エンタープライズ企業のベスト プラクティス

このガイドでは、Google Cloud Platform(GCP)への移行を進めている企業のお客様にベスト プラクティスを紹介します。このガイドは、すべての推奨事項を説明するものではありません。企業のアーキテクトや技術担当者の方が活動の範囲を把握し、適切な計画を作成できるように役立つ情報を提供することを目的としています。各セクションには、主要な作業の説明と参考情報のリンクが記載されています。

このガイドを読む前に、プラットフォームの概要で GCP の全体像を理解しておくことをおすすめします。

組織の設定

リソース階層を定義する

GCP のリソースは階層的に編成されます。これにより、組織の運用体制を GCP にマッピングし、関連リソースのグループに対するアクセスを制御できます。次の図は、階層の例を示しています。

階層的に編成されたリソースの逆ツリー構造

階層の最上位ノードは組織リソースで、組織(会社など)を表します。組織リソースは、階層の下にあるすべてのリソースを集中管理します。

階層の次のノードはフォルダです。フォルダを使用すると、親組織のさまざまな部署やチームの要件を分離できます。また、本番環境と開発環境のリソースを分けることもできます。

階層の一番下にあるのがプロジェクトです。プロジェクトには、アプリを構成するコンピューティング、ストレージ、ネットワーク リソースが含まれます。プロジェクトについては、このドキュメントの後半で詳しく説明します。

構造は柔軟に定義できます。変化する要件にも対応できます。まだ GCP に慣れていない場合は、初期の要件を満たす最も単純な構造を採用できます。詳細については、Resource Manager の概要をご覧ください。

組織ノードを作成する

GCP でサポートされている機能の多くは組織ノードを必要とします。Cloud Identity を使用して、example.com などの会社のインターネット ドメインにマッピングする組織ノードを作成します。また、既存の GCP プロジェクトや請求先アカウントを組織ノードに移行できます。詳細については、組織を作成、管理するをご覧ください。

設定でサポートが必要な場合は、組織設定ウィザードをご覧ください。

プロジェクト構造を指定する

GCP を使用するにはプロジェクトが必要です。Compute Engine 仮想マシンや Cloud Storage バケットなど、すべての GCP リソースが 1 つのプロジェクトに属します。プロジェクトの詳細については、プラットフォームの概要をご覧ください。

プロジェクトの範囲は自由に決めることができます。1 つのプロジェクトに複数のアプリを入れることも、逆に 1 つのアプリを複数のプロジェクトに関連付けることもできます。プロジェクト内のリソースを複数のリージョンや地域に分散することもできます。

理想的なプロジェクト構造は要件によって異なります。また、時間とともに変わることもあります。プロジェクトの構造を設計するときには、リソースごとに請求を行う必要があるかどうか、どの程度の分離が必要か、リソースとアプリを管理するチームをどのように編成するかを決める必要があります。

プロジェクトの作成を自動化する

GCP のプロジェクトとリソースの作成や管理を自動化すると、一貫した処理が可能になり、再現性を高め、テストを容易に行うことができます。構成をコードとして扱うことで、ソフトウェアの成果物と一緒に構成のバージョニングやライフサイクルを管理できます。自動化により、リソースに一貫した命名規則やラベル付けを適用するなど、ベスト プラクティスを実現できます。また、要件が変化した場合でも、プロジェクトのリファクタリングを簡単に行うことができます。

GCP プロジェクトには、GCP ネイティブの管理ツールである Cloud Deployment Manager を使用します。Deployment Manager で構成ファイルを作成し、同時にデプロイする一連の GCP リソースを記述できます。また、再利用可能な構成要素として、パラメータ化されたテンプレートを定義することもできます。Deployment Manager では、プロジェクト作成プロセスの一環としてデベロッパーに適切なアクセス権が付与されるように、Cloud IAM を使用してアクセス制御権限を設定することもできます。

Terraform、Ansible、Puppet などのツールも使用できます。これらのツールに慣れている場合、新しいスキルを習得する必要はありません。

ID とアクセスの管理

Google ID を管理する

GCP は認証とアクセス管理に Google アカウントを使用します。デベロッパーや他の技術スタッフが GCP にアクセスするには Google アカウントが必要です。Cloud Identity を使用して、会社のドメイン名にフルマネージドの Google アカウントを関連付けることをおすすめします。これにより、デベロッパーは会社のメールアドレスを使用して GCP にアクセスできるようになります。また、管理者は管理コンソールにアカウントを表示し、管理できるようになります。このドキュメントの以降のセクションでは、既存の ID プラットフォームを Cloud Identity に統合する方法について説明します。

Cloud Identity はスタンドアロンの IDaaS(Identity-as-a-Service)ソリューションです。これにより、Cloud Platform のユーザーは、G Suite(Google Cloud の生産性向上アプリのセット)から提供される多くの ID 管理機能を利用できます。Cloud Identity は G Suite のライセンスを必要としません。Cloud Identity に登録すると、会社のドメイン名に関連付けられた Google アカウントの管理レイヤが提供されます。この管理レイヤにより、GCP を含む Google サービスへのアクセスが許可または禁止されます。Cloud Identity に登録すると、ドメインの組織ノードも作成されます。これにより、リソース階層を使用して会社の組織体制を GCP リソースにマッピングし、管理できます。

詳細については、Cloud Identity ソリューションをご覧ください。

ID プロバイダを GCP と連携させる

組織でオンプレミスまたはサードパーティの ID プロバイダを使用している場合は、ユーザー ディレクトリを Cloud Identity と同期し、ユーザーが会社の認証情報を使用して GCP にアクセスできるようにします。これにより、ID プラットフォームを使用しながら、Cloud Identity で従業員による Google サービスへのアクセスを制御できます。

管理対象外のアカウントを移行する

ドメインのメンバーが会社のメールアドレスを使用して個人の Google アカウントを作成している場合(YouTube、Blogger などの Google サービスに登録した場合など)、これらのアカウントを移行し、Cloud Identity で管理できるようにすることを検討してください。これらのアカウントが別のメールアドレスを使用するように強制的に変更することもできます。

アカウントを移行する方法やアカウントの名前を強制的に変更する方法については、Cloud Identity または G Suite への一般ユーザー向けアカウントの移行をご覧ください。

リソースへのアクセスを制御する

デベロッパーと IT スタッフには、GCP リソースの使用を許可する必要があります。Cloud Identity and Access Management(IAM)を使用すると、特定の GCP リソースに対するアクセス権をきめ細かく設定し、他のリソースへの不要なアクセスを防ぐことができます。たとえば、Cloud IAM では、誰(ID)がどのリソースにどのようなアクセス権(役割)を持つのかを定義できます。

権限を直接割り当てるのではなく、役割を割り当てます。IAM の役割は権限のコレクションです。たとえば、BigQuery データ閲覧者の役割には、BigQuery テーブルの一覧表示、読み取り、クエリを行う権限が含まれていますが、新しいテーブルの作成や既存データの変更を行う権限は含まれていません。Cloud IAM には、一般的なユースケースに利用できる多くの役割が事前に定義されています。カスタム役割を作成することもできます。

Cloud IAM では、最小権限のセキュリティ原則を適用して、リソースに対して必要最低限のアクセス権を付与できます。Cloud IAM は、エンタープライズの組織で基本的なトピックです。Identity and Access Management の詳細については、次のリソースをご覧ください。

グループとサービス アカウントを使用して業務を委任する

同じ業務に携わるユーザーをグループにまとめ、Cloud IAM の役割を個々のユーザーではなくグループに割り当てることをおすすめします。たとえば、「データ サイエンティスト」というグループを作成し、BigQuery や Cloud Storage を操作できるように適切な役割を割り当てます。新しいデータ サイエンティストがチームに参加したときに、グループに追加するだけで、定義済みの権限を継承できます。グループの作成と管理は管理コンソールで行います。

サービス アカウントは特別なタイプの Google アカウントで、個々のユーザーではなく、Google Cloud サービスの ID またはアプリを表します。ユーザーやグループと同様に、サービス アカウントにも IAM 役割を割り当て、特定のリソースへのアクセス権を付与できます。サービス アカウントの認証はパスワードではなくキーで行います。GCP 上で実行されるコードのサービス アカウントキーは Google が管理し、ローテーションを行っています。サーバー間のやり取りにはサービス アカウントの使用をおすすめします。

組織ポリシーを定義する

組織のポリシーを使用すると、組織のクラウド リソースをプログラムで集中管理できます。 Cloud IAM で重要なのは「誰が」です。権限に基づいて特定のリソースに対するアクションをユーザーやグループに承認する人物が重要になります。組織ポリシーで重要なのは「何」で、特定のリソースに制限を設定し、どのような構成と使用方法が可能であるかを決定することが重要です。たとえば、仮想マシン インスタンスに外部の IP アドレスが割り当てられないように制限を定義できます。

リソースのポリシーはリソースの階層内で設定します。リソースのポリシーはそのすべての子孫に継承されます。最上位の組織ノードにポリシーを適用することで、基本的な一連の制約が階層内のすべての要素に適用されます。継承されたポリシーを上書きしたり、結合したりする場合は、子ノードにカスタム組織ポリシーを設定します。

ポリシーの設定方法については、エンタープライズのお客様向けのポリシー設計をご覧ください。

ネットワーキングとセキュリティ

VPC を使用してネットワークを定義する

VPC とサブネットを使用してネットワークを計画し、関連リソースをグループ化して分離します。VPC(Virtual Private Cloud)は物理ネットワークを仮想化したネットワークです。VPC ネットワークは、Compute Engine の仮想マシン(VM)インスタンスや、Google Kubernetes Engine(GKE)、Cloud Dataproc、Cloud Dataflow などの VM インスタンスを利用するサービスにスケーラブルで柔軟なネットワークを提供します。

VPC ネットワークはグローバルなリソースです。公共のインターネットを経由することなく、単一の VPC で複数のリージョンにまたがる通信を実現できます。つまり、1 つの GCP プロジェクトから世界中に分散しているリソースを接続して管理できます。1 つのプロジェクトに、複数の独立した VPC ネットワークを作成することもできます。

VPC ネットワーク自体には IP アドレス範囲を定義しません。各 VPC ネットワークはサブネットワークという 1 つ以上のパーティションから構成され、それぞれのサブネットに 1 つ以上の IP アドレス範囲が定義されています。サブネットはリージョン リソースです。1 つのサブネットは 1 つのリージョンに明示的に関連付けられています。

詳細については、VPC ネットワークの概要をご覧ください。

ファイアウォール ルールでトラフィックを管理する

各 VPC ネットワークは分散仮想ファイアウォールを実装しています。Compute Engine の VM インスタンスや GKE クラスタなど、VPC に接続しているリソース間のトラフィックを許可または拒否するファイアウォール ルールを構成します。ファイアウォール ルールは仮想ネットワーキング レベルで適用されるため、インスタンスが使用するオペレーティング システムに関係なく、効果的な保護とトラフィック制御を行うことができます。ファイアウォールはステートフルです。つまり、許可されているフローの場合、戻りトラフィックは自動的に許可されます。

ファイアウォール ルールは VPC ネットワークごとに異なります。このルールには、トラフィックの種類(ポートやプロトコルなど)とトラフィックの送信元または宛先(IP アドレス、サブネット、タグ、サービス アカウントなど)を指定できます。たとえば、特定のサービス アカウントに関連付けられた VM インスタンスが、特定の送信元サブネットからポート 80 への TCP トラフィックを許可するように、上りルールを作成できます。各 VPC ネットワークには、暗黙のデフォルト ファイアウォール ルールが自動的に設定されます。

アプリが GKE でホストされている場合は、ネットワーク トラフィックの管理とファイアウォール ルールの構成について別の注意事項があります。詳しくは、GKE ネットワーキングのコンセプトをご覧ください。

外部アクセスを制限する

VPC ネットワークを利用する GCP リソースを作成する場合は、リソースを配置するネットワークとサブネットを選択します。リソースには、サブネットに関連付けられている IP 範囲の 1 つから内部 IP アドレスが割り当てられます。ファイアウォール ルールで拒否されない限り、VPC ネットワーク内のリソースは内部 IP アドレスで相互に通信を行うことができます。

インターネットと通信するには、リソースに外部のパブリック IP アドレスを割り当てるか、Cloud NAT を使用する必要があります。外部ネットワークになんらかの方法で(たとえば VPN 経由で)接続していない限り、同じ VPC ネットワークにない外部のリソースに接続するには、外部 IP アドレスが必要になります。詳しくは、IP アドレスのドキュメントをご覧ください。

インターネットへのアクセスは、必要なリソースにのみ許可する必要があります。プライベート Google アクセスを使用すると、プライベートの内部 IP アドレスしかないリソースでも多くの Google API やサービスにアクセスできます。このプライベート アクセスにより、インターネットから隔離された状態で、主要な Google サービスや GCP サービスと利用できます。

ネットワーク制御を一元管理する

共有 VPC を使用すると、共通の VPC ネットワークに接続できます。これらのプロジェクト内のリソースは、内部 IP を使用してプロジェクトの境界を越えて安全で効率的な通信を行います。プロジェクト全体に一貫したネットワーク ポリシーを適用することで、サブネット、ルート、ファイアウォールなどの共有ネットワーク リソースを中央のホスト プロジェクトから一元管理できます。

共有 VPC と IAM を使用すると、ネットワークの管理とプロジェクトの管理を切り分けることができます。これにより、最小権限の原則を実装しやすくなります。たとえば、一元管理されたネットワークのチームは、参加しているプロジェクトに対する権限がなくてもネットワークを管理できます。同様に、プロジェクト管理者は、共有ネットワークの操作権限なしでプロジェクトのリソースを管理できます。

企業ネットワークを接続する

既存のオンプレミス インフラストラクチャと GCP リソースを接続する場合、帯域幅、レイテンシ、SLA の要件を検討して最適な接続方法を選択する必要があります。

  • インターネット経由で GCP に接続することなく、オンプレミスと VPC ネットワーク間で安定したデータ転送を実現するために、低レイテンシで高可用性のエンタープライズ レベルの接続が必要な場合は、Cloud Interconnect を使用します。

    • Dedicated Interconnect は、オンプレミス ネットワークと Google のネットワークの間に直接的な物理接続を提供します。
    • Partner Interconnect は、サポート対象のサービス プロバイダを介して、オンプレミス ネットワークと GCP VPC ネットワークの間の接続を提供します。
  • Cloud Interconnect の低レイテンシと高可用性を必要としない場合や、クラウドへの移行を始めたばかりの場合は、Cloud VPN を使用して、オンプレミス ネットワークと VPC 間に暗号化された IPsec VPN トンネルを設定します。プライベートな直接接続と比べて、IPsec VPN トンネルはオーバーヘッドが少なく、低コストです。

アプリとデータを保護する

GCP では、データセンターの物理的な安全対策、独自のセキュリティ ハードウェア、研究者から構成された専任チームなど、堅牢なセキュリティでインフラストラクチャとサービス全体を保護しています。しかし、GCP リソースの保護にはお客様の協力が不可欠です。アプリとデータが確実に保護されるように、適切な対策を講じるようお願いいたします。

ファイアウォール ルールと VPC の分離に加えて、次のツールを使用して、アプリを保護してください。

  • VPC Service Controls を使用して、GCP リソースにセキュリティ境界を定義し、VPC 内のデータを制限してデータ引き出しのリスクを軽減します。
  • GCP グローバル HTTP(S) ロードバランサを使用して、インターネットに接続するサービスの高可用性とスケーリングをサポートします。
  • Google Cloud Armor を HTTP(S) ロードバランサと統合して、DDoS 対策と、ネットワーク エッジで IP アドレスをブラックリストおよびホワイトリストに登録する機能を提供します。
  • Cloud Identity-Aware Proxy(Cloud IAP)を使用して、ユーザーの ID とリクエストのコンテキストを確認し、ユーザーにアクセスを許可するかどうか判断します。これにより、アプリへのアクセスを制御します。

GCP では、転送中のデータと保存データの両方を暗号化することでデータの安全性を維持しています。デフォルトでは、保存データの暗号化に Google 管理の暗号鍵が使用されます。センシティブ データの場合は、GCP で鍵を管理できます。より細かい制御が必要な場合は、GCP の外部で管理されている独自の暗号鍵を指定できます。独自の鍵を管理または維持するとオーバーヘッドが発生するため、この方法は本当に重要なデータにのみ使用することをおすすめします。詳細については、保存データの暗号化をご覧ください。

ロギング、モニタリング、オペレーション

ロギングとモニタリングを一元管理する

複数のアプリ、データ パイプライン、その他のプロセスを異なるプラットフォームで実行している企業が少なくありません。これらのアプリやプロセスを正常な状態に維持することは、デベロッパーと運用チームにとって重要な責務となります。正常な状態を維持するため、Stackdriver でロギング、モニタリング、デバッグ、トレース、プロファイリングなどを管理することをおすすめします。

ログは、アプリやプロセスの正常性を診断する基本的な情報源となります。 Stackdriver Logging は、Stackdriver スイートの一部です。ログデータやイベントの保存、表示、検索、分析、アラートを行うことができます。Logging は多くの GCP サービスとネイティブに統合されています。Compute Engine または Amazon Elastic Compute Cloud(EC2)仮想マシン インスタンスでホストされているアプリケーションの場合、Logging エージェントをインストールして自動的に Stackdriver にログを転送できます。Stackdriver Logging は、オンプレミスで実行されるアプリケーションを含む、あらゆるソースからログを書き込むために使用できる API も提供します。Logging を使用すると、すべてのアプリからのログを取得し、Stackdriver で一元管理できます。

安定したオペレーションを確実に行うには、ログだけでなく、アプリやシステムの他の側面もモニタリングする必要があります。Stackdriver Monitoring を使用すると、アプリとインフラストラクチャのパフォーマンス、稼働時間、全体的な状態を可視化できます。Monitoring では、イベント、指標、メタデータを取り込み、ダッシュボード、チャート、アラートで分析情報を提供します。Monitoring では、多くの GCP やサードパーティ ソースの指標をすぐに使用できます。Monitoring ではカスタム指標も定義できます。たとえば、異常な行動やトレンドが運用チームに通知されるように、指標を使用してアラート ポリシーを定義できます。Monitoring の柔軟ダッシュボードと豊富な可視化ツールにより、問題の兆候を発見できます。

監査証跡を設定する

状況によっては、アプリやプロセスレベルのログを収集するだけでなく、デベロッパーや IT チームがどのように GCP リソースを使用しているかを追跡し、トレース情報を維持する必要があります。Cloud 監査ログを使用すると、GCP プロジェクト内で「誰が、何を、どこで、いつ行ったか」を調べるのに役立ちます。監査ログを書き込む GCP サービスの一覧については、監査ログ付きの Google サービスをご覧ください。監査ログの表示権限を持つユーザーを制限するには、IAM コントロールを使用します。

Cloud 監査ログは、いくつかの種類のアクティビティをキャプチャします。管理アクティビティ ログには、リソースの構成またはメタデータを変更する API 呼び出しやその他の管理アクションに関するログエントリが含まれます。管理アクティビティ ログは常に有効です。データアクセス監査ログには、ユーザー提供データを作成、変更、または読み込む API 呼び出しが記録されます。データアクセス監査ログは、非常に大きくなる可能性があるため、デフォルトでは無効になっていますが、データ アクセスログを生成する GCP サービスを構成できます。

監査ログの詳細については、Cloud Audit Logs をご覧ください。

ログをエクスポートする

Logging は、アプリと監査ログを一定期間保持します。法令遵守のため、ログの保存期間の延長が必要になる場合があります。あるいは、履歴分析のためにログの保存が必要になることもあります。

ログは、Cloud Storage、BigQuery、Cloud Pub/Sub にエクスポートできます。フィルタを使用して、エクスポートにリソースを追加したり、除外したりできます。たとえば、すべての Compute Engine ログをエクスポートし、サイズの大きい Cloud Load Balancing ログを除外することなどが可能です。

ログのエクスポート先はユースケースによって異なります。多くの企業は複数の場所にログをエクスポートしています。大まかに言うと、法令遵守のために長期保存する場合は Cloud Storage を使用します。ログの分析には BigQuery を使用します。BigQuery は SQL クエリとサードパーティ ツールの大規模なエコシステムをサポートしています。

ログのエクスポートの詳細については、Logging のエクスポートのための設計パターンをご覧ください。

DevOps とサイト信頼性エンジニアリングを採用する

俊敏性を高め、アプリや機能の市場投入までの時間を短縮するには、開発、運用、ネットワーキング、セキュリティの各チーム間のサイロ化を解消しなければなりません。そのためには、DevOps というプロセス、文化、ツールが必要になります。

GCP には、DevOps の採用に役立つさまざまなサービスが用意されています。たとえば、統合されたソースコード リポジトリ継続的デリバリー ツール、Stackdriver の豊富なモニタリング機能、オープンソース ツールの強力なサポートなどを利用できます。詳細については、GCP の DevOps ソリューションをご覧ください。

サイト信頼性エンジニアリング(SRE)は DevOps と密接に関連した一連のプラクティスです。これらは、Google の本番環境インフラストラクチャを管理する SRE チームのプラクティスから進化したものです。多くの企業にとって SRE の専任部門を設ける必要はないでしょうが、運用戦略の立案に役立つプラクティスを学ぶため、SRE の書籍をご覧になることをおすすめします。

クラウド アーキテクチャ

移行を計画する

オンプレミスのアプリとインフラストラクチャをクラウドに移行する場合、評価と計画を慎重に行う必要があります。それぞれのアプリについて、リフト&シフトから変換と移行まで、さまざまな移行戦略を評価する必要があります。GCP には、仮想マシンの移行、データの転送、ワークロードの最新化に役立つツールが用意されています。詳細については、移行センターをご覧ください。

規制、技術または財務上の制約から、特定のアプリがパブリック クラウドに移行できないことや、移行が望ましくない場合があります。その場合、オンプレミスと GCP のインフラストラクチャでワークロードの分散と統合が必要になる可能性があります。この環境はハイブリッド クラウドといいます。ハイブリッド ワークロードの詳細については、ハイブリッド クラウドをご覧ください。ハイブリッドとマルチクラウド ソリューションの詳細については、パターンと実践をご覧ください。

マネージド サービスを使用する

クラウドを採用する主な理由は、IT のオーバーヘッドを削減して効率化を図り、コアビジネスに集中できるようにすることです。運用の負担を軽減し、総所有コスト(TCO)を抑えるには、DevOps プラクティスを採用し、自動化を促進することに加え、GCP マネージド サービスを使用する必要があります。

マネージド サービスを使用すると、アプリケーション スタックの各部分を個別にインストールしてサポートや操作を行うのではなく、アプリケーション スタックの一部をサービスとして使用できます。たとえば、VM インスタンスに MySQL データベースをインストールして自己管理する場合と異なり、Cloud SQL が提供する MySQL データベースを使用することで、基盤となるインフラストラクチャを GCP で管理し、バックアップや更新、複製を自動化できます。

それぞれのマネージド サービスで提供される SLA を評価することをおすすめします。

GCP では、マネージド データベースからビッグデータ処理ツールまで、一般的な多くのアプリ コンポーネントとユースケースで使用できるマネージド サービスとサーバーレス オプションを提供しています。このマネージド サービスの多くは一般的なオープンソース フレームワークとプラットフォームに対応しているため、これらのオープンソース プラットフォームを利用する既存のアプリをクラウドに移行することで TCO を低減できます。

高可用性を設計する

ミッション クリティカルなアプリの稼働時間を維持するには、障害や予期しない負荷の変化にも対応できる復元性の高いアプリを設計する必要があります。高可用性とは、システム内のコンポーネントに障害が発生しても機能し続けるアプリの能力を意味します。高可用性のアーキテクチャでは通常、コンピューティング リソースを分散し、負荷分散やデータのレプリケーションが行われています。高可用性のプロビジョニングの範囲はアプリによって異なります。可用性のコンセプトの詳細については、地域とリージョンのドキュメントをご覧ください。

特定のゾーンの障害から保護するため、Compute Engine VM インスタンスや GKE クラスタなどのコンピューティング リソースをリージョン内の使用可能なゾーン全体に分散する必要があります。地理的に分散した複数のリージョンにリソースを配置すると、リージョン全体の損失を防ぎ、コンピューティング リソースの可用性をさらに向上させることができます。コンピューティング リソースを作成する場所のガイダンスについては、Compute Engine のリージョン選択に関するベスト プラクティスをご覧ください。

GCP では、いくつかの方法で負荷分散を行っています。インターネットに接続するアプリの公開でよく使用されるのが HTTP(S) ロードバランサです。このロードバランサはグローバルな負荷分散を行うため、異なる地域のリージョン間で負荷を分散できます。ゾーンまたはリージョンが使用不能になると、ロードバランサが使用可能なゾーンにトラフィックを転送します。詳しくは、グローバル負荷分散によるアプリケーションの処理能力の改善をご覧ください。

データ ストレージを選択する際には可用性も考慮する必要があります。GCP データ ストレージ サービスの中には、単一リージョンのゾーン間でデータを複製できるものもあります。他のサービスでは、地理的なエリアの複数のリージョンでデータが自動的に複製されますが、レイテンシと整合性モデルがトレードオフになることがあります。最適なデータ ストレージ サービスはアプリと可用性の要件によって異なります。

障害復旧戦略を計画する

高可用性の設計に加えて、大規模な機能停止や自然災害が発生した場合でも事業を継続できるように計画を作成しておく必要があります。障害復旧(DR)は重大なインシデントから復旧するための機能です。高可用性のプロビジョニングが無効であるか、利用できない場合は、障害回復を開始する必要があります。

効果的な DR プランを作成するには計画とテストが必要です。早い段階で DR 計画を作成することをおすすめします。詳しくは、障害復旧計画ガイドと関連記事をご覧ください。

リソース

請求と管理

リソースの課金方法を理解する

GCP では消費モデルが採用されています。特定の支払期間でのリソースまたはプロダクトの使用量に基づいて課金が行われます。多くのプロダクトは、さまざまな方法で使用量を測定しています。次に例を示します。

  • 時間: マシンの稼働時間(秒)
  • ボリューム: 保存されるデータ量
  • 実行されたオペレーションの数
  • 上記コンセプトのバリエーション

費用を正確に測定できるように、システム内のコンポーネントがどのように課金されるのかを理解しておく必要があります。プロダクトのドキュメントに詳細な料金情報が記載されています。多くのプロダクトには無料枠が用意されています。使用量が特定のしきい値を超えるまで無料で使用できます。無料枠を超えてリソースを使用する場合は、課金を有効にする必要があります。

GCP の料金体系、イノベーション、割引の詳細については、料金体系ページをご覧ください。

請求管理を設定する

Compute Engine VM、Cloud Storage バケット、BigQuery データセットを含むすべての GCP リソースは、GCP プロジェクトに関連付ける必要があります。無料枠を超えてリソースを使用する場合は、プロジェクトを請求先アカウントに関連付ける必要があります。請求先アカウントとプロジェクトの間には 1 対多の関係があります。1 つのプロジェクトに設定できる請求先アカウントは 1 つだけですが、1 つの請求先アカウントには複数のプロジェクトを関連付けることができます。

請求先アカウントを使用して、一連のプロジェクトのリソース使用料の支払者を定義します。アカウントには、請求先のクレジットカードなどの支払い方法も定義します。請求先アカウントは組織レベルで定義できます。ここで定義すると、組織ノードの下にある複数のプロジェクトに請求先アカウントをリンクできます。組織内に複数の請求先アカウントを作成して、異なるコストセンターまたは部門を設定することもできます。

Cloud IAM が提供する一連のコントロールを使用すると、ユーザーによる請求の管理方法を制限できます。これらのコントロールにより、最小権限の原則を適用し、役割を明確に分離するのに役立ちます。たとえば、請求先アカウントを作成する権限と、特定の請求先アカウントとプロジェクトをリンクする権限を分離できます。

課金のコンセプトと設定の詳細については、請求オンボーディング チェックリストをご覧ください。

請求書を分析してエクスポートする

適切な権限があれば、GCP Console で費用の明細や取引履歴などを確認できます。この情報は請求先アカウントごとに表示されます。このコンソールには、インタラクティブな請求レポートも表示されます。このレポートでは、プロジェクト、プロダクト、期間でフィルタリングし、情報を絞り込むことができます。GCP の設定が複雑でなければ、GCP Console の機能で十分です。

ただし、通常はカスタム分析でレポートを作成し、クラウド関連の支出を確認する必要があります。この作業を行うには、請求料金を毎日エクスポートする機能を有効にします。CSV または JSON ファイルにエクスポートして Cloud Storage バケットに保存するようにファイルへのエクスポートを構成できます。また、BigQuery へのエクスポートも構成できます。リソースに適用されているラベルもエクスポートされます。

BigQuery へのエクスポートを有効にすることをおすすめします。ファイルへのエクスポートと比べると、費用の内訳をよりきめ細かく表示できます。請求データが BigQuery に取り込まれると、財務チームが標準の SQL でデータを分析し、BigQuery と統合できます。

容量要件を計画する

GCP プロジェクトには割り当て量が設定され、特定のリソースまたは API による使用量が制限されています。予期しない使用量の急増を防ぐことで、より広い GCP コミュニティを保護できます。この割り当てにより、少数のユーザーやプロジェクトが特定のリージョンやゾーンの CPU コアを占有しないように制限できます。

リソースの使用量が予期せず制限されないように、プロジェクトの容量要件を事前に計画しておく必要があります。割り当てが不足している場合は、GCP Console の [割り当て] セクションで変更を依頼できます。大容量が必要な場合は、GCP のセールスチームにお問い合わせください。

費用管理を行う

クラウド サービスのスケールアップに合わせて費用も上昇します。GCP では、リソースの使用量を制限し、関係者に請求関連のイベントを通知するために、いくつかの方法が用意されています。

予算を定義すると、支出額が特定のしきい値に達したときにアラートを生成できます。アラートはメールで送信されます。プログラムで通知する場合は、Cloud Pub/Sub メッセージを生成できます。予算は、請求先アカウント全体に適用されるか、請求先アカウントにリンクされている個々のプロジェクトに適用されます。たとえば、請求先アカウントの月額支出の合計が、指定した予算額の 50、80 または 100 パーセントに達したときにアラートを生成するように予算を作成できます。ただし、予算で支出が制限されるわけではありません。これは、アラートの生成を目的としています。詳しくは、予算のアラートのドキュメントをご覧ください。費用管理の簡素化に役立つベスト プラクティス、設計上の決定、構成オプションについては、Cloud Billing オンボーディング チェックリストをご覧ください。

特定のリソースの使用量を制限するために、割り当てを使用することもできます。たとえば、プロジェクトが BigQuery で過剰に使用されないように、BigQuery API に「1 日あたりのクエリ使用量」を設定できます。

サポート パッケージを購入する

GCP では、コミュニティ フォーラムから有料サポート パッケージまで、問題発生時にさまざまな方法でサポートを利用できます。ビジネスに不可欠なワークロードを保護するため、エンタープライズ サポート パッケージの購入をおすすめします。詳しくは、GCP サポート ポータルをご覧ください。

購入するサポートレベルによっては、サポート チケットを発行できる個人が限定される場合があります。このため、サポート用クリアリングハウスまたはトリアージ デスクの設置をおすすめします。これにより、チケットの重複や連絡ミスを避け、Google Cloud Support との連絡状況を最大限明瞭にできます。

エキスパートのヘルプを利用する

Google Cloud Professional Services Organization(PSO)は、GCP への移行に役立つコンサルティング サービスを提供しています。PSO のコンサルタントが、担当チームにベスト プラクティスや指針を指導して、ソリューションの実装を成功へと導きます。サービスは、ワークロードの計画、デプロイ、実行、最適化に役立つパッケージの形式で提供されます。

GCP には Google Cloud パートナーの強力なエコシステムもあります。大規模なグローバル システム インテグレータから機械学習のような特定分野を専門とするパートナーまで、さまざまなパートナーが参加しています。これらのパートナーは、GCP を使用して成功する方法を提示し、プロジェクトの加速化とビジネスの成果向上をサポートします。企業のお客様は、GCP の実装を計画して実行するためにパートナーの利用をおすすめします。

センター オブ エクセレンスを構築する

Google は、このようなプロダクトへの投資を続けており、新しい機能が次々と導入されています。組織の情報、経験、パターンを wiki、Google サイト、または内部のサイトといった内部の知識ベースにキャプチャすることで、価値を生み出すことができます。

同様に、組織内で GCP のエキスパートを指名することもおすすめします。エキスパートのスキル向上に役立つさまざまなトレーニングと認定資格が用意されています。Google Cloud のブログを購読すると、常に最新のニュース、お知らせ、お客様の事例を確認できます。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...