オラクルが考えるDBインフラのクラウド化「DBaaS」とは？ 実現方法と支援環境を聞く：Database Watch（2015年5月版）

連載バックナンバー

　2015年4月に開催されたイベント「Oracle CloudWorld Tokyo 2015」では、米オラクルのCTO（最高技術責任者）であるラリー・エリソン氏がクラウド市場の展開を熱く語っていました。その1カ月後となる5月、筆者はオラクルから現実的、実践的なデータベースのクラウド移行プロセスについて、あらためて話を聞く機会を得ました。データベース／データベースアプリケーションのクラウド化を確実に進めるにはどうしたらいいのでしょうか。

データベースクラウドの道のりは多くが「旅の途中」

　今回取材に応じていただいたのは米オラクルでOracle Databaseの管理製品担当 バイスプレジデントを務めるMughees Minhas（ムギース・ミンハス）氏です。

　ミンハス氏は「クラウドへの道のりは旅のようなもの」と語ります。ここで、ミンハス氏がいう「クラウド」とは、データベースシステムのクラウド的な利用・運用を指しています。また、「クラウド的な」というのは、「共用の構成が可能なコンピューティングリソースに、どこからでも、簡便に、必要に応じて、ネットワーク経由でアクセスできること」です。

　「Oracle Database 12c」の「c」がクラウドを意味していることからも分かるように、12c以降のオラクルでは、「DBaaS（Database as a Service）」として、データベースインフラもクラウド的になるべきだと考えています。今回取材したミンハス氏は、このDBaaSを具現化するための工程、そしてそれらの工程にひそむ課題を解消する方法をどう用意しているのかを解説してくれました。

データベースクラウドに至る三つの段階

　ミンハス氏はデータベースの「クラウドへの移行」を、幾つかの段階を経て成熟していくものだと説明します。その段階について、ミンハス氏は大きく分けて三つあるとしています。

　まず、（1）サービスの品質を高める段階があり、次に（2）システムを統合していく「コンソリデーション」の段階があります。そして、これらのプロセスを確実にクリアしてから（3）完全なるクラウド化へと進むことができるのだそうです。

　逆に言うと、前段階をきちんと踏んでおかないとクラウドに完全移行したときにメリットを最大限に生かせないことになるかもしれません。なるほど、旅行をするにも準備が重要ですね。財布を忘れて出発してはどうにもなりません。ミンハス氏は、準備万端で出発すれば旅行はいいものとなるのと同様、クラウドに進むには前段階を経験し、完成度の高い状態にしておくことが大切だということを強調していました。

　実際のところ、世界、あるいは日本の企業や組織は、三つの段階のどの段階にいるのでしょうか。ミンハス氏の見解ではグローバルでは多くが現段階で1〜2段階目にあり、3段階目に到達できているのはごく少数だといいます。

　それでは、それぞれの段階をもう少し深く伺っていきましょう。

（1）サービスの品質を高める段階

　1段階目はサービス品質――パフォーマンスや可用性を高める段階です。リハーサルで完璧にしておけば、本番のクラウドという舞台に立っても問題なく稼働できる可能性は高くなります。

　品質を管理していく上で大事なのは、問題を早急に検知して解決することです。

　ミンハス氏は、この段階にある組織を助けるものとしてオラクルでは「Oracle Enterprise Manager（以下、Oracle EM）」を提供している、と述べました。

　Oracle EMでは自動パフォーマンス診断機能があり、ボトルネックの原因を検知します。また、自動SQLチューニングもあります。データベースで性能劣化の原因を調べていくと、SQLにたどり着くことが多くあります。Oracle EMには自動パフォーマンス診断機能があり、ボトルネックの原因を検知することができます。

　これらは問題の早期検知と解決に結び付くものですが、「さらに進んだ対策がある」とミンハス氏は言います。問題のタネそのものを発生させないようにする「SPA Quick Check」です。

　本番環境を想定したテストが行える「Oracle Database 12c」のオプション「Real Application Testing」にはSQLパフォーマンス分析（SPA）という機能があり、SPA Quick Checkは、これを簡単に実行できるようにした機能です。SQLを実行する前に処理をシミュレーションして、性能にどのような影響を与えるかを知ることができます。

　アプリケーションやサービスがオンプレミスにあろうが、クラウド上にあろうが、最良の状態で稼働させるのが理想です。まずは、「きちんと運用管理できる状態にする」が1段階目です。

（2）システムを統合していく「コンソリデーション」の段階

　2段階目はコンソリデーション――つまり「統合」です。第一段階で、一定の品質、かつ一定のプロセスで運用管理が行えるようになった段階で、複数のデータベースをまとめていきます。

　簡単に「データベースをまとめる／統合する」といっても、その方法には複数の選択肢があります。

選択肢1：仮想化による物理サーバーの統合

　まず、サーバー仮想化による統合が考えられます。同じ物理サーバー上の仮想マシンに複数のデータベースを載せて、サーバーハードウエアを共有します。仮想マシンが利用するリソースが共通なだけであって、仮想マシン上のOSやアプリケーションは独立しています。この場合、ハードウエア管理以外の運用管理プロセス全般は、個別のデータベースサーバーを管理する場合と同じになります。

選択肢2：OSレベルでの統合

　また、複数のデータベースを共通のサーバーOS上で稼働させる方法もあります。データベースインスタンスないしスキーマの単位で統合することから、OSが共通になり、ハードウエアだけでなくOSレイヤーの運用管理を効率化できます。

　ただし、アプリケーションを同じOS環境で動作させるには、場合によってはOSバージョンを共通化したり、システムが利用する名前空間を統一したり、データベースのバージョンをそろえたりする必要があります。

選択肢3：プラガブルデータベースによる統合

　そして、Oracle Database 12cの目玉機能でもある、「プラガブルデータベース」を用いた統合もあります。個々のデータベースの独立性を保ったまま統合できる点が特徴です。この場合は、上記の共通OS上でのデータベース運用と比較した際に、統合のためのOSやデータベースのバージョン、スキーマ統合のような煩雑な事前準備を回避しつつ、Oracle Database 12cが持つ「コンテナー」単位での運用管理が可能になります。

（3）完全なるクラウド化の段階

　ミンハス氏は「こうした段階的な“旅”を経て、最終的には完全なるクラウド化への段階に到達する」といいます。するとそこにはデータベースがサービス化された「DBaaSの世界」が待っているというわけです。

　冒頭で示したように、データベースのリソースを必要な時に必要なだけ、ネットワーク経由で得られる環境の実現です。DBaaSが実現すれば、開発や調達に関わる時間短縮が可能になり、また、運用管理も大きく変わっていくことでしょう。

キャパシティプランニングは、クラウド化への旅程を確かなものにする

　ミンハス氏はさらりと三つの段階（クラウド化への旅程）を説明してくれましたが、その実現は難しい問題をはらんでいます。

　特に第2段階は、手法はさまざまありますが、実際に何らかの方法でデータベース統合に着手するとなると、動作の安全性やパフォーマンスなどの面で「複数のデータベースを一緒にしても大丈夫？」という心配が付きまといます。

　そのため、目的のレベルで共有できるかどうかを判断するために、それぞれのデータベースアプリケーションのワークロードを的確に見積もる必要があります。

　当然ですがアプリケーションごとにCPU、メモリ、ストレージ、ネットワークの使用状況は異ります。統合によって過負荷になってしまわないか、慎重に判断しなくてはいけません。加えてデータベースアプリケーションに掛かる負荷は常に同じとは限りませんし、データの蓄積や規模の拡大などによって負荷そのものも時間と共に高まっていくことを考慮する必要があります。

　統合の段階では、何と何を、または何から組み合わせたらいいのかを考えることも大事です。例えば、負荷のピーク時間帯が同じものを統合してしまうのは好ましくありません。負荷の時間変化も考慮し、ワークロードを重ね合わせて問題ないかを確認する必要があります。これを「キャパシティプランニング」といいます。

　このようなキャパシティプランニングにも、Real Application Testingが有効だとミンハス氏はいいます。また、上述のSQLパフォーマンス分析（SPA）も使えることでしょう。加えて本番環境のワークロードを取得してテストする「データベース・リプレイ」機能も、キャパシティ検証に有効です。

オラクルをDBaaSへの旅の“トモダチ”にしてほしい

　ミンハス氏は「オラクルはデータベース統合の三つの段階の全てにソリューションを提供しています。“クラウド（DBaaS）への旅”において、われわれを共に歩む友として見ていただきたい」と話していました。

　ミンハス氏が言うように、オラクルではDBaaS実現のための道筋とともに、各段階での支援環境を用意していますが、ここで大事なのは、どの環境・ツールを使ってDBaaSへ進むにせよ、運用の品質を極力事前に整備しておくこと、統合する際には、十分な検証を行っておくことです。これらをきちんとこなしていれば、運用管理の効率や調達利便性の高いDBaaS環境を手に入れる際、リスクを最小限にすることができるでしょう。