Oracle Database 12cの「マルチテナント・アーキテクチャ」は、データベース統合や運用管理だけでなく、従来からの「アプリケーション開発・テスト」のプロセスにも大きな変化を起こす。今回は主にこの「アプリケーション」の観点から、12cがもたらすメリットについて紹介する。

この連載では、Oracle Database 12cの持つ新機能、特に「マルチテナント・アーキテクチャ」が、エンタープライズシステムにもたらす変化について紹介している。前々回は主に「データベース統合」の視点、前回は「データベース運用管理」の視点で、マルチテナント・アーキテクチャが、従来からの方法論をどのように変えるのかについて紹介した。

3回目となる今回は、主に「アプリケーション開発・テスト」の観点から、マルチテナント・アーキテクチャを中心とするOracle Database 12cがもたらす恩恵について考えてみたい。

Oracle Database 12cから新たに採用されたマルチテナント・アーキテクチャは、新たなデータベース型である「マルチテナント・コンテナ・データベース(CDB)」の上に、複数の「プラガブル・データベース(PDB)」を乗せて稼働させることができる機構である。データベースが利用するシステムリソースはCDB上で統合して管理し、その上のPDBでは、CDBが管理するリソースを共有して稼働する。

マルチテナント・アーキテクチャ
運用コストを圧縮してシステムの独立性を保つ、プラガブル・データベースでの統合

前回、前々回でも触れたが、この「CDBとPDBが分離する」という仕組みによって、従来、分離することが難しい「密結合」の状態にあった「データベース管理」と「アプリケーション開発」との関係は、必要に応じて組み替えられる「疎結合」の状態へと変化する。これによって、データベース管理者は主にCDBを、アプリケーション開発者は主にPDBを見て作業を行うという役割分担が可能になる。

このことは、アプリケーションの開発・テストのプロセスにも、大きな変化をもたらすのだ。

PDBで「開発・テスト環境の構築」がカンタンに

いくつか例を考えてみよう。新規アプリケーションの開発・テストにあたっては「環境の構築」が必要となる。従来、そうした環境を作る際には、開発・テスト用のサーバを立て、そこにOS、ミドルウェア、データベース、テストデータをインストールして準備をする必要がある。

テスト環境が1つだけで済むのであれば、こうした作業もそこまでの負荷にはならない。しかし現実には、開発フェーズや機能ごとに異なるテストを行うケースが多く、テスト環境もその数だけ用意しなければならない。テストデータの準備も含めるとかなりの工数になってしまう。

Oracle Database 12cのマルチテナント・アーキテクチャでは、あらかじめ開発・テスト用開発環境用のPDBテンプレートを用意しておき、それをクローニングするだけで、新たなテスト環境用データベースができあがる。データベースの基本設定に関してはCDBで統一可能なため、個々のテスト環境の設定ミスなどに起因する問題は回避することができる。

クローニング

また、追加開発や障害対応においては、開発・テスト環境に本番環境と同等のデータを用意することが多いが、この際も、Oracle Database 12cであれば、本番環境から開発・テスト環境にPDBをクローニングするだけだ。もちろん、本番環境のデータをそのまま移すのは危険と言える。そこで、Oracle Database 12cには、データの一部を自動で加工できる「Data Redaction」と呼ばれるセキュリティ機能も用意されている。この機能を使うと、データベースにアクセスするユーザーやアプリケーションにアクセスポリシーを設定し、アクセスに対してポリシーに応じたマスキングを掛けたデータを結果として返すことができる。

Oracle Database 12c のセキュリティ
ポリシーに従って精密データを動的にマスキング

PDBのクローンニングと、このData Redactionを必要に応じて使い分ければ、従来、それなりの手間と工数を掛けていたアプリ開発やテストのための環境構築を大幅に省力化できるというわけだ。

Oracle Databaseだからこそ実現できる「本番と同じ」テスト環境

アプリケーションの開発やテストを行う際に問題となるのは、もちろん環境構築の手間だけではない。

例えば「本番環境と同等の負荷をテスト環境で十分に再現できない」「本番環境で起こっている不具合が、テスト環境で再現できない」といった状況は、実際に開発に携わっている人であれば、一度は経験したことがあるのではないだろうか。

Oracle Database 12cでは、こうした状況を打破するためのソリューションが利用できる。それがOracle Database 12cの標準管理フレームワークである「Oracle Enterprise Manager 12c」(Oracle EM)との統合で利用できる「Real Application Testing(RAT)」と呼ばれるオプション製品である。

Oracle Database 12cでは、本番環境で発生しているトランザクションをすべてキャプチャし、ログとして保存しておく機能が用意されている。必要に応じて、このトランザクションログをテスト環境上で「再現」することで、本番環境と同等の負荷を与えてパフォーマンスを検証したり、テスト環境の手作業では再現不可能な本番でのアクセスや操作のパターンを忠実に、網羅的に再現することが可能になっている。

Real Application Testing(RAT)

Database Replay
最も現実的な「データベース機能テスト」を実現

SQL Performance Analyzer(SPA)
SQL単体パフォーマンスのテスト

開発・テスト環境構築の容易さに加えて、Oracle Database 12c特有のこうした機能を活用することにより、安定して稼働するアプリケーションの開発や改善を効率的に促進することができるのだ。もちろん、開発が完了したアプリケーションを本番環境にデプロイする際にも、PDBによる省力化が期待できる。

Oracle DBとWebLogicとの組み合わせをオススメする理由

Oracle Database 12cには、実際のアプリケーション運用の現場においても非常に役に立つ機能が多く追加されている。そのうちのいくつかを紹介しておこう。

「アプリケーションの継続性」(Application Continuity)を担保するにあたって、Oracle Database 12cのRAC(Real Application Cluster)では、RACノードのひとつに障害が起きた場合に、ユーザー側にエラーの発生を伝えることなく、透過的に正常なノードへと処理を引き継ぐ機能が追加されている。

アプリケーションサーバとして、同じくオラクルが提供する最新の「WebLogic Server」を利用している場合、この機能を使うにあたってアプリケーションコードの変更は不要だ。

RACでは従来から、RACを構成するノードの1つに障害が起きた場合、他の正常なノードに接続が切り替わり、システム自体は停止することなく、処理を継続することが可能だった。しかし、アプリケーションとの間でトランザクションが発生しているノードに障害が起きてしまった場合に備えて、アプリケーション側にエラーを返したりリトライをするコードを組み込むなどの準備をしておく必要があった。それでも大抵の場合は、実際にアプリケーションとデータベースの処理のどのタイミングで障害が起きたか確認する方法が無く、データの二重登録などが行われることもあったはずだ。 Oracle Database 12cと最新のWebLogic Server 12cの組み合わせでは、GridLinkと汎用データソースの双方に追加された新機能によって、この再実行の処理が自動化されている。クエリの実行中に、FANイベントの通知や回復可能なエラーが発生した場合、生存しているノードに対し、データベースに対して行われたにも関わらず失われてしまった処理を、自動で再実行するのである。しかも再実行に際しては、最後に行われたトランザクションがデータベース側でcommitされたかどうかを確認する機能も追加されている。

新機能:Application Continuity
障害時にトランザクションを自動リプレイし、ユーザーにエラーを返さない

ちなみに、最新のWebLogic Server 12cでは、Oracle Database 12cが提供するPDBに対し、より最適化された接続方式が用意されている。

ひとつは、WebLogicクラスタに含まれるデータソースごとにPDB接続を行うもので、これは、従来のDBサービスへの接続と同等の方式になる。

もうひとつは「動的PDBスイッチング」と呼ばれるもので、データソース内のコネクションごとにPDBの接続先を動的に変更できるものだ。この動的PDBスイッチングを活用すれば、アプリケーションから接続するPDBを容易に切り替えられるため、アプリケーションの移植性の向上や、複数のアプリケーションでデータソースを共有することによるリソースの有効活用といったメリットを享受できる。

より高い継続性が求められるアプリケーションの安定稼働や運用にあたって、Oracle Database 12cとWebLogic Server 12cの組み合わせから得られるメリットは非常に大きい。用途によっては十分検討に値するはずだ。

初期コストだけでは計れない「Oracle Database 12c」が生みだす価値

さて、これまで3回にわたって「マルチテナント・アーキテクチャ」を中心とする「Oracle Database 12c」の新機能が、データベース統合や運用管理、そしてアプリケーション開発やテストのプロセスにどのような変化を起こすのかについて紹介してきた。Oracle Database 12cが持つ高度な機能の一部を知ってもらうことができたのであれば幸いだ。

近年、オープンソースのデータベース製品も機能が向上し、実際のビジネスの現場において活用されるケースも増えてきている。たしかに、Oracle Databaseはサポートのある商用データベースとして、オープンソースの製品と比較すれば初期の導入コストは高くなりがちだという見方もある。しかし、より高い信頼性や可用性を求められるエンタープライズシステムの核としてのポテンシャルや、長期的な運用管理コストを削減するための機能の充実は、それに十分に見合うものだと考えることもできるだろう。

さらに、Oracle Database 12cの最大の特長である「マルチテナント・アーキテクチャ」は、システム統合という企業ITのトレンドの中で、今後の主流となっていくであろう「データベースクラウド」「DBaaS」の基盤となり得る先進的な機能である。

Oracle Database 12cは、Oracle Technology Networkからその評価版を無償で利用することも可能になっている。もし少しでも興味を持ったのであれば、ぜひOracle Technology Networkのチュートリアル記事と一緒にダウンロードして、さまざまな新機能を実際に手元で体験してみてほしい。

(参考URL) Oracle Database 12c:
http://www.oracle.com/technetwork/jp/database/enterprise-edition/downloads/index.html 製品マニュアル:
http://www.oracle.com/technetwork/jp/database/enterprise-edition/documentation/index.html