Content last updated 2026-05-06

Artifact Registry ADR 003: システム要件

Artifact Registry のインフラ要件とパフォーマンス制約

背景

Artifact Registry は、エンタープライズ規模のアーティファクト管理を支えるために、堅牢なインフラ基盤を必要とします。本 ADR ではインフラ要件とパフォーマンス制約を文書化します。

レジストリは次をサポートする必要があります。

  • 非同期操作、マイグレーション、ライフサイクルポリシー向けの 信頼性の高いバックグラウンドジョブ処理
  • アーティファクト、リポジトリ、アクセス制御、監査ログ向けの 永続的なメタデータストレージ
  • Organization レベルの重複排除を伴う、アーティファクトデータ向けの コンテンツアドレッサブル Blob ストレージ
  • コストトラッキング、利用パターン、AI 駆動レコメンデーション向けの アナリティクスとインサイト
  • 頻繁にアクセスされるデータ、レート制限、セッション管理向けの 分散キャッシュ
  • リアルタイム通知とプラットフォーム統合向けの イベント駆動アーキテクチャ

これらの要件を満たす技術選択は ADR-006 に文書化されています。

決定

Artifact Registry は次のインフラ機能を必要とします。

1. バックグラウンドジョブ処理

目的: 信頼性の高いリトライロジックとモニタリングを伴う、長時間操作の非同期タスク実行。

ユースケース:

  • イベント記録と監査ログ処理
  • 非同期一括操作（一括削除、一括タグ付け、一括移動）
  • アーティファクトマイグレーション（外部プロバイダーから、既存の GitLab レジストリから）
  • ライフサイクルポリシー実行（保持クリーンアップ、有効期限管理）
  • キャッシュ無効化とウォーミング
  • 脆弱性スキャンとセキュリティ分析
  • メタデータの抽出と enrichment

2. リレーショナルデータベース

目的: アーティファクトメタデータ、リポジトリ、Repository collection、アクセス制御の永続ストレージ。

ユースケース:

  • アーティファクト、リポジトリ、Repository collection のメタデータ管理
  • アクセス制御ルールと RBAC 定義
  • 監査ログとコンプライアンストラッキング
  • ライフサイクルポリシー定義と実行状態
  • 仮想リポジトリ構成とアップストリームソース管理
  • Organization と Repository collection の階層
  • ガベージコレクション用の参照トラッキング

3. Blob ストレージ

目的: アーティファクト重複排除のためのコンテンツアドレッサブルストレージ。Organization スコープと GitLab の統合オブジェクトストレージをサポート。

ユースケース:

  • 実際のアーティファクトデータ（コンテナレイヤー、パッケージファイル、バイナリ Blob）の保存
  • Organization 重複排除のサポート（ADR-002 を参照）
  • 効率的なガベージコレクションとライフサイクル管理を可能にする
  • マルチリージョンレプリケーションとディザスタリカバリのサポート

4. コンテンツデリバリーネットワーク (CDN)

目的: アーティファクトダウンロード用のエッジキャッシング。頻繁にアクセスされるコンテンツのレイテンシとオリジン負荷を削減します。

ユースケース:

  • ユーザーに近いエッジロケーションでアーティファクト Blob のダウンロードをキャッシュ
  • オブジェクトストレージとオリジンサーバーの負荷を削減
  • 地理的に分散したチームのダウンロードレイテンシを改善
  • プライマリストレージからの egress 削減によるコスト最適化

5. アナリティクスエンジン

目的: 大規模データセットを効率的にフィルタリング、集計、クエリし、アナリティクス、コストトラッキング、AI 駆動インサイトに活用します。

ユースケース:

  • 長期イベント記録（ダウンロード、アップロード、アクセスパターン）
  • コストアナリティクスと予測
  • 利用トレンドとインサイト
  • レコメンデーションと最適化のための AI/ML 機能の供給
  • パフォーマンス分析とボトルネック特定

6. キャッシュ

目的: 頻繁にアクセスされるデータ、レート制限、分散ロック、エフェメラルな共有アプリケーション状態のキャッシュ。

ユースケース:

  • メタデータとセッションデータのキャッシュ
  • レート制限とクォータの強制
  • 並行操作向けの分散ロック
  • 一時的なアップロードセッションの追跡
  • エフェメラルな共有アプリケーション状態
  • キャッシュ無効化の調整

7. イベントバス

目的: リアルタイム通知とプラットフォーム統合のためのイベント駆動アーキテクチャ。

ユースケース:

  • アーティファクトに対するすべてのアクション（アップロード、ダウンロード、削除、タグ付けなど）のイベント発行
  • イベントからのアクションのトリガー（キャッシュ無効化、アナリティクスインジェスト、セキュリティスキャン）
  • 他の GitLab プラットフォームコンポーネントとの統合
  • サブスクライバーへのリアルタイム通知
  • 監査とコンプライアンスのためのイベントストリーミング

パフォーマンス、スケール、運用上の制約

Artifact Registry は大規模エンタープライズ組織と GitLab.com 規模をターゲットとします。本セクションでは高レベルの制約をキャプチャします。詳細なキャパシティプランニングは追って行います。

想定される利用特性

  • 高い読み取りボリューム（ダウンロード、メタデータ読み取り）と持続的な書き込み活動（アップロード、タグ更新、ライフサイクルポリシーアクション）。
  • 少数の「ホット」リポジトリとアーティファクトに強い偏りがあり、稀にアクセスされるコンテンツのロングテール。
  • 主に CI/CD ワークロードによって駆動されるスパイクのあるトラフィックパターン（例: デプロイ波、大規模パイプライン）。
  • 数千のリポジトリと数百万のアーティファクトを持つ多数の大規模 Organization。

主要なパフォーマンス・信頼性目標

  • API およびレジストリ操作は、典型的なエンタープライズワークロード下で応答性を保ち、広範な障害ではなく負荷下での予測可能な劣化を示す。
  • コア操作（アップロード、ダウンロード、ガベージコレクション、ライフサイクルポリシー）は高並行性下で安全かつ正確である。
  • メタデータ操作（リスト、検索、バージョン解決）は「Organization あたり数百万のアーティファクト」スケールで適切に動作する。
  • バックグラウンド処理は、ピークイベント中に作成されたバックログを許容可能なウィンドウ内で消化できる。

キャパシティと成長の考慮事項

Artifact Registry は初期データなしの新規サービスとしてローンチします。成長は顧客が提供を採用するにつれて自然に進みます。マイグレーションツールは後のフェーズで計画されており、顧客が時間をかけて既存レジストリからアーティファクトを移動できるようにします。

顧客がマイグレーションするにつれ、負荷とストレージは既存のレジストリ（コンテナレジストリ、パッケージレジストリ）から Artifact Registry へ徐々にシフトします。すべてのレジストリにわたる結合負荷は安定したままで、既存レジストリが縮小するにつれて統合レジストリが成長するはずです。

現在の GitLab.com レジストリメトリクスは、Artifact Registry が最終的に達するであろうスケールの指針を提供します。詳細なメトリクスは 内部キャパシティプランニングノート を参照してください。

  • トラフィック (GitLab.com の予測):

    • API トラフィック: 定常状態で毎秒数千リクエスト、CI バーストピーク時に毎秒数万にスケール。
    • バックグラウンドジョブスループット (GC、ライフサイクル、マイグレーション、アナリティクス): 毎秒数十から数百ジョブ、クリーンアップ操作中にピーク。
    • ストレージスループット: アップロード数百 MB/秒、ダウンロード数 GB/秒。

  • データ量 (GitLab.com の予測):

    • 総ストレージアーティファクトデータ: すべての顧客にわたって数十ペタバイト。
    • オブジェクト数: Blob ストレージで約 10 億オブジェクト。
    • アーティファクトメタデータ: 大規模 Organization あたり数百万のアーティファクト、結果として TB 範囲に成長する PostgreSQL データセット。
    • 保持される監査／イベントレコード: 利用パターンに基づいて推定。典型的なエンタープライズの保持期間は 90～365 日。

  • ストレージパターン:

    • 既存レジストリは、ほとんどのアーティファクトデータが初期 push/pull サイクル後にあまりアクセスされないことを示しており、ストレージの大部分は最終的にコールド／アーカイブティアに移動します（80% 以上がコールドストレージクラス）。Artifact Registry はコストを最適化するため、同様の階層化ストレージを計画する必要があります。

詳細なインフラサイジング、デプロイメントトポロジ、環境固有の SLA は本 ADR のスコープ外です。

参考文献

最終更新 July 30, 2026: Merge pull request #483 from kyama0/translation/batch-2026-07-29-1 (c955a93f)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License