内部サービスが課金サービスからユーザーデータを取得する必要があるとき、1ミリ秒の遅延すら命取りになります。この内部トラフィックをパブリック向けのエッジゲートウェイ経由でルーティングすると、リクエストはプライベートネットワークを離れ、外部のファイアウォールを通過し、不要なシリアライズのオーバーヘッドが発生します。この経路をたどるだけで、1つの依存関係の呼び出しに対して簡単に30ミリ秒のレイテンシーが追加されてしまいます。
内部のサービス間通信には、エッジルーティングとは異なるアーキテクチャのアプローチが必要です。エッジでは、公開開発者ポータルや、外部クライアント向けの複雑なレート制限、重いOAuth2検証が求められます。一方で内部では、低レイテンシー、ネイティブなサービスディスカバリ、そして最小限の運用摩擦が求められます。
内部マイクロサービスに最適なAPIゲートウェイの選択は、チームがどれだけの運用負荷を許容できるかと、生のパフォーマンスへの要求度とのバランスによって決まります。
内部マイクロサービスのルーティングにおける課題：セルフホスト vs. マネージド
プラットフォームアーキテクトは、内部ルーティングを設計する際に根本的な選択を迫られます。サービスの近くにセルフホスト型のゲートウェイをデプロイして管理するか、それともインフラ管理をマネージドクラウドサービスに委ねるかです。
セルフホスト型ゲートウェイは、プライベートネットワーク内（多くの場合、Kubernetesクラスター内のサイドカーやイングレスコントローラーとして）で動作します。このデプロイモデルはトラフィックをローカルに保つため、レイテンシーを最小限に抑えられます。また、ルーティングルール、ヘッダー操作、ConsulやEtcdなどのツールとのサービスディスカバリ連携を完全に制御できます。しかし、基盤となる仮想マシン、スケーリングポリシー、アップグレードの管理は自社チームで行う必要があります。
マネージドクラウドゲートウェイは、外部サービスとして動作します。メンテナンスはほぼ不要で、トラフィックの急増に合わせて自動的にスケールします。トレードオフとなるのは、レイテンシーとコストです。すべての内部リクエストは、クラウドプロバイダーのゲートウェイエンドポイントを経由して仮想プライベートクラウド（VPC）に戻る必要があります。この余分なネットワークホップがレイテンシーを引き起こし、連鎖するマイクロサービス呼び出しのパフォーマンスを低下させる原因になります。
Kong：プラグイン豊富なエコシステムを持つ高性能ゲートウェイ
Kongは、NginxウェブサーバーとOpenRestyウェブプラットフォームをベースに構築されたオープンソースのゲートウェイです。Nginxのイベント駆動型アーキテクチャを継承しているため、Kongは高スループットかつ低レイテンシーなルーティングにおいて抜群の性能を発揮します。
[内部リクエスト] ---> [Kong Gateway (Nginx/OpenResty)] ---> [対象マイクロサービス]
|
[Luaプラグイン] (認証、レート制限、ログ記録)
Kongは拡張にLuaを使用します。ヘッダーの変更、認証トークンの挿入、Prometheusへのリクエストログ記録などが必要な場合は、プラグインを適用します。オープンソース版のKong Gateway OSSには、豊富なコミュニティプラグインが含まれています。ロールベースのアクセス制御（RBAC）やマルチゾーンデプロイなどの高度なエンタープライズ機能が必要な場合、チームはKong Enterpriseへ移行する必要があります。
Kongを管理するには、その設定状態の管理が必要です。従来のデータベースモード（ルーティング設定を保存するためにPostgreSQLデータベースが必要）でKongを実行することも、DBレスモードで実行することもできます。DBレスモードでは、宣言的なYAMLファイルに設定を記述し、ゲートウェイのメモリに直接適用します。このアプローチはGitOpsワークフローやKubernetes環境と相性が良いですが、動的なデータベースストレージを必要とする一部のプラグインが使用できなくなるという制限があります。
Tyk：追加設定なしで機能が揃うGoネイティブなゲートウェイ
Tykは、完全にGoで書かれたオープンソースのAPIゲートウェイです。コア機能にモジュール式のプラグインアーキテクチャを採用しているKongとは異なり、Tykはレート制限、アナリティクス、サービスの仮想化などの機能をコアエンジンに直接内蔵しています。
TykはGoで記述されているため、すでにGoの知見を持つチームにとって魅力的です。開発者は、TykのgRPCベースのプラグインコプロセッサを使用して、Go、Python、JavaScript、またはLuaでカスタムプラグインを記述できます。
Tykの動作にはRedisが必要です。セッションストレージ、レート制限カウンター、キャッシュにRedisを使用します。このデータベース依存は管理対象を増やしますが、RedisのおかげでTykは予測可能かつ極めて低いレイテンシーで大量のトラフィックを処理できます。Tykのオープンソース版は非常に機能が豊富で、有料のエンタープライズ版と同じゲートウェイエンジンを提供しています（エンタープライズ層では管理コントロールプレーンとダッシュボードが追加されます）。
クラウドネイティブの選択肢：AWS API Gatewayとプラットフォームマネージドサービス
インフラが完全にパブリッククラウド上で動作している場合、AWS API Gateway、Azure API Management、Google Cloud Apigeeなどのマネージドオプションは非常に手軽な選択肢です。
AWS API Gatewayは、他のAWSサービスと直接連携します。カスタムの統合コードを書くことなく、着信したAPI呼び出しをAWS Lambda関数、SQSキュー、または内部のApplication Load Balancer（ALB）に直接ルーティングできます。セキュリティはAWS Identity and Access Management（IAM）ポリシーを通じて処理されるため、アクセス制御が簡素化されます。
しかし、クラウドマネージドゲートウェイにはパフォーマンス面でのトレードオフがあります。
- コールドスタート： サーバーレスのバックエンドと連携する場合、最初のリクエストの解決に数秒かかることがあります。
- ネットワークホップ： トラフィックは、プライベートネットワークに戻る前に、ゲートウェイのパブリックエンドポイントに到達するためにプライベートサブネットの外に出る必要があります。
- ベンダーロックイン： 設定がクラウドプロバイダー独自のAPIやデプロイツールに依存します。
高スループットの内部マイクロサービスにおいて、これらの要因はクラウドネイティブな選択肢をセルフホスト型の代替案よりも不利にする可能性があります。
意思決定フレームワーク：チーム規模と運用予算による選択
最適なゲートウェイを選択するには、インフラを管理するチームのキャパシティと、パフォーマンス要件を天秤にかけて評価します。
小規模なスタートアップチーム（開発者1〜10名）
小規模なチームであれば、運用のオーバーヘッドを低く抑えることを最優先にすべきです。AWS API Gatewayなどのクラウドプロバイダーのマネージドゲートウェイを使用して、サービスを迅速に立ち上げましょう。この規模では、セットアップの容易さとメンテナンスフリーのモデルが、わずかなレイテンシーのデメリットを上回ります。
中規模のプラットフォームチーム（開発者10〜50名）
サービスメッシュが成長するにつれ、クラウドゲートウェイのコストはリクエストボリュームに応じて線形に増加します。この段階になると、セルフホストの導入がコスト面でも運用面でも現実的な選択肢になります。
現実的なコスト比較を見てみましょう。
- マネージドのシナリオ（例）： 中規模のアプリケーションが1日に100,000,000件の内部リクエストを処理するとします。クラウドゲートウェイの料金が100万リクエストあたり3.50ドルと仮定すると、ルーティングコストだけで1日350ドル、つまり月額約10,500ドルになります。
- セルフホストのシナリオ（例）： 同じチームが既存のKubernetesクラスターにKongまたはTykをデプロイします。高可用性を確保するために3つの小さなコンピュートインスタンスを実行し、コンピュートリソースのコストは合計で月額150ドルに収まります。
セルフホストを選択することで大幅な予算削減が可能になりますが、プラットフォームチームは毎月数時間を費やして、アップデートの管理、RedisやPostgreSQLの監視、デプロイパイプラインの設定を行う必要があります。Northwind Studioのようなブティックエージェンシーでも、クライアントのインフラ設計を支援する際、この運用コストとインフラ実費のバランスを重視しています。
大企業のプラットフォームチーム（開発者50名以上）
厳格なコンプライアンスとミリ秒未満のレイテンシー要件を持つ大企業では、セルフホスト型ゲートウェイがほぼ必須となります。これらのチームは通常、KongやTykをハイブリッドまたはマルチリージョン構成でデプロイし、トラフィックを完全にローカルデータセンターやVPC内に留めます。
| 選定基準 | Kong | Tyk | AWS API Gateway |
|---|---|---|---|
| 主な開発言語 | Lua / C | Go | 独自仕様 |
| データベース依存 | PostgreSQL または DBレス | Redis | なし（マネージド） |
| 拡張性 | Luaプラグイン | Go, Python, gRPC | AWSインテグレーション |
| レイテンシー特性 | ミリ秒未満 | 極めて低い（マイクロ秒単位） | 中程度（ネットワークホップあり） |
| 最適な用途 | 高性能なNginx環境 | すぐに使える機能を求めるGo中心のチーム | サーバーレスおよび純粋なAWSアーキテクチャ |
StackMatchでAPIインフラの選択肢を評価する
適切なAPIゲートウェイの選択は、システムのレイテンシー、コスト、運用の複雑さに影響を与える重要なアーキテクチャ上の決定です。StackMatchでは、さらに多くの選択肢を探索し、これらのツールを詳細に比較できます。StackMatchは、プラットフォームエンジニアが特定の技術スタックに最適なツールを見つけられるよう、厳選されたツールリスト、並列比較ページ、使いやすさ・価格の透明性・連携性に基づく編集スコアを提供しています。
FAQ
内部ルーティングにおいて、KongはAWS API Gatewayよりも高速ですか？
はい、一般的にKongはAWS API Gatewayよりも大幅に低いレイテンシーを提供します。KongはNginx上で動作し、マイクロサービスの近くのプライベートVPC内にデプロイできるため、AWSの完全マネージドサービスに伴うネットワークホップやコールドスタートを回避できます。
Tykはデータベースなしで動作しますか？
Tykはキャッシュ、レート制限、セッションストレージのためにRedisを必要とします。Redisなしで完全にステートレスに実行することはできませんが、このアーキテクチャにより、リレーショナルデータベースに依存するゲートウェイと比較して、最小限のレイテンシーで高スループットのトラフィックを処理できます。
クラウドネイティブなゲートウェイからセルフホスト型ゲートウェイへの移行を検討すべきタイミングは？
一般的には、クラウドネイティブゲートウェイの料金がAPI呼び出し回数に比例して膨らみ始めたとき、またはWANルーティングによるレイテンシーの増加が内部マイクロサービスのパフォーマンスに影響を与え始めたときです。内部サービスに10ミリ秒未満のレスポンスタイムが求められる場合、通常はKubernetes上にKongやTykをセルフホストする必要があります。
KongとTykはgRPCやGraphQLをどのように処理しますか？
両方のゲートウェイともgRPCおよびGraphQLのルーティングをサポートしていますが、処理方法が異なります。KongはgRPCトランスコーディングやGraphQLスキーマ検証にプラグインを使用します。一方、Tykは複数のスキーマを1つのグラフに統合するネイティブなGraphQLエンジン機能を標準で提供しています。