QCOW2の「魔法」を紐解く：なぜスナップショットは一瞬で終わるのか？
クラウドインフラの現場で「VMをクローンした瞬間、数GBのデータがコピーされたはずなのに一瞬で完了した」と不思議に思ったことはありませんか？その舞台裏で静かに仕事をしているのが、QEMU/KVMの標準フォーマットである QCOW2 です。
単なる「ディスクの保存形式」だと思っていると、本番環境でのパフォーマンス劣化や、思わぬディスク枯渇事故で痛い目を見ます。今日は、SREの視点からQCOW2の「Copy-on-Write」の挙動と、現場で役立つ運用知識を深掘りしていきましょう。
—
1. QCOW2の内部構造：L1/L2テーブルという「地図」
QCOW2（QEMU Copy On Write version 2）は、単なるバイナリの塊ではありません。内部的には小さなブロック単位（クラスター）に分割され、その居場所を示す「地図」を持っています。
- ヘッダー: ファイルのメタデータ。バージョンや機能フラグが記されている。
- L1テーブル: 全体的なインデックス。
- L2テーブル: L1から参照される詳細なマッピング。これらが「ゲストOSのセクタ」と「ホスト上のファイル内位置」を繋いでいます。
この構造があるおかげで、QCOW2は「論理的なディスク」と「物理的なストレージ」を切り離すことができます。これが、Copy-on-Write（CoW）を支える心臓部です。
—
2. Copy-on-Writeの仕組み：差分管理の正体
Copy-on-Writeの概念はシンプルです。「変更されるまでコピーしない」。
1. ベースイメージ: 読み取り専用のテンプレート（Golden Image）として保持。
2. 差分ファイル: 書き込みが発生したブロックだけを、新しいファイルに書き出す。
3. 読み込み時: L2テーブルを参照し、差分ファイルに存在すればそこを、なければベースイメージを参照する。
この仕組みにより、100台のVMを立ち上げても、ベースイメージは共有されるため、ディスク容量を劇的に節約できます。
—
3. 実践：qemu-imgによるスナップショット操作
現場で最もよく使うのが qemu-img です。APIで制御する前の「基礎体力」として、このコマンドを使いこなせないとトラブル時に詰みます。
ベースイメージから差分ディスクを作成する
# 1. ベースとなるイメージを作成（読み取り専用として扱う）
qemu-img create -f qcow2 base_image.qcow2 20G
# 2. 差分ディスク（Overlay）を作成
# -b: ベースを指定
# -F: ベースのフォーマットを指定
qemu-img create -f qcow2 -b base_image.qcow2 -F qcow2 overlay.qcow2この overlay.qcow2 は作成直後は数KBしかありません。ここにOSが起動し、ログが吐き出され、パッケージがアップデートされるたびに、少しずつ容量が増えていきます。
—
4. Pythonでメタデータを覗き見る（運用監視のヒント）
インフラ監視を自動化する際、qemu-img info の出力をJSONでパースするのはSREの常套手段です。
import subprocess
import json
def get_qcow2_info(file_path):
# JSON形式で詳細情報を取得
cmd = ["qemu-img", "info", "--output=json", file_path]
result = subprocess.run(cmd, capture_output=True, text=True)
data = json.loads(result.stdout)
# 物理サイズと論理サイズの乖離をチェック（断片化の指標になる）
actual_size = data.get("actual-size")
virtual_size = data.get("virtual-size")
print(f"File: {file_path}")
print(f"使用中容量: {actual_size / 1024 / 1024:.2f} MB")
print(f"仮想最大容量: {virtual_size / 1024 / 1024:.2f} MB")
# 実行例
# get_qcow2_info("overlay.qcow2")—
5. 現場のシニアエンジニアから伝えたい「罠」
この仕組みを理解した上で、運用上の注意点を3つだけ挙げます。
1. バックグラウンドのIOPS増加: 階層が深くなればなるほど、L2テーブルのルックアップコストが増大します。スナップショットを数珠つなぎ（Chain）にするのは避けましょう。
2. スパースファイルの特性: ls -lh で見えるサイズと、ディスクが実際に消費している容量は異なります。du コマンドで確認する癖をつけないと、知らないうちにストレージが枯渇します。
3. 断片化（Fragmentation）: 長期間運用したQCOW2は、ホスト側の物理ディスク上で断片化します。定期的な qemu-img convert による再構築（コンパクション）は、パフォーマンス維持に不可欠です。
—
まとめ
QCOW2のCoWは、仮想化環境における「メモリ管理」と「ファイルシステム」のいいとこ取りをしたような賢い仕組みです。しかし、魔法のように見える裏側には、ディスクI/Oのレイテンシやテーブル管理のオーバーヘッドが隠れています。
「なぜ遅いのか？」「なぜ容量が足りないのか？」と悩んだときは、まず qemu-img info でそのイメージの「地図」を確認することから始めてみてください。それが、トラブルシューティングの第一歩です。
皆さんのインフラが、今日も安定してパケットを捌き続けることを願っています。
コメント