TOP>企業情報>コラム>技術情報>ユーザの意見をトコトン反映した12c R2のマルチテナント

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

Oracle Database 12c

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を共有するためリソースに無駄がなく、単一のインフラ上で多くのデータベースを稼働させることができます。

図1:Oracle Databaseのマルチテナント

図1:Oracle Databaseのマルチテナント

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

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

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

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

  • PDBごとにメモリの割当てを制御したい
  • 異なるキャラクタセットのデータベースを統合したい
  • データベースを止めずにクローンやUnplug/Plugなどの操作を実施したい
  • 各PDBで共通して使うデータを一元管理したい

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

PDBごとのメモリ管理


マルチテナントは、単一のインフラ上で高密度のデータベース統合を実現する機能です。そのため、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環境でのみ可能

図2:12c R1までのメモリ制御

図2:12c R1までのメモリ制御

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

図3:12c R2のメモリ制御

図3:12c R2のメモリ制御


初期化パラメータ 説明
表1:PDBごとに設定できる初期化パラメータ
SGA_TARGET PDBのSGA最大サイズ
(CDBのSGAに空きがあっても上限突破しない)
SGA_MIN_SIZE PDBに保証されるSGAのサイズ
(SGA_TARGETの50%以下に設定)
DB_CACHE_SIZE PDBに保証されるバッファキャッシュのサイズ
SHARED_POOL_SIZE PDBに保証される共有プールのサイズ
PGA_AGGREGATE_LIMIT PDBのPGA最大サイズ
PGA_AGGREGATE_TARGET PDBのPGAターゲットサイズ

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

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

図4:Exadata Express Cloud Serviceのアーキテクチャ

図4:Exadata Express Cloud Serviceのアーキテクチャ


初期化パラメータ 設定値※2
表2:Exadata Express Cloud Serviceの初期化パラメータ
SGA_TARGET 3G
SGA_MIN_SIZE 0
PGA_AGGREGATE_LIMIT 3G
PGA_AGGREGATE_TARGET 1500M

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

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

PDBのホットクローン、リフレッシュ


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

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

図5:PDBのホットクローン

図5:PDBのホットクローン

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

図6:ホットクローンの内部動作

図6:ホットクローンの内部動作

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

図7:PDBのリフレッシュ

図7:PDBのリフレッシュ

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

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

アプリケーション・コンテナ


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

図8:アプリケーション観点で見たマルチテナントの課題

図8:アプリケーション観点で見たマルチテナントの課題

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

図9:アプリケーション・コンテナ

図9:アプリケーション・コンテナ

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


執筆者紹介

関 俊洋

関 俊洋(Toshihiro Seki)

株式会社アシスト データベース技術本部

2006年、株式会社アシスト入社。データベース・システムの構築や運用トラブルの解決といったフィールド・サポート業務を経験し、その後は新製品の検証やハードウェアとデータベースを組み合わせたソリューション(DODAI)の立ち上げに従事。現在はデータベースの価値や魅力を伝えるための執筆・講演活動を行っている。『SQL逆引き大全363の極意』共著。

関の紹介記事はこちら


Facebookで情報をお届けしています

Facebookでは、アシストの「今」を週3回のペースでお届けしています。「めげない、逃げない、あまり儲けない」を合言葉に日々頑張っておりますので、応援よろしくお願いします。



ページの先頭へ戻る