この記事の目次
AWS ヘルスチェックってなに？
AWSのサービスに限らずサービスを提供・維持するにおいて障害が発生した時には、しっかりとした対策（ヘルスチェック）が欠かせないものとなってきます。
サービスを提供するにあたり様々な復元力や信頼性を考慮した設計が可能ですが、より信頼性などを実現するには、予知可能なインシデントなどの発生時の対策なども必要不可欠になります。
AWSでは、故障に備えた設計（Design for Failure）の考えを元に サービス冗長化構築をしています。
ハードウェアは、いずれかはクラッシュ（寿命）があると考えられており、これらの問題をAWSヘルスチェックを行う事で被害・影響を最小限に抑えます。
AWS ヘルスチェックで正常性の見分け方について
ハードウェアなども生き物同様に定期的なヘルスチェックを行う事で快適な状態を維持出来ます。
サーバーなどのハードウェアは、破損する可能性もあるので、システム内にはヘルス状態をチェックする場所も多く存在しています。
その中には、特定の要因をチェックする機能もあれば、誤検出してしまう様々なタイプがあります。
それぞれメリットもあるので、その中の代表的なも4つのヘルスチェック機能を紹介していきます。
ライブ型ヘルスチェック
ライブ型ヘルスチェックとは、AWSサービスの基本的な接続、サーバープロセスをチェックします。
ロードバランサー、外部モニタリングによって実行されるので、アプリケーション詳細を認識は出来ません。
ライブ型ヘルスチェックの実例についてはサーバーが「新しいTCP受け入れ時、ステータスコード応答時、基本事項EC2のステータス確認時」などのライブ型ヘルスチェックの例が挙げられます。
ローカルヘルスチェック
ローカルヘルスチェックでは、ライブ型ヘルスチェックが認識出来なかった、アプリケーションの認識も可能にしています。
アプリケーションの認証（ヘルスチェック）に加えてサーバーのピア（対向機器）と共有されていない情報をヘルスチェックを行うので、同時に障害が発生する事は滅多に起きません。
依存関係ヘルスチェック
依存関係ヘルスチェックでは、隣接するアプリケーションと対話する能力を細かく検査します。
依存関係ヘルスチェックの理想としては、期限切れの資格情報などの障害、対話を妨げている問題をチェックします。
ですが、誤検出の可能性も高いので、依存関係ヘルスチェックの誤検出にどのように対応するかも大切になってきます。
異常検出
異常検出では、サーバー内の全てのフリートを調べてピアと相違がないか比較し異常に対応しているサーバーがあるのかないのかを判断しています。
モニタリングを行い各サーバーの情報を集約して「遅延、エラー数」などを見つけ自動的に削除します。
もしもAWS ヘルスチェックが失敗してしまったら？
仮にヘルスチェック時に正常ではないと判断した場合について解説します。
サーバーなどが正常でないと判断した場合は、実行可能アクションは2種類あり、ロードバランサーのヘルスチェックの失敗もしくは、キューのポーリング失敗の2つが考えられます。作業を行わないようにローカルで定めサービス停止してしまう可能性もあります。
サーバーを反応させるには、ヘルスチェック失敗の要因を中央機関に通知し中央機関システムに処理を行わせる事です。
また、中央機関システムはオートでフリート全域がダウンする事はないので、失敗要因に対処する事が出来ます。
対処の方法もいくつかあるので、そちらも解説します。
フェールオープン
フェールオープンとは、機器などの通信の維持をする事を指します。
ロードバランサーの一部は、中央機関として機能する事が出来、各サーバーがヘルスチェックに失敗をするとロードバランサーにおけるトラフィックが停止してしまいます。
また、全てのサーバーが同時にヘルスチェックに失敗するとロードバランサーはオープンに失敗してしまい、サーバーのトラフィックを全て許可してしまいます。
サーキットブレーカーが無いヘルスチェックの実装
サーキットブレーカーとは、一定の変動や障害を起こした際に強制的に停止をさせるシステムです。
サーバー自身の問題に対応出来るように復旧への近道と感じるかもしれませんが、サーバーの状態が異なるかフリート全体で問題が起きているか把握してない場合は、リスクが高くなってしまいます。
フリート全体のサーバーが同様の問題を同時に起こしてしまうと、隣接するサービス全体へ連鎖反応が発生する可能性もあります。
また、ヘルスチェックとモニタリングに差異がある場合、サーバーは問題検出されるまで機能低下してしまう事もありますが、サーキットブレーカーでは、フリート全体で予知出来ないヘルスチェック動作によるサービス停止を防ぐ事が出来ます。
正常性を優先する
サーバーが高負荷状態では、サーバーが通常の作業よりもヘルスチェックを優先する事が大切になってきます。
高負荷の場合、ヘルスチェックに失敗してしまうか、遅延など状況がさらに悪化する可能性があります。
サーバーがロードバランサーのヘルスチェックに失敗すると、ロードバランサーはすぐに、サービスを停止するように要求します。
単体のサーバーに障害が発生した場合、そこまで問題視する必要はありませんが、サービスへのトラフィックが急増している状況では、サービスを縮小する事は望ましくありません。
高負荷時にサーバーのサービスを停止すると、スパイラルが発生する可能性があり、サーバーが過負荷になりやすくなり、ヘルスチェックに失敗してしまいます。
AWS ヘルスチェックで問題発生時や利用例について
ヘルスチェックが正しく行われない時、どのような影響がシステムに及ぶのかを解説します。
ヘルスチェック時の問題点として、「デプロイ、非同期のプロセッサー、ディスク容量過多、ゾンビ現象」の4つの例を挙げて解説していきます。
デプロイ
ヘルスチェック時の障害の1つとしてデプロイが挙げられます。
デプロイシステムは、新しいコードをまとめてフリートに要求し1つのデプロイが完了するのを待ってから次の工程に進みます。
このプロセスは、サーバーが新しいコードで実行されるとデプロイに報告するサーバーに依存しているので、報告がないとコードに問題があると判断してしまいロールバックしてしまいます。
ディスク容量過多
サーバー上のディスクの容量が一杯になりログや処理が失敗してしまいます。
ディスク容量過多によって引き起る障害は、モニタリングシステムに報告が出来なくなり可視性にギャップが生じてしまいます。
ゾンビ現象
しばらくネットワークから遮断されていたサーバーなどをゾンビサーバーなどと呼びます。
そういったゾンビサーバーが再始動すると、別のフリートと同期がとれなくなり問題が発生する可能性があります。
ゾンビサーバー対策としてシステムが実行中のソフトウェアバージョンなどでヘルスチェックに応答する事などが挙げられます。
そもそもAWSサービスとは？
ここまで、AWSヘルスチェックについて解説をしてきましたが、そもそものAWSのサービス概要についておさらいをしていきます。
AWS（Amazon Web Services）とは、クラウドコンピューティングの総称で、インターネットを介してストレージ、サーバーといったコンピューターを使ってサービスを利用する事です。
手元に1台インターネット環境が備わっているパソコンを持っているだけで、大容量ストレージ、サーバーが必要な時に必要な数だけ利用が出来るという事です。
今までの物理サーバーとの大きな違い！
「コスト、管理、スペース」などの負担の軽減に繋がります。
従来までのオンプレミス型のサーバーだと、機器を設置するにあたってスペースの確保や機器購入するにあたってのコストなどがかかっていました。
機器の納期などが長期間になると、運用までに時間もかかります。
そこで、AWSのようなクラウドコンピューティングでは、機器購入、管理、スペースの確保などの必要がインターネット上で完結します。
必要な時に必要な分だけ確保、管理などが出来るので、オンプレミス型に比べるとスピード感があり手軽に利用が出来ます。
AWS ヘルスチェックで定期検査をしてあげよう！
AWSヘルスチェックは、サービス維持やサービスの提供をする上で大切な役割を担っています。
ヘルスチェック1つとっても幾つかのパターン（ライブ型ヘルスチェック、ローカルヘルスチェック、依存関係ヘルスチェック、異常検出）に分かれています。
それぞれのパターンで、得意不得意もあるので、正しいチェック法を活用しましょう。
また、ヘルスチェックを行うにもしっかりとした環境などを整えておかないとヘルスチェックがうまく実行しない事もあります。
ヘルスチェックに失敗しても焦らずに原因を追究しましょう。
