BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ アーティクル NetflixにおけるFederated GraphQLプラットフォームの進化

NetflixにおけるFederated GraphQLプラットフォームの進化

キーポイント

  • Federated GraphQLは、グラフの所有権を複数のチームに分散させる。これは、すべてのチームがFederated GraphQLを採用し、学習する必要があり、開発者とスキーマのワークフローのための充実したエコシステムを提供することで達成できる。

  • カスタムツールを構築する前に、コミュニティにて採用されている既存のツールやリソースを使用し、初期採用者と徐々に協力してギャップを特定することが有効だ。

  • (D)omain(G)raph(S)ervices(DGS)フレームワークは、Spring BootベースのJavaフレームワークであり、開発者が簡単にGraphQLサービスを構築できるようにして連携グラフの一部にできる。DGSフレームワークは、Netflixのエコシステムとすぐに統合できる多くの機能を提供するが、コアはオープンソースプロジェクトとしてコミュニティに公開されている。

  • より多くのチームが参加するにつれ、我々は開発規模に追いつく必要があった。GraphQLサービスの構築を支援するだけでなく、スキーマ連携のために手作業のワークフローを、連携グラフにて作業を支援するエンドツーエンドのスキーマ開発ワークフローに対応するために、より多くのツールに置き換える必要があった。

  • 現在では、200以上のサービスが連携グラフの一部となっている。Federated GraphQLは、Netflixにおけるサクセスストーリーであり続けている。我々は、ストリーミングAPIをfederated architectureに移行し、グラフのパフォーマンスとオブザーバビリティ(可観測性)を向上させるために投資を続けている。

 

この記事では、Federated GraphQLアーキテクチャへの移行の過程を説明する。具体的には、Spring Bootとgraphql-javaを使用してJavaでGraphQLサービスを実装するためのDGS(Domain Graph Services)フレームワークとスキーマ開発用ツールで構成されるGraphQLプラットフォームについて説明する。また、エコシステムが採用の様々な段階で進化してきたかを説明する。

なぜFederated GraphQLなのか?

Netflixはここ数年、オリジナルコンテンツを進化させている。スタジオ組織内の多くのチームが、タレント管理、予算管理、ポストプロダクションなど、制作を促進するためのアプリケーションやサービスに取り組んでいる。

いくつかのケースでは、チームはgRPC、REST、さらにはGraphQLを使って独自にAPIを作成していた。クライアントは、必要なデータを取得するために、1つ以上のバックエンド・サービスを用いなければならない。実装に一貫性がなく、同じデータを取得する方法が多くあるため、真実のソースが複数であった。これを改善するために、モノリスにサポートされた共通のGraphQL APIを作成した。クライアント・チームは、この共通のAPIを通じて必要なすべてのデータにアクセスでき、単一のバックエンド・サービスと話すだけで済むようになった。モノリスは、1つのGraphQLレスポンスでデータを取得して返すために、必要なすべてのバックエンドと通信するすべての作業が行われる。

しかし、このモノリスは、より多くのチームがこの統一されたGraphQL APIの背後にデータを追加すると、拡張できなくなった。入ってくるリクエストを、様々なサービスに対応する呼び出しに対し、どのように変換するかを決定するには、ドメインの知識が必要だった。これは、このグラフを維持するチームにメンテナンスと運用の負担を生じさせた。さらに、スキーマの進化も、主にデータを担当する製品チームが所有するものではないため、クライアント向けのAPIの設計は不十分であった。

私たちは、データを所有するチームが、クライアント開発者が対話するための統一されたGraphQL APIを維持しながら、そのGraphQL APIにも責任を持てるような、異なる所有権モデルを模索したいと考えた(図1参照)。

図1:グラフの所有権のフェデレーション(連携)

2019年、ApolloはFederation Specをリリースし、チームが単一のグラフの一部でありながらサブグラフを所有できるようになった。言い換えれば、入ってくるGraphQLリクエストを処理するさまざまなリゾルバをバラバラにすることで、グラフの所有権を複数のチームでフェデレーションできるようになった。モノリスの代わりに、Domain Graph Servicesと呼ばれるシンプルなゲートウェイを使うことができる。これはサブグラフにサービスを提供するGraphQLバックエンドにリクエストをルーティングするものだ。各DGSは、同じチームが所有して対応するバックエンドからのデータを取得する(図2参照)。我々はFederated GraphQL Gatewayのカスタム実装の実験を開始し、この新しいアーキテクチャに移行するためにいくつかのチームと作業を開始した。

図2:Federated GraphQLアーキテクチャ

それから数年が経ち、現在では150以上のサービスがこのグラフの一部となっている。studio graphを拡張しただけでなく、社内のプラットフォーム・ツールやストリーミングAPIの移行用など、他のドメイン用のグラフも作成した。

初期導入段階

移行を開始したとき、私たちのGraphQLモノリスが提供するfederated graphには、すでに約40のチームが参加していた。これらのチームすべてに、まったく新しいアーキテクチャへの移行を依頼した。これは、我々にとってもまったく新しい概念であるFederated GraphQLの知識を必要とした。優れた開発者体験を提供することが、この規模での採用を成功させる鍵だった。

当初、新しいアーキテクチャへの移行を選択したチームは少数だった。私たちは、開発者のワークフロー、ギャップ、そして知識のギャップを埋め、移行プロセスを容易にするために必要なツールをよりよく理解するために、チームの開発者に働きかけた。

私たちの目標は、採用者が新しいGraphQLサービスを実装し、できるだけ簡単に連携グラフの一部にすることだった。私たちはいくつかのツールやフレームワークで構成されるGraphQLプラットフォームを徐々に構築し始め、採用のさまざまな段階で進化を続けた。

進化するGraphQLエコシステム

Domain Graph Services(DGS)フレーム ワークは、graphql-javaベースのSpring Bootライブラリであり、開発者がGraphQLリゾルバを彼らのスキーマに簡単につなぐことを可能にする。当初、私たちはNetflixの開発者向けに、セキュリティ、メトリクス、トレースのためのNetflix固有の統合をすぐに提供することを目標に、このフレームワークを作成した。加えて、手作業でリゾルバにつなぐ作業をなくしたかったので、コアの一部としてカスタムDGSアノテーションを使用して最適化した。図3は、開発者が選択できるいくつかのオプトイン機能を備えたフレームワークのモジュラーアーキテクチャーを示している。

図3:DGSフレームワークのアーキテクチャ

DGSフレームワークを使用する場合、開発者は単にビジネス・ドメイン・ロジックに集中でき、GraphQLのすべての仕様を学ぶ必要はない。さらに、スキーマを表すJavaまたはKotlinクラスを生成するためのコード生成Gradleプラグインを作成した。これにより、これらのクラスを手動で作成する必要がなくなった。

時間の経過とともに、Netflix以外のサービス開発者にとっても、より一般的に役立つ機能を追加していった。2021年初めにDGSフレームワークDGSコード生成プラグインをオープンソース化し、進化させ続けることを決めた。また、スキーマからデータリゾルバの実装へのナビゲーションと、DGSを実装するためのコード補完スニペットを提供するDGS IntelliJプラグインも作成した。

GraphQLサービスが実装に取り組んだ次のステップは、DGSを登録し、連携グラフの一部とすることだ。スキーマを対応するサービスにマッピングするために、スキーマ・レジストリ・サービスを実装した。連携ゲートウェイはスキーマレジストリを使用して、入力されたクエリからどのサービスにアクセスするかを決定する。また、開発者がDGSを管理し、連携スキーマを発見できるように、このスキーマレジストリサービスのセルフサービスUIを実装した。

最後に、GraphQL用の既存のオブザーバビリティツールを強化した。我々の分散トレースツールは、相関するログを表示する機能に加え、コールグラフの全体的なビューを提供して、パフォーマンスの問題やリクエストエラーを簡単にデバッグできた。

Federated GraphQLプラットフォームのスケーリング

2019年初めにこの取り組みを開始して以来、200以上のチームが連携グラフに参加している。federated Graph QLアーキテクチャの採用は大成功したので、Studio Graphに加えて他のドメイン用のグラフをさらに作成することになった。現在では、Enterpriseグラフと呼ぶ内部プラットフォーム・ツール用のものと、ストリーミングAPI用のものがある。

新しいEnterpriseグラフを導入した後、チームがEnterprise GraphとStudio Graphの一部として、同じDGSの公開に関心があることに気づいた。同様に、クライアントも両方のグラフからデータを取得することに関心を持っていた。そこで、StudioとEnterpriseのグラフを1つの大きなスーパーグラフに統合した。これにより、開発者の規模や数に応じてグラフをスケーリングするという、別の課題が発生した。

グラフが大きくなったことで、スキーマ・レビュー・グループのメンバーがほとんど手作業で監督していたため、スキーマ・レビュー・プロセスの規模の拡大が難しくなった(図4参照)。このようなプロセスの一部の自動化には、多くのツールを作成する必要があった。私たちは、GraphDoctorというツールを作成し、スキーマの照合して、登録されている全サービスのスキーマ変更に関連するPRを自動的にコメントした。私たちはグラフの他の部分に影響を与えることなく、スキーマの変更をテストするサンドボックス環境をステージングするGraphLabsをスキーマ・コラボレーションにて支援した。これにより、フロントエンドとバックエンドの開発者の両方が、スキーマの変更についてより迅速にコラボレーションできた(図4参照)。

図4:スキーマ開発ワークフロー

開発者サポートモデル

私たちは、ドメイングラフサービスの実装とグラフでの作業を円滑にするためにGraphQLプラットフォームを構築した。しかし、これだけでは十分ではなく、優れた開発者サポートで経験を補完する必要があった。当初、私たちはチームで集結して、多くの移行作業を行うことで、最高の移行体験を提供した。これにより、開発者の経験を向上させるために何を構築すべきかについて、多くの知見が得られた。私たちは、開発者がビジネス・ロジックに集中し、反復的なコードのセットアップを排除できることで、実装のスピードアップに役立つ既存ソリューションの欠点を特定した。

安定したプラットフォームの入手後は、より多くのチームを迅速に取り込めた。また、フェデレーションやGraphQLの概念に関する優れたドキュメントやチュートリアルを開発者に提供することにも多大な投資をして、開発者が簡単にセルフサービスできるようにした。私たちは、営業時間中にSlackを介した社内のコミュニケーション・チャンネルで開発者サポートを提供し続け、どんな質問にも答え、問題が発生した場合にはトラブルシューティングを行っている。

開発者への影響

GraphQLプラットフォームは、スキーマの設計から始まり、GraphQLサービスにおけるスキーマの実装、連携グラフの一部となるサービスの登録、そしてデプロイ後の同じ操作まで、ワークフロー全体の経路を完全に整備して提供している。これにより、より多くのチームがこのアーキテクチャを採用するようになり、Netflixでは従来のREST APIよりもGraphQLが普及している。特に、Federated GraphQLは、フロントエンド開発者のデータアクセスを大幅に簡素化し、チームが迅速にプロジェクトを進められる。

我々の学び

開発者の経験に大きく投資することで、他の方法よりもはるかに速いペースで採用を推進できた。私たちは、コミュニティ・ツールの活用でスモール・スタートを切った。その結果、ギャップやカスタム機能が必要な箇所を特定できた。私たちはDGSフレームワークと、コード生成プラグインや基本的なスキーマ管理のためのツールのエコシステムを構築した。

基本的なワークフローに取り組んだことで、より包括的なスキーマワークフローツールに注力できた。採用が増えるにつれて、問題を特定し、より大きなグラフで動作するようにプラットフォームを適応させ、開発者の増加に合わせて拡張できた。スキーマ・レビュー・プロセスの一部を自動化したことで、より大きなグラフでの作業が容易になった。私たちは、新しい使用事例の発生を見続けており、同じような事例に対して舗装されたソリューションを提供できるよう、プラットフォームの進化に取り組んでいる。

今後の展望は?

これまでのところ、Studioアーキテクチャを統合GraphQLに移行し、内部プラットフォームチーム用の新しいグラフをStudioグラフと統合することで、1つの大きなスーパーグラフを形成している。現在は、Netflix UIのディスカバリー体験を支えているNetflixストリーミングAPIを同様なモデルに移行している。この新しいグラフには、異なる課題が伴う。Netflixストリーミング・サービスは様々なデバイスでサポートされており、UIはそれぞれのプラットフォームで異なるようにレンダリングされる。異なる使用事例に対応して、スキーマをうまく設計する必要がある。

もう一つの大きな違いは、ストリーミング・サービスは、他の既存のグラフとは異なり、かなり高いRPSの処理が必要だ。我々は、GraphQLサービスをより高性能にするために、フレームワークとツールのパフォーマンス・ボトルネックを特定している。同時に、これらのサービスをスケールで運用できるように、オブザーバビリティツールの改善も行っている。

作者について

この記事に星をつける

おすすめ度
スタイル

BT