Azure Container Registry（ACR）で大規模なイメージ Pull が遅い、AKS のノード増加時に Pod 起動がばらつく――そんな管理者が今回まず押さえるべき結論は、「レイヤーのコピー数は多ければ多いほど速い」わけではないという点です。2026年6月23日の「How Many Copies of Each Layer Does Your Container Registry Actually Need?」は、ACR の内部的なレイヤー配置と Pull 性能の関係を説明する Notice であり、今すぐ利用者側で設定変更や移行を強制される発表ではありません。
ただし、AKS、Azure Container Apps、App Service、CI/CD などで同じコンテナイメージを大量ノードから同時に Pull する環境では、運用設計を見直すきっかけになります。特に確認すべきなのは、ACR の SKU、リージョン配置、Geo レプリケーション、AKS から ACR への権限、Azure Monitor による Pull 失敗や認証失敗の監査です。公式発表では、約1,000ノード規模のテストで、適度なレイヤーコピーは Pod 起動 P99 を改善した一方、過剰なコピーでは遅延が戻る結果が示されています。(TECHCOMMUNITY.MICROSOFT.COM)
How Many Copies of Each Layer Does Your Container Registry Actually Need? とは何か
この発表は、Azure Container Registry の「レイヤーコピー数」を利用者が手動で調整するための手順ではありません。ACR の内部では、コンテナイメージのレイヤーデータが Azure Storage 側に保持され、同じレイヤーに対する複数の読み取りを分散できるようにコピーが管理されます。公式発表では、コピー数が増えると読み取りを受け持つバックエンドが増え、同時 Pull 時のスループット向上につながる一方で、一定以上になると効果が頭打ちになり、さらに増やすと逆にレイテンシが悪化する場合があると説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
管理者向けに言い換えると、今回のポイントは「ACR の性能問題を、単純な容量不足や SKU だけで判断しないこと」です。コンテナレジストリの Pull 性能は、レジストリのリージョン、SKU、同時 Pull 数、イメージサイズ、レイヤー構成、ノード側キャッシュ、ネットワーク経路が組み合わさって決まります。
まず確認すべき結論
| 確認項目 | 管理者の判断 |
|---|---|
| サービス停止や破壊的変更か | いいえ。Notice 扱いの技術解説として読み、直ちに設定変更が必要な発表ではありません。 |
| ユーザーがレイヤーコピー数を直接設定するのか | 通常は設定対象ではありません。利用者側は SKU、配置、監視、イメージ設計を確認します。 |
| 影響が大きい環境 | 大規模 AKS、AI/ML 学習基盤、短時間に多数 Pod を起動するバッチ、全台一斉更新、CI/CD の集中 Pull 環境です。 |
| 最初に見るべき指標 | Pod 起動時間の P90/P99、Pull 失敗、HTTP 429、ACR の Pull 回数、認証失敗、Storage used です。 |
| 取るべき行動 | 監視の追加、権限の棚卸し、Geo レプリケーションや Premium SKU の必要性確認、イメージ軽量化です。 |
公式発表から読み取れる性能上のポイント
公式発表では、ACR Premium を使い、約1,000ノードが同じ大きなイメージを同時にコールド Pull する条件でテストされています。変えたのは単一レジストリエンドポイント背後のレイヤーコピー数で、測定対象は Pod 起動の P50/P90/P99、ストレージ読み取りレイテンシ、エグレススループット、ストレージスロットリングイベントです。(TECHCOMMUNITY.MICROSOFT.COM)
| 構成 | Pod 起動 P50 | Pod 起動 P90 | Pod 起動 P99 | スロットリング | 読み取り負荷の状態 |
|---|---|---|---|---|---|
| Baseline | 9分36秒 | 11分00秒 | 14分16秒 | 多い | 上位バックエンドが上限付近 |
| Low | 9分27秒 | 10分14秒 | 12分59秒 | 一部あり | まだ上限超過が残る |
| Mid | 9分25秒 | 9分45秒 | 10分22秒 | なし | 上限未満 |
| Higher | 9分20秒 | 9分37秒 | 10分22秒 | なし | 余裕あり |
| Very high | 9分28秒 | 10分31秒 | 13分48秒 | なし | スロットリングはないが遅延が悪化 |
重要なのは、Mid 構成で P99 が 14分16秒から 10分22秒に改善した一方、Very high では 13分48秒まで悪化したことです。公式発表は、コピー数の「最適点」が存在し、ストレージスロットリングが解消された後は、コピーを増やしても効果が伸びないと説明しています。(TECHCOMMUNITY.MICROSOFT.COM)
管理者が確認すべき影響範囲
今回の Notice は、すべての Azure 利用者に同じ重みで影響するものではありません。小規模な開発環境や、数台のコンテナホストがたまに Pull するだけの環境では、優先度は高くありません。反対に、同時起動数が多い環境では、Pod 起動遅延がアプリケーションの可用性やジョブ開始時刻に直結します。
| 環境 | 影響が出やすい理由 | 確認すること |
|---|---|---|
| AKS の大規模クラスター | ノード追加、アップグレード、再スケジュール時に同一イメージ Pull が集中する | ノード数、同時 Pod 起動数、Pod 起動 P99、ImagePullBackOff の発生有無 |
| AI/ML 学習基盤 | 大容量イメージを多数 GPU ノードで同時に取得しやすい | 学習開始前の Pull 時間、ジョブ待ち時間、イメージサイズ |
| CI/CD ランナー群 | ビルドやテストのタイミングが集中しやすい | Pull/Push 回数、認証失敗、429、ランナーの分散 |
| 複数リージョン展開 | 遠いリージョンの ACR から Pull すると遅延が増える | ACR と実行基盤のリージョン、Geo レプリケーション有無 |
| 集約型 ACR | 複数チームが同じレジストリを共有し、権限と負荷が混在する | リポジトリ単位の権限、利用チーム別の Pull 傾向、監査ログ |
権限確認：AcrPull と ABAC の使い分けを見直す
Azure 管理者が最初に確認すべき実務ポイントは、AKS や CI/CD が ACR にどう認証しているかです。AKS と ACR の統合では、AKS のエージェントプールに関連付いた Microsoft Entra ID マネージド ID に AcrPull ロールが割り当てられます。Microsoft Learn では、Microsoft Entra グループ経由で AcrPull を付与した場合、RBAC 反映に遅延が出る可能性があるため、自動化では kubelet identity の設計に注意するよう案内されています。(Microsoft Learn)
さらに、ACR で Microsoft Entra ABAC によるリポジトリ単位の権限を有効にしている場合は注意が必要です。ABAC 有効レジストリで権限モードが「RBAC Registry + ABAC Repository Permissions」の場合、az aks --attach-acr による従来の付与ではなく、Container Registry Repository Reader などのリポジトリ権限に合わせたロール割り当てが必要になります。(Microsoft Learn)
権限の確認チェックリスト
| 対象 | 確認内容 | 推奨判断 |
|---|---|---|
| AKS | kubelet identity に Pull 権限があるか | 通常は AcrPull。ABAC 有効時はリポジトリ単位の Reader 権限を確認 |
| CI/CD | Push 用と Pull 用の権限が分かれているか | Push 権限を本番実行基盤に付けない |
| 開発者 | 個人ユーザーに過剰な AcrPush/AcrDelete が付いていないか | 必要なリポジトリだけに限定 |
| サービスプリンシパル | パスワード期限、利用場所、所有者が管理されているか | 可能ならマネージド ID へ寄せる |
| Admin account | ACR の管理者アカウントが有効になっていないか | Microsoft は高権限のため必要時のみ有効化と説明しているため、常用は避ける |
| ABAC | チーム別・環境別にリポジトリ条件を設計しているか | 集約 ACR では特に有効 |
ACR の認証方式には、個人の Microsoft Entra ID、サービスプリンシパル、マネージド ID、管理者アカウント、非 Entra のトークンベース権限などがあります。管理者アカウントはレジストリ全体に高い権限を持つため、複数ユーザーや本番運用の恒常利用には向きません。(Microsoft Learn)
監査とモニタリング：Pull の「遅い」を見える化する
今回の発表で重要なのは、平均値だけを見ても問題を見落とす点です。Pod 起動の P50 が大きく悪化していなくても、P99 が伸びると、ローリング更新やノードスケールアウトの最後の数％が遅れます。実務では、アプリケーション側の Pod 起動時間と ACR 側の Pull/認証/失敗ログを並べて確認します。
Azure Container Registry は Azure Monitor のメトリックとして StorageUsed、SuccessfulPullCount、SuccessfulPushCount、TotalPullCount、TotalPushCount などを提供しています。また、リソースログとして ContainerRegistryLoginEvents と ContainerRegistryRepositoryEvents を収集でき、後者では push、pull、untag、delete、purge などのリポジトリ操作を確認できます。(Microsoft Learn)
まず有効化する監査ログ
| ログ・メトリック | 用途 | 見るべき場面 |
|---|---|---|
TotalPullCount | Pull の総量を把握する | デプロイ時間帯、AKS スケールアウト、CI/CD 集中時間 |
SuccessfulPullCount | Pull 成功数を確認する | Pull 失敗率を推定する |
StorageUsed | レジストリ容量の増加を把握する | 古いタグ、巨大イメージ、レプリカ増加の影響確認 |
ContainerRegistryLoginEvents | 認証成功・失敗を監査する | 権限変更後、AKS 接続変更後、CI/CD 変更後 |
ContainerRegistryRepositoryEvents | Pull/Push/Delete/Untag を追跡する | 失敗、誤削除、不審な操作、負荷集中の分析 |
| Activity log | レジストリ作成・更新・削除、ロール割り当てを追跡する | 管理操作の監査、変更管理 |
Azure Monitor のリソースログは、診断設定を作成して Log Analytics、Storage、Event Hubs などへルーティングしないと保存・クエリできません。ACR のポータル画面で「Monitoring」配下の「Diagnostic settings」を確認し、少なくとも本番レジストリはログ保存先を明確にしておきます。(Microsoft Learn)
KQL 例：Pull 操作の遅延を確認する
ContainerRegistryRepositoryEvents
| where TimeGenerated > ago(24h)
| where OperationName has "Pull"
| summarize
PullCount = count(),
P95DurationMs = percentile(DurationMs, 95),
P99DurationMs = percentile(DurationMs, 99)
by Repository, bin(TimeGenerated, 15m)
| order by TimeGenerated descこのクエリで、どのリポジトリの Pull がどの時間帯に遅くなっているかを確認できます。特定のリポジトリだけ P99 が高い場合は、イメージサイズやレイヤー構成、同時起動するワークロードを優先して確認します。
KQL 例：429 や失敗らしきイベントを確認する
ContainerRegistryRepositoryEvents
| where TimeGenerated > ago(24h)
| where ResultDescription contains "429"
or ResultDescription contains "Too Many"
or ResultDescription contains "40"
or ResultDescription contains "50"
| project TimeGenerated, LoginServer, OperationName, Repository, Tag, Identity, CallerIpAddress, ResultDescription, DurationMs
| order by TimeGenerated descHTTP 429 が多い場合、単純に ACR のせいと決めつける前に、デプロイ方式を確認します。たとえば、全ノード同時更新、短時間に集中する CI ジョブ、キャッシュされない大容量イメージ、同一リージョン外からの Pull が重なると、レジストリ側・ネットワーク側・ノード側のいずれでもボトルネックが出ます。
KQL 例：認証失敗を確認する
ContainerRegistryLoginEvents
| where TimeGenerated > ago(24h)
| where ResultDescription != "200"
| project TimeGenerated, LoginServer, Identity, CallerIpAddress, ResultDescription
| order by TimeGenerated desc権限変更後に認証失敗が増えている場合は、AcrPull、ABAC 条件、マネージド ID、サービスプリンシパルのシークレット期限を確認します。AKS 側で ImagePullBackOff が出ていても、原因が性能ではなく認証や権限であるケースは珍しくありません。
SKU とリージョン構成の確認
ACR には Basic、Standard、Premium の SKU があり、Premium はより高いストレージ、同時操作、スループットの上限を持ち、Geo レプリケーションや Private Link などの機能も提供します。Microsoft Learn では、Basic は低利用シナリオ向け、Standard は多くの本番シナリオ向け、Premium は高ボリュームや大規模同時デプロイ向けと説明されています。(Microsoft Learn)
| 確認項目 | Basic/Standard のままでよい可能性 | Premium を検討する目安 |
|---|---|---|
| 利用規模 | 開発・検証、少数ノード、低頻度 Pull | 多数ノード、同時 Pull、頻繁なデプロイ |
| リージョン | 単一リージョンで完結 | 複数リージョンに展開 |
| セキュリティ | パブリック到達性を制限しない構成で足りる | Private Link や高度なネットワーク制御が必要 |
| 可用性 | レジストリ停止時の影響が限定的 | リージョン障害や大規模展開の影響が大きい |
| 運用体制 | 小規模チームで単純運用 | 複数チーム・複数環境で共有 |
ただし、今回の発表を理由に、すべての ACR を Premium へ移行する必要はありません。まずは Pull 回数、失敗率、Pod 起動時間、リージョン間の距離、イメージサイズを測定し、性能上の根拠がある場合に SKU を見直します。
Geo レプリケーションとレイヤーコピーを混同しない
Geo レプリケーションは、ACR の内容を複数の Azure リージョンに複製し、利用者に近いリージョンから Pull しやすくする機能です。Microsoft Learn では、Geo レプリケーションを有効にすると選択したリージョンに geo-replica リソースが作成され、イメージを push すると各レプリカへコンテンツとメタデータが同期されると説明されています。Geo レプリケーションは Premium SKU が必要です。(Microsoft Learn)
今回の「レイヤーコピー数」は、主に同一リージョン内のレイヤーデータ読み取り分散に関する話です。一方、Geo レプリケーションはリージョン間の配置に関する話です。どちらも Pull 性能に関係しますが、解決する問題が違います。
| 問題 | 主な対策 |
|---|---|
| 同一リージョン内で大量ノードが同時 Pull して遅い | SKU、同時起動制御、イメージ軽量化、監視、Microsoft 側の内部スケーリング改善を確認 |
| 別リージョンの ACR から遠距離 Pull して遅い | Geo レプリケーション、実行基盤と ACR のリージョン整合を確認 |
| 認証失敗で Pull できない | AcrPull、ABAC、マネージド ID、サービスプリンシパルを確認 |
| 古いイメージが溜まり容量が増える | タグ運用、削除、保持ポリシー、StorageUsed を確認 |
| デプロイ時だけ遅い | デプロイの同時実行数、ローリング更新幅、事前 Pull、ノードキャッシュを確認 |
複数リージョンへコンテナを展開している場合、Microsoft Learn のベストプラクティスでも、レジストリ管理の簡素化とレイテンシ低減のために Geo レプリケーションが推奨されています。(Microsoft Learn)
移行・設計見直しの判断基準
今回の Notice は、強制移行の発表ではありません。そのため、移行計画を立てる場合も「何が遅いのか」を分けて判断します。
すぐに移行しなくてよいケース
次の条件に当てはまる場合、まずは監視の追加と現状把握で十分です。
| 条件 | 理由 |
|---|---|
| Pull 失敗や 429 がほぼない | ACR が明確なボトルネックとは言いにくい |
| Pod 起動 P99 が業務要件内 | 改善余地はあっても緊急性は低い |
| 単一リージョン・少数ノード | Geo レプリケーションや Premium 化の効果が限定的 |
| イメージサイズが小さい | レジストリよりアプリ起動処理が支配的な場合がある |
| デプロイ頻度が低い | コスト増の方が大きくなる可能性がある |
構成変更を検討すべきケース
次のような状況では、SKU、リージョン、権限、デプロイ方式を見直します。
| 症状 | 具体的な対応 |
|---|---|
| AKS のスケールアウト時に Pod 起動が大きくばらつく | P90/P99 を測定し、同時起動数を調整する |
| 複数リージョンの AKS が1つの ACR から Pull している | Premium + Geo レプリケーションを検討する |
| CI/CD の特定時間帯に Pull/Push が集中する | ランナーの実行時間分散、キャッシュ、リトライ設計を見直す |
| 429 や Pull 失敗が繰り返される | SKU、リクエスト集中、リトライ、同時デプロイ数を確認する |
| 権限エラーと性能問題が混在している | 認証失敗ログと Pull 遅延を分けて分析する |
| レジストリを複数チームで共有している | ABAC によるリポジトリ単位権限を検討する |
イメージ設計で見直すべきポイント
ACR の内部最適化だけに頼るのではなく、コンテナイメージ自体も見直します。Microsoft Learn のベストプラクティスでは、Pull 性能に影響する要素としてイメージのレイヤー数にも触れており、少なすぎると再利用やキャッシュの利点が出にくく、多すぎると Pull や展開に時間がかかるため、5〜10レイヤーが目安とされています。(Microsoft Learn)
実務で効くイメージ改善
| 改善項目 | 効果 | 注意点 |
|---|---|---|
| ベースイメージを軽量化する | Pull 時間と展開時間を短縮しやすい | セキュリティ更新と互換性を確認する |
| 不要なツールを最終イメージに入れない | サイズ削減、脆弱性面の改善 | multi-stage build を使う |
| レイヤー数を極端に増やさない | Pull と展開のオーバーヘッドを抑える | キャッシュ再利用とのバランスを見る |
| タグだけでなく digest を使う | 意図しないイメージ変更を避けやすい | 運用ルールをチームで統一する |
| 本番と開発のイメージを分ける | 本番イメージを小さく保ちやすい | デバッグツールを本番に残さない |
| 古いタグを整理する | StorageUsed の増加を抑える | 参照中の digest を削除しないよう確認する |
ACR の StorageUsed は、共有レイヤー、マニフェスト、レプリカコピーを含む容量として扱われます。レイヤー共有があるため、単純に各リポジトリのサイズを足した値とは一致しない場合があります。(Microsoft Learn)
デプロイ運用で避けたい失敗
大規模環境では、ACR の性能だけでなく「いつ、どれだけ同時に Pull するか」が重要です。特に、ノードの入れ替え、クラスターアップグレード、全 Pod の再起動、HPA/KEDA による急激なスケールアウトが重なると、同じレイヤーへの読み取りが集中します。
| 失敗しやすい運用 | 起きる問題 | 改善策 |
|---|---|---|
| 全ノード・全 Pod を一斉更新する | ACR、ネットワーク、ノード展開が同時に詰まる | ローリング更新幅を制御する |
| 大容量イメージを毎回 Pull する | ノード追加時の起動が遅い | ベースイメージを見直し、不要ファイルを削る |
| CI/CD と本番デプロイが同時刻に集中する | Push/Pull が同時に増える | ジョブ時間を分散する |
| 権限変更とデプロイを同日に行う | 性能問題と認証問題の切り分けが難しい | 権限変更後に小規模 Pull テストを行う |
| 平均起動時間だけを見る | 一部 Pod の遅延を見落とす | P90/P99 を見る |
| ACR のリージョンを意識しない | 遠距離 Pull で遅延が増える | 実行リージョンに近い配置を選ぶ |
周知ポイント：開発チーム・SRE・セキュリティに伝える内容
今回の発表は、開発チームに「ACR が変わるので作業してください」と伝えるより、運用基準の見直しとして共有するのが適切です。特に、アプリケーションチームにはイメージサイズとデプロイ方式、SRE には監視指標、セキュリティ担当には権限と監査ログを伝えます。
社内周知テンプレート
Azure Container Registry のレイヤーコピー数と大規模 Pull 性能に関する Microsoft の技術解説が公開されました。今回の発表は破壊的変更や強制移行ではありませんが、大規模 AKS、CI/CD、複数リージョン展開では、同時 Pull 時の Pod 起動 P99 や Pull 失敗を確認する必要があります。各チームは、利用中の ACR、イメージサイズ、デプロイ時の同時起動数、ACR への権限、監査ログの有効化状況を確認してください。
役割別の依頼事項
| 対象 | 依頼する内容 |
|---|---|
| アプリ開発チーム | 本番イメージのサイズ、レイヤー数、不要ファイル混入を確認する |
| DevOps チーム | CI/CD の Pull/Push 集中時間、ランナー数、リトライ設定を確認する |
| AKS 管理者 | ノードスケールアウト時の Pod 起動 P90/P99、ImagePullBackOff を確認する |
| セキュリティ担当 | AcrPull、AcrPush、ABAC、サービスプリンシパル、Admin account を棚卸しする |
| 監査担当 | ContainerRegistryLoginEvents と ContainerRegistryRepositoryEvents の保存先を確認する |
| コスト管理担当 | StorageUsed、SKU、Geo レプリケーションの必要性を確認する |
管理者向け最終チェックリスト
| 分類 | チェック項目 | 完了基準 |
|---|---|---|
| 影響範囲 | ACR を利用する AKS、Container Apps、App Service、CI/CD を一覧化した | 利用レジストリ、リージョン、SKU、用途が分かる |
| 性能 | Pod 起動 P90/P99 と Pull 失敗を確認した | 遅延が特定時間帯・特定リポジトリに偏っていないか判断できる |
| SKU | Basic/Standard/Premium の妥当性を確認した | 高ボリュームや複数リージョンでは Premium 検討理由が整理されている |
| リージョン | ACR と実行基盤の距離を確認した | 遠距離 Pull がある場合は Geo レプリケーションを検討した |
| 権限 | AKS、CI/CD、開発者の Pull/Push 権限を確認した | 過剰権限や期限切れ SP がない |
| ABAC | ABAC 有効レジストリの AKS 接続方式を確認した | az aks --attach-acr 前提のままになっていない |
| 監査 | 診断設定を有効化した | Log Analytics などにログが保存されている |
| アラート | Pull 失敗、認証失敗、Storage used のアラートを設計した | 異常を利用者報告前に検知できる |
| イメージ | 大容量イメージとレイヤー数を確認した | 改善対象のリポジトリが明確になっている |
| 周知 | 影響チームへ Notice の意味を共有した | 強制移行ではなく、運用確認であると伝わっている |
まとめ：今やるべきことは「コピー数調整」ではなく運用の可視化
「How Many Copies of Each Layer Does Your Container Registry Actually Need?」は、Azure Container Registry の内部設計を理解するうえで重要な発表です。ただし、管理者が今すぐ行うべきことは、レイヤーコピー数を手動で増やすことではありません。まずは、自社の ACR 利用状況を棚卸しし、Pull が集中する時間帯、Pod 起動 P99、認証失敗、HTTP 429、SKU、リージョン配置を確認することです。
特に本番 AKS や大規模 CI/CD で ACR を使っている場合は、次の順番で進めると失敗しにくくなります。最初に Azure Monitor の診断設定を有効化し、Pull と認証のログを残します。次に、AKS と ACR の権限、ABAC の有無、管理者アカウントの状態を確認します。そのうえで、イメージサイズ、レイヤー数、デプロイ同時実行数、Geo レプリケーションや Premium SKU の必要性を判断します。
今回の Notice は、ACR の性能を「容量」だけで見るのではなく、「同時 Pull」「レイヤー設計」「監査」「リージョン配置」まで含めて考えるよい機会です。大規模環境ほど、平均値ではなく P90/P99 を見て、利用者が体感する Pod 起動遅延を基準に改善してください。
コメント