クラウドのためのデータベース「Oracle Database 12c」で運用がどう変わる？：データベースはシステムをどう変えるか？ Oracle Database 12c（1）
ITインフラ周辺の技術革新が進む中、「データベースの機能だけでシステムや運用の差別化は望めない」「高い要求レベルのシステム以外であれば、データベースはどれも同じ」といった声が聞かれるようになってきた。そんな渦中でオラクルは、Oracle Database 12cを市場投入した。この製品は久々に我々をわくわくさせる仕掛けを持っての登場となるようだ。オラクルの提案する新しいデータベースで運用管理はどう変わっていくのか。[プライベートクラウド/データベース統合][運用管理効率化][Engineered System][Oracle Enterprise Manager]
Oracle Database 12c（以下、12c）がついにリリースされた。既に2012年のOracle OpenWorldで告知されているとおり、12cはマルチテナント対応のデータベースだ。マルチテナント・コンテナ・データベースと呼ばれる新しい形式のデータベース上で複数のプラガブル・データベースと呼ばれる仮想的なデータベースを持つマルチテナント構成が可能であることや、マルチテナント・アーキテクチャによるデータベース集約の効果などに注目が集まっている。
とはいえ、既存Oracle ユーザーにとって、それは移行するに値する魅力的なものなのだろうか？ 大方の読者は、バージョンアップは必要だと感じていても、システムのダウンタイムや移行に際してのトラブルは避けたいという意識が働くのではないだろうか。
例えば、サーバ仮想化技術を使ってサーバリソース集約を進めるだけであれば、既にVMwareなどを使って実施中というところも多いだろう。管理にしても、サーバ自体の管理は仮想化ツールに付属する管理ツールで実施しているし、データベース単体については既存の管理ツールで十分と考えている向きもあるだろう。
オラクルとしても、そうしたユーザー側の動向に関心がないわけではない。12cをローンチしたのは、こうした市場に対して、12cが十分にインパクトを与えられると判断したからだ。
「12cのキーテクノロジの1つである“マルチテナント・アーキテクチャ”によるデータベース集約と、管理共通化は、従来のITインフラ管理者の課題に、もう1つの選択肢を与えるものになるはずです」（日本オラクル テクノロジー製品事業統括本部 戦略製品 & Business Analyticsソリューション本部 シニアエンジニア 小幡創氏）
ここで小幡氏がいう「従来のITインフラ管理者の課題」は、コスト削減・運用プロセス効率化の要請や、意思決定速度を高めたいという経営層からの情報アクセスに関する要請への対応と集約することができる。
それぞれの課題の根本原因をあらためて整理してみよう。
課題1：DBサーバ集約は喫緊の課題だけれども……プロセスはそのまま？
サーバ仮想化技術が成熟しつつあることから、多くの企業ではITリソースの効率的な統合・集約によるハードウェア資産の見直しやコスト削減への要請は強まっていることだろう。
サーバ仮想化技術を使った集約において、もっとも懸念されるのが、集約してハードウェアリソースは削減できたものの、運用プロセスそのものは依然として従来のまま、個別のアプリケーションであったり、部門やロケーションごとの管理体制のままであったりという状態である。
これは、仮想化技術がOSレベルでの統合であることに起因する。簡単な集約であれば、現状の物理サーバと同じ環境を仮想マシンとして立ち上げ、そこに移植するだけで、ひとまずはサーバ台数を減らすことができる。
しかし、集約後のサーバには、複数のOS、複数のアプリケーションがバージョンすら統一されずに置かれている状況があるのではないだろうか。これでは結局、筺体の置き場所が変わっただけで、情報システム部門の管理効率が変わることはない。直近の読者アンケートでもこの管理プロセスの非効率を喫緊の課題として挙げる回答者が多かった（関連記事）。
課題2：サーバ集約と情報システムプロセスの効率化を阻む巨大な壁をどう攻略するか？ が情報システム担当者のウデの見せどころ
では、運用プロセスを共通化・標準化するにはどうしたらよいだろうか？
まず必要となるのはそれぞれのシステムを支えるOS、ミドルウェア、アプリケーションを統一することである。もう1つは、サイロ化して作りこまれているデータベース環境を、商流やビジネスプロセスに合わせて効率良く統合していくことだ。だが、これは非常に厄介な問題だ。
OSやデータベース統合を行うには、まず、アプリケーション側が、ある程度共通のプラットフォーム上で動作していることが前提となる。OS環境であり、データベースといったミドルウェアの共通化である。
現状で要求に応える性能で動いているアプリケーションを変更することのリスクは大きい。パッケージ製品をカスタマイズせずに使っているような場合であれば対応可能かもしれないが、日本企業では社内業務プロセスそのものがビジネスの差別化をもたらしていると考える傾向が強い。例えば、ERPパッケージ導入をとってもMRP標準プロセスに則すというよりも、現場のプロセスを生かすためのカスタマイズが行われるのが常だ。アプリケーションパッケージから全て置き換えることを選択した場合でも、既存資産の変換・置き換えには膨大な工数が掛かる。
この問題は事業統合といった業務プロセスそのものが異なるケースではさらに過酷なものになる。加えてデータベースそのものの統合にも厄介な問題が付きまとう。
「お客さまの中にも数年がかりの統合プロジェクトで苦慮されている方も過去少なくありませんでした。そうした方々を支えていく上で12cが打ち出した幾つかの機能は新たな選択肢を提供するものになるでしょう」（日本オラクル 製品戦略事業統括本部 テクノロジー製品技術本部 プリンシパルエンジニア 猿田剛氏）
マルチテナント・アーキテクチャとEnterprise Manager 12cで何ができる？
マルチテナント・アーキテクチャによるデータベース集約は、サーバ仮想化では対応できない運用プロセスのムダを省きつつ、スキーマ統合のようなハードコアなシステム改革を回避するのに有効だという。
多くのハードウェア仮想化技術が提供するような動的なリソース配分も、複数のPluggable Databaseを1つのデータベース配下に持つことによってクリアしている。また、1つのデータベースへの統合は、これまでの常識よりもはるかに容易に実現できる。
おのおののシステムにあるデータベースを「そのまま」「スキーマ統合なしに」集約できるからだ。
「これにより、スキーマ統合などの重たい工程を含むシステム統合プロジェクトを経ずとも、ひとまずDBのバージョンアップないし移行のみで、システムの集約を実現できるようになります」（小幡氏）
ERPとCRMのような業務系システムを1つのデータベースに配置しておくことで、バックアップやデータのインポート・エクスポートといった定期的に必要なプロセスを統合できる。同様に、システムの管理面での利点も、コンテナ概念を活用することで効率化できる。
「例えばセキュリティパッチを当てるだけでも大がかりなシステムであれば非常に骨の折れる作業です。同じプロセスを何度も繰り返す、あるいは、バージョンなどの違いから、個別に管理してパッチを当てる、といった作業が必要です。これは、集約したもののバラバラのプロセスで運用されていることに起因しています。これらの中で、類似した運用プロセスのものを選択し、1つのデータベースに統合することで、パッチ当てやバックアップといった、見えにくいながら運用者としてはもっとも工数のかかるプロセスを、格段に効率化できるのです」（小幡氏）
マルチテナント・アーキテクチャに対応できるようにするには12cに移行する必要があるが、サポートなどの状況を考えると大方は11gにアップグレード済み、もしくは12cへのアップグレードを検討するフェイズになっていることだろう。11gから12cへのバージョンアップは、隣接バージョンであり、移行ツールも充実しているため、比較的容易に行える。過去、9iへのバージョンアップなどで苦労した読者もいるだろうが、少なくとも現状ではそのような苦労は経ずに最新版を導入できるようになっている。
Enterprise Manager 12cによる運用標準化
クラウド環境での統合を行うと、1つのデータベースに複数のシステムが同居することになる。これにより、従来の「1システム、1サーバ」に比べると、運用コストは確かに削減される。しかしどこに何があるかはわかりづらくなり、運用の複雑さは増加してしまう面があることは否めない。つまりクラウド環境では、グラフィカルに状態を把握できる管理ツールは、かかせないのだ。
12cでは管理ツール「Enterprise Manager」を使って、共通のワークフローに即した運用・管理が可能になる。
「パフォーマンス管理にしても個々のアプリケーションごとに職人技的にあたりを付けてSQLチューニングをするといった運用では、さらなる効率化は望みにくいでしょう。視覚的に状況を把握し、問題を示唆できるツールを持つことで、高度な運用スキルを持つ人材を抱え込まずとも一定水準の運用レベルを保つことができます」（猿田氏）
同様にバックアップなどの工程も統合できる。一括バックアップにより、作業ボリュームが削減できるだけでなく、短期間での復旧が求められるリカバリ作業については、PDBのテーブル単位でも行えるなど、運用者にとって使いやすい仕掛けが用意されている点も注目したい。こちらも、コマンドライン操作などは不要で、GUI経由でだれでも安全に復旧できるようになっている。
管理プロセス効率化のための機能の多くは、Enterprise Managerを介して行なわれる。Enterprise Managerについては、Oracle Database 12cに先行して、Enterprise Manager 12cは既にリリースされているので、既に利用している読者もいるだろう。
12cの登場によって、ようやくEnterprise Managerがその機能を存分に発揮することになる。上述のコンテナによる一括管理など、運用プロセスの効率化や、Pluggable Database 群を自由に抜き差しするためのインターフェイスも備えている。
Enterprise Manager 12cを使った複数DBの一括管理 画面を見ると分かるようにコンテナの中にあるERPやCRMなど複数のデータベースを一括して管理できる。個々のデータベースのパフォーマンス情報なども同じ画面上でモニタリングできる（クリックで拡大）
OS仮想化によるサーバ集約だけでは到達できなかった、運用プロセスの持つムダを、データベースレイヤで実現し、かつ、同一プラットフォーム上でスキーマを統合せずに持つことができるようになる。
また、こうした管理そのものをGUIで、かつパフォーマンス管理を含めたプロセスを、一定レベルで持つことができるうえ、運用プロセスそのものの効率化も進むというわけだ。結果として、つらい運用業務から解放される技術者が増え、より生産性の高い業務を進めることができるようになる。
この他にも、Enterprise Managerには開発場面で有効な利用方法がある。例えば、データベース集約の際のリソース配分や、アプリケーションの動作検証などだ。Enterprise Manager上から元のシステムでのトランザクションをコピーできるため、テスト用のデータではなく、実データを基にした検証が可能になるのだ。
「実データを使った動作検証では、システムパフォーマンスも同じツール上で確認できます。アプリケーション側から出るクエリのどの部分がパフォーマンス上のボトルネックになっているかも、運用者だけでなく開発者が直接確認できるようになります」（猿田氏）
開発中のアプリケーションについて、実データを基に検証できるため、稼働時のアプリケーション負荷についてもテスト段階から確認できるようになる。個別のクエリのどの部分にボトルネックがあるのか、解消するにはチューニングか、リソースの再配分かといった検証も、こうした環境が整っていれば、すぐさまテストして確認できるようになるだろう。
結果として、運用だけでなく新規の開発案件についてもリリース前段階で、一定水準の品質を維持できるようになる。
Enterprise Manager 12c経由で、実データを基にしたテスト環境の構築や、パフォーマンスチューニング、リソース割り当ての検証などを行えば、開発・運用の垣根を越えてPDCAサイクルに則して実施しやすくなる
いかにもEnterprise Managerのような管理ツールは、キャッシュアウトの瞬間には高い買い物に見えるかもしれないが、応分のハードウェア資産やITリソースを削減し、より高度な情報システム運営が可能になると考えると、投資としては決して高くないといってよいだろう。12cへのバージョンアップやクラウド環境への統合を検討するならば、以降の運用プロセス革新の布石として入手しておくべきだろう。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
本稿では、12cがDBAやシステム運用担当者のワークフローをどう変えていくか、その概要を紹介した。次回は、既存Oracleユーザーが12cに移行する際の留意点や、移行後のメリットなどを詳述する。
この記事に関連するホワイトペーパー
”クラウド”のために開発されたデータベース「Oracle Database 12c」
「Oracle Database 12c」は、初めてクラウドを意識して設計・開発された。データベース層でマルチテナントを実装するために採用された「マルチテナント・アーキテクチャ」を始め、その新機能の全貌を紹介！
※ダウンロードにはTechTargetジャパンへの会員登録が必要です
Copyright © ITmedia, Inc. All Rights Reserved.
提供：日本オラクル株式会社
アイティメディア営業企画／制作：＠IT 編集部／掲載内容有効期限：2013年8月16日
