はじめに
OCIにはコンパートメントと呼ばれるコンポーネントがあります。
これはAWS、Azure、Google Cloudなど他のクラウドにはないコンポーネントで、OCIの利用には切り離せないものとなっております。
既にいくつかコンパートメントについてまとめられた記事がありますが、自身の勉強と備忘録のために改めてまとめてみようと思います。下記記事も参考にさせてきただきました！
コンパートメントってなんなんだ?
ここからは早速本題に入っていきたいと思います。
いろいろドキュメントを漁ってみるとそれっぽい文章を見つけることができました。
コンパートメントは、クラウド・リソースの編成に使用する主要なビルディング・ブロックです。コンパートメントを使用してリソースを編成および分離すると、管理とアクセス保護が容易になります。
うーん、それっぽい感じで記載されていますが、(個人的には)実際何ができて何がうれしいのかなどわかりそうでわからない...
個人的にはリソースの分離とそれに伴う、権限統制などができるよって意味合いで"テナントとは別の概念で論理的に区分けされた箱"という理解をしているのですが、ここからは図も使って説明していきたいと思います。
コンパートメントとテナンシの関係について
まず最初にテナンシ(=アカウント)とコンパートメントの関係図 / イメージ図が以下になります。
前提としてテナンシの作成と同時にroot-compartmentと呼ばれるデフォルトのコンパートメントが作成されます。
絵で記載した通り、上位コンパートメントからネストさせるようなイメージで最大6階層までコンパートメントを作成することが可能です。
こういう絵を描くと、コンパートメントが"テナントとは別の概念で論理的に区分けされた箱"のようなイメージを持ちやすいかなと思います。
想定されるユースケースとしてはプロジェクト、システム、部署などでコンパートメントを分けることが考えられます。
極論、root-compartmentの1つだけで運用しても問題はないのですが、適切なリソース分離と権限管理などを運用すると考えたときにコンパートメントがあると便利になります。
コンパートメントと権限統制/リソース分離について
コンパートメントで一番強調される特徴が個人的にはリソース分離と権限統制です。
上記絵で記載したようにプロジェクトや部署毎にOCIを運用する場合、いくら社内の人間でも別プロジェクトのリソースにアクセスできる状態は望ましくありません。
そういった際にコンパートメントを分離することでリソースの分離ができたり、アクセス権限を適切にコントロールすることが可能です。
権限統制について
コンパートメントにおける権限統制のイメージとしては以下のようになります。
細かいルールは他にもあるでしょうが
- 上位ユーザは下位コンパートメントへのアクセス権を有する
- 同階層コンパートメントへのアクセスは権限が必要
- 上位階層へのコンパートメントはアクセス不可
なのでプロジェクト毎に管理者ユーザを作成し、さらにコンパートメントをネストし、事細かに権限統制を図ることが可能です。
そこまでに細かくやるか?という気持ちもありますが、各システムやプロジェクト毎に本番用と検証/開発用のユーザを作り分けたりすることで人的作業ミスなどは減らせるかなと思います。
実際の権限設定はポリシーと呼ばれるサービスで制御はするのですが、コンパートメントは権限統制の機能を持つ概念のため、セキュリティ機能に含まれると個人的には理解しています。
リソース分離について
次にリソース分離についてです。
VCNやComputeやBlock Storageといったリソースはすべてコンパートメントの中に作成します。
個人的にはここがややこしいのですが、コンパートメントはリージョンに関係なく存在できるグローバルリソースのため、同じコンポーネントでもリージョンを跨いでリソース配置することもできます。
下記は「テナンシ / リージョン / Availability Domain / Fault Domain / コンパートメント/ VCN / Subnet / 各種リソース」を絵に起こしたものとなります。
リソースは必ずコンパートメントを指定して配置するということがポイントなります。
その上でどのリージョンのどのVCN、サブネット上にリソースを作成するか決定する必要があります。
例えば、「PROJECT-A-compartmentに対して東京リージョンのVCNのSubnetAに対して、FD1でComputeを作成する」などです。
これらの絵で少しでもコンパートメントのイメージを持ってもらえれば幸いです。
注意
適切な権限やアクセス許可さえ付与していればコンパートメント間での通信は可能です。
今回はコンパートメントの特徴の一つして "リソースの分離もできる" 点に着目して記載しているので誤解がなきよう記載しておきます
(もう少しイケている絵にしたかったのですが、これが限界...)
コンパートメントとユーザ管理の分割について
さきほど、コンパートメント毎にリソース分離と権限統制が可能とお伝えしましたが、ユーザ管理もコンパートメント毎に可能です。
ユーザ管理自体は"アイデンティティ・ドメイン"と呼ばれるサービスで管理をするのですが、この「アイデンティティ・ドメインはコンパートメント内に作成されるリソース」のためコンパートメント単位でユーザ管理をすることも可能になる、という寸法です。
コンパートメントとコスト管理について
コンパートメント自体は無償のサービスとなります。いくら作成しても費用はゼロ円です。
コンパートメントを利用するとコスト管理も容易になります。
具体的には"コスト分析"サービスのフィルタリングの中でコンパートメント別にすることが可能なので
「どのコンパートメントでどのリソースをいくら使っているか」というのが一目で管理できます。
注意点としてはテナンシ(=アカウント)自体は1つなので、請求書も1枚で送付されます。
例えばAWSやAzureでアカウントを複数存在していて、各アカウント管理者が請求書を処理する必要があるという業務フローだと、逆に請求書が1枚にまとまっていると内部的な処理が煩雑になるかもしれませんね。
その時はコンパートメントではなく、OCIでもテナンシを分ければいいだけなのでOCIは取り得る選択肢が多いってくらいの認識を持つのが良さそうです。
コンパートメントとリソース割当て制限について
コスト管理と密接しますが、OCIに限らずパブリッククラウドで注意しないといけないのは不要なリソースの作成、それに伴うコスト増です。
前提としてOCIにはデフォルトでサービス制限(=https://docs.oracle.com/ja-jp/iaas/Content/General/Concepts/servicelimits.htm)と呼ばれる「利用者が特定のリソースやサービスに対して設定された上限数を超えないようにする機能」を持っています。
このサービス制限を、より細かく制限を設けたい際にコンパートメント毎に"リソース割当て制限"機能を利用して設定可能です。
例えばですが、以下のような制限を設けることが可能です
プロジェクトA-コンパートメント：Computeを5CPU / 40GBメモリまでしか使えない
プロジェクトB-コンパートメント：Computeを20CPU / 80GBメモリまでしか使えない
この機能を利用することで各コンパートメントで必要以上のリソースを作成させないようなガバナンスを効かせた運用が可能です。
まとめ
ざっくりコンパートメントができる機能について箇条書きしました。
- 1つテナンシの中で適切なリソース分離 / 権限管理を実現可能
- 1つテナンシの中でユーザ管理の分割が可能
- コンパートメント毎に利用料を算出可能
- 各コンパートメントに対してリソース制限を設けることが可能
最後に
今回あらためてコンパートメントについてまとめました。
自己学習というか振り返り程度の備忘録となりますが、OCIをはじめたばかりの方などの一助になればと思います。