Google Cloud への移行: 基盤の構築

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

このドキュメントはシリーズの一部です。

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

4 フェーズの移行パス

このドキュメントでは、オンプレミス環境、非公開のホスティング環境、または別のクラウド プロバイダから Google Cloud への移行を計画する際に役立つ情報を提供します。また、移行について検討している場合、その概要を把握するためにも利用できます。エンタープライズ オンボーディング チェックリストとこのドキュメントは、利用可能なプロダクト、サービス、オプションを理解して、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 Kubernetes Engine の責任共有モデルPCI DSS の顧客責任マトリックスなど、さまざまなサービス向けのセキュリティ責任共有モデルを採用しています。

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

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

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

リソース階層

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

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

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

Google Cloud リソースについて

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

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

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

クラウド プロジェクトの管理

Google Cloud では、各プロジェクトのリソース使用量に対して割り当てが定められています。これらの割り当てにより、プロジェクトで使用できる特定の Google Cloud リソースの量に上限が設けられています。割り当て管理は Google Cloud への移行において極めて重要です。そのため、移行戦略には入念な割り当て計画を組み込む必要があります。

また、割り当ては、リソース階層におけるクラウド プロジェクトの機能の一つです。Google Cloud 基盤の計画において、プロジェクトの数を多くするほど、割り当てをうまく管理できます。たとえば、標準 VPC共有 VPC かの選択における割り当ての影響についての理解を深めるには、Virtual Private Cloud(VPC)リソース割り当てのドキュメントをご覧ください。

Google Cloud リソース階層の計画やその他の基本的なトピックについては、エンタープライズ企業のベスト プラクティスをご覧ください。すでに Google Cloud を利用しており、テストや概念実証用に独立したプロジェクトを作成している場合は、既存のクラウド プロジェクトを組織に移行できます。

ID とアクセスの管理

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

  • 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 の設定には、次の 3 つの一般的な方法があります。

  • Google Cloud で直接 ID を管理する。
  • 既存の G Suite アカウントを使用する。
  • 既存の ID プロバイダ(IdP)を使用する。

Google Cloud で直接 ID を管理する場合、既存の IdP なしで Cloud Identity を使用できます。G Suite をご利用の場合、G Suite アプリで使用しているものと同じ ID を使用して、ハイブリッド環境の企業ユーザーを認証できます。組織内で IdP をすでに利用している場合、Google Cloud で既存の IdP を使用できます。

ID の移行

現在の環境で IdP を利用している場合、ID 連携を使用すれば、現在の IdP での ID 管理を SSO をサポートしつつ継続できます。多くの場合、企業の IT 部門はユーザー アカントの管理とアプリケーションやコンピューティング リソースへのアクセス制御を既存のディレクトリ サービスに依存しています。

連携は、ID を現在の IdP から Google Cloud へ同期すること、および既存の IdP へ認証を委任することにより動作します。このタイプの構成では、ユーザーは一度ログインすればシステムでユーザー認証されます。そのため、ID 連携により Google Cloud リソースへもアクセス可能となります。

Cloud Directory Sync を使用すれば、ID とグループを LDAP(Lightweight Directory Access Protocol)サーバーから Google Cloud へ同期できます。Cloud Directory Sync は、セキュアな接続を介して Identity Platform と通信し、通常、既存のコンピューティング環境で実行されます。

アクセス管理について

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

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

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

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

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

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

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

ベスト プラクティス

IAM を適切に構成すると、ユーザーが行った操作のロギングと監査ができます。ロールと権限を理解していることを確認し、最小権限の原則に従ってロールを付与します。IAM ロールの推奨事項を定期的に確認して、IAM ユーザーに付与されている過剰な権限を特定します。

IAM ポリシーを設計する際は、陥りやすい誤りを避けてください。子リソースに設定したポリシーで親リソースに付与されたアクセス権を制限することはできない点にご注意ください。各リソースに付与されているポリシーを確認し、階層継承を確実に把握してください。基本ロール、事前定義ロール、カスタムロールの使い分け、組織ポリシーの制約権限のテスト方法を理解します。IAM のベスト プラクティスでは、一般的な実装パターンも説明されています。

アプリケーションの個々のコンポーネントは個別の信頼境界として扱ってください。異なる権限を必要とする複数のサービスがある場合は、サービスごとに個別のサービス アカウントを作成した後で、各サービス アカウントに必要な権限のみを付与します。ユーザー アカウントに多要素認証を適用し、モバイル デバイスからの安全なアクセスを実施できます。Google は、最小権限の原則とゼロトラスト セキュリティのコンセプトを、BeyondCorp というエンタープライズ セキュリティの新しいモデルに集成しました。

課金

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

  • 既存の財務トラッキング方法は、Cloud Billing に対してどのように変更または適応されるか。
  • どこに請求が行くのか、また、支払方法には何があるか。
  • 従量課金制モデルにより、資本の割り当てや IT サービスの調達にどのような変更がおよぶか。
  • アプリケーションのオーナーはどのようにしてクラウドへの出費を既存のコストセンターにつけるか。

課金要件の評価

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

リソース階層課金のコンセプトは密接に関連しています。そのため、お客様とビジネス上の関係者によるコンセプトの理解が重要となります。要件を満たす方法で Cloud 請求先アカウントを設定するために、現行の会計と報告の要件を完全に評価し、理解していることを確認してください。その他の Google Cloud アカウントをお客様の組織全体で保有している場合には、Cloud 請求先アカウントを組織に移行できます。

オンプレミス課金の考慮事項としては、保守、電力、および物理ハードウェアと設備の冷却が挙げられます。また、Cloud Billing には、複数のアカウントの使用、予算、ラベル、レポート オプションといった独自の考慮事項があります。

Cloud Billing へのアクセスの管理

Cloud 請求先アカウントは、定義されたリソースセットに対する支払いを誰が行うかを定義します。お支払い方法が設定されているお支払いプロファイルに接続されているアカウント。Cloud 請求先アカウントの作成時に、組織内での Cloud Billing 管理者を規定します。また、Cloud 請求先アカウントへのアクセス権を持つ担当者とそのアカウントで実行できるアクションを規定します。詳しくは、Cloud Billing アクセス制御をご覧ください。

費用を管理して予算の制限を行うには、予算を作成し、アラートを設定する方法を学び、リソースの使用量が一定のしきい値に達したときに通知されるようにします。

費用の管理と分析

リソースは、Google Cloud プロジェクトでグループ化され、Cloud 請求先アカウントは、1 つ以上のプロジェクトにリンクされて、誰がどのリソースの支払いを行うかが決定されます。個別のチームやコストセンターへの使用料の請求など、さらに細分化された費用の帰属を定めるために、ラベルを使用できます。ラベルは、課金データを BigQuery にエクスポートして、詳細な分析を行う際に役立ちます。Orbitera などの高度なツールを使用して、複雑な課金を管理することもできます。

Cloud Billing ラベルを使用して、クラウド支出を組織内で見えやすくすることを計画している場合、ラベリングをクラウド ガバナンス戦略に組み込む必要があります。これらの措置により、Google Cloud でリリースされたすべてのリソースに適切なラベルが付けられていることを確認できます。

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

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

  • ソフトウェア定義ネットワーキングで、ワークロード間の接続性を管理する方法がどのように変更されるか。
  • Google Cloud でのネットワーク ファイアウォール ルールをどのように設定するか。
  • どのようにしてワークロードをグローバルにデプロイするか。
  • 既存のオンプレミス環境を新しいクラウド環境に接続するために使用可能な戦略はどのようなものか。

ネットワーキング要件の評価

ネットワーク アーキテクチャは、Google Cloud リソースがセグメント化される方法、既存のオンプレミス環境、公共のインターネット、任意のサードパーティ サービス、その他の Google リソースとの通信方法を決定します。このアーキテクチャは、現行のネットワーク アーキテクチャ、コンプライアンスと法令要件、スケーラビリティと障害復旧の検討事項、パフォーマンス要件、Google Cloud ネットワーキングのベスト プラクティスの組み合わせによって異なります。これらの Google Cloud ネットワーキング コンセプトが現行のインフラストラクチャにどう関連するかを理解する必要があります。

Google Cloud への移行を計画する際は、ワークロードを移行するリージョンとゾーンを決定する必要があります。これらの決定がビジネス目標や法令遵守の要件にどのように関連するかを把握しておいてください。

VPC について

Virtual Private Cloud(VPC)は、お客様が制御する Google Cloud 内のプライベート ネットワーク空間であり、ネットワーク アーキテクチャの基本コンポーネントです。VPC の構成には、セキュリティとガバナンスの重要な考慮事項があります。VPC を適切に構成することで、基盤を強化し、移行を促進できます。

VPC を使用することにより、複数のゾーンやリージョンをまたがるスケーリングを行い、ワークロードの接続方法とデプロイ方法を構成できる柔軟性を獲得できます。このマルチリージョン機能は、組織の障害復旧作業を計画し、製品やサービスの世界規模での展開を計画する際に重要となります。

組織全体で単一の VPC を実行して、それを多くの Cloud プロジェクト間で共有することも、複数の VPC を設定することもできます。また、共有 VPC を活用して複数の Cloud プロジェクトのリソースを共通の VPC ネットワークに接続することも、VPC ピアリングを使用して異なるプロジェクトや組織をまたがる複数の VPC を接続することもできます。

Google Cloud のファイアウォール管理は、お客様のネットワーク チームがこれまで用いている手法とは異なる場合があります。そのため、既存のファイアウォール構成を VPC ファイアウォール ルールに変換してワークロードを保護し、クラウド資産への攻撃を最小限に抑える必要があります。

リージョンとゾーンについて

Google Cloud は、そのインフラストラクチャをさまざまなロケーションでホストしています。お客様は、リソースをデプロイする場所を選択し、Google のグローバル ネットワークを活用してワークロードをスケーリングできます。

リージョンは、ゾーンで構成された、独立した地理エリアです。ゾーンは、リージョン内にある Google Cloud リソースの単一のデプロイエリアです。ゾーンは、リージョン内の単一の障害ドメインとみなすことができます。Google Cloud のリソースは、グローバル、マルチリージョン、リージョン、ゾーンのいずれかになります。たとえば、VPC とその関連ルート、ファイアウォール ルールはグローバルです。つまり、これらは特定のリージョンやゾーンには関連付けられていません。リソースのデプロイ方法を選択する際には、多くの検討項目があります。課金、ネットワーク アーキテクチャ、パフォーマンス、障害復旧、法令遵守が地理的要因にどう影響されるかを把握することが重要です。

接続オプションについて

ワークロードが、オンプレミス環境と公共のインターネットに接続する必要がある場合があります。Google Cloud が提供するハイブリッド接続オプションを十分に理解し、オンプレミス環境やマルチクラウド環境との接続を管理します。それぞれの接続オプションには異なる属性があり、ビジネス要件に最も合ったプロダクトを特定する必要があります。各アプローチには、重要なセキュリティ、パフォーマンス、コンプライアンスの影響があります。

次の方法を使用して、VPC をオンプレミス ネットワークに接続できます。

Cloud VPN を使用すれば、IPsec VPN トンネルを介してインターネット経由で Google Cloud ネットワークに安全に接続できます。Cloud VPN は簡単に設定できます。Cloud Interconnect は、エンタープライズ レベルの高可用性を持つ、低レイテンシの専用接続を、柔軟な帯域幅オプションとともに VPC に提供します。Cloud Interconnect の確立は Cloud VPN 接続よりも時間がかかります。また、通常は Partner Interconnect との連携が必要です。ダイレクト ピアリングまたはキャリア ピアリングの使用もまた、エンタープライズ レベルの専用接続で、Google の要件を満たす場合、帯域幅の使用量を抑え、設定時間を短縮できるオプションがあります。

VPN、Cloud Interconnect、ピアリングは、ビジネスのニーズに合わせて、組み合わせて使用できます。最も一般的な接続オプションの多くは、VPC のベスト プラクティスに記載されています。接続オプションを選択して実装すると、Cloud Router サービスが、Border Gateway Protocol(BGP)を使用してルーティング情報をオンプレミス ネットワークと交換できるようになります。

Cloud NAT を使用して、プライベート VM と Google Kubernetes Engine(GKE)クラスタに、公共インターネットへのセキュアで制御されたアクセスを提供できます。クラウド内での IP アドレス計画を作成します。Google Cloud 環境を計画する際は、使用可能なさまざまな IP アドレス オプションを理解する必要があります。まず、VPC の作成時に使用するデフォルトの IP アドレス オプションを確認します。自動モードを使用すると、各リージョンの事前定義のプライベート IP 範囲のサブネットを自動的に作成できます。また、リージョンと指定する IP 範囲だけを使用して、作成するサブネットを決定できるカスタムモード ネットワークも使用できます。VPC を自動モードで作成した場合は、後でいつでもカスタムモードに切り替えることができますが、カスタムモードから自動モードに戻すことはできません。本番環境ネットワークは、常にデプロイ前に計画する必要があります。カスタムモードは、本番環境で使用することをおすすめします。

VM には、1 つのプライマリ内部 IP アドレス、1 つ以上のセカンダリ IP アドレス、1 つの外部 IP アドレスを設定できます。同じ VPC ネットワーク上のインスタンス間で通信する際には、インスタンスの内部 IP アドレスを使用できます。公共のインターネットと通信するには、プロキシまたは Cloud NAT を構成していない限り、インスタンスの外部 IP アドレスを使用する必要があります。同様に、ネットワークが VPC ピアリングまたは Cloud VPN 経由で接続されていない限り、同じ VPC ネットワーク外のインスタンスに接続するには、インスタンスの外部 IP アドレスを使用する必要があります。外部プライマリ IP アドレスと内部プライマリ IP アドレスは、エフェメラルまたは静的のいずれかになります。

その他の多くの Google Cloud サービスには、Google Cloud 基盤の設計に影響する IP アドレスのルールがあります。たとえば、GKE クラスタを作成する際、ルートベースまたは VPC ネイティブルールのいずれかを使用することができます。GKE は、Pod を設計する際の IP アドレス割り当ての最適化に関するガイダンスを提供しています。Google Cloud 内で使用する予定の各サービスの IP 設計の詳細を確認してください。

DNS オプションについて

Cloud DNS は、パブリック ドメインネーム システム(DNS)サーバーとして機能します。VPC には、内部 DNS という、別であるものの同様のサービスが含まれています。自身の DNS サーバーを手動で移行して構成する代わりに、プライベート ネットワークの内部 DNS サービスを使用できます。詳細については、内部 DNS と Cloud DNS の違いをご覧ください。IP アドレスのブロックを保有していて、このブロックを Google Cloud で使用する場合は、カスタムルートの作成とテストの方法をご覧ください。Cloud DNS を実装する方法の詳細については、Cloud DNS のベスト プラクティスをご覧ください。

データ転送について

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

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

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

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

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

セキュリティ

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

  • 既存のセキュリティ ツールやプロセスを新しい Google Cloud 環境にマッピングするにはどうすればよいか。
  • クラウドベースのセキュリティ サービスを活用し、最新のクラウド セキュリティ モデルに適応させるには、どのような管理やプロセスの変更が必要か。
  • Google では、Google Cloud で個人データのセキュリティとプライバシーをどのようにメンテナンスしているか。
  • クラウド環境をデータ漏洩やその他のセキュリティ上の脅威から保護するにはどうすればよいか。

Google Cloud セキュリティ モデルについて

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

ほとんどの企業では、ファイアウォールを使用して境界セキュリティを実施しています。しかし、このセキュリティ モデルでは、境界が侵害された場合、攻撃者が企業限定のイントラネットに比較的簡単にアクセスできるため、問題があります。

移行の際には、ツール、技術、手法、企業セキュリティの方針を新たにする場合があります。それにより、セキュリティを強化し、ミッション クリティカルなワークロードを攻撃から保護して、データの改竄や漏洩を防ぐことができます。現在の手法とツールをゼロトラスト セキュリティ環境に適応させる方法を習得することが重要です。詳細については、BeyondCorp ホワイトペーパーをご覧ください。

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

データをセキュリティで保護する

Google のセキュリティ戦略の中心にあるのは、保存データと転送中の両方のデータの認証、整合性、暗号化です。保存データの暗号化では、保存中のデータを暗号化することで、システム侵害やデータ漏洩からデータを保護します。転送データの暗号化では、データがオンプレミス環境と Google Cloud 間または 2 つの Google Cloud サービス間を移動する際に通信が傍受された場合、そのデータを保護します。暗号鍵を安全に管理することは、セキュリティと規制の全体方針における最重要項目です。

Cloud Key Management Service(Cloud KMS)を使用することで、暗号鍵を一元管理できます。たとえば、Cloud KMS でどのように鍵のローテーションを構成するかについての知識は、セキュリティの点で役立つだけではなく、PCI データ セキュリティ基準に準拠するうえで必要な場合があります。鍵の保護にハードウェア セキュリティ モジュールが必要な場合、Cloud KMS の Secret の管理の方法、IAM の鍵とキーリングへのアクセスの構成方法を理解してください。

機密性の高い顧客データや内部ビジネス情報を保存または処理するワークロード向けに、Cloud Data Loss Prevention の使用方法を理解して、これらのワークロードを保護します。

VPC を使用すれば、Google Cloud サービスのリソースにセキュリティ境界を構成して、境界をまたがるデータの移動を制御できます。VPC は IAM の範囲外で動作するため、IAM 認証情報が侵害された場合でもデータを保護できます。

アプリの保護

クラウドでアプリケーションを安全に実行するために、まず各アプリケーションのセキュリティのニーズを評価する必要があります。この評価は、VPC、ネットワーク ルーティング ポリシー、ファイアウォール ルール、Cloud IAM の適切な構成と管理に役立ちます。ネットワーク レベルのポリシーの理解に加えて、Identity-Aware Proxy をアプリケーションの一元的な承認レイヤとして使用するタイミングと構成方法を学びます。その他のワークロードでは、セキュリティの強化や法令遵守の要件を満たすために、Shielded VM の OS レベルの保護が必要な場合もあります。一般向けのアプリケーションでは、Google Cloud Armor のポリシーを構成することによるアクティブな DDoS 対策が必要な場合があります。

リスクの管理

お客様とセキュリティ管理者は、Security Command Center(SCC)を理解し、組織全体の潜在的なセキュリティ リスクの追跡と監視に役立てる必要があります。Security Command Center で、攻撃者が悪用できるようになる前に、リスクを修正できます。Google のコア インフラストラクチャに既知のリスクがある場合、Google は、インシデントのレポート、伝達、修正のプロセスを透明性をもって提示します。インシデントを管理するこれらのポリシーやプロセスは、Google が社内で使用するものと同じです。資産のセキュリティを強化するため、お客様の組織でこれらのプロセスを採用することを検討いただけます。Google によるインシデント対応の完全なハンドブックとして、Google の書籍『Site Reliability Engineering』の第 9 章をご覧ください。

モニタリングとアラート

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

  • 現在のモニタリング ソリューションは Google Cloud とどのように連携するか。
  • 自社のサービスと Google Cloud が提供するサービスをモニタリングするにはどのようなオプションがあるか。
  • サービスへのセキュアで透過的なアクセスをどのようにして実現して、規制当局や監査者に準拠させるか。

現在のモニタリングとアラートのソリューションの評価

現在のお客様のエンタープライズ IT 環境ではおそらく、すでに 1 つ以上のロギングとモニタリングのソリューションを採用しているでしょう。Google Cloud を使用すれば、インフラストラクチャのすべてのロギング、指標、イベントをワークスペースに集約できます。インフラストラクチャやワークロードから生成されるロギングデータを管理するオプションを理解することが重要です。

ロギングデータの一元管理を行う場合は、Cloud Logging のログを既存のソリューションにエクスポートするか、現在のツールからログをインポートします。Cloud Logging は、Google Cloud のユーザーが広範なオペレーション、セキュリティ、コンプライアンス機能を利用できるよう、統合のエコシステムを拡大し続けています。

ロギングについて

Cloud Logging では、さまざまな Google Cloud サービスのログデータを集約して、分析、ユーザー アクションの監査、ワークロードのモニタリング、問題への対応を実施できるようにしています。お客様のインシデント対応チームは、Cloud Logging をコマンド センターとして使用して、アプリのバグやセキュリティ インシデントの検出、対応、修復を行えます。Cloud Logging によって取得される情報により、Google Cloud 環境が表示されます。IAM 監査ログVPC フローログエージェント ログなどのさまざまなソースから収集されたデータを使用しています。これらのログは未加工の形式で Cloud Logging に送信され、指標アラートフィルタで拡充されます。お客様のチームは、モニタリングの対象と方法、収集されたデータの分析方法、関連性のある実用的なアラートの作成方法について理解する必要があります。

リアルタイムのモニタリングの他に、Cloud Logging のデータを BigQuery にエクスポートすることで、大規模なロギング データセットのカスタム分析を行うことができます。たとえば、ログをクエリして、Google Cloud への内部ユーザー アクションとアプリケーション パフォーマンスとの相関関係を把握できます。

Cloud Logging は、ワークロードやインフラストラクチャに関する重要かつ多くの場合機密のデータを収集します。すべての Google Cloud サービスと同様に、IAM を使用して Cloud Logging へのアクセスを制御する方法を理解することが重要です。認可済みユーザーが行った操作を確認するには、Cloud Audit Logs を使用します。問題の診断に Google Cloud のサポートを利用する場合は、サポート スタッフがお客様の環境にアクセスする必要があります。アクセスの透明性を有効にすると、サポートチームが行った操作を監査できます。

ワークスペースでは、複数の Cloud プロジェクトのロギング、モニタリング、アラートの構成を一元管理できます。ハイブリッド環境やマルチクラウド環境では、Cloud Logging を使用して、オンプレミス インフラストラクチャAmazon Web Services(AWS)環境をモニタリングできます。ワークスペースではさまざまなソースからの指標が集計されるため、ワークスペースと関連ツール(BigQuery など)を別の Cloud プロジェクトに設定することをおすすめします。これにより、この情報へのアクセスを効果的に調整し、プロジェクト割り当てに影響を与えないようにできます。

指標とアラートについて

インフラストラクチャのワークロードの状態を把握するための主なツールは、Cloud Monitoring の指標です。指標は、Cloud Monitoring で収集される観測値で、アプリやシステム サービスのパフォーマンスの把握に役立ちます。Google Cloud は、Google Cloud や AWS などのプラットフォームのモニタリングに役立つ 1,000 種類以上の指標を備えています。ユースケースやビジネス要件に応じて、カスタム指標を作成して、ワークロードやインフラストラクチャの他の側面もモニタリングできます。有用なアラートを作成するには、指標を十分に理解しておく必要があります。アラートは、アラート ポリシーを構成することでトリガーできます。

指標は、Cloud Monitoring のダッシュボードとグラフに表示されるデータにもフィードします。透過的サービスレベル指標をモニタリングに組み込んで、問題を診断する方法を学びます。問題の原因がビジネス ワークロードのいずれかに起因するのか、あるいは 1 つ以上の Google Cloud サービスでの機能低下に起因するのかを判別できます。Google Cloud ステータス ダッシュボードを使用して、Google Cloud インフラストラクチャの現在の運用状況の概要を確認することもできます。

Google Cloud の操作

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

  • ユーザーとアプリは Google Cloud サービスとどのように連携できるか。
  • 新しいリソースのプロビジョニングをどのように自動化するか、それが既存のビジネス プロセスにどのような影響を与えるか。

方法の比較

Google Cloud サービスとやり取りする方法は、以下のようにいくつかあります。

  • Cloud APIs にはプログラマティック インターフェースがあり、アプリコードで Google Cloud を操作できます。Cloud APIs は、Google Cloud のあらゆる操作のベースとなっています。
  • Cloud Console はグラフィカル ユーザー インターフェースであり、ブラウザで Google Cloud を操作できます。
  • Cloud SDK は、デベロッパー向けのソフトウェア ライブラリで、アプリケーションが Cloud APIs と連携できるようにします。
  • gcloud コマンドライン ツールは、コマンドラインから Cloud APIs に呼び出しを行えるツールで、繰り返し可能タスクの記述に便利です。
  • Infrastructure as Code(IaC)は、インフラストラクチャのデプロイをソースコードで管理し、Cloud APIs を使用してリソースのプロビジョニングを標準化します。

さまざまな人やシステムが、それぞれのロールや機能に応じて、Google Cloud を異なる方法で利用しています。たとえば、財務チームのメンバーは、Cloud Console を使用して、BigQuery の Cloud Billing ログを操作できます。自動デプロイ プロセスでは、Cloud APIs に直接呼び出しを行うことでリソースをプロビジョニングできます。クラウド環境の適切なガバナンスとセキュリティのためには、それぞれの方法の適切な使用法を理解することが重要です。

プロダクト固有の操作

Cloud Storage や GKE などの一部のサービスでは、これらのサービスのきめ細かい操作ができる独自のツールを備えています。たとえば、Cloud Storage では、gsutil というツールを備えています。データの移行を最適化し、Cloud Storage バケットのセキュリティを適切に管理するには、このツールを理解することが重要です。GKE では、Cloud Console や gcloud コマンドライン ツールを使用してクラスタをデプロイできますが、クラスタの管理は kubectl コマンドライン ツールを使用して実施されます。

操作の自動化

Google Cloud では、コードのビルドとデプロイをサポートするマネージド サービス Cloud Build も提供しています。IaC を活用できるサービスとして、Deployment Manager を使用すると、Google Cloud サービスとプロダクトのライフサイクルを管理できます。

Cloud APIs を使用すると、特定のリソースの操作を自動化できます。Google Cloud では、Cloud APIs はプロジェクト単位で有効化されているため、ガバナンス戦略において、Cloud APIs の有効化を許可するユーザーとその条件を決定する必要があります。これらの API を使用すると、Google Cloud サービスのリソースが消費され、費用が発生する可能性があります。Cloud APIs の有効化が課金に与える影響を確実に理解してください。

ガバナンス

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

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

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

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

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

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

たとえば、Cloud Functions を使用して Compliance as a Code ソリューションを提供できます。Cloud Functions の関数で Cloud API を使用して、プロビジョニングされたリソースの名前とラベルを検証することにより、確実に標準に従うことができます。場合によっては、既存の標準に違反するリソースのプロビジョニングを自動的に解除できます。移行計画プロセスにおいて、これらの標準と規則を確立し、適用方法を決定することが重要です。また、重要なリソースの誤削除を防止し、Cloud Functions を使用して、特定のラベルを持つリソースに対する保護を自動的に適用できます。IAM Conditions を使用して、リソースの特定の属性に基づき、アクセス権を変更する方法を理解しておいてください。

移行における人材の有効活用

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

  • クラウドへの移行を計画、実行するための知識、経験、人材があるか。
  • クラウドの移行期間中に戦略的なガイダンスや技術サポートにアクセスするにはどうすればよいか。
  • クラウドでの運用を開始したら、どこでサポートを受けられるか。

能力の評価

Google Cloud への移行は、ビジネスにとって重要な戦略的変革です。クラウド移行の作業をどう分割するかについては、組織によってさまざまな選択肢があります。社内リソースのみを使用する企業もあれば、すべての業務を外部委託する企業もありますが、ほとんどはその中間にあります。現在の組織が持つ知識や専門的技術などの能力を理解することで、適切なバランスでのアプローチを選択できます。

スタッフのトレーニングは、すべての組織にとって最優先事項です。Google Cloud 認定資格を取得すれば、既存のチームが Google Cloud テクノロジーをビジネスでフル活用するために必要なスキルの実証と検証ができます。Google では、トレーニング オプションとして、詳細コースハンズオンラボダイレクト トレーニング エンゲージメントを提供しています。

クラウド エキスパートとの協力

Google はプロフェッショナル コンサルティング サービスを提供しており、Google Cloud への移行作業の各段階でご利用いただけます。

専任のコンサルタントが選ばれ、Google Cloud インフラストラクチャの構築を担当したエキスパートがご協力します。成功した実装のベスト プラクティスと指針をチームに伝えることができます。

プロジェクトのニーズに応じて、Google Cloud パートナーとの連携を検討することもできます。パートナーは、1 つ以上の専門分野で Google により審査されており、Google Cloud Certified プロフェッショナルを採用しています。適切なパートナーは専門知識を持ち、クラウドの移行を促進する実践的なガイダンスを提供します。

サポート オプションについて

Google Cloud 上でビジネスの運営を開始した後、Google Cloud サポートにより、最初の段階から問題の発生を防ぐことができます。問題が発生した場合、サポートが問題の根本原因を迅速に特定し、問題の再発を防ぐ長期的なソリューションを提供します。さまざまな利用可能なサポート オプションを把握し、ビジネスに適したサポートを選択してください。

次のステップ