Google Cloud エンジニアのための Oracle Cloud Infrastructure(OCI)入門

2025年2月20日掲載

【Looker x GenAI】Looker と生成 AI で実現するパーソナライズドマーケティング:カスタム Action で顧客体験を向上

Google Cloud(以下、GCP)を6年間担当してきた私が Oracle Cloud Infrastructure(OCI)に初めて触れたとき、まず戸惑ったのは、クラウド基盤に対する設計思想や用語の違いでした。

本記事では、GCP との対比を交えながら OCI の基本的な概念を整理します。
これから OCI に触れる方の参考になれば嬉しいです。

目次

ロケーションの考え方:リージョンと可用性ドメイン(AD)

GCP ではリージョン・ゾーン(例: asia-northeast1-a)という構成がおなじみですが、OCI ではゾーンに相当する単位を可用性ドメイン(Availability Domain / AD)と呼びます。

リージョンは地理的な領域を指し、その中に1つ以上のデータセンター群である「可用性ドメイン」が存在します。OCI の特徴的な仕様として、アカウント開設時に「ホーム・リージョン」を選択します。初期状態ではホーム・リージョンのみが有効化されており、他のリージョンを利用するには明示的にサブスクライブ(有効化)する必要があります。

さらに、各可用性ドメイン内には3つのフォルト・ドメイン(FD)が含まれています。これはドメイン内のハードウェア群を論理的に分割したもので、ユーザーが明示的に指定できる点が特徴です。1つの FD で障害やメンテナンスが発生しても他の FD には影響しないため、単一の可用性ドメイン内でもある程度の可用性を確保できる設計になっています。

階層

GCP

OCI

広域拠点

リージョン

リージョン

データセンター単位

ゾーン

可用性ドメイン(AD)

物理故障の境界

-

フォルト・ドメイン(FD)

OCI の可用性ドメインは GCP のゾーンに近い概念ですが、サービスによっては AD を意識せずに構成できるものも多く、設計上の粒度は若干異なります。

 

アカウントと組織構造

GCP では「Organization > Folder > Project」という階層構造が基本であり、リソース管理や請求の単位として Project が非常に重要な役割を果たします。

一方、OCI ではアカウントを開設時にテナンシと呼ばれる環境が払い出され、その直下に ルート・コンパートメント が作成されます。
OCIにはGCPのプロジェクトに直結する概念がなく、代わりにコンパートメントを用いてリソースを論理的に分離します。コンパートメントは、開発や本番といった環境ごと(dev / stg / prod) 、あるいは組織・チームごと(team-a / team-b) に作成し、必要に応じて入れ子構造にすることも可能です。

注意点として、OCIのリソースは必ずどこか一つのコンパートメントに属さなければならず、複数のコンパートメントにまたがって所属することはできません。
また、CP ではプロジェクトごとに請求先アカウントを紐付けられますが、OCI ではテナンシ単位で請求が合算されます(コスト分析自体はコンパートメント単位で可能です)。
※OCI には組織(Organizations)という機能があり、複数のテナンシを統合して一括請求(親テナンシに集約)することも可能です。

 

階層

GCP

OCI

最上位

Organization

Tenancy(テナンシ)

リソース管理単位

Folder / Project

Compartment(コンパートメント)

 

アクセス制御:IdentityとIAM の違い

GCP では「メンバー」「ロール」「リソース」からなる Binding によって権限を付与しますが、OCIでは「グループ」「ポリシー文」「コンパートメント」を組み合わせて制御します
OCIのポリシーは自然文に近い形式で記述するのが特徴です。

例:Allow group Devs to manage instances in compartment Test
  (Devs グループに、Test コンパートメント内のインスタンス管理権限を許可する)

このように、「誰が(グループ)」「何を(アクション)」「どこで(リソース)」を文章として定義します。
※OCI では、原則としてユーザーに直接権限を付与せず、グループ経由で付与します。ポリシーでは any-user を指定して権限を付与することも技術的には可能ですが、これは テナンシ内のすべてのユーザーに権限を許可することになるため、通常は非推奨とされています。

また、GCP のサービスアカウントに近い概念として、OCI には動的グループ(Dynamic Group)があります。これはユーザーではなく、「特定のタグを持つインスタンス」などの条件に基づいて権限を付与する仕組みです。

GCP では、Cloud Functions や Cloud Run にサービスアカウントを紐づけて権限管理を行いますよね。
OCI で Function に「Object Storage の読み書き権限」を与える場合は、

1.条件に一致する Function を含む動的グループを定義
2.その動的グループに対してポリシーを割り当て

という流れになります。
OCI では、GCP とは異なりユーザーに直接割り当ては行わず、「グループ」ベースで権限を付与する点が特徴的だと思いました。

 

比較項目

GCP

OCI

IAMの適用単位

リソース単位(Binding)

原則コンパートメント単位(Policy)

記述形式

Binding構造

Policy文(宣言型)

付与対象

メンバー(個人/SA)またはグループ単位

グループ単位

さいごに

OCI は GCP とは異なるアーキテクチャ思想に基づいて設計されており、特に IAM、構成管理、用語体系の違いを意識することが重要だと感じました。

本記事が、OCIを学び始めるGCPエンジニアの皆様の一助となれば幸いです。

最後までお読みいただき、ありがとうございました!

 

関連サービス

あらゆるワークロードに対応する完全なインフラストラクチャサービスとプラットフォームサービスです。ミッションクリティカルシステムにおけるクラウド運用を加速するサービスを継続的に提供します。

MSP(Managed Service Provider)サービスは、お客さまのパブリッククラウドの導入から運用までをトータルでご提供するマネージドサービスです。

おすすめの記事

条件に該当するページがございません