会社情報

1. データベース統合のあれこれ

これまでデータベース・システムはその重要性から、負荷分散やシステムごとの影響度を極小化するために個別に構築することが主流でした。しかし、これがシステムをサイロ化させ、データベースの散在を招く結果となっています。リーマン・ショック以降、厳しい経済環境が続く中で、各企業におけるITコスト削減の動きはシステム基盤であるデータベース層も例外ではありません。管理コストの削減、メンテナンス性の向上などを目指してデータベース統合を検討する事案も増加しています。一方で、データベース統合については、「難易度が高く統合にかかるコストも馬鹿にならない」という声も少なくありません。

データベース統合と一口に言っても手法は様々ですが、大別すると「物理サーバ統合」、「物理データベース統合」、「論理データベース統合」に分けられます。データベース・システムにおける「物理サーバ統合」は、「複数の物理的なデータベース・サーバを集約する」手法です。サーバ仮想化などと組み合わせて、物理的なサーバ集約を目指しますが、データベースそのものには、手を加えません。

「物理データベース統合」では、1つのデータベースに集約しますが、データの整理などは必要最低限にとどめるため、場合によっては重複データが存在した状態での統合となるケースもあります。

「論理データベース統合」は、複数あるデータベース・システムのデータを整理して、1つのデータベースへ統合することです。「論理データベース統合」には、データ・モデルの見直しやマスタ・データの再設計も含まれます。これが成功すれば、物理的なサーバ台数などが削減できるのはもちろんのこと、マスタ・データも整理されるため、保持するデータ量の削減や業務オペレーションの統合などによる人的なコスト削減効果も期待できます。ただ、見込めるコスト削減効果は大きいのですが、「論理データベース統合」に必要なデータ・モデルの見直し等の作業には多大な時間と労力がかかることが多く、なかなか実践に踏み出せないお客様が多いのが現状ではないかと思います。

2. ステップ・バイ・ステップ データベース統合

データベース統合の理想形は、マスタ・データを整理／統合して、データベース処理に関する運用（オペレーションなども含む）を統一していくことですが、一足飛びに実施することは非常に困難です。そこで、図1に示した統合手法を、実践難易度の低いものからステップに分けて進めていくことを考えてみたいと思います。

■ ステップ1：「物理サーバ統合」

データベース・システム以外でも行われていることであり、おなじみの手法かも知れません。物理的なハードウェア数を減らすことによって、コスト削減やリスク軽減を目指します。なお、次のステップへの布石として、「プラットフォームの統一」や「ソフトウェア・バージョンの統一」なども「ハードウェアの集約」時に意識する必要のある項目です。手法としては、サーバ仮想化や物理サーバ上への単純な集約などが考えられます。このステップでは、集約のための基盤を検討することがメインの作業となります。データベースについては、「そのまま」既存のものに極力手を加えずに移行して、同じサーバで複数データベースを稼働させる手法を採ることになります。このステップでの効果としては、物理的なハードウェアの管理コストやソフトウェアのライセンス・コストの削減が期待できます。ただ、システムの観点では、データベース数の削減にはならないため、管理対象の削減には至りません。

■ ステップ2：「物理データベース統合」

ステップ1では、いったんサーバ集約を行いましたが、その後、折を見ながら1つのデータベースにまとめていく手法を想定します。

具体的な手法としては、図2のようにシステムごとにデータベース・スキーマとして1つのデータベースに集約していくのが一般的です。
最終的に1つのデータベースにまとめることができれば、管理対象が減るため、運用管理コストの削減が見込めます。


■ ステップ3：「論理データベース統合」

論理データベース統合では、業務オペレーションなどを再確認して、マスタ・データの整理に挑んでいくことになります。非常に難易度の高い作業となりますが、実現できれば、コスト削減とともにデータ品質の向上や業務プロセスの最適化なども期待できます。

上述のようなステップ・バイ・ステップで統合に取り組む方法は、特に目新しい内容ではなく、これまでも一般的に検討されてきたものだと思います。しかし、これらの方法を採ってもなかなかうまく進められないといった声を聞きます。

3. 従来の手法とその問題点

データベース統合を困難にしている要素は何なのでしょうか。筆者は、各ステップでの実現手法や技術の課題と、次のステップを見据えた手法選択の困難さが原因ではないかと考えます。各ステップでの実現技術の課題について例を挙げてみます。

ステップ1において、1つのサーバ上に複数のデータベース・インスタンスを稼働させるという手法は古くからあります。しかし、この手法では各インスタンスの重要度と関連付けてサーバ・リソースを制御することができません。そのため、1つのインスタンスへの過剰負荷が他のインスタンスにも影響を与えてしまうなどの問題が考えられます。

またステップ1では、物理サーバ層をサーバ仮想化製品で集約し、サーバ・リソースを仮想マシンの単位で独立性を保ちつつ制御するという手法を採用するケースも増えてきました。
サーバ仮想化とは、1台のサーバ上で複数サーバが稼働しているかのような環境を提供する技術で、VMwareやOracle VMをはじめとする仮想化ソフトウェアが存在します。サーバ仮想化のメリットはその高い移植性です。仮想環境に移植前の環境を再現することで、システムへの修正を最小限に抑えつつ、統合のための環境移行が行えます。また、いったん仮想環境に移行してしまえば、サーバ・リプレースの際などにもカプセル化された仮想環境イメージを新しいサーバへコピーするだけで移行できるため、ポータビリティの高い環境を構築できます。

一見すると、サーバ仮想化による統合は、リソース制御の課題をクリアできるように見えますが、以前の当誌の記事（『アシスト』2009年春号（No.01）：安易な「サーバ仮想化」の導入ではコスト削減は、期待できない）で指摘しているように、サーバ仮想化製品で広く採用されているハイパーバイザーによる仕組みがボトルネックとなるケースを想定する必要があります。ハイパーバイザー型のサーバ仮想化製品では、ディスクI/Oなどのハードウェア操作のための特権命令をハイパーバイザーが処理します。複数の仮想マシンから特権命令が多発された場合、ハイパーバイザーへの負荷が集中し、ボトルネックとなる可能性があります。
また、サーバ仮想化製品を利用する際には、複数仮想マシン・イメージを保持するための大容量で高性能な外付けストレージが必要です。とりわけ前述のとおり、I/O性能を要求されるデータベース・システムへの採用時にはストレージ・コストが増加しがちになり、コスト削減の妨げになることもあります。

他にも、サポート面でサーバ仮想化製品とデータベースの問題切り分けが困難であるケースが多いことや、仮想マシン単位で移植できることから「プラットフォームの統一」が後回しになり、いざ「物理データベース統合」を行おうとすると、プラットフォームの壁が立ちはだかる、といったケースも起こり得ます。

これらの課題を踏まえると、複数インスタンス稼働時の柔軟なリソース制御や次のステップでの構成変更に柔軟に対応できるデータベース・インフラ基盤（以下、共通基盤）が解決の糸口となりそうです。

4. 共通基盤としてのRAC One Node

11g R2の新機能であるReal ApplicationClusters One Node（以下、RAC One Node）は、この課題を解決する可能性を秘めているのではないかと考えます。RAC One Nodeは、RAC^※１のクラスタ技術を利用したシングル構成のデータベース環境を提供します。RAC One Nodeでは、データベース・インスタンスの仮想化を行い、柔軟にサーバ間（サーバ・プール間）の移動を行う機能を提供します。
また、インスタンス単位でサーバ・リソースの制御が行えるため、異なる複数のデータベースを重要度に応じたリソース割り当てで同時に稼働させることもできます。複数データベースを共通基盤上で同時に稼働できるメリットは、複数ある統合対象のデータベースを段階的に移行しても、すでに移行済みのデータベースへの影響を極小化できるところです。この機能により、ステップ1の物理サーバ統合によるデータベースの集約が容易になります。

RAC One Nodeでは、サーバ・プール内で柔軟にデータベース・インスタンスを移動させることができます。そこでステップ2において、他のインスタンスに影響を与えないために、物理データベース統合用のインスタンスを新規に作成し、サーバ・プール内の負荷の低いサーバへそのインスタンスを移動させて移行作業の負荷を分散する、といったことも可能です。データベース・インスタンスを1箇所に集約したことで、発生するデータ移行作業等によるサーバへの負荷の集中という課題にも対応できるということです。RACの技術を応用しているため、サーバ追加（サーバ・プールの拡張）も容易に行え、将来的にマルチノードがActiveなRACに機能拡張することも可能です^※２。統合用の共通基盤として必要な要素をRDBMSとして持っていると言えます。

サーバ仮想化製品での実装と異なり、ハイパーバイザーのオーバーヘッドがないこともデータベース統合用の共通基盤として適合しやすい技術です。

5. まとめ

柔軟かつ堅牢な共通基盤はデータベース統合を進めていくにあたって必要不可欠です。しかし、共通基盤に求められる要件を満たそうとするとハードウェアなどの設備投資コストがかさみます。サーバ・リソースを有効活用できるRAC One Nodeを活用することによって、コストを抑えつつ要件を満たした共通基盤の構築が可能になります。これまでにありそうでなかった新たな技術として、RACOne Nodeをデータベース統合時の選択肢の1つに加えてはいかがでしょうか。



＜脚注＞

※1		RACとは、1つのデータベースを複数サーバ上のインスタンスから管理するクラスタ・データベース構成を実現するOracle Databaseの拡張機能。従来のAcitve/Standby型ではなく、Active/Active型のクラスタ・データベース環境を提供し、高可用性と負荷分散による高いパフォーマンスを実現します。
※2		ライセンスの差額購入が必要となります。