サーバー仮想化で運用コストは本当に減らせるの?データベース運用の効率化は“サービス”視点で考えよう!

サーバー仮想化で運用コストは本当に減らせるの?データベース運用の効率化は“サービス”視点で考えよう!

データベース基盤と管理の「それって本当?」――スペシャリストが真実を暴く　その2

今稼働中のサーバー、「そのまま丸ごと仮想化すればコストは下げられる」と思っていませんか？ 実は必ずしもそうとは限りません。適用範囲を見極め、それに適した形の仮想化をしなければ、運用が複雑化してかえってコストがかさむ恐れがあるのです。自由度は高いけれど手を加える必要がある路面店と、必要な設備が整ったショッピングモールとの比較で考えてみましょう。

はじめまして。日本オラクルの伊藤勝一です。クラウド・テクノロジー事業を推進する中で、多くのお客さまのクラウド移行や仮想化導入支援に携わってきました。ご相談を受けるときによく耳にする言葉が、「せっかく仮想化したのに、思うようにパフォーマンスが出ない」「意外と運用が面倒で、コストもかさむ」といったものです。そこで今

回は、目的に見合った仮想化技術を活用し、プロジェクトから効果を得るコツをご紹介します。

「仮想化」と「クラウド」は似て非なるもの。 「仮想化」で運用コストは上がってしまう? 　「仮想化」は今やシステム構築・更改とプライベートクラウドへの移行を検討する際に挙がる選択肢の一つではないでしょうか。1台のハードウェアにハイパーバイザを載せ、その上で複数の仮想マシンを稼働させてハードウェアリソースを集約し、ハードウェア自体のコストを削減できることがその「利点」とされてきました。　しかし、実際にサーバを仮想化してみたところ「思ったほどコストが減らせない」ことに気付く方も増えているようです。既存のシステムをそのままハイパーバイザー上に載せるのでは、物理的な機器の数は減っても、論理的なシステム構成数は減りません（図 1）。むしろ、仮想化でレイヤーが増える分、今までより管理が大変になり、特にシステムに問題が発生した際のトラブルシューティングなどにも時間や手間がかかるケースも増えてきます。結果として、運用コストがネックになってコスト削減の目標が達成できないことが多いようです。

「仮想化しただけ」では リソース最適化ができない理由

　もう一つの大きな課題はパフォーマンスです。確かに、サーバー仮想化の狙いの一つは「せっかく導入したハードウェアなのだからリソースが余っているのはもったいない。できるだけ集約して使い切ろう」というところにありました。しかし、OSからアプリまでを丸ごと仮想化して詰め込むだけ詰め込むと、仮想マシンごとにメモリーやプロセスといったリソースを確保することになり、全体を見渡すと重複するリソース消費が多数存在し、無駄が多いように見えます（図 2）。　一体どうしてでしょう？ それは、仮想化、標準化のレイヤーが低すぎることに起因しています。そもそも、システムの目的とは何でしょうか？ 従業員や顧客といったエンドユーザーに「サービス」を提供することですよね。従って、基盤側から考えるのではなく、サービス視点、アプリケーション視点で必要な性能や可用性を考慮し、アーキテクチャを考えていくことが重要です。　そのアプリケーションを支えているのが、ミドルウェアやデータベースです。この部分、すなわちプラットフォームレイヤーを標準化し、仮想化して統合する、そんなシンプルなアーキテクチャが実現できればどうでしょうか。OSやデータベースへのパッチ適用やバックアップなども少ない手間で行えますし、常に最新のパッチを適用できるため高いセキュリティレベルを確保できます。また、メモリーをはじめとするリソースをプラットフォーム全体で共有しつつ、システムの重要度に応じて配分することで、より有効に活用できるでしょう。無駄なリソース割り当てを省くことで統合できるシステムも増え、集約率を向上できます。しかも開発者は、下のレイヤーのことを気にせず自由にアプリケーション開発に専念できます。　確かにインフラレベルで仮想化すれば自由度は高く、何でもできるでしょうが、その分あれこれとメンテナンスに手間がかかります。「サービスを提供する」という目的が明確ならば、それに合わせて高いレイヤーで標準化することで、求められるパフォーマンス要件を満たしつつ全体の ITコストを削減できます。

「リソース」を「サービス」として 提供するなら、どうするのがベスト？

　では ITリソースの供給を「サービス」と考えてみましょう。手間をかけ

日本オラクル 伊藤勝一

図 1　仮想化により物理サーバーの数を減らしても中身は複雑に

図 2　負荷分散ができないため無駄にリソースを消費してしまう

ずに必要なものを必要な時に共有するとしたら？ というのも、IT部門が管理する「リソース」は、いわばお客さまに提供するための「商品」です。できるだけ原価率を抑えて効率よく、一定の品質で提供するにはどうしたらよいでしょう？　店舗経営者ならこう答えることでしょう。「商品提供に直接関係がないムダを極限まで排除すること」。つまり、サービス提供に注力することです。では、どうすれば商品提供「だけ」に集中できるでしょう？　その答えは、「まとめられることをまとめて実施すること」にあります。現代的なショッピングモールの運営をイメージしてみると分かりやすいかもしれません（図 3）。　駐車場の確保やポイントカードの発行や運用は、路面店では個別に行う必要があるためコスト増加につながりますが、ショッピングモールでの出店なら、他店と共有、共通化することで、低コストかつ標準的なサービスを提供できます。売り場のスタッフも接客対応に集中することで、パフォーマンス（＝売り上げ）も増加することでしょう。　さらに、店舗運営の固定費が削減できれば、営業利益率の向上につながります。　ショッピングモール方式の利点はもう一つあります。それは、セキュリティ、ガバナンスの確保です。路面店の場合、近隣の環境の変化は予想がしにくいでしょうし、営業活動の阻害要因も出てくるかもしれません。店舗ごとのサービスレベルもばらつきがでるかもしれません。一方、ショッピングモールでは出店に際し一定の利用規約が設けられ、運営会社によるチェックがあります。自分勝手な運営はできず、一定のルールが守られる保証が得られるのです。　もし運営する店舗が一つだけなら、路面店に手を入れ、古株スタッフの経験に頼って販売していくことも可能でしょう。しかし、ビジネス拡大を視野に、どんどん店舗を増やしていくことを考えるならば、標準化というプロセスを避けることはできません。そもそも、昔ながらのやり方が正しいとは限りません。今の環境、これからの環境に合わせて最新のツールやデータを使いこなし、スタッフの経験に依存せずに一定品質の接客を実現していくことが、売り上げ拡大には欠かせません。　全体のパフォーマンスを見て、需要の大きな地域への出店もショッピングモール方式であれば、迅速に実現できますし、逆に店舗の売り上げ

が伸びないと判断したら、すぐに撤退できます。これが路面店ならば、計画から出店するまで時間や初期投資がかかるところです。「業者側のスケジュールが遅れた」といったさまざまな要因によって、当初の計画通りに進まない恐れもあります。　さて、これをデータベースシステムの運用にたとえたらどうなるでしょう？個 の々データベースの独立性は維持したいところです。しかし、一方で、バックアップやパッチ適用などは、どのデータベースでも実施する部分でなおかつ、こうした運用は「サービス提供」の視点からすると、重要なことではありますが、ついつい軽視しがちな部分で、適切に行われていないこともよく見かけられます。データベースのバージョンや構成がバラバラではオペレーションも煩雑になり、ミスも発生しやすくなるでしょう。　データベースの層を標準化し、必要なオペレーションを１度で確実に行うことで、先ほどのページで紹介したハイパーバイザーを利用した仮想化による、メモリーやCPUのムダと同じように、運用のムダも排除され、より効率のよい運用が可能になります。

コンテナ型のアーキテクチャを持つOracle Multitenantは

どうして運用のムダを削減できる？　サーバー仮想化とプラットフォームの仮想化の違いを、独立店舗とショッピングモールにたとえて紹介しましたが、お伝えしたいことは 3つです。（1）運用も含めて効率化したいなら「サービス提供」を軸に考えること（2）オペレーションは極限までシンプルにすること（3） システムインフラ運用の効率化を目指すなら、データベースとアプリ

ケーションを分けて共通化すること　ポイントは、データベースという、共通したオペレーションが行われるミドルウェアの層で標準化することで、全体がシンプルになり、運用効率が高まる、ということ。そしてそれが運用コスト削減につながることです。ハイパーバイザによって仮想化し集約したシステムと比較したときに運用コスト面で優位なのはこのためです。　日本オラクルでは現代的なショッピングモールのように効率を考え抜いたオペレーションを実現するアーキテクチャとして、「Oracle Database 12c」において「Oracle Multitenant」を提案しています。

図 3　個別の店舗では重複部分にリソースが必要。ショッピングモール型なら共通部分を一括運用してリソースを削減し、管理も一元化

　その中核的な技術が、データベースクラウド基盤となる「マルチテナント・コンテナ・データベース」（CDB）と、用途に応じて論理的に分離された「プラガブル・データベース」（PDB）です。これまでは用途ごとに別 に々データベースを構築するケースが多かったと思います。これに対しOracle Multitenantは、CDBで、メモリをはじめとするリソースを共有し、集約度を高めるとともに、必要なリソースを適切に割りてることで、パフォーマンス向上を実現します。パッチ適用やバックアップをはじめとするメンテナンス作業は、CDBという一つのデータベースに対して行えばよいため、作業工数が減り、運用管理コストを大きく削減できます。一方、用途ごとのデータは、論理的に分離したPDBに格納され、これまで個別に構築、運用していた従来型のデータベースとまったく同じ独立性、セキュリティを確保しているので安心です。既存システムで利用していたアプリケーションコードの変更も不要です（図 4）。　実は、データベース運用コストの 60％以上が、パッチ適用やバックアップといった作業のための人件費で占められているという調査結果があります。Oracle Multitenantを利用した統合によってこれらのタスクを集

約し、運用効率を 10 倍に上げられるとしたら、運用コストの削減効果は絶大なものがあるでしょう。　ちなみにPDBは、「プラガブル」という名前が示す通り、USBメモリーを抜き差しする感覚で非常に少ないステップでデータベースを移行したり、作成・削除が行えたります。開発・検証用のクローン環境の作成もスピーディーでかつ容易に行えますし、セルフ・サービスによるプロビジョニングも可能です。　今後、さまざまな環境やビジネス要件に応じて迅速にサービスを提供するには、システムデザインをしっかり考え、標準化したものをサービスカタログ化する、といった準備が重要になるでしょう。そうした環境さえ整えば、あとは必要に応じてセルフ・プロビジョニングし、手間をかけず迅速にサービスを展開できるようになります。安易に「サーバを仮想化すればコストが減り、柔軟にサービスを展開できる」と考えるのではなく、データベースも含めたプラットフォーム・レベルで標準化、仮想化を考えていただきたいと思います。

サーバー仮想化で運用コストは本当に減らせるの?データベース運用の効率化は“サービス”視点で考えよう!

サーバー仮想化で運用コストは本当に減らせるの?データベース運用の効率化は“サービス”視点で考えよう!

データベース基盤と管理の「それって本当?」――スペシャリストが真実を暴く　その2

今稼働中のサーバー、「そのまま丸ごと仮想化すればコストは下げられる」と思っていませんか？ 実は必ずしもそうとは限りません。適用範囲を見極め、それに適した形の仮想化をしなければ、運用が複雑化してかえってコストがかさむ恐れがあるのです。自由度は高いけれど手を加える必要がある路面店と、必要な設備が整ったショッピングモールとの比較で考えてみましょう。

❶ 既存システムを仮想化集約するだけでは運用コストは変わらない。❷ 「サービス」を支えるデータベースやプラットフォーム・レベルでの 　 標準化、仮想化が運用コスト削減のカギ。❸Oracle Multitenantは、運用効率の向上とコスト削減を実現し、 　 目的に合わせたデータベース・プラットフォームを実現する。

今回の学び

図 4　リソースの効率化と運用管理の簡略化を実現する Oracle Database 12c

・ 従来のDB

多数のDBを1つのDBとして管理パッチ適用／アップグレード

バックアップ

従来 : DB 毎 マルチテナント : 1度

迅速なDBの展開

PDB単位も可

・ 従来のDBクローニング

移動

従来 : 複数ステップ マルチテナント : 1 ステップ

データファイルのコピー &リストア

バックアップ

データファイルパスの変更

SID & 制御ファイルの

変更

クローン

データファイルのコピー &リストア

バックアップ

データファイルパスの変更

制御ファイルの変更

移動

UNPLUG PLUG