AWSエンジニアから見たOCI

# はじめに
NTTデータの奥村です。  
最近、周囲でOracle Cloud Infrastructure（以降OCI）に関する話をよく聞くようになってきました。AWSエンジニアの皆さんもOCIという名前は聞いたことがあるとは思いますが、「どうやらOracleを制限なく使えるようだぞ」とか「他のハイパースケーラー（AWS、Azure、GCPのような大規模クラウド事業者）より料金が安いらしい」という断片的な情報だけをお持ちのケースが多いのではないでしょうか？（私自身もそうでした）  
そこでAWSエンジニアの目線で見たときに、特に違いがあるなと思われるところをいくつか紹介していきたいと思います。個人的にインパクトが大きいと感じた点を中心に紹介するため、網羅的ではない点をご了承ください。

# OCIとは？
2016年からIaaS/PaaSを中心とした現在のサービス体系でのサービス提供が開始され、2019年5月に東京リージョン、2020年2月に大阪リージョンでの提供が開始されました。
参考：[Oracle Cloud Infrastructureの現在と未来：全てはお客様の変革のために](https://www.oracle.com/jp/news/announcement/blog/now-future-oracle-cloud-infrastructure-2023-04-07/)
AWSやAzureといったハイパースケーラーより数年遅れてサービス提供が開始されたため、市場シェアはまだ大きくありません。しかし、後発であることを生かし、他のハイパースケーラーにはない特徴を持っています。本記事ではそうした特徴のいくつかを紹介していきます。

# OCIのメリット
## コスト
AWSと同様に、OCIにも無償枠があります。非常に多くのサービスに無償枠があるのですが、特にメリットが大きいと感じた点をいくつか紹介します。
+ アウトバウンド通信が1か月あたり10TBまで無料
    + 大規模なシステムの場合、アウトバウンドのデータ通信料がクラウド利用料の多くを占めるケースがあり、10TBまで無料である点は、非常に大きなメリットです
+ Functionsの呼び出しが1か月あたり200万件以下かつ40万GB・秒以下まで無料
    + かなり大きな無料枠であるため、多くのケースでFunctionsは費用をかけずに利用できるでしょう
+ Network Load Balancerが無料
    + それほど利用シーンは多くないかもしれませんが、L4レベルでのロードバランサーが無料で利用できるため、ネットワーク関連の費用を抑えられるケースが出てくるでしょう
+ サービスゲートウェイが無料
    + AWSでいうVPCエンドポイント相当の各サービスへのプライベート接続機能が無料となっています。OCIのサービスゲートウェイは、AWSのゲートウェイ型のVPCエンドポイントに近い機能となっていますが、AWSのゲートウェイ型VPCエンドポイントと違い、多くのサービスをサポートしています。プライベート接続の要件は金融系をはじめとして、多くのエンタープライズで求められるため、接続先のサービスが増えてくるとコストへの影響も大きいため、無料であることは大きな利点です

参考：[OCI価格リスト](https://www.oracle.com/jp/cloud/price-list/)
※執筆時点での情報に基づきます。

## コンパートメント
OCIではコンパートメントと呼ばれるOCIリソースをまとめて管理する機能が用意されています。コンパートメントが階層構造（ネスト）を持つことが可能で、上位のコンパートメントに付与されたIAMポリシーが継承されるという特徴も持っています。これにより、複数のOCIリソースに対する利用者のアクセス制限を柔軟かつシンプルに実装できます。AWSでは1つのAWSアカウントを利用している場合、あとからシステム単位や部署単位などでアクセス可能な範囲を制限したいケースでは、タグを利用したアクセス制御を行う必要が生じることがあります。この際にはIAMの設定が複雑になり、その維持に相当な負荷のかかるケースが多いです。OCIの場合は、コンパートメント単位でアクセス制御が可能なため、AWSで単一アカウント内でリソースを管理する場合と比較してアクセス管理にかかる運用負荷を下げることが可能です。
![Compartment.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3965348/6aefe309-ccf8-4ec9-9289-ee8dd9ee99f5.jpeg)


## IAM
この点については評価が分かれるかもしれませんが、OCIではIAMポリシーは下記のようにホワイトリスト型の制御となり、Denyで明示的に操作権限を拒否することはできません。
>Allow group A-Admins to manage all-resources in compartment Project-A

参考：[ポリシー構文](https://docs.oracle.com/ja-jp/iaas/Content/Identity/Concepts/policysyntax.htm#two)

誤って想定以上の権限を付与してしまうことを避けやすい、というメリットがある一方、細かくアクセス制御をしている場合には、新たに使いたいサービスが出てくるたびに権限を付与する必要がある、というデメリットもあります。
OCIでのIAMポリシーの基本的な構文は下記となっており、それぞれの要素は以下の通りです。
>Allow [subject] to [verb] [resource] in [location]

| 要素 | 説明 |
|:-|:-|
| subject  | 操作者が所属するグループまたはプリンシパル |
| verb  | 操作権限 |
| resource  | 操作対象のOCIサービス |
| location  | コンパートメントまたはテナント全体 |

この中でAWSと比べたときに注意したほうがよいと感じる部分は下記となります。
+ subject
    + 権限を付与できる最小単位がグループとなっています。ユーザーに付与することはできないのでご注意ください
+ verb
    + 事前定義済みのinspect（リソースの一覧表示など）、read（inspectに加え、設定値の参照など）、use（readに加え、リソースの起動・停止や更新など）、manage（全ての操作権限）のいずれかを選択可能です。アクションを細かく制限したい場合は、[where句内のrequest.operationを用いて制御](https://docs.oracle.com/ja-jp/iaas/Content/Identity/Concepts/policyadvancedfeatures.htm)します
+ resource
    + サービスレベルでの指定だけではなく、サービスをまとめたfamilyレベルでの指定が可能です。例えばネットワーク関連をまとめたvirtual-network-familyといったものが存在します。AWSと異なり複数のサービスの操作権限をまとめて指定でき、IAMポリシーをシンプルにできるというメリットがあります

## コンピュートのインスタンスタイプ
OCIのインスタンスは、CPUおよびメモリをそれぞれ1vCPU、1GB単位で設定可能なフレキシブル・シェイプと呼ばれるインスタンスタイプが存在します。オンプレミス環境からの移行の場合には、VMwareで割り当てていたvCPUおよびメモリサイズと同一構成でクラウド上のインスタンスを検討されることが多いです。しかし、AWSの場合はすでに決められたインスタンスタイプから選択する必要があり、CPUまたはメモリのどちらかが過剰となるケースもよくあります。完全にオンプレミスと同一のリソース構成でVMインスタンスを作ることで、VM構成に関する検討工数を抑えられるという面でメリットが大きいでしょう。
![flexible_shape.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3965348/5a3cfbb0-4623-42ea-99f7-3d0c70e07d21.jpeg)

## リソース・マネージャ
OCIではAWSと異なり、AWS CloudFormationのような独自のIaCサービスではなく、TerraformによるIaCサービスであるリソース・マネージャが提供されています。これはTerraformの実行環境を提供するだけでなく、Terraformの状態ファイル（tfstate）の管理や、構成ドリフトの検出といった機能も備えたマネージドサービスです。 Terraformに慣れ親しんでいる方であれば、低いハードルでOCIのIaCを実現できるようになっています。
![ResourceManager.jpg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3965348/9510663b-e543-4567-bc92-bf38cf31b386.jpeg)

## データベース
OCIはデータベースサービスに強みを持っていますが、やはりOracle Databaseにて、RAC（Real Application Clusters）構成を組めることが最大の強みです。AWS RDS for Oracleでは、本書執筆時点でRAC構成がサポートされていません。マネージドなデータベースサービスでRAC構成が必要な場合は、OCIのOracle Base Database Serviceなどが有力な選択肢となるでしょう。  
また、Oracle ExadataのフルマネージドサービスであるAutonomous Databaseが提供されているのも非常に大きなポイントです。オンプレミスでExadataを利用しており、大きくアーキテクチャーを変更したくない場合は、まずOCIが有力な選択肢となるでしょう。AWSでもOracle Database@AWSの一部提供が始まり、AWSからOCIのExadataサービスを利用することも可能になりつつありますが、本記事執筆時点では一般提供がされておらず、誰もが利用できる状況にはなっていません。

# OCIの改善が期待される点
## マルチAvailability Domainのリージョンが少ない
AWSのAvailability Zone（AZ）は、OCIではAvailability Domain（AD）に該当します。本記事執筆時点では、複数のADが構成されているリージョンはドイツ中央部(フランクフルト)や米国東部(アッシュバーン)などに限られています。（日本国内のリージョンはいずれも1AD構成です）  
参考：[リージョンおよび可用性ドメイン](https://docs.oracle.com/ja-jp/iaas/Content/General/Concepts/regions.htm)  
AWSをはじめとした他のハイパースケーラーと比較すると、可用性の点で他のハイパースケーラーに見劣りします。OCIには単一AD内でもFault Domainによる障害分離の仕組みがありますが、データセンターレベルの障害に対応するにはマルチAD構成が不可欠です。マルチAZが一般的となっている現在の状況を踏まえ、マルチAD構成リージョンの拡大が期待されます。

## CDNサービスが提供されていない
AWSのAmazon CloudFrontのようなネイティブの汎用CDNサービスは、OCIでは現時点（執筆時点）で提供されていません。OCI環境でCDNを利用する場合、Oracleと戦略的パートナーシップを結んでいるAkamai CDNとの連携や、他のサードパーティCDNサービスを利用することが主な選択肢となります。WebシステムにおいてCDNは重要な要素であるため、ネイティブサービスの提供が期待されます。

## サービスの品質
一見すると、サービスラインナップは一通り揃っているように見えますが、運用において、管理コンソールの安定性や障害時のコミュニケーション速度などに課題が見られる場合があります。これはある程度利用者が増えてくることで改善してくる可能性もあると思いますが、継続的な品質向上が期待されます。

# おわりに
AWSエンジニア目線でOCIのメリットと改善が期待される点を紹介しました。本記事がどなたかのお役に立てば幸いです。

# 仲間募集中です！
NTTデータ クラウド&データセンタ事業部では、以下の職種を募集しています。
1. [プライベートクラウドコンサル/エンジニア](https://www.nttdata.com/global/ja/recruit/uptodata/articles/1268/)
2. [デジタルワークスペース構築／新規ソリューション開発におけるプロジェクトリーダー](https://www.nttdata.com/global/ja/recruit/uptodata/articles/1315/)
3. [IT基盤(パブリッククラウド、プライベートクラウド)エンジニア](https://www.nttdata.com/global/ja/recruit/uptodata/articles/4687/)
4. [パブリッククラウド/プライベートクラウドを用いた大規模プロジェクトをリードするインフラエンジニア](https://www.nttdata.com/global/ja/recruit/uptodata/articles/5104/)

# ソリューション紹介
1. [クラウドプロフェッショナルサービス/クラウドインテグレーションサービス/クラウドマネージドサービス/パートナークラウドサービス](https://dc.jp.nttdata.com/cloud/index/awssolutions.html)
2. [OpenCanvas](https://portal.opencanvas.ne.jp/)