クラウド対応の次世代データベース
Oracle Database 12cが描く未来像

2013年7月17日、およそ5年半振りのメジャー・バージョンアップとなるOracle Database 12cの国内提供が開始されました。本稿では、500を超える新機能の中で最も注目されているマルチテナント・アーキテクチャについて解説します。

Oracle Open World 2012での発表から10ヵ月、ついにOracle Database 12c（以下、12c）の国内提供が開始されました。クラウドの「c」を製品名に掲げ、コンテナ、プラガブル、マルチテナントなど、これまでのOracle Databaseにはなかった多くのコンセプトを携えて登場した12cには、実に500を超える新機能が実装されています。

Oracle Databaseの新機能は、その時代のトレンドと密接に関わっています。8iと9iではインターネット環境の大量トランザクション、大量データに対応するためにマルチメディア・データへの対応やReal Application Clusters（RAC）が提供され、10gと11gではグリッド・コンピューティングに対応するためにGrid InfrastructureやAutomatic Storage Management（ASM）が実装されてきました。

そして、最新バージョンである12cでは、「大量のユーザがネットワーク越しに1つのサービスを利用する」というクラウド・コンピューティングの時代に対応するべく、マルチテナント・アーキテクチャが新しく実装されました。

マルチテナントとは1つのシステムを複数のユーザ（企業）で共有しながら利用する環境のことで、様々な企業が入居する集合オフィス・ビルによく似ています。この場合、1つの建物内に複数の店舗や企業が同居できるため集約率が高まります。運営側にとっては必要な資源や運用コストを削減できるというメリットがあり、利用者側にとっても自社ビルを建築するよりは集合オフィス・ビルの一角を借りた方が安価で済みます。

データベースをマルチテナント化するための手法はこれまでいくつか登場しており、代表的なものとして「仮想マシンを複数作成する」、「データベースを複数作成する」、「スキーマを複数作成する」などがあります。これらのメリット、デメリットを整理すると、12cのマルチテナント・アーキテクチャが理解しやすくなります。図2は1つのシステム上に「HR」、「ERP」、「CRM」という3つのサービスを同居させた場合のイメージ図です。

サーバ仮想化は、サービスの数だけ仮想マシンを起動し、その上でさらにデータベースを起動するという手法です。OSやデータベースのバージョンが異なっていてもマルチテナント化できるというメリットはありますが、サーバの台数は減っても管理しなければならないOSやデータベースの数は変わらないため、運用管理コストを抑える効果はありません。またサーバを仮想化するために、より多くのメモリやCPUリソースを必要とし、他の手法と比べて集約率があまり高くならないというデメリットもあります。

データベースを複数作成してマルチテナント化した場合、サーバ仮想化と比べて管理するOSの数は減りますが、データベースの数は変わりません。データベースを起動するにはインスタンスに一定のメモリを割り当てる必要があるため、集約率には限界があります。

スキーマを複数作成した場合は集約率を高めることができますが、スキーマ名が競合している場合はスキーマ統合を検討したり、アプリケーションの改修をしたりといった作業が必要になります。また、仮想化や複数データベースの場合に確保されていた分離性がなくなるため、メモリやCPUといったリソースの割り当て方法やセキュリティ対策を十分に検討しなければなりません。


このように、従来のマルチテナント手法にはメリット、デメリットがあるため、一概に正解を導き出せないという課題がありました。この状況を打破するために登場したのが、12cのマルチテナント・アーキテクチャなのです。

12cのマルチテナント・アーキテクチャを一言で表現すると、「データベースの中にデータベースを作成する機能」です。11g以前と比べて、データの保存先であるデータ・ファイルの構造が大きく変更されています（図3参照）。

メモリ領域とバックグラウンド・プロセス群から構成されるOracleインスタンスは大きな変更はありませんが、データベースがコンテナ・データベース（CDB）という名前になり、その中にあるデータ・ファイルがプラガブル・データベース（PDB）として独立しています。アプリケーションから見ると、PDBの数だけデータベースがあるように見えるという仕組みです。

PDBがいくつあってもインスタンスは1つだけであるため、サーバ仮想化や複数データベースといった従来のマルチテナント手法よりもCPUやメモリといったハードウェア・リソースを大幅に節約し、集約度を高めることができます。さらに、PDBとして物理ファイルが独立しておりPDBごとにスキーマやオブジェクトとその権限を定義できるため、ユーザからは独立したデータベースとして扱えます。そのため、スキーマ名の競合やセキュリティの見直しといった従来のスキーマ統合の手法にありがちな課題まで、まとめて解決することができます。

さらに、12cのマルチテナント・アーキテクチャには「プラガブル（着脱可能）」という発想を活かしたユニークな機能が実装されています。

各PDBが独立してデータを保持しているため、まるで1つのファイルを「コピー＆ペースト」するかのように簡単にクローンを作成できます。クローンをテンプレートのように扱うことで、同じデータ・モデルやデータを持ったPDBを複数作成することもできます。またクローンを利用して開発環境に本番データをコピーすることもできます。これにより、例えばSaaS提供者は同サービスを利用する顧客ごとのデータベース環境を素早く作成することができます。

ファイルの「カット＆ペースト」を行うように、あるサーバからPDBを取り外し（Unplug）、別のサーバに取り付ける（Plug）ことができます。この機能を利用すれば、PDBが自由にサーバ間を行き来できるようになり、ハードウェアのメンテナンスやパッチ適用などのメンテナンス作業が発生しても、PDBを一時的に別のサーバで稼働させることができます。また、ハードウェアの更改やデータベースのバージョンアップを行う場合でも、PDBをUnplug／Plugするだけで簡単にデータベースを移行できます。

マルチテナントではなく従来型のデータベース（non-CDB）をCDBに変換してPlugすることもできるため、旧バージョンからの移行も非常に簡単です（図4参照）。

12cのマルチテナント・アーキテクチャは、「1サーバ＝複数データベース」というクラウドの時代を見据えて開発されました。高い集約率やデータの分離性、PDB単位のクローンやUnplug／Plugなどの各機能は、パブリック・クラウド、プライベート・クラウドだけではなくオンプレミスにおけるデータベースの統合などに幅広く利用できます。

現在、オンプレミスの場合、「1サーバ＝1データベース」という構成が当たり前になっていますが、ハードウェア性能の向上によってその考えも変わりつつあります。例えば、データベース・サーバとして選択されることが多い2ソケットのIAサーバで見てみると、この10年間でCPU性能は500倍、メモリ量は128倍にもなっています。この流れが続けば、「1サーバ＝1データベース」の時代はいずれ終焉を迎えるでしょう。ハードウェアのリソースに余裕が生まれることで、企業内に散在するデータベースを統合する動きが加速するはずです。

また、パブリック・クラウドにおいては、豊富はハードウェア・リソースを効率的に使用しながら集約率を高める手法がより一層求められるでしょう。クラウドにおいて必ず懸念材料として挙げられるデータの分離性やセキュリティもマルチテナント・アーキテクチャで解決することができるため、利用者にとってデータベースのクラウド化がより現実的になります。

12cのマルチテナント・アーキテクチャはこうした時代背景から生まれた機能であり、5年後や10年後におけるデータベース・システムの未来像を我々に示しています。

アシストでは、Oracle Database 12cの国内出荷開始と同時にマルチテナント・アーキテクチャを最大限活用するための「データベース統合支援サービス」と「アップグレード支援サービス」の提供を開始しました。「1サーバ＝複数データベース」の時代に向けて、今後もOracle Database 12cの最新技術を活用するためのサービス拡充や情報発信を行っていきます。

最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。