API ゲートウェイパターン

API ゲートウェイパターンは、複数のクライアントアプリケーションを含む複雑または大規模なマイクロサービスベースのアプリケーションを設計および構築する場合に推奨されます。このパターンはオブジェクト指向設計のファサードパターンに似ていますが、分散システムのリバースプロキシまたはゲートウェイルーティングの一部であり、同期通信モデルを使用しています。

このパターンは、リクエストを内部のマイクロサービスエンドポイントにリダイレクトまたはルーティングするリバースプロキシを提供します。API ゲートウェイは、クライアントアプリケーションに単一のエンドポイントまたは URL を提供し、リクエストを内部マイクロサービスに内部的にマッピングします。抽象化のレイヤーは、特定の実装の詳細 (例えば、Lambda 関数の名前やバージョン) を隠すことによって提供され、レスポンスやリクエストの変換、エンドポイントアクセスの承認、またはトレースなどの追加機能をバックエンドサービスの上に追加することもできます。

以下の場合は、API ゲートウェイパターンの使用を検討してください。

• マイクロサービスの依存関係の数は管理可能であり、時間とともに増加することはありません。

• 呼び出し元システムは、マイクロサービスからの同期応答を必要とします。

• 低レイテンシーの要件があります。

• 複数のマイクロサービスからデータを収集するには、1 つの API を公開する必要があります。

ユースケース

このユースケースでは、Lambda関数としてデプロイされた 4 つのマイクロサービス (「Customer」、「Communication」、「Payments」、「Sales」) で構成される保険システムで、カスタマーが毎月定期的な支払いを行っています。「Customer」マイクロサービスはカスタマーデータベースを毎月の支払いの詳細で更新します。「Sales」マイクロサービスは、セールスチームがクロスセルの機会についてカスタマーをフォローアップするのに役立つ関連情報で売上データベースを更新します。「Communication」マイクロサービスは、支払いが正常に処理された後に確認メールをカスタマーに送信します。最後に、「Payments」マイクロサービスは、カスタマーが毎月の支払いを行うために使用するシステム全体です。このパターンでは、ウェブサービスを使用して「Customer」、「Sales」、「Communication」の各サブシステムを「Payments」マイクロサービスと統合します。

このパターンをこのユースケースに使用することには、3 つの課題があります。

• 同期呼び出しはダウンストリームのシステムに対して行われます。つまり、これらのサブシステムによって発生するレイテンシーは、全体の応答時間に影響します。

• 「Payments」システムは、呼び出し側のシステムに応答する前に他のマイクロサービスからの応答を待っているため、ランニングコストが高くなります。そのため、非同期システムに比べて総実行時間は相対的に長くなります。

• エラー処理と再試行は、個々のマイクロサービスではなく、「Payments」システム内のマイクロサービスごとに個別に処理されます。

次の 2 つの例は、API ゲートウェイパターンを使用して複数の API ゲートウェイまたは 1 つの API ゲートウェイを使用してマイクロサービスを統合する方法の概要を示しています。

複数の API ゲートウェイ

以下の図では、各マイクロサービスには独自の API ゲートウェイがあります。「Payments」マイクロサービスは個々のシステムを呼び出して API ゲートウェイパターンを実装します。

単一 API ゲートウェイ

以下の図では、各マイクロサービスは Lambda 関数としてデプロイされていますが、すべてのマイクロサービスは同じ API ゲートウェイで接続されています。