翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
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 ゲートウェイで接続されています。
