🚀 [Istio] サーキットブレーカー vs K8s Readiness Probe: 完璧なMSAのための二重防御壁

—

こんにちは！今日は、マイクロサービスアーキテクチャ（MSA）を運用している多くの方が一度は首をかしげるテーマを持ってきました。

「Istioのサーキットブレーカー（Circuit Breaker）は、KubernetesのReadiness Probeと同じじゃないですか？どちらも問題のあるPodにトラフィックを送らないようにするんですよね？」

結論から言うと、「結果は似ていますが、過程と目的は全く異なります！」 🙅‍♂️

この二つの技術がどのように異なり、なぜ実務では両方を使用しなければ「無停止サービス」というユニコーン🦄を捕まえられないのか、詳しく掘り下げていきます。

その通りです。ご質問の通り、「問題のあるものに仕事をさせない（トラフィック遮断）」という結果論的な観点では、二つの機能は同じです。

しかし、「誰が」「いつ」「どのように」問題を判断するかで決定的な違いが生じます。

KubernetesのReadiness Probe（準備性プローブ）は、能動的（Active）なヘルスチェック方式です。

動作原理: ノードのエージェントであるkubeletが、決められた時間ごとにPodに尋ねます。「生きている？リクエストを受けられる？」(/healthz呼び出し)
特徴: トラフィックがあろうとなかろうと、絶えず検査します。
主な目的: アプリケーションが起動中（Startup）であったり、設定ファイルのロードなどでまだトラフィックを受け取る準備ができていない状態をフィルタリングするためです。

例えるなら？ 医師の先生が定期的に回診し、患者の体温と血圧を測るようなものです。「熱があるね？今日は休んでください。」と診断を下すわけです。

Istioのサーキットブレーカー（正確にはOutlier Detection）は、受動的（Passive）な検知方式です。

動作原理: サイドカープロキシであるEnvoyが、実際のユーザーのトラフィックが通過する場所で見張っています。普段は静かにしていますが、実際のエラー（5xx）が発生したり、応答が遅くなったりすると、その時に介入します。
特徴: トラフィックがなければPodが故障しているかどうかは分かりません。その代わり、実際の運用中に発生する「本当の問題」をリアルタイムで捉えます。
主な目的: 急な負荷による応答遅延、DBコネクションプールの枯渇など、実際のサービス品質低下を防ぎ、障害の伝播を遮断するためです。

例えるなら？サッカーの試合審判と同じです。選手がじっと立っているときは何も言いませんが、試合中に反則（エラー）をしたり、空振りしたりすると、すぐにホイッスルを吹いて「君、退場（Ejection）！」させるようなものです。

この表一つで面接の質問も完璧に準備できます！ 😉


比較項目	K8s Readiness Probe	Istio Circuit Breaker

—	—	—
検知方式	Active（能動的）定期的にプローブ	Passive（受動的）実際のエラー発生時に検知
検知主体	kubelet（インフラレベル）	Envoy Proxy（ネットワーク/アプリレベル）
判断基準	開発者が作成したAPI応答（OK/Fail）	実際のトラフィックのHTTP 5xx、Latency
措置方法	Serviceエンドポイントリストから削除	Envoyロードバランシングプールから除外（Ejection）
死角	アプリは起動しているが機能が故障している場合の検知が困難	トラフィックがないと故障していることが分からない

「一つだけうまく使えばいいんじゃないか？」と思われるかもしれませんが、実務では相互補完的な関係のため、両方が必須です。

あるPodのTomcatは元気に動いているのに、内部のDB Connection Poolが満杯で、DBクエリを投げるとエラーになる状況を仮定してみましょう。

この二つが合わさって初めて、「準備できたPodだけを投入し、問題が発生したらすぐに取り除く」という鉄壁の無停止システムが完成します。

あなたのKubernetesクラスターには、これら二つの安全装置がすべて適切に設定されていますか？今すぐYAMLファイルを確認してみてください！ 🧐

Comments