記事一覧へ戻る

掲載元 2014年3/4月

テクノロジー：Ask Tom

Oracle Database 12cについて：パート4

オラクルの技術者がオラクル製品管理担当とともに、Oracle Database 12cとOracle Multitenantオプションについて話します。

Ask Tomの各コラムでは通常、過去2か月の間にユーザーが投稿した質問を3つか4つ取り上げて、それらの質問と回答を紹介しています。しかし、過去3回と今回のコラムでは、Oracle Database 12cの重要な機能のいくつかについて説明します。これらの重要な機能はすべて、2012年にサンフランシスコで開催されたOracle OpenWorldで筆者が行ったプレゼンテーション"12 Things About Oracle Database 12c"で取り上げたものです（このプレゼンテーションのスライドは、asktom.oracle.comのFilesタブで公開しています）。1回目のコラムでは、Oracle Database 12cの最初の3つの機能（改善されたデフォルト値、大きなデータ型、上位Nの問合せ）について説明しました。2回目のコラムでは、新しい行パターン・マッチングについて説明し、一時表のUNDOがOracle Database 12cでどのように変わったかを紹介しました。前回は、パーティション化の改良点、適応型実行計画、統計機能の改良点について取り上げました。

今回は、Oracle Database 12cのナンバー・ワンの新機能について、いつもとは違うアプローチで説明します。これより、Oracle Multitenantオプションのプロダクト・マネージャーであるPatrick Wheelerとの対談をお届けします。いつもとは一風変わったスタイルをお楽しみください。

Kyte：オラクルでの経歴を少し教えてください。

Wheeler：私は1986年にオラクルに入社し、ロンドンやサンフランシスコの大規模な金融機関向けに、コンサルタントやコンサルティング・プラクティス・マネージャーとして働いていました。Oracle CASEの開発に深く関わり、Oracle CASEの全世界向けリリースを担当しました。

その後、1995年にSiebel Systemsに入社し、Founder’s Circleの一員になりました。Siebelでは、データ・アーキテクトや、データ・モデリングのディレクターを務めました。オラクルに戻った今は、Oracle Multitenantオプションの製品管理を担当しています。

Kyte：今日の対談のテーマは、Oracle Multitenantです。これはOracle Database 12cに関して私が紹介している12の機能の1つです。Oracle Multitenantとは何か、簡単に説明してもらえますか。

Wheeler：Oracle Multitenantは、データベースを統合し、クラウドでの操作を簡素化するためのマルチテナント・アーキテクチャを提供する、Oracle Database 12cの新オプションです。すでに本番リリースされ、ご利用いただけます。この新しいアーキテクチャを利用すれば、資本コストと運用コストを削減し、俊敏性を高めることができます。そして、変化への適応も簡単です。

Kyte：2人とも長い間オラクルに勤めてきましたが、Oracleは常に非常に優れたデータベース・システムであり続けました。なぜ、アーキテクチャを変更する必要があったのでしょうか。

Wheeler：ご存じのとおり、ユーザーの要件は常に進化しています。そのためテクノロジーも進化する必要があります。企業は現在、システムを統合し、クラウド・コンピューティングの利点を実現することを求める大きな圧力に直面しています。まず、統合すること、しいては設置床面積、電力コスト、ライセンス・コストを削減することを求める経済面の圧力があります。また、迅速で低コストのセルフサービス・プロビジョニングや、標準化されたサービスの配信など、クラウドベースの俊敏性を得ることを求める運用面での圧力もあります。必要とされているのは、データベースの独立性と、多数のデータベースを1つのものとして管理できることの間で適切なバランスを保つことです。

Kyte：統合の良い面を挙げられましたが、統合自体は新しいことではありません。現在の問題は、統合すべきか否かというよりは、どのように統合すべきかにあると思うのですが。

Wheeler：そのとおりです。企業はこれまで、データベース統合のさまざまなアプローチを試してきました。たとえば、仮想マシンを試した企業もあるでしょう。しかし、VMを使用した場合、物理的なスプロールが仮想スプロールに置き換わり、仮想スプロールでも高い管理コストがかかります。さらに、データベースやOSソフトウェアのオーバーヘッドを各VMにレプリケートすることになり、その結果、統合密度、つまり1台のサーバー内にホスト可能なアプリケーション数が制限されます。

Kyte：そうですね。しかし、1台のサーバーに複数のデータベースを配置すれば、統合密度を高めることができます。

Wheeler：もちろんそうですが、それでも最適な状態ではありません。新しいデータベースを導入するときに、新しい共有メモリ領域を割り当てて、20個程度の新しいバックグラウンド・プロセスのセットを起動する必要があります。新しいデータベースを導入するたびにこの作業を繰り返すと、レプリケートされたプロセスがシステム内の利用可能なリソースをすぐに消費するので、最終的な統合密度が制限されます。

Kyte：Oracle Database 12cより前のバージョンでは、1台の大規模なサーバーと1つの膨大なデータベースを使用した、スキーマ統合アプローチを取るユーザーもいました。このアプローチでは、各アプリケーションの"バックエンド"が1つのスキーマ内にホストされます。通常、このアプローチを成功させるには、アプリケーションを修正する労力が必要でしたが、成功したユーザーは統合による多大な利点を実現してきました。しかしその後、そのような統合の利点と俊敏性の間にトレードオフがあることに気付いています。粒度の細かいコントロールができなくなっているのです。

Wheeler：それらはまさに、Oracleマルチテナント・アーキテクチャを設計する上で私たちのチームが考慮したことです。

Kyte：その新しいマルチテナント・アーキテクチャについて説明してもらえますか。

Wheeler：マルチテナント・アーキテクチャでは、各アプリケーションのバックエンド・データベースがプラガブル・データベース（PDB）になります。このプラガブルという部分が新しいところですが、これまでと変わらないこととして、プラガブル・データベースはフル機能搭載の自己完結型Oracle Databaseインスタンスです。つまり、アプリケーションの観点からは、何も変わっていません。

Kyte：なるほど。それは、新しいデータベース・アーキテクチャを導入するためにアプリケーションの修正をユーザーに求めることは、合理的ではないからですね。

Wheeler：そのとおりです。利用中のデータベースをマルチテナント・アーキテクチャ内のPDBへとアップグレードするために、アプリケーションの変更は一切必要ありません。

Kyte：データベースという部分から話題を移しましょう。プラガブルという部分について説明してもらえますか。

Wheeler：マルチテナント・アーキテクチャでは、ルート・データベースという新しい概念が導入されました。多数の個々のPDBを1つのルートにプラグインでき、それらのPDBが一体となって、マルチテナントのコンテナ・データベース（CDB）を形成します。運用の観点からは、このCDBこそがデータベースです。1つの共有システム・グローバル領域（SGA）と、1つのバックグラウンド・プロセスのセットが、そのCDB内のすべてのPDBによって共有されます。

Kyte：それこそが、マルチテナント・アーキテクチャで優れた統合密度を達成できる理由ですね。たとえば、データベースあたり20個のバックグラウンド・プロセスがあり、30個のデータベースを1台のサーバー内に配置するとすれば、600個のバックグラウンド・プロセスが必要になります。しかし、マルチテナント・アーキテクチャであれば、それら30個のデータベースのそれぞれを1つのCDB内のPDBとして統合できるため、必要になるのは20個のバックグラウンド・プロセスだけです。

Wheeler：そのとおりです。そして、ここで重要になるのはバックグラウンド・プロセスの数だけではありません。その質も重要です。この点を実証するために、私たちのチームはこれまでさまざまな統合スケーラビリティ・テストを実施してきました。先ほどの30個のデータベースの例で、一部のOLTPの負荷が高いと仮定しましょう。すなわち、データベース書込みやログ書込みが大量にあります。データベース・ライター（DBWR）とログ・ライター（LGWR）はともに優先順位が高く、重いプロセスです。個別のデータベースを使用した場合、複数のDBWRプロセスやLGWRプロセスが競合し、追い抜きながらキューの入口に向かうことになります。そのため、L3キャッシュ・ミスが増加することが観測されました。このキャッシュ・ミスの増加が、スケーラビリティを制限する主要因でした。

これに対して、同じ数のPDBを1つのCDBに統合した上で、同じワークロードを実行すると、1つのLGWRのみが動作し、2つのスレーブは静かに快適に稼働していました。

Kyte：Oracle Multitenantはスループットの向上とスケーラビリティの向上を同時に達成するということですね。

Wheeler：まさにそうです。

Kyte：これまでの説明をまとめると、Oracle Multitenantでは、統合されるサーバーあたりのアプリケーション数を増やすことで、資本コストを削減できます。先ほど、運用コストも削減できると言っていましたが、この点についてはどうでしょうか。

Wheeler："データベースとは何か"という単純な質問でも、それぞれの視点によって異なる回答が得られます。アプリケーションの観点からはPDBがデータベースですが、運用の観点からはCDBがデータベースです。

Kyte：つまり、"運用の観点から"と言った場合には、パッチ適用、バックアップ、Oracle Real Application Clusters（Oracle RAC）やOracle Active Data Guardの構成といった一般的なDBAのタスクについてお話されているのでしょうか。

Wheeler：そのとおりです。そして、一般的なユーザーが管理する必要のあるデータベース数を考慮した場合に、これらのタスクは高コストになります。

Kyte：そうですね。多くのユーザーは数百のデータベースを運用し、データベース数が数千に上るユーザーもいます。

Wheeler：それら数百のデータベースを、少数、おそらくは10数個程度のCDBに統合できるようになります。バックアップやパッチ適用をすべき数百のデータベースが、わずか数個のデータベースになるのです。このように多数のデータベースを1つ（または少なくとも数個）のデータベースとして管理できるため、運用コストが大幅に削減されます。

Kyte：これには別の見方もあります。個々のデータベースのすべてに対して、そのようなエラーを起こしやすく時間のかかる面倒な管理作業をDBAが行う必要がなくなります。そのため、一般的には価値を高めてサービスの品質を改善できます。水の上に頭を出して必死に生き延びようとするのではなく、より戦略的に価値を上げることができます。

しかし、"多くのものを1つのものとして管理"できることの利点は分かりますが、現実的には、すべてのデータベースを同じように管理したくないときもあります。この点が、先ほど話題になったスキーマ統合モデルの大きな欠点でした。具体的な例として、パッチ適用を取り上げましょう。スタック全体を見ると、まずサーバーがあり、そのサーバーでOracle Databaseインスタンスが稼働しています。しかし、一番上の層にあるのはアプリケーション層で、しかもユーザーが重視しているアプリケーションです。この場合に、特定のパッチ・レベルの認定が済んでいないアプリケーションがあると、その1つのアプリケーションの準備が整うまで、すべてのアプリケーションのアップグレードを待つ必要があります。この種の現実的な問題が、ユーザーが私に対して不満を示す問題です。

Wheeler：まさに今触れられたことが、Oracle Multitenantのもう1つのテーマです。資本コストと運用コストの削減についてはすでに説明しました。運用コストの削減に対して私が好む表現は、"多くのものを1つのものとして管理するが、粒度の細かいコントロールを適宜行う"というものです。次に説明するテーマは俊敏性です。

Kyte：これまでは一般的に、運用コストの削減と俊敏性の間にトレードオフが存在しました。

Wheeler：Oracle Multitenantにはそのようなトレードオフはありません。いくつかの例を紹介しましょう。

バックアップの場合、CDB全体に対して1つのバックアップを構成できますが、個々のPDBのポイント・イン・タイム・リカバリを実行することもできます。

パッチの場合、データベース・バージョンというのは運用上の考え方であるため、CDBレベルに相当します。パッチをCDBレベルで適用すると、そのCDB内のすべてのPDBが一挙にアップグレードされます。しかし、先ほどの現実的な例に戻れば、このようなアップグレードはかならずしも実用的ではありません。そのような場合は、2つ目のCDBを作成して、そのCDBに対して新しいレベルのパッチを適用します。その後、1つ目のCDB（例：Oracle Database 12c Release 12.1.0.1）から個々のPDBをアンプラグして、2つ目のCDB（例：Release 12.1.0.2）にプラグインすることで、個々のPDBをアップグレードできます。

Kyte：いいですね。重要な点は、アップグレードの準備が整っていないPDBを移行する必要がないことですね。また、おそらくこれは、より速いパッチの適用方法でもあるでしょう。

Wheeler：どちらも正解です。

Kyte：その場合、スキーマ統合での状況よりは確実に改善されます。しかし、クラウドベースの俊敏性について議論される場合に、その対象はパッチ適用やバックアップだけには収まりません。変化するワークフローへの柔軟な適応、品質保証契約（SLA）の変更によるアプリケーションの効率的な移行なども議論されます。これらの分野でOracle Multitenantが実現できることは何でしょうか。

Wheeler：よい質問ですね。実際には、良い質問が2つありました。各質問に順にお答えします。

まず、変化するワークフローへの柔軟な適応について。これは、Oracle RACとの緊密な統合が関わる分野です。Oracle RACの構成は運用タスクです。ということは、Oracle RACでは、クラスタ全体にわたってCDBがオープンされます。これは、"多くのものを1つのものとして管理する"というテーマに沿います。一方、"粒度の細かいコントロールを適宜行う"というテーマに従って、特定のノード（厳密に言えばクラスタのインスタンス）内で、個々のPDBを選択的にオープンすることもできます。このことを、PDBのインスタンスへのアフィニティゼーションと呼んでいます。技術的には、任意のノードで特定のPDBのサービスをオープンすることで、アフィニティゼーションを実現しています。たとえば、業務サイクルのある特定の段階で、クラスタの負荷が非常に高くなっているとします。このとき、PDBのサービスを、負荷の高いノードから負荷の低いノードに移すことで、このようなワークロードの変化に柔軟に適応できます。同様のさまざまなシナリオが簡単に思い浮かぶでしょう。これは本当に今までに例のないような柔軟性です。Oracle MultitenantがOracle RACを良くしているとも、Oracle RACがOracle Multitenantを良くしているとも言えます。

Kyte：2つ目の質問についてはいかがですか。

Wheeler：Oracle Multitenantと、SLAの異なる層での移動について。SLAの層は通常、パフォーマンスや可用性などの事柄を定義しているものであり、多くの場合は、Oracle RACやOracle Active Data Guardなどの具体的なデータベース・オプションの組合せに対応します。すでに説明したとおり、CDBレベルで定義される事柄があります。たとえば、Goldサービスを"Oracle RACとOracle Active Data Guard"、Silverサービスを"Oracle Active Data Guardのみ"と定義できるでしょう。これらは運用上の事柄であるため、各SLAに対応したCDBを作成することになります。ここで、プラガブル・データベースは、移植可能なデータベースです。特定のPDBについてSLAをアップグレード（もしくはダウングレード）したい場合は、単純にそのPDBを現在のCDBからアンプラグして、適切なSLAによって管理されているCDBにプラグインします。

Kyte：これまでの説明から、"多くのものを1つのものとして管理"できるからといって、CDBを1つだけ作成すべきということにはならないと私は理解しましたが。

Wheeler：そのとおりです。10数個のCDBを作成することも簡単です。たとえば、異なるSLA層に対応させる、あるいは、アンプラグ/プラグによってアップグレードするという目的で複数のCDBがあっても、正常に運用できます。

Kyte：すばらしいですね。ところで、ご存じのように私は多くのDBAと話してきました。DBAの苦悩はおもに2つあります。1つ目についてはすでに説明されました。それはパッチ適用です。もう1つは、新しいデータベースのプロビジョニングです。

Wheeler：まさしく苦悩ですね。プロビジョニングについて言及したときに顔を歪める人を探すことで、聞き手の中で誰がDBAなのかが分かります。まじめにお答えすると、Oracle Multitenantでのプロビジョニングについてぜひお伝えしたいことがあります。それはすべて、クローニングと呼ばれる機能に基づいています。ローカル・クローンを（同じCDB内のPDBから）作成することも、リモート・クローンを（データベース・リンク経由でリモートCDBに対して）作成することもできます。KyteさんはSQLの人なので、PDBのクローニングが1行のSQL文で実行できることを気に入るのではないでしょうか。セキュリティ分野の技術者もこの点を気に入ります。OSアクセスは不要で、データベース・アクセスだけが必要になるからです。そして、クローニングは高速であるため、誰もが気に入ります。完全クローンと呼ばれる機能は高速ですが、さらに、桁外れに高速なのがスナップショット・クローンです。スナップショット・クローンは、基盤のファイル・システムのCopy-On-Writeという機能を利用できる場合に、その機能を利用します。

Kyte：Copy-On-Writeは実績と定評のあるテクノロジーです。この機能を利用して、プラガブル・データベースのシン・プロビジョニングを行うということですね。開発環境とテスト環境の生産性が上がることが想像できます。数十人、もしくは数百人のエンジニアが数個の"ゴールド・マスター"データベースをそれぞれ個別にコピーして、それを使用して作業するという状況がよくありますよね。スナップショット・クローニングを使用すれば、ストレージやサーバーの負荷の増分を最小限に抑えて、これらのデータベースをすばやくリフレッシュできます。この操作をセルフサービスで実行できることも想像できます。

Wheeler：クローニングは、Oracle Multitenantの優れたユースケースであり、Oracle Multitenantへの移行を正当化する優れた機能です。当然ながら開発環境とテスト環境は本番環境ではないので、まさに、この新しいテクノロジーを習得してほしいその開発エンジニアとテスト・エンジニアが、日々の業務でこのテクノロジーを利用することになります。先ほど言及されたとおり、隠れた開発コストやテスト・コストがなくなるため、組織の生産性が高まり、仕事の質も上がります。

Kyte：迅速で低コストのデータベース・プロビジョニングは、過去の苦悩に満ちたプロセスからの大きな前進と言えます。新しいデータベースを作成するために、官僚的な手順を処理すると何週間、何か月とかかることもあるのですから。

Wheeler：はい。資本コストと運用コストの削減についてはすでにお話ししました。これらの削減幅は非常に大きなものになりえますが、コスト削減は段階的なものです。数分でデータベースを作成できるようになると、たとえば新しいビジネス・チャンスの非定型分析を行う場合に、チャンスを掴んで最初に市場に投入できるかもしれません。一方、そのデータベースの作成に数週間かかるとすれば、ビジネス・チャンスを逃してしまうことも十分に考えられ、それに思い悩む価値さえもなくなります。迅速なセルフサービス・プロビジョニングについて今話しているのは、程度ではなく質の違いについてです。段階的なコスト削減により最終的に得られる結果ではなく、最初の段階で大幅に高められる可能性について話しているのです。

Kyte：いいですね。プロビジョニングについては積もる話がありますが、Oracle Multitenantには他にも多くのユースケースがあるはずです。いくつかのユースケースを挙げてもらえますか。

Wheeler：分かりました。Oracle Multitenantのアーキテクチャは非常に柔軟です。明らかなユースケースとして、異種アプリケーションの統合、Software as a Service（SaaS）、Database as a Service（DBaaS）、パッケージ化されたアプリケーションやデータの配信などが挙げられます。

Kyte：すべて魅力的に聞こえるのですが、統合についてユーザーと話すと、共有リソースの競合を懸念しているという答えがかならず返ってきます。つまり、どの個別のPDBもシステムの全リソースを独占するような状況にはしたくない、と。

Wheeler：それはもっともな懸念点なのですが、優れたソリューションがあります。CPU、セッション、パラレル実行サーバー、さらにOracle Exadata上のI/Oさえも制御できるように、Oracle DatabaseのResource Manager機能が拡張されました。シェアとキャップという単純かつ強力な概念を利用して、PDB間でのリソースの共有方法を指定したポリシーを簡単に定義できます。

Kyte：優先度の高いシステムには多くのシェアを割り当て、優先度の低いシステムには少ないシェアを割り当てることになるのでしょうか。

Wheeler：はい。さらに、優先度の低いシステムについては、利用できるリソースを制限するためのキャップを適用できます。シェアは、PDBにリソースが必要になる場合の、割り当てるリソースの保証される最小シェアを表します。しかし、リソースが必要でない場合は、他のPDBでそのリソースを利用できます。これはオーバープロビジョニングと呼ばれることがあります。良くないことを表す言葉のように感じられますが、多くの状況でオーバープロビジョニングは良いことで、統合のおもな利点の1つです。

Kyte：特定のCPU数でキャップするインスタンス・ケージングよりもはるかに柔軟ですね。インスタンス・ケージングでは、他のCPUがアイドル状態でも身動きが取れず、アイドル状態のCPUを利用できません。

Oracleのデータベース・アーキテクチャの中で本当に大きく前進したところのように感じます。多くのユーザーがすでに、Oracle Multitenantの導入を始めているか、まもなく導入する予定です。Oracle Multitenantへのアップグレードはどれほど簡単なのでしょうか。

Wheeler：非常に簡単で、1、2の3でできます。ステップ1：通常どおり、データベース・システムをアップグレードします。Oracle Database 10g Release 2、Oracle Database 11g Release 1およびRelease 2からの直接アップグレードがサポートされます。その結果、Oracle Database 12cになりますが、これはいわゆる非CDBで、古いアーキテクチャのままです。

ステップ2：この非CDBをPDBとして導入します。基本的に、これは、事前に作成したCDBにこの非CDBをプラグすることを意味します（CDBは、Oracle Database Configuration Assistantを使用して簡単に作成できます）。

その後、Oracle Multitenantと連携するようにアプリケーションを変更します。でも、待ってください。Oracle Multitenantを導入するためにアプリケーションの変更は必要ありません。

Kyte：つまり、ステップ3はないということでしょうか。

Wheeler：そう、ステップ3はありません。

Kyte：Oracleのデータベース・アーキテクチャの中で特に大きく前進したところですね。その利点のいくつかについては、ここで詳しくお話ししましたが、最後に利点についてまとめていただけますか。

Wheeler：Oracle Multitenantを使用することで、次のことが可能になります。

• 対応可能なサーバーあたりのアプリケーション数の増加によって、資本コストを削減

• 多くのデータベースを1つのものとして管理し、標準化されたサービスを配信することで（セルフサービスとしての配信も可能）、運用コストを削減

• 迅速な低コストのプロビジョニングと"プラガブルな移植性"によって俊敏性が向上

• この新しいアーキテクチャを容易に導入可能 

   

▲ ページTOPに戻る

記事一覧へ戻る