Google Cloud のランディング ゾーンの設計

Last reviewed 2023-08-31 UTC

このドキュメントでは、Google Cloud のランディング ゾーンを設計する方法の概要を説明します。「クラウド基盤」とも呼ばれるランディング ゾーンは、組織がビジネスニーズに応じて Google Cloud を導入できるようにする、モジュール式でスケーラブルな構成です。ランディング ゾーンは、多くの場合、クラウド環境にエンタープライズ ワークロードをデプロイするための前提条件です。

「ランディング ゾーン」は、ゾーンやゾーンリソースではありません。

このドキュメントは、以下の概要を知りたいソリューション アーキテクト、技術者、経営幹部クラスの関係者を対象としています。

  • Google Cloud のランディング ゾーンの一般的な要素
  • ランディング ゾーンの設計に関する詳細情報の入手先
  • 企業のランディング ゾーンをデプロイする方法（事前構築済みのソリューションをデプロイするオプションを含む）

このドキュメントは、ランディング ゾーンの設計とビルドの方法を理解するために役立つシリーズの一部です。このシリーズの他のドキュメントでは、組織のランディング ゾーンの設計時に行う必要があるハイレベルの決定について説明します。このラボでは、次のタスクについて学びます。

このシリーズでは、金融サービスやヘルスケアなどの規制対象となる業界におけるコンプライアンス要件は特に取り上げていません。

Google Cloud ランディング ゾーンとは

ランディング ゾーンを使用すると、企業は Google Cloud サービスをより安全にデプロイ、使用、スケールできます。ランディング ゾーンは動的であり、企業がより多くのクラウドベースのワークロードを導入するにつれて増大します。

ランディング ゾーンをデプロイするには、まず組織リソースを作成し、オンラインのまたは請求書が発行された請求先アカウントを作成する必要があります。

ランディング ゾーンは複数の領域にまたがり、ID、リソース管理、セキュリティ、ネットワーキングなどのさまざまな要素が含まれています。ランディング ゾーンの要素で説明されているように、他の多くの要素をランディング ゾーンに含めることもできます。

次の図は、ランディング ゾーンの実装例を示しています。これは、Google Cloud でのハイブリッド クラウドとオンプレミスの接続を持つ Infrastructure as a Service（IaaS）のユースケースを示しています。

ランディング ゾーンのサンプル アーキテクチャ。

上の図のアーキテクチャ例は、次の Google Cloud サービスと機能を含む Google Cloud ランディング ゾーンを示しています。

  • Resource Manager では、組織のポリシーを使用してリソース階層が定義されます。

  • Cloud Identity アカウントはオンプレミス ID プロバイダと同期し、Identity and Access Management（IAM）は Google Cloud リソースへのきめ細かいアクセスを提供します。

  • 以下を含むネットワーク デプロイ。

    • 各環境（本番環境、開発環境、テスト環境）の共有 VPC ネットワークは、複数のプロジェクトのリソースを VPC ネットワークに接続します。
    • Virtual Private Cloud（VPC）ファイアウォール ルールは、共有 VPC ネットワーク内のワークロードとの接続を制御します。
    • Cloud NAT ゲートウェイは、外部 IP アドレスを持たないネットワーク内のリソースからインターネットへの送信接続を許可します。
    • Cloud Interconnect は、オンプレミスのアプリケーションとユーザーを接続します。（Dedicated Interconnect や Partner Interconnect など、さまざまな Cloud Interconnect オプションを選択できます）。
    • Cloud VPN は他のクラウド サービス プロバイダに接続されます。
    • Cloud DNS 限定公開ゾーンは、Google Cloud のデプロイの DNS レコードをホストします。

  • 複数のサービス プロジェクトが、共有 VPC ネットワークを使用するように構成されています。これらのサービス プロジェクトはアプリケーション リソースをホストします。

  • Google Cloud Observability には、モニタリング用の Cloud Monitoring とロギング用の Cloud Logging が含まれています。Cloud Audit Logs、Firewall Rules Logging、VPC Flow Logs は、必要なすべてのデータがログに記録され、分析に利用できるようにするうえで役立ちます。

  • VPC Service Controls の境界には、共有 VPC とオンプレミス環境があります。セキュリティ境界でサービスとリソースを分離することで、サポートされている Google Cloud サービスからデータが漏洩するリスクを軽減できます。

ランディング ゾーンの単一または標準の実装がないため、上の図は単なる例です。次のようなさまざまな要因に応じて、多くの設計上の選択を行う必要があります。

  • 業界
  • 組織構造とプロセス
  • セキュリティとコンプライアンスの要件
  • Google Cloud に移行するワークロード
  • 既存の IT インフラストラクチャとその他のクラウド環境
  • ビジネスと顧客の場所

ランディング ゾーンを構築するタイミング

ランディング ゾーンは次の機能を提供するため、最初のエンタープライズ ワークロードを Google Cloud にデプロイする前にランディング ゾーンを構築することをおすすめします。

  • 安全性を考慮して設計された基盤
  • エンタープライズ ワークロード向けのネットワーク
  • 内部コスト分散の管理に必要なツール

ただし、ランディング ゾーンはモジュール式であるため、ランディング ゾーンの最初のイテレーションは最終的なバージョンではないことがよくあります。したがって、スケーラビリティと拡張を考慮したランディング ゾーンの設計をおすすめします。たとえば、最初のワークロードでオンプレミス ネットワーク リソースへのアクセスが必要ない場合は、後でオンプレミス環境への接続を構築できます。

組織と、Google Cloud で実行する予定のワークロードの種類によっては、ワークロードによって要件が大きく異なる場合があります。たとえば、一部のワークロードには、独自のスケーラビリティまたはコンプライアンス要件があります。このような場合、組織に複数のランディング ゾーンが必要になることがあります。1 つのランディング ゾーンでほとんどのワークロードをホストし、別のランディング ゾーンで固有のワークロードをホストできます。ID、課金、組織リソースなどの要素は、ランディング ゾーン間で共有できます。ただし、ネットワーク設定、デプロイ メカニズム、フォルダレベルのポリシーなど、他の要素は異なる場合があります。

ランディング ゾーンの要素

ランディング ゾーンでは、Google Cloud で次のコア要素を設計する必要があります。

これらのコア要素に加えて、ビジネスに追加の要件がある場合があります。次の表では、これらの要素と、その詳細を確認できる場所について説明しています。

ランディング ゾーンの要素 説明
モニタリングとロギング すべての関連データがログに記録されるようにモニタリングとロギングの戦略を設計し、データの可視化と実用的な例外を通知するアラートのダッシュボードを用意します。
詳しくは以下をご覧ください。
バックアップと障害復旧 バックアップと障害復旧の戦略を設計します。
詳しくは以下をご覧ください。
コンプライアンス 組織に関連するコンプライアンス フレームワークに従います。
詳しくは、コンプライアンス リソースセンターをご覧ください。
費用対効果と制御 ランディング ゾーン内のワークロードの費用をモニタリングして最適化する機能を設計します。
詳しくは以下をご覧ください。
API 管理 開発した API 用のスケーラブルなソリューションを設計します。詳細については、Apigee API をご覧ください。
クラスタ管理

ベスト プラクティスに従って Google Kubernetes Engine（GKE）クラスタを設計し、スケーラブルで復元力のある監視可能なサービスを構築します。

詳しくは以下をご覧ください。

ランディング ゾーンの設計とデプロイのベスト プラクティス

ランディング ゾーンを設計してデプロイするには計画が必要です。タスクを実行し、プロジェクト管理プロセスを使用するための適切なチームが必要です。このシリーズで説明する技術的なベスト プラクティスに従うこともおすすめします。

チームを作る

社内の複数の技術チームのスタッフで構成されるチームを編成します。チームには、セキュリティ、ID、ネットワーク、オペレーションなど、すべてのランディング ゾーン要素を構築できる人を含める必要があります。Google Cloud を理解している、チームを主導するクラウド技術者を決めます。チームには、プロジェクトを管理して実績を追跡するメンバーと、アプリケーションまたはビジネス オーナーと共同作業するメンバーを含める必要があります。

プロセスの初期にすべての関係者が関与するようにします。関係者は、プロセスの範囲について共通の理解を持ち、プロジェクトの開始時に大まかな決定を行う必要があります。

プロジェクト管理をランディング ゾーンのデプロイに適用する

ランディング ゾーンの設計とデプロイには数週間かかる場合があるため、プロジェクト管理は必要不可欠です。プロジェクトの目標が明確に定義されてすべての関係者に伝達され、すべての関係者がプロジェクトの変更に関する最新情報を受け取るようにします。定期的なチェックポイントを定義し、運用プロセスと予期しない遅延を考慮した現実的なタイムラインでマイルストーンに合意します。

ビジネス要件に合わせるために、Google Cloud に最初にデプロイするユースケース用の最初のランディング ゾーンデプロイを計画します。水平方向の多層ウェブ アプリケーションなど、Google Cloud 上で最も簡単に実行できるワークロードを最初にデプロイすることをおすすめします。これらのワークロードは、新しいワークロードまたは既存のワークロードです。既存のワークロードの移行準備状況を評価するには、Google Cloud への移行: スタートガイドをご覧ください。

ランディング ゾーンはモジュール式であるため、最初のワークロードの移行に必要な要素を中心として初期設計を行い、後で他の要素を追加することを検討してください。

技術的なベスト プラクティスに従う

Terraform などで Infrastructure as Code（IaC）の使用を検討してください。IaC は、デプロイを繰り返し、モジュール化できるようにするものです。GitOps を使用してクラウド インフラストラクチャの変更をデプロイする CI / CD パイプラインを使用すると、内部ガイドラインに従い、適切な制御を実施できます。

ランディング ゾーンを設計する際は、チームで技術的なベスト プラクティスを考慮に入れるようにしてください。ランディング ゾーンに関する決定について詳しくは、このシリーズの他のガイドをご覧ください。

次の表に、このシリーズに加え、ユースケースに応じてベスト プラクティスに従う場合に役立つフレームワーク、ガイド、ブループリントを示します。

関連ドキュメント 説明
Google Cloud 設定チェックリスト 本番環境に対応したスケーラブルなエンタープライズ ワークロード向けに Google Cloud を設定する際に役立つ、高水準のチェックリスト。
Security Foundation ブループリント CISO、セキュリティ担当者、リスク マネージャー、コンプライアンス責任者を対象とした、Google Cloud のセキュリティ ベスト プラクティスの独自の見解。
Google Cloud アーキテクチャ フレームワーク 安全性、効率、復元性、パフォーマンス、費用対効果の高いクラウド トポロジを設計、運用するためのアーキテクト、デベロッパー、管理者などのクラウド アーキテクト向けの推奨事項とベスト プラクティス。
Terraform ブループリント Terraform モジュールとしてパッケージ化され、Google Cloud のリソースの作成に使用できるブループリントとモジュールのリスト。

ランディング ゾーンの実装に役立つリソースを特定する

Google Cloud には、ランディング ゾーンの設定に役立つ次のオプションがあります。

これらのサービスはすべて、世界中のさまざまな業界やビジネスニーズに対応するように設計されたアプローチを採用しています。ユースケースに最適な選択ができるように、Google Cloud アカウント チームと協力して選択を行い、プロジェクトを確実に成功させることをおすすめします。

次のステップ