Netflixは、フェデレーションGraphQL APIを大規模に実装することに成功した。最近のブログ投稿シリーズとQConPlusの講演で、Netflixのエンジニアが彼らの旅とその過程で学んだ教訓について説明している。
Netflixのソフトウェアシステムは、さまざまなペースと規模で個別に進化する何百もの独立したマイクロサービスで構成されている。これは、サービス構造をカプセル化し、UI開発者からその複雑さを隠す統合API集約レイヤ (またはAPIゲートウェイ) を採用している。ただし、システムが複雑になるにつれて、APIゲートウェイを単一のチームで維持することがますます困難になった。それは事実上モノリスになっている。
この問題を解決するために、NetflixはGraphQL Federationに基づくソリューションを採用することを決定した。このアプローチでは、APIゲートウェイの実装は、実装するドメイングラフサービス (DGS) を介して、個々のドメインサービスを所有するバックエンドチームに配布される。この変更により、フェデレーションゲートウェイはすべてのドメイン固有のビジネスロジックをDGSに委任できる。ゲートウェイ自体は、クエリプランニングと、ロギングやモニタリングなどの集中タスクのみを処理する。
出典: https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2
彼らは、Netflix Studio APIを最初のフェデレーションゲートウェイの実装とすることを決定した。Studio APIは、テレビ番組や映画が売り込まれてからNetflixで利用できるようになるまでのビジネスプロセスを管理する。エンジニアは、「GraphQLとフェデレーションは生産性に相乗効果がありました」と述べている。プロセスを次のように要約する:
私たちの前向きな経験にもかかわらず、GraphQL Federationは成熟ライフサイクルの初期段階にあり、すべてのチームや組織に最適であるとは限りません。GraphQLとDGSの開発を学び、フェデレーションレイヤを実行し、移行を行うには、パートナチームからの高いコミットメントとシームレスなクロスファンクショナルコラボレーションが必要です。(...) 集約する必要のあるマイクロサービスの大規模な範囲を持つ私たちのようなエコシステムの場合、開発速度と改善された操作性により、移行は価値があります。
以下に、NetflixのフェデレーションGraphQL実装への進化をまとめた:
出典: https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2
- 当初、モノリシックバックエンドはNetflixのすべての機能を実装していました。モノリスの複雑さは、維持するのが困難になるまで時間とともに増大した。
- その後、バックエンドのモノリスは複数のマイクロサービスに分割され、UI開発者に直接公開されました。この分割はバックエンド開発にとって価値があることが証明されているが、クライアントの複雑さを劇的に増加させた。
- マイクロサービスのクライアントから複雑さを隠すための抽象化として、ゲートウェイ集約レイヤ (APIゲートウェイ) が追加された。APIの複雑さが増すにつれて、このレイヤはモノリスに成長した。
- フェデレーションGraphQLは、ゲートウェイモノリスを分割するために使用される。これにより、ドメイン開発者は、統合されたAPIをクライアントに公開しながら、ゲートウェイの一部を維持できる。
Netflixのエンジニアは、GraphQLフェデレーションへの移行に課題があったことを認める:
最大の課題は、組織全体でこの戦略を調整することでした。当初、多くの懐疑論と反対意見がありました。この概念はかなり新しく、成功するには組織全体で高度な調整が必要でした。私たちのチームは、開発者からのフィードバックに基づいて、反対意見に対処し、アーキテクチャを調整することに多くの時間を費やしました。プロトタイプの開発といくつかの重要な重要な声との積極的なパートナーシップを通じて、自信を植え付け、重要なギャップを埋めることができました。
彼らは、これらの課題をより適切に処理するために取ったいくつかのステップを詳しく説明する:
- コアインフラストラクチャ - 彼らのGraphQL GatewayはKotlinで書かれている。この選択により、JavaよりもKotlinのリッチさを維持しながら、NetflixのJavaエコシステムにアクセスできる。また、Cassandraデータベース上でイベントソーシングパターンを利用して、KotlinでGraphQLスキーマを管理するためのスキーマレジストリを開発した。
- 開発者エクスペリエンス - 新しいアーキテクチャでは、すべてのDGSチームがGraphQLサービスを学習して構築する必要がある。エクスペリエンスを向上させるために、彼らはこれらのサービスのオーサリングを容易にするためのフレームワークを作成した。このフレームワークは、2021年初頭にオープンソース化される予定だ。
- スキーマガバナンス - 彼らには、組織全体のデータモデリングと調整に焦点を当てたStudio Data Architectがいた。また、チームの境界を越えたフィードバックとレビューを含む共同設計プロセスを採用している。
- 可観測性 - Netflixのエンジニアは、「ゲートウェイとDGSのアーキテクチャコンポーネントをZipkin、内部分散トレースツールEdgar、およびアプリケーション監視ツールTellTaleと統合した」 また、ゲートウェイで分散ログ相関メカニズムを採用して、より複雑なサーバの問題のデバッグを支援した。
- セキュリティ - 異なるレイヤが同じルールを実装する可能性がある過去の状況とは対照的に、承認はDGS所有者に委任される。承認ルールごとに1つの実装があり、さまざまなアプリケーション間で同じユーザに対して一貫した承認が得られる。
実装のベースはGraphQL Federationだ。GraphQL Federationは、スキーマの責任とクエリ実行を複数のサービスに分割することで機能する。次に、ゲートウェイは、合意された識別子を使用してこれらのサービスのクエリ結果をマージし、クライアントから複雑さを隠す。Netflixのエンジニアは、映画データを担当するMovies DSG、制作関連データの管理を担当するProduction DSG、映画に取り組んでいるタレント (俳優、監督等々) のデータを管理するTalent DSGの3つの主要サービスで構成される例を提供する。これらのサービスを前提として、映画のタイトルと制作IDおよび俳優の名前を簡単にクエリすると、次のクエリプランが作成される:
出典: https://netflixtechblog.com/how-netflix-scales-its-api-with-graphql-federation-part-1-ae3557c187e2
フェデレーションゲートウェイは、クライアントクエリを関連するDSGの個別のクエリに分割し、それらを最適化された方法で順次または並列に実行し、結果をステッチバックして複雑さを抽象化する。ドメインチームはビジネスロジックに責任があるため、APIは全体としてはるかに速いペースで進化できる。