統合データベース環境の運用効率化に「マルチテナント」と「Zero Data Loss Recovery Appliance」は使えるか？：データベースクラウドに求められる3つの要件（2）（2/3 ページ）

[PR／＠IT]

PR

スキーマ統合の問題を解決するOracle Database 12cのマルチテナントアーキテクチャ

　このようなスキーマ統合の問題を解決する技術として、Oracle Database 12cで導入されたのが「マルチテナントアーキテクチャ」だ。マルチテナントアーキテクチャでは、データベースごとにインスタンスを立ち上げるのではなく、「コンテナデータベース（CDB：Container Database）」と呼ばれるデータベース上で複数の仮想的なデータベースとして「プラガブルデータベース（PDB：Pluggable Database）」を実行することで、それぞれのデータベースの独立性を確保しながらインスタンス統合を行うことができる。

　データベースのプロビジョニングやハードウェア間の移行が容易であることも、マルチテナントアーキテクチャの特徴だ。CDB内に簡単にPDBを作成できるのはもちろん、既存のPDBをベースにして新たにPDBを作成（コピー）したり、別のCDBからPDBを移動したりできる他、既存のデータベースをCDBに取り込むといったことも可能である。

　データベースを複製する際、コピー元のデータを参照することでストレージの消費を抑える「スナップショット」と呼ばれる機能も用意されている。この機能を使った場合、複製されたデータベースが持つのはオリジナルのデータへのポインタだけとなるため、短時間でデータベースをクローニングできる他、ディスク容量の削減にもつながる。

　スナップショットで作成したデータベースに対して更新処理を行うことも可能であり、その場合は変更されたデータだけがオリジナルとは別に記録される。このスナップショットの機能は、開発／テスト用のデータベースを作成するといった場面で特に威力を発揮するだろう。

マルチテナントアーキテクチャがデータベース運用を効率化

　データベースのアップグレードに伴う負担を軽減できることも、マルチテナントアーキテクチャの利点である。具体的には、CDB単位で複数のデータベースをまとめてアップグレードすることが可能な他、事前にバージョンアップしたCDBを用意しておくことにより、PDB単位で段階的にアップグレードすることもできる。個々のデータベースの要件を考慮した柔軟なアップグレードが可能なのだ。

　バックアップとリカバリについても、CDBとPDBのどちらの単位でも実行可能だ。複数のPDBをCDB単位でまとめてバックアップし、それを一括してリストアできる他、一部のPDBだけをリストアするといったことも可能となっている。

　また、マルチテナントアーキテクチャには、各データベースに対するハードウェアリソースの割り当てを効率化するための「share」という概念に基づく仕組みが組み込まれている。リソース割当量をパーセンテージで固定的に指定した場合、新たなデータベースを追加した際に再計算が必要となり、設定作業が煩雑になる。それに対して、shareでは各データベースに設定された数値（share）の総和から、割り当てるリソースを自動算出する方式をとる。

　これにより、例えばそれぞれ「1 share」と「2 share」を設定した2つのデータベースがある場合、「2 share」のデータベースには約66％、「1 share」のデータベースには約33％のリソースが自動的に割り当てられる。この環境に、さらに「1 share」のデータベースを追加すると、リソースの再計算が自動的に行われ、「2 share」のデータベースへの割り当ては50％、「1 share」のデータベースへの割り当ては各25％に変更される。マルチテナントアーキテクチャでは、このshareの仕組みによって効率的なリソース管理が実現されるのだ。

　データベースのクローンを手軽に作成できるというマルチテナントアーキテクチャの利点を生かした使い方として、読み書きが可能な分析用サンドボックス環境の作成が考えられる。例えば、データウェアハウスで利用しているPDBのクローンを作り、データを変更した場合の影響を調べたり、索引の付加によるクエリ実行速度の変化を確認したりするわけだ。また、インメモリデータベース機能である「Oracle Database In-Memory」と組み合わせて、クローンとして作成したデータベースを高速な分析基盤として使うといった用途も考えられる。