APIゲートウェイ対サービスメッシュ

ユースケースを見ると，APIゲートウェイとサービスメッシュの間に重複する領域があり，それがサービスコネクティビティユースケースであることが分かります。

サービスメッシュが提供するサービスコネクティビティ機能は，APIゲートウェイが提供するAPIコネクティビティ機能と競合しています。しかし，サービスメッシュにより提供される機能はより包括的（L4+L7，すべてのTCPトラフィック，HTTPやAPIだけでなくすべてのサービス）であるため，ある意味，より完全です。しかし，上の図から分かるように，サービスメッシュで提供されないユースケースもあります。「⁠製品としてのAPI」ユースケースとフルライフサイクルAPI管理はAPIゲートウェイパターンに属しています。

サービスメッシュは広範なユースケース（L4+L7）のサービスコネクティビティ要件をすべて提供するため，APIゲートウェイ（L7のみ）の事項を引き継ぐと考えるのは当然です。この結論はサービスメッシュデプロイモデルを利用できる場合にのみ当てはまるものです。これから説明するように，常にそうとは限りません。

2つのパターン間の重要な相違点はデプロイモデルです。サービスメッシュパターンでは，プロキシデータプレーンをすべてのサービスのすべてのレプリカとともにデプロイする必要があります。チームが独自の製品または事業部門の範囲内でサービスメッシュをデプロイする場合は特に問題ありませんが，範囲外にプロキシをデプロイする場合は次の理由により実装が難しくなります。

1. 異なる製品，チーム，事業部門でソフトウェアの構築，実行およびデプロイの方法が根本的に異なる場合，プロキシアプリケーションを組織内のすべての製品のすべてのサービスとともにデプロイしようとすると反対されることがあります。
2. すべてのデータプレーンプロキシはコントロールプレーンとの接続を開始する必要がありますが，組織の製品，チームまたは事業部門の境界の外部にデプロイされたサービスからコントロールプレーンへのアクセスが許可されない場合やアクセスができない場合もあります。
3. 組織の外部の開発者，顧客またはパートナーにより構築されたサードパーティアプリケーションの場合，すべてのサービスをコントロールできないため，データプレーンプロキシをすべてのサービスとともにデプロイすることは不可能です。
4. 同じサービスメッシュでデプロイされたサービスは，互いに利用する有効なTLS証明書を提供するために同じCA（認証局）を使用する必要がありますが，異なる製品やチームに属するサービス間でのCAの共有は不可能な場合や望ましくない場合があります。この場合は，中間のAPIゲートウェイ経由で互いに通信できる2つの（それぞれ独自のCAを使用する）サービスメッシュを作成します。

APIゲートウェイとサービスメッシュはさまざまなユースケースに焦点を当てています。ほとんどの組織では製品/ユーザーとサービスコネクティビティの両方のユースケースを実装する必要があるため，両方のユースケースが使用されると仮定して，APIゲートウェイを使用するかサービスメッシュを使用するか判断するチートシートを用意しました。

チートシート

APIゲートウェイは，分岐ポイント経由で内部または外部のクライアント/ユーザーに「製品として」APIを提供し，フルライフサイクルAPIMプラットフォーム経由でどのように公開およびオンボーディングされるか管理する場合に使用します。クライアントと基本的なAPIの間の抽象層を作成する場合にも使用します。

サービスメッシュは，すべてのサービスで採用および施行できる分散型サイドカーデプロイ経由で，システムで実行しているすべてのサービス間で信頼性があり，安全で観測可能なL4/L7トラフィックコネクティビティを構築する場合に使用します。すべてのサービスの2地点間のコネクティビティを作成する場合にも使用します。

ほとんどの場合，組織は両方のユースケースを使用するため，APIゲートウェイとサービスメッシュが同時に使用されます。

例：金融機関

上記の図から，次の例を考えてみましょう。

1つの組織に異なる製品を構築する異なるチームが存在することは非常に一般的であり，これらの製品間で情報をやり取りすることもよくあります。この金融機関には銀行業務を扱う「銀行製品」と株式市場の取引を扱う「取引製品」があり，2つの製品間で情報を共有するために互いに通信する必要があります。

これらのチームは，製品を構築しているサービス間のサービスコネクティビティを向上するため，ロードマップのあるポイントでサービスメッシュを実装することを決定します。異なるチームが異なる速度で実行するため，2つの「サービスメッシュA」と「サービスメッシュB」を実装します。

高可用性になるように，両方の製品が2つの異なるデータセンター「DC1」と「DC2」にデプロイされていると仮定します。

銀行チームは銀行内の顧客，取引チームに製品としてサービスを提供するため，オンボーディングするチームが内部APIゲートウェイを経由する外部ユーザーであるかのようにポリシーをセットアップします。両方の製品を利用するモバイルチームも，エッジAPIゲートウェイ経由で利用する必要があります。アーキテクチャは次のようになります。

APIゲートウェイはメッシュの一部であることに注意してください。メッシュの一部でないと，メッシュ内でサービスを利用できるID（TLS証明書）が提供されません。これまで説明したように，APIゲートウェイはネットワークリクエストを送信および受信できるサービス間の1つのサービスにすぎないのです。

参照記事：

The Difference Between API Gateways and Service Mesh

翻訳：エクセルソフト株式会社（えくせるそふとかぶしきがいしゃ）

エクセルソフト株式会社は，ソフトウェア開発ツールを中心に，世界中の優れたソフトウェアを日本およびアジアにおいて販売しています。エンタープライズ向けにモダンアーキテクチャのためのサービスコントロールプラットフォームを提供するKongを含む幅広い製品を提供し，今日のコンピューター ユーザーの多様なニーズに応えています。Kong製品の詳細，価格，ライセンス体系，デモの依頼などについては，お気軽にお問い合わせください。エクセルソフト株式会社はKongのGold Partnerです。