Apollo Federationが『マイクロサービスGraphQL』を可能にする
Apollo Federationは複数のGraphQLサービス（Subgraph）を1つの統合スキーマ（Supergraph）として束ねるフレームワークで、Netflix・Expedia・GitHub・MoneyForward等の本番運用例が公開されています。マイクロサービス境界を越えた型安全な統合を実現し、フロントエンドからは『単一のGraphQLエンドポイント』に見えながら、バックエンドでは独立した各サービスが分散実装される、という設計を可能にします。
採用すべき5つのシグナル
- マイクロサービスが10サービス以上に分散している
- フロント側からの統合API設計に手間がかかっている
- サービス間でデータ参照（リレーション）が複雑
- BFF（Backend for Frontend）が肥大化
- 各サービスの独立リリース・チーム自律性を維持したい
BFF vs API Gateway vs Federation比較
BFF: フロント別にバックエンド集約層を設計・型安全管理が課題。
API Gateway: REST集約・ルーティング中心・型統合は弱い。
Federation: GraphQLレベルでスキーマ統合・型完全・サービス自律性維持。学習コスト高。
使い分け: シンプル統合はBFF・REST集約はGateway・大規模型安全統合はFederation。
Federation 2の重要な進化
- Composition: スキーマ統合がツールで自動化（GraphOS Studio）
- Shared Types: 複数Subgraphでの共通型をシームレスに扱える
- Entity Interface: インタフェースをSubgraph間で実装可能
- Migration Path: Federation 1からの段階移行サポート
実装の基本パターン
(1) Subgraph実装: 各マイクロサービスでGraphQLサーバ + Federationディレクティブ
(2) Entity定義: type Product @key(fields: 'id') { id: ID! name: String! }
(3) Router構成: Apollo Routerが各Subgraphにクエリ分散
(4) GraphOS Studio: スキーマレジストリ・CIで継続的Composition
(5) 監視: Apollo Studioで各Subgraphの性能・エラー監視
本番運用の3つのチェックポイント
- Subgraph境界設計: マイクロサービス境界とGraphQL境界の整合性が重要
- パフォーマンス: N+1問題対策・DataLoader実装・Apollo Router最適化
- スキーマ進化: Subgraph独立進化と統合スキーマ整合性の両立
料金感（実務目安）
- GraphOS Free: スキーマレジストリ無料・小規模本番OK
- GraphOS Enterprise: $20,000/年〜・大規模運用・SLA付き
- Self-hosted: Apollo RouterはOSS・GraphOSなしでも運用可能
採用判断の境界
Federationは強力だが学習コストと運用負荷が高いため、以下のシグナルがある場合は採用しない方が良い:
(1) マイクロサービスが5サービス以下
(2) GraphQL経験者がチームに少ない
(3) フロント・バック両方でモノレポ採用・tRPC等で十分
(4) 統合エンドポイントの設計をBFFで吸収可能
(5) 既存REST APIで運用に支障がない
30日学習プラン
- 1週目: Federation基礎・2サービス間のEntity共有実装
- 2週目: Apollo Router・Composition・GraphOS Studio連携
- 3週目: N+1問題対策・DataLoader・性能最適化
- 4週目: 本番デプロイ・モニタリング・スキーマ進化
関連リンク
GraphQL基礎は GraphQL実践、マイクロサービスは マイクロサービス実践、APIゲートウェイ設計は APIゲートウェイ設計 を参照してください。tRPCとの比較は tRPC深掘り もどうぞ。