AWS上のvSocket HA構成でルーティング切り替えを実現した話

本記事は夏休みクラウド自由研究2026 8/22付の記事です。

こんにちは。Catoエンジニアの中山です。

今回は、AWS上でvSocketのHA構成を検討した際に直面したルーティングの課題と、その解決策についてご紹介します。

通常、AWS版vSocketではCatoがHA向けのルーティング切替機能を提供しています。しかし、今回の環境では設計上の要件によりその仕組みを利用できませんでした。

そこで、

CloudWatch Synthetics
CloudWatch Alarm
Lambda

を活用し、AWSサービスのみでルーティングを切り替える仕組みを構築しました。

同じような要件で設計を検討している方の参考になれば幸いです。

HAのルーティングで困ったこと

vSocketを利用する場合、通信経路を実現するために以下の2つのルーティングを考慮する必要があります。

Cato側のルーティング
AWS側のルーティング

今回課題となったのは、AWS側のルーティングです。

CatoではvSocketのHA構成向けに自動ルーティング切替機能が提供されていますが、今回の環境では要件に合致せず、そのまま利用することができませんでした。

Cato標準のHAルーティング切替の仕組み

まずはCatoが提供しているHA機能の動作を簡単に整理します。

障害発生時は以下の流れでフェイルオーバーが行われます。

SecondaryのLAN ENIからPrimaryのLAN ENIへKeepAliveパケットを送信
Primary障害発生によりKeepAliveが途絶
SecondaryがMasterへ昇格
SecondaryがIAMロール権限を利用してルートテーブルを更新
通信経路を自身のLAN ENIへ切り替え
Primary復旧後にSecondaryはStandbyへ戻る

この仕組みにより、vSocketのMaster切替と同時にAWSのルーティングも自動で変更されます。

なぜ利用できなかったのか

今回の環境では、主に2つの制約がありました。

理由①: 更新対象のルートテーブルを1つしか指定できない

Catoのルーティング切替機能では、更新対象となるルートテーブルを1つ指定します。

しかし今回の環境では、

LANサブネット用ルートテーブル
業務サーバ用サブネットのルートテーブル

が分かれていました。

Catoが更新するのは指定されたルートテーブルのみであり、業務サーバ用サブネット側のルーティングまでは変更されません。

その結果、SecondaryがMasterへ昇格した後も業務サーバ用サブネット側は引き続きPrimaryのLAN ENIへ通信を送ろうとしてしまい、正常な通信ができなくなります。

特に移行期間中など、業務サーバ用サブネット側のルートテーブルをすぐに変更できない環境では大きな制約になります。

理由②: 0.0.0.0/0 を利用する前提となる

もう1つの制約が対象ルートです。

Catoの仕組みでは、ルートテーブルの切替対象として 0.0.0.0/0 を使用します。

しかしAWS環境では、

インターネット向け通信をNAT Gateway経由にしたい
一部通信のみをCatoへ通したい

といった要件も少なくありません。

その場合、0.0.0.0/0 をvSocketのLAN ENIへ向けられないため、Cato標準のルーティング切替機能を利用できません。

解決策

前段が長くなってしまいましたが、HA時のルーティングがうまく切り替わらない問題を解決するためにAWS側の仕組みにてルーティングの切り替えを実現しました。

その構成がこちらです！

仕組みとしては、Cloudwatch Synthetic Monitorにて、Primary側のLANのIPアドレスに対してICMPの応答状況をCloudwatchメトリクス化して、

作成したメトリクスにて、Cloudwatch Alarmを設定し、アラーム時/正常時でLambdaのアクションを設定し、Lambdaにて対象のルートの向き先(Primary LAN or Secondary LAN)を変えるようにしてます。

この方式を取ることで、以下を実現しております。

Cato標準ルーティング切替に依存しない
任意ルートを切り替え可能
AWSサービスのみで構成可能

この構成以外だと、フェイルオーバーを検知するための仕組みとして、Catoの Link Health Rule と AWSの APIゲートウェイを用いて、Cato側のSocketフェイオーバーイベントをWebhookにて発報し、APIゲートウェイにて受け取り、Lambdaをキックする方法も考えましたが、Cato×AWSになるので、仕組みが複雑になり、うまく連携して動作するか確認が必要でしたので、今回のようにAWSサービスだけで構成しました。

構成を検討にあたっての懸念点がいくつか上がってきましたが、それぞれ以下のように整理してます。

Cato×AWSの連動面でCato側のフェイルオーバーとAWS側のルーティング切り替えがズレてしまう可能性があるのでは？

⇒使用しているポートなどは違いますが、パケットを送りその応答状況に応じて切り替えを行う点は同じのため、影響はほぼなしと判断しました。

この仕組みはLAN側の検知を前提としているが、Cato側だとWAN側の不通を検知することができるため、機能不足なのでは？

⇒WANはAWSのインターネット基盤を使用して通信するが、AWSのインターネット部分のみ障害が発生する可能性は低いと思われるため、設計の考慮外としました。(手動で変えることは可能。)

一応、この構成の弱点も書いておきます。

vSocketのアプリケーション部分の動作不良に弱い。

ICMPなどサーバーの状況を判定して動作しているため、サーバごと落ちてしまえばよいのですが、サーバは活きてて、アプリ部分だけうまく動いてないとかの場合、懸念点で記載したようなMaster側のズレが発生しうるのでは？と考えております。

⇒Link Health Rules × APIゲートウェイの構成だと解決できたりしそう。。

Cato側のフェイルオーバーとAWSルーティング切り替えの時間のラグがある

Cato側のフェイルオーバーはKeepAliveパケットのロスから3秒程度でMasterの切り替えが行われるのですが、AWS側のルーティング切り替えはCloudwatch Synthetic Monitorの最小単位が30秒であるため、最速で30秒かかり、Catoの切り替わりとAWSの切り替わりで20秒程度ラグが発生してしまいます。。

⇒システムによっては許容できないモノがいそうだなと思っているので、今後改善を検討したいポイントです。

まとめ

今回は、AWS上のvSocket HA構成で発生したルーティングの課題と、その解決策についてご紹介しました。

CatoとAWSをを組み合わせた設計はそこまで公開されている事例があまりないかと考えまして、私自身が設計を検討した際も、「きっと同じように困っている人がいるはず！」と感じたので、その時の知見をまとめてみました。

困っている方にこの情報が届き、少しでも助けになれば嬉しいです！