ユーザーの意見をトコトン反映した12c R2のマルチテナント

Oracle Database 12c R2（以下12c R2）はクラウドファーストのデータベースとして、Oracle Cloud Platform上で先行リリースされています。12c R2には300を超える新機能が実装されており、なかでもマルチテナントはOracle Database 12c R1（以下12c R1）と比べて格段に進化しています。いずれやってくる12c R2へのバージョンアップに備えて、マルチテナントがどこまで進化したのかを押さえておきましょう。

マルチテナント（Oracle Multitenant）は12c R1から提供されている機能です。データベースの中にデータベースを作ることができ、統合・集約を加速させる新しい手段として登場しました。最大の特長は集約率の高さで、H/W、OS、DBMSを共有するためリソースに無駄がなく、単一のインフラ上で多くのデータベースを稼働させることができます。

※以下の記事で詳細なアーキテクチャを解説していますので、併せてご参照ください。

・クラウド時代の新しいアーキテクチャ、Oracle Database 12cのマルチテナント機能
・12cのマルチテナントは本当に“使える”機能なのか？ (前編）
・12cのマルチテナントは本当に“使える”機能なのか？（後編）

まさに12cの“c”が示すとおりクラウドを意識した機能と言えますが、いち技術者として見る限り、国内市場への浸透はまだ道半ばという印象です。アーキテクチャが変われば運用も変わるので、慎重に時間をかけて評価するというケースがほとんどではないでしょうか。データベースのメジャーバージョンアップはそれだけで一大プロジェクトです。できるだけ変更要素を減らしてリスクを抑えるという判断が働くのも当然と言えます。

また、12c R1のマルチテナントを検証すると機能的な課題にぶつかることがあります。検証プログラムや技術者同士のディスカッションに参加した際、よく聞こえてきた課題が以下の4つです。

結論から言うと、これらの課題は12c R2ですべて解決できます。12c R2のマルチテナントはユーザーの意見を取り入れた機能改善が多く行われており、12c R1とは違った評価を得られるだけの魅力が備わっています。今回はマルチテナントの進化をいくつかのポイントに分けてご紹介します。

マルチテナントは、単一のインフラ上で高密度のデータベース統合を実現する機能です。そのため、CPUやメモリ、ストレージといった限られたリソースをPDB間でどう制御していくかが鍵になります。

リソース制御については12c R1の時点である程度機能が備わっており、PDBごとにCPUとI/O^※1を制御できます。ただし、メモリについてはPDBごとに制御できず、全PDBで1つのSGA（System Global Area）を共有しています。リソースの無駄をなくして集約率を高める仕組みになっているのですが、以下のように高負荷なPDBがSGAを占有すると、他のPDBに影響を与える可能性があります。

※1 12c R1のI/O制御はExadata環境でのみ可能

12c R2のマルチテナントではPDBごとにメモリ関連のパラメータを設定することができるようになりました。SGA_MIN_SIZEというパラメータが新しく追加され、これを設定しておけばPDBに割り当てられる最低限のSGAを保証できます。また、PDBにSGA_TARGETを設定するとそれがSGAの上限値になるので、他のPDBに影響を与えずに済みます。

このように、12c R2ではPDBごとにきめ細かくメモリを制御できます。PDBの独立性が高まり、より安全に統合・集約を進められるようになったと言えるでしょう。ただし、パラメータの設定は慎重に行う必要があります。例えば、SGA_MIN_SIZEを必要以上に高く設定すると集約率が落ちてしまいます。最初からすべてのPDBを対象とせず、必要なPDBに絞ってパラメータを設定することをお薦めします。

参考までにOracle社が提供するクラウドサービスであるExadata Express Cloud Serviceのパラメータを覗いてみましょう。Exadata Express Cloud Serviceは、マルチテナントのPDBだけを提供するPaaSです。つまり、1つのCDBを独占して利用するのではなく、複数のユーザーで共有しているのです。

※2 X20という最小のプランを選択した場合の値です

パラメータを見ると、SGA_TARGETは設定されていますがSGA_MIN_SIZEは0になっています。つまり、上限だけが設定されている状態です。クラウドサービスのように集約率を重視する場合、こうした設定にしておくとリソースの無駄がありません。Exadata Express Cloud Serviceは月額\21,000という低価格で提供されているのですが、もしかしたらこのあたりに安さの秘訣があるのかもしれません。

マルチテナントには統合・集約以外にもう一つ大きな特長があります。それはPDBの可搬性です。PDBのPはプラガブルの略で、日本語にすると着脱可能という意味になります。PDBはそれ自体にデータを含んでいるので、別のCDBにクローンを作成したり、移動したりといった操作を簡単に行うことができるのです。

12c R2では、この可搬性が更に強化されました。その象徴とも言えるのが、PDBのホットクローンとリフレッシュです。ホットクローンは、その名のとおりオンラインでPDBのクローンを作成できる機能です。12c R1ではPDBを読み取り専用でオープンしなければいけませんでしたが、12c R2ではその必要がありません。書き込み可能な状態でクローンを作成できます。例えば、以下のように本番環境を止めずに検証環境にデータを持っていきたい場合に便利です。

この時、裏側ではデータファイルの読み取りとコピーが並列で実行されています。しかし、本番環境のPDBはクローン中も更新され続けるため、このままではデータの差異が生じてしまいます。この問題を防ぐために、PDBのホットクローンでは内部的にREDOの転送と適用を行っています。もともとOracle Databaseが持つリカバリ技術を応用したもので、最終的にはホットクローンが終了した時点（SCN）までのデータがクローン先のPDBに含まれます。

これでホットクローンの処理は終了となり、本番環境と同じデータを持ったPDBが利用できます。ある一時点のデータをクローンしたい場合はこれで十分ですが、なかには本番環境のデータを定期的に取り込みたいというケースもあるでしょう。12c R2では、一度複製したPDBに対してリフレッシュを行うことで、差分データを同期することができるのです。

リフレッシュでは、ホットクローンと同じようにREDOの転送と適用を行っているため、大きな負荷はかかりません。差分データのみを同期するので、最初からクローンをやり直すよりも遥かに効率的なため、処理時間を大幅に短縮できます。また、コマンド1つで操作できるので、実装も簡単です。

リフレッシュには手動と自動の2種類があり、自動にしておけば最短1分間隔でデータを同期できます。1分は少し極端ですが、定期的にリフレッシュを実行しておけば、常に新しいデータを使って検証・開発を行うことができます。マルチテナントを単なる統合・集約の手段と捉えるのはもったいないので、こうしたプラガブルな仕組みを活用できないか一度検証してみることをお薦めします。

最後に紹介するのはアプリケーション・コンテナという新機能です。マルチテナントはクラウドを強く意識したアーキテクチャになっていますが、12c R1にはアプリケーションから見た時にいくつか課題がありました。例えば、以下のようにSaaSのバックエンドとしてPDBを顧客ごとに分けて提供しているとします。各PDBは顧客データとアプリケーション用のオブジェクトを保持していますが、後者には顧客固有の要素はありません。結果として各PDBで全く同じオブジェクトを保持することになるので、メンテナンスやアップデートの手間が増えてしまいます。

アプリケーション・コンテナを使うと、アプリケーション・ルートと呼ばれる専用のPDBにオブジェクトのマスター定義を保持できます。アプリケーション用のPL/SQLパッケージや表をここに格納しておけば、全てのPDBでそれを共有することができます。1箇所で集中管理できるため、もしオブジェクトのメンテナンスが発生しても作業は1回で済みます。PDBの数が多いほど恩恵を受けやすく、SaaSなど大規模な環境では欠かせない技術になるでしょう。

今回紹介した以外にも、マルチテナントには多数の新機能が搭載されています。12c R2で一番強化された機能といっても過言ではないので、バージョンアップの際には是非一度検証してみることをお薦めします。マルチテナントの検証には、今回取り上げたExadata Express Cloud ServiceやDatabase Cloud Serviceが便利です。12c R2のデータベースをすぐに手に入れることができ、利用期間に合わせたプランでコストを大きく抑えられます。試使用もできるので、とりあえず触ってみたいという方にもお薦めです。

最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。