クラウド間の依存関係
This page contains information related to upcoming products, features, and functionality.
It is important to note that the information presented is for informational purposes only.
Please do not rely on this information for purchasing or planning purposes.
The development, release, and timing of any products, features, or functionality may be
subject to change or delay and remain at the sole discretion of GitLab Inc.
| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
sxuereb | devops tenant-scale | 2025-07-21 |
コンテキスト
Cell は AWS と GCP の両方のクラウドプロバイダーで動作します。 これにより、両方のクラウドプロバイダーで Cell を個別にプロビジョニングする必要があるという複雑さが生じます。
決定事項
あるクラウドプロバイダーで Cell をプロビジョニングする際、他のクラウドプロバイダーに依存すべきではありません。
例:
- ルート CA: GCP に単一の共有ルート CA を持つのではなく、各クラウドプロバイダーで個別のルート CA を管理します。
- ランタイムアーティファクト: GitLab アプリケーションの実行に必要な Docker イメージを Google Artifact Registry と Amazon Elastic Container Registry の両方にプッシュします。
この分離の利点:
- クリーンなアーキテクチャ: コードベースはクラウドプロバイダー間の明確な分離を維持します。
- コスト最適化: クラウド間のイングレス/エグレスコストを排除します。
- 耐障害性の向上: 単一のクラウドプロバイダーで障害が発生した場合でも、もう一方のプロバイダーで Cell を運用し続けることができます。
結果
- データの重複: クラウド間でいくつかのデータ（Docker イメージ、Helm チャート）を重複させる必要がありますが、これはわずか数 GB のデータに過ぎません。
- メンテナンスの増加: 重複したインフラコンポーネントを管理することで、追加の運用オーバーヘッドが発生します。
- 同期の複雑さ: 両方のクラウドプロバイダー間でアーティファクトの整合性を確保する必要があります。これにより AWS と GCP 環境間で設定のドリフトが発生するリスクが増大し、デバッグが困難な問題やインシデントが発生する可能性があります。
代替案
共有リソース（例: GCP のみのルート CA）に対して 1 つのクラウドプロバイダーをプライマリソースとして使用する方法があります。クラウド間の依存関係と単一障害点の可能性があるため、この案は却下されました。
最終更新 July 30, 2026: Merge pull request #483 from kyama0/translation/batch-2026-07-29-1 (
c955a93f)