【GCP】【OCI】クラウド・リソース管理スコープについて

下記記事でまとめている、GCP・OCIにおいて、作成したクラウドリソースがどういったスコープで管理されているのかについて説明します。

c-taquna.hatenablog.com

プロジェクト(汎用的な意味での)

ここでいうプロジェクトは、業務で使用する”案件"という意味で使用しています。

説明に使用する図を先にのせます。
f:id:c_taquna:20190715005335p:plain:w400

登場人物として、下記3つがあげられます。

  • 【OCI】Tenancy, Compartment
  • GCP】Project

そして、私の理解では、上記が各プラットフォームで対になるものだと理解しております。

たとえば、GCPだとログインしたあとにProjectを作成します。課金やAPI有効化、すべてのGCPのサービスの使用はProjectに紐付いています。つまり、Projectを変えれば、課金の額も変わりますし、使用するAPIは再度有効化する必要もあります。作成したStorageなどのリソースは別のプロジェクトでは表示されません

cloud.google.com

一方、OCIで上記に該当するのはTenancyです。このTenancyはOracleとの契約に対して一つ紐付けられます。自分のアカウント作るとTenancyが一つ作成できます。

docs.oracle.com

OCIではこのTenancyに対して課金がされます。ここでGCPと違うのは、GCPのProjectと異なりTenancyは容易に変えることができないことです。作成したリソースはすべてTenancy内にできます。そうなると、Tenancyに属するユーザーすべてが作成したリソースを操作できてしまうのではないか、、リソース単位にアクセス制御しなければならないのか、と考えると思います。

もちろんそうはなりません。Tenancyに作成されたリソースを論理的にパーティショニングする機能がCompartmentになります。作成したリソースは、必ず一つのCompartmentに所属する必要があります。そして、各ユーザのCompartmentに対するアクセス制御をすることでGCPのProjectの機能と同じ様な状態に持っていくことができます。

このサイトにある図も参考になります。
cosol.jp

ロケーション(リージョンなど)

次に、ロケーションについて説明します。ここで出てくる登場人物は下記です。

リージョン、アベイラビリティドメイン、ゾーン

リージョンの考え方は同じです。リソースを実行できる特定の地理的な場所です(例:東京リージョン)。その下に、OCIならAD、GCPならzoneという考え方があります

ADはリージョン内にある1つ以上のデータセンターです。ユーザは1リージョンに対して3つのADを使用することができます(2019_7現在、東京リージョンはまだADが1しかないけど。東京データセンターしかないので)。AD同士は物理的に分離されているので、AD1で発生した障害がAD2のリソースに影響を及ぼすことはありません。

docs.oracle.com

GCPにおいて、このADに該当するのが、zoneです。下記ドキュメントにもありますが、”ゾーンが相互に依存しない設計を採用しています。”とあるように、物理的にもzone同士は分離されています。

cloud.google.com

フォルトドメイン(おまけ)

OCIにはフォルトドメインという機能があります。これは、障害耐性を高めるため、AD内でさらに物理的にリソースを分割配置したものです。ADはデータセンター単位でしたが、フォルトドメインラック単位となります。つまり、データセンター内のどのラックにリソースを配置するか選択することで、よりSPOFとなる箇所を少しでも減らしています。

docs.oracle.com

まとめ

GCPでは、リソース管理のスコープや課金管理はProjectという単位で行われている。OCIでは、一番大きなくくりがTenancyで課金管理はこの単位でされる。リソース管理はCompartmentによって実施される。