API Gateway
API Gawewayという言葉をよく目にするようになった。
アーキテクチャ議論でよく出てくるのでなにを指しているのか理解しておきたい。
API Gatewayなしの場合
API Gatewayありの場合
- クライアントは「発注」という処理のためにAPI Gatewayを一度呼び出す
- API Gatewayは「発注」処理に必要な複数のサービスを呼び出してクライアントに応答を返す
- サービスがREST API以外のAPIを公開していてもAPI Gatewayが吸収する
- TLS、認証/認可、Logging/分散TracingなどCross Cutting ConcernはAPI Gatwayが実装している
メリット
- クライアントの実装がシンプルになる
- サービスの横断的関心事をAPI Gatewayに実装することでサービス開発者はビジネスロジックに集中できる
- 既存のSOAPなどを使用するサービスを再利用できる
- クライアントと各サービスが疎結合になる
デメリット
API Gatewayが提供する機能
- Proxy機能
- Mediator機能
- API変換
- 認証/認可
- TLS
- Request Rate Limiting
- Retry/Circuit Breaker
- Loadbalancing
- Logging/Distributed Tracing(correlation)
- Whitelisting IP address
Use Case
- 既存のサービスと簡易なUIを組み合わせて新しい機能を提供する
- MonolithicアプリケーションをAPI Gatewayの背後で隠蔽してマイクロサービスに分割する
- Version混在、マイグレ、A/Bテスト、Canary Deployment
- Microservice Architectural PatternにおけるAPI Gatewayパターン
API Gatewayパターン
実装例
サービスメッシュとの違い
複数のサービス間の横断的な技術的課題を解決するソリューションとして他にサービスメッシュがある。
サービスメッシュとAPI Gatewayが解決する課題は一部重複しているが基本的には異なるものだ。
- サービスメッシュはサービス間のEast/Westトラフィックを主に制御する。
- API GatewayはNorth/South Trafficを制御する。
- サービスメッシュはLayer3、Layer4の低次元な課題解決を行う。
- API Gatewayは低次元な課題に加えてLayer7を含む高次元な課題解決ができる。
サービスメッシュについてはこちらの記事を参照して欲しい。