サーバー間ヘルスチェック

概要
要件
設計
1. アクティブヘルスチェック / パッシブヘルスチェック
2. ヘルスチェック手法
  1. 余談
L4ヘルスチェックの設計悩み
まとめ
Reference

概要

サーバー間ヘルスチェックをどのように設計するか悩んだのでまとめます。

要件

サーバーAはサーバーBのrest apiに差分データを随時postするという設計から以下の要件を出ます．

サーバーBはサーバーAからの更新が途絶した場合に警告を出す
– サーバーBはサーバーAからの更新途絶を検出する
　(更新頻度は一定でないため，サーバーAのダウンと識別する能力が必要)
– xxx
サーバーAはサーバーBへのpostに失敗した場合に警告を出す
– サーバーAは失敗したpostを一定期間保持し，リトライする．
– サーバーAは失敗したpostを一定期間後に破棄する．
– サーバーAは破棄したpost内容と対処の通知を行う
– xxx

一方通行のデータ授受のため，上記のような要件が想定されます．

今回の記事は主に太字で示した部分，即ちヘルスチェックをどう設計するかというのが題材です．

設計

アクティブヘルスチェック / パッシブヘルスチェック

大別するとアクティブヘルスチェックとパッシブヘルスチェックの2通りが存在します．(*1

アクティブヘルスチェックとは定期的に対象機器に対して，いずれかのレイヤー通信で応答確認を行うことで，対象機器の生存を確認します．

パッシブヘルスチェックとは対象機器への必要な通信時に，通信結果から対象機器の生存を確認します．

今回はデータ受領側がデータ送信側のヘルスチェックを行いたいので，パッシブヘルスチェックは取れません．（データ送信側がダウンしている場合にはそもそも通信が行われないため）．そのためアクティブヘルスチェックを実施するしかありません．

ヘルスチェック手法

ヘルスチェックはロードバランサーで最も一般的に使用されている技術です。ヘルスチェックをどのレイヤーで実施するかも決定する必要があります．

L3チェック
ICMP echoリクエストを送信し、echoリプライが返ってくるかどうかを確認します。
L4チェック
TCPのハンドシェークを行い、サーバの動作を確認します。
L7チェック
HTTP等のアプリケーションレイヤで擬似的なリクエストを出し、サーバのレスポンスを確認する。
https://www.f5.com/ja_jp/services/resources/glossary/health-check

L3チェックでは機器自体が生存しているが，アプリケーションプロセスがダウンしている場合にも応答を返してしまうため，本目的には沿いません．機器の電源が入っているか等のより低レベルでのヘルスチェックを実現する際に採用されます．

L4チェック/L7チェックのどちらを採用するかはアプリケーションの設計に依存します．
– HTTPを採用しているか
– L4チェックがTCPハンドシェイクのみか特定応答の返答も可能か（TCPハンドシェイクのみの場合は，接続確認のみでプロセスが正常動作しているか不明．偶々TCP接続部だけ正常動作している場合があるかもしれない）
– L4チェックにおけるTCPポートの確保は可能か
等かと思います．

基本的にはアプリケーションプロセスレベルのヘルスチェックを実施できるのであれば，機能要件としてはL4/L7のどちらでも構わないと思います．非機能要件としては
– HTTPログにヘルスチェックが含まれるべきか否か
– ヘルスチェックも暗号化や機器認証を行いたいか(HTTPとして設計しておいた方がHTTPS等への拡張が容易)
– 実装工数
等が考慮事項として挙げられます．

今回はTCP層でアプリケーションプロセスレベルのヘルスチェックを実施する設計を採用したと仮定します．（サーバーAのHTTPサーバー機能には機器認証が必須なため，プロトタイプとして試行するには手間がかかるため見送ったというのが実情です．通常は大人しくHTTPで実現するのがいいと思います．）

余談

ちなみにSpring Bootを使用している場合はspring-boot-actuatorなるライブラリが存在し，実装工数を大幅に下げることが可能です．

L4ヘルスチェックの設計悩み

L4ヘルスチェックでも以下の3通りぐらいは選択肢としてあると思います

①	TCP接続を保持し続けて，その接続が切れたらダウンと判断する
②	TCP接続を保持し続け，そこで定期的にステータス通知する
③	TCP接続を毎回張り直し，定期的にステータス通知する