API Gateway デプロイメントパターン
December 16, 2022
APIは、アプリケーションの構築方法や組織内外でのデータ公開方法を変えています。また、APIの成功はその整合性、可用性、パフォーマンスに依存します。Apache APISIXのようなAPI Gatewayを使用することで、これらの成功指標を達成できます。
API Gatewayのデプロイメントに関しては、4つのよく知られたパターンがあります: 中央集権型エッジゲートウェイ、2層ゲートウェイ、マイクロゲートウェイ、サイドカー。この記事では、これらのパターンについて説明し、ビジネスに適したAPI Gatewayデプロイメントパターンを選択するためのアイデアを提供します。
API Gatewayとは何か？
API Gatewayは、システムのエッジに位置し、消費者とバックエンドサービスの集合の間に存在する管理ツールであり、定義されたAPIグループの単一のエントリーポイントとして機能します。消費者は、エンドユーザーアプリケーションやデバイス（シングルページのウェブアプリケーションやモバイルアプリなど）、別の内部システム、またはサードパーティのアプリケーションやシステムである可能性があります。
API Gatewayデプロイメントのコンポーネント
API Gatewayは、2つの高レベルの基本コンポーネントで実装されます: コントロールプレーンとデータプレーン。これらのコンポーネントは通常、一緒にパッケージ化されるか、別々にデプロイされます。コントロールプレーンは、オペレーターがゲートウェイと対話し、ルート、ポリシー、必要なテレメトリを定義する場所です。データプレーンは、コントロールプレーンで指定されたすべての作業が行われる場所で、ネットワークパケットがルーティングされ、ポリシーが適用され、テレメトリが発行されます。 例えば、APISIXには、異なるプロダクション使用ケースに対応する3つの異なるデプロイメントモード（従来型、分離型、スタンドアロン型）があります。
中央集権型エッジゲートウェイ
API Gatewayは通常、システムのエッジにデプロイされますが、この場合の「システム」の定義は非常に柔軟です。スタートアップや多くの中小企業では、API Gatewayはデータセンターやクラウドのエッジにデプロイされることがよくあります。これらの状況では、単一のAPI Gateway（高可用性のために複数のインスタンスでデプロイおよび実行される）が、バックエンド全体のフロントドアとして機能し、API Gatewayがすべてのエッジ機能を提供します。
API Gatewayは、_ユーザー認証、認可、リクエストレート制限、キャッシング、タイムアウト/リトライ、リクエスト/レスポンス変換、メトリクス、ログ、トレースデータの提供_など、システム内でのオブザーバビリティの実装をサポートするための横断的な要件を提供します。
また、多くのAPI Gatewayは、APIのライフサイクルを管理するための追加機能を提供し、APIを使用する開発者のオンボーディングと管理（開発者ポータルや関連するアカウント管理およびアクセス制御の提供など）を支援し、エンタープライズガバナンスを提供します。
2層ゲートウェイ
大規模な組織や企業では、API Gatewayは通常、複数の場所にデプロイされます。多くの場合、データセンターの境界での初期エッジスタックの一部としてデプロイされ、追加のゲートウェイが各製品、事業部門、または組織部門の一部としてデプロイされることがあります。この文脈では、これらのゲートウェイは通常、別々の実装であり、地理的な場所（必要なガバナンス）やインフラストラクチャの能力（低電力のエッジコンピュートリソースで実行される）に応じて異なる機能を提供する場合があります。
以下の図は、Apache APISIX API Gatewayが、パブリックインターネットとプライベートネットワークの非武装地帯（DMZ）の間に位置する様子を示しています。
マイクロゲートウェイ
マイクロゲートウェイは、マイクロサービス間の内部通信のために完全に設計されています。個々のマイクロゲートウェイは、異なるポリシーやセキュリティルールを持ち、複数のサービスからの監視とメトリクスの集約を必要とする場合があります。
このコンセプトは、マイクロサービスを管理する個々のチームに、サービスを安全に公開する方法を制御するための機能（専用ゲートウェイ）を提供することです。同じ開発者チームがマイクロサービスとマイクロゲートウェイを管理および維持するため、バグの修正、更新の提供、改善を独立して行い、他の依存関係とのやり取りを少なくして変更を迅速に本番環境にプッシュし、デプロイメント内の他のアプリケーションに影響を与えずに済みます。
サイドカーAPI Gateway
サイドカーは、Kubernetesなどの独立したランタイムでサービスに接続されたコンテナとしてAPI Gatewayを実装します。サイドカーは、オートバイに取り付けられたサイドカーに対応するパターンであり、同様に親アプリケーション（サービスメッシュと呼ばれるソフトウェアコンポーネント）に接続され、アプリケーションのサポート機能を提供します。サイドカーは親アプリケーションと同じライフサイクルを共有し、親と共に作成および廃棄され、監視、ロギング、設定、ネットワーキングサービスなどの追加機能を導入します。
このパターンを採用する利点は、各サービスのランタイムが独自のAPI Gatewayを最適な方法で設定できることです。API Gatewayの機能と設定を有効にする要件は、サービスごとに異なる場合があるためです。同時に、共有のAPI Gatewayインフラストラクチャで問題が発生した場合、すべてのサービスが影響を受けないように懸念を分離します。例えば、Ameshは、Apache APISIXに基づく別のサービスメッシュソリューションです。
前述の図は、各サービスエンドポイントへのAPIロードバランサーおよびリソースルーターとして機能するイングレスを示しています。サービスのエントリーポイントはサービスエンドポイント自体ではなく、サイドカーAPI Gatewayです。サイドカーは、サービスエンドポイントへのトラフィックをルーティングするだけでなく、API Gatewayが提供する機能のいずれかを実行できます。
結論
私たちが理解しているように、すべての条件に適した単一のデプロイメントパターンはありません。時には、システム内で1つまたは複数のゲートウェイを使用することができます。デプロイメントの選択は、ビジネスの複雑さとニーズに依存します。どのデプロイメントパターンが最適かを決定するのに助けが必要な場合は、私たちのコミュニティSlackチャンネルに参加し、専門家が決定を支援します。
関連リソース
➔ API Gatewayとは何か、そしてクラウドネイティブ時代になぜ不可欠なのか？.
推奨コンテンツ
➔ ブログ記事を読む: