最近、いろいろ調査や検証をしていますが Amazon Route 53 を利用してサービス停止を検知してフェイルオーバーを実施することは難しいです。
構成図
例えば、下図の構成で SQL Server がフェールオーバークラスタリング（WSFC/MSFC）でクラスタリングしているとします。
SQL Server は EC2 インスタンス上にインストールされています。
この構成で Route 53 のルーティングポリシーでフェールオーバーを実現したい場合はどうなるでしょうか。
Route 53 のルーティングポリシー
Route 53 には以下のルーティングポリシーがあります。
- シンプルルーティング
- 加重
- 位置情報
- レイテンシー
- フェイルオーバー
- 複数値回答
- IP ベース
この中で「フェイルオーバー」が利用できるでしょうか？
しかしDB サーバでのフェイルオーバーは OS が停止した時だけではなく、SQL Server サービスが停止した際にもフェイルオーバーしてもらわなければいけません。
DB が停止していたらアプリが DB にアクセスをしてもエラーになってしまいます。
サービス（SQL Server等）が停止でのフェイルオーバーは困難
常に綺麗に？ EC2 インスタンスに障害が起きて OS まで停止してくれれば Route 53 でのフェイルオーバーの実現はできそうです。
そかし、常にそんな都合のいいことはなくても両方の EC2 インスタンスが正常に稼働している場合、Route 53 のエンドポイント監視でシンプルなヘルスチェック（ポート監視等）を用いた場合は、フェイルオーバーの実現は困難です。
どうしても Route 53 を利用して Route 53 でフェイルオーバーを実現したい場合は作り込みが必要となります。
例えば ECS で Fargate を利用していて Route 53 を使わなければいけない場合などです。
案① HTTP/HTTPSを用いたヘルスチェックで文字列の監視をする
HTTP/HTTPS を用いた監視では文字列を監視することが可能です。
Amazon Route 53 でヘルスチェックの正常性を判断する方法
例えば正常の場合は監視対象 URL で「OK」と返し、それ以外の場合は「NG」と返すことでフェイルオーバーを実現可能です。
案② CloudWatch アラームを用いたヘルスチェック
Route 53 のヘルスチェックで CloudWatch アラームも利用することが出来ます。
Route 53 が CloudWatch アラームをモニタリングするヘルスチェックのステータスを決定する方法
例えば CloudWatch メトリクスにデータを送信して、何か SQL Server サービスが正常でなくなった場合に CloudWatch アラームの状態が変化するようにすることでフェイルオーバーが実現可能となります。
どれも若干難しいというか、敷居が高いような気がします。
というのもフェイルオーバーは確実に短時間でやる必要がありますが、上記のような作りこみになると SQL Server サービスが停止していることに気が付くのに時間が掛かりそうです。
やっぱり RDS に移行してしまうのが一番理想ですが、なかなかそう簡単にはいかないのが企業なんですよね。
柔軟に対応していくしかありません。
コメント