Google Cloud アーキテクチャ フレームワークのこのドキュメントでは、Google Cloud でリソースを整理および管理するためのベスト プラクティスについて説明します。
リソース階層
Google Cloud のリソースは、組織、フォルダ、プロジェクトに階層的に配置されています。このような階層を使用することで、アクセス制御、構成設定、ポリシーなどリソースに共通する要素を簡単に管理できます。クラウド リソースの階層を設計するためのベスト プラクティスについては、Google Cloud ランディング ゾーンのリソース階層を決定するをご覧ください。
リソースラベルとタグ
このセクションでは、ラベルとタグを使用して Google Cloud リソースを整理するためのベスト プラクティスについて説明します。
シンプルなフォルダ構造を使用する
フォルダを使用すると、プロジェクトとサブフォルダを任意に組み合わせることができます。Google Cloud リソースを整理するシンプルなフォルダ構造を作成します。必要に応じてレベルを追加して、ビジネスニーズをサポートできます。フォルダ構造は柔軟で拡張可能です。詳細については、フォルダの作成と管理をご覧ください。
フォルダとプロジェクトを使用してデータ ガバナンス ポリシーを反映させる
組織内のデータ ガバナンス ポリシーを反映するように、フォルダ、サブフォルダ、プロジェクトを使用してリソースを分離できます。たとえば、フォルダとプロジェクトの組み合わせを使用して、財務、人事、エンジニアリングを分離できます。
プロジェクトを使用して、同じ信頼境界を共有するリソースをグループ化してください。たとえば、同じプロダクトやマイクロサービスのリソースは、同じプロジェクトに含めることができます。詳細については、Google Cloud ランディング ゾーンのリソース階層を決定するをご覧ください。
プロジェクトの開始時にタグとラベルを使用する
Google Cloud プロダクトを初めて使うときにラベルとタグを使用できます（必ずしもすぐに使う必要はありません）。後でラベルとタグを追加する作業は手作業で行う必要があり、エラーが発生しやすくなります。
タグを使用すると、リソースに特定のタグが付加されているかどうかに基づいて、条件付きでポリシーの許可や拒否を行えます。ラベルとは、Google Cloud のインスタンスを整理する際に役立つ Key-Value ペアです。ラベルの詳細については、ラベルの要件、ラベルをサポートするサービスのリスト、ラベルの形式をご覧ください。
Resource Manager が提供するラベルとタグは、リソースの管理やコストの割り当てとレポートに役立ちます。また、きめ細かいアクセス制御を行うために、異なるリソースにポリシーを割り当てる際にも役立ちます。たとえば、ラベルとタグを使用して、さまざまなテナント リソースとサービスにきめ細かいアクセス権と管理の原則を適用できます。VM ラベルとネットワーク タグの詳細については、VM ラベルとネットワーク タグの関係をご覧ください。
ラベルは、次のようなさまざまな用途に使用できます。
- リソースに対する課金の管理: 課金システムでラベルを使用して、コストをラベル別に分割できます。たとえば、異なるコストセンターや予算にラベルを付けることができます。
- 類似した特性または関係に基づいたリソースのグループ化: ラベルを使用して、アプリケーション ライフサイクルのさまざまなステージや環境を分離できます。たとえば、本番環境、開発環境、テスト環境にラベルを付けることができます。
ラベルを割り当てて費用と請求のレポートをサポートする
統合レポート構造（プロジェクトごと、プロダクトごとなど）以外の属性に基づいて、詳細な費用と課金レポートをサポートするには、リソースにラベルを割り当てます。ラベルは、コストセンター、部門、特定のプロジェクトへの費用の割り当てや内部的な費用の振り替えに役立ちます。詳細については、費用最適化のカテゴリをご覧ください。
大量のラベルを作成しない
大量のラベルを作成しないでください。プロジェクト レベルでラベルを作成することをおすすめします。また、サブチームレベルではラベルを作成しないでください。必要以上に詳細なラベルを作成すると、分析にノイズが入る可能性があります。ラベルの一般的なユースケースについては、ラベルの一般的な使用例をご覧ください。
ラベルに機密情報を追加しない
ラベルは、機密情報を処理するように設計されていません。個人名や役職など、個人を特定できる情報もラベルには含めないでください。
プロジェクト名で情報を匿名化する
プロジェクト名は COMPANY_INITIAL_IDENTIFIER-ENVIRONMENT-APP_NAME のようにしてください。ここで、プレースホルダは一意なものとし、会社名やアプリケーション名は公表しないでください。チーム名やテクノロジーなど、将来変更される可能性がある属性は含めないでください。
タグを適用してビジネス ディメンションをモデル化する
タグを適用すると、組織構造、リージョン、ワークロードの種類、コストセンターなど、追加のビジネス ディメンションをモデル化できます。タグの詳細については、タグの概要、タグの継承、タグの作成と管理をご覧ください。タグをポリシーで使用する方法については、ポリシーとタグをご覧ください。タグを使用してアクセス制御を管理する方法については、タグとアクセス制御をご覧ください。
組織のポリシー
このセクションでは、クラウド リソース階層全体にわたる Google Cloud リソースにガバナンス ルールを構成するためのベスト プラクティスについて説明します。
プロジェクトの命名規則を確立する
SYSTEM_NAME-ENVIRONMENT（dev、test、uat、stage、prod）のように、標準化されたプロジェクト命名規則を設定します。
プロジェクト名の長さは 30 文字に制限されています。
COMPANY_TAG-SUB_GROUP/SUBSIDIARY_TAG のような接頭辞を適用できますが、企業の再編があると、プロジェクト名が過去のものになる場合があります。プロジェクト名から識別可能な名前をプロジェクト ラベルに移すことを検討してください。
プロジェクトの作成を自動化する
本番環境や大規模な企業向けのプロジェクトを作成するには、Deployment Manager や Google Cloud プロジェクト ファクトリ Terraform モジュールのような自動プロセスを使用します。これらのツールは、次の処理を行います。
- 開発環境、テスト環境、本番環境を作成し、適切な権限のあるプロジェクトを自動的に作成します。
- ロギングとモニタリングを構成する
Google Cloud プロジェクト ファクトリ Terraform モジュールは、Google Cloud プロジェクトの作成を自動化する際に役立ちます。大企業では、Google Cloud でプロジェクトを作成する前に、プロジェクトを確認して承認することをおすすめします。このプロセスにより、次のことを保証できます。
- 費用を関連付ける。詳細については、費用最適化のカテゴリをご覧ください。
- データ アップロードの承認を行う。
- 規制やコンプライアンスの要件を満たす。
Google Cloud プロジェクトとリソースの作成や管理を自動化すると、整合性、再現性、テスト容易性の面でメリットを得られます。コードとして構成を扱うことで、ソフトウェア アーティファクトと一緒にバージョニングして、構成のライフサイクルを管理できます。自動化により、リソースに一貫した命名規則やラベル付けを行うなど、ベスト プラクティスに対応できます。自動化により、要件の変化に合わせて、プロジェクトのリファクタリングを容易に行うことができます。
システムを定期的に監査する
新しいプロジェクトに対するリクエストが監査、承認されるようにするには、企業のチケット システムや監査を提供するスタンドアロン システムを統合します。
一貫性を保ってプロジェクトを構成する
プロジェクトは、組織のニーズが一貫して満たされるように構成します。プロジェクトを設定するときは、次のものを含めます。
- プロジェクト ID と命名規則
- 請求先アカウントのリンク
- ネットワーク構成
- 有効な API とサービス
- Compute Engine のアクセス構成
- ログのエクスポートと使用状況レポート
- プロジェクト削除リーエン
ワークロードや環境を切り離す
割り当てと上限は、プロジェクト レベルで適用されます。割り当てと上限を管理するには、ワークロードや環境をプロジェクト レベルで切り離します。詳細については、割り当ての操作をご覧ください。
環境の分離は、データ分類の要件とは異なります。データをインフラストラクチャから分けることは、実装が高コストで複雑になるため、データの機密性とコンプライアンス要件に基づいてデータの分類を実装することをおすすめします。
課金の分離を適用する
課金の分離を適用して、異なる請求先アカウントに対応し、ワークロードや環境ごとの費用の可視性をサポートします。詳細については、セルフサービス Cloud 請求先アカウントの作成、変更、閉鎖とプロジェクトの課金の有効化、無効化、変更をご覧ください。
管理の複雑さを最小限に抑えるため、プロジェクト レベルの重要な環境や、複数のプロジェクトにまたがるワークロードに対して、詳細なアクセス管理を行います。重要な本番環境のアプリケーションにアクセス制御を作成すると、ワークロードを保護して安全に管理できます。
組織のポリシー サービスを使用してリソースを制御する
組織ポリシー サービスでは、ポリシー管理者に組織のクラウド リソースの一元管理と、プログラムによる制御権が与えられます。これにより、リソース階層全体にわたる制約を構成できます。詳細については、組織のポリシー管理者の追加をご覧ください。
組織のポリシーを使用して規制ポリシーを遵守する
コンプライアンス要件を満たすには、組織ポリシー サービスを使用して、リソースの共有とアクセスにコンプライアンス要件を適用します。たとえば、外部関係者との共有を制限したり、クラウド リソースを地理的にデプロイする場所を決定します。その他のコンプライアンス シナリオとしては次のものがあります。
- 制御の集中化により、組織のリソースの使用方法を定義する制限を構成する。
- 開発チームがコンプライアンスを遵守できるようにポリシーを定義して確立する。
- 規制遵守を維持し、さらにコンプライアンス ルール違反の懸念を最小限に抑えながら、プロジェクト オーナーとチームがシステムを変更できるように支援する。
ドメインに基づいてリソースの共有を制限する
共有に関する制限された組織のポリシーを使用すると、Google Cloud リソースが組織外の ID と共有されるのを防ぐことができます。詳細については、ドメイン別の ID の制限と、組織のポリシーの制約をご覧ください。
サービス アカウントとキーの作成を無効にする
セキュリティを強化するには、Identity and Access Management（IAM）のサービス アカウントと対応するキーの使用を制限します。詳細については、サービス アカウントの使用を制限するをご覧ください。
新しいリソースの物理的な場所を制限する
リソース ロケーションを制限して、新しく作成されたリソースの物理的なロケーションを制限します。組織のリソースを制御するための制約のリストについては、組織のポリシーのサービスの制約をご覧ください。
次のステップ
コンピューティングを選択して管理する方法を確認する。次のものを確認します。
アーキテクチャ フレームワークの他のカテゴリ（信頼性、オペレーショナル エクセレンス、セキュリティ、プライバシー、コンプライアンスなど）を確認する。