コンテナの「正体」を暴く：OCI仕様と低レイヤランタイムが支える静かな革命
こんにちは。クラウドインフラの深淵を覗き続けて十数年、パケットの微かな揺らぎから障害の予兆を読み取るSREの端くれです。
「Dockerを使えばコンテナが動く」というのは、もはや現代のエンジニアにとって呼吸をするような当たり前の事実でしょう。しかし、本番環境で突然起動しなくなったコンテナ、あるいは特定ノードでだけ発生する謎のパフォーマンス劣化……そんな泥臭いトラブルに直面したとき、「コンテナがOS上で具体的に何をしているのか」を知っているかどうかで、復旧までの時間が劇的に変わります。
今日は、コンテナ技術の「心臓部」であるOCI（Open Container Initiative）標準と、それを物理的に実行する runc や crun といった低レイヤランタイムの正体に迫ります。
—
1. コンテナの本質：OCIは「共通言語」である
かつてコンテナ界隈は、Docker一強の時代から、ランタイムの乱立による混沌の時代を迎えました。そこで、「どのコンテナエンジンでも動かせるようにしよう」と策定されたのが OCI（Open Container Initiative） です。
OCIには主に2つの仕様があります。
1. Image Specification: コンテナイメージの構造（レイヤの重ね方、JSON形式のマニフェストなど）
2. Runtime Specification: コンテナの実行方法（ファイルシステム、環境変数、プロセス監視など）
これがあるおかげで、我々は docker build で作ったイメージを、Kubernetesの containerd で動かし、最後は runc で実行するという、ベンダーを跨いだエコシステムを享受できているわけです。
—
2. ランタイムの役割：runc と crun の実務的な違い
OCIランタイムの役割は、非常にシンプルかつ強烈です。「指定された config.json を読み込み、Linuxの namespaces と cgroups を操作してプロセスを隔離し、コンテナを起動する」こと。
runc: Go言語で書かれた、いわば業界のデファクトスタンダード。安定性は抜群ですが、Goのランタイムオーバーヘッドがわずかに存在します。crun: C言語で書かれた新鋭。メモリフットプリントが極めて小さく、起動速度が爆速です。特に大規模クラスタで数千個のコンテナを短時間で立ち上げるような環境（サーバーレス系など）では、crunの採用がスタンダードになりつつあります。
—
3. 手を動かして「コンテナ」の正体を見る
「コンテナは単なるプロセスである」という事実を、実際に確認してみましょう。OCIランタイムが読み込む config.json の断片は、以下のような構造をしています。
{
"ociVersion": "1.0.2",
"process": {
"terminal": true,
"user": { "uid": 0, "gid": 0 },
"args": ["/bin/sh"], // コンテナ起動時に実行するバイナリ
"env": ["PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"]
},
"linux": {
"resources": {
"memory": { "limit": 1073741824 } // 1GBにメモリ制限をかける
},
"namespaces": [ // ここでプロセスを隔離している
{"type": "pid"},
{"type": "network"},
{"type": "mount"}
]
}
}この設定ファイルを使い、実際に runc でコンテナを起動するフローは以下のようになります。
# 1. コンテナのルートファイルシステムを展開
mkdir rootfs
docker export $(docker create alpine) | tar -C rootfs -x
# 2. config.jsonの雛形を作成
runc spec
# 3. コンテナを起動（デバッグ時はこのコマンドが非常に役に立ちます）
sudo runc run my-container-idrunc run を実行した瞬間、OSのカーネルに対して clone() システムコールが発行され、namespaces でプロセスが隔離され、cgroups でリソースが制御されます。Web APIを叩く際、裏側でこうした「プロセスの檻」が瞬時に構築されていると想像してください。
—
4. SRE的視点：トラブルシューティングの勘所
現場でよくあるのは、「コンテナが OOMKilled されるが、なぜ落ちたかわからない」というケースです。これは cgroups の設定値と、アプリケーションのメモリ確保ロジックが乖離している証拠です。
Pythonのアプリケーションでメモリリークを疑う際、cgroups の制限値を確認するには、コンテナ内から /sys/fs/cgroup/memory/memory.limit_in_bytes を見るのが一番の近道です。
# コンテナ内のメモリ制限を確認するスクリプト例
def check_container_memory_limit():
try:
with open("/sys/fs/cgroup/memory/memory.limit_in_bytes", "r") as f:
limit = int(f.read().strip())
print(f"現在のメモリ制限は: {limit / 1024 / 1024 / 1024:.2f} GB です")
except FileNotFoundError:
print("cgroup v2環境か、制限が設定されていません")
check_container_memory_limit()—
最後に：ブラックボックスを紐解く勇気
クラウドネイティブな開発において、抽象化層は非常に便利です。しかし、高レイヤーのAPIやKubernetesのYAMLに頼り切りになると、本当のボトルネックが見えなくなります。
「OCI標準に基づき、このランタイムはどの namespace を操作しているのか？」「cgroups の階層構造はどうなっているのか？」
こうした低レイヤの挙動に思いを馳せるだけで、あなたのインフラ運用能力は間違いなく一段階上がります。次回のトラブルシューティングでは、ぜひ runc や crun のログ、あるいは /sys/fs/cgroup の中身を覗いてみてください。そこには、教科書には載っていない「リアルな挙動」が必ず刻まれています。
それでは、また次回の深掘りでお会いしましょう。現場からは以上です。
コメント