インフラ運用に携わるエンジニアにとって頭が痛い案件はいくつもあるが、その中でも屈指(?)の面倒臭さを誇るのがテスト環境の構築だ。とくにビジネスに直結するデータベースのパッチ当ては、できるだけ速く検証を済ませたいという業務部門からの要求が強い。ただしここで厄介になるのは、業務ユーザは必ずしも全員が同じバージョンのパッチを当てたいとは望んでいないということだ。業務ユーザが5人いれば、5人とも違う要求をしてくることは日常茶飯事で、希望するバッチのバージョンもばらばらだったりする。
使用中のデータベースにパッチを当てると、アプリケーションに不具合が出るかもしれないからむやみにパッチを当てたくない、という業務ユーザの心境はビジネスを回している以上やむを得ない。本番環境で経験したことのないトラブルが起これば、事業に大きく影響が出る場合もある。そうならないために、通常はテスト環境を構築して検証を行うのだが、このテスト環境を用意するという作業は、物理環境中心のインフラでは簡単にいかない場合が多い。
そこでインフラリソースの柔軟な切り出しを図るために、多くの企業で仮想化ソリューションが導入されたが、ここに来て単なる仮想化ではうまくいかないというケースが増えてきている。可用性の担保が不透明だったり、予想以上のオーバーヘッドがかかり、ヘッダ部分でリソースを食うため、期待したほどの柔軟なリソースコントロールができない、事前に聞いていたほどコストメリットがない、etc.といった不満の声が上がっているのだ。ことにデータベースにおいては「仮想化しても思ったほどの効果が出ない」と口にするユーザは多い。
結局、また面倒な物理リソースの手配に走らなければならないのか…とがっかりしたくなった運用担当者もいるかもしれないが、実はそんな常識を覆すプロダクトが存在する。Oracle Database 12cのオプションである「Oracle Multitenant」だ。パッチ当ても、そしてテスト環境の構築も、そしてバックアップやデータベース統合までも、あの面倒な手間は何だったんだろうと過去の笑い話に変えてしまう魔法のような機能、それがデータベースのマルチテナント機能である。
マルチテナントの最大のポイントは、土台となっている1個のマルチテナントコンテナデータベース(CDB)に、複数（最大252個）の仮想的なデータベースであるプラガブルデータベース （PDB）がまるでブロックのようにはめ込まれている点だ。ブロックライクなので着脱自由、つまりプラガブルなデータベースということができる。
マルチテナントアーキテクチャの構成
ではデータベースがブラガブルだとなぜ、運用担当者のココロを蝕む作業が面倒ではなくなるのだろうか。
まずテスト環境の構築。マルチテナント機能は、そのプラガブルな特徴を活かし、テスト環境に必要なだけのデータベースを早く簡単に用意することができる。アプリケーションの追加開発のテスト環境など、これまで難しかったサイズのテスト用データベースも、必要なとき必要な分だけにプラグし、テストが終了すれば容易に破棄できる。仮想化されたデータベースリソースよりも、ずっと柔軟に迅速にテスト環境を構築することが可能になるのだ。このまさに「テストクラウド」とも呼べる柔軟性がマルチテナントの大きな魅力といえる。
また、パッチ当てについても業務ユーザがそれぞれ希望するバージョンを適用することができる。運用担当者の理想をいえば、スキーマ統合やデータベース統合を行うことで、権限管理を統一し、全ユーザが同じバージョンの統合されたデータベースを使えばいい、ということになるかもしれない。だがそれでは、アプリケーション開発担当などから「データベースのバージョンくらい自由に選ばせてほしい」と苦情がくる場合も少なくない。一般的に、IT部門の運用管理担当者は、組織内の力関係で業務ユーザよりも弱い立場に置かれていることが大半で、運用管理者の努力だけでは効率化を実現できない部分が大きすぎるのだ。
だがこうしたシチュエーションもマルチテナント機能が救ってくれる。パッチを当てた状態のCDBを用意し、パッチを当てたいプラガブルデータベースから順に新しいCDBに移行する（unplug/plug）ことで アップグレードが完了する。パッチを当てたくないプラガブルデータベースは準備ができるまで元の環境に残しておけば良い。
プラグ/アンプラグの仕組み
プラグ/アンプラグのしくみで鍵となるのはマルチテナントコンテナデータベースとプラガブルデータベースをつなぐ「Root」の存在だ。このRootが、マルチテナントコンテナデータベース上にある全データベースで共有するメタデータやオブジェクトを管理している。データベースがプラグ/アンプラグされるたびにXML形式のメタデータが読み書きされるが、このメタデータを司っているのがRootになる。新しいデータベースの作成も、コンテナ間のデータベースの移動も、いわばRoot上におけるメタデータの動きの変化と言える。
