API Gatewayが気になって勉強してみた。 Microsoftのドキュメントがめっちゃわかりやすかったのでメモ。
API Gatewayとは？
API Gatewayパターンで設置されるAPIのエントリーポイントを提供するゲートウェイ
API Gatewayパターンとは？
マイクロサービスアーキテクチャを採用していることが前提となる
マイクロサービスでは、各マイクロサービスがパブリックエンドポイントを公開して、クライアントがそのパブリックエンドポイントに対してアクセスしてデータのやり取りを行う
やり取りの方法として2通りある
- クライアントからマイクロサービスへの直接通信
- API GatewayパターンによるAPIゲートウェイを介した通信
- シングルAPIゲートウェイ
- マルチAPIゲートウェイ / BFF(Backend for Frontend)
クライアントからマイクロサービスへの直接通信
小規模なマイクロサービスのアプリケーションでは特に直接通信でも問題ない
大規模で複雑なアプリケーションになる場合は幾つかの問題にぶち当たる
- バックエンドへの要求を最小化したい
- セキュリティ/データ変換/動的なディスパッチなどの横断的な問題への対応
- 非インターネット対応プロトコルを使用するサービスとの通信
- モバイルアプリ専用のファサードの形成
API GatewayパターンによるAPIゲートウェイを介した通信
マイクロサービスベースのアプリケーションでは、APIゲートウェイ（中間レイヤ）を導入すると便利
以下のような問題を解消できる
-
密結合
直接通信の場合、クライアントアプリはマイクロサービスと結合する。
マイクロサービスのリファクタリングや改修に対してダイレクトに影響を受ける。 -
膨大な数のラウンドトリップ
クライアントの1画面のUIを構築するために、複数のマイクロサービスを何回も呼び出す必要がある場合に、複数のネットワークラウンドトリップが発生してしまい、ユーザーの待機時間が大幅に長くなる。ユーザーエクスペリエンスの低下。 -
セキュリティの問題
APIゲートウェイがない場合、すべてのマイクロサービスのエンドポイントが公開されているため、攻撃される部分が大きくなってしまう。 -
横断的な問題
パブリックに公開される各マイクロサービスは、認可やSSLなどの問題を処理する必要が出てくる。
APIゲートウェイは、クライアントアプリとマイクロサービスの間に位置する。
リバースプロキシとして機能して、クライアントからサービスへと要求をルーティングする。また、認証、SSL終端、キャッシュなどの横断的な機能も提供できる。
SSL終端（Termination）は、HTTPSトラフィックの処理を特定のポイント（ここではAPI Gateway）で集中させることができる。サーバーなどは、通常のHTTPトラフィックを扱うだけで済む。
シングルAPIゲートウェイ
クライアントアプリは、1つのエンドポイント（APIゲートウェイ）に接続する。
ブラウザやモバイルアプリ、MVCフレームワーク等様々なクライアントアプリから接続される場合は注意が必要。
クライアントアプリからの多種多様な要件が発生して、APIゲートウェイが複雑化・肥大化して、モノリシックに似た状態になる場合がある。
APIゲートウェイを何らかの単位で複数のより小さいAPIゲートウェイに分割することが推奨されている。
全ての内部マイクロサービスに対する単一のアグリゲーターとして機能させないように設計していく必要がある。
分割の例として、クライアントアプリの種類に対してAPIゲートウェイを用意すること。（モバイルアプリ用、Webクライアント用など）
もう少し大規模になってくると、クライアントアプリの種類だけでなくビジネス境界に基づいてAPIゲートウェイを設置することが必要になってくる。
APIゲートウェイの主な機能
リバースプロキシ / ゲートウェイルーティング
マイクロサービスのエンドポイントにリクエストをリダイレクト / ルーティングするためのリバースプロキシを提供する。（L7ルーティング）
APIゲートウェイはクライアントアプリように１つのエンドポイントまたはURLを提供して、内部マイクロサービスのグループに内部的にマッピングする。
ルーティング機能は、クライアントアプリとマイクロサービスの分離だけでなく、モノリシックAPIとクライアントアプリの間にAPIゲートウェイを設置して、モノリシックAPIを刷新するときにも便利。マイクロサービスに分割されるまでの間従来のモノリシックAPIを使用しながら、新しいAPIを新しいマイクロサービスとして追加できる。
APIゲートウェイがあるため、クライアントアプリはモノリシックAPIなのかマイクロサービスAPIなのかを知る必要がなくなる。モノリシックAPIからマイクロサービスAPIにリファクタリングする場合も、APIゲートウェイのルーティングによってクライアントアプリはURI変更の影響を受けない。
リクエストの集約
複数のマイクロサービスに対する複数のリクエストを１つのリクエストに集約することができる。特にクライアントアプリのUIが複数のマイクロサービスからの情報を必要とする場合に効果が大きい。
この方法では、クライアントアプリがAPIゲートウェイに1つのリクエストを送信する。APIゲートウェイはマイクロサービスに複数のリクエストをディスパッチして、返ってきたレスポンスを集約して、クライアントアプリに送り返す。この設計により、頻繫な通信を減らすことができる。SPAやモバイルアプリにおいては、非常に重要。MVCアプリではあまり重要ではない。
共通機能のオフロード（委譲）
認証・認可、キャッシュ、リトライポリシー、サーキットブレーカー、レート制限、負荷分散、ロギング、ヘッダー、クレーム変換、IP制限（許可リスト）
上記のような機能をAPIゲートウェイにオフロードできる。
オフロードにより、共通の問題を１つの層にまとめることができ、各マイクロサービスを単純化することができる。
APIゲートウェイの欠点
- 単一障害点が増える可能性
- APIゲートウェイを介すためネットワーク呼び出しの応答が増加する可能性
- 正しくスケールアウトされていない場合、APIゲートウェイがボトルネックになる可能性
- メンテナンスの作業量が増える
- マイクロサービスが新しいエンドポイントを公開する場合、APIゲートウェイを更新が発生
- APIゲートウェイをコードで実装している場合コードの改修が発生
- APIゲートウェイが単一チームで開発される場合、開発のボトルネックになる可能性