Microsoft の Azure Container Registry（ACR）チームが、外部レジストリのコンテナイメージを ACR 経由でキャッシュする「ACR Artifact Cache」の内部アーキテクチャを公式ブログで詳細に公開した。1日1億件を超えるイメージプルを支えるプルスルーキャッシュの設計思想と、実際の動作フローが明らかになった。

なぜ上流レジストリに直接依存してはいけないのか

コンテナを本番運用しているチームなら、一度は遭遇したことがあるはずだ——Docker Hub のレートリミットに引っかかり、Kubernetes ノードが突然イメージを取得できなくなるアレだ。

Docker Hub は認証なしユーザーや個人プランユーザーに対してプル数を制限しており、CI/CD の共有エージェントや大規模な Kubernetes クラスターでは、あっという間に上限に達する。しかしこれは Docker Hub 固有の話ではない。本質的な問題は「上流レジストリへの直接依存が、本番システムに許容できないリスクをもたらす」という点にある。

具体的な失敗パターンはこうだ：

  • 上流の一時的な障害や低速化がそのままサービス停止に直結する
  • レートリミット・バースト制限で大規模スケールアウト時にイメージ取得が詰まる
  • 認証情報の管理が各チームに分散し、セキュリティ統制が効かなくなる
  • ネットワークポリシー（承認済みの境界内のみ通信を許可）が上流への直接アクセスを許可しないケースがある

ACR Artifact Cache はこの問題を「上流の内容を ACR 経由で透過的にキャッシュする」ことで解決する。クライアントは通常の ACR プルと同じ操作をするだけでよく、裏側の複雑さは隠蔽される。

キャッシュルールとクレデンシャル管理

設定はコントロールプレーンで行う。チームはまず「キャッシュルール」を作成し、ACR 内の下流パスと上流ソースのマッピングを定義する。

出典: この記事は Inside ACR Artifact Cache: Pull-Through Caching at Scale の内容をもとに、筆者の見解を加えて独自に執筆したものです。