LASSIC Media らしくメディア

システムを止めずに動かし続けるには、サーバーやプロセスが正常に動作しているかどうかを、常時確かめる仕組みが要ります。突然の高負荷や故障で処理が止まっても、気づくのが遅れれば、利用者への影響はそのぶん長引くでしょう。この「気づきの遅れ」を防ぐ土台として使われているのが、ハートビートです。開発会社との打ち合わせで、監視の設計を具体的に詰めるうえでも欠かせない基礎知識といえます。

ハートビートは、クラスタの代表ノードを決める「リーダー選出」や、負荷の振り分けを担う「ロードバランサ」とは役割が異なります。本記事では、生きているかどうかを信号でやり取りし、途絶えたときに故障とみなす、死活監視・障害検知の仕組みに絞った解説です。発注担当者やプロジェクトマネージャーが、開発会社との打ち合わせで押さえておきたい勘所をまとめています。実装の細部よりも、判断のポイントを中心に取り上げました。

ハートビートとは——生存確認信号で異常にすぐ気づく仕組み

ハートビートとは、サーバーやプロセスが正常に動いているかを確かめるために、一定の間隔で送り合う短い生存確認の信号です。

役割は、異常が起きたときにできるだけ早く気づき、待機系への切り替えや異常ノードの除外といった対応の引き金にすることにあります。信号を受け取り続けている間は「生きている」と判断し、途絶えれば「故障した」と見なす、単純な判定がベースです。

代表ノードを決めるリーダー選出や、アクセスの振り分けを担うロードバランサは、それぞれ別の役割を持つ仕組みです。本記事が扱うのは、あくまで生死を信号で確かめ、途絶えを故障の合図として扱う部分に限られます。3つの仕組みの違いを一覧にすると、次のとおりです。

いずれも分散システムを支える仕組みですが、扱う対象と目的が異なる点を押さえておくと、混同を避けられます。名称は、心臓の鼓動になぞらえたもので、送り続ける限り「生きている」ことを示す合図です^*1*2。クラスタ管理ソフトウェアの多くは、ノードごとに稼働状態を持ち、信号の有無に応じて状態を切り替える仕組みを備えています。

要件定義書や設計書でこれらの用語が混同されていると、開発会社との認識にずれが生じかねません。用語を正しく切り分けておくことも、発注時に押さえておきたい基本のひとつです。

Linux環境のクラスタ管理ソフトウェアの実装例でも、ノードの生死判定にこの方式が採用されてきました^*1。こうした実装の広がりが、死活監視の標準的な部品として定着した背景にあるといえます。

仕組み自体は単純ですが、複雑な判定ロジックを持ち込まずに済む点が、長く使われ続けている理由でしょう。信号を送る側・受け取る側の双方が、同じ約束事だけを守ればよいため、実装の見通しが立てやすいのです。

この記事では、この単純な仕組みがどう組まれ、どこでつまずきやすいかを、発注担当者やプロジェクトマネージャーの視点から見ていきます。

監視の仕組みが無ければ、異常の発覚が利用者からの問い合わせ頼みになりかねません。ハートビートを組み込むことで、社内が先に異常を把握し、対応に動き出せる体制を築けます。

発注担当者にとっては、開発会社が死活監視をどう設計しているかを確認することが、稼働後のトラブル対応力を見極める手がかりになるでしょう。

サーバー間監視・LB・クラスタでの使いどころ

ハートビートが使われる場面は、大きく3つあります。サーバー間の死活監視、ロードバランサによる正常性チェック、クラスタでの障害検知と切り替えです。

サーバー間の死活監視

クラスタを組むサーバー同士が、一定間隔で信号を送り合い、相手の生死を確かめる使い方です。片方の信号が途絶えれば、残った側が異常を検知し、処理を引き継ぎます。

たとえば、待機系を控えたシステムでは、稼働系から一定間隔で送られる信号が途絶えた瞬間に、待機系が処理を引き継ぐ設計がよく採られます。信号の送信先を複数に分けておけば、経路の一部に不具合があっても、判定の誤りを減らせるでしょう。監視の経路を一本化しないことは、後述する誤検知への備えにもつながります。

サーバー間の死活監視を組み込んでいない場合、異常の発覚が利用者からの問い合わせ頼みになり、対応の初動が遅れる要因になり得ます。層を分けて監視を組み込んでおくこと自体が、初動の速さを左右するのです。

ロードバランサの正常性チェック

AWSのApplication Load Balancerは、登録先のターゲットへ定期的にリクエストを送ります。連続の失敗回数が設定値（UnhealthyThresholdCount）を超えると、そのターゲットを振り分け対象から外します^*4。Google Cloudのロードバランサも、確認の間隔・タイムアウト・しきい値を設定でき、連続失敗が続いたバックエンドを異常と判定する設計です^*5。

これらのヘルスチェックは、単体のサーバー同士が交わす死活監視の信号とは別に、利用者からのアクセスを実際に受けられる状態かどうかを確かめる目的を持ちます。異常と判定されたターゲットは、振り分け対象から一時的に外れるだけで、システム全体から切り離されるわけではない点も押さえておきたいところです。

クラスタでの障害検知と切り替え

Kubernetesのliveness probe（生存確認のプローブ）は、コンテナを定期的にチェックします。失敗し続けた回数がfailureThreshold（既定値3）に達すると、そのコンテナを異常とみなして再起動します^*3。死活監視の判定結果を、実際の切り替え・復旧アクションへつなげる代表例だといえるでしょう。

クラスタ管理ソフトウェアでは、ノードごとに稼働状態を持ち、信号の有無に応じて状態を切り替える設計が一般的です。コンテナの再起動にとどまらず、ノード自体を切り離して別のノードへ処理を寄せる、より広い範囲の切り替えを担う場合もあります。

3つの使いどころは、独立して使われることもあれば、同じシステムの中で層を分けて併用されることもあります。それぞれの使いどころで、何が信号を確かめ、途絶えたときに何が起こるのかを整理すると、次のとおりです。

いずれの使いどころも、「一定間隔で確かめる主体」と「途絶えたときに動くアクション」がセットになっている点は共通しています。どの層で死活監視を組み込むかによって、検知の速さや切り替えの粒度が変わってくるでしょう。

一定間隔の信号と閾値判定の仕組み

仕組みは単純です。送信側が、決めた間隔で信号を出し続けます。受信側は、信号が届くたびに時刻を記録し、次の信号が来るまでの経過時間を見張ります。

経過時間が設定したタイムアウトを超えたとき、あるいは連続で届かなかった回数が猶予回数（しきい値）を超えたとき、受信側はそのノードを「故障した」とみなすのです。この判定が、待機系への切り替えや、異常ノードを処理対象から外すといった動作の引き金になります。

図が示すとおり、ノードAは変わらぬ間隔で信号を送り続けます。ノードBは信号が来るたびに時計を測り直し、猶予回数ぶん届かなければ、その時点で故障と判断するのです。

信号そのものは、たいていごく小さなデータです。生死の確認だけが目的であれば、詳しい状態を運ぶ必要はなく、短い合図を高い頻度で送るほうが、通信の負荷を抑えながら検知を速められます。逆に、信号に付随する情報を増やすと、1回あたりの負荷は増し、間隔を詰めにくくなる面もあるのです。

目安として、間隔を5秒・猶予回数を3回に設定した場合、最短でも15秒程度は経過しないと故障とはみなされない計算になります。間隔や回数を変えれば、この最短時間も比例して変わるため、許容できる遅れから逆算して決める考え方が実務的でしょう。

監視の対象がプロセスか、ホストか、コンテナかによっても、確認の手段は変わってきます。プロセス同士なら軽い信号のやり取りで足りる一方、ホスト全体やコンテナの状態を見る場合は、CPUやメモリの状況もあわせて確認する構成が採られることもあります。

検知の判定は、切り替えの引き金になるだけでなく、運用担当者への通知トリガーとしても使われるのです。両方の役割を意識して間隔・猶予回数を決めることが大切です。

間隔と猶予回数の決め方は、検知の速さと誤検知の起こりやすさのバランスを左右します。両者の関係を整理すると、次の表のとおりです。

実務での既定値は、対象や用途によって異なります。AWSのApplication Load Balancerは間隔30秒・異常判定2回連続^*4です。Kubernetesのliveness probeは失敗3回連続^*3となっています。自社のシステムがどこまでの検知の遅れを許容できるかを起点に、間隔と猶予回数を決めるのが現実的な進め方です。既定値をそのまま使うのではなく、対象システムの特性に照らして見直す姿勢が要ります。

間隔や猶予回数の調整は、検知の速さを買う代わりに、何かを引き換えにする判断でもあります。その引き換えの中身こそが、次に見る誤検知という難所です。

誤検知という難所

誤検知は、ノードが実際には生きているのに、信号が届かなかったという理由だけで「故障した」と判定してしまう現象です。原因としてよくあるのが、高負荷によるCPU処理の詰まりと、ネットワークの一時的な瞬断でしょう。

CPU処理が詰まると、信号を送る処理そのものが後回しになり、猶予回数の範囲を超えて届かなくなることがあります。ネットワークが一時的に不安定になった場合も、信号自体は生成されていても、経路上で届かないという状況が起こり得ます。

この状態のまま切り替わってしまうと、起こるのがフェイルオーバーの空振りです。本来動いていたノードが処理対象から外され、切り替え先への負荷集中や、復旧後の切り戻し作業といった余分な手間につながるのです。

反対に、信号自体は届いていても、実際の処理が滞っているケースもあります。プロセスは生きていても、内部の処理が固まっていれば、利用者から見た異常は残ったままです。信号の有無だけでなく、実際の応答内容まで確認する仕組みをあわせて持つことが望まれます。

ネットワークが分断されると、双方の系がお互いを「落ちた」と見なし、双方が処理を引き継ごうとする状況に陥りかねません。

分散データベースの複製構成を例にとると、本来1系統だけのはずの書き込み担当（プライマリ）が、分断の間だけ両系統に生まれてしまう恐れがあります。双方が別々に書き込みを受け付ければ、あとでデータの食い違いを解消する作業が発生しかねません。

この種の混乱を避けるために、過半数の合意を取ってから切り替える仕組み（クォーラム）を、ハートビートによる死活監視と組み合わせる設計もよく採られます。信号の有無だけで即断せず、複数の観測結果を突き合わせる工夫が、誤検知の影響を抑える鍵になるでしょう。

単一の観測点だけに頼らず、複数の経路・複数のノードから同じ相手を見張る構成にしておくと、一つの経路に不具合が出ても、全体としての誤判定を防ぎやすくなります。監視そのものを冗長化する発想も、誤検知対策のひとつです。

送信側の間隔と、受信側が見るタイムアウトは、同じ長さで設計されるとは限りません。受信側のタイムアウトを送信間隔よりわずかに長く取り、送信タイミングのわずかなずれを吸収する調整も、実務ではよく行われます。

誤検知が起きた際に、何が原因だったのかを追えるよう、信号の送受信ログを残しておくことも実務上有効です。ログがあれば、間隔や猶予回数を見直す際の判断材料にもなります。

猶予回数やタイムアウトの調整は、誤検知を減らす一方で検知の遅れも招くため、システムの重要度に応じたバランスを見きわめることが欠かせません。

発注・レビューで押さえる点

ハートビートの仕組み自体を一から作り込む場面は少なく、多くは監視ツールやミドルウェア、クラウドサービスの設定を、要件に合わせて選ぶ形になります。発注やレビューの段階で確認しておきたい点を3つに整理しました。

どのくらいで故障とみなすか——検知までの許容時間を決める

顧客向けのAPIのように応答の即時性が問われるシステムでは、検知までの許容時間を短く設計する必要があります。一方でバッチ処理のように多少の遅れが業務に響きにくい系では、猶予回数を厚めにとり、誤検知を避ける設計のほうが向いているでしょう。この許容時間の設計方針を、開発会社との打ち合わせで具体的な秒数・回数として確認しておくことが大切です。

打ち合わせでは、少なくとも次の点を具体的な数値で確認しておきたいところです。

• 監視の間隔は何秒か、猶予回数（連続失敗の許容回数）は何回か
• 検知から実際の切り替え・再起動までに、追加でどれだけ時間がかかるか
• システムの重要度に応じて、許容時間を使い分けているか

同じシステムの中でも、機能ごとに許容時間を変えている例は珍しくありません。一律の設定で済ませず、機能単位で見直す視点を持っておくとよいでしょう。

誤検知が起きた場合の影響を洗い出す

誤検知でフェイルオーバーが空振りした場合、何が起こるのかを洗い出しておくことが欠かせません。処理の二重実行が起きないか、切り戻しにどの程度の作業が要るか、利用者への影響がどこまで及ぶか、といった観点です。

信号の有無だけで判定しているのか、実際の応答内容まで確認しているのかも、あわせて確認しておきたいところです。前者だけでは、処理が固まった状態を見逃す恐れがあります。

想定される影響が大きいシステムほど、誤検知を避ける設計への比重を高める判断が要るでしょう。こうした影響を洗い出したうえで、誤検知を避ける設計に寄せるか、検知の速さを優先するかを判断する流れになります。

監視の間隔と通知の設計を確認する

監視の間隔を細かくし過ぎると、通知が頻発し、確認する側が対応しきれなくなる恐れがあります。逆に間隔が粗ければ、異常への気づきそのものが遅れるでしょう。

どのレベルの異常で誰に通知するか、通知の粒度と経路をあわせて設計しておくと、運用の負荷を抑えられます。通知先が広すぎると重要な異常が埋もれてしまうため、対応者を絞り込む工夫も欠かせません。

監視・通知を運用する体制を明確にする

設計だけでなく、実際に通知を受け取り、対応する体制が整っているかも確認しておきたい点です。誰が一次対応に当たるか、休日・夜間はどう回すか、対応の切り分けをどこまで自動化するかによって、必要な体制の規模は変わってきます。

開発を委託する場合は、監視・通知の設計と、稼働後の一次対応をどこまで含めるかを、契約の範囲としてあらかじめすり合わせておくと、稼働後の認識違いを防げるでしょう。既定値の見直しや猶予回数の調整を、誰がどのタイミングで担うのかも、あわせて決めておきたいところです。

ここまでの3点に体制面の確認をあわせておくと、稼働後に想定外の対応へ追われる場面を減らせるでしょう。

まとめ

• ハートビートは、サーバーやプロセスが動いているかを一定間隔の信号で確かめる仕組みである。
• 送信側が信号を出し続け、受信側は経過時間や連続失敗の回数を見張り、しきい値を超えると故障とみなす。
• 間隔を短く・猶予回数を少なくすれば検知は速まるが、一時的な遅延も故障と誤判定しやすくなる。
• 高負荷やネットワークの瞬断による誤検知は、フェイルオーバーの空振りを招くため、猶予回数とタイムアウトの調整が欠かせない。
• 監視の主体はサーバー間・ロードバランサ・クラスタ管理ソフトウェアなど層によって異なり、組み合わせて使われることも珍しくない。
• サーバー間・LB・クラスタといった監視の層は、独立に設定するのではなく、全体設計として整合させておきたい。
• 誤検知をゼロにするのは難しく、猶予回数やタイムアウトの調整で許容範囲を管理する発想が実務的である。
• 発注時は、検知までの許容時間・誤検知時の影響・通知設計の3点を、開発会社との打ち合わせで具体的に確認するとよい。

よくある質問

設計や発注の場面でよく挙がる疑問を、4つにまとめました。

死活監視の間隔は、どのくらいに設定するのが一般的ですか。

対象や製品によって既定値は異なります。たとえばAWSのApplication Load Balancerは間隔30秒・異常判定2回連続^*4です。Kubernetesのliveness probeは失敗3回連続^*3を既定値としています。まずは既定値から始め、猶予回数とセットで、自社システムが許容できる遅れに合わせて調整するのが現実的です。

死活監視と、ロードバランサのヘルスチェックは同じ仕組みですか。

目的は近いものの、役割の重心が異なります。死活監視はノードが生きているかどうかを確かめること自体が主眼です。ロードバランサのヘルスチェックは、その確認結果を使ってアクセスの振り分け先を決める点に重心があります^*4*5。発注時にどちらの仕組みを指しているのか明確にしておくと、認識のずれを防げるでしょう。

一時的な不調による誤検知が起きると、どんな影響がありますか。

生きているノードが「故障した」と誤って判定され、不要な切り替え（フェイルオーバーの空振り）が起こります。切り替え先への負荷集中や、正常化後の切り戻し作業といった余分な手間が生じやすくなるのです。誤検知の頻度が高いシステムほど、猶予回数やタイムアウトの見直しが必要になります。誤検知が続く場合は、間隔や猶予回数の見直しに加え、ネットワーク経路の点検も有効でしょう。

死活監視の仕組みを導入するには、どんな準備が要りますか。

監視の間隔・猶予回数・通知先といった設計方針を、システムの特性に合わせて決める作業が必要です。あわせて、誤検知時に何が起こるかを洗い出し、開発会社と認識をそろえておくことも欠かせません。既存のクラウドサービスやミドルウェアの機能を使う場合は、まず既定値を確認するところから始めるとよいでしょう。具体的な費用や体制は、導入する監視ツールの規模によって変わるため、要件整理の段階で詰めていくことになります。

著者：テレリモ総研編集部　鈴木 亮佑

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

出典

• Wikipedia日本語版「ハートビート」
• Wikipedia英語版「Heartbeat (computing)」
• Kubernetes公式ドキュメント「Configure Liveness, Readiness and Startup Probes」
• AWS公式ドキュメント「Health checks for your target groups」
• Google Cloud公式ドキュメント「Health check concepts」