AWS AppSync Merged API でマイクロサービスの GraphQL を統合 - チーム分散開発の実践
複数チームが独立して開発・デプロイする GraphQL API を単一エンドポイントに統合する。スキーマ競合の回避策と認証戦略の設計を紹介します。
Merged API の必要性
マイクロサービスアーキテクチャで複数チームが GraphQL API を開発する場合、フロントエンドは複数のエンドポイントにリクエストを送る必要があり、クライアント側の複雑さが増します。Merged API はこの問題を解決し、複数のソース API を単一のエンドポイントに統合します。ユーザーチームの User API、注文チームの Order API、商品チームの Product API をそれぞれ独立して開発・デプロイしつつ、フロントエンドからは 1 つの GraphQL エンドポイントでアクセスできます。API Gateway のような REST ベースの API 集約と異なり、GraphQL のスキーマレベルで統合されるため、クロスサービスのクエリも単一のリクエストで実行できます。
ソース API の設計と独立デプロイ
各チームはソース API として独立した AppSync API を開発します。スキーマ、リゾルバー、データソースはソース API ごとに管理され、チームは自分の API を自由にデプロイ・更新できます。ソース API の更新は自動的に Merged API に反映されます。スキーマの競合 (同名の Query フィールド、同名の型定義) はマージ時に検出され、エラーとして報告されます。競合を避けるため、チーム間でスキーマの命名規則を事前に合意し、名前空間的なプレフィックス (user_、order_) を使用するか、共通の型定義を共有スキーマとして管理する設計が推奨されます。
認証戦略
Merged API レベルでデフォルトの認証方式 (Cognito ユーザープール、 IAM 、 API キー、 Lambda オーソライザー) を設定します。ソース API ごとに追加の認証方式を設定でき、特定のフィールドに対してソース API の認証を適用できます。例えば、 Merged API のデフォルト認証を Cognito に設定しつつ、管理者向けの Mutation にはソース API レベルで IAM 認証を追加する構成が可能です。@aws_auth ディレクティブでフィールドレベルの認証を制御し、特定のフィールドを特定の Cognito グループのみに公開できます。 マイクロサービスに関する詳しい解説はAmazon の関連書籍でも確認できます。
Merged API の料金と制約
Merged API の料金は通常の AppSync API と同じで、クエリ・ミューテーションは 100 万リクエストあたり約 4.00 ドルです。Merged API 自体に追加料金は発生しませんが、ソース API の数に上限 (デフォルト 10) があり、大規模なマイクロサービス環境では上限緩和の申請が必要です。ソース API のリゾルバーが Lambda を呼び出す場合、Lambda の料金はソース API のアカウントに課金されます。Merged API のキャッシュを有効にすると、ソース API をまたいだクエリ結果がキャッシュされ、バックエンドの呼び出し回数を削減できます。
まとめ
AppSync Merged API は複数チームの GraphQL API を単一エンドポイントに統合するサービスです。各チームの独立したデプロイを維持しつつ、フロントエンドにはシンプルな単一エンドポイントを提供します。マイクロサービスアーキテクチャで GraphQL を採用する場合の標準的なパターンです。