CDP:Deep Health Checkパターン
システムのヘルスチェック
目次 |
解決したい課題
ロードバランサーやDNSのヘルスチェック機能を使用すれば、ひも付けられたサーバーの状態を判断して処理を振り分けることができる。
Webサーバー、Proxyサーバー、APサーバー、DBサーバーの構成で、Webサーバーの前にロードバランサーがある場合を考えてみる。ロードバランサ―はWebサーバーの状態を判断し、動作が不調なWebサーバーを切り離すことができる。しかし、ProxyサーバーやAPサーバー、DBサーバーなどバックエンドのサーバーの状態をロードバランサ―は把握できない。DNSのヘルスチェック機能を使用した場合も同様である。
クラウドでの解決/パターンの説明
クラウドのロードバランサーやDNSが持つヘルスチェック機能を使い、PHPやJavaServletなどの動的なページ（つまりプログラム）をチェックするように設定にしておく。そのプログラムで、ProxyサーバーやAPサーバー、DBサーバーなどの動作をチェックし、その結果をロードバランサーやDNSに返す。こうすることで、システム全体の健全性をチェックできる。
実装
AWSのロードバランサーサービスELBのヘルスチェック機能は、指定URLへのHTTP(S)アクセスの成否によりステータスを確認する。これを利用し、ヘルスチェック先を動的なページに設定する。ロードバランサー、Webサーバー、Proxyサーバー、APサーバー、DBサーバー から構成されるシステムとDNSを利用したシステム（DNSサーバ、Webサーバー、Proxyサーバー、APサーバー、DBサーバーから校正されるシステムとDNSを利用したシステム（DNSサーバ、Webサーバー、Proxyサーバー、APサーバー、DBサーバーから校正されるシステム））を実装例に挙げる。
（ロードバランサーを利用したシステムの手順）
- ELBを起動してヘルスチェック機能を有効にする。
- APサーバー上で動作するプログラムを作成。そのプログラムはDBアクセスを伴う。
- ELBのヘルスチェックURLは上記プログラムとし、そのURLへのリクエストに対してプログラムが動作するように設定する。
- ELBからのヘルスチェックを実施する。
（DNSを利用したシステムの手順）
- DNSのヘルスチェック機能を有効にする。
- APサーバー上で動作するプログラムを作成。そのプログラムはDBアクセスを伴う。
- DNSのヘルスチェックURLは上記プログラムとし、そのURLへのリクエストに対してプログラムが動作するように設定する。
- DNSからのヘルスチェックを実施する。
構造
利点
- システムの動作に必要なすべてのサーバーをチェックすることが可能。
- ヘルスチェックに応答するプログラムの作り方によっては、閉局（リクエストを受け付けないようにする）処理を行ったり、障害内容によってカスタマイズされたエラー情報を出力することが可能になる。
注意点
- ロードバランサーやDNSのヘルスチェック下に配置されるアプリケーションサーバには高度な安定性が要求される。そのため、DBサーバ自体の状態を確認するための最低限のプログラムを用意する。
- ロードバランサーを利用したDeep Health CheckとAutoScalingの併用は禁忌事項である。
- ロードバランサー下でのオートスケールと組み合わせたアプリケーションサーバを配置した時、アプリケーションサーバには問題がないのにアプリケーションサーバがずっと入れ替わることになる。
- サーバー数が多い場合、ヘルスチェック自体が負荷になる場合があるので、ヘルスチェックの時間間隔を考慮する。
- DBサーバーがSPOF（単一障害点）になっている場合、そこがダウンすると（バックエンドサーバーのチェックプログラムの作り方によっては）過剰反応し、すべてのサーバーを停止させてしまうケースがある。
- DBサーバー部分がSPOFにならないように、DB Replicationパターンを併用することが望ましい。
