早分かり！Oracle Database Cloud Service入門　Vol.2

Oracle Database Cloud Serviceは、Oracle Databaseの環境を数クリックでクラウド上に構築できるPlatform as a Service（PaaS）です。リリース以来様々なアップデートが行われており、今ではReal Application ClustersやData Guardといった定番の高可用性構成を簡単に構築できるようになりました。今回は実際の画面をもとに、高可用性構成ができあがるまでの流れとその動作をご紹介します。

Oracle Databaseを利用する上で欠かせないのが、可用性の確保です。今でこそOracle Exadata Database MachineやOracle Database ApplianceなどのEngineered Systems^※1でお墨付き構成をすぐ入手できますが、ゼロから設計・実装まで行うには高度なスキルを必要とします。

※1：Oracleのソフトウェアとハードウェアが一体となったアプライアンス型の製品

とは言えOracle Databaseは歴史ある製品なので、オンプレミスの場合はSIerやベンダーが持つノウハウ、経験で大抵の場合は事足ります。Real Application Clusters（以下、RAC）、Data Guard、サードパーティ製クラスタウェアを利用したアクティブ・スタンバイ構成、ストレージミラーなど実装方法も様々なので選択肢には困りません。

ところが、クラウドになると話が変わります。可用性をデータベースの機能で確保するのか、それともクラウド側が持つ技術で確保するのか、責任の所在がぶれてしまうからです。例えばInfrastructure as a Service（IaaS）を利用する場合、インフラ層は一定の可用性が確保されていますが、その上で動いているデータベースまでは考慮してくれません。対策としてRACを組みたくても、ほとんどのクラウドではサポートされていません。

Oracle Database Cloud ServiceはRACとData Guardをサポートしており、さらに構築が非常に簡単です。オンプレミスとの高い互換性を持つというコンセプトのとおり、定番の高可用性構成をクラウドでそのまま利用できるのです。

Oracle Database Cloud ServiceでRACをどれだけ簡単に作れるのか、実際に試してみましょう。以下がRACの構築画面です。

操作は非常にシンプルで、赤枠の部分にチェックを入れるだけです。あとは数十分待つだけでRACの環境が自動的に立ち上がります。通常、RACの構築はクラスタウェアとデータベースをそれぞれインストールする必要があり、動作検証まで含めると数日がかりの作業になります。それをたったワンクリックで実現できるのは、クラウドならではのメリットと言えるでしょう。

RACの環境ができあがると、以下のように各ノードの情報が表示されます。

現在は2ノード構成のみ作成可能になっており、トライアル版では2 OCPU^※2以上、契約済の環境では 4 OCPU以上のリソースが必要です。エディションはEnterprise Edition - Extreme Performanceを選択する必要があり、Standard EditionのRAC（SE-RAC）は構築できないのでご注意ください。

※2：Oracle Compute Unitの略で、インスタンスに割り当てられるCPUリソースのこと

前述のとおりRACをサポートするクラウドはほとんどないので、このRACは様々な用途に活用できます。従量制にして時間単位の課金を選択できるので、まず開発・テスト環境として利用してみるのが良いでしょう。オンプレミスの場合、本番環境がRACだと開発・テスト環境にもRACが必要になりますが、実際はライセンスやインフラのコストが折り合わず、シングル構成になることがよくあります。構成に差異があると、本番環境のワークロードを再現できなかったり、事前にパッチの適用手順・影響度を確認できなかったりと様々なリスクがあります。クラウドにRAC環境を持つことでコストの削減とリスクの低減を同時に実現できます。

Oracle Database Cloud Serviceは、2016年6月のアップデートでData Guardに対応しました。こちらもRACと同じようにワンクリックで実装できます。

Data GuardにはRACのようなOCPU数の要件はなく、Enterprise Edition、Enterprise Edition - High Performance、Enterprise Edition - Extreme Performanceのいずれかで利用できます。構成には「High Availability」と「Disaster Recovery」の2種類があります。High Availabilityを選択すると、同じデータセンターの異なるゾーン^※3にインスタンスが作成され、その間でData Guardが構成されます。もう一方のDisaster Recoveryを選択すると、異なるデータセンターにインスタンスが作成され、その間でData Guardが構成されます。

※3:Oracle Cloudの物理リソースが配置されている単位

Data Guardの環境ができあがると、以下のようにプライマリ／スタンバイそれぞれの情報が表示されます。スイッチオーバー、フェイルオーバーもブラウザ上から実施できるので、基本的な操作に困ることはないでしょう。

このようにとにかく簡単で分かりやすい画面が特長のOracle Database Cloud Serviceですが、別の環境に複製を作ること自体は特に目新しくありません。むしろ、クラウドなのでできて当たり前とも言えます。Oracle Database Cloud Serviceならではの強みは、Active Data Guardでスタンバイサイトを有効活用できることにあります。一般的なクラウドはストレージミラーでデータを複製しているため、平常時はスタンバイサイトにアクセスすることができません。それでもプライマリ／スタンバイの両方に対して課金されてしまうので、リソースの有効活用という点で課題が残ります。Active Data Guardならスタンバイサイトを読み取り専用でオープンできるので、レポーティング用途などに活用できます。

環境ができあがったので、障害発生時のダウンタイムを計測してみましょう。比較対象はOracle Database Cloud ServiceのRAC構成、Data Guard構成、他社クラウドのストレージミラー構成の3つです。CPUやメモリなどのリソースは可能な限り揃えています。実際に物理的な障害を起こすことはできないので、RACの場合はプロセスを強制終了、Data Guardと他社クラウドのストレージミラーでは手動でフェイルオーバーを実施しています。

結果は当然ながら、アクティブ-アクティブ構成であるRACが圧倒的に優れていました。オンプレミスでも同様の検証を実施したのですが、RACとData Guardはほとんど変わらない結果が出ました。ストレージミラーはデータベース以外の操作をいくつか間に挟むので、どうしても時間がかかってしまいます。こうしたダウンタイムは、どのクラウドを選択するかの重要な指標になるので、トライアルまたは時間課金のサービスで検証してみると良いでしょう。

今回ご紹介した高可用性構成をはじめ、Oracle Database Cloud Serviceには新しい機能が次々と追加されています。オンプレミスでお馴染みの構成を簡単・手軽に実装できるのは大きな利点なので、適材適所でクラウドを活用しながら時間やコストの最適化を図ってみてはいかがでしょうか。

・早分かり！Oracle Database Cloud Service入門 Vol.1

最後までご覧いただきありがとうございました。
本記事でご紹介した製品・サービスに関するコンテンツをご用意しています。また、この記事の他にも、IT技術情報に関する執筆記事を多数公開しておりますのでぜひご覧ください。