project
gcp
Quad incDay 13

GCP Project のベストプラクティス

Google Cloud Platform(GCP) について

AWSやAzureに並ぶ、Googleが提供するクラウド基盤(PaaSやIaaS)です。
AWSの方が微に入り細に入っている感はまだ否めませんが、今後伸びることが想定されます。
基本的なコンピューティングサービスやコンテナサービス、機械学習といったトレンドに従ったものはありますし、他のクラウドサービスと比較して安価になりやすい事が利点です。

Projectとは

GCPでは、プロジェクトと呼ばれる単位で課金アカウントを紐付け、その下でサービスを実行します。
これにより、各プロジェクトでのコストを明確に管理できるという事になりますし、各プロジェクトで環境を明確に分ける事ができます。

ですが、
「どのような単位でプロジェクトを切り分ければいいのか?」
「相互に連携する機能を開発したいけど、同じネットワークに属している必要があるからプロジェクト一緒にしなきゃいけないの?」
といった疑問が浮かぶのではないでしょうか。

本稿では、プロジェクトを分ける指針を「GCP Project のベストプラクティス」と銘打って述べたいと思います。

Projectはサービス単位で分けるべし!

サービス(機能)毎に分けた場合のベストプラクティス

プロジェクトは、各社各人でいろいろな単位で分かれていると思います。
例えば機能毎・顧客毎・チーム/部署毎といった形で、一番使い良い形で分けているのではないでしょうか。
GCPのプロジェクトは、その単位で分けても大丈夫なようにできています。
例えばチーム毎に作成し、VPCを顧客毎に分けて作成し、その中にSubnetを機能毎に作成するといったことが可能です。

ですが、

  • ホストプロジェクトを利用する事で、環境毎の統制を行える
    • 他プロジェクトからの参照可能なリソース、特定のプロジェクト専用のリソースを柔軟に構築できる
  • プロジェクト間のトラフィックに対する課金は、プロジェクト内での課金と同一(コストデメリット無し)
  • ホストプロジェクトのリソースは、別のホストプロジェクトからも利用可能

という点から、組織や環境毎にホストプロジェクトを作成し、ある程度のサービス毎に(例えば、ECサイトとコーポレートサイトを別サービスとして)分ける方が理にかなっています。

例えば、本番環境、検証環境、開発環境としてホストプロジェクトを作成し、そこに各サービスごとにプロジェクトを作成します。

こうすることで、本番環境と開発環境を分けて影響を排除しつつ、各サービス間での通信を担保することができます。

参考URL

プロジェクトの作成と課金管理
共有 VPC の概要