マイクロサービスアーキテクチャの外部 API 統合パターン

今日は API 統合について話します。前の 2 日間の理解により、マイクロサービスはマルチサービスで疎結合されたサービスセットであることがわかりました。マルチサービスが関与するため、外部 API を呼び出すことが不可欠です。

顧客の多様性により、アプリケーションの外部 API の設計はより困難になります。これらのクライアントは多くの場合、異なるデータ要件を持っています。

1. 直接コミュニケーション

このように、API はクライアントがサービスを直接呼び出すように設計されています。現在、マイクロサービスアーキテクチャでは、次のような欠点があるため、このアプローチが採用されることはほとんどありません。

クライアントは、必要なデータを取得するために、きめ細かいサービス API を通じて複数のリクエストを行う必要がありますが、これは非効率であるだけでなく、ユーザーエクスペリエンスの低下につながる可能性があります。
各サービスとその API に関するクライアントの知識によってカプセル化が欠如しているため、スキーマと API の変更は困難です。
クライアントは、サービスの IPC メカニズムを使用することが便利でも実用的でもないと感じるかもしれません。

開発の際、下位互換性の維持をバックエンドサービスの開発者に任せることはできません。サービスをサードパーティに直接公開するのではなく、別のパブリック API を開発する必要があります。

この大変な作業は、API Gateway のアーキテクチャコンポーネントによって実行されます。

2. APIゲートウェイモード

サービスに直接アクセスすることには多くの欠点があります。API Gateway は、より優れたサービスアクセスパターンです。

基本的に、API ゲートウェイは、外部アプリケーションのエントリポイントとして機能するサービスでもあります。このコンポーネントは、リクエストのルーティング、API の構成、および認証、監視、レート制限などのその他の横断的な問題を担当します。API GatewayはOOPSにおけるファサードデザインパターン（デザインパターン）に似ています。API ゲートウェイは、アプリケーションの内部アーキテクチャをカプセル化し、クライアントに API を提供します。

API ゲートウェイは、リクエストのルーティング、API の構成、およびプロトコルの変換も行います。外部クライアントからの API リクエストは API ゲートウェイを経由し、API ゲートウェイは一部のリクエストを対応するサービスにルーティングします。API Gateway は、複数のサービスを呼び出して結果を集約することで、他のリクエストを処理することもできます。サーバーは、HTTP や WebSocket などのクライアントに適したプロトコルと、サービスで使用されるクライアントに不向きなプロトコルとの間で変換することもできます。

3. リクエストルーティング

リクエストのルーティングは、API ゲートウェイの最も重要な機能の 1 つです。API ゲートウェイは、リクエストを適切なサービスにルーティングすることで API オペレーションを実装します。API Gateway はリクエストを受信すると、ルートマップにクエリを実行して、リクエストをルーティングするサービスを決定します。たとえば、ルートマップは、HTTP メソッドとパスをサービスの HTTP URL にマッピングする場合があります。NGINX などの Web サーバーは、この機能の一部としてリバースプロキシを提供します。

4. API構成

API ゲートウェイは通常、リバースプロキシ以上の役割を果たします。API 合成を使用して API 操作を実行することもできます。API ゲートウェイは、クライアントに 1 回のリクエストで必要なデータを取得できる粗粒度の API を提供します。

Aggregator/Composite パターンには 2 つのサブパターンがあります。

連鎖パターン: 基本的に、このタイプの複合パターンは連鎖構造に従います。このパターンでは、クライアントはサービスと通信し、すべてのサービスが連鎖し、1 つのサービスの出力が次のサービスの入力になります。
フォークパターン: フォークパターンは、アグリゲーターとチェーンパターンの拡張バージョンです。クライアントはサービスと直接通信でき、この設計パターンでは、サービスは同時に複数のサービスと通信できます。

5. プロトコル変換

API Gateway はプロトコルを変換することもできます。アプリケーションサービスは内部で REST や gRPC などのさまざまなプロトコルを使用しますが、REST API を外部クライアントに公開する場合があります。一部の API 操作は、必要に応じて RESTful 外部 API と内部 gRPC ベース API の間で変換を行います。

一部の外国の技術 Web サイトでは、この機能を直接「プロトコル変換」と呼んでいます。直訳は「プロトコル変換」です。私は直接「能力に応じたプロトコル変換」と呼んでいます。

6. フロントエンドモデルのバックエンド

API ゲートウェイは共通の API を提供できます。単一の API に関する問題の 1 つは、クライアントごとに異なるニーズがあることが多いことです。この問題の解決策は、GraphQL と同様に、サーバーが返すフィールドと関連オブジェクトをリクエストで指定するオプションをクライアントに与えることです。サードパーティアプリケーションにサービスを提供する必要があるパブリック API の場合は、このアプローチで十分ですが、これ以上のオプションの操作を顧客に提供することはできません。

APIゲートウェイを介してクライアントにパーソナライズされたAPIを提供するのは良い選択であり、通信データのプレッシャーをある程度軽減できるこの機能も気に入っています。

7. 横断的な懸念事項を実装する

API ゲートウェイは主に API のルーティングと構成を処理しますが、横断的な問題も処理する場合があります。横断的な懸念事項の例は次のとおりです。

認証 : リクエストを行っているクライアントの身元を確認します。
Authorization : クライアントがその特定のアクションを実行する権限を持っていることを確認します。
レート制限: 特定のクライアントまたはすべてのクライアントからの 1 秒あたりのリクエスト数を制限します。
キャッシュ: 応答をキャッシュして、サービスへのリクエストの数を減らします。
メトリクスの収集: API 使用状況のメトリクスは、請求分析の目的で収集されます。
リクエストのログ: リクエストをログに記録します。

注: 横断的な懸念事項とは、複数のモジュールにまたがる動作を持ついくつかの特別な懸念事項を指し、従来のソフトウェア開発方法では効果的なモジュール化を実現できません。たとえば、典型的なケースでは、ログ関数

8. APIゲートウェイのアーキテクチャ

API Gateway には、階層化されたモジュラーアーキテクチャがあります。API 層とパブリック層の 2 つの層で構成されます。1 つ以上の API モジュールが API レイヤーを構成します。API モジュールは、顧客の要件に応じて API を実装します。

ここに画像の説明を挿入

9. APIゲートウェイのメリット

API ゲートウェイを使用する主な利点は、アプリケーションの内部構造がカプセル化されることです。
API ゲートウェイはクライアントにクライアント固有の API を提供し、クライアントとアプリケーション間の往復回数を削減します。
簡素化されたクライアントコード。

10. APIゲートウェイのデメリット

メンテナンスコストの追加も、開発、展開、管理が可能な可用性の高いコンポーネントです。
開発者はサービス API を公開するために API ゲートウェイを随時更新する必要があるため、API ゲートウェイが開発のボトルネックになる可能性があります。

11. 既製の API ゲートウェイ

API ゲートウェイ機能を実装する既製のサービスと製品がいくつかあります。

AWS API Gateway : AWS API Gateway API は REST リソースのセットであり、それぞれが 1 つ以上の HTTP メソッドをサポートします。すべてのリクエストをバックエンドサービスにルーティングするように API Gateway を構成できます。バックエンドサービスに API 合成を実装する必要があります。AWS API Gateway は API 合成をサポートしていません。

Kong : Kongは NGINX HTTP サーバーに基づいており、HTTP メソッド、ヘッダー、およびパスに基づいて柔軟なルーティングルールを定義し、使用するバックエンドサービスを決定できます。

12. APIゲートウェイの開発

Web フレームワークを使用すると、リクエストを他のサービスにプロキシする独自の API ゲートウェイを構築できます。Netflix Zuul と Spring Cloud Gateway を見てみましょう。

Netflix Zuul : Zuul は、ルーティング、レート制限、認証などの横断的な機能を実装する Netflix フレームワークです。Zuul は、サーブレットフィルターに似た再利用可能なリクエストインターセプターであるフィルターの概念を使用します。Zuul は、リクエストを変換し、バックエンドサービスを呼び出し、クライアントに送信する前に応答を変換する一連のフィルターを組み立てることによって HTTP リクエストを処理します。

Spring Cloud Gateway : Spring Cloud Gateway は、 Spring Framework、Spring Boot、およびリアクティブ Web フレームワークである Spring Webflux に基づく API ゲートウェイフレームワークです。

Spring Cloud Gateway は、以下を行うためのシンプルかつ包括的な方法を提供します。 

リクエストをバックエンドサービスにルーティングします。
API 合成を実行するリクエストハンドラーを実装します。
認証などの横断的な問題に対処します。