Artifact Registry

解決する課題

ビルドしたコンテナイメージやライブラリを、自前のサーバーやストレージを用意せずに安全に保管・配布できる場所が手に入ります。

• ビルドしたコンテナイメージを一元管理し、Cloud Run / GKE / Compute Engine からそのまま pull したい
• npm・Maven・Python（PyPI）・Go・Apt・Yum など言語/OS パッケージを社内レジストリとして持ちたい
• 外部の公開レジストリ（Docker Hub・npm 公式など）への依存をキャッシュして可用性と速度を上げたい
• 保存したイメージを脆弱性スキャンし、安全なものだけをデプロイしたい
• リポジトリへの push/pull を IAM できめ細かく制御したい

主要概念と用語

• リポジトリ（repository）: アーティファクトを入れる単位。作成時にフォーマット（Docker / npm / Maven / Python など）とロケーション（地域）を1つ決める。最上位の管理単位
• フォーマット: そのリポジトリが扱う種類。コンテナイメージのほか各種言語/OS パッケージに対応
• アーティファクト: 保存する実体。コンテナイメージや各言語のパッケージ
• イメージのパス: ロケーション-docker.pkg.dev/プロジェクトID/リポジトリ名/イメージ名:タグ の形式で参照
• 標準リポジトリ（standard）: 自分でアーティファクトを push して保管する通常のリポジトリ
• リモートリポジトリ（remote）: Docker Hub や npm 公式など外部レジストリのキャッシュとして振る舞う読み取り用リポジトリ
• 仮想リポジトリ（virtual）: 複数のリポジトリ（標準・リモート）を1つのエンドポイントに束ねる入口。優先順位を付けて検索できる
• タグとダイジェスト: タグは可変の別名、ダイジェスト（sha256）は内容に固定で紐づく不変の識別子

仕様・制限・クォータ

• リポジトリはフォーマットとロケーションを作成時に固定する（後から種類は変えられない）
• ロケーションはリージョンまたはマルチリージョンを選べる。デプロイ先と同じ地域に置くと pull が速くコスト効率も良い
• 認証は IAM ベース。Docker クライアントには gcloud auth configure-docker で認証ヘルパーを設定する
• 同一リポジトリ内で複数フォーマットは混在できない（Docker 用と npm 用は別リポジトリ）
• ストレージ容量・リクエスト数などに各種クォータ/上限があり、必要に応じて引き上げ申請ができる

内部の仕組み

Artifact Registry はリポジトリ単位でアーティファクトを管理するマネージドサービスです。コンテナイメージは内部的にレイヤー（blob）とマニフェストに分けて保存され、同一レイヤーは重複排除されます。データは選んだロケーションに保管され、Google 管理鍵で保存時に自動暗号化されます。

• 標準リポジトリは push されたアーティファクトをそのまま保管する
• リモートリポジトリは初回 pull 時に上流（Docker Hub・npm 公式など）から取得してキャッシュし、2回目以降は手元から返す。上流障害やレート制限の影響を受けにくくなる
• 仮想リポジトリは複数のリポジトリへの単一の入口となり、優先度順に検索して最初に見つかったものを返す。利用側はエンドポイントを1つだけ知っていればよい

旧サービスである Container Registry（gcr.io） の後継にあたり、コンテナに加えて言語パッケージまで同じ仕組みで扱える点が大きな違いです。AWS でいえば、コンテナの Amazon ECR と言語パッケージの AWS CodeArtifact を1つにまとめたような位置づけです。

設計パターン / ベストプラクティス

• リポジトリは用途/環境ごとに分割（本番用・開発用など）し、IAM で push/pull 権限を分ける
• デプロイ先（Cloud Run / GKE）と同じリージョンにリポジトリを置き、レイテンシと下り課金を抑える
• 外部公開レジストリはリモートリポジトリでキャッシュし、上流のレート制限・障害から切り離す
• 利用側からは仮想リポジトリを入口にし、内部の構成（標準/リモートの組み合わせ）を隠蔽する
• デプロイ参照は可変のタグではなくダイジェスト（sha256）固定にして、再現性を担保する
• 不要な古いイメージはクリーンアップポリシーで自動削除し、ストレージコストを抑える

運用・監視

• Cloud Audit Logs で誰がいつ push/pull・設定変更したかを監査
• Cloud Monitoring でストレージ使用量やリクエスト傾向を可視化
• pull 失敗（403 / unauthorized）の多くは IAM ロール不足（読み取りなら Artifact Registry Reader）か認証ヘルパー未設定が原因
• 容量増加にはクリーンアップポリシーでタグなしイメージや古いバージョンを定期削除
• リポジトリの設定（フォーマット・ロケーション・暗号化）は describe コマンドで確認できる

コスト

主に「保存しているアーティファクトの容量」と「リポジトリからの下りネットワーク転送（egress）」に課金されます。同一リージョン内の Google Cloud サービスへの転送は割安または無料の範囲があり、別地域やインターネットへの転送ほど高くなります。

セキュリティ

• アクセス制御は Cloud IAM。読み取りは Artifact Registry Reader、書き込みは Writer といった事前定義ロールで最小権限を割り当てる
• 脆弱性スキャン（Artifact Analysis） を有効化し、保存イメージの既知 CVE を検出する
• Binary Authorization と組み合わせ、署名・スキャン済みの信頼できるイメージだけを Cloud Run / GKE にデプロイできるよう強制する
• 保存時暗号化は既定で有効（Google 管理鍵）。要件に応じて CMEK（Cloud KMS 管理鍵） に切り替えられる
• リポジトリは既定で非公開。必要な主体にだけ権限を付与し、allUsers のような広い公開は避ける

Well-Architected の観点

• セキュリティ: IAM による最小権限、脆弱性スキャン、Binary Authorization での署名済みイメージ強制、CMEK 暗号化により、サプライチェーン全体を保護する
• 運用上の優秀性: CI/CD（Cloud Build など）と統合し、ビルド成果物の保管からデプロイまでを自動化。クリーンアップポリシーやリモート/仮想リポジトリで運用負荷を下げる

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# Docker フォーマットのリポジトリを東京リージョンに作成
gcloud artifacts repositories create my-repo \
  --repository-format=docker \
  --location=asia-northeast1 \
  --description="App container images"

# Docker クライアントに認証ヘルパーを設定（このレジストリ向け）
gcloud auth configure-docker asia-northeast1-docker.pkg.dev

# ローカルイメージにタグを付けて push
docker tag web:latest \
  asia-northeast1-docker.pkg.dev/PROJECT_ID/my-repo/web:latest
docker push \
  asia-northeast1-docker.pkg.dev/PROJECT_ID/my-repo/web:latest

# あるサービスアカウントに pull（読み取り）権限だけを付与
gcloud artifacts repositories add-iam-policy-binding my-repo \
  --location=asia-northeast1 \
  --member="serviceAccount:web-sa@PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/artifactregistry.reader"

# リポジトリ内のイメージとタグを一覧
gcloud artifacts docker images list \
  asia-northeast1-docker.pkg.dev/PROJECT_ID/my-repo