ソニー: GraphQLを活用したデータ配信プラットフォームの事例紹介

「2024年こそ使いこなす！GraphQL最前線」で発表した資料です。

ソニーのホームエンタテインメント領域では、TVやサウンドバー、ヘッドホンをはじめとする様々な製品、それらに付随するアプリケーションを取り扱っています。我々はホームエンタテインメント領域の横断組織として、それらの製品・アプリに対してクラウドサービスを提供しています。この領域において頻繁に要求される機能の一つに、データ配信があります。従来は製品・アプリの案件ごとにそれぞれ個別にサービスを開発しており、サービス間連携やリソースの共通化など横断組織ならではの利点をうまく発揮することができていませんでした。本セッションでは、この問題を解決すべく開発した共通データ配信プラットフォームについて、そこで活用されているGraphQLという技術との関係について、お話しします。

1. GraphQLを活用したデータ配信プラットフォームの事例紹介 2024.01.30 ソニー株式会社 クラウドサービス・アプリケーション技術部門 クラウドソリューション開発部 加藤 慎
2. 2 2024年こそ使いこなす！GraphQL最前線 自己紹介 • 経歴 • 2021- ソニー株式会社 • TVやサウンドバー、ヘッドホンをはじめとする製品向けのクラウドサービス開発・運用を担当 • 個人開発（OSS開発） • github.com/Aton-Kish 加藤 慎 ソニー株式会社 クラウドサービス・アプリケーション技術部門 クラウドソリューション開発部
3. 3 2024年こそ使いこなす！GraphQL最前線 本日お話しすること • データ配信プラットフォーム • 背景・課題 • 構成 • 技術選定 • 開発・運用上の問題
4. データ配信プラットフォームの背景・課題
5. 5 2024年こそ使いこなす！GraphQL最前線 社内での我々の立ち位置 TVやサウンドバー、ヘッドホンをはじめとするHome Entertainment & Sound領域の 様々な製品・アプリに対して横断的にクラウドサービスを提供 「ソニーでの事例から考えるプラットフォーム開発 | 今から予測する2024年のPlatform Engineering」より https://forkwell.connpass.com/event/303922/
6. 6 2024年こそ使いこなす！GraphQL最前線 どのようなデータを配信している？ Sony | Headphones Connect • ソニー製のヘッドホンの設定をカスタマイズするモバイルアプリ • ヘッドホンの画像など一部の情報はサーバから取得して表示 データ配信サービス このヘッドホン の情報をください
7. 7 2024年こそ使いこなす！GraphQL最前線 どのようなデータを配信している？ Sony | Home Entertainment Connect • ソニー製のサウンドバーなどの対応機器をセットアップ・操作するモバイルアプリ • 機器セットアップ手順やプライバシーポリシーなどの情報をサーバから取得して表示 データ配信サービス このサウンドバー の情報をください
8. 8 2024年こそ使いこなす！GraphQL最前線 データ配信プラットフォームの構想 Home Entertainment & Sound領域で扱うあらゆるデータを 製品・アプリが取得できるEndpointを提供する データ配信 プラットフォーム Products Data Sources
9. 9 2024年こそ使いこなす！GraphQL最前線 従来のデータ配信における問題点 • 単純なデータ配信APIでも各種工数が大きい • データを配布するだけの単純な仕組みでも開発、セキュリティ対応、社内申請で工数が大きくなる • 単純なデータ配信にも時間がかかりすぎている（月単位でかかっている） • インフラ（最低でもAPI Gateway/Lambda）からCICDの仕組みを用意してリリースまで行っていると 1-2カ月かかっているのが現状 • リソースは分かれていてもアーキテクチャは同じようなことが多いので効率化の余地がある API A API B 開発・運用
10. 10 2024年こそ使いこなす！GraphQL最前線 従来のデータ配信における問題点 • クライアント間でデータの取得方法・データ形式が定まっておらずデータ共有が難しい データ共有したとしてもクライアントにとって必要十分なデータを提供できない • 案件が発生する度に接続方法、API定義/APIサーバの構築を行っているため 各API仕様が各クライアントの仕様に依存している • 同じデータ（API）を他クライアントで流用しようとしても不都合が出てくるケースが多い • 主にデータ形式がアプリに依存していることが原因 API for Client A Client A Client B
11. 11 2024年こそ使いこなす！GraphQL最前線 従来のデータ配信における問題点 • 複数のデータ配信APIにセキュリティリスクが散らばっている • 案件ごとにAPIを構築しており、各APIに認証の仕組みを導入する必要がある • クライアントが複数のデータソースのデータを扱おうとするとAPIがわかれているため、 複数のEndpoint情報、認証情報を持たなくてはならず管理が大変 • 今後もクライアント側に延々と追加されていく Client API A API B API C API D
12. 12 2024年こそ使いこなす！GraphQL最前線 データ配信プラットフォーム開発のミッション Home Entertainment & Soundの製品群が 素早く、秩序を持って、柔軟に、安全にデータを取得できる環境を提供する • 素早く • 最低限の工数でデータ配信を行える仕組みを構築する • 秩序 • データ配信のインターフェイスを統一し、共有を容易にする • 柔軟に • クエリやフィルタリングによりクライアントに必要十分なデータを提供する • 安全に • データ配信のEndpointを統一することでセキュリティリスクを集約する
13. 13 2024年こそ使いこなす！GraphQL最前線 データ配信プラットフォーム開発のミッション Home Entertainment & Soundの製品群が 素早く、秩序を持って、柔軟に、安全にデータを取得できる環境 • 素早く • 最低限の工数でデータ配信を行える仕組みを構築する • 秩序 • データ配信のインターフェイスを統一し、共有を容易にする • 柔軟に • クエリやフィルタリングによりクライアントに必要十分なデータを提供する • 安全に • データ配信のEndpointを統一することでセキュリティリスクを集約する 問題点との対応関係
14. 14 2024年こそ使いこなす！GraphQL最前線 データ配信プラットフォーム開発のミッション Home Entertainment & Soundの製品群が 素早く、秩序を持って、柔軟に、安全にデータを取得できる環境を提供する • 素早く • 最低限の工数でデータ配信を行える仕組みを構築する • 秩序 • データ配信のインターフェイスを統一し、共有を容易にする • 柔軟に • クエリやフィルタリングによりクライアントに必要十分なデータを提供する • 安全に • データ配信のEndpointを統一することでセキュリティリスクを集約する これらはGraphQLが得意なこと！
15. データ配信プラットフォームの構成
16. 16 2024年こそ使いこなす！GraphQL最前線 Server Server データ配信プラットフォームの構成 client database GraphQL Gateway GraphQL API ・ ・ ・
17. 17 2024年こそ使いこなす！GraphQL最前線 Server Server データ配信プラットフォームの構成 client database GraphQL Gateway GraphQL API ・ ・ ・ GraphQL Gateway バックエンドデータ配信API 2段構成 • 統一された共通エンドポイントをクライアントに提供するGraphQL Gateway • 各プロジェクトごとに用意するバックエンドデータ配信API
18. 18 2024年こそ使いこなす！GraphQL最前線 Server Server client database GraphQL Gateway GraphQL API ・ ・ ・ データ配信プラットフォームの構成 AppSync GraphQL API DynamoDB 既存のサービス API App Runner Apollo Server GraphQL Shield GraphQL Mesh GraphQL Gateway バックエンドデータ配信API
19. 19 2024年こそ使いこなす！GraphQL最前線 Server Server client database GraphQL Gateway GraphQL API ・ ・ ・ AppSync GraphQL API DynamoDB 既存のサービス API App Runner Apollo Server GraphQL Shield GraphQL Mesh GraphQL共通エンドポイントの提供により ・データの取得方法・データ形式の統一 ・クライアントは必要十分なデータを取得可能に ・セキュリティリスクが集約し守るべきものがシンプルに アーキテクチャパターンの共通化により 各種工数削減が可能に！ データ配信プラットフォーム開発のミッション達成 Home Entertainment & Soundの製品群が 素早く、秩序を持って、柔軟に、安全にデータを取得できる環境を提供する
20. データ配信プラットフォームの技術選定
21. 21 2024年こそ使いこなす！GraphQL最前線 Server Server client database GraphQL Gateway GraphQL API ・ ・ ・ バックエンドデータ配信APIの技術選定 AppSync GraphQL API DynamoDB 既存のサービス API App Runner Apollo Server GraphQL Shield GraphQL Mesh
22. 22 2024年こそ使いこなす！GraphQL最前線 バックエンドデータ配信APIの技術選定 • 単純なデータ配信APIの開発・運用には工数をかけたくない → AWSのGraphQLマネージドサービスであるAWS AppSyncを採用 画像: https://docs.aws.amazon.com/ja_jp/appsync/latest/devguide/api-components.html
23. 23 2024年こそ使いこなす！GraphQL最前線 バックエンドデータ配信APIの技術選定 AWS AppSync • マネジメントコンソールにGraphQL API開発に必要なものが一通り揃っている • 「DynamoDBからレコードを取得するだけ」など単純なデータ配信APIの案件は AppSyncが用意しているリゾルバテンプレートを選ぶだけで実現可能 → クライアント開発者にAppSyncの開発・運用をお任せできる！ 要件すり合わせのオーバヘッドがなくなり効率化
24. 24 2024年こそ使いこなす！GraphQL最前線 Server Server client database GraphQL Gateway GraphQL API ・ ・ ・ GraphQL Gatewayの技術選定 AppSync GraphQL API DynamoDB 既存のサービス API App Runner Apollo Server GraphQL Shield GraphQL Mesh
25. 25 2024年こそ使いこなす！GraphQL最前線 GraphQL Gatewayの技術選定 AppSyncは「統合されたエンドポイントで複数データにアクセスする」というコンセプトを 掲げている 画像: https://aws.amazon.com/jp/appsync/
26. 26 2024年こそ使いこなす！GraphQL最前線 GraphQL Gatewayの技術選定 AppSyncは「統合されたエンドポイントで複数データにアクセスする」というコンセプトを 掲げている 2023.05にAppSync Merged APIが登場し 複数のGraphQL APIを束ねることができるようになった → 2024年現在ならGraphQL Gatewayの 技術としてAppSyncが有力候補に挙がる 画像: https://aws.amazon.com/jp/blogs/mobile/introducing-merged-apis-on-aws-appsync/
27. 27 2024年こそ使いこなす！GraphQL最前線 GraphQL Gatewayの技術選定 画像: https://aws.amazon.com/jp/blogs/mobile/introducing-merged-apis-on-aws-appsync/ AppSyncは「統合されたエンドポイントで複数データにアクセスする」というコンセプトを 掲げている 2023.05にAppSync Merged APIが登場し 複数のGraphQL APIを束ねることができるようになった → 2024年現在ならGraphQL Gatewayの 技術としてAppSyncが有力候補に挙がる しかし開発当時はMerged APIがまだ存在せず、 別の手段を考える必要があった
28. 28 2024年こそ使いこなす！GraphQL最前線 GraphQL Gatewayの技術選定―データソースを束ねる GraphQL Mesh • The Guild（OSS開発者のグループ）によるGraphQL Gatewayフレームワーク • GraphQL API, REST APIをはじめとする、あらゆるデータソースを束ねる機能をもつ 画像: https://the-guild.dev/graphql/mesh
29. 29 2024年こそ使いこなす！GraphQL最前線 GraphQL Gatewayの技術選定―データソースを束ねる GraphQL Mesh • The Guild（OSS開発者のグループ）によるGraphQL Gatewayフレームワーク • GraphQL API, REST APIをはじめとする、あらゆるデータソースを束ねる機能をもつ Server Server client database GraphQL API ・ ・ ・ 束ねてくれる GraphQL Gateway GraphQL Mesh
30. 30 2024年こそ使いこなす！GraphQL最前線 GraphQL Gatewayの技術選定―GraphQL Server • Meshはデータソースを束ねる機能がメインなので別途GraphQL Serverが必要 • Meshにデフォルトで統合されるサーバはThe GuildによるGraphQL Yoga • しかし開発時点ではYogaは成熟していなかった → Apollo Serverを採用 Server Server client database GraphQL API ・ ・ ・ GraphQL Gateway GraphQL Mesh Apollo Server
31. 31 2024年こそ使いこなす！GraphQL最前線 GraphQL Gatewayの技術選定―アクセス制御 • GraphQL Gatewayとして共通エンドポイントを提供するが クライアントはすべてのデータソースを触る必要はないことが多い • The GuildによるGraphQL Shieldでデータソースごとのアクセス制御を実現 Server Server client database GraphQL API ・ ・ ・ GraphQL Gateway GraphQL Mesh Apollo Server GraphQL Shield アクセス制御
32. 32 2024年こそ使いこなす！GraphQL最前線 GraphQL Gatewayの技術選定―インフラ • インフラをなるべくメンテナンスせずに運用したい → AWSのコンテナアプリケーションのマネージドサービスであるAWS App Runnerを採用 Server Server client database GraphQL API ・ ・ ・ App Runner Apollo Server GraphQL Shield GraphQL Mesh
33. 33 2024年こそ使いこなす！GraphQL最前線 データ配信プラットフォームが完成したので、これでうまくいくはず…！
34. 34 2024年こそ使いこなす！GraphQL最前線 残念ながら、うまくいくことばかりではない
35. データ配信プラットフォームの開発・運用上の問題
36. 36 2024年こそ使いこなす！GraphQL最前線 開発・運用上の問題点 • GraphQL APIのエラーハンドリングが難しい • GraphQLの複数の操作を一度に実行できる特性により部分的にリクエストが成功/失敗する 可能性があり、REST APIのようにHTTP Status Codeでエラーを表現することができない • HTTP Status CodeではなくGraphQLレスポンス内に独自のエラーコードを含めることで表現する • 一方でインフラ自体に問題がある場合は従来通りHTTP Status Codeでエラーが表現される 例）大量リクエスト＝429エラー、サーバダウン＝503エラー、など → クライアントサイドのエラーハンドリングロジックが従来のREST APIのものとは異なり クライアント開発者の学習コストがそこそこ高くなる client GraphQL Gateway 200 OK {"errors": [{"extensions": {"code": "HOGE_ERROR"}}]} 429 Too Many Requests 503 Service Unavailable
37. 37 2024年こそ使いこなす！GraphQL最前線 開発・運用上の問題点 • GraphQL APIの監視設計が難しい • REST APIでは参考情報がたくさん出てくるがGraphQL APIは情報が少ない • 自分たちの監視したい項目を洗い出しつつ、Apollo StudioなどのSaaSを参考に設計 • 200 OKでエラーが返ることもあるので、4XX/5XXメトリクスの監視だけでは障害を見落とす可能性がある → ログベースでGraphQLエラーコードのカスタムメトリクスを作成して監視 • 従来よりREST APIのリクエスト成功率は以下の式で計算していたが、GraphQL APIでも成り立つ？ リクエスト成功率 = 200レスポンス数 / (200レスポンス数+5XXレスポンス数) → GraphQLエラーの内容に応じてHTTP Status Codeを上書きして計算式が成り立つように工夫 GraphQL Gateway 200 OK {"errors": [{"extensions": {"code": "HOGE_ERROR"}}]} 200 OK 400 Bad Request {“errors”: [{“extensions”: {“code": "BAD_REQUEST"}}]} 200 OK 500 Internal Server Error {“errors”: [{“extensions”: {“code": "INTERNAL_SERVER_ERROR"}}]} メトリクス監視
38. 38 2024年こそ使いこなす！GraphQL最前線 開発・運用上の問題点 • GraphQL Meshがまだv0なので不安定 • 仕方のないことだが破壊的変更が入るときは入ってしまう • 既存コードや連携部分が動かなくなることもあるのでバージョン上げ作業は根気が必要 • 一方でバージョン上げするだけで性能向上することもあるので一概に悪者ではない • 幸いサービスインしてからは仕様変更せざるを得ないような破壊的変更がないのでなんとかなっている • 2023.05にv1.0.0-alphaリリースされたが、残念ながらv1はまだ遠そうな予感… • ちなみに… • Apollo Serverは2023.10.22にv2/v3のEOLを迎えたが、v4移行ガイドが丁寧に 用意されていたのでとてもスムーズに移行できた • よく言われることではあるが、保守していく上では成熟したプロジェクトを選定することも重要だと再認識
39. 39 2024年こそ使いこなす！GraphQL最前線 開発・運用上の問題点 • (GraphQL関係ないですが)AWS App Runnerの扱いが意外と難しい • インフラをなるべくメンテナンスせずに運用したくて選定したはいいけど割と新しいサービスなので • 不具合時のプラクティスが不十分だったり • 痒い所に手が届かなかったり • … • 2/21(水)に「App Runner」をテーマとする勉強会の開催を予定しているので、 詳しくはそちらでお話しします！
40. 40 2024年こそ使いこなす！GraphQL最前線 まとめ • 従来のデータ配信サービスが抱えていた問題点をGraphQLを活用して解決した • 素早く、秩序を持って、柔軟に、安全にデータを取得できるデータ配信プラットフォームを開発 • 一方で、開発・運用上の問題点は様々出てきているのでまだまだ改善の余地あり Server Server client database GraphQL Gateway GraphQL API AppSync GraphQL API DynamoDB 既存のサービス API App Runner Apollo Server GraphQL Shield GraphQL Mesh
41. SONYはソニー株式会社の登録商標または商標です。 各ソニー製品の商品名・サービス名はソニー株式会社またはグループ各社の登録商標または商標です。その他の製品および会社名は、各社の商号、登録商標または商標です。