Google Cloud への移行: 基盤の計画と構築

Last reviewed 2024-07-31 UTC

このドキュメントは、ワークロードを処理する基本的なクラウド インフラストラクチャを構築する際に利用できます。また、このインフラストラクチャでアプリケーションをどのようにサポートするかを計画する際にも役立ちます。これには、ID の管理、組織とプロジェクトの構造、ネットワーク構成などが含まれます。

このドキュメントは、Google Cloud への移行に関する次の複数のパートからなるシリーズの一部です。

次の図は、移行の過程を示しています。

4 フェーズの移行パス

このドキュメントでは、オンプレミス環境、非公開のホスティング環境、または別のクラウド プロバイダから Google Cloud への移行を計画する際に役立つ情報を提供します。また、移行について検討している場合、その概要を把握するためにも利用できます。このドキュメントは、移行のユースケースに焦点を当てた基盤を構築する際に、利用可能なプロダクトと決定事項を理解するうえで役立ちます。

事前作成された実装可能なオプションについては、以下をご覧ください。

基盤の設計に関するその他のベスト プラクティスのガイダンスについては、以下をご覧ください。

Google Cloud への移行を計画する際には、クラウド アーキテクチャに関するトピックスとコンセプトを一通り理解する必要があります。基盤の計画が不十分であると、ビジネスの遅れ、混乱、中断が生じ、クラウド移行が失敗してしまう可能性が生じます。このガイドでは、Google Cloud 基盤のコンセプトと判断事項の概要を説明します。

このドキュメントの各セクションでは、Google Cloud の基盤構築の前に、お客様の組織において明確にしておくべき課題事項を提示しています。すべての課題事項を網羅しているわけではありません。お客様の組織にとって何が適切かについて、アーキテクチャ チームと経営陣との間の意見交換を促進にすることを目的としています。インフラストラクチャ、ツール、セキュリティ、アカウント管理の計画は、お客様のビジネスに応じた固有のものであり、綿密な検討が必要となります。このドキュメントを読み終え、お客様の組織向けの課題事項に回答した時点で、Google Cloud への移行をサポートするクラウド インフラストラクチャとサービスの正式な計画を開始する準備が整います。

エンタープライズ向けの検討事項

次の課題事項について、お客様の組織における状況を検討してください。

  • Google Cloud への移行に際して、お客様の組織とインフラストラクチャ プロバイダとの間で IT に関する責任分担のどの部分に変更が生じるか。
  • Google Cloud への移行中、および移行後の定期的なコンプライアンス適合のニーズ（HIPAA や GDPR など）をどのように満たすか。
  • データの保存場所と処理場所を、データ所在地の要件に従いつつどのように管理するか。

共有責任モデル

お客様の組織と Google Cloud との間の共有責任モデルは、従来のものとは異なる可能性があり、それらのビジネスへの影響を把握する必要があります。リソースのプロビジョニング、構成、利用において過去に適用していたプロセスは、変更される可能性があります。

利用規約と Google セキュリティ モデルを参照して、お客様の組織と Google との間の契約関係、およびパブリック クラウド プロバイダを利用する影響の概要を理解してください。

コンプライアンス、セキュリティ、プライバシー

多くの組織には、業界と政府の標準、規制、認証に関するコンプライアンス要件があります。エンタープライズ ワークロードの多くは規制当局による調査の対象であり、お客様組織とクラウド プロバイダによるコンプライアンスの証明が求められることがあります。HIPAA や HITECH の下でビジネスが規制されている場合は、ユーザーの責務と、Google Cloud サービスが規制を受ける範囲について必ず把握しておいてください。Google Cloud が取得している認証と満たしているコンプライアンス基準については、コンプライアンス リソース センターをご覧ください。地域固有または業界固有の規制の詳細については、Google Cloud と一般データ保護規則（GDPR）をご覧ください。

信頼とセキュリティは、すべての組織にとって重要です。Google Cloud は、さまざまなサービス向けのセキュリティの責任共有モデルを採用しています。

お客様のデータ、およびお客様の顧客のデータのプライバシー保護に関する Google の取り組みは、Google Cloud の信頼原則でご確認いただけます。Google のセキュリティとプライバシーの設計方法の詳細については、Google インフラストラクチャのセキュリティ設計の概要をご覧ください。

データ所在地に関する検討事項

コンプライアンスにおいて、地理的事項も重要な考慮事項となります。データ所在地に関する要件を把握し、新しいリージョンにワークロードをデプロイしてデータの保存場所と処理場所を管理するためのポリシーを実装していることを確認します。リソースの場所に関する制約の使用方法を把握して、事前承認されたリージョンにのみワークロードをデプロイできるようにします。ワークロードのデプロイ ターゲットを選択する際は、各 Google Cloud サービスの地域性について把握する必要があります。法規制のコンプライアンス要件と、コンプライアンスの確保に役立つガバナンス戦略の実装方法を確実に理解します。

リソース階層

次の課題事項について、お客様の組織における状況を検討してください。

  • 既存のビジネスと組織構造を Google Cloud にどうマッピングするか。
  • リソース階層の変更はどのくらいの頻度で発生するか。
  • プロジェクトの割り当てがクラウドでリソースを作成する能力にどの程度影響を与えるか。
  • 既存のクラウド デプロイメントと移行したワークロードを統合するにはどのようにすればよいか。
  • 複数のチームを複数の Google Cloud プロジェクトで同時に管理するためのベストな手段は何か。

現行のビジネス プロセス、コミュニケーションのライン、レポート構造は、Google Cloud リソース階層の設計に反映されます。リソース階層により、クラウド環境に必要な構造を規定し、リソース消費の請求方法を決定して、ロールと権限を付与するセキュリティ モデルを確立します。これらの側面を現在のビジネスに適用する方法を理解し、これらのプロセスを Google Cloud に移行する方法を計画する必要があります。

Google Cloud リソースについて

リソースは、すべての Google Cloud サービスを構成する基本要素です。組織リソースは、Google Cloud リソース階層の頂点になります。組織に属するすべてのリソースは組織ノード下でグループ化されます。この構造により、組織に属するすべてのリソースを集中管理できます。

組織には 1 つ以上のフォルダを含めることができ、各フォルダには 1 つ以上のプロジェクトを含めることができます。フォルダを使用すると、関連プロジェクトをグループ化できます。

Google Cloud プロジェクトには、Compute Engine、仮想マシン（VM）、Pub/Sub トピック、Cloud Storage バケット、Cloud VPN エンドポイント、その他の Google Cloud サービスなどのサービス リソースがあります。Google Cloud コンソール、Cloud Shell、Cloud APIs を使用して、リソースを作成できます。環境が頻繁に変更されることが予想される場合は、リソース管理の効率化のために Infrastructure as a Code（IaC）の採用を検討してください。

Google Cloud プロジェクトの管理

Google Cloud リソース階層の計画と管理について詳しくは、Google Cloud ランディング ゾーンのリソース階層を決定するをご覧ください。すでに Google Cloud を利用しており、テストや概念実証用に独立したプロジェクトを作成している場合は、既存の Google Cloud プロジェクトを組織に移行できます。

Identity and Access Management

次の課題事項について、お客様の組織における状況を検討してください。

  • Google Cloud リソースへのアクセスの制御、管理、監査はどこが担当するか。
  • Google Cloud への移行時に、既存のセキュリティ ポリシーとアクセス ポリシーをどのように変更するか。
  • ユーザーとアプリを Google Cloud サービスと安全に連携させるにはどうすればよいか。

Identity and Access Management（IAM）により、Google Cloud リソースに対するアクセスを詳細に設定できます。Cloud Identity は、別のサービスであるものの関連するサービスで、ID の移行と管理に役立ちます。大局的にみると、Google Cloud リソースへのアクセスをどのように管理するのかを理解することで、IAM のプロビジョニング、構成、維持の内容が自ずと決まります。

ID について

Google Cloud では、認証とアクセス管理に ID が使用されます。Google Cloud リソースにアクセスするには、組織のメンバーが Google Cloud で認識される ID を保有している必要があります。Cloud Identity は IDaaS（Identity as a Service）プラットフォームであり、Google Cloud リソースにアクセスできるユーザーとグループの中央管理ができます。Cloud Identity のユーザーを設定することで、何千ものサードパーティ SaaS（Software as a Service）アプリケーションを使用したシングル サインオン（SSO）を設定できます。Cloud Identity の設定方法は、ID の管理方法によって異なります。

Google Cloud の ID プロビジョニングのオプションについて詳しくは、Google Cloud に ID をオンボーディングする方法を決定するをご覧ください。

アクセス管理について

アクセス管理のモデルは、次の 4 つの基本コンセプトで構成されています。

  • プリンシパル: リソースへのアクセスが許可されている Google アカウント（エンドユーザーの場合）、サービス アカウント（Google Cloud プロダクトの場合）、Google グループ、Google Workspace アカウント、Cloud Identity アカウントを使用できます。プリンシパルは、許可されていない操作を行うことはできません。
  • ロール: 権限の集合
  • 権限: リソースに対して許可されるオペレーションが決まります。プリンシパルにロールを付与すると、そのロールに含まれるすべての権限が付与されます。
  • IAM ポリシー: 一連のプリンシパルをロールにバインドします。リソースにアクセスできるプリンシパルを定義する際は、ポリシーを作成してリソースに接続します。

プリンシパル、ロール、権限を適切に設定して効果的に管理することで、Google Cloud のセキュリティ対策の骨組を形成できます。アクセス管理によって、内部からの不正使用や、外部からのリソースへの不正アクセスからユーザーを保護できます。

アプリケーション アクセスについて

ユーザーやグループの他に、サービス アカウントと呼ばれる別の種類の ID があります。サービス アカウントとは、プログラムやサービスが Google Cloud リソースの認証やアクセスに使用できる ID のことです。

ユーザー管理サービス アカウントには、IAM を使用して明示的に作成、管理するサービス アカウントと、すべての Google Cloud プロジェクトに組み込まれた Compute Engine のデフォルト サービス アカウントがあります。サービス エージェントは自動的に作成され、ユーザーの代理として Google の内部プロセスを実行します。

サービス アカウントを使用する際に重要なのは、アプリケーションのデフォルト認証情報を理解し、推奨されるサービス アカウントのベスト プラクティスに従って、リソースが過剰なリスクにさらされないようにすることです。最も一般的なリスクは、重要なアプリケーションが依存しているサービス アカウントの権限昇格や誤った削除です。

ベスト プラクティスを実践する

ID とアクセスを効果的に管理するためのベスト プラクティスについて詳しくは、ID とアクセスを管理するをご覧ください。

課金

利用する Google Cloud リソースの支払い方法は、お客様のビジネスにとって重要な検討事項であるとともに、Google Cloud との関係における重要な部分です。Google Cloud コンソールの Cloud Billing で、その他のクラウド環境とまとめて請求を管理できます。

リソース階層と課金のコンセプトは密接に関連しています。そのため、お客様とビジネス上の関係者によるコンセプトの理解が重要となります。

費用を追跡して管理する際に役立つベスト プラクティス、ツール、手法について詳しくは、費用の最適化をご覧ください。

接続性とネットワーキング

Google Cloud でのネットワーク設計の詳細については、以下をご覧ください。

移行元の環境が別のクラウド サービス プロバイダにある場合は、Google Cloud 環境との接続が必要になる場合があります。詳細については、他のクラウド サービス プロバイダを Google Cloud に接続するためのパターンをご覧ください。

本番環境のデータとワークロードを Google Cloud に移行する際は、接続ソリューションの可用性が移行の成功にどのように影響するかを考慮することをおすすめします。たとえば、特定のトポロジに従ってプロビジョニングすると、Cloud Interconnect が本番環境レベルの SLA をサポートします。

移行元の環境から Google Cloud 環境にデータを移行する際は、プロトコル オーバーヘッドを考慮して最大伝送単位（MTU）を調整する必要があります。これにより、データを効率的かつ正確に転送できます。この調整は、データの断片化やネットワーク パフォーマンスの問題に起因する遅延を防ぐうえでも役立ちます。たとえば、Cloud VPN を使用して移行元の環境を Google Cloud 環境に接続する場合は、伝送ユニットごとに、VPN プロトコルのオーバーヘッドに対応するために MTU を低い値に構成する必要がある場合があります。

Google Cloud への移行中に接続の問題が発生しないようにするには、次のことをおすすめします。

  • 移行元の環境と Google Cloud 環境の全体で DNS レコードが解決されることを確認します。
  • 移行元の環境と Google Cloud 環境間のネットワーク ルートが環境全体で正しく伝播されるようにします。

VPC で独自のパブリック IPv4 アドレスをプロビジョニングして使用する必要がある場合は、お客様所有 IP アドレスの使用をご覧ください。

DNS オプションについて

Cloud DNS は、パブリック ドメイン ネーム システム（DNS）サーバーとして機能します。Cloud DNS を実装する方法について詳しくは、Cloud DNS のベスト プラクティスをご覧ください。

送信元または宛先に応じて Cloud DNS がクエリに応答する方法をカスタマイズする必要がある場合は、DNS ポリシーの概要をご覧ください。たとえば、既存の DNS サーバーにクエリを転送するように Cloud DNS を構成できます。また、クエリ名に基づいて限定公開 DNS のレスポンスをオーバーライドすることもできます。

VPC には、内部 DNS という、別であるものの同様のサービスが含まれています。自身の DNS サーバーを手動で移行して構成する代わりに、プライベート ネットワークの内部 DNS サービスを使用できます。詳細については、内部 DNS の概要をご覧ください。

データ転送について

オンプレミスのネットワーキングは、クラウド ネットワーキングとは根本的に異なる方法で管理、料金設定されています。独自のデータセンターやコロケーション施設を管理する場合には、ルーター、スイッチ、ケーブルを設置するための一定の先行設備投資が必要です。クラウドの場合、ハードウェアの導入にかかる固定費用ならびに継続的なメンテナンス費用ではなく、データ転送費用に対して課金されます。クラウドにおけるデータ転送費用を理解して、データ転送費用を正確に計画、管理してください。

トラフィック管理の計画に際して、次の 3 つの課金方法があります。

  • 上り（内向き）トラフィック: 外部ロケーションから Google Cloud 環境に入るネットワーク トラフィック。外部ロケーションとしては、公共のインターネット、オンプレミス ロケーション、その他のクラウド環境が挙げられます。上り（内向き）トラフィックについては、Google Cloud のほとんどのサービスで無料です。Cloud Load Balancing、Cloud CDN、Google Cloud Armor など、インターネット接続されるトラフィック管理を扱うサービスは、上り（内向き）トラフィックの処理量に基づいて課金されます。
  • 下り（外向き）トラフィック: Google Cloud 環境から出ていくネットワークト ラフィックです。下り（外向き）トラフィックの課金は、多くの Google Cloud サービスに適用されます。たとえば、Compute Engine、Cloud Storage、Cloud SQL、Cloud Interconnect などです。
  • リージョンとゾーンのトラフィック: Google Cloud でリージョンやゾーンの境界を通過するネットワーク トラフィックは、帯域幅課金の対象になることもあります。これらの課金は、障害復旧と高可用性のためにどのようなアプリ設計を行うかに影響します。下り（外向き）トラフィックの課金と同様に、多くの Google Cloud サービスにはクロス リージョンとクロスゾーン トラフィック課金が適用され、高可用性と障害復旧を計画する際には考慮に入れる必要があります。たとえば、別のゾーンのデータベース レプリカにトラフィックを送信すると、クロスゾーン トラフィックの課金が発生します。

ネットワーク設定の自動化と管理

Google Cloud では、物理ネットワーク レイヤが仮想化されます。お客様は、ソフトウェア定義ネットワーキング（SDN）を使用して、ネットワークのデプロイと構成を行います。ネットワークを一貫性と再現性のある方法で構成するには、環境を自動的にデプロイまたは破棄する方法を理解する必要があります。Terraform などの IaC ツールを利用できます。

セキュリティ

Google Cloud のシステムのセキュリティの管理と維持の方法、および使用するツールは、オンプレミス インフラストラクチャの管理の場合とは異なります。新たな脅威の出現、新製品の投入、セキュリティ モデルの改善に適応するため、採るべきアプローチは時間の経過とともに変化し、進化します。

Google とお客様との責任分担は、現在のプロバイダとのものとは異なる場合があり、相違点を理解することが、ワークロードのセキュリティとコンプライアンスを確実に継続するうえで非常に重要です。強力で検証可能なセキュリティと法令遵守は、互いに関連する場合があります。強力な管理と監視手法、Google Cloud のベスト プラクティスの一貫した実装、アクティブな脅威の検出とモニタリングはその端緒となります。

Google Cloud で安全な環境を設計する方法について詳しくは、Google Cloud ランディング ゾーンのセキュリティを決定するをご覧ください。

モニタリング、アラート、ロギング

モニタリング、アラート、ロギングの設定について詳しくは、以下をご覧ください。

ガバナンス

次の課題事項について、お客様の組織における状況を検討してください。

  • ユーザーがコンプライアンスの要件を満たし、ビジネス ポリシーに沿わせるにはどうすればよいか。
  • Google Cloud のユーザーとリソースを維持、整理するためにはどのような戦略があるか。

Google Cloud でのアセットの信頼性、セキュリティ、メンテナンス性を確保するには、効果的なガバナンスが不可欠です。どのようなシステムでも、エントロピーは時間の経過とともに自然に増加します。そのため、クラウドの拡散や他のメンテナンス性の問題が発生します。効果的なガバナンスが確立されていないと、これらのさまざまな問題により、ビジネス目標の達成や、リスクの軽減が困難になります。クラウド移行戦略の重要な要素は、命名規則、ラベル付け方針、アクセス制御、コスト管理、サービスレベルに関する標準の計画と適用を厳格に行うことです。一般的に、ガバナンス戦略を策定することにより、当事者と経営陣と間での協調が生みだされます。

継続的なコンプライアンスのサポート

Google Cloud リソースの組織全体のコンプライアンスをサポートするには、一貫したリソース命名とグループ化の戦略の確立を検討してください。Google Cloud には、リソースに対するポリシーにアノテーションを付けて適用するための方法がいくつかあります。

  • セキュリティ マークは、リソースを分類して、Security Command Center からのセキュリティの分析情報を提供し、リソースのグループに対してポリシーを適用できます。
  • ラベルは、Cloud Billing でのリソース支出を追跡して、Cloud Logging で詳細な分析情報を提供できます。
  • ファイアウォールのタグを使用すると、グローバル ネットワーク ファイアウォール ポリシーとリージョン ネットワーク ファイアウォール ポリシーでソースとターゲットを定義できます。

詳細については、リスク・コンプライアンス管理のコード化をご覧ください。

次のステップ

寄稿者

著者:

  • Marco Ferrari | クラウド ソリューション アーキテクト
  • Travis Webb | ソリューション アーキテクト