【ITニュース解説】Kong Cluster

Kong Clusterは、APIゲートウェイであるKongを複数台同時に動かすことで、システム全体の性能と信頼性を高める仕組みを指す。これは、入ってくる大量のリクエストを複数のKongノードに分散させ、一台のノードに負荷が集中するのを防ぐ「負荷分散」と、もし一台のノードが故障してもサービスが停止しないように他のノードが処理を引き継ぐ「高可用性」という二つの重要な目的を達成するために利用される。

この構成の基本的な要素は、複数のKong Gatewayノード、これらが共通で利用するPostgresデータベース、そしてKongノードの手前に配置されるHAProxyというロードバランサーである。各Kongノードは同じPostgresデータベースに接続し、そこから設定情報を読み込み、同じAPIゲートウェイ機能を提供する。HAProxyは、外部からのすべてのリクエストを受け取り、それらを稼働中のKongノードのいずれかに賢く振り分ける役割を担う。この記事で紹介されているのは、Kongのオープンソース版やコミュニティ版における標準的なクラスタリング構成であり、複数のデータプレーン（APIトラフィックを処理する部分）がロードバランサーの背後にあり、同じデータベースを共有する形になっている。

HAProxyのようなロードバランサーをKongの前に配置する理由はいくつかある。第一に、HAProxyはリクエストを複数のKongノードに均等に、あるいは設定されたルールに従って分散させる。例えば、デフォルトでは「ラウンドロビン」という方式で、一つずつ順番にリクエストを振り分ける。第二に、HAProxyは各Kongノードの健康状態を常に監視し、もしノードが異常になったり応答しなくなったりした場合は、自動的にそのノードへのリクエスト送信を停止する。これにより、たとえ一部のKongノードが故障しても、サービスは停止することなく継続される。これを自動フェイルオーバーと呼ぶ。第三に、外部のアプリケーションは、複数のKongノードのアドレスを知る必要がなく、HAProxyが提供する単一の安定したエンドポイント（窓口）にだけ接続すればよいため、システム構成がシンプルになり、管理が容易になる。

この解説で示されている環境は、Docker Composeというツールを使って簡単に構築できる。Docker Composeは、データベース、アプリケーション、ロードバランサーなど、複数のコンポーネントをまとめて定義し、一度に起動・停止できる便利なツールだ。今回の構成には、Kongの設定情報を永続的に保存するためのPostgres 13データベース、データベースの初期設定を行うためのKongマイグレーションサービス、APIトラフィックを実際に処理する二つのKong Gatewayノード（kong-1とkong-2）、それらの前に立つHAProxy、そしてKongの管理画面を提供するKongaとMongoDB（Kongaのデータストア）、さらにオプションでKong Dashboardが含まれる。HAProxyは、プロキシ用と管理API用の二つのポートを公開し、プロキシ用ポートでは、リクエストがどのKongノードによって処理されたかを示す「X-Served-By」というカスタムヘッダーをレスポンスに追加する設定がされている。

Kong Gatewayを実際に機能させるには、その設定をAdmin APIを通じて行う必要がある。設定は主にUpstream、Target、Service、Routeという四つの概念で構成される。Upstreamは、実際にAPIリクエストを処理するバックエンドサーバーの集合を論理的に定義するものであり、ここでは「demo-upstream」という名前で作成される。Upstreamには「アクティブヘルスチェック」という機能を含めることができ、これはKongが定期的にバックエンドサーバーの健康状態を自動的に確認し、問題があるサーバーを一時的にトラフィックの対象から外す仕組みである。Targetは、このUpstreamに属する具体的なバックエンドサーバーのアドレスとポートを指定する。今回の例では、テスト用に用意された二つの「httpbin」サービスがターゲットとして登録される。Serviceは、公開したいAPIの論理的な定義であり、「demo-svc」という名前で作成され、どのUpstreamにリクエストを転送するかを指定する。Routeは、外部からのリクエストがどのServiceに到達するかを定義するもので、「demo-route」という名前で作成され、「/demo」というパスにマッチするリクエストを「demo-svc」に転送するよう設定される。これらの設定は、KongのAdmin APIにHTTPリクエストを送信することで実行できるが、KongaというWebベースの管理UIを利用して、より直感的に設定することも可能だ。どちらの方法で設定を行っても、情報は共有のPostgresデータベースに保存されるため、すべてのKongノードで同じ設定が有効になる。

構築されたシステムが期待通りに機能するかを確認するため、「フェイルオーバー」の動作を二つの側面から検証する。一つ目は「Gatewayノードのフェイルオーバー」である。これは、HAProxyがKong Gatewayノードの障害を検知し、自動的に健全なノードにリクエストを切り替えることを意味する。例えば、稼働中の「kong-1」ノードを意図的に停止させても、HAProxyは残りの「kong-2」ノードにのみリクエストを送り続け、サービスが中断しないことを確認できる。その後、「kong-1」を再起動すれば、HAProxyは再び両方のノードにリクエストを分散させるようになる。二つ目は「Upstreamターゲットのフェイルオーバー」である。これは、Kong Gateway自体がバックエンドの「httpbin」サービスのようなUpstreamターゲットの障害を検知し、健全なターゲットにリクエストを切り替えることを意味する。例えば、「httpbin1」サービスを停止させても、Kongはヘルスチェック機能によってその異常を検知し、「httpbin2」サービスにのみリクエストを転送し続ける。これにより、バックエンドサービスの一部が停止しても、APIゲートウェイ経由のサービスは継続される。その後、「httpbin1」を再起動すれば、Kongは再び両方のターゲットにリクエストを振り分けるようになる。

トラブルシューティングの際には、KongaがKongのAdmin APIに接続できない場合、HAProxy経由のAdmin LB（9201番ポート）を使用してみることが推奨される。HAProxyが「503 Service Unavailable」エラーを返す場合は、個々のKongノードのプロキシポート（8000番や18000番）と管理ポート（8001番や18001番）が正常に動作しているかを確認する必要がある。このデモ構成ではPostgresデータベースが唯一の障害点となるため、実際の運用環境では、データベース自体も高可用性を持つようにクラスター化するか、マネージドサービスを利用することを検討すべきだ。また、ヘルスチェックの検出速度が遅い、または速すぎる場合は、KongのUpstream設定にあるアクティブヘルスチェックの間隔や失敗回数の閾値を調整することで、システムの応答性を最適化できる。

このように、複数のKongノードが共有データベースとロードバランサーを組み合わせることで、システムの負荷分散と高可用性を実現する「Kong Cluster」を構築できる。HAProxyはノードレベルでのフェイルオーバーを、Kong自体はバックエンドサービスレベルでのフェイルオーバーを提供し、これによってAPIゲートウェイは非常に堅牢なシステムとして機能する。