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

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

c-taquna.hatenablog.com

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

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

図

説明に使用する図を先にのせます。

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

• 【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】リージョン(Region)、アベイラビリティドメイン(AD、可用性ドメイン)
• 【GCP】リージョン、ゾーン(zone)

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

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

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

docs.oracle.com

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

cloud.google.com

フォルトドメイン（おまけ）

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

docs.oracle.com

まとめ

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