コンテナレジストリとは｜200個ためても、依存まで同じなら保存量は1.9%で済んだ

200個ためても、依存まで同じなら保存量は1.9%で済んだ

個数に比例して増えるのは、イメージごとに違う層だけです。揃えた範囲は1つで済みます。

コンテナレジストリの保存量は、どこまで層を揃えられるかで決まります。実際に計算しました。

1つのイメージの内訳を、土台420MB・実行環境180MB・依存240MB・自分のコード12MBと置きました。合わせて852MBです。

共有の範囲を変える

イメージ数  共有しない  土台だけ共有  依存まで共有  依存まで共有した割合
1個               852MB         852MB         852MB                100.0%
5個              4260MB        2580MB         900MB                 21.1%
20個            17040MB        9060MB        1080MB                  6.3%
50個            42600MB       22020MB        1440MB                  3.4%
200個          170400MB       86820MB        3240MB                  1.9%

共有しない場合、200個で170400MBです。1個852MBの単純な掛け算になります。

土台だけ共有すると86820MBで、およそ半分です。土台420MBは1つで済むためです。

依存まで揃えると桁が変わる

依存まで同じなら3240MBです。共有しない場合の1.9%まで落ちます。

この場合、個数に比例して増えるのは自分のコードの12MBだけです。200個でも2400MBにしかなりません。

出典もレジストリの役割をイメージレジストリは、コンテナイメージを保存し共有するための集約された場所であるとしています。共有できる範囲が効きます。

レジストリと保管庫は別のものを指す

レジストリは置き場所全体、保管庫はその中のまとまりです。層はレジストリの単位で共有されます。

コンテナレジストリの話では、2つの言葉が混ざりがちです。出典が区別を書いています。

その説明はレジストリはコンテナイメージを保存し管理する集約された場所であり、いっぽう保管庫はレジストリの中にある関連したコンテナイメージのまとまりであるというものです。

共有される単位

前の節の共有は、レジストリの単位で起きます。保管庫が違っても、層の内容が同じなら1つで済みます。

つまり、アプリごとに保管庫を分けても保存量は増えません。増えるのは、層の内容が違うときだけです。

共有が崩れる条件

1. 土台が違う。版が1つずれるだけで別の層になる
2. 導入する順番が違う。並びが変われば結果も変わる
3. 日付や識別子が入る。毎回違う値が層に残る
4. 取り込む対象が広い。関係ないファイルの差で分かれる

3番目は気づきにくい形です。層の中に作成時刻が書き込まれると、内容が同じでも別の層になります。

並べ方そのものの効き方はDockerの記事で測っています。同じ理屈が、保存量にも効いています。

見るのは総量ではなく、共有できていない層

総量だけでは、増えている原因が分かりません。共有できている層と、そうでない層を分けます。

コンテナレジストリの運用で見るべきなのは、共有できていない層の量です。総量ではありません。

総量が増えていても、イメージの数が増えただけなら問題ありません。1個あたりの増え方が変わったときに手を打ちます。

見る数字

1. 1個あたりの増分。イメージを1つ足すと何MB増えるか
2. 共有された層の数。複数から参照されている層
3. 参照されていない層。消したイメージの残り
4. 版の数。保管庫ごとに何世代残っているか

1番目がこの計測の主題です。依存まで揃っていれば12MB、揃っていなければ432MBになります。

消す運用も要る

3番目と4番目は放っておくと積み上がります。古い版を残す期間を決めて、それ以外は消します。

出典も保管庫の中身を各保管庫は1つ以上のコンテナイメージを含むと書いています。1つの保管庫に版が積み上がる形です。

消す判断のために、いま動いている版がどれかを分かるようにしておきます。使われている版を消すと復旧できません。