どう選ぶ？API Gateway、Ingress Controller、Service Meshの比較

Jenn GileNGINX製品マーケティング責任者

2021年を通じて実施したIngressコントローラーとサービスメッシュに関するほぼすべてのウェビナーで、次のような質問が寄せられました。「このツールはAPIゲートウェイとどう違うのですか？」または、「Kubernetesでは、APIゲートウェイとIngressコントローラー（またはサービスメッシュ）の両方が必要ですか？」

このような混乱が生じるのも、次の2つの理由から無理はありません。

• Ingressコントローラーとサービスメッシュは、APIゲートウェイの多くのユースケースに対応できます。
• 一部のベンダーは、自社のAPIゲートウェイツールをIngressコントローラーやサービスメッシュの代替手段として位置付けるか、3つすべての機能を1つのツールに統合しています。

このブログでは、これらのツールの違いと、Kubernetes固有のAPIゲートウェイのユースケースにどのツールを使用すべきかを解説します。デモを含む詳細については、ウェビナー「Kubernetes向けAPIゲートウェイのユースケース」をご覧ください。

定義

APIゲートウェイ、Ingressコントローラー、サービスメッシュは、いずれも基本的にはプロキシの一種であり、環境内へのトラフィックの取り込みと環境内での転送を目的として設計されています。

APIゲートウェイとは

APIゲートウェイは、クライアントからのAPIリクエストを適切なサービスにルーティングします。しかし、この単純な定義から、APIゲートウェイは固有のテクノロジーであると誤解されがちです。実際にはそうではありません。「APIゲートウェイ」とは、さまざまな種類のプロキシを介して実装できる一連のユースケースを指します。最も一般的なのはADCまたはロードバランサーとリバースプロキシであり、近年ではIngressコントローラーやサービスメッシュも利用されるようになっています。

ツールがAPIゲートウェイとして機能するために「必須」とされる機能について、業界内で十分な合意が形成されているとはいえません。一般に、お客さまが必要とする機能は次のとおりです（ユースケース別に分類）。

レジリエンスのユースケース

• A/Bテスト、カナリアデプロイ、ブルーグリーンデプロイ
• プロトコル変換（JSONとXML間の変換など）
• レート制限
• サービスディスカバリ

トラフィック管理のユースケース

• メソッドに基づくルーティングとマッチング
• リクエスト／レスポンスのヘッダーおよびボディの操作
• レイヤー7でのリクエストルーティング

セキュリティのユースケース

• APIスキーマの適用
• クライアントの認証と認可
• カスタムレスポンス
• きめ細かなアクセス制御
• TLS終端

これらのユースケースのほぼすべてが、Kubernetesで一般的に使用されています。一方、プロトコル変換やリクエスト／レスポンスのヘッダーおよびボディの操作は、通常、Kubernetesやマイクロサービス環境に適していないレガシーAPIに関連するため、あまり一般的ではありません。

APIゲートウェイのユースケースについて詳しくは、F5のブログ記事「NGINXをAPIゲートウェイとして導入する：パート1」をご覧ください。

Ingress Controllerとは

An Ingress controller（Kubernetes Ingress Controller、略称KICとも呼ばれます）は、トラフィックをKubernetes内に取り込み、サービスに転送してから再び外部へ送り出す、専用のLayer 4およびLayer 7プロキシです。このトラフィックは、イングレス・エグレスまたはノース・サウストラフィックと呼ばれます。Ingress controllerは、トラフィック管理に加え、可視化とトラブルシューティング、セキュリティとアイデンティティ、さらに最も高度なものを除くAPIゲートウェイのユースケースにも使用できます。

Ingress controllerを基本的なトラフィック管理以外にも活用する方法について詳しくは、F5のブログ記事「Ingress Controller選定ガイド 第1回：要件の特定」をご覧ください。

サービスメッシュとは

A サービスメッシュは、Kubernetesサービス間を流れるトラフィック（サービス間トラフィックまたはEast-Westトラフィックと呼ばれます）を処理し、一般にエンドツーエンド暗号化（E2EE）の実現に使用されます。高度なデプロイを導入する組織やE2EEを必要とする組織が増えるにつれ、サービスメッシュの導入はまだ少数ながら拡大しています。サービスメッシュは、アプリのすぐ近くに配置される分散型の軽量APIゲートウェイとして使用できます。これは、データプレーンレベルでサービスメッシュのサイドカーを使用することで実現します。

サービスメッシュの詳細と、導入に適したタイミングについては、F5ブログの「サービスメッシュの選び方」をご覧ください。

Kubernetes環境にはKubernetesネイティブツールを活用

Mark ChurchがNGINX Sprint 2.0の基調講演「Kubernetesとアプリケーションネットワーキングの未来」で述べたように、「APIゲートウェイ、ロードバランサー、サービスメッシュは、今後ますます互いに似たものとなり、同様の機能を提供するようになるでしょう」。私たちもこの見解に全面的に同意します。さらに重要なのは、どこで、どのように使用するかに応じて、用途に適したツールを選ぶことです。マチェーテもバターナイフも切るための道具ですが、朝食のトーストにマチェーテを使うことはまずないでしょう。

では、どのツールが適しているかをどう判断すればよいのでしょうか。答えはシンプルです。Kubernetes内でAPIゲートウェイ機能が必要な場合は、通常、YAMLなどのKubernetesネイティブな構成ツールを使用して設定できるツールを選ぶのが最善です。一般的には、Ingressコントローラーまたはサービスメッシュが該当します。しかし、「APIゲートウェイツールにはIngressコントローラー（またはサービスメッシュ）よりはるかに多くの機能があるのに、機会を逃すことにならないでしょうか」と思われるかもしれません。いいえ、その心配はありません。機能が多ければ優れたツールとは限りません。特にKubernetesでは、ツールの複雑さが致命的になりかねません。

注： Kubernetesネイティブ（Knativeとは異なります）とは、Kubernetes向けに設計・構築されたツールを指します。通常、Kubernetes CLIで操作でき、Helmを使用してインストールできるほか、Kubernetesの機能と連携します。

多くのKubernetesユーザーは、開発やGitOpsのエクスペリエンスを変えずに済むため、Kubernetesネイティブな方法で構成できるツールを好みます。YAMLとの親和性が高いツールには、主に3つのメリットがあります。

• YAMLはKubernetesチームにとって使い慣れた言語です。そのため、既存のKubernetesツールをAPIゲートウェイ機能に使用する場合、学習の負担は小さく、場合によってはまったくありません。使用頻度が低い可能性のある新しいツールの設定方法を学ぶ必要がなく、チームは既存のスキルを活用して作業できます。
• YAMLに対応したツールは、他のKubernetesツールと同じ方法で自動化できます。既存のワークフローに無理なく組み込めるツールはチームに受け入れられやすく、利用される可能性も高まります。
• Ingressコントローラー、サービスメッシュ、またはその両方を使用することで、Kubernetesのトラフィック管理ツールスタックを簡素化できます。ホップが増えるたびに影響が生じるため、不要なレイテンシーや単一障害点を追加する理由はありません。また、Kubernetes内に導入するテクノロジーの数を減らすことは、コストの削減と全体的なセキュリティの向上にもつながります。

南北方向のAPIゲートウェイのユースケース：Ingressコントローラーの使用

Ingress Controllerは、API Gatewayのさまざまなユースケースを実現できる可能性があります。定義で説明したユースケースに加え、組織にとって特に価値が高いのは、以下を実装できるIngress Controllerです。

• 認証と認可のオフロード
• 認可に基づくルーティング
• レイヤー7レベルのルーティングとマッチング（HTTP、HTTP/S、ヘッダー、Cookie、メソッド）
• プロトコル互換性（HTTP、HTTP/2、WebSocket、gRPC）
• レート制限

サンプルシナリオ：メソッドレベルのルーティング

Ingressコントローラーを使用してAPIリクエストのPOSTメソッドを拒否するために、メソッドレベルのマッチングとルーティングを実装します。

攻撃者の中には、API定義に準拠しない種類のリクエストを送信して、APIの脆弱性を探す者もいます。たとえば、GETリクエストのみを受け付けるよう定義されたAPIにPOSTリクエストを送信します。Webアプリケーションファイアウォール（WAF）は、リクエスト文字列と本文のみを調べて攻撃を検出するため、この種の攻撃は検出できません。そのため、IngressレイヤーでAPIゲートウェイを使用して不正なリクエストをブロックすることがベストプラクティスです。

例として、新しいAPI /coffee/{coffee-store}/brandをクラスターに追加したばかりだとします。まず、APIをupstreamsフィールドに追加するだけで、NGINX Ingress Controllerを使用してAPIを公開します。

apiVersion: k8s.nginx.org/v1kind: VirtualServer
metadata:
name: cafe
spec:
host: cafe.example.com
tls:
secret: cafe-secret
upstreams:
-name: tea
service: tea-svc
port: 80
-name: coffee
service: coffee-svc
port: 80

メソッドレベルのマッチングを有効にするには、routesフィールドに/coffee/{coffee-store}/brandパスを追加し、$request_method変数を使用してGETリクエストとPOSTリクエストを区別する2つの条件を追加します。HTTP GETメソッドを使用するトラフィックは、すべて自動的にcoffeeサービスに渡されます。POSTメソッドを使用するトラフィックは、「You are rejected!」というメッセージを表示するエラーページに転送されます。これだけで、不要なPOSTトラフィックから新しいAPIを保護できます。

routes: - path: /coffee/{coffee-store}/brand
matches:
- conditions:
- variable: $request_method
value: POST
action:
return:
code: 403
type: text/plain
body: "You are rejected!"
- conditions:
- variable: $request_method
value: GET
action:
pass: coffee
- path: /tea
action:
pass:tea

エラーページでメソッドレベルのルーティングとマッチングを使用する方法について詳しくは、NGINX Ingress Controllerのドキュメントをご覧ください。IngressコントローラーをAPIゲートウェイとして使用するセキュリティ関連の例については、F5のブログ記事「OktaとNGINX Ingress Controllerを使用したKubernetes向けOpenID Connect認証の実装」をご覧ください。

East-West APIゲートウェイのユースケース：サービスメッシュの活用

ほとんどのAPIゲートウェイのユースケースでは、実現したいことの大半はIngressレイヤーで実行でき、また実行すべきであるため、サービスメッシュは必須ではなく、少なくとも導入当初は有用とも限りません。ただし、アーキテクチャが複雑になるにつれて、サービスメッシュを利用する価値が高まります。特に有用なユースケースは、E2EEとトラフィック分割に関連するものです。たとえば、A/Bテスト、カナリアデプロイ、ブルーグリーンデプロイなどが挙げられます。

シナリオ例：カナリアデプロイ

HTTP/Sの条件に基づく条件付きルーティングを使用して、サービス間にカナリアデプロイを設定します。

この方法の利点は、本番トラフィックの大部分に影響を与えることなく、新機能や新バージョンなどのAPI変更を段階的に展開できることです。

現在、NGINX Ingress Controllerは、NGINX Service Meshで管理されているCoffee.frontdoor.svcとTea.frontdoor.svcという2つのサービス間でトラフィックをルーティングしています。これらのサービスはNGINX Ingress Controllerからトラフィックを受信し、Tea.cream1.svcなどの適切なアプリ機能にルーティングします。Tea.cream1.svcをリファクタリングし、新しいバージョンをTea.cream2.svcとすることにしました。ベータテスターから新機能に関するフィードバックを得るため、ベータテスター固有のセッションCookieに基づいてカナリアトラフィック分割を設定し、通常のユーザーにはTea.cream1.svcのみが提供されるようにします。

NGINX Service Meshを使用し、まずTea.cream1.svcとTea.cream2.svcを含む、Tea.frontdoor.svcの背後にあるすべてのサービス間でトラフィック分割を作成します。条件付きルーティングを有効にするには、HTTPRouteGroupリソース（名前はtea-hrg）を作成してトラフィック分割に関連付けます。これにより、ベータユーザーからのリクエスト（セッションCookieがversion=betaに設定されたリクエスト）のみがTea.frontdoor.svcからTea.cream2.svcにルーティングされます。通常のユーザーには、引き続きTea.frontdoor.svcの背後にあるバージョン1のサービスのみが提供されます。

apiVersion: split.smi-spec.io/v1alpha3kind: TrafficSplit
metadata:
name: tea-svc
spec:
service: tea.1
backends:
- service: tea.1
weight: 0
- service: tea.2
weight: 100
matches:
- kind: HTTPRouteGroup
name: tea-hrg

apiVersion: specs.smi-spec.io/v1alpha3
kind: HTTPRouteGroup
metadata:
name: tea-hrg
namespace: default
spec:
matches:
- name: beta-session-cookie
headers:
- cookie: "version=beta"

この例では、カナリアデプロイを0～100の比率で開始します。つまり、すべてのベータテスターがTea.cream2.svcを利用しますが、ベータテスト戦略に合わせて任意の比率で開始することもできます。ベータテストの完了後は、Cookieルーティングを使用しないシンプルなカナリアデプロイにより、Tea.cream2.svcのレジリエンスをテストできます。

NGINX Service Meshでのトラフィック分割の詳細については、ドキュメントをご覧ください。上記のトラフィック分割構成では、ルートサービスもバックエンドサービスとして指定されているため、自己参照型となっています。この構成は現在、Service Mesh Interface仕様（smi-spec）ではサポートされていません。ただし、この仕様は現在アルファ段階にあり、変更される可能性があります。

KubernetesアプリでAPIゲートウェイツールを使用するタイミングと方法

KubernetesにおけるAPIゲートウェイのユースケースの大半は、Ingressコントローラーまたはサービスメッシュで対応できます（また、そうすべきです）。ただし、NGINX PlusなどのAPIゲートウェイツールが適している特殊なケースもあります。

ビジネス要件

複数のチームやプロジェクトで一連のIngressコントローラーを共有したり、環境ごとにIngressコントローラーを特化させたりすることは可能です。一方で、既存のIngressコントローラーを活用するのではなく、Kubernetes内に専用のAPIゲートウェイをデプロイすることが適切な場合もあります。Kubernetes内でIngressコントローラーとAPIゲートウェイを併用することで、組織はビジネス要件を満たすための柔軟性を確保できます。たとえば、次のようなシナリオがあります。

• APIゲートウェイチームがKubernetesに不慣れで、YAMLを使用していない場合があります。たとえば、NGINXの設定に慣れているチームであれば、Kubernetes内にNGINX PlusをAPIゲートウェイとしてデプロイすることで、導入時の負担を軽減し、学習コストを抑えられます。
• プラットフォーム運用チームが、Ingressコントローラーをアプリケーショントラフィック管理専用にすることを希望している場合。
• クラスター内の1つのサービスにのみ適用されるAPIゲートウェイのユースケースがある場合、Ingressコントローラーを使用してすべてのノースサウストラフィックにポリシーを適用する代わりに、APIゲートウェイをデプロイして、必要な箇所にのみポリシーを適用できます。

Kubernetes環境へのAPIの移行

既存のAPIをKubernetes環境に移行する際は、Kubernetesの外部にデプロイされたAPIゲートウェイツールに、それらのAPIを公開できます。この場合、APIトラフィックは通常、外部ロードバランサー（クラスター間の負荷分散用）、APIゲートウェイとして機能するよう構成されたロードバランサー、Kubernetesクラスター内のIngressコントローラーの順にルーティングされます。

KubernetesでのSOAP APIのサポート

最新のAPIの多くはRESTを使用して作成されています。その理由の1つは、RESTfulまたはgRPCのサービスやAPIがKubernetesプラットフォームを最大限に活用できることです。しかし、再設計されていないSOAP APIが残っている場合もあります。SOAP APIはマイクロサービス向けに最適化されていないため、Kubernetesでの使用は推奨されませんが、再設計が完了するまではKubernetesにデプロイする必要が生じることがあります。そのAPIがRESTベースのAPIクライアントと通信する必要がある場合は、SOAPプロトコルとRESTプロトコルを相互変換する手段が必要です。この機能はIngressコントローラーでも実現できますが、リソース消費が非常に大きいため推奨しません。代わりに、SOAPとRESTを相互変換するため、APIゲートウェイツールをPod単位またはサービス単位のプロキシとしてデプロイすることを推奨します。

Kubernetes内外のAPIトラフィック管理

Kubernetes環境の内外にまたがるAPIの管理に関心を持つお客さまは、比較的少数です。Kubernetesネイティブなツールの選定よりもAPI管理戦略を優先する場合は、API管理ソリューションと統合できる「Kubernetesフレンドリー」なAPIゲートウェイをKubernetesにデプロイすることが、適切な選択肢となる可能性があります。

注：Kubernetesネイティブツールとは異なり、Kubernetesフレンドリーツール（Kubernetes対応型とも呼ばれます）は、Kubernetes向けに設計されたものではなく、Kubernetesの設定を使用して管理することはできません。ただし、機敏かつ軽量であるため、大幅なレイテンシーを追加したり、大規模な回避策を講じたりすることなく、Kubernetes上で動作できます。

NGINXを使い始める

NGINXは、3種類すべての導入シナリオに対応するオプションを提供しています。

Kubernetesネイティブツール：

• NGINX Ingress Controller – NGINX Plusをベースとし、高度なトラフィック制御とシェーピング、監視と可視化、認証とシングルサインオン（SSO）に対応するKubernetes向けIngressコントローラー。
• NGINX Service Mesh – NGINX Plusをエンタープライズ向けサイドカーとして採用した、軽量ですぐに導入でき、開発者にとって使いやすいサービスメッシュ。

まずは、NGINX App Protect WAFおよびDoSを搭載したNGINX Ingress Controllerの30日間無料トライアルをお申し込みいただき、常時無料のNGINX Service Meshをダウンロードしてください。

Kubernetes環境の内外で利用できる、Kubernetesとの親和性が高いAPIゲートウェイ：

• NGINX Plus – 高可用性、アクティブヘルスチェック、DNSシステム検出、セッション永続化、RESTful APIなどのエンタープライズグレードの機能を備えた、ロードバランサー、リバースプロキシ、Webサーバー、APIゲートウェイのオールインワン製品です。NGINX Controllerと統合することで、［現在の名称：F5 NGINX Management Suite］APIライフサイクル全体に対応するソリューションを実現します。

NGINX PlusをAPIゲートウェイとして使用する方法について詳しくは、30日間の無料トライアルをお申し込みのうえ、NGINXをAPIゲートウェイとして導入する方法をご覧ください。

著者について

Jenn GileNGINX製品マーケティング責任者

Jenn Gileのその他のブログ記事