Webアプリケーションサーバのヘルスチェック機構の工夫

下の本に、Webアプリケーションのヘルスチェックの機構に対しての工夫が書いてあったでの、メモっときます。

Mobageを支える技術 ~ソーシャルゲームの舞台裏~ (WEB+DB PRESS plus)

一般に、Webアプリケーションでサービスを提供している場合、負荷分散や運用監視のためにそのアプリケーションの生死確認（ヘルスチェック）をしているかと思います。

例えば、「GET /app/helthcheck」などのレクエストをアプリケーションに対して行い、アプリケーションが正常にレスポンス（200 OK）を返す場合、ロードバランサは、そのアプリケーション（サーバ）をそのままリクエスト転送先として維持し続けます。一方、エラー（400系や500系）を返された場合、ロードバランサはそのアプリケーション（サーバ）をリクエスト転送の対象から外すことになります。また運用監視の場合、インシデントなどで運用区や設計区に通知することになります。

DeNAではそのヘルスチェックの仕組みについての工夫を実施しており、上記の書籍で紹介されてました。その工夫とは、アプリケーションへの以下のような条件の追加です。

特定のファイルが存在していた場合には、異常（HTTPステータスコード500番台）を返す。

このようにしている理由は2つあります。

とにかく簡単にサービスアウトできるから

　あるサーバを何らかの理由でサービスアウトしたい場合には、そのファイルを作成してやれば、簡単に行うことができます。そのような作業が必要になる理由はさまざまありますが、アプリケーションやミドルウェアのバージョンアップなどです。
　もちろんロードバランサの設定変更を行えば同じことはできますが、通常ロードバランサの設定は複雑で変更にはリスクが伴います。設定変更間違いの影響は計り知れません。ロードバランサが複数ある場合、全ての設定を変更するのが面倒なことにもなります。また組織によってはネットワークの管理がサーバ管理とは別になっていて自分たちですぐ行えないようなこともあるでしょう。

稼働中のサーバを安全にサービスアウトすることができるから

　例えば、サービスアウトのためにhttpdを停止したり、もしくはDSR構成であったら設定しているループバックアドレスを外したりといったことをすると、その時点で処理を行っているサービスリクエストにも影響が発生します（apacheの場合は現在の処理が終わってから停止する機構があるそうですが。）。通常ヘルスチェックのチェック間隔は数秒～数十秒単位です。よって実際NGとなって外れるまでのタイムラグがあるので、こういった外し方をするとその間のユーザリクエストが影響を受けることになります。
　また、1つのサーバに複数種類のアプリケーションが稼働している場合、1つのアプリケーションのために、Webサーバ自体を停止することは非効率であり、許されるものではないでしょう。
　そこで、ヘルスチェックだけはエラー（500）が返るが、その他の機能（や、他のアプリケーション）は正常に処理できる状態を作り出すことで、安全にロードバランサからサービスアウトさせることができます。

まとめ

Webアプリケーションに、本当のエラーじゃなくて任意のタイミングでエラー（400、500）を返せるようにしておくと、いろいろ楽だよという話でした。