Fargateのエフェメラルストレージとは？Dockerイメージの保存先と書き込みレイヤーの仕組みを解説

AWS

「Fargateのエフェメラルストレージって、結局なにを保存しているの？」——ECS on Fargateを使い始めると一度はぶつかる疑問です。この記事を読むと、エフェメラルストレージにDockerイメージがどう格納されるのか、そして「書き込み可能なデータ」とは具体的に何を指すのかが、コンテナの内部構造のレベルでスッキリ理解できます。

この記事のゴール

本記事では、次の3点をクリアにします。

  • AWS ECS on Fargate のエフェメラルストレージが何に使われるのか
  • ECRからプルしたDockerイメージが、そのストレージ上にどう置かれるのか
  • 「書き込み可能なデータ」の正体——読み取り専用レイヤーと書き込み可能レイヤーの関係


エフェメラルストレージとは

「エフェメラル（ephemeral）」は「一時的な・つかの間の」という意味の英単語です。その名のとおり、タスク（コンテナ群の実行単位）が動いている間だけ存在し、タスクが停止すると中身ごと消える、使い捨ての一時ストレージを指します。

AWS ECS on Fargate（サーバー管理不要でコンテナを動かすAWSのサービス）では、プラットフォームバージョン1.4.0以降の各タスクに、デフォルトで20GiBのエフェメラルストレージが割り当てられます。必要に応じてタスク定義の ephemeralStorage パラメータで、最大200GiBまで拡張できます。

そしてここが本題です。ECRからプルされたDockerイメージは、このエフェメラルストレージ上に保存されます。AWS公式ドキュメントでも、プルされた圧縮状態のイメージと、展開（解凍）後のイメージの両方がエフェメラルストレージに置かれると明記されています。つまり「イメージを一時的に置く場所」という直感は正しいのですが、もう一歩踏み込むと、より正確な姿が見えてきます。


構成図：1つのストレージにレイヤーが同居する

重要なのは、読み取り専用のイメージレイヤーも、実行中に書き込まれるデータも、同じ20GiBのプール上に同居しているという点です。

たとえばDockerイメージが2GiBを使う場合、書き込み可能なデータ用に残るのは約18GiBです。1つのタスク内で複数コンテナを動かす場合は、この残り容量を各コンテナで分け合うことになります。だからこそ大きなイメージを使うと、その分だけ実際に使える作業領域が削られていきます。


「書き込み可能なデータ」の正体

大前提として、ビルドされたDockerイメージのレイヤーは読み取り専用（イミュータブル＝変更不可）です。イメージそのものに直接書き込むことはできません。

コンテナを起動すると、コンテナランタイムがその読み取り専用レイヤーの上に、薄い「書き込み可能レイヤー（writable container layer）」を1枚重ねます。実行中のプロセスが行う書き込みは、すべてこの最上位のレイヤーに記録されます。これが「書き込み可能なデータ」の正体です。

この書き込み可能レイヤーには、大きく2種類のデータが入ります。

種類具体例
実行中に新しく作られるファイル（主目的）アプリが生成するログファイル、一時ファイル、キャッシュ、ダウンロードデータ、計算中間ファイルなど
イメージ由来のファイルを書き換えたときの差分コピーオンライト（CoW）により、変更対象ファイルのコピーが書き込み可能レイヤーに作られたもの

イメージ内の既存ファイルを編集すると、コピーオンライト（Copy-on-Write／CoW）という仕組みが働きます。読み取り専用レイヤーにある元ファイルはそのまま残し、変更対象のファイルだけを書き込み可能レイヤーへコピーしてから、そのコピーに変更を加えます。結果としてイメージ本体は一切変わらず、変更分だけが上のレイヤーに溜まっていきます。

【用語】コピーオンライト（Copy-on-Write／CoW）
「書き込むときに初めてコピーする」方式のこと。読み取り専用レイヤーにある元ファイルはそのまま残し、変更対象のファイルだけを書き込み可能レイヤーへコピーしてから変更を加えます。元のイメージは不変なので、同じイメージから起動した別のコンテナは影響を受けません。

つまり「イメージに書き込んでいる」ように見えても、実態は「変更されたファイルのコピーが別レイヤーに作られている」だけです。これがコンテナを軽量かつ高速に保つ仕組みです。


順序を間違えないために——レイヤーとファイルの関係

よくある誤解は「生成したファイルが書き込み可能レイヤーを作る」という理解です。正しくは順序が逆で、次のようになります。

  1. コンテナが起動した時点で、ランタイムが空の書き込み可能レイヤーを先に用意する
  2. その後、コンテナが動く中で生成されるログや一時ファイルが、その用意済みのレイヤーに溜まっていく

「ファイルが先、レイヤーが後」ではなく、「レイヤーが先に用意され、そこにファイルが書き込まれる」というイメージです。

【運用上の注意】
書き込み可能レイヤーは、コンテナ（タスク）が停止すると破棄されます。ログを残したい場合は CloudWatch Logs などの外部に送る、永続データは Amazon EFS（永続ストレージ）をマウントするといった設計が必要です。「コンテナに書いたファイルが再起動で消えた」というトラブルの多くは、この性質を知らないことが原因です。


例え話でイメージをつかむ——「マスター設計図」と「トレーシングペーパー」

Dockerイメージを、建物のマスター設計図だと考えてみてください。これは完成済みで、誰も直接書き込んではいけない読み取り専用の原本です。

コンテナを起動するとは、設計士（コンテナ）がこの設計図の上に透明なトレーシングペーパーを1枚重ねるようなもの。設計士が書き込む変更やメモ（＝ログや一時ファイル）は、すべてこのトレーシングペーパー側に書かれます。原本の設計図はまったく汚れません。

何人もの設計士が同じ原本を共有しても、各自が自分のトレーシングペーパーを持つので互いに干渉しません。そして作業が終われば（コンテナが停止すれば）、トレーシングペーパーは捨てられ、原本だけが残ります。これがコンテナの「使い捨て」の正体です。


まとめ

  • Fargateのエフェメラルストレージは、タスク実行中だけ存在する使い捨ての一時ストレージ（デフォルト20GiB、最大200GiB）
  • ECRからプルしたDockerイメージ（圧縮・展開後の両方）は、このストレージ上に格納される
  • イメージレイヤーは読み取り専用。コンテナ起動時に、その上へ書き込み可能レイヤーが1枚重ねられる
  • ログや一時ファイルは書き込み可能レイヤーに溜まる。イメージ由来ファイルの編集はコピーオンライトで差分だけが記録され、イメージ本体は不変
  • 書き込み可能レイヤーはタスク停止で消えるため、永続化が必要ならEFSやCloudWatch Logsを併用する

「イメージの一時置き場」という入口の理解から一歩進んで、読み取り専用レイヤー＋書き込み可能レイヤーという二層構造まで押さえておくと、Fargateの容量設計やトラブルシュートがぐっとやりやすくなります。


参考リソース

コメント

タイトルとURLをコピーしました