Google Cloudのリソース階層

Google Cloudのリソース階層は、組織を起点として始まります。組織はルートノードとして機能し、特定の状況によって他の形態が求められない限り、1つのルートノードを持つことが望ましいです。フォルダとプロジェクトは階層の下位レベルを定義するために使用され、ネストされたフォルダの作成によって望ましい構造を構築することができます。ワークロードをホストするプロジェクトは、階層内の任意のレベルで作成することができます。

Decide a resource hierarchy for your Google Cloud landing zone

アプリケーション環境に基づく階層

多くの組織では、開発、本番、テストなど、異なるアプリケーション環境に対して独自のポリシーやアクセス制御が確立されています。アプリケーション環境に基づく階層を採用することで、各環境に対して標準化されたポリシーを適用することで、管理と設定を簡素化することができます。例えば、本番環境はテスト環境と比べて厳格なセキュリティポリシーを持つ場合があります。

次の条件が満たされている場合、アプリケーション環境に基づく階層を利用してください。

• 独自のアプリケーション環境があり、それぞれ独自のポリシーや管理要件がある場合
• 高度にカスタマイズされたセキュリティや監査要件が必要なユースケースがある場合
• 異なるアイデンティティとアクセス管理（IAM）の役割が、異なる環境でGoogle Cloudのリソースにアクセスするために必要な場合

次の条件が該当する場合は、この階層を避けてください。

• 複数のアプリケーション環境を運用していない場合
• 異なる環境間でのアプリケーションの依存関係やビジネスプロセスの変動がない場合
• リージョン、チーム、アプリケーション間に重要なポリシーの違いがある場合

次の図は、架空の金融テクノロジー企業であるexample.comの階層の例を示しています。

Decide a resource hierarchy for your Google Cloud landing zone

上記の図に示されているように、example.comは3つの異なるアプリケーション環境を維持しており、それぞれ異なるポリシー、アクセス制御、規制要件、プロセスを持っています。これらの環境は次のとおりです。

• 開発およびQA環境: 内部の従業員やコンサルタントによって管理される環境で、継続的なコードデプロイと品質保証が行われます。ビジネスの顧客がアクセスすることはありません。統合と認証の要件は本番環境よりも緩やかであり、開発者には適切な権限を持つ役割が割り当てられます。開発およびQA環境は、example.comの標準的なアプリケーション提供に専用されています。
• テスト環境: リグレッションテストやアプリケーションテストに専用されており、example.comのB2Bのオファリングに対して同社のAPIを利用するクライアントをサポートしています。example.comはこの目的のために2つのプロジェクトタイプを作成します:
  • B2Bのオファリングに関連する内部リグレッション、パフォーマンス、および設定に対する内部テストプロジェクト。
  • ユーザーエクスペリエンス、ブランディング、ワークフロー、レポートなどのexample.comの要件と一致するように、B2Bのクライアントが自分の設定を検証し、調整することができるマルチテナントのクライアントUATプロジェクト。
• 本番環境: 検証され、受け入れられ、ローンチされた製品オファリングをホストする環境です。Payment Card Industry Data Security Standard（PCI DSS）の規制に準拠し、ハードウェアセキュリティモジュール（HSM）を利用し、認証や支払い処理のためにサードパーティのプロセッサと統合します。監査とコンプライアンスのチームがこの環境で重要な役割を果たし、自動化された展開プロセスを通じて厳密に制御されたアクセスを提供します。

リージョンまたは子会社に基づく階層

一部の組織は複数のリージョンで事業を展開しているか、合併や買収により異なる地理的な場所で事業を行っている子会社を持っています。これらの組織では、Google Cloudの拡張性と管理オプションを活用しながら、異なるプロセスとポリシーを持つリージョンまたは子会社の自治性を維持するために、リソース階層が必要です。この階層では、子会社またはリージョンが最上位のフォルダとして機能します。展開手順は通常、特定のリージョンに焦点を当てて行われます。

次の条件が該当する場合は、リージョンまたは子会社に基づく階層を選択してください:

• リージョンまたは子会社が独立して運営されている場合
• リージョンまたは子会社が異なる運用バックボーン、デジタルプラットフォームオファリング、およびプロセスを持っている場合
• リージョンまたは子会社に対して異なる規制およびコンプライアンスの基準を遵守している場合

次の図は、リージョンによって構成される2つの子会社とホールディンググループを持つグローバル組織の階層の例を示しています。

Decide a resource hierarchy for your Google Cloud landing zone

上記の図では、次の階層構造が示されています。

• 第1レベルには、会社の2つの子会社を表す「Subsidiary 1」と「Subsidiary 2」のフォルダがあります。これらのフォルダは、組織の他の部分とは異なるアクセス権限とポリシーを持っています。各子会社はIAMを利用して、自身のプロジェクトやGoogle Cloudのリソースへのアクセスを制限しています。
• 「Holding group」フォルダは、リージョン間で共通の上位レベルのポリシーを持つグループを表しています。
• 「Bootstrap」フォルダは、Google Cloudインフラストラクチャを展開するために必要な共通のリソースを表しています。これはセキュリティの基盤設計に記載されています。
• 「Holding group」フォルダ内の第2レベルには、次のフォルダがあります。
  • 「APAC」、「EMEA」、「Americas」の各フォルダは、グループ内の異なるリージョンを表しており、それぞれ独自のガバナンス、アクセス権限、ポリシーを持っています。
  • 「Shared infrastructure」フォルダは、全てのリージョンで共有されるリソースを表しています。
• 各フォルダには、各子会社やリージョンに関連するリソースを担当するさまざまなプロジェクトが含まれています。

組織内の異なる法人、部門、およびチームを区別するために、さらにフォルダを追加することも可能です。

説明責任フレームワークに基づく階層

説明責任フレームワークに基づく階層は、製品が独立して動作し、組織ユニットには製品のライフサイクル全体に説明責任を持つ明確に定義されたチームがあります。これらの組織では、製品所有者がプロセス、サポート、ポリシー、アクセス権限など、製品の全体のライフサイクルに説明責任を持ちます。組織内の製品は多様であり、いくつかの組織全体のガイドラインが存在します。

次の条件が該当する場合、説明責任フレームワークに基づく階層を導入することを検討してください。

• 各製品に対して明確な所有権と説明責任が組織内に存在する場合
• ワークロードが独立しており、共通のポリシーを共有することはほとんどない場合
• プロセスや外部開発者プラットフォームがサービスまたは製品として提供されている場合

次の図は、ECプラットフォームプロバイダーの階層の例を示しています。

Decide a resource hierarchy for your Google Cloud landing zone

上記の図では、次の階層構造が示されています:

• 第1レベルには、「Ecommerce Modules」と「Logistics and Warehousing Modules」という名前のフォルダがあります。これらはプラットフォームオファリング内のモジュールを表し、製品のライフサイクル全体で同じアクセス権限とポリシーが必要です。
• 「Reconciliation and Billing」フォルダは、プラットフォームオファリング内の特定のビジネスコンポーネントのエンドツーエンドモジュールに説明責任を持つ製品チームを表しています。
• 「Bootstrap」フォルダは、Google Cloudインフラストラクチャを展開するために必要な共通のリソースを表しています。これはセキュリティの基盤設計に記載されています。
• 各フォルダには、さまざまな製品チームが管理する独立したモジュールが含まれています。

参考

https://cloud.google.com/architecture/landing-zones/decide-resource-hierarchy