クロスクラウド依存関係の許可リスト
| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
kerusu | devops tenant-scale | 2026-06-30 |
概要
この ADR は ADR-016: Cross Cloud Dependencies を拡張します。ADR-016 は、Cell が別のクラウドプロバイダーに依存してはならないことを定めています。この ADR はそれをデフォルトとして維持し、狭く統制された例外を定義します。つまり、定義された移行期間に限って許容されるクロスクラウド依存関係の、短く明示的に名付けられた許可リストです。各依存関係には、指名された owner とサンセット条件があります。運用原則は デフォルトでは封じ込め、例外としてクロスクラウドです。
コンテキスト
ADR-016 は、コスト、レジリエンス、明確な分離のために、Cells のルールとして単一クラウドでの自己完結を定めました。実際には、いくつかのコンポーネントは GitLab が中央で運用するサービスであり、クラウドごとの同等物がまだありません。そのため、完全にセルラーなマルチクラウドアーキテクチャへ移行する間、「他方」のクラウド上の Cells がそれらを利用するには、クラウドをまたいでアクセスする必要があります。
具体的かつすでに稼働している例は AI Gateway です。現在 AWS の Dedicated にデプロイされた Cells は、Duo/AI 機能を提供するために GCP でホストされている AI Gateway にアクセスします。これは機能している、受け入れ済みの依存関係であり、欠陥ではありません。ADR-016 を絶対的なものとして扱うと、私たちが実際に運用しているシステムを誤って表現することになり、クラウドごとの同等物がまだリージョン化されていない、真に共有される中央サービスについて、チームに認可された道筋を与えられません。
管理すべきリスクは、クロスクラウド依存関係が存在することではなく、それらが統制なく増えていくことです。明示的なリストと追加基準がなければ、アドホックなクロスクラウド呼び出しが蓄積し、ADR-016 の最終状態（2 つの独立した単一クラウドスタック）に到達できなくなります。
決定
あるクラウドプロバイダー上のコンポーネントは、その依存関係が下記の許可リストにある場合にのみ、別のクラウドプロバイダー上のコンポーネントに依存できます。リストにないものはすべて ADR-016 の対象であり、単一クラウド内で自己完結している必要があります。
許可リストは、時間とともに増えるのではなく縮小することを想定しています。エントリの追加は、この ADR の修正（新しいリビジョンまたは置き換え ADR）として記録されるアーキテクチャ上の決定であり、アドホックに行われる実装上の選択ではありません。
許可されるクロスクラウド例外の基準
エントリを許可リストに追加できるのは、以下のすべてを満たす場合のみです。
- クラウドごとの同等物がまだない。 そのコンポーネントは GitLab が中央で運用しており、クラウドごとのデプロイは自明ではない、またはまだ資金が割り当てられていません。
- 指名された owner とサンセット条件。 その依存関係には DRI と、それを廃止する条件（何によってなくなるのか、おおよそいつなのか）が文書化されています。
- 境界づけられ、理解されたトラフィック。 クロスクラウド egress は、付随的なものではなく、コストとレイテンシのためにモデル化されています。
- 可能な場合はグレースフルデグラデーション。 ADR-016 のレジリエンスに関する根拠と一致するように、リンク障害時には Cell 全体を停止させるのではなく、依存する機能がグレースフルに劣化します。
許可リスト（移行期）
| 依存関係 | クラウドをまたぐ理由 | Owner | サンセット条件 |
|---|---|---|---|
| 任意の Cell → GCP AI Gateway | 中央ホスト型の Duo/AI モデル仲介。クラウドごとの同等物がない。AWS 上の Dedicated ですでに稼働中。 | AI / Cloud Connector | リージョン別 / クラウド別の AI Gateway ホスティング、またはテナントごとのセルフホスト型モデルオプション |
| AWS Cell → GCP Topology Service | Org の分類 / claim、Cell の発見 / ヘルス、SSH ルーティング — 現在は単一の中央インスタンス（ADR-019 を参照） | Cells Infrastructure | Topology Service のクラウドごとのレプリケーション（決定保留中） |
| GCP → AWS via Siphon+NATS (HA-VPN / Transit Gateway) | Legacy Cell から AWS Protocell への Org データ移行 | ODM / Cells migration tooling | コホートの移行完了後に自動的に削除 |
| AWS Cell → Artifact Registry | GCP にのみデプロイされています | Artifact Registry | Cellular Target |
| AWS Cell → Secrets Manager | GCP にのみデプロイされています | Secrets Manager | Cellular Target |
| AWS S3 → GCP Elastic Agent (OIDC workload identity) | 中央運用の Elasticsearch への Cells ログ取り込み | Security Logging | クラウドごとのログシンク（正当化される場合 / 時期） |
この表にない依存関係は、単一クラウド内に封じ込める必要があります。
ネイティブなクロスクラウドレプリケーションとの関係
ネイティブデータレプリケーションによってクラウド間で単一の論理サービスを維持するコンポーネント（たとえば、1 つの GitLab.com realm を維持するために YugabyteDB のクロスクラウドレプリケーションを使う GATE/Auth スタック）は、許可リストのエントリではありません。これは実行時のクロスクラウド呼び出しを行いません。各 Cell はクラウド内のレプリカとのみ通信します。これは、真に共有されるステートフルなケースに推奨されるパターンであり、ADR-016 に準拠したままです。許可リストは、実行時のクロスクラウド依存関係のみに限定されます。
結果
ポジティブ
- 正直なモデル。 文書化されたアーキテクチャは、理想化されたものではなく、実際に本番環境で稼働しているシステム（AWS Cells から AI Gateway への依存）と一致します。
- 統制された表面積。 クロスクラウド依存関係は、誰も所有していない創発的な性質ではなく、列挙され、owner があり、期限が区切られた集合になります。
- ADR-016 の最終状態への明確な道筋。 各エントリにはサンセット条件があるため、2 つの独立した単一クラウドスタックへ向かう進捗を測定できます。
ネガティブ
- 継続的なガバナンスコスト。 リストはレビューされ、エントリはサンセットへ向けて能動的に進められる必要があります。そうでなければ固定化します。
- 残存するクロスクラウドコストとコンプライアンス上の露出。 エントリが残っている間（特に AI Gateway）、クロスクラウド egress コストとデータ egress コンプライアンスの精査が続きます。
緩和策
- 各 Cells アーキテクチャ / CTO レビューで許可リストをレビューし、エントリのサンセットに向けた動きを報告します。
- すべての新しいエントリについて、サンセット条件を後回しにせず、最初から定義して持ち込むことを求めます。
- 共有コンポーネントがステートフルな場合は、新しい実行時クロスクラウド依存関係よりも、ネイティブレプリケーションパターン（GATE/Auth）を優先します。
代替案
- ADR-016 を絶対的なものとして維持する（例外なし）。 却下: 稼働中の AI Gateway 依存関係と矛盾し、共有中央サービスに認可された移行パスを残しません。
- リストなしでケースバイケースにクロスクラウド依存関係を許可する。 却下: これは現状の失敗モードです — owner もサンセットも集約ビューもないまま依存関係が蓄積し、単一クラウドの最終状態に到達できなくなります。
c955a93f)