Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

Shin Kato
January 30, 2024

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

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

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

Shin Kato

January 30, 2024
Tweet

Other Decks in Technology

Transcript

  1. 2 2024年こそ使いこなす!GraphQL最前線 自己紹介 • 経歴 • 2021- ソニー株式会社 • TVやサウンドバー、ヘッドホンをはじめとする製品向けのクラウドサービス開発・運用を担当

    • 個人開発(OSS開発) • github.com/Aton-Kish 加藤 慎 ソニー株式会社 クラウドサービス・アプリケーション技術部門 クラウドソリューション開発部
  2. 6 2024年こそ使いこなす!GraphQL最前線 どのようなデータを配信している? Sony | Headphones Connect • ソニー製のヘッドホンの設定をカスタマイズするモバイルアプリ •

    ヘッドホンの画像など一部の情報はサーバから取得して表示 データ配信サービス このヘッドホン の情報をください
  3. 7 2024年こそ使いこなす!GraphQL最前線 どのようなデータを配信している? Sony | Home Entertainment Connect • ソニー製のサウンドバーなどの対応機器をセットアップ・操作するモバイルアプリ

    • 機器セットアップ手順やプライバシーポリシーなどの情報をサーバから取得して表示 データ配信サービス このサウンドバー の情報をください
  4. 9 2024年こそ使いこなす!GraphQL最前線 従来のデータ配信における問題点 • 単純なデータ配信APIでも各種工数が大きい • データを配布するだけの単純な仕組みでも開発、セキュリティ対応、社内申請で工数が大きくなる • 単純なデータ配信にも時間がかかりすぎている(月単位でかかっている) •

    インフラ(最低でもAPI Gateway/Lambda)からCICDの仕組みを用意してリリースまで行っていると 1-2カ月かかっているのが現状 • リソースは分かれていてもアーキテクチャは同じようなことが多いので効率化の余地がある API A API B 開発・運用
  5. 12 2024年こそ使いこなす!GraphQL最前線 データ配信プラットフォーム開発のミッション Home Entertainment & Soundの製品群が 素早く、秩序を持って、柔軟に、安全にデータを取得できる環境を提供する • 素早く

    • 最低限の工数でデータ配信を行える仕組みを構築する • 秩序 • データ配信のインターフェイスを統一し、共有を容易にする • 柔軟に • クエリやフィルタリングによりクライアントに必要十分なデータを提供する • 安全に • データ配信のEndpointを統一することでセキュリティリスクを集約する
  6. 13 2024年こそ使いこなす!GraphQL最前線 データ配信プラットフォーム開発のミッション Home Entertainment & Soundの製品群が 素早く、秩序を持って、柔軟に、安全にデータを取得できる環境 • 素早く

    • 最低限の工数でデータ配信を行える仕組みを構築する • 秩序 • データ配信のインターフェイスを統一し、共有を容易にする • 柔軟に • クエリやフィルタリングによりクライアントに必要十分なデータを提供する • 安全に • データ配信のEndpointを統一することでセキュリティリスクを集約する 問題点との対応関係
  7. 14 2024年こそ使いこなす!GraphQL最前線 データ配信プラットフォーム開発のミッション Home Entertainment & Soundの製品群が 素早く、秩序を持って、柔軟に、安全にデータを取得できる環境を提供する • 素早く

    • 最低限の工数でデータ配信を行える仕組みを構築する • 秩序 • データ配信のインターフェイスを統一し、共有を容易にする • 柔軟に • クエリやフィルタリングによりクライアントに必要十分なデータを提供する • 安全に • データ配信のEndpointを統一することでセキュリティリスクを集約する これらはGraphQLが得意なこと!
  8. 17 2024年こそ使いこなす!GraphQL最前線 Server Server データ配信プラットフォームの構成 client database GraphQL Gateway GraphQL

    API ・ ・ ・ GraphQL Gateway バックエンドデータ配信API 2段構成 • 統一された共通エンドポイントをクライアントに提供するGraphQL Gateway • 各プロジェクトごとに用意するバックエンドデータ配信API
  9. 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
  10. 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の製品群が 素早く、秩序を持って、柔軟に、安全にデータを取得できる環境を提供する
  11. 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
  12. 23 2024年こそ使いこなす!GraphQL最前線 バックエンドデータ配信APIの技術選定 AWS AppSync • マネジメントコンソールにGraphQL API開発に必要なものが一通り揃っている • 「DynamoDBからレコードを取得するだけ」など単純なデータ配信APIの案件は

    AppSyncが用意しているリゾルバテンプレートを選ぶだけで実現可能 → クライアント開発者にAppSyncの開発・運用をお任せできる! 要件すり合わせのオーバヘッドがなくなり効率化
  13. 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
  14. 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/
  15. 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がまだ存在せず、 別の手段を考える必要があった
  16. 28 2024年こそ使いこなす!GraphQL最前線 GraphQL Gatewayの技術選定―データソースを束ねる GraphQL Mesh • The Guild(OSS開発者のグループ)によるGraphQL Gatewayフレームワーク

    • GraphQL API, REST APIをはじめとする、あらゆるデータソースを束ねる機能をもつ 画像: https://the-guild.dev/graphql/mesh
  17. 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
  18. 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
  19. 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 アクセス制御
  20. 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
  21. 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"}}]} メトリクス監視
  22. 38 2024年こそ使いこなす!GraphQL最前線 開発・運用上の問題点 • GraphQL Meshがまだv0なので不安定 • 仕方のないことだが破壊的変更が入るときは入ってしまう • 既存コードや連携部分が動かなくなることもあるのでバージョン上げ作業は根気が必要

    • 一方でバージョン上げするだけで性能向上することもあるので一概に悪者ではない • 幸いサービスインしてからは仕様変更せざるを得ないような破壊的変更がないのでなんとかなっている • 2023.05にv1.0.0-alphaリリースされたが、残念ながらv1はまだ遠そうな予感… • ちなみに… • Apollo Serverは2023.10.22にv2/v3のEOLを迎えたが、v4移行ガイドが丁寧に 用意されていたのでとてもスムーズに移行できた • よく言われることではあるが、保守していく上では成熟したプロジェクトを選定することも重要だと再認識
  23. 39 2024年こそ使いこなす!GraphQL最前線 開発・運用上の問題点 • (GraphQL関係ないですが)AWS App Runnerの扱いが意外と難しい • インフラをなるべくメンテナンスせずに運用したくて選定したはいいけど割と新しいサービスなので •

    不具合時のプラクティスが不十分だったり • 痒い所に手が届かなかったり • … • 2/21(水)に「App Runner」をテーマとする勉強会の開催を予定しているので、 詳しくはそちらでお話しします!