プロンプトとコンテキスト
チームがパッケージ、コンテナイメージ、またはビルドアーティファクトを公開およびダウンロードできるレジストリを設計してください。メタデータ、バイナリブロブ、バージョンのタグ、権限、可用性、キャッシング、失効処理、監査を網羅してください。
まずアーティファクトの形式を1つ選択し、どの抽象化が一般化できるかを説明してください。コアとなる制約は、コンテンツダイジェストごとに1つのコピーであること、部分的にしか見えないリリースを発生させないこと、バイト列が置き換えられていないことをクライアントが検証できることです。
面接官がテストしていること
メタデータ対コンテンツ
優れた回答では、メタデータの読み取りで大きなファイルをスキャンしなくて済むよう、パッケージ、バージョン、タグ、依存関係、署名のメタデータを不変のコンテンツブロブから分離します。
バージョンと整合性のセマンティクス
セマンティックバージョニング、可変タグ、並行パブリッシュ、削除について説明します。リゾルバが不適切だと、ビルドの再現性が失われます。
配信とコスト
単にオブジェクトストレージを描くだけでなく、チャンクアップロード、再開可能性、コンテンツアドレッシング、CDN、クロスリージョンレプリケーション、ガベージコレクションについて議論します。
セキュリティとガバナンス
権限管理、テナント分離、署名、SBOM、マルウェアスキャン、監査、失効処理は、単一の運用ループを形成する必要があります。
尋ねるべき明確化のための質問
- これはnpmのようなパッケージですか、OCIイメージですか、それとも任意のビルドファイルですか？
- 1日あたりのパブリッシュ/ダウンロードレートと総ストレージ容量はどのくらいですか？
- latestのようなタグは移動可能ですか？
- 公開されたバージョンは上書き可能ですか、それとも新しいバージョンを追加することしかできませんか？
- プライベートテナント、アップストリームプロキシ、マルチリージョンリカバリは必要ですか？
- 失効処理は新しいダウンロードをブロックしますか、バイトを削除しますか、それとも証拠を保持しながらリスクとしてマークしますか？
30秒の回答フレームワーク
「私ならマルチテナントでコンテンツアドレス指定が可能なレジストリから始めます。パブリッシャーはブロブをアップロードして検証し、不変のマニフェストをコミットします。タグは既存のバージョンのみを指し、並行性制御条件下で移動します。クライアントはメタデータを読み取り、オブジェクトストレージまたはCDNからダイジェストでブロブを取得し、ダイジェストと署名を検証します。権限は名前空間とアクションを対象とします。失効処理は、監査証拠をすぐに削除することなくリスクをマークします。ホットなアーティファクトにはCDNを使用し、レプリケーション、スキャン、ガベージコレクションは非同期で実行します。」
ステップバイステップの詳細解説
ステップ1：リソースモデルの定義
リソースは名前空間、パッケージ、バージョン、タグ、マニフェスト、ブロブ、署名、来歴（provenance）です。マニフェストはダイジェスト、メディアタイプ、サイズを参照し、ブロブはそのダイジェストにおいて不変です。
ステップ2：パブリッシュの設計
クライアントはアップロードセッションを要求し、一時ストレージにチャンクを送信します。サービスは各チャンクと最終ダイジェストを検証し、マニフェストをアトミックにコミットします。期限切れのセッションはクリーンアップされ、既存のダイジェストは再利用されます。
ステップ3：バージョンとタグの処理
不変バージョンは上書きできません。タグは移動できますが、操作者、新旧のターゲット、条件付きバージョンが記録されます。依存関係の解決では、latestよりも固定バージョンとダイジェストが優先されます。
ステップ4：ダウンロードの設計
メタデータはマニフェスト、依存関係、署名を返します。ブロブ配信はRangeリクエスト、ETag、CDNをサポートします。クライアントはダイジェストを検証します。ダイジェストがキャッシュキーとなり、タグ解決には短いTTLを設定します。
ステップ5：スケーリングとリカバリ
オブジェクトストレージには大きなブロブを保持し、メタデータは名前空間とパッケージごとにパーティショニングされます。マニフェストをブロブの前または同時にレプリケートし、読み取りポリシーが満たされた場合にのみ新しいリージョンを公開します。
ステップ6：セキュリティと運用
最小権限の原則に基づく読み取り、書き込み、パブリッシュ、タグ移動、削除アクションを使用します。マルウェアのスキャン、SBOMの生成、署名と来歴の検証を行い、すべてのアクションを監査ログに書き込みます。失効したバージョンは新しいダウンロードがブロックされますが、証拠は保持ポリシーに従います。
模範的な高水準の回答
「レジストリをメタデータ、ブロブストレージ、非同期ガバナンスジョブに分割します。クライアントはチャンクアップロードセッションを作成し、ダイジェスト検証後に、不変ブロブを参照するマニフェストをトランザクションでコミットします。バージョンは上書きできず、タグの移動には条件付きバージョンを使用し履歴を保持します。ダウンロード時は固定バージョンを解決し、CDNまたはオブジェクトストレージからダイジェスト指定で取得して署名を検証します。
コンテンツアドレス指定によるキャッシングとRangeリクエストにより、アクセスが集中するブロブのコストを削減します。バックグラウンドジョブがリージョン間でレプリケーションを行い、マルウェアをスキャンし、SBOMと来歴を添付します。プライベート名前空間はテナント権限とクォータを強制します。失効処理はバージョンをブロック状態としてマークし、監査証拠を削除することなく新規ダウンロードを停止し、ビルドシステムにアラートを出します。パブリッシュ成功率、ダウンロードレイテンシのp95、キャッシュヒット率、レプリケーション遅延、不正アクセスを追跡します。」
よくある間違い
- クライアントにオブジェクトストレージの直接変更を許可する → 権限と整合性がバイパスされる → 短時間のアップロードセッションとサーバーサイドでのマニフェストコミットを使用する。
- 公開済みバージョンの上書きを許可する → ビルドが再現できなくなる → バージョンを不変にし、新しいバージョンを発行する。
- latestを恒久的なキャッシュキーとして使用する → バイト列が静かに変化してしまう → ダイジェスト単位でキャッシュし、短いTTLでタグを解決する。
- バイト列のみを保存する → 依存関係や署名が失われる → 構造化されたマニフェストと来歴を永続化する。
- すべてのリージョンを即座に読み取り可能にする → 不完全なアーティファクトが見えてしまう → マニフェスト、ブロブ、ポリシーの状態に基づいて読み取りをゲートする。
- 失効したアーティファクトを削除する → 監査やインシデントの証拠が消えてしまう → ブロック済みとしてマークし、保持ルールに基づいて非同期でクリーンアップする。
- ログインのみをチェックする → テナント間のアクセスが漏洩する可能性がある → 各境界で名前空間、アクション、アーティファクトを認可する。
- スキャン処理でパブリッシュをブロックする → アップロードレイテンシが跳ね上がる → まず隔離し、非同期でスキャンしてから、可用性状態を変更する。
フォローアップの質問と回答
フォローアップ1：2人のパブリッシャーが同じタグを同時に移動させた場合、どうなりますか？
条件付きバージョンまたはcompare-and-swapを使用します。コンフリクト時には現在のバージョンを返し、クライアントが表示された履歴をもとに再試行できるようにします。無言でlast-write-wins（後勝ち）を適用してはいけません。
フォローアップ2：完全なダウンロードをどのように保証しますか？
マニフェストにはダイジェスト、サイズ、メディアタイプが宣言されています。クライアントはダイジェストを検証し、失敗した場合は別のレプリカで再試行します。サービス側は検証失敗を監視します。
フォローアップ3：レプリケーションの遅延中にパブリッシュを進めることはできますか？
プライマリリージョンはリリースを受け入れ、レプリケーション中としてマークできます。ターゲットリージョンは、必要なマニフェスト、依存関係のブロブ、ポリシー状態の整合性が取れた後にのみ、それを公開します。
フォローアップ4：重複したブロブをどのようにガベージコレクションしますか？
アクティブなマニフェスト、署名、保持ポリシーから参照セットを構築します。参照されていないブロブをマークし、猶予期間を待って並行性を再確認した後に削除します。
フォローアップ5：来歴（provenance）はダウンロードの決定にどのように影響しますか？
署名、SBOM、来歴をマニフェストに関連付けます。ポリシールールエンジンが、テナント、環境、アーティファクトのリスクに基づいて、許可、隔離、またはアラートを判断します。
出典1：OCI Distribution Specification
OCI仕様は、配布の中心をマニフェスト、ディスクリプタ、ブロブに置き、コンテンツアドレス指定レジストリ向けのpush、pull、ダイジェスト、およびエラーのセマンティクスを定義しています。
出典2：npm Registryのメタデータ
npm Registryのメタデータは、バージョン、dist-tags、パッケージ情報を個別の関心事として扱っており、タグと不変バージョンに対する異なる整合性およびキャッシング規則をサポートしています。
出典3：SLSAサプライチェーンの完全性
GoogleのSLSAの導入では、アーティファクトの来歴、トレーサビリティ、耐改ざん性が強調されています。これらのシグナルは、レジストリの署名、SBOM、スキャン、およびダウンロードポリシーに反映できます。