Oracle Database 12cのマルチテナント・アーキテクチャは他とは何が違うのか

完璧なデータベースの分離性を実現した12cのマルチテナント・アーキテクチャとは

　大勢のユーザーが、インターネット越しに1つのクラウドサービスを利用する。その実現に必要なのがマルチテナントという環境だ。

　「マルチテナントは、クラウドのサービスを実現するために持っていなければならない機能です。それをどこで持っているかが、鍵となります」（田村氏）

　一般的なマルチテナント実現方法は、仮想化ハイパーバイザーを利用し、物理サーバー上でユーザーごとの仮想サーバーを動かすもの。この方法はすでに「こなれた」感もあり、容易に実現でき分離性も高い。しかし、OSごと分離するので、ユーザー数が増えればその分だけの仮想サーバーを管理、運用しなければならない。

　「仮想サーバーを使う方法は、データベースの統合を考えた場合には、必ずしも適切とは言えません。管理性はあまり向上しないのです」（田村氏）

　一方でデータベースをクラウドサービス化するのであれば、スキーマのレベルで分離しマルチテナントを実現する方法がある。これは、同一のデータベースで、ユーザーごとにスキーマを分けて使う。リソースを共有し、運用管理を統一できるメリットがある。とはいえ、「スキーマは、本来複数のデータベースの統合やマルチテナントのために作られた機能ではありません」と田村氏。リソースは共有でき管理も統一できるが、一方で分離性はそれほど高くない。例えばデータベース管理者ユーザなどはテナント間で共有されることになる。

　余談だが、SaaS、PaaSベンダーであるSalesforce.comの場合には、基本的に同一データベース、同一スキーマを複数ユーザーで共有するアーキテクチャを取っている。マルチテナントの実現は、内部的にパーティショニング機能などを利用し、アプリケーションのレベルで独自実装しているのだ。この方法は、スキーマで分離するよりもリソース効率は高くなるが、分離性は低い。なので、さまざまな利用制限がある。データベースを自由にカスタマイズすることはできず、Salesforce.comの定めた厳しいルールに基づいた利用を強いられる。

　これらのマルチテナントの実現方法では、データベースをクラウドに本格的に対応するには不十分である。そう判断したOracleが新たに提供するのが、マルチテナント・コンテナ・データベースとプラガブル・データベースを使って実現する12cのマルチテナント・アーキテクチャだ。スキーマレベルの方法ではないが、管理、運用性はそれ以上に柔軟で容易。さらに、仮想サーバーを利用するのに匹敵する、いやデータベースとしてはより「完璧なデータベースの分離性」も実現する。

マルチテナント・アーキテクチャの最大のメリットは運用管理性が大きく向上すること

　"c"が強調されたこともあり、このマルチテナント・アーキテクチャは「クラウドのためのもの」というイメージが強い。なので、この機能を利用すべきはクラウドサービスベンダーなど、一部の大規模ユーザーだと考えがちだ。もちろん、そういった用途に最適なものだろう。

　しかし、「今回のマルチテナント・アーキテクチャで、もっとも重要なのは運用管理が極めてシンプルになることです。数多くのデータベースを統合しても、データベースの管理は1つでいい。これは、アップデート、バックアップ、テスト環境などを作るクローニングなど、日常的に手間のかかる作業を大幅に軽減します」と田村氏は言う。

　つまりは完璧な分離性を持つデータベースのマルチテナント環境は、それを実現することのみが目的なのではなく、それによりもたらされる運用管理の大幅な軽減にこそ大きなメリットがあるということ。なので、必ずしもクラウドベンダーだけが必要とするものではなく、いま複数のデータベースが稼動しておりその運用管理に手間もコストもかかっているならば、12cのマルチテナント・アーキテクチャは誰にでも大きなメリットをもたらす可能性がある。

　「こういう説明をしていると、すべてを1つにしなければならないのですか、という質問を必ず受けます。そんなことはありません。個別なほうがいいものは、いままで通り個別で運用すればいい。一方で、10個あるデータベースを1つに統合したほうが効率的な場合もあります。これからは、データベースをどの単位で、いくつどこに作るかを考える必要があります」（田村氏）

　運用管理の単位が、ベースとなるマルチテナント・コンテナ・データベースと、個別システムのプラガブル・データベースに分離される。作業を一括しておこないたければ、マルチテナント・コンテナ・データベースに対してメンテナンス作業を実施すればよい。目的別にマルチテナント・コンテナ・データベースを設定しておけば、その目的単位でも管理を統合できる。個別に実施したければプラガブル・データベース単位で、独立して行えば良い。これは、運用管理をある意味階層的にコントロールできるということ。このように一括管理できることは、結果的にIT環境のコンプライアンス確保にも大きく貢献する。

マルチテナント・アーキテクチャでDBAとアプリケーション管理者の役割が明確に分離できる

　これまでは、データベース導入時には、どのサーバーマシンを選び、それにどれくらいのメモリー、ストレージを搭載するか、さらにインスタンスをいくつ上げるか考慮し構成を設計した。そういったサーバーが、複数あるのが企業ユースでは普通だ。これからは、それらに加え、そのサーバーの中にいくつのマルチテナント・コンテナ・データベースを作るのか、さらにどのコンテナで、どのプラガブル・データベースを動かすのかを考える必要があるのだ。

　これは、具体的にどういうことだろうか。

　たとえば、仮想サーバーを使ってデータベースを統合するのは、企業においてもすでに導入されている。ところが、せっかく統合しても、まとめてバックアップを取りバックアップ作業を効率化することはなかなかできない。これは技術的に難しいというよりも、たとえば統合したAのデータベースとBのデータベースでは利用する部門が異なり、バックアップを同じタイミングでは取りたくないといった理由が管理作業の効率化を邪魔するのだ。そうなると、仮想化で統合はしたけれども、結局はデータベース単位で個別にバックアップを取ることに。これは、パッチあてやバージョンアップなど、他の管理作業でも同様なのだ。仮想化の管理レイヤーが増える分だけ、管理作業はむしろ複雑化しかねない。

　これがマルチテナント・コンテナ・データベースを利用すると大きく変わる。たとえば、日次バックアップ用、週次バックアップ用のコンテナを別々に作っておき、要件に応じプラガブル・データベースをそれぞれに刺し動かす方法がある。または、パッチあてなどのメンテナンスを目的とする待避用コンテナを作っておき、必要時にだけプラグして作業することも可能だ。もちろん、ピーク時にだけ高性能なサーバー上のコンテナに刺し直し、必要な性能を確保する使い方もあるだろう。このように、今後のデータベースの管理者は、コンテナをどう構成すると、効率的で管理性が向上するのか、それを考えることになる。

　これは、データベース管理者とアプリケーション管理者を明確に分けることにつながる。データベース管理者は、マルチテナント・コンテナ・データベース以下のレイヤーの管理だけに集中すればいい。個々のプラガブル・データベースやその上で動くアプリケーションの管理は、アプリケーションサイドの管理者が担う。こうすることで、とくに日本にはあまり数多くいない「専任のデータベース管理者」という存在を明確化、育成できることにもなる。

　このアプリケーションとデータベースの管理者を分けるメリットは、作業を効率化するだけでなくセキュリティ対策、コンプライアンス確保の面でもメリットが大きい。

　「それぞれの管理者の役割が明確になり、その分野のプロフェッショナルになれます。さらに、データベース管理者は、プラガブル・データベースに触る必要がないので、たとえばそこで管理されている個人情報などにアクセスする権限はなくていい。まさに役割と権限を、マルチテナント・アーキテクチャで分離できるわけです」（田村氏）

ライセンス費用の面でもメリットは大

　このマルチテナント・アーキテクチャを利用するには、Oracle Database Enterprise EditionのオプションであるOracle Multitenant Optionを購入する必要がある。これだけ見ると、オプション分だけ費用が増えるのかと思うところ。しかし、場合によってはこの追加オプションの導入だけでライセンス費用の圧縮となる可能性もある。Multitenant Optionは、親となるサーバー単位のNamed User PlusかProcessorライセンスとなる。コンテナやプラガブル・データベース単位でのライセンスは必要ない。1つのコンテナで252個のプラガブル・データベースが作れるが、仮にそこまでデータベースを増やしても追加ライセンス費用は発生しないのだ。

　また、コスト面から数多くのStandard Editionのデータベースを仕方がなく利用しているユーザーも多いだろう。Enterprise Editionのあの機能を使いたくても、諦めていた。そんなユーザーが、そのデータベースをプラガブル・データベース化しマルチテナント・コンテナ・データベースに移行すれば、そのデータベースは自動的にEnterprise Editionとして利用できるのだ。このように運用管理性向上のために統合するだけでなく、ライセンス費用の面からも12cのマルチテナント・アーキテクチャへの移行は、大きなメリットを生み出す可能性がある。

　この他にもデータベースのレベルで情報のライフサイクル管理を実現するHeat Map機能、アクセスするユーザーやアプリケーションに応じデータを隠すことができるData Redaction機能など、12cにはさまざまな新機能がある。「じつは、新機能の多くが、マルチテナント環境を効率的に利用できるようにするためのものとなっています」と田村氏。個別に使っても効果はあるが、マルチテナントで利用することで、その効果が最大化するのだ。もちろん新機能だけでなく、Real Application Clustersなどの既存機能もマルチテナントに対応している。新たなマルチテナントという環境の中で、データベースがいったいどのような動きになるのか。興味のあるエンジニアは、是非Oracle Technology Networkのサイトから12cをダウンロードして試してみてほしい。

***

　さて、今回は目玉である、マルチテナント・アーキテクチャの話をメインにお届けした。今後DB　Onlineでは、さらにマルチテナント・アーキテクチャを掘り下げるほか、その他の新機能にもフォーカスを当てて、Oracle Database 12cの真の姿を明らかにしていきたいと考えている。実際に検証作業に携わったエンジニアからその印象を聴き、利用した際に感じた本音の部分も引き出して、皆さんにお伝えする予定だ。