LASSIC Media らしくメディア

クラウドでコンテナやサーバーを動かす仕組みでは、アプリが「いま依頼を受けられる状態か」「ちゃんと生きているか」を、基盤側が絶えず確かめています。この確認に使うのがヘルスチェックです。ところが、この設定を疎かにすると、起動しきっていないアプリに依頼が流れてエラーになったり、逆に一時的な不調で健全なコンテナが次々と再起動され、かえってサービスが不安定になったりします。

ヘルスチェックは、正しく設計すれば入れ替えや障害の際に取りこぼしを防ぐ頼もしい仕組みですが、誤って設定すると事故のもとにもなります。しかも「死活監視」と混同されがちで、担う役割は別物です。本記事では、クラウドでシステムを運用する情報システム部門や開発担当者に向けて、ヘルスチェックとは何か、死活監視との違い、3種類のプローブの使い分け、そして実装や外注の勘所を整理します。

ヘルスチェックとは——死活監視との違い

ヘルスチェックとは、アプリが自分の状態を決められた形で申告し、その結果をもとに基盤側が自動で判断・行動する仕組みを指します。たとえば「まだ依頼を受けられません」と申告すれば、負荷を振り分ける側は依頼を送らずに待つ仕組みです。「反応がなくなりました」と分かれば、そのコンテナを作り直します。人が見張るのではなく、基盤が自動でさばく点が特徴です。よく似た言葉と並べると、役割の違いがはっきりします。

ハートビートによる死活監視は、外側から対象が生きているかを定期的に確かめ、異常があれば人に知らせたり記録に残したりする取り組みです。いわば「外から見て気づく」仕組みです。これに対してヘルスチェックは、アプリ自身が状態を申告し、その申告を受けた基盤が自動で対処するところまでを含みます。誰かに知らせて終わりではなく、依頼の振り分けや再起動といった行動に直結する点が異なります。

外から見て気づく監視でも、単なる生死の確認でもなく、アプリの申告をもとに基盤が自動で動く——ここに違いがあります。負荷を振り分けるロードバランサは、この申告を見て、準備のできたところにだけ依頼を回す仕組みです。自社が整えたいのが、異常に気づく監視なのか、それとも基盤に自動で対処させる申告の設計なのかを見極めておくと、取り組みの範囲を絞りやすくなります。

なぜ2種類（readinessとliveness）が要るのか

ヘルスチェックには目的の異なる2つの問いがあります。一つは「いま依頼を受けられるか（readiness）」、もう一つは「そもそも生きているか（liveness）」です。この2つを分けずに一緒くたにすると、思わぬ事故が起こります。

たとえば、起動直後でまだ準備が整っていないアプリを考えてみます。この状態は「依頼を受けられない（readinessは不合格）」ですが、「アプリ自体は生きている（livenessは合格）」のが正しい姿です。ここを一緒にしてしまうと、準備中というだけで再起動がかかり、いつまでも立ち上がらない事態になりかねません。逆に、内部で処理が固まって反応しなくなったときは、readinessだけでなくlivenessも不合格とし、作り直す必要があります。つまり、依頼を送るかどうかの判断（readiness）と、作り直すかどうかの判断（liveness）は、別々に扱うべきものです。両者を切り分けることで、準備中は依頼を止めつつ待ち、本当に壊れたときだけ作り直す、という自然な振る舞いが実現します。

3つのプローブでやること

多くの基盤では、ヘルスチェックを3つのプローブとして設定します。それぞれ役割と、失敗したときの行動が異なります。自社のアプリでどこまで設定できているかと照らし合わせてみてください。

一つ目は、readinessプローブです。アプリが依頼を受けられる状態かを確かめ、不合格の間は振り分け先から外して依頼を送らないようにします。再起動はしません。二つ目は、livenessプローブです。アプリが固まっていないかを確かめ、不合格が続けばコンテナを作り直します。三つ目は、startupプローブです。起動に時間のかかるアプリで使うもので、起動が完了するまでlivenessの判定を待たせ、立ち上がりきる前に再起動がかかるのを防ぎます。いずれのプローブも、どれくらいの間隔で確かめるか、何回続けて失敗したら行動するか、応答をどれだけ待つかといった値を、アプリの実態に合わせて決めます。この関係を図にすると次のとおりです。

つまずきやすい難所

ヘルスチェックを設計するうえで、あらかじめ想定しておきたい難所がいくつかあります。着手前に押さえておくと、かえって不安定にする設定を避けやすくなります。

一つ目は、livenessで見る対象の広げすぎです。生きているかを確かめるはずのlivenessで、データベースなど外部の依存先の状態まで見てしまうと、依存先が一時的に不調になっただけで、健全なコンテナまで次々と再起動され、全体が再起動ループに陥ります。livenessは自分自身が固まっていないかに絞り、依存先の状態はreadinessで扱うのが基本です。二つ目は、しきい値の甘さや厳しさです。失敗と判定するまでの回数や待ち時間が短すぎると、一瞬の遅れで作り直しがかかります。長すぎると、壊れたまま依頼が流れ続けます。三つ目は、確認する内容の重さです。プローブのたびに重い処理を走らせると、確認そのものが負荷になります。四つ目は、起動の遅いアプリへの配慮です。startupプローブを使わずにlivenessだけにすると、立ち上がりに時間のかかるアプリが、起動しきる前に作り直され続けてしまいます。

プローブの使い分け早見表

3つのプローブは、目的と失敗時の行動、そして見るべき対象が異なります。設計の出発点として整理しました。

見るべき対象も分けて考えます。readinessは、依頼をさばくのに必要な準備（依存先への接続など）まで含めてよい一方、livenessは自分自身が固まっていないかに絞ります。この線引きが、再起動ループを防ぐ勘所です。まずは各プローブに簡単な確認用のエンドポイントを用意し、運用しながら間隔やしきい値を実態に合わせていくとよいでしょう。

外注時に確認しておきたい点

ヘルスチェックの設計や実装を外部に委託する場合は、次の点を事前にすり合わせておくと、認識のずれを防ぎやすくなります。まず、対象とするアプリと、動かしている基盤です。どんな仕組みの上で動くのか、起動にどれくらい時間がかかるのかによって、必要なプローブや値が変わります。次に、それぞれのプローブで何を確かめるか。とくにlivenessで依存先まで見ないという線引きは、事故を防ぐうえで欠かせないため、はっきりさせておきたいところです。

さらに、確認の間隔やしきい値、応答を待つ時間の初期値と、運用しながら見直す進め方も、あらかじめ決めておきたいところです。ヘルスチェックは、アプリの起動時間や処理の内容が変われば見直しが要ります。あわせて、止めるときに依頼を取りこぼさないよう、graceful shutdown（正常終了）と組み合わせて設計してもらえるかも確認しておくと、入れ替え時の取りこぼしを抑えられるのも利点です。実装だけを頼むのか、動作の確認や見直しまで含めるのかを明確にしておくと、任せたあとのつまずきを抑えやすくなります。

まとめ：ヘルスチェックで押さえる3つの視点

ヘルスチェックは、外から気づく死活監視とは役割の異なる、「アプリの申告をもとに基盤が自動で対処する」仕組みです。検討するうえで押さえたい視点は3つに整理できます。第一に、死活監視とヘルスチェックを切り分け、気づくための監視なのか、自動で対処させる申告なのかを見極めること。第二に、readiness（依頼を受けられるか）とliveness（生きているか）は目的が異なると踏まえ、見る対象を分けて設計すること。第三に、livenessで依存先まで見ないという線引きを守り、間隔やしきい値をアプリの実態に合わせて調整することです。この3点を踏まえておけば、「一時的な不調で健全なコンテナまで再起動ループに陥る」という事故を避けやすくなります。自社だけで設計しきるのが難しいと感じたら、基盤に合わせたプローブの設計から外部の手を借りるのも一つの選択肢です。

よくある質問

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

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

1. *1　出典：Kubernetes公式ドキュメント「Liveness, Readiness and Startup Probes」（https://kubernetes.io/docs/concepts/configuration/liveness-readiness-startup-probes/）

Tweet