Google Distributed Cloud

解決する課題

クラウドの俊敏性は欲しいが、規制・データ主権・低遅延などの理由で「データや処理を特定の場所に置かなければならない」というケースは多くあります。Google Distributed Cloud（GDC）は、Google Cloud のインフラとマネージドサービスを、利用者のデータセンターやエッジロケーションへ拡張することで、この相反する要求を両立させます。

• 規制やデータ主権の要件で、データや処理を自国内・自社内に留めたい
• 工場・店舗・基地局などのエッジで低遅延に処理したい（クラウド往復を避ける）
• インターネットから完全に切り離したエアギャップ環境で機密ワークロードを動かしたい
• オンプレとクラウドで運用モデルや API を統一し、二重運用の負担を減らしたい
• 既存のオンプレ資産を活かしつつ、Kubernetes ベースのモダンな基盤へ移行したい

AWS でいえば AWS Outposts（および規制向けの各種ソブリン/エッジ製品）に近い位置づけです。クラウドの管理体験をオンプレ・エッジへ持ち出す、という発想が共通しています。

主要概念と用語

• Google Distributed Cloud（GDC）: Google Cloud のインフラとサービスを、利用者のデータセンターやエッジへ拡張して動かす製品群の総称
• 接続型（connected）: Google Cloud のコントロールプレーンとネットワーク接続を保ったまま運用する形態。クラウド側のコンソールやサービスと連携しやすい
• エアギャップ型（air-gapped）: インターネットや Google Cloud から物理的・論理的に隔離して運用する形態。管理機能も含めてローカルで完結し、機密性・主権要件の厳しい用途に向く
• エッジ構成: 小規模なハードウェアを店舗・工場・基地局などの分散拠点に置き、現場で処理する構成。低遅延やオフライン耐性が目的
• GKE（Kubernetes）基盤: GDC 上のワークロードは Kubernetes を中心に動く。クラウドの GKE と一貫した運用モデルを採れる
• フリート（fleet）管理: 複数のクラスタ/拠点をまとめて構成・ポリシー適用・監視する管理単位
• コントロールプレーン: クラスタの状態を管理する制御層。接続型はクラウド連携、エアギャップ型はローカルで完結する点が異なる
• ハードウェアアプライアンス: GDC はソフトウェアだけでなく、検証済みハードウェアと組み合わせて提供される構成がある

仕様・制限・クォータ

• 接続型とエアギャップ型で利用できるサービスや管理経路が異なる。要件（接続可否・データ所在）に応じて形態を選ぶ
• ワークロードは Kubernetes 前提が基本で、VM やコンテナを Kubernetes の枠組みで動かす
• オンプレ/エッジに置く以上、物理設置・電源・ネットワーク・ハードウェア保守といった現地要件が伴う
• 利用できるリージョン/サービス/ハードウェア構成は提供形態や地域によって異なり、個別の要件確認・契約が前提になることが多い
• クラスタやノードの規模、対応するワークロード種別には構成ごとの上限があり、バージョンや形態で変動する

具体的な対応サービス・ハードウェア仕様・上限値は形態やリリースで変動するため、設計時は公式ドキュメントと提供条件を必ず確認してください。

内部の仕組み

GDC は、Google Cloud で培われた GKE / Anthos のハイブリッド運用モデルを土台にしています。ワークロードは Kubernetes 上で動き、クラスタやポリシーはフリートとしてまとめて管理されます。これにより、クラウドとオンプレ・エッジで API と運用手順をできるだけ揃えられます。

接続型では、利用者の拠点に置いたインフラが Google Cloud のコントロールプレーンと連携します。クラウド側のコンソールやサービスと統合した管理・監視がしやすく、ハイブリッド構成の一部としてオンプレを組み込む使い方に向きます。

エアギャップ型では、コントロールプレーンや管理機能までをローカルで完結させ、インターネットや Google Cloud から隔離した状態で運用します。アップデートやイメージの取り込みも隔離前提の手順で行うため、機密性・主権要件の厳しい政府系や重要インフラ向けの用途に適します。

エッジ構成では、より小型のハードウェアを多数の拠点に分散配置し、現場での低遅延処理やオフライン時の継続稼働を狙います。いずれの形態でも、Kubernetes を共通言語にすることで、ワークロードの移植性と運用の一貫性を確保しています。

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

• 最初に接続型/エアギャップ型とデータセンター/エッジの軸で形態を確定し、要件に合う構成を選ぶ
• ワークロードは Kubernetes ネイティブに設計し、クラウドの GKE と運用モデルを揃えて移植性を高める
• 複数拠点はフリートとして一元管理し、構成・ポリシー・更新をまとめて適用する
• エッジ拠点はオフライン耐性を前提に設計し、接続断時でも現場処理が続くようにする
• アップデートやパッチは計画的な運用ウィンドウで実施し、隔離環境では取り込み手順を整備する
• 可能な範囲でクラウドと共通の CI/CD・IaC・監視を使い、ハイブリッド運用の二重化を避ける

運用・監視

• クラスタやワークロードの状態は、形態に応じたフリート管理/監視基盤で把握する。接続型はクラウド側の監視と統合しやすい
• エアギャップ型では監視・ログもローカルで完結するため、現地で完結する可観測性スタックを用意する
• ノードやハードウェアの健全性・容量・更新状況を定期的に点検し、現地保守の計画を立てる
• Kubernetes ワークロードの障害は、クラウドの GKE と同様に Pod のログ・イベント・リソース状況から切り分ける
• 更新はリリースに追従しつつ、業務影響の少ない時間帯に計画的なアップグレードとして実施する

コスト

GDC は「ソフトウェア/プラットフォーム利用料」と「現地に置くハードウェア・設置・保守」の両面でコストを考えます。クラウドの従量課金だけでなく、オンプレ特有の固定的な費用が乗る点が特徴です。

オンプレ・エッジに資産を置く以上、稼働率にかかわらず発生する固定費の比率が高くなりがちです。拠点数・ハードウェア規模・運用体制を含めた総保有コストで評価するのが現実的です。

セキュリティ

• データ所在を要件どおりに保てるかを最優先で確認する。エアギャップ型は隔離によってデータ主権・機密性の要件に応えやすい
• 拠点・クラスタへのアクセスは IAM と RBAC を組み合わせ、操作権限を最小化する
• ワークロード間通信は Network Policy などで最小化し、ラテラルムーブメントを抑える
• イメージは検証済みのものだけを取り込み、隔離環境では取り込み経路と検証手順を厳格に管理する
• 物理設置を伴うため、現地のハードウェア・施設セキュリティ（入退室・物理保護）も設計対象に含める

関連サービス・比較

GDC はオンプレ・エッジ向けの基盤ですが、フルマネージドのクラウド上で Kubernetes を使う場合は GKE が基本選択になります。どこでワークロードを動かす必要があるか（クラウドか、自社/エッジか）で選択が分かれます。

ハンズオン / CLI例

# GDC 関連の Kubernetes クラスター（フリート登録済み）の認証情報を取得
gcloud container fleet memberships get-credentials demo-membership

# フリートに登録されているメンバーシップ（クラスター）一覧を確認
gcloud container fleet memberships list

# kubectl で対象クラスターのノード/ワークロードを確認
kubectl get nodes
kubectl get pods --all-namespaces

# ワークロードをデプロイ（クラウドの GKE と同じ Kubernetes マニフェスト）
kubectl apply -f deployment.yaml