Google Cloud の VPC において、「Composite Health for Private Service Connect（PSC向け複合ヘルス）」が一般提供（GA）されました。
複合ヘルス自体は既存の機能ですが、今回の GA により Private Service Connect (PSC) との連携が正式サポートされ、PSC を使用したアーキテクチャにおける自動クロスリージョン フェイルオーバーの構成がより強力かつ柔軟になります。
本記事では、公式ドキュメントの内容に基づいたPSC向け複合ヘルスの仕様、従来のマルチリージョン構成における課題、そして図解によるフェイルオーバーの仕組みについて解説します。
Composite Health for Private Service Connect の概要
複合ヘルスチェックは、1つ以上のヘルスソース（バックエンドサービスなど）のヘルス状態を集約し、公開されたサービスに対して単一の「複合ヘルス状態」を生成するリソースです。
今回の GA により、PSC 経由でコンシューマー側のロードバランサにヘルス状態を伝播できるようになりました。
PSC との組み合わせで以下のような仕様が実現します。
- 健康状態の集約: ヘルス集計ポリシーにより、正常なエンドポイントの割合と最小数のしきい値に基づいてサービス全体のヘルス状態を決定します。設定したしきい値を下回ると、公開サービスは異常とみなされます。
- 自動状態伝播: 複合ヘルスステータスは公開サービスの転送ルールに提供され、接続されているロードバランサに自動的に伝播されます。
- 迅速なフェイルオーバー: 異常な状態が伝播されると、クロスリージョンフェイルオーバーをサポートするロードバランサによって、他リージョンへの自動フェイルオーバーがトリガーされます。
- モニタリングの強化: ヘルス状態の遷移は Cloud Logging に記録されます。
これまでのマルチリージョン構成における課題
本機能が GA される以前、PSC を経由したアーキテクチャでは、「コンシューマー側（Cloud Run など PSC を利用する側）のロードバランサが、プロデューサー側（Cloud SQL など PSC でサービスを公開する側）にあるデータベースの障害を直接検知できない」という課題がありました。
PSC接続自体が正常であればデータベースがダウンしていても「正常」と判断されてしまうため、以前はアプリケーション側でカスタムヘルスチェックを作り込んだり、監視アラートをトリガーに自作スクリプトを走らせたりといった力技での対応が必要でした。
なぜ Cloud DNS のフェイルオーバーでは不十分なのか？
「リージョン障害なら Cloud DNS のルーティングポリシーで切り替えれば良いのでは？」と思われるかもしれません。
しかし、ミッションクリティカルなシステムにおいては以下の違いがあります。
- TTL（キャッシュ）によるタイムラグ: DNSは仕組み上、クライアント側にキャッシュが残るため、切り替えを行っても数分から数十分のダウンタイムが発生し、その間ユーザーはエラー画面を見ることになります。
- Anycast IP による瞬時の切り替え（GLBの強み）: Google のグローバルロードバランサ（GLB）は Anycast IP を持ち、ユーザーからのIPアドレスは変わりません。複合ヘルスによって異常を検知した瞬間、GLBはキャッシュ待ちなしで瞬時にネットワーク内のルーティングを他リージョンへ変更します。
つまり、いかなる障害であっても「ダウンタイムほぼゼロ」で瞬時に切り替えたい場合、GLB と 複合ヘルスの組み合わせが必須となるのです。
PSC向け複合ヘルスを用いたマルチリージョン・フェイルオーバーの仕組み
ここからは、本機能がどのようにフェイルオーバーを実現するのか、グラレコ風に図解したイラストを用いて具体的なフローを見ていきましょう。
この構成では、東京リージョンをメイン、大阪リージョンをスタンバイとして構成し、GLB から各リージョンの Cloud Run、PSCを経由して Cloud SQL へと接続するマルチリージョンアーキテクチャを想定し、グラレコ風に図解しました。
通常のアクセス経路
正常時は、以下のように東京リージョンでリクエストが処理されます。
ロードバランサ → 東京 Cloud Run → (PSC) NEG / Endpoint → 東京 Cloud SQL
障害発生からフェイルオーバーまでの5つのステップ
- 東京CS（Cloud SQL）障害: 東京リージョンのデータベース側で障害が発生し、正常な応答ができなくなります。
- 複合ヘルスが検知 (Unhealthy): ヘルス集計ポリシーと複合ヘルスチェックにより、正常エンドポイントのしきい値を下回ったと判定され、ステータスが「Unhealthy」になります。
- PSC経由で状態伝播: 複合ヘルスによって検知された異常状態が、PSC Endpoint / NEG を経由してコンシューマー側のロードバランサへと迅速に伝播されます。これにより、東京へのトラフィックが直ちに停止します。
- LBが自動切り替え: グローバルロードバランサが東京リージョン側の異常を検知し、瞬時にトラフィックを正常な大阪リージョンへと振り向けます。
- 大阪で正常処理: トラフィックは大阪リージョンの Cloud Run から PSC を経由し、大阪の Cloud SQL で正常に処理されます。
複合ヘルスの効果: プロデューサー側のデータベースのような深い層にある健康状態を、コンシューマー側のロードバランサに直接的かつ迅速に伝えることで、ダウンタイムを最小限に抑えたフェイルオーバーを実現できる点にあります。
まとめ
Composite Health for Private Service Connect の GA により、これまで複雑だったバックエンドの異常検知と、それに応じたコンシューマー側でのトラフィック制御が、非常にシンプルかつ自動化されるようになりました。
Cloud DNS単体では実現できなかった、キャッシュに依存しないシームレスでリアルタイムなフェイルオーバーが可能になります。
マルチリージョンでの高可用性が求められるシステムにおいては、必須級の強力な機能なのではないかと思いました！
簡単30秒