API Gateway

API Gawewayという言葉をよく目にするようになった。

アーキテクチャ議論でよく出てくるのでなにを指しているのか理解しておきたい。

API Gatewayなしの場合

• クライアントは「発注」という処理のために複数のサービスをREST APIで呼び出す
• 各サービスはTLS、認証/認可、Logging/分散Tracingなどを個別に実装している

---

API Gatewayありの場合

• クライアントは「発注」という処理のためにAPI Gatewayを一度呼び出す
• API Gatewayは「発注」処理に必要な複数のサービスを呼び出してクライアントに応答を返す
• サービスがREST API以外のAPIを公開していてもAPI Gatewayが吸収する
• TLS、認証/認可、Logging/分散TracingなどCross Cutting ConcernはAPI Gatwayが実装している

---

メリット

• クライアントの実装がシンプルになる
• サービスの横断的関心事をAPI Gatewayに実装することでサービス開発者はビジネスロジックに集中できる
• 既存のSOAPなどを使用するサービスを再利用できる
• クライアントと各サービスが疎結合になる

---

デメリット

• API GatewayがSingle point of failureになる
• SOAのESB同様、API Gatewayに縛られる

---

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を利用するパターンのこと。
• 特定のマイクロサービス グループに対して単一のエントリ ポイントを提供する。

---

実装例

• Kong(OSS)
• Ambassador(OSS)
• Ocelot(C#)
• Azure API Management
• Amazon API Gateway
• Google Cloud Endpoints

---

サービスメッシュとの違い

複数のサービス間の横断的な技術的課題を解決するソリューションとして他にサービスメッシュがある。

サービスメッシュとAPI Gatewayが解決する課題は一部重複しているが基本的には異なるものだ。

• サービスメッシュはサービス間のEast/Westトラフィックを主に制御する。
• API GatewayはNorth/South Trafficを制御する。
• サービスメッシュはLayer3、Layer4の低次元な課題解決を行う。
• API Gatewayは低次元な課題に加えてLayer7を含む高次元な課題解決ができる。

サービスメッシュについてはこちらの記事を参照して欲しい。

architecting.hateblo.jp