「マルチテナント・アーキテクチャ」でDB運用管理の方法論が進化する

前回は、主に「データベース統合」の観点から、Oracle Database 12cで新たに採用された「マルチテナント・アーキテクチャ」がもたらすメリットについて紹介した。今回は、このアーキテクチャによって、旧来のDB運用管理の方法論が、どう効率的になるのかについて説明していこう。

ここで少しだけ復習をしておこう。マルチテナント・アーキテクチャは、1つのデータベース上に、複数の仮想的なデータベースを作成して稼働を可能にする機構だ。構成にあたっては、新しい型のデータベースである「マルチテナント・コンテナ・データベース（CDB）」を作成し、その上に「プラガブル・データベース（PDB）」を差し込んで稼働させるスタイルになる。

CDBではメモリやCPUといったシステムリソースを管理し、その上で稼働している複数のPDBで共有する。そのため、一般的な仮想化機構を使った仮想マシンによる方法よりもオーバーヘッドが少なく、より効率的にリソースを使うデータベース統合が実現できるというのが、前回の主な内容だ。

実は、データベースをCDBとPDBの各レイヤに分割できるということには、単に「リソースが効率的に使える」以上のメリットがある。従来、アプリケーションとデータベースとの結びつきが密接だったが故に必要だった、さまざまな運用管理上の手間が、このプラガブル・データベースをうまく活用することで大幅に軽減できるのだ。

今回は主に、マルチテナント・アーキテクチャによって、旧来のDB運用管理の方法論が、どのように変わるのかについて説明していこう。

手間のかかるDBへのパッチ当てが「アンプラグ＆プラグ」で

すべてのデータベース管理者にとって、重要でありながら、手間がかかる管理作業のひとつが「データベースへのパッチ適用」そして「データベースのバージョンアップ」である。実際、Oracle Databaseにおいても、年間4回ほどのPSU（Patch Set Update：重要な修正プログラムとセキュリティ脆弱性修正プログラムの累積パッチ）と呼ばれるパッチが出されており、適用が強く推奨されている。

新たな機能を追加するだけではなく、リリース後に発見された脆弱性や不具合を修正するという意味で、パッチ適用やバージョンアップは必要な管理作業だ。ただ、その重要さは理解しているものの、なかなか気軽には実行できないというのが、従来の状況だった。

データベース側のバージョンアップやパッチが、アプリケーションに対して及ぼす影響を見きわめるためには、事前の入念なテストが必要になる。アップデートしたデータベース上に、既存のアプリケーションの環境を改めて用意し、それが問題なく動くかどうかを確認。問題がなければ最新のデータを旧環境と同期させつつ、新環境へと切り替えていくという作業が必要になる。かなりの手間と、注意力を必要とする作業になっていたはずだ。

マルチテナント・アーキテクチャでは、CDBとPDBを容易に「分離」できることにより、こうした作業を大幅に省力化できる。

大まかな手順はこうだ。まず、パッチを適用したり、バージョンアップを行ったりした新たなCDBを（テスト環境として）作成する。次に、対象となるPDBの複製を行い、新環境のCDB上に「差し込む」。PDBの移行にあたって、PDB自体やCDBに変更を行う必要はないし、複数の環境も簡単に作ることができる。新しいCDBの上で、PDBやアプリケーションが問題なく稼働することが確認できれば、本番環境も同様に移し替えて稼働させることが可能になるというわけだ。

マルチテナント・アーキテクチャへの移行後は、パッチ適用やバージョンアップ、リソース管理といった、従来の一般的な運用管理はCDBのレベルで行い、各アプリケーションに関する開発や管理作業はPDBに対して行うといった「分割」が可能になる。それぞれのレベルでの管理作業を、明確に分けて行えるようになることで、データベースの運用管理スキームを、従来よりも大幅に簡素化、省力化できるというわけだ。

マルチテナントの応用例－ライフサイクルに応じたDBサービスの提供

この、CDBとPDBを「分けて」管理できるというプラガブル・データベースの特長をうまく利用することにより、これまでは難しかった、より高度なデータベースサービスの提供が可能になる。ここでは、システムのライフサイクルに合わせて変化する、データベースの管理スキームを提供する例を考えてみよう。

一般的にITシステムでは、システムごとに求められる要件があり、その要件によって、必要な「可用性」「機密性」「バックアップ頻度」などが異なる。また、その要件は、時間の経過によっても変わってくる可能性がある。

例えば、当初部門レベルで導入し、今後全社規模に展開することになるシステムや、新たなシステムへの入れ替えによって徐々に終息していく方向にあるシステムなどでは、そのシステムの稼働に求められる水準、つまり「サービスレベル」も、時機に応じて変化することになる。

プラガブル・データベースのアーキテクチャをうまく使うと、こうした異なるサービスレベルが求められる複数のシステムに、容易に対応することが可能になる。

具体的には、クラスタリングによる冗長化や、データ保護機能、バックアップ頻度などのサービスレベルが異なるCDBを複数作っておき、それぞれのCDBの上に、対応するPDBを差し込む形になる。

バックアップや運用監視などは、設定したサービスレベルに応じて、各CDBに対して一括で行うことができる。また、最大の利点は、サービスレベルを変更する場合にも、PDBを別のCDB上に差し替えるだけで作業が済むという点だ。CDBとPDBを分離できることにより、従来は難しかったサービスレベルの変更を、より容易に実現できる。

さらに、Oracle Database 12cでは、それぞれのPDBが、実際にシステム上で利用したストレージ容量やCPUリソースなどについてログを記録し、集計することが可能になっている。この記録と、サービスレベルの異なるCDBとを組み合わせて管理すれば、例えば「サービスレベル」と「使用リソース」に対して費用を発生させるような、プライベートクラウド上での「DBaaS（Database as a Service）」へ発展させていくことも可能になるわけだ。

Oracle Database 12cの「c」は、「Cloud」の頭文字をとったものだという。クラウドでの効率的なデータサービス提供を可能にする「マルチテナント・アーキテクチャ」が、12cの目玉機能とされている理由は、そこにある。

運用管理をさらにシンプルにするDatabase 12cの新機能

マルチテナント・アーキテクチャ以外にも、Oracle Database 12cには、データベースの運用管理を自動化、効率化するためのさまざまな新機能が搭載されている。ここで、そのいくつかを紹介しておこう。

「Advanced Compression」オプションには、データベースのストレージ効率とパフォーマンスに大きな影響を与える、データの「圧縮」や「移動」の作業を省力化する機能が追加されている。従来、管理者が対象となるデータの利用頻度やタイミングを見計らって随時実行していた作業を、データベース側で自動化してくれる。管理者は、あらかじめ「90日間更新がなければ圧縮」といった、データ管理に関するポリシーを設定しておくだけでいい。その後は、データの利用頻度などをデータベースが自分で判断し、圧縮、アーカイブ、移動などの処理を実行してくれる。

「Active Data Guard」の新機能として実装された「Far Sync」は、災害や障害に備えて遠隔地に構築しているバックアップサイトとのデータ同期を、本番環境のパフォーマンスに影響を与えずに行える機能だ。Active Data Guardでは、スタンバイサイトと直接データ同期を行うのではなく、より遅延の少ない場所にトランザクションログのみを同期転送しておき、遠隔地にあるサイトに対しては、そのログをもとに時間差でデータ同期を行う。この仕組みによって、例えば国内の遠隔地だけでなく、ネットワーク遅延の大きい海外のデータセンターなどにも、より容易かつ確実にバックアップサイトを配備することが可能になる。

マルチテナント・アーキテクチャだけでなく、Oracle Database 12cのこうした新たな機能を組み合わせて使うことで、求められるレベルに応じた高度なデータサービスを、運用管理の手間やコストを低減させつつ、実現することができるのだ。

今回は、マルチテナント・アーキテクチャをはじめとするOracle Database 12cの新機能が、主にデータベース運用管理の方法をどのように変えるのかについて見てきた。最終回となる次回は、さらに視点を変え、マルチテナント・アーキテクチャによって「アプリケーション開発・テスト」の方法が、どう変わるかについて見てみよう。