データベースの運用を意識したプライベートクラウド構築のアプローチはCAPEXだけでなくOPEXも削減する：データベース運用管理をクラウド化する方法（1）（2/4 ページ）

「社内に散在するデータベースを整理／統合し、運用管理が容易でスピーディに使える統合データベース基盤を作りたい」という企業に適したRDBMSが「Oracle Database 12c」だ。本企画では3回にわたり、同RDBMSを用いたプライベートクラウド構築のポイント、関連ツールを用いた実践ノウハウを紹介していく。[プライベートクラウド/データベース統合][運用管理効率化][パフォーマンス改善][Oracle Database 12c][Oracle Enterprise Manager]

[PR／＠IT]

プライベートクラウド構築の勘所

　PaaSのレイヤーまで標準化／仮想化の対象にしてプライベートクラウドを構築する際には、下図に示すように幾つか留意すべきことがある。

　この中でも重要なのが、「データベースとアプリケーションは分けて考える」ことだ。それぞれが動作するデータベースサーバーとアプリケーションサーバーでは、性能や可用性を担保するアーキテクチャの実装方法が異なる。それらを一つのプラットフォーム上に無理に集約して要件を満たそうとすると、破綻してしまう場合が多いのだ。また、ミドルウエアのライセンス料や運用管理業務の観点からも、アプリケーションとデータベースは分離し、データベースについては、それに特化したプラットフォームを作るのが最適であろう。

　もう一つの重要なポイントは、「データベースのサービスレベル（SLA：Service Level Agreement）と依存関係を整理する」ことである。本番環境と開発環境、あるいは勘定系と情報系など、異なる環境で運用されているデータベースをひとまとめに考えてしまうと、要件の整理が難しくなるのはもちろん、データベースの集約／統合にも支障を来す可能性がある。多数のデータベースを運用している場合は、それらをサービスレベルや依存関係の観点で整理して考えるようにしたい。

　加えて「ユーザーの観点に立ってプライベートクラウド基盤のアーキテクチャを考える」ということも強調しておきたい。すなわち、「プライベートクラウドを利用するユーザー部門やグループ企業がどのようなサービスを求めているのか」という視点から出発してアーキテクチャを考えるのである。プライベートクラウドの構築において、IT部門はしばしば「統合するのはIaaSとPaaSのレイヤーのどちらか」「どの仮想化技術を使うか」といったインフラ／技術の観点に偏りがちとなるが、プライベートクラウドを利用するユーザー側がどう使うのかを「サービス視点」で考慮することが肝要である。

先行事例から学ぶ、プライベートクラウド構築のベストプラクティス

　それでは、具体的にどのようなアプローチでプライベートクラウドを構築し、散在するデータベースの集約／統合を進めていけばよいのか。これについて考える上で参考になるのが、ある金融機関の事例だ。

　この金融機関では、初めに「それぞれのデータベースで使われている技術」と「データベース間の依存関係」を整理した。その目的の一つは、各データベースの移行順序を決めることだ。

　例えば、オープンな技術を使い、依存関係がシンプルなデータベースは移行しやすく、逆にメインフレームなどのように非オープンな技術で作られ、依存関係が複雑なデータベースを標準化したプラットフォームに移行するのは容易ではないだろう。このように、それぞれのデータベースを分類した上で、移行が容易なものから手を付けていくわけである。

　移行が難しいデータベースから着手すれば、難易度が高まりコスト負担も大きくなることから、移行プロジェクトの失敗、ひいてはプライベートクラウド構築プロジェクトの失敗につながる可能性が高くなる。一方、移行しやすいデータベースから着手すれば、ノウハウを蓄積しながらある程度の成果を出したところで、余裕を持って難易度の高いデータベースの移行に取り組める。実際にこのように作業を進めることで、この金融機関はスムーズな移行を果たすことができた。

　もう一つ注目すべきポイントは、プライベートクラウドで提供するITサービスのレベルを3段階で定義し、それに各システムにマッピングすることである。具体的には、「システムの重要度」「RTO（Recovery Time Objective）／RPO（Recovery Point Objective）」「セキュリティレベル」「データのバックアップ取得間隔」などに応じて「Silver」「Gold」「Platinum」のサービスレベルを設定する。

　サービスレベルを定義したら、次に行うのは「各サービスレベルを実現するためのアーキテクチャの検討」である。例えば、Silverであれば単純な「Oracle Real Application Clusters（RAC）」によるクラスター構成、Goldならば「Oracle Data Guard」を使った同一サイト内でのバックアップ機能を付加、Platinumでは「Oracle Active Data Guard」を使った遠隔地へのバックアップを可能にするといった具合だ。そして、各システムの要件を洗い出し、どのサービスレベルを適用するかを検討するといった流れでプロジェクトを進める。使用する技術やアーキテクチャから考えるのではなく、まず求められるサービスレベルを明らかにした上で、それを満たすアーキテクチャを後から当てはめて進めていくことが、プライベートクラウド構築のベストなアプローチとなる。