Future Tech Blog
フューチャー技術ブログ
DBカテゴリ

「脱Oracle」の背景にある、Oracle Databaseの価値を改めて考える

はじめに

2019年10月15日、Amazonは自社サービスにおける実質的な”脱Oracle”を発表しました。75PBに及ぶデータを、傘下のAWSが提供するDatabase Service（AuroraやDynamoDB、Redshiftなど）へと移行したとの事。

この一報は、Amazonというグローバル規模のECの巨人、クラウド・プラットフォーマーのリーダーの一角が、大規模基幹システム領域におけるRDBMSのデファクト・スタンダードと決別したという点で、業界関係者に対して非常に大きなインパクトを残したものかと思います。
大人の色々な側面が垣間見えるものの、非常に難易度の移行PJであった事はを想像に難くありません。

“Oracleもいよいよ賞味期限を迎える”

果たしてそうなのか。ここで今一度、**”脱Oracle”とは何を脱する事なのか**、を考えてみます。

“脱Oracle”とは？

第1は高コスト & ベンダー・ロックインからの脱却です。Oracle Databaseの価格が競合のプロダクトと比較して高額である中で、価格改定や廉価版プロダクトの提供停止、自社クラウド・プラットフォームへの見る人によってはやや露骨に見える誘導といった流れに対してのアレルギー反応から生まれた潮流と見ます。

第2はHWと代替プロダクト(主にPostgreSQL)の進化です。HWに関しては、DBの性能面でボトルネックとなりやすい物理I/Oの領域におけるフラッシュストレージの普及が大きいと考えます。

PostgreSQLは近年、メジャーバージョンのリリース毎に目覚ましい機能追加を続けています。特に注目すべきはパーティショニング機能で、Oracleの専売特許と言って過言でなかった機能レベルに近づきつつあります。

また、PostgreSQLはBSDライセンスの体系を採用している事から、後述のAurora(RDS)、RedshiftといったAWSのマネージド・サービス、EnetrpriseDB、Vertica、Greenplumなどの商用プロダクトのベースとして採用され、名を変え機能拡張された形で世出しています。

具体的な採用領域としては、Oracle EEの代替・SEの移行先としてAurora(RDS)やEnterpriseDB、Exadataの代替(DHW系ワークロードの場合)としてRedshiftやVertica、Greenplumといったマッピングになるかと思います。

「デザインしたアーキテクチャに対して、必要な機能とコストを鑑みてプロダクト選定した結果、それはOracle Databaseでなかった」

私はこれを”脱Oracle”と定義します。

Oracleの進化

Oracle Databseは時代のニーズに応え続ける事により、DBMSのリーディング・プロダクトという地位を築きました。

以降では、改めてOracle Databaseの歴史を辿ってみたいと思います。

Oracle V2

  • Oracle Databaseはイメージ戦略(枯れているプロダクトと印象付けたい)からV2銘と打たれ、世界初の商用RDBMSとしてリリースされました。

Oracle 8

  • パーティショニング機能が実装され、テーブルをパーティション・キーに応じて物理分割する事が可能となりました。これにより、ストレージ(HDD)ネックの時代において、I/O極小化の観点での新たなチューニング・アプローチをもたらしました。
  • **ORDBMSの機能(関数や型の独自定義)**が実装され、より柔軟なデータ管理が可能となりました。
    ※ORDBMSの実装自体はOracleが他プロダクトに先行しているものではありません

Oracle 9i

  • 9iで実装された**Real Application Clusters(RAC)**は業界屈指の革新的な発明だと私は解釈しています。クラスタ構成ノードのメモリ間でデータを転送・共有させる事で、トランザクションを担保しながらDBのスケールアウトを可能としました。このアーキテクチャのボトルネックは物理ストレージの性能に依存しますが、ストレージが性能限界でない限りはHWリソースの追加により処理性能がスケールすします(機能特性に応じたのチューニングは必要です)。
  • 9iの登場は、ベンダー・ロックイン状態の企業における**”脱メインフレーム”**にあたっての強力な武器となりました。

Oracle 10g

  • 10gにおいて実装されたGrid Infrastructure、とりわけ**Automatic Storage Management(ASM)**の機能は、ストレージの仮想化を実現しました。Oracle Databaseから見えるデバイスをASM DiskGroupという形で抽象化させる事で、I/Oを複数の物理デバイスに分散可能となります。これにより、Oracleは可用性の向上とともに、前述のRACの性能面での懸念を補完しました。
  • 当該バージョン以降からは、DB運用の自動化(機械化)を目指した機能が追加されています。

Oracle Exadata Database Machine

  • 現在のオンプレミス・シーンにおいて、最高峰のRDBMS環境です。Oracle社のSun Microsystems買収により、SunのHW技術を土台としてOracle Databaseの稼働に特化したHW/MW一体のプロダクトが登場しました。
  • Oracle社は、**“Exadataに移行するだけで性能が向上する”という謳い文句とともに売り込みを行い、2010年代に多くの導入事例が生まれました。このコンセプトは、自PJメンバーのスキル不足や、アーキテクチャの多少の考慮不足をプロダクトがカバーしてくれる**という点で、システムの導入側にとっては非常に魅力的です。それゆえに、アーキテクチャ・デザインで勝負したい人達(私たちもそうですが)にとっては、最終手段的位置付けなのではないでしょうか。

Oracle 19c(12cR2)

  • 11g以降も、Oracleは機能アップグレードを継続的に行ってきました。現時点での最新バージョンは19cで、これは旧バージョン体系(Oracle社が2018年リリースよりポリシー変更)では12cR2に相当します。
  • 近年ではクラウド・プラットフォームでの稼働を意識した機能追加がされていますが、プロダクトのライセンス体系(廉価版エディションの廃止、稼働筐体の物理CPUコア数に対する課金など)がOracle Cloudを前提としているため、前述のアレルギー反応を生む結果となっています。

Amazonの事例から見る(推察する)”脱Oracle”

先に取り上げたAmazonにおけるDBのAWS移行に関して、どういった機能マッピングで”脱Oracle”したのか、私なりにAWSのマネージド・サービスとのマッピングして読み解いてみたいと思います。

※あくまでも私個人の推察であり、関係者へのヒアリング等に基づいたものではありません

Aurora(RDS)

https://aws.amazon.com/jp/rds/aurora/

ハイトランザクションのOLTP系のDBがここに移行されたと推察します。ECのコア領域の大半の移行先がここなのではないでしょうか。
ワークロード特性によって、PostgreSQLのMySQLで使い分けをしているかもしれません。

Redshift

https://aws.amazon.com/jp/redshift/

RedshiftのようなMPPアーキテクチャの分散RDBMSが活きるのは、構造化された大量データを扱うバッチ処理や、BIのようなアドホックなクエリが発行される(いわゆる事由分析)といった領域です。
ECのイメージでは、多角的なメトリクスでの売上等の集計であったり、顧客の行動分析など、主に(やはり)BI領域で適用されているのではと推察します。

DyanmoDB

https://aws.amazon.com/jp/dynamodb/

RDBMSよりもNoSQL(KVS)で管理する方が適しているデータを管理するようなアプリケーションで利用していると推察します。
昨年にトランザクション機能がリリースされるなど、採用可能領域を拡げてる印象です。トランザクション機能はユーザーの需要に応えたというのは当然あるでしょうが、もしかしたらAmazonのDB移行PJを見据えた側面もあるかもしれません。

Neptune

https://aws.amazon.com/jp/neptune/

リコメンド機能など、消費者と商品の関連性の分析といった領域で利用していると推察します。
機能実装の初期段階からグラフDBを利用している事も考えられ、当該領域に関しては”脱Oracle”のスコープ外かもしれません。

その他

ElasticCache、DocumentDB(MongoDB)、Timestream、QLDB 等のマネージド・サービスも適宜利用しているでしょうし、非/未公開のDBも利用しているかもしれません。

Oracleの現在地

ここまで述べてきたように、Oracle Databaseは現在においても最も洗練されたRDBMSの1つでしょう。しかしながら、市場におけるシェアは減っていくものと考えます。DBMSはOracle一択といっても過言ではなかった時代から、数多の選択肢が存在する群雄割拠の時代に突入しています。

ここ数年、私自身が顧客や業界関係者と会話する中でも、”脱Oracleがよしとされる風潮”を感じる場面に多く遭遇します。Oracle Databaseの旗色は悪く、今後ドラスティックな方向転換(価格など含めたライセンス体系の見直し)がない限りは劇的に良くなる事もないでしょう。

“脱Oracle”は大いに結構な事だと思います。

しかしながら、そこには敬意があるべきと考えます。Oracle DatabaseはRDBMSの歴史を作り、未だDBMSのリーディング・プロダクトです。その存在あったからこそ、追随せんとするプロダクト/サービスが生まれているのもまた事実です。

おわりに

RDBMSは世の中を変えました。

Edger F. Coddが提唱したリレーショナル・モデル、IBMのSystem R、Michael Stonebreakerが実装に落としたIngress(→ Postgres → PostgreSQL → MPPアーキテクチャの分散RDBMS)、Larry Ellisonが商用化を成功させたOracle Database、この系譜は、然るべき人が然るべく時代の流れを読み、”世界を変える”仕事をしたものだと思います。

彼らの功績により、私たちはコンピューター・リソースを用いてデータを構造的に管理する事が可能になりました。企業は業務の自動化を行い、生産性を飛躍的に向上させました。

定量的な多角的分析によって、新たなサービスが創出され、企業のみならず私たち個人も日常の発見・改善の恩恵を受けてきました。

全体を通して、Oracle Databaseの良い面にフォーカスを当てた内容となっていますが、決して肩入れするといった意図はありません。昨今の潮流・批判(やや的を外したもの)を少し不憫に感じ、この記事を執筆するに至りました。

私も自分の仕事として、自らの定義に従い、”脱Oracle”をします。

「デザインしたアーキテクチャに対して、必要な機能とコストを鑑みてプロダクト選定した結果、それはOracle Databaseでなかった」