再起動したコンテナは、業務も復旧したのか

架空事例：青葉機材が予約・帳票サービスをコンテナで運用する。容量、配置、故障、判断は独自の例であり、実際のクラスタの検証結果ではない。資源制御の具体例はLinux上のKubernetesを対象とし、すべてのコンテナ環境へ同じ設定や挙動を要求しない。

管理画面の緑色が戻った

帳票を作っていたコンテナが停止した。自動的に再起動され、監視画面は正常へ戻った。ところが、営業の端末には、いつまで待っても帳票が届かない。

処理途中の依頼一覧を、そのプロセスのメモリにしか置いていなかったのである。新しいプロセスは正しく起動したが、何を再開すればよいかを知らなかった。

実行環境の回復と、業務の回復は違う。

原教材第16章のオーケストレーションは、配置、起動、監視などを扱う。予約の受付をどこに確定し、どの仕事を再処理してよいかまで自動的に決めるものではない。1 再起動を採用するなら、再起動しても必要な仕事が失われない構造を別に用意する。

仮想化する対象を、混ぜて覚えない

典型的な仮想マシンは、仮想的なハードウェアの上でゲストOSを動かす。OSレベルのコンテナは、ホストのカーネルを共有しながら、プロセスや資源の見え方を分ける。1 何を共有するかが違うので、起動時間や運用の負担、隔離の前提も変わる。

一方、マイクロサービスは、業務や変更の責務をどう分けるかというアーキテクチャの考え方である。コンテナへ入れれば、巨大な一つのアプリケーションが自動的に独立した業務サービスへ分かれるわけではない。

青葉機材が、予約と帳票を別々に増減させたいなら、その実行単位を分ける案を検討できる。しかし、一つの共有DBへすべての処理を集中させたままなら、実行単位の独立性だけではDBの競合は消えない。分けた場所と、共有したままの場所を同時に見る。

イメージは、現在の業務状態ではない

コンテナイメージは、アプリケーションを配布・起動するための内容をまとめる単位である。実行中の予約データや、外部へ送信済みの通知と同じものではない。1

本事例で同じイメージから起動し直しても、前のプロセスのメモリにあった帳票依頼は復元できない。逆に、イメージに入っていない外部DBの設定が変わっていれば、同じアプリケーションでも振る舞いは変わる。再現したい環境には、実行設定や接続先も含めて考える必要がある。

青葉機材は、受付を確定した依頼を、処理プロセスの外に残す。再開する側は、未完了の依頼を識別し、既に保存した帳票や通知と照合する。このとき、送信済み通知を再び送るなどの副作用を、再起動の仕組みだけで取り消すことはできない。

第2・3巻の冪等性や整合性は、業務APIだけでなく、停止後に同じ仕事をやり直す場面にも必要になる。

配置できることと、最大まで使えること

Kubernetesのrequestsは、Podの配置を決める際などに使う資源要求である。limitsは、実行時に使う資源の制限に関わる。利用可能な資源があれば、コンテナがrequestsを超えて使える場合もある。2

説明を単純にし、Podへ割り当て可能な資源をCPU四単位・メモリ8GiBとする。他の制約や追加のオーバーヘッドを除き、一つのPodに一つのコンテナがあり、そのrequestsがCPU一単位・メモリ2GiBなら、要求量の計算では四つが収まる。

各コンテナのメモリlimitsを3GiBにしても、四つが同時に3GiBずつ使える物理メモリが生まれるわけではない。上限の合計は12GiBであり、8GiBとは別の量である。配置時に要求した量と、実際のピーク使用量の違いを考える必要がある。

青葉機材で帳票の同時生成が増えると、各処理が扱う画像や明細の量も増えるとする。requestsを小さく記述して配置しやすくしただけでは、実際のメモリ消費は減らない。入力規模、同時実行数、失敗時の再処理を含む条件で容量を判断する。

CPUの制限と、メモリ不足では止まり方が違う

Linux上のKubernetesでは、CPU limitsによる制御はCPU時間の抑制に関係し、メモリ制限を超える割当てはOOMによるプロセス終了につながり得る。両者は、同じ「制限値」を指定しても実行への影響が異なる。2

メモリ超過は、必ず指定した一バイト目で即座に終了するという単純な仕組みとして扱わない。カーネルの検出や回収、設定の条件が関係する。一方、CPUの使用を抑えられた結果、処理が遅くなって応答期限を超えることもある。

本事例では、コンテナの再起動回数だけでなく、その理由を区別する。処理の欠陥で終了したのか、資源を使い過ぎたのか、監視の判断で停止されたのかによって、必要な修正が違うからだ。再起動ができることを、原因を調べなくてよい理由にしない。

起動した、受け付けられる、やり直すべき

帳票サービスは、起動後に必要な辞書と設定を読み込む。その間、プロセスは存在しているが、まだ要求へ答えられない。Kubernetesのstartup・readiness・livenessは、こうした異なる問いを扱う。3

startup probeを設定した場合、その成功までlivenessとreadinessの検査を開始しない。livenessの失敗が設定した許容回数を超えると、コンテナの再起動につながる。readinessは、通常のServiceの転送先として受け付けられる状態かを示す側の判断であり、その失敗自体を再起動の命令と同一視しない。3

青葉機材が、初期化中の遅い応答を即座にlivenessの失敗として扱えば、準備が終わる前に繰り返し停止させてしまう。起動に時間がかかることと、起動後に前進できなくなったことを分ける必要がある。

ただし、readinessが成功しているから、任意の予約が必ず業務上成功するわけではない。点検条件や在庫など、各要求の結果は別に判断される。ヘルスチェックは、すべての業務ルールの合格証明ではない。

外部DBが止まったのに、自分を再起動する

予約DBへの接続が途切れるたびに、アプリケーションを停止して起動し直すようにした。DBはまだ復旧していないため、再起動後も接続できない。しかも、残った処理へ要求が集まり、再接続も増えた。

本事例で解決すべき原因は、アプリケーション内の行き詰まりとは限らない。自分の再起動によって回復する状態と、依存先が回復するまで要求を保留・拒否する状態を分ける。Kubernetesの公式文書も、不適切なlivenessの設計が障害の連鎖を生む危険を示している。3

青葉機材では、DBを必要とする予約の受付と、独立して返せる説明画面をどう扱うかを検討する。全機能を一つの可否判定へまとめるなら、止める範囲が広くなる。逆に、実際にはDBが不可欠なのに受入可能と表示し続ければ、失敗する要求を流し込むだけになる。

何を再起動し、何を受付停止し、何を継続するか。監視の種類を選ぶ前に、提供したい機能の境界を定める。

ディレクトリがあるだけでは、寿命は分からない

KubernetesのemptyDirへ帳票を保存すると、同じPod内のコンテナが停止・再起動した場合には内容を保持できる。しかし、Podがノードから取り除かれると、そのemptyDirのデータは失われる。4

したがって、一回のコンテナ再起動でファイルが残ったという確認から、別ノードへ作り直した場合にも残ると結論してはいけない。何が終わるまで保存される領域かを、使うボリュームの契約から読む。

PersistentVolumeは、個々のPodとは独立したライフサイクルを持つ保存資源として扱われる。ただし、利用を終えた後の保持・削除はreclaim policyなどに依存する。5 persistentという名前は、誰がどんな削除操作をしても永遠に残るという意味ではない。

青葉機材では、生成途中の一時ファイルと、顧客へ交付した確定帳票を分ける。前者は依頼の記録から作り直せるなら短い寿命でもよい。後者は必要な保存期間、バックアップ、復元手順を別に定める。ボリュームを付けたことと、誤削除から回復できることも同じではない。

二つの実行単位と、二つの故障領域

予約サービスを二つ起動した。しかし、両方が同じホストに置かれているなら、そのホストを失うと両方を失う可能性がある。別ホストでも、同じ電源や記憶装置に依存すれば、共通原因は残る。

第4巻で計算した冗長化の独立性を、実行単位の数だけで満たしたと判断しない。1 本事例では、故障時にどこへ配置し直せるか、必要なデータへ接続できるか、残る側の容量で処理を続けられるかを確認する。

平常時の資源を余さず使う構成は効率的に見える。しかし、障害後に受け持つ場所がなければ、再配置を指示できても業務は戻らない。復旧時間には、障害検出、配置、必要なデータや設定の準備、アプリケーションが受け付けられるまでの時間が入る。単にコンテナの起動時間だけを測らない。

クラウドを選ぶことと、管理を手放すこと

NIST SP 800-145は、クラウドを、共有された構成可能な資源をネットワーク越しに必要に応じて利用するモデルとして整理する。6 一台のコンピュータを仮想化する技術と、資源やサービスをどのように提供・利用するかは別の軸である。

原教材第16章の区別では、IaaSは基盤資源、PaaSはアプリケーションを動かす基盤、SaaSはアプリケーション機能を利用する側へ重点が移る。1 ただし、具体的な管理範囲はサービスの契約と機能で確認する。名称だけで、どの設定も変更も提供者が引き受けると決めない。

青葉機材が予約DBの運用を外部サービスへ任せても、誰のデータをどこまで見せるか、どの時点までの復旧を必要とするか、業務上どの情報を保存するかは残る。アプリケーションの誤更新も、設備の保守を任せたことだけでは消えない。

また、使用量が測定されることから、どんな負荷でも自社運用より安くなるとは導けない。通常時とピーク時、通信、保存、保守作業を含む条件で比較する。自動化の価値は、判断しなくてよくなることではなく、決めた運用を少ない手作業で実行できる範囲を広げることにある。

知識を答案へ戻す

午前Ⅱ。 VM・コンテナ・マイクロサービス・クラウドの分類を混ぜない。資源の要求と上限、起動・受入れ・再起動、Podと保存領域の寿命を区別する。製品固有の設定名は、対応する概念を理解するための例として読む。

午後Ⅰ。 再起動後に失われる状態、同じホストへの集中、依存先の停止、復旧時の容量を本文から特定する。管理基盤があることを、業務の継続性の証明にしない。

午後Ⅱ。 自動化へ任せた範囲と、業務側に残した責任を示す。再処理、データ保持、受付制御、障害後の能力をどう確かめたかを説明し、配置・起動の成功と業務復旧の完了を分ける。

立ち止まって考える：コンテナが自動で再起動し、ヘルスチェックも通った。受付済みの依頼はすべて回復したか

プロセスが起動し、検査した条件を満たしたことまでしか分からない。受付済みの依頼が保存されているか、処理済みの副作用と照合できるか、未完了分を正しく再開できるかを別に確かめる必要がある。

出典と照合範囲

[1] コンプリートテキスト第7・13・15・16章、IPA「SAシラバス Ver.5.2」4-7、4-10、4-12、5-5、8-4、16-2、16-3：仮想化、クラウド、再試行、冗長化、保存と復旧を出発点とした。青葉機材の構成と責任の分担は独自の例である。仮定した要求量・上限・物理容量の算術はPythonで確認した。公式シラバス

[2] Kubernetes, Resource Management for Pods and Containers：requestsとlimits、配置と実行時制御、LinuxでのCPU・メモリ制限を公開文書へ照合した。Podレベルの指定、特殊な資源、機能ゲートの全組合せは扱っていない。四Podの例は追加条件を除いた独自の計算で、実クラスタでの配置試験ではない。公式文書

[3] Kubernetes, Liveness, Readiness, and Startup Probes：三種類の目的と、不適切なlivenessによる障害連鎖の注意を参照した。検査周期やしきい値を一律に推奨せず、特別な転送設定を用いない作例として説明した。公式文書

[4] Kubernetes, Volumes, emptyDir：コンテナの停止とPodの除去で保存の扱いが異なる点を参照した。すべてのボリュームがemptyDirと同じ寿命だとはしていない。公式文書

[5] Kubernetes, Persistent Volumes, Introduction・Reclaiming：Podから独立したライフサイクルと、利用終了後の保持・削除の方針を参照した。基盤装置の無故障やバックアップを保証する用語として扱っていない。公式文書

[6] NIST SP 800-145, The NIST Definition of Cloud Computing（2011）：公開概要にあるクラウドの位置付けを参照した。現在の特定サービスの料金や契約条件を同資料から推測していない。NIST公開記録

Kubernetesの説明は2026年10月19日に参照した英語公式文書の範囲である。本章は操作手順書ではなく、特定環境の実行検証や全バージョンへの適用確認を行ったものではない。