組織を GCP のリソース階層にマッピングする
Google Cloud Japan Team
クラウドの利用が増えてくると、次のような質問に答えることが難しくなってきます。
- どうすればリソースをうまく整理できるのか
- 部署、チーム、環境、アプリケーションをどうやって切り分ければよいのか
- 一元管理を維持しつつ管理責任を委任するにはどうすればよいのか
- 請求やコストの配分をどう管理すればよいのか
なかでも、GCP のリソース階層においてルート ノードとなる組織リソースは、GCP のリソース全体にわたって一元的な可視性と制御機能を提供します。
私たち Google はこのほど、こうした組織リソースの下に位置する新たなレイヤとして、Folder(フォルダ)をベータ リリースしました。フォルダを使用すれば、組織構造に合わせて GCP のリソースをより柔軟に調整できるようになります。
GCP での事業が拡大するにつれて、私たちはプロジェクトを合理化する方法を模索し始めました。Cloud Resource Manager のおかげで、今ではどのようにリソースが作成され、自社ドメイン内でどのように請求すべきかを一元的に管理、監視することができます。IAM とフォルダを使うことで、リソースへのアクセスや使用量に対する可視性を損なうことなく、各部署は必要に応じて自主性と俊敏性を確保しています。これにより、管理負荷が大幅に低減され、ユーザーを大規模にサポートする能力に直接的な良い影響をもたらしました。
Ocado Technology のシニア ソフトウェア エンジニア、Marcin Kolda 氏
Google Cloud のリソース階層
GCP のリソース階層は、組織、プロジェクト、そして新たにベータ リリースされたフォルダで構成されています。この階層は、従来の OS のファイルシステムのようなものだと考えてください。
階層には所有権があり、各 GCP リソースに 1 つずつ親が割り当てられ、その親がリソースのライフサイクルを管理します。グループ化も可能で、リソースをプロジェクトやフォルダにまとめることもできます。プロジェクトやフォルダは、サービスやアプリケーション、もしくは組織内の部署やチームといった組織エンティティを論理的に表しています。さらに、階層はアクセス管理や設定ポリシーの「足場」も提供し、どのノードにも付随して階層の下まで伝播することができ、それによって管理の簡素化とセキュリティの改善が見込めます。
以下の図は、GCP のリソース階層の一例です。
プロジェクトは、所有権、グループ化、ポリシー付随ポイントなどの最初のレベルとなります。一方、組織には企業が持つすべてのリソースが含まれており、一元的な可視化や管理に向けたハイレベルな領域が提供されます。組織レベルで定義されたポリシーは、階層内の全リソースに継承されます。その中間にあるフォルダにはプロジェクトや他のフォルダが含まれ、分離要件の境界線の整理や作成に柔軟に対応できます。
たとえば、企業の組織管理者であれば、最初のレベルのフォルダを組織の下に作成し、エンジニア部門、IT部門、オペレーション部門、マーケティング部門などをマッピングします。そして、担当部門のリーダーにフォルダ管理者 IAM の役割を与えれば、各フォルダの管理を完全に委任できます。
各部門では、チームやアプリケーションなどのサブフォルダを作成することで、部門内のリソースを整理できます。組織レベルで集中的に組織全体のポリシーを定義することも可能で、そのポリシーは組織内の全リソースに継承され、一元的な可視化と管理を実現します。同様に、フォルダ レベルで定義されたポリシーはその階層下に適用され、チームや部署の自律性を適切に保つことができます。
GCP に組織をマッピングする際の考慮ポイント
組織ごとに構造や企業文化、業務のスピード、自律性の要件は異なります。すべてのケースに当てはまる、事前に定義された方法はないのですが、GCP のリソースを整理する際に考慮すべき基準をいくつか紹介します。
分離 : 信頼の境界線はどこに設定するべきなのでしょうか。部署やチームごとなのか、アプリケーションやサービスごとなのか、または稼働環境、テスト環境、開発環境といった環境ごとなのでしょうか。ネストされた階層とプロジェクトでフォルダを使用することで、クラウド リソースを分離しましょう。誰がどのリソースにアクセスできるかを決める IAM ポリシーは、さまざまな階層レベルで設定しましょう。
委任 : 自律性と一元管理のバランスはどのように保てばよいのでしょうか。フォルダと IAM により、開発者が自由にビルドやテストが行えるように区画を設け、より厳しい管理が必要なエリアをよけておくことができます。たとえば、開発フォルダを作成することで、ユーザーがそこでプロジェクトを作成したり、仮想マシン(VM)を動かしたり、サービスを稼働させたりすることができるのです。また、IAM によって最小の権限しか与えられていない専用のプロジェクトやフォルダにプロダクション ワークフローを集約し、保護することも可能です。
継承 : 継承によってポリシー管理をどのように最適化できるのでしょうか。上述したように、ポリシーは階層の各ノードにて定義可能で、そのポリシーは子ノードに継承できます。もっとも、IAM のポリシーは追加的なものであり、たとえば、bob@myorganization.com さんが、あるフォルダ内で Compute Engine のインスタンス管理者の役割を与えられた場合、この人はそのフォルダ内で各プロジェクトの VM を起動させることが可能です。
共有リソース : ネットワークや VM イメージ、サービス アカウントなど、組織内で共有すべきリソースがある場合は、プロジェクトやフォルダを使って共有リソース用の中央リポジトリを構築し、そのリソースに対する管理権限を特定のユーザーのみに制限することが可能です。他のユーザーへのアクセス許可については、最小権限の原則を適用しましょう。
GCP リソース階層を管理する
フォルダのベータ リリースに合わせて、Google Cloud Console のユーザー インターフェース(UI)も再設計され、リソース階層の可視性や管理性が改善されました。新しいスコープ ピッカーや、以下に示す Manage Resources により、階層のブラウズ、リソース管理および IAM ポリシーの定義などが簡素化されています。
上の例では、myorganization.com という組織は Engineering と IT の 2 つのトップレベルのフォルダで構成されています。Engineering には Product_A および Product_B という 2 つのサブフォルダがあり、それぞれに Production、Development、Test といったフォルダが含まれています。設定したいリソースを選んで右側の管理領域にアクセスすれば、以下のように同じ UI 内で IAM を設定できます。
IAM の権限を使用すれば、組織管理者はユーザーに対してツリー内の一部を表示しないように制限でき、部署や製品、環境ごとに分離して信頼の境界線を設けることが可能です。
たとえば、Product_A の本番環境におけるセキュリティを最大限に高めたい場合は、そのフォルダに対して一部のユーザーにのみアクセス権やブラウズを許可することができます。bob@myorganization.com さんが Product_A の新機能を開発中のときは、本番環境でミスが起きるリスクを最小限に抑えるため、本番環境のフォルダを非表示にすることも可能です。
以下の画像は、bob@myorganization.com さんの組織リソース内でのブラウズ画面を示しています。
他の GCP コンポーネントと同様に、私たちは UI と共に API およびコマンドライン(gcloud)インターフェースを提供することでリソース階層全体をプログラムで管理できるようにしており、ポリシーおよび環境の自動化や標準化を実現しています。
以下のスクリプトは、gcloud コマンドライン ツールを使用して、上記のリソース階層をプログラム上で作成します。
以上のように、Cloud Resource Manager は組織内の GCP リソースを管理し整理するための強力なツールです。詳細はクイックスタートをご覧ください。今後数か月の間に新しい機能も追加する予定です。お楽しみに。
* この投稿は米国時間 5 月 11 日、Product Manager である Marco Cavalli によって投稿されたもの(投稿はこちら)の抄訳です。
- By Marco Cavalli, Product Manager