TOP>企業情報>コラム>技術情報>早分かり!Oracle Database Cloud Service入門 Vol.2

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

Cloud

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

Vol.2 「ボタンをぽちっ」で高可用性DBを手に入れよう

オンプレミスの定番構成をクラウドへ


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

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

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

構成 概要
表:Oracle Databaseの代表的な高可用性構成
RAC アクティブ-アクティブ型のクラスタ構成。ノード追加によるスケールアウトが可能
RAC One Node RACの技術を応用したアクティブ-スタンバイ型のクラスタ構成
Data Guard REDOログの転送によってデータベース間の同期を取る構成
Active Data Guard Data Guardの同期を維持したまま、スタンバイ側を読み取り専用でオープン可能
アクティブ・スタンバイ 障害発生時にスタンバイ側へフェイルオーバーする構成
ストレージミラー ストレージやデバイスのレベルでデータを同期する構成

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

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

ワンクリックでRACを構築


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

図1:RACの構築画面

図1:RACの構築画面

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

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

図2:RAC構築完了後の画面

図2: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環境を持つことでコストの削減とリスクの低減を同時に実現できます。

Data Guardもワンクリックで


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

図3:RACの構築画面

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

図4:RAC構築完了後の画面

図4:RAC構築完了後の画面

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

図5:Active Data Guardによるスタンバイの有効活用

図5:Active Data Guardによるスタンバイの有効活用


障害発生時のダウンタイムはどのくらい?


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

図6:障害発生時のダウンタイム

図6:障害発生時のダウンタイム

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

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


執筆者紹介

関 俊洋

関 俊洋(Toshihiro Seki)

株式会社アシスト データベース技術本部

2006年、株式会社アシスト入社。データベース・システムの構築や運用トラブルの解決といったフィールド・サポート業務を経験し、その後は新製品の検証やハードウェアとデータベースを組み合わせたソリューション(DODAI)の立ち上げに従事。現在はデータベースの価値や魅力を伝えるための執筆・講演活動を行っている。『SQL逆引き大全363の極意』共著。

関の紹介記事はこちら

連載記事一覧

関連製品/サービス


Facebookで情報をお届けしています

Facebookでは、アシストの「今」を週3回のペースでお届けしています。「めげない、逃げない、あまり儲けない」を合言葉に日々頑張っておりますので、応援よろしくお願いします。



ページの先頭へ戻る