はじめに

私はAWSを利用した開発業務を行っていますが、OCIに魅力を感じて記事を書いたり、社内でセミナーを開催したりしています。改めて、なぜ私がOCIに魅力を感じているのか、自身の整理もかねて一度共有したいと思いこの記事を書かせていただきました。

エッセイみたいなものなので、こんな考えの人もいるんだ..くらいで見て下さい。
＊個人の主観記事です。筆者の所属団体やオラクル社とは全く関係ない個人の思想です。

Why OCI?

結論から先に言うと、OCIはデータ中心のクラウドであり
SoRやSoIの領域で、他のクラウドにはないユニークな価値を提供できると考えたからです。

AWSを選ぶ時
個人の見解にはなりますが、OCIとAWSとは真逆の思想だと考えています。
AWSはユーザが欲しい、実現したいと考えたことを実現する様々なマネジメントサービスが提供され、SoE（System of Engagement)を実現する「人」中心のクラウドと考えています。
何か新しいサービスを試したいといった要件でしたら、私も現時点ではAWSを提案するケースが多いと思います。

OCIを選ぶ時
一方OCIはAWS比較でマネジメントサービスの充実度は劣りますが、DB技術に代表される
大量のデータを正確管理するSoRや、そのデータを活用する分析基盤およびデータエンジニアリングといったSoI領域において強みを発揮する「データ」中心のクラウドと考えています。
基幹システムや分析用途等でデータ集約を考える際は、私は現時点ではOCIを提案するケースが多いとおもいます。

もちろんAWSでもSoR/SoIのサービスは多く存在しますし、逆にOCIでもSoE系のサービスはあります。ここは私が「人」と「データ」どちら中心に見ているかといった主観にすぎません。

ただ、サービスの種類に限らずクラウド戦略としてOCIがデータ中心であり、基幹系に適していると思うポイントがいくつかあります。
以降は、私の考えるOCIの強みを通じて「データ中心」と考える理由をお話しします。

Single Data

最初に最も私が魅力的だと感じたポイントである「Single Data」についてお話しします。これは何度かオラクル社からも出ている言葉であり、データを、1つに集約管理するといった考えです。

私は、この「Single Data」は基幹系システムをクラウドで構築/運用するにあたって直面する
多くの課題に対する、１つの解であると考えています。

これを実現するためのOCIの考えとして「Converged Database」と「Autonomous Database」があるので少しだけご紹介します。

Converged Database

OCIというとAutonomousが真っ先に浮かぶ方多いと思いますが、私はこのConverged Databaseが最も重要なコンセプトであり、Autonomousはこれを実現するための考えであると考えています。

Converged Databaseは「マルチデータフォーマット」「マルチワークロード」を１つのDBサービスで実現する考えであり、OCIで提供されるOracle DBはこの機能を有しています。
では、なぜこれが基幹/分析システムに適しているのでしょうか。

マルチデータフォーマットをマイクロサービスで実現する課題

基幹/分析系システムを考えたとき、複数のデータソースからデータを集め、集約管理することは多々あるかと思います。
ここで「マルチデータフォーマット」が課題となるケースがあります。

例えば、データソースとしてはRDBMSで管理されていた「構造化データ」だけでなく「非構造化データ」も考えらえます。
「XML」や「JSON」だけでなく、「Spatial」や「Graph」等、様々なものが考えられます。
これらを管理するとき、マイクロサービスでは個別でデータに合ったサービスを用意する必要があるかもしれません。
これは分割損になりやすく、管理サービスの増加による運用コスト増にもつながります。

マルチワークロードをマイクロサービスで実現する課題

大規模なシステム基盤でしたら、OLTP/OLAPのマルチワークロードを同一DBに対して実施する必要が出てくるかもしれません。
このような場合、両方のワークロードに対応できるだけスペックをあげるか（スケールアップ）、レプリカ等でDB自体を増やして処理をインスタンス別で分けるか（スケールアウト）といった対応が必要となり、想定外のコストとなる可能性があります。

また、ワークロードによっては別途専用のマイクロサービスを用意しないと実現できないケースもあります。（ML/Block Chain等）
これもマルチデータフォーマット同様に分割損となる可能性があります。

上記理由から、マルチデータフォーマット、マルチワークロードの対応が発生しやすい基盤系システムではマイクロサービスは有効な手段とならないケースは多く、集約管理を想定したOCIが効果を発揮すると考えています。

Autonomous Database

こちらはOCIの代名詞ともなりつつあるサービスですね。
自動でなく、「自律」をコンセプトとして
「Auto Security」「Auto Recovery」「Auto Tuning」と人の手を介さず
自動的に最適な状態を保つOracleの考えた最強のDBみたいなサービスです。

これだけでも素晴らしいのですが、私はAutonomousは上述したConverged Databaseを実現するために必要な機能と考えています。

データを集約しているということはそれだけ、システムとしての重要度は高いです。
マルチワークロードが発生するということはそれだけ性能チューニングは困難です。

つまり、人力では運用しきれないモンスターDBになる可能性が高く
DB運用がConverged Databaseを実現するハードルとなりかねないので、
運用を人を介さず自律的に実施するAutonomous Databaseが必要となると考えています。

Single Dataのまとめ

私がOCIが基幹系/分析系に適していると考える理由は
マルチデータフォーマット、マルチワークロード１つのDBで実現できる
「Converged Database」と、集約化による運用リスクを低減する
「Autonomous Database」の考えを実現できることとなります。

Oracle DBリフト

OCIのメリットは？と聞いて出てきそうな回答として「Oracleの機能をそのまま使える」ことが思い浮かびます。
オラクル社製だから当然..といわれればその通りかもしれませんが
実はこれはSoRのような基幹系システムにおいてはとても重要だと考えています。

基幹系システムがクラウド化しにくい理由

いくつも理由はあるかと思いますが
「連携システムが多いこと」、「セキュリティ」は共通した課題ではないでしょうか。

基幹系である以上、連携システムは多くPF変更による影響は計り知れません。
また企業にとって重要な情報を保持しているケースも多く、一般的なクラウドマネジメントサービスでは要件を満たしきれてないケースもあるかと思います。

OCI選択における、オンプレ基盤移行時の強み

ここで先ほどお話しした「Oracleの機能をそのまま使える」ことがでてきます。

何故に？と思われるかもしれませんが、オンプレ基盤系システムではOracle DBが採用されていることがかなり多いです。
脱Oracleが詠われる中で継続はいかにと思う方はいるかもしれませんが、大量のシステム連携やアプリケーションに大規模な変更なく
オンプレ基盤をクラウド化する有効な選択だと思います。

脱Oracle、脱オンプレ、1つずつ影響が大きいところから着手でいいのではないでしょうか。。
（オンプレはともかく、OCIのコストは私は悪くないと思っています。）

Oracle DBのセキュリティ機能が利用できることも強みと考えています。
行暗号化等、高度なDBセキュリティ機能を利用できることは、基盤としてのデータ信頼性にもつながります。
データは社内DCに置く必要がある場合も、データはユーザのDC内に保持しながらもOCIの機能を利用できるCloud@Customerも提供されているので対応可能です。（AWSでいうところのOutposts)

Oracle DBリフトのまとめ

私がOCIが基幹系/分析系に適していると考える理由は
オンプレ基盤はOracle DBを採用しているケースが多く、その場合は大規模な改修なくそのままクラウドリフトが可能。
また、Oracle独自のセキュリティ機能がオンプレ同様使えるので、セキュリティにおける問題のいくつかをクリアできるからです。

コスト戦略

これもOCIのメリットは？と聞いて出てきそうな回答ですが
後発クラウドなので、他クラウドよりコストが安めに設定されているサービスが多いです。

DB系サービスのコスト性能比が注目されがちですが、私はIaaS関連（特にアウトバンド通信量）のコストが、OCIがSoR/SOIに向いていると考えるポイントとなります。

通信量のコスト

どこかで目にする機会が多いかと思いますが、OCIはコンピュートやストレージが他クラウドよりかなり安く設定されています。
中でも得に価値があると考えているのが、アウトバンド通信量です。

OCIはアウトバンド通信が月10T無料であり、10T以降の通信量も日本では0.025$/GBと他クラウドより圧倒的に安いです。

クラウドシステムで大量のデータを集約して管理/分析する際にアウトバンド通信のデータ料は
コストのボリュームゾーンになりがちであり、大容量のデータを保持する基幹系/分析系システムのクラウド化の障壁です。

分析やレポーティングで定量のデータを出力するケースでは特に考えなくてはいけないポイントですが、OCIはこの課題に対して、１つの解となりうるコスト体系をだと考えています。

OCI のデータ通信量
https://www.oracle.com/jp/cloud/networking/networking-pricing.html

コスト戦略のまとめ

私がOCIが基幹系/分析系に適していると考える理由は
基幹系/分析系システムのクラウド化の障壁となる、アウトバンド通信のデータ料金が安く
コストメリットを出しやすいからです。

まとめ

OCIが基幹系/分析系に適していると考える理由として３つあげさせていただきました。
①　Single Data
②　Oracle DBリフト
③　コスト戦略

改めて見てみると
①マルチデータフォーマットやマルチワークロードを実現するDBを提供しており
②そのDBへ既存のデータの移行は比較的実行しやすく
③移行/集約したデータを使うにあたってのコストはかなり抑えている

とデータをいかにうまく使うかと考えているクラウドのように見えます。
これが、私がデータ中心であり、魅力的と感じた背景になります。

おわりに

本記事では、私の主観としてOCIの魅力をお話させていただきましたが
私は各クラウドにはそれぞれの魅力があって、適した使い方をすることで
大きなメリットを得ることができると日々考えています。

記事については賛否あるかと思います。
あくまで1つの意見としてとらえていただき、クラウドサービスに魅力について
新ためて考えるきっかけになったと思います。