# セルフヒーリング ## 定義 セルフヒーリング(self-healing)は、システムが障害や異常を検知し、自動的に回復してサービス継続性を保つ能力である。コンテナオーケストレーションでは、Kubernetes が Pod の障害を検知して自動再起動する仕組みが代表的である。従来の再起動は状態を失うコールドスタートを伴うが、CANDARW 2025 はランタイム中立チェックポイントを用いたホットリスタートにより、状態を保持したままの回復を実現する。 ## 横断的知見 - **単純な再起動に代わり、チェックポイントからのホットリスタートと動的ランタイム切り替えにより、障害回復とリソース制約緩和を統合できる**: CANDARW 2025 は、コンテナ障害時にはホットリスタートで状態を保持し、メモリ圧力時には軽量ランタイムへ切り替えることで、Pod 退避を伴わない新しいセルフヒーリングパラダイムを提示している。これは、従来の「障害が起きたら再起動する」モデルから「状態を保持しつつ最適なランタイムへ適応する」モデルへの転換を示唆する。(Source: [[@2025__CANDARW__Seamless Self-Healing in WebAssembly Container Orchestration with Runtime-Neutral Checkpointing]]) - **ストレージ領域のセルフヒーリングは、コンテナ領域の「状態保持」とは異なる軸——「段階的な不可逆判定」——で完全自動化を実現しており、両者は「人間の介入なしに何を保存し何を切り捨てるか」という共通の設計問題への異なる答えになっている**: [[@2021__OReillyJapan__SREの探求 - Chapter 17 データ耐久性のエンジニアリング]] が示す Dropbox の自動ディスク修復ワークフローは、不良セクタ検出→(x回の障害で)不良ファイルシステムと判断しディスクを再フォーマット→(y回の障害で)ディスク自体を不良と判定し物理リプレースのチケットを発行、という段階的にエスカレートする不可逆判定プロセスであり、各段階でデータは既に別コピーから再構築・再レプリケートされた上で当該ハードウェアを切り捨てる。CANDARW 2025 のセルフヒーリングが「状態を保持しつつ最適なランタイムへ適応する」ことを主眼とするのに対し、Dropbox の自動修復は「データの状態(コンテンツ)は他ノードとの冗長性によって常に保持し、ハードウェア(器)側だけを不可逆に切り捨てる」という設計であり、両者は「何を保持し、何を交換可能とみなすか」の境界線をコンテナ領域とストレージ領域でそれぞれ異なる場所に引いている。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 17 データ耐久性のエンジニアリング]] §17.6.3) - **「人間はディスクの物理的な取り出し時点まで一切介入しない」という Dropbox の不変条件は、CANDARW が未解決の問いとして残す「自動性と人間承認の境界」への1つの実例的回答になる**: 本ページが既に記録する未解決の問い(セルフヒーリングの自動性と人間による承認の境界はどこに置くべきか)に対し、[[@2021__OReillyJapan__SREの探求 - Chapter 17 データ耐久性のエンジニアリング]] は「重要なプロダクションデータを保持しているディスクに運用者が手を出すことは決して許されない」という不変条件を明示し、人間の介入点を物理的なハードウェア交換という最終段階のみに限定する具体的な設計を提示する。これはコンテナ領域の CANDARW が扱わない「境界をどこに置くか」の実例であり、境界設計の判断基準(データが別コピーから完全に再構築・再レプリケートされたことが保証された後にのみ、当該ハードウェアへの人間の関与を許可する)を横断的に示す。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 17 データ耐久性のエンジニアリング]] §17.6.3) - **「セルフヒーリング」という語自体は 2003 年の自律コンピューティングのビジョン論文で自己管理の 4 側面の一つとして定義され、当時から「局所化されたソフトウェア・ハードウェア問題の自動検知・診断・修復」という定義だった**: [[@2003__Computer__The Vision of Autonomic Computing]] は、ベイジアンネットワークなどに基づく問題診断コンポーネントがログファイルを分析し、既知のパッチと照合して適用・再テストする、という定義を示している。この定義は「問題を検知→診断→自動的に修復アクションを実行」という 3 段階構造を持ち、CANDARW 2025 のホットリスタート(検知→ランタイム切り替えという修復アクション)や Dropbox の自動ディスク修復(検知→段階的エスカレーションという修復アクション)は、いずれもこの 3 段階構造の異なる実装と位置づけられる。原論文が「診断」を明示的に修復の前段として位置づけている点は、CANDARW 2025 のようにチェックポイントから即座に切り替える設計(診断を経ない機械的なフェイルオーバー)との対比として興味深い——原論文の想定するセルフヒーリングは根本原因の特定を伴うが、現代の実装は診断を省略して回復速度を優先する傾向があるとも読める。(Source: [[@2003__Computer__The Vision of Autonomic Computing]]) ## 未解決の問い - 状態を保持したセルフヒーリングと、意図的な状態リセット(障害ループ脱出など)の使い分けはどう設計すべきか。 - セルフヒーリングの自動性と人間による承認の境界はどこに置くべきか。 - 大規模分散システムでのホットリスタートと従来の障害隔離・シャットダウン戦略はどう組み合わせるか。 - セルフヒーリングの効果を測定する指標(可用性、回復時間、データ損失、ユーザー影響)はどう定義すべきか。 - Dropbox の自動ディスク修復ワークフローのような「段階的エスカレーション+不可逆判定」パターンは、コンテナオーケストレーションのセルフヒーリング(CANDARW のホットリスタート/動的ランタイム切り替え)にどこまで一般化できるか。コンテナには「物理交換」に相当する最終段階がないため、同じ設計原理がどう変形されるかは未検証。 ## 関連 - 概念: [[ランタイム中立チェックポイント]] / [[ホットリスタート]] / [[動的ランタイム切り替え]] / [[コンテナオーケストレーション]] / [[データ耐久性]] / [[ハードディスク信頼性]] / [[自律コンピューティング]] - エンティティ: [[Kubernetes]] / [[WasmEdge]] / [[WAMR]] / [[James Cowling]] / [[Dropbox]] / [[Jeffrey O. Kephart]] / [[David M. Chess]] - ソース: [[@2025__CANDARW__Seamless Self-Healing in WebAssembly Container Orchestration with Runtime-Neutral Checkpointing]] / [[@2021__OReillyJapan__SREの探求 - Chapter 17 データ耐久性のエンジニアリング]](自動ディスク修復ワークフロー、§17.6.3)/ [[@2003__Computer__The Vision of Autonomic Computing]](セルフヒーリングの初出定義) - 関連 MOC: [[SRE - MOC]] / [[System Engineering - MOC]]