このガイドでは、Google Cloud への移行を進めている企業のお客様にベスト プラクティスを紹介します。このガイドは、すべての推奨事項を説明するものではありません。企業のアーキテクトや技術担当者の方が活動の範囲を把握し、適切な計画を作成できるように役立つ情報を提供することを目的としています。各セクションには、主要な作業の説明と参考情報のリンクが記載されています。
このガイドを読む前に、プラットフォームの概要を確認して、Google Cloud の全体像を把握することをおすすめします。
使ってみる
Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。
無料で開始組織の設定
リソース階層を定義する
Google Cloud のリソースは階層的に編成されます。この階層により、企業の運用体制を Google Cloud にマッピングし、関連リソースのグループのアクセス制御と権限を管理できます。次の図は、階層の例を示しています。
階層の最上位ノードは組織リソースで、組織（会社など）を表します。組織リソースは、階層の下にあるすべてのリソースを集中管理します。
階層の次のノードはフォルダです。フォルダを使用すると、親組織のさまざまな部署やチームの要件を分離できます。また、本番環境と開発環境のリソースを分けることもできます。
階層の一番下にあるのがプロジェクトです。プロジェクトには、アプリを構成するコンピューティング、ストレージ、ネットワーク リソースが含まれます。プロジェクトについては、このドキュメントの後半で詳しく説明します。
構造は柔軟に定義できます。変化する要件にも対応できます。まだ Google Cloud に慣れていない場合は、初期の要件を満たす最も単純な構造を採用できます。詳細については、Resource Manager の概要をご覧ください。
組織ノードを作成する
Google Cloud でサポートされている機能の多くは組織ノードを必要とします。Cloud Identity を使用して、example.com などの会社のインターネット ドメインにマッピングする組織ノードを作成できます。また、既存の Google Cloud プロジェクトや請求先アカウントを組織ノードに移行できます。詳しくは、組織の作成と管理をご覧ください。
設定でサポートが必要な場合は、組織設定ウィザードをご覧ください。
プロジェクト構造を指定する
Google Cloud を使用するにはプロジェクトが必要です。Compute Engine 仮想マシンや Cloud Storage バケットなどのすべての Google Cloud リソースが 1 つのプロジェクトに属します。プロジェクトの詳細については、プラットフォームの概要をご覧ください。
プロジェクトの範囲は自由に決めることができます。1 つのプロジェクトに複数のアプリを入れることも、逆に 1 つのアプリを複数のプロジェクトに関連付けることもできます。プロジェクト内のリソースを複数のリージョンや地域に分散することもできます。
一般的な推奨事項は、環境ごと、アプリケーションごとに 1 つのプロジェクトを使用することです。たとえば、「app1」と「app2」という 2 つのアプリケーションがあり、それぞれに開発環境と本番環境がある場合、4 つのプロジェクト app1-dev、app1-prod、app2-dev、app2-prod を作成します。これにより、環境が相互に分離されるため、開発プロジェクトに加えた変更が本番環境に悪影響を及ぼすことはありません。また、すべてのデベロッパーに開発プロジェクトへのアクセスを許可しながら、CI / CD パイプラインへの本番環境アクセスは制限できるため、アクセス制御を強化できます。
理想的なプロジェクト構造は要件によって異なります。また、時間とともに変わることもあります。プロジェクトの構造を設計するときには、リソースごとに請求を行う必要があるかどうか、どの程度の分離が必要か、リソースとアプリを管理するチームをどのように編成するかを決める必要があります。
プロジェクトの作成を自動化する
Google Cloud のプロジェクトとリソースの作成や管理を自動化すると、一貫した処理が可能になり、再現性を高め、テストを容易に行うことができます。構成をコードとして扱うことで、ソフトウェアの成果物と一緒に構成のバージョニングやライフサイクルを管理できます。自動化により、リソースに一貫した命名規則やラベル付けを適用するなど、ベスト プラクティスを実現できます。また、要件が変化した場合でも、プロジェクトのリファクタリングを簡単に行うことができます。
Google Cloud プロジェクトの場合は、Terraform または Config Controller を使用します。自動化ツールを使用すると、一貫した方法でデプロイする一連の Google Cloud リソースを記述できます。Google では、Terraform と Config Controller 用のプロジェクト作成テンプレートのサンプルを提供しています。また、これらのテンプレートを使用すると、プロジェクト作成プロセスでデベロッパーに適切なアクセス権が付与されるように、IAM によるアクセス制御の権限を設定することもできます。
ID とアクセスの管理
Google ID を管理する
ID プロバイダを Google Cloud と連携させる
管理対象外のアカウントを移行する
リソースへのアクセスを制御する
グループとサービス アカウントを使用する
組織ポリシーを定義する
Google ID を管理する
Google Cloud では、Google アカウントが認証とアクセス管理に使用されます。デベロッパーや他の技術スタッフが Google Cloud にアクセスするには Google アカウントが必要です。Cloud Identity を使用して、会社のドメイン名にフルマネージドの Google アカウントを関連付けることをおすすめします。これにより、デベロッパーは会社のメール ID を使用して Google Cloud にアクセスできるようになります。また、管理者は管理コンソールにアカウントを表示し、管理できるようになります。このドキュメントの以降のセクションでは、既存の ID プラットフォームを Cloud Identity に統合する方法について説明します。
Cloud Identity はスタンドアロンの IDaaS（Identity-as-a-Service）ソリューションです。これにより、Cloud Platform のユーザーは、Google Workspace（Google Cloud の生産性向上アプリのセット）から提供される多くの ID 管理機能を利用できます。Cloud Identity は Google Workspace のライセンスを必要としません。Cloud Identity に登録すると、会社のドメイン名に関連付けられた Google アカウントの管理レイヤが提供されます。この管理レイヤを介して、従業員に Google Cloud を含む Google サービスへのアクセスを許可または禁止します。Cloud Identity に登録すると、ドメインの組織ノードも作成されます。これにより、リソース階層を使用して会社の組織体制を Google Cloud リソースにマッピングし、管理できます。
詳細については、Cloud Identity ソリューションをご覧ください。
ID プロバイダを Google Cloud と連携させる
組織でオンプレミスまたはサードパーティの ID プロバイダを使用している場合は、ユーザー ディレクトリを Cloud Identity と同期し、ユーザーが会社の認証情報を使用して Google Cloud にアクセスできるようにします。これにより、ID プラットフォームを使用しながら、Cloud Identity で従業員による Google サービスへのアクセスを制御できます。
管理対象外のアカウントを移行する
ドメインのメンバーが会社のメールアドレスを使用して個人の Google アカウントを作成している場合（YouTube、Blogger などの Google サービスに登録した場合など）、これらのアカウントを移行し、Cloud Identity で管理できるようにすることを検討してください。これらのアカウントが別のメールアドレスを使用するように強制的に変更することもできます。
アカウントを移行する方法やアカウントの名前を強制的に変更する方法については、既存のユーザー アカウントの評価をご覧ください。
リソースへのアクセスを制御する
デベロッパーと IT スタッフには、Google Cloud リソースの使用を許可する必要があります。Identity and Access Management（IAM）を使用して、特定の Google Cloud リソースに対するアクセス権を詳細に設定できるため、他のリソースへの不要なアクセスを防ぐことができます。たとえば、IAM では、誰（ID）がどのようなアクセス権（ロール）をどのリソースに持つのかを定義できます。
権限を直接割り当てるのではなく、ロールを割り当てます。IAM のロールは権限のコレクションです。たとえば、BigQuery データ閲覧者のロールには、BigQuery テーブルの一覧表示、読み取り、クエリを行う権限が含まれていますが、新しいテーブルの作成や既存データの変更を行う権限は含まれていません。IAM には、一般的なユースケースに利用できる多くのロールが事前に定義されています。カスタムロールを作成することもできます。
IAM では、最小権限のセキュリティ原則を適用して、リソースに対して必要最低限のアクセス権を付与できます。IAM は、エンタープライズの組織で基本的なトピックです。Identity and Access Management の詳細については、次のリソースをご覧ください。
グループとサービス アカウントを使用して業務を委任する
同じ業務に携わるユーザーをグループにまとめ、IAM のロールを個々のユーザーではなくグループに割り当てることをおすすめします。たとえば、「データ サイエンティスト」というグループを作成し、BigQuery や Cloud Storage を操作できるように適切なロールを割り当てます。新しいデータ サイエンティストがチームに参加したときに、グループに追加するだけで、定義済みの権限を継承できます。グループの作成と管理は管理コンソールで行います。
企業のお客様は、次の 6 つのグループを作成することをおすすめします。
| グループ | 関数 |
|---|---|
gcp-organization-admins
|
組織の管理者は、組織で使用するリソースの構造の編成を担当します。 |
gcp-network-admins
|
ネットワーク管理者は、ネットワーク、サブネット、ファイアウォール ルール、およびクラウド ルーター、クラウド VPN、クラウド ロードバランサなどのネットワーク デバイスの作成を担当します。 |
gcp-security-admins
|
セキュリティ管理者は、アクセス管理や組織の制約ポリシーなどの組織全体のセキュリティ ポリシーの確立と管理を担当します。 |
gcp-billing-admins
|
請求管理者は、請求先アカウントの設定とその使用状況の監視を担当します。 |
gcp-devops
|
DevOps 従事者は、継続的インテグレーション、継続的デリバリー、モニタリング、システム プロビジョニングをサポートするエンドツーエンドのパイプラインを作成または管理します。 |
gcp-developers
|
デベロッパーはアプリケーションの設計、コーディング、テストを担当します。 |
サービス アカウントは特別なタイプの Google アカウントで、個々のユーザーではなく、Google Cloud サービスの ID またはアプリを表します。ユーザーやグループと同様に、サービス アカウントにも IAM 役割を割り当て、特定のリソースへのアクセス権を付与できます。サービス アカウントの認証はパスワードではなくキーで行います。Google は、Google Cloud 上で実行するコードのサービス アカウント キーを管理し、ローテーションします。サーバー間の通信にはサービス アカウントを使用することをおすすめします。
組織ポリシーを定義する
組織のポリシーを使用すると、組織のクラウド リソースをプログラムで集中管理できます。IAM で重要なのは「誰が」です。権限に基づいて特定のリソースに対するアクションをユーザーやグループに承認する人物が重要になります。組織ポリシーで重要なのは「何を」で、特定のリソースに制限を設定し、どのような構成と使用方法が可能であるかを決定することが重要です。たとえば、仮想マシン インスタンスに外部の IP アドレスが割り当てられないように制限を定義できます。
リソースのポリシーはリソースの階層内で設定します。リソースのポリシーはそのすべての子孫に継承されます。最上位の組織ノードにポリシーを適用することで、基本的な一連の制約が階層内のすべての要素に適用されます。継承されたポリシーの上書きや結合を行う場合は、子ノードにカスタム組織ポリシーを設定します。
ネットワークとセキュリティ
VPC を使用してネットワークを定義する
ファイアウォール ルールでトラフィックを管理する
外部アクセスを制限する
ネットワーク制御を一元管理する
企業ネットワークを接続する
アプリとデータを保護する
VPC を使用してネットワークを定義する
VPC とサブネットを使用してネットワークを計画し、関連リソースをグループ化して分離します。VPC（Virtual Private Cloud）は物理ネットワークを仮想化したネットワークです。VPC ネットワークは、Compute Engine 仮想マシン（VM）インスタンスと、VM インスタンスを利用する Google Kubernetes Engine（GKE）、Dataproc、Dataflow などのサービスに対して、スケーラブルで柔軟なネットワークを提供します。
VPC ネットワークはグローバルなリソースです。公共のインターネットを経由することなく、単一の VPC で複数のリージョンにまたがる通信を実現できます。つまり、1 つの Google Cloud プロジェクトから世界中に分散したリソースを接続および管理でき、1 つのプロジェクトで複数の独立した VPC ネットワークを作成できます。
VPC ネットワーク自体には IP アドレス範囲を定義しません。各 VPC ネットワークはサブネットワークという 1 つ以上のパーティションから構成され、それぞれのサブネットに 1 つ以上の IP アドレス範囲が定義されています。サブネットはリージョン リソースです。1 つのサブネットは 1 つのリージョンに明示的に関連付けられています。
プロジェクトを作成すると、デフォルト ネットワークも自動的に作成されます。これは本番環境には適していません。代わりに、カスタムモードの VPC ネットワークを作成します。詳しくは、VPC 設計のためのおすすめの方法とリファレンス アーキテクチャをご覧ください。
VPC の詳細については、VPC の概要をご覧ください。
ファイアウォール ルールでトラフィックを管理する
各 VPC ネットワークは分散仮想ファイアウォールを実装しています。Compute Engine の VM インスタンスや GKE クラスタなど、VPC に接続しているリソース間のトラフィックを許可または拒否するファイアウォール ルールを構成します。ファイアウォール ルールは仮想ネットワーキング レベルで適用されるため、インスタンスが使用するオペレーティング システムに関係なく、効果的な保護とトラフィック制御を行うことができます。ファイアウォールはステートフルです。つまり、許可されているフローの場合、戻りトラフィックは自動的に許可されます。
ファイアウォール ルールは VPC ネットワークごとに異なります。このルールには、トラフィックの種類（ポートやプロトコルなど）とトラフィックの送信元または宛先（IP アドレス、サブネット、タグ、サービス アカウントなど）を指定できます。たとえば、特定のサービス アカウントに関連付けられた VM インスタンスが、特定の送信元サブネットからポート 80 への TCP トラフィックを許可するように、上りルールを作成できます。各 VPC ネットワークには、暗黙のデフォルト ファイアウォール ルールが自動的に設定されます。
アプリが GKE でホストされている場合は、ネットワーク トラフィックの管理とファイアウォール ルールの構成について別の注意事項があります。たとえば、GKE クラスタ内の内部通信を制御するためにネットワーク ポリシーを作成できます。Istio のようなサービス メッシュを使用し、クラスタとの通信をさらに管理して保護することもできます。詳しくは、GKE ネットワーキングのコンセプトをご覧ください。
外部アクセスを制限する
VPC を活用する Google Cloud リソースを作成するときに、リソースを設置するネットワークとサブネットを選択します。リソースには、サブネットに関連付けられている IP 範囲の 1 つから内部 IP アドレスが割り当てられます。ファイアウォール ルールで拒否されない限り、VPC ネットワーク内のリソースは内部 IP アドレスで相互に通信を行うことができます。
インターネットと通信するには、リソースに外部のパブリック IP アドレスを割り当てるか、Cloud NAT を使用する必要があります。外部ネットワークになんらかの方法で（たとえば VPN 経由で）接続していない限り、同じ VPC ネットワークにない外部のリソースに接続するには、外部 IP アドレスが必要になります。詳しくは、IP アドレスのドキュメントをご覧ください。
インターネットへのアクセスは、必要なリソースにのみ許可する必要があります。限定公開の Google アクセスを使用すると、プライベートの内部 IP アドレスしかないリソースでも多くの Google API やサービスにアクセスできます。このプライベート アクセスにより、インターネットから隔離された状態で、リソースは主要な Google サービスや Google Cloud サービスとやりとりができます。
ネットワーク制御を一元管理する
共有 VPC を使用すると、共通の VPC ネットワークに接続できます。これらのプロジェクト内のリソースは、内部 IP を使用してプロジェクトの境界を越えて安全で効率的な通信を行います。プロジェクト全体に一貫したネットワーク ポリシーを適用することで、サブネット、ルート、ファイアウォールなどの共有ネットワーク リソースを中央のホスト プロジェクトから一元管理できます。
共有 VPC と IAM を使用すると、ネットワークの管理とプロジェクトの管理を切り分けることができます。これにより、最小権限の原則を実装しやすくなります。たとえば、一元管理されたネットワークのチームは、参加しているプロジェクトに対する権限がなくてもネットワークを管理できます。同様に、プロジェクト管理者は、共有ネットワークの操作権限なしでプロジェクトのリソースを管理できます。
企業ネットワークを接続する
既存のオンプレミス インフラストラクチャと Google Cloud リソースを接続する場合、帯域幅、レイテンシ、SLA の要件を検討して最適な接続方法を選択する必要があります。
Google Cloud へのインターネット接続を経由することなく、オンプレミスと VPC ネットワークの間でデータを確実に転送できる、エンタープライズ クラスの低レイテンシかつ高可用性の接続が必要な場合は、Cloud Interconnect を使用します。
- Dedicated Interconnect は、オンプレミス ネットワークと Google のネットワークを物理的に直接接続します。
- Partner Interconnect は、サポート対象のサービス プロバイダを介して、オンプレミス ネットワークと Google Cloud VPC ネットワークを接続します。
Cloud Interconnect の低レイテンシと高可用性を必要としない場合や、クラウドへの移行を始めたばかりの場合は、Cloud VPN を使用して、オンプレミス ネットワークと VPC 間に暗号化された IPsec VPN トンネルを設定します。プライベートな直接接続と比べて、IPsec VPN トンネルはオーバーヘッドが少なく、低コストです。
アプリとデータを保護する
Google Cloud では、データセンターの物理的な安全対策から、独自のセキュリティ ハードウェア、研究者から構成された専任チームまで、堅牢なセキュリティ機能でインフラストラクチャとサービス全体を保護しています。しかし、Google Cloud リソースの保護にはお客様の協力が不可欠です。アプリとデータが確実に保護されるように、適切な対策を講じるようお願いいたします。
ファイアウォール ルールと VPC の分離に加えて、次のツールを使用して、アプリを保護してください。
- VPC Service Controls を使用して、Google Cloud リソースにセキュリティ境界を定義し、VPC 内のデータを制限してデータ引き出しのリスクを軽減します。
- Google Cloud グローバル HTTP(S) ロードバランサを使用して、インターネットに接続するサービスの高可用性とスケーリングをサポートします。
- Google Cloud Armor を HTTP(S) ロードバランサと統合して、ネットワーク エッジで信頼できる既知の IP アドレスまたは信頼できない IP アドレスへのアクセスを制御し、DDoS に対する保護を実現します。
- Identity-Aware Proxy（IAP）を使用して、ユーザーの ID とリクエストのコンテキストを確認し、ユーザーにアクセスを許可するかどうか判断します。これにより、アプリへのアクセスを制御します。
Google Cloud では、転送中のデータと保存データの両方を暗号化することでデータの安全性を維持しています。デフォルトでは、保存データの暗号化に Google 管理の暗号鍵が使用されます。センシティブ データの場合は、Google Cloud で鍵を管理できます。より細かい制御が必要な場合は、Google Cloud の外部で管理されている独自の暗号鍵を指定できます。独自の鍵を管理または維持するとオーバーヘッドが発生するため、この方法は本当に重要なデータにのみ使用することをおすすめします。詳細については、保存データの暗号化をご覧ください。
ロギング、モニタリング、オペレーション
ロギングとモニタリングを一元管理する
複数のアプリ、データ パイプライン、その他のプロセスを異なるプラットフォームで実行している企業が少なくありません。これらのアプリやプロセスを正常な状態に維持することは、デベロッパーと運用チームにとって重要な責務となります。正常な状態を維持するために改善するために、Cloud Logging と Cloud Monitoring を使用して、ロギング、モニタリング、デバッグ、トレース、プロファイリングなどを管理することをおすすめします。
ログは、アプリやプロセスの正常性を診断する基本的な情報源となります。Cloud Logging を使用すると、ログデータとイベントの保存、表示、検索、分析、アラートを行うことができます。Logging は多くの Google Cloud サービスとネイティブに統合されています。Compute Engine または Amazon Elastic Compute Cloud（EC2）仮想マシン インスタンスでホストされているアプリケーションの場合、Logging エージェントをインストールして、Cloud Logging に自動的にログを転送できます。また、Cloud Logging は、オンプレミスで実行されるアプリケーションなど、任意のソースからのログの書き込みに使用できる API も提供します。Logging を使用すると、すべてのアプリからログを一元管理します。
安定したオペレーションを確実に行うには、ログだけでなく、アプリやシステムの他の側面もモニタリングする必要があります。Cloud Monitoring を使用すると、アプリとインフラストラクチャのパフォーマンス、稼働時間、全体的な状態を可視化できます。Monitoring では、イベント、指標、メタデータを取り込み、ダッシュボード、チャート、アラートで分析情報を提供します。Monitoring では、多くの Google Cloud やサードパーティ ソースの指標をすぐに使用できます。Monitoring ではカスタム指標も定義できます。たとえば、異常な行動やトレンドが運用チームに通知されるように、指標を使用してアラート ポリシーを定義できます。Monitoring の柔軟ダッシュボードと豊富な可視化ツールにより、問題の兆候を発見できます。
監査証跡を設定する
アプリやプロセスレベルのログを収集するだけでなく、デベロッパーと IT チームが Google Cloud のリソースをどのように使用しているかを追跡し、トレース情報を維持する必要があります。Cloud Audit Logs を使用すると、Google Cloud プロジェクト内で「誰が、何を、どこで、いつ行ったか」を調べるのに役立ちます。監査ログを書き込む Google Cloud サービスの一覧については、監査ログ付きの Google サービスをご覧ください。監査ログの表示権限を持つユーザーを制限するには、IAM コントロールを使用します。
Cloud 監査ログは、いくつかの種類のアクティビティをキャプチャします。管理アクティビティ ログには、リソースの構成またはメタデータを変更する API 呼び出しやその他の管理アクションに関するログエントリが含まれます。管理アクティビティ ログは常に有効です。データアクセス監査ログには、ユーザー提供データを作成、変更、または読み込む API 呼び出しが記録されます。データアクセス監査ログは、非常に大きくなる可能性があるため、デフォルトでは無効になっていますが、データ アクセスログを生成する Google Cloud サービスを構成できます。
監査ログの詳細については、Cloud Audit Logs をご覧ください。
ログをエクスポートする
Logging は、アプリと監査ログを一定期間保持します。法令遵守のため、ログの保存期間の延長が必要になる場合があります。あるいは、履歴分析のためにログの保存が必要になることもあります。
ログは、Cloud Storage、BigQuery、Pub/Sub に転送できます。フィルタを使用することで、エクスポートへのリソースの追加や除外を行うことができます。たとえば、すべての Compute Engine ログをエクスポートし、サイズの大きい Cloud Load Balancing ログを除外することなどが可能です。
ログのエクスポート先はユースケースによって異なります。多くの企業は複数の場所にログをエクスポートしています。大まかに言うと、法令遵守のために長期保存する場合は Cloud Storage を使用します。ログの分析には BigQuery を使用します。BigQuery は SQL クエリとサードパーティ ツールの大規模なエコシステムをサポートしています。
ログのエクスポートの詳細については、Logging のエクスポートのための設計パターンをご覧ください。
DevOps とサイト信頼性エンジニアリングを採用する
俊敏性を高め、アプリや機能の市場投入までの時間を短縮するには、開発、運用、ネットワーキング、セキュリティの各チーム間のサイロ化を解消しなければなりません。そのためには、DevOps というプロセス、文化、ツールが必要になります。
Google Cloud には、DevOps の採用に役立つさまざまなサービスが用意されています。たとえば、統合されたソースコード リポジトリ、継続的デリバリー ツール、Cloud Monitoring の豊富なモニタリング機能、オープンソース ツールの強力なサポートなどを利用できます。詳細については、Google Cloud の DevOps ソリューションをご覧ください。
サイト信頼性エンジニアリング（SRE）は DevOps と密接に関連した一連のプラクティスです。これらは、Google の本番環境インフラストラクチャを管理する SRE チームのプラクティスから進化したものです。多くの企業にとって SRE の専任部門を設ける必要はないでしょうが、運用戦略の立案に役立つプラクティスを学ぶため、SRE の書籍をご覧になることをおすすめします。
クラウド アーキテクチャ
移行を計画する
オンプレミスのアプリとインフラストラクチャをクラウドに移行する場合、評価と計画を慎重に行う必要があります。それぞれのアプリについて、「リフト＆シフト」から「変換して移行」まで、さまざまな移行戦略を評価する必要があります。Google Cloud には、仮想マシンの移行、データの転送、ワークロードのモダナイズに役立つツールが用意されています。詳細については、移行センターをご覧ください。
規制、技術または財務上の制約から、特定のアプリがパブリック クラウドに移行できないことや、移行が望ましくない場合があります。その場合、オンプレミスと Google Cloud のインフラストラクチャでワークロードの分散と統合が必要になる可能性があります。この環境はハイブリッド クラウドといいます。ハイブリッド ワークロードの詳細については、ハイブリッド クラウドをご覧ください。ハイブリッドとマルチクラウド ソリューションの詳細については、パターンと実践をご覧ください。
マネージド サービスを使用する
クラウドを採用する主な理由は、IT のオーバーヘッドを削減して効率化を図り、コアビジネスに集中できるようにすることです。運用の負担を軽減して総所有コスト（TCO）を抑えるには、DevOps プラクティスの採用や自動化の促進に加え、Google Cloud マネージド サービスを使用する必要があります。
マネージド サービスを使用すると、アプリケーション スタックの各部分を個別にインストールしてサポートや操作を行うのではなく、アプリケーション スタックの一部をサービスとして使用できます。たとえば、VM インスタンスに MySQL データベースをインストールして自己管理する代わりに、Cloud SQL によって提供される MySQL データベースを使用できます。Google Cloud を使用して、基盤となるインフラストラクチャを管理し、バックアップ、更新、レプリケーションを自動化できます。
それぞれのマネージド サービスで提供される SLA を評価することをおすすめします。
Google Cloud では、マネージド データベースからビッグデータ処理ツールまで、一般的な多くのアプリ コンポーネントとユースケースで使用できるマネージド サービスとサーバーレス オプションを提供しています。このマネージド サービスの多くは一般的なオープンソース フレームワークとプラットフォームに対応しているため、これらのオープンソース プラットフォームを利用する既存のアプリをクラウドにリフト＆シフトすることで TCO を低減できます。
高可用性を設計する
ミッション クリティカルなアプリの稼働時間を維持するには、障害や予期しない負荷の変化にも対応できる復元性の高いアプリを設計する必要があります。高可用性とは、システム内のコンポーネントに障害が発生しても機能し続けるアプリの能力を意味します。高可用性のアーキテクチャでは通常、コンピューティング リソースを分散し、負荷分散やデータのレプリケーションが行われています。高可用性プロビジョニングの範囲は、アプリによって異なる場合があります。可用性のコンセプトの詳細については、地域とリージョンのドキュメントをご覧ください。
特定のゾーンの障害から保護するため、Compute Engine VM インスタンスや GKE クラスタなどのコンピューティング リソースをリージョン内の使用可能なゾーン全体に分散する必要があります。地理的に分散した複数のリージョンにリソースを配置すると、リージョン全体の損失を防ぎ、コンピューティング リソースの可用性をさらに向上させることができます。コンピューティング リソースを作成する場所のガイダンスについては、Compute Engine のリージョン選択に関するベスト プラクティスをご覧ください。
Google Cloud では、いくつかの方法で負荷分散を行っています。インターネットに接続するアプリの公開でよく使用されるのが HTTP(S) ロードバランサです。このロードバランサはグローバルな負荷分散を行うため、異なる地域のリージョン間で負荷を分散できます。ゾーンまたはリージョンが使用不能になると、ロードバランサが使用可能なゾーンにトラフィックを転送します。詳しくは、グローバル負荷分散によるアプリケーションの処理能力の改善をご覧ください。
データ ストレージを選択する際には可用性も考慮する必要があります。一部の Google Cloud データ ストレージ サービスでは、1 つのリージョン内の複数のゾーンの間でデータを複製できます。他のサービスでは、地理的なエリアの複数のリージョンでデータが自動的に複製されますが、レイテンシと整合性モデルがトレードオフになることがあります。最適なデータ ストレージ サービスはアプリと可用性の要件によって異なります。
障害復旧戦略を計画する
高可用性の設計に加えて、大規模な機能停止や自然災害が発生した場合でも事業を継続できるように計画を作成しておく必要があります。障害復旧（DR）は重大なインシデントから復旧するための機能です。高可用性のプロビジョニングが無効であるか、利用できない場合は、障害回復を開始する必要があります。
効果的な DR プランを作成するには計画とテストが必要です。早い段階で DR 計画を作成することをおすすめします。詳しくは、障害復旧計画ガイドと関連記事をご覧ください。
リソース
請求と管理
リソースの課金方法を理解する
請求と権限を設定する
請求書を分析してエクスポートする
容量要件を計画する
費用管理を行う
サポート パッケージを購入する
エキスパートのヘルプを利用する
センターオブ エクセレンスを構築する
リソースの課金方法を理解する
Google Cloud では消費モデルが採用されています。特定の支払期間でのリソースまたはプロダクトの使用量に基づいて課金が行われます。Google Cloud プロダクトを使用するには、Cloud 請求先アカウントを有効にする必要があります。多くのプロダクトは、さまざまな方法で使用量を測定しています。次に例を示します。
- 時間: マシンの稼働時間（秒）
- ボリューム: 保存されるデータ量
- 実行されたオペレーションの数
- 上記コンセプトのバリエーション
費用を正確に測定できるように、システム内のコンポーネントがどのように課金されるのかを理解しておく必要があります。各プロダクトのドキュメントに詳細な料金情報が記載されています。多くのプロダクトには無料枠が用意されています。一定のしきい値未満の使用量に関しては請求先アカウントに返金されるため、課金は発生しません。無料枠に用意された量を超過したリソースの使用については、請求先アカウントに課金されます。
Google Cloud の料金体系、イノベーション、割引の詳細については、料金ページをご覧ください。
請求管理を設定する
Compute Engine VM、Cloud Storage バケット、BigQuery データセットなどの Google Cloud リソースはすべて、Google Cloud プロジェクトに関連付ける必要があります。無料枠に用意されたリソースを含め、リソースを使用するには、プロジェクトを請求先アカウントに関連付ける必要があります。請求先アカウントとプロジェクトの間には 1 対多の関係があります。1 つのプロジェクトに関連付けることができる請求先アカウントは 1 つのみですが、1 つの請求先アカウントを多数のプロジェクトに関連付けることができます。
請求先アカウントは、一連のプロジェクトのリソース使用料の支払者を定義します。請求先アカウントは、セルフサービス（オンライン）自動支払いアカウントか、請求書発行アカウントのいずれかにできます。セルフサービス（オンライン）アカウントでは、費用が自動的に課金されるお支払い方法（クレジット カードなど）をご利用いただけます。請求書発行アカウントでは、小切手または銀行振込でお支払いいただけます。使用している請求先アカウントの種類を確認するには、Cloud 請求先アカウントの種類と請求期間の確認をご覧ください。
請求先アカウントは組織レベルで定義できます。ここで定義すると、組織ノードの下にある複数のプロジェクトに請求先アカウントをリンクできます。組織内で複数の請求先アカウントを作成することもできますが、一元化された請求先アカウントを 1 つのみ作成することをおすすめします。
IAM が提供する一連のコントロールを使用すると、ユーザーによる請求の管理方法を制限できます。これらのコントロールにより、最小権限の原則を適用し、ロールを明確に分離するのに役立ちます。たとえば、請求先アカウントを作成する権限と、特定の請求先アカウントとプロジェクトをリンクする権限を分離できます。
課金のコンセプトと設定の詳細については、請求オンボーディング チェックリストをご覧ください。
請求書を分析してエクスポートする
適切な権限を持つユーザーは、コンソールで費用、取引履歴などの詳細を確認できます。この情報は請求先アカウントごとに表示されます。このコンソールには、インタラクティブな請求レポートも表示されます。このレポートでは、プロジェクト、プロダクト、期間でフィルタリングし、費用を詳細に分析できます。Google Cloud の設定がそれほど複雑でなければ、コンソールの機能で十分です。
ただし、通常の場合にカスタム分析でレポートを作成して、クラウド関連の支出を確認する必要がある場合は、BigQuery データセットへの Cloud Billing データの日次エクスポートを有効にすることをおすすめします。エクスポートされたデータには、リソースに適用されているラベルが含まれます。
タイミングが重要です。Cloud 請求先アカウントを作成するのと同時に、BigQuery へのエクスポートを有効にすることをおすすめします。BigQuery データセットには、Cloud Billing エクスポートの設定日以降に発生した Google Cloud の課金データのみが反映されます。すなわち、Google Cloud の課金データが過去にさかのぼって追加されることはありません。エクスポートを有効にする前の Cloud Billing データは表示されません。課金データが BigQuery に取り込まれると、財務チームは標準 SQL を使用してデータを分析し、BigQuery と統合されたツール（データポータルなど）を使用できるようになります。
容量要件を計画する
Google Cloud プロジェクトには、特定のリソースまたは API の使用量を制限する割り当てがあります。割り当ては予期しない使用量の急増を防ぎ、Google Cloud コミュニティを広く保護するための仕組みです。この割り当てにより、少数のユーザーやプロジェクトが特定のリージョンやゾーンの CPU コアを占有しないように制限できます。
リソースの使用量が予期せず制限されないように、プロジェクトの容量要件を事前に計画しておく必要があります。割り当てが十分でない場合は、コンソールの割り当てセクションで変更をリクエストできます。大容量が必要な場合は、Google Cloud のセールスチームにお問い合わせください。
費用管理を行う
クラウド サービスのスケールアップに合わせて費用も上昇します。Google Cloud では、リソースの使用量を制限し、関係者に請求関連のイベントを通知するために、いくつかの方法が用意されています。
予算を定義すると、支出額が特定のしきい値に達したときにアラートを生成できます。アラートはメールで送信されます。プログラムで通知する場合は、Pub/Sub メッセージを生成できます。予算は、請求先アカウント全体に適用されるか、請求先アカウントにリンクされている個々のプロジェクトに適用されます。たとえば、請求先アカウントの月額支出の合計が、指定した予算額の 50、80 または 100 パーセントに達したときにアラートを生成するように予算を作成できます。ただし、予算で支出が制限されるわけではありません。これは、アラートの生成を目的としています。詳しくは、予算のアラートのドキュメントをご覧ください。費用管理の簡素化に役立つベスト プラクティス、設計上の決定、構成オプションについては、Cloud Billing オンボーディング チェックリストをご覧ください。
特定のリソースの使用量を制限するために、割り当てを使用することもできます。たとえば、プロジェクトが BigQuery で過剰に使用されないように、BigQuery API に「1 日あたりのクエリ使用量」を設定できます。
サポート パッケージを購入する
Google Cloud で問題が発生した場合、コミュニティ フォーラムから有料サポート パッケージまで、さまざまな方法でサポートを利用できます。ビジネスに不可欠なワークロードを保護するため、エンタープライズ サポート パッケージの購入をおすすめします。詳しくは、Google Cloud のサポート ポータルをご覧ください。
購入するサポートレベルによっては、サポート チケットを発行できる個人が限定される場合があります。このため、サポート用クリアリングハウスまたはトリアージ デスクの設置をおすすめします。これにより、チケットの重複や連絡ミスを避け、Google Cloud Support との連絡状況を最大限明瞭にできます。
エキスパートのヘルプを利用する
Google Cloud の Professional Services Organization（PSO）は、Google Cloud のご利用に役立つコンサルティング サービスを提供しています。PSO のコンサルタントが、担当チームにベスト プラクティスや指針を指導して、ソリューションの実装を成功へと導きます。サービスは、ワークロードの計画、デプロイ、実行、最適化に役立つパッケージの形式で提供されます。
Google Cloud には Google Cloud パートナーの強力なエコシステムもあります。大規模なグローバル システム インテグレータから機械学習のような特定分野を専門とするパートナーまで、さまざまなパートナーが参加しています。これらのパートナーは、Google Cloud を使用して成功する方法を提示し、プロジェクトの加速とビジネスの成果向上をサポートします。企業のお客様は、Google Cloud の実装を計画して実行するためにパートナーを利用することをおすすめします。
センターオブ エクセレンスを構築する
Google は、このようなプロダクトへの投資を続けており、新しい機能が次々と導入されています。組織の情報、経験、パターンを wiki、Google サイト、または内部のサイトといった内部の知識ベースにキャプチャすることで、価値を生み出すことができます。
同様に、組織内で Google Cloud のエキスパートを指名することもおすすめします。エキスパートのスキル向上に役立つさまざまなトレーニングと認定資格が用意されています。Google Cloud のブログを購読すると、常に最新のニュース、お知らせ、お客様の事例を確認できます。
次のステップ
- リリース チェックリストを確認する。
- ビジネスを最適化する Google Cloud ソリューションを探す。
他のプラットフォームと比較する。
ブログを見る
Google Cloud に関するリファレンス アーキテクチャ、図、チュートリアル、ベスト プラクティスを確認する。Cloud Architecture Center を確認します。