技術ブログ
個人ドメインでのブログ http://www.csus4.net/d/2014/02/21/jpuog_tech_talk_night_4/ にも書きましたが、3月11日(火) 19:00 に「JPOUG Tech Talk Night #4」が行われます。
JPOUG Tech Talk Night #4では、LTに加えてOracle Database 12c座談会を予定しています。で、12cの目玉と言えばマルチテナント アーキテクチャ。ということで、マルチテナントについての雑感をつれづれ書いてみますね。
Oracle Database 12c マルチテナントアーキテクチャについては、すでに多くの資料が 世の中に出ています。
まず最初は、となると、OTNのOracle Multitenantページを見るべきでしょうか。 このページにホワイトペーパーが掲載されています。
ホワイトペーパーのExecutive Overviewにマルチテナント 5つの利点がまとめられています。 これは、OTNのOracle Multitenantページに掲載されているものと同じですね。
それぞれについて、自分なりにコメントしてみます。
"高密度の統合"とは、他の手法であれば、1つのマシンに3つのデータベースしか統合できなかったところを、マルチテナントを使用することで3つよりも多い数のデータベースを統合できる ことを示します。
OTNページには、「メモリやバックグラウンド・プロセスを共有」することにより、 リソースの使用量を抑えることにより、これを実現できると書かれています。
結論から言えば、私も、12cのマルチテナントにより"高密度の統合"が実現できると考えていますが、理由はちょっと違います。「不要な予備リソース」をなくせることがおおきな理由であると考えています。（著名なビジネス書籍 「ザ・ゴール ― 企業の究極の目的とは何か」で知られる制約理論での「バッファ」をなくすイメージに近いです。）
そもそも、統合対象とするデータベースは、実質的なリソースの使用率が高くないもの、または、性能要件がさほど厳しくないものだと思います。平たく言えば、あまり取扱いに注意が必要ないデータベースと言えるでしょうか。ただ、実際にはそれにもかかわらず、導入時点では万が一問題が発生しないよう、十分すぎるほどのリソースを割り当てていたりします。で、導入後、問題が発生しないことが確認されたら・・・・、割り当てているリソースを減らす？？？ そんなことはしないし、なかなか難しいですよね。統合は、このような「不要な予備リソース」を削減できるチャンスと考えることができます。
しかしながら、マルチテナント以外の統合方法である、仮想化を用いた統合、インスタンスベースの統合では、このような不要な予備リソースを取り除く方向に向かいません。（参考資料：【セミナー動画/資料】ここから始めるデータベース統合 (オラクルエンジニア通信 - 技術資料、マニュアル、セミナー)） 仮想化を用いた統合を例にとると、統合前のマシン(３台)の物理メモリサイズが8GBであった場合、統合後も各VMの8GBのメモリを割り当てる形になります。もちろんハイパーバイザのオーバーコミットを使用すれば実際の物理メモリよりも大きなサイズのメモリをVMに割り当ててて、不要な予備リソースの割り当てを回避できますが、データベースサーバに対してハイパーバイザのオーバーコミットを使用することはちょっと躊躇するのではないでしょうか。 また、インスタンスベースの統合でも、同様のことが言えます。統合前のインスタンス（３インスタンス）のSGA+PGAのサイズが4GBであった場合、統合後もインスタンスに4GBを割り当てるはずです。
マルチテナントを用いた統合は、統合前後でリソースの扱いが全く異なるため、「不要な予備リソース」をなくすための良い機会になるのではと考えています。 もちろん、スキーマベースの統合でも同様のことが言えます。ただ、スキーマベースの統合は統合によって生じる（旧）データベース同士の結合度合いが密になりすぎるのが問題です。また、統合にも十分な準備が必要で、この作業自体にコストが生じあるため、コストを削減したいので統合したいという気持ちにマッチしないところがあります。
"SQLによる迅速なプロビジョニングとクローニング" とは、端的には
CREATE PLUGGABLE DATABASE pdb1 USING 'xml_file';
にて既存のPDBをCDBに簡単に配置できること、
CREATE PLUGGABLE DATABASE pdb2 FROM pdb SNAPSHOT COPY ... ;
で既存のPDBを簡単にクローンできることを指しています。
これらが有効に機能するのはどのような状況でしょうか？
まず、プロビジョニングについては、PDBの配置先となるマシンを変更したいようなケースが考えられます。例えば、運用中に配置先マシンを変更したり、開発から本番運用に移るタイミングで、本番マシンにPDBを配置するなどです。ただ、これらについてはさほど頻繁におこるものではないので、手順の簡単さのみで有効性をアピールするのはちょっと厳しいかなという印象を持っています。
次に、クローニングについては、本番環境のデータ（データベース）を元に、テスト環境、開発環境のデータベースを作成するケースが考えれられます。これには一定のメリットがありそうですが、その反面、セキュリティなどの理由で全ての環境においてご利益が得られるかというと微妙な気がします。
"高速のパッチ適用とアップグレードの新たなパラダイム" とは、 CDBにパッチを適用すれば、CDB内のすべてのPDBにパッチが適用できること、 また、パッチ適用済みのCDBにPDBをplugすれば、PDBにパッチを適用したことになることを示しています。
これはかなり便利な機能です。セキュリティパッチを多数のデータベースに何度も何度も適用する状況を想像すれば、この機能のありがたみがわかると思います。
その反面、データベースごとに適用するパッチを変えたい状況、変えざるを得ない状況には向きません。つまり、いい意味で適用対象のパッチに関して、あまり細かく気にしない！という思い切りが必要になります。そもそも、適応するパッチをデータベースごとに変えるようなヘテロな状況と、管理容易性はトレードオフの関係にありますので、トレードオフの関係にあることをきちんと見据え、全体最適の観点でどのやり方が合理的なのか？を判断出来る必要があるとも言えます。すなわち、データベースを取り巻く、IT環境に関する適切な意思決定ができないと、この機能を適切利用できないとも言えるかもしれません。
"多数のデータベースを一元管理"とは、統合前であればデータベースごとに個別に実施する必要があった 管理作業やセキュリティや高可用性構成などの各種改善作業を、CDBだけに実行すればよくなることを示します。
この利点が、最も広い範囲において、効果を把握しやすいメリットをもたらすものではないかと考えています。企業に存在するデータベースは様々です。若干語弊がある表現ですが、多少性能が落ちても、多少止まってもさほど大きな問題とならないデータベースもあるはずです。ただし、そのようなデータベースであってもバックアップやセキュリティパッチ適用などの重要な管理作業は必ず行わなくてはならない。しかも、全てのデータベースに対して、１つずつ実施しなければならないのです。
しかし、マルチテナントでデータベースを統合すれば、作業は１つのデータベースに対して実施すればよくなります。
類似した論点が以下の記事でも触れられています。
"プラガブル・データベース間での動的なリソース管理"とは、CDBレベルとPDBレベルでリソースマネージャ機能によるリソース管理を適用できるようになったことを示します。
基本的には既存のリソースマネージャ機能を引き継いでいるため、既存のリソースマネージャ機能の制限もそのままです。また、インスタンスを共有するというマルチテナントの特性上、メモリについては、リソース制御の対象になりません。
類似した論点が、以下の記事でも触れられています。
と、オラクルが考えるマルチテナントの利点について、自分なりの判断を持ってつれづれ書いてみました。 これらが、JPOUG Tech Talk Night #4の12c座談会の肴になれば、うれしいなと思っています。ではでは。
プロフィール
渡部 亮太
・Oracle ACE
・AWS Certified Solutions Architect - Associate
・ORACLE MASTER Platinum Oracle Database 11g, 12c 他多数
カテゴリー
アーカイブ
2024年
2023年
2022年
2021年
2020年
2019年
2018年
2017年
2016年
2015年
2014年
2013年
2012年
2000年