クラウドでもMAAでミッションクリティカルなシステムを実現できる
佐々木氏は、ミッションクリティカルなシステムのポイントとして、「高い性能」「堅牢なセキュリティ」「高可用性」「運用性」を挙げる。今回のセッションで説明するのは、「高可用性」をクラウドでどう実現するか?という部分だ。
「Oracle MAA(Maximum Availability Architecture)は、クラウドでも適用できます」と語る佐々木氏。
ミッションクリティカルなデータベースの可用性においては、データ保護とサービスの継続を考えなければならない。計画停止、計画外停止があってもこれらを確保できるようにするのだ。計画停止にはデータセンターのメンテナンスやOSなどの更新がある。計画外停止では、ハードウェア障害、ソフトウェア障害、管理者のオペレーションミスなどがある。いずれにせよ、データを確実に保護しサービスを継続できるようにすることが肝心だ。
では、クラウドとオンプレミスでは可用性に対する考え方は異なるのだろうか。
「クラウドでは主に汎用的なストレージを利用するので、障害は発生する前提に立つべきです。またクラウドでは、サービス提供側のスケジュールでメンテナンスが行われることも認識しておく必要があります。つまりクラウドでは停止や障害が発生するのが前提です」(佐々木氏)
障害が発生する前提は、これまでOracleが提唱してきたMAAの考え方と同じだと説明する。MAAは、Oracleの開発チームで実証済みの高可用性テクノロジーと、成功事例に基づいた設計、運用のベストプラクティスだ。MAAでシステムを構築し運営すれば計画停止を短くし、障害発生を少なくできる。仮に障害が発生しても、それを早期に発見し迅速に対応できるのだ。MAAについては、マニュアルやホワイトペーパーが提供されており、さらにMAAの運用状況をチェックするツールもある。
クラウドを活用することで安価に容易に可用性を高めることが可能に
「MAAは、自分では制御できないような停止を前提に、システムを構築する考え方です。これは実はクラウドにぴったりの考え方でもあります」と佐々木氏。MAAはOracleが提供しているReal Application Clusters(RAC)やData Guard、GoldenGateなどの各種可用性確保の仕組みを組み合わせて実現する。これらの可用性の仕組みは、Oracle Database Cloud Serviceでももちろん利用可能だ。
またバックアップなどのデータベースに関連する、Oracle Database Backup ServiceやGoldenGate Cloud ServiceなどのPaaSも今では充実している。「Oracleでは、オンプレミスとクラウドで同じアーキテクチャとなっており、同じ製品を同じ知識、ノウハウで使えます」(佐々木氏)。
クラウドの環境でMAAを適用するには、2つのアプローチがある。1つが、オンプレミスのデータベースの可用性を確保するためにクラウドを使うハイブリッド式のアプローチ。もう1つは、新規にクラウドの上で高可用性のあるデータベースシステムを構築するアプローチだ。
ハイブリッドでは、災害対策目的などでクラウドの環境を利用することが多い。その際には松竹梅の3つのレベル分けができる。もっとも安価に実現できる梅構成では、オフサイトのストレージにバックアップを置く。その際にはRMAN(Recovery Manager)を用いクラウドにバックアップを置くのだ。バックアップ取得の原則は、3つのコピーを2つの異なるメディアにバックアップし、1つはオフサイトに置くことだ。これまではテープに記録し、そのテープはプライマリサイト以外の建屋に輸送して保管してきた。「テープで行っていたオフサイトへの保管をクラウドにするのが梅構成です」と佐々木氏。
たとえばオンプレミスにシングルインスタンスのデータベースがあり、そのバックアップをローカルサイトに取得しているとする。このローカルのバックアップを暗号化し、Oracle CloudのDatabase Backup Serviceに送るのだ。暗号化して送るが、オンプレミスのデータベースに暗号化オプションは必要ない。これによりテープを搬送する手間とコストがなくなる。
オンプレミスで障害が発生した際には、クラウドにあるバックアップからシステムを復旧できる。クラウドのデータベースサービスと連携して簡単な操作で災害対策サイトを新規に構築することも可能だ。バックアップのデータを使いクラウド上に開発やテスト環境を作ることもできる。
クラウド上にあるバックアップからリストアするので、バックアップのサイズが大きければ時間はかかることに注意する必要がある。とはいえ操作はシンプルで、データベースを構築する際に既存のバックアップを使うかどうかの項目で「Yes」を選び、クラウド上のバックアップを指定すればリストアできる。
竹構成は、データベースのレプリケーション機能を使いクラウド上にスタンバイのデータベースシステムを作るものになる。これにはOracle Data Guardを使う。オンプレミスのシングルインスタンスのデータベースを、Data Guardを使いクラウド側にレプリケーションで複製するのだ。
オンプレミスのデータベースの変更履歴をリアルタイムに複製するので、万が一オンプレミスで大規模な障害が発生してもすぐにクラウド上でバックアップサイトを動かせる。クラウド上の構成は、オンプレミスよりも小規模で良い。災害時が発生してバックアップサイトをいざ動かす際に、必要な規模に拡張すれば良いのだ。小さいサイズで始められるので、コストを低く抑えられる。注意点は、パッチレベルをオンプレミスとクラウドで合わせることだ。
松構成は、竹のクラウド上のスタンバイ構成を有効利用するものだ。これにはActive Data Guardを使い、スタンバイ側を検索用途などで利用する。処理をクラウドにオフロードできるので、オンプレミスのシステムの負荷軽減が図れる。簡単にオフロードするために、Oracle Database 12cのバージョン12.2からはGlobal Data Serviceが提供されている。Global Data Service層にいるリスナーが接続リクエストを受けると、データベースの負荷状況やネットワーク遅延などを考慮しクエリーを投げる先を判断し負荷分散するのだ。ネットワーク遅延が発生している場合などには、クラウドへ投げるクエリーは自動的に少なくなる。残念ながらGlobal Data ServiceはPaaSでは提供されていないので、自身でインストールする必要がある。
アプリケーションも含め高可用性を考える際には、梅構成ではアプリケーションのバックアップをデータベースと同様にクラウドに送る。これには、Storage Cloud Serviceのオブジェクトストレージに定期的にコピーするようにすれば良い。竹や松の構成の場合も、基本的な考え方は同じだ。データベースがクラウドにあるので、アプリケーションをデータベースに載せてしまうことができる。データベース・ファイルシステムにアプリケーションのデータを持つことで、クラウドのデータベース・ファイルシステムに自動でバックアップできる。
クラウドならRACやData Guardでの災害対策構成も簡単に構築可能
クラウド上で新規にミッションクリティカルな構成を作る際には、ブロンズ、シルバー、ゴールド、プラチナという4つのレベルの可用性を選ぶことができる。4つのレベルにクラウドサービスを当てはめると、それぞれの構成をマッピング可能だ。ブロンズレベルは、ハイブリッドの梅構成のクラウド版となる。リージョン1、リージョン2で梅構成を構築するイメージだ。まずは同じリージョン内にバックアップを取得し、それを定期的にリージョン2にコピーする。Database Cloud ServiceのEnterpriseかStandardで利用でき、Database Backup Serviceを組み合わせることになる。使い方はハイブリッドの梅と同様だ。
Database Cloud Serviceでバックアップを取得するには、インスタンスを作る際に選択するだけだ。それでオブジェクトストレージにバックアップが取得できる。基本は日次でデータファイルがバックアップされ、アーカイブログは30分に1回取得され、ローカルに7日間、オブジェクトストレージに30日間保持される。
バックアップは取得するだけでなく、戻すことが重要だ。実際に戻せるかどうかに関わるファイルが足りてるかどうかのチェックなどは自動で実施される。ブロンズ構成では、データ破損、データベース再起動不可、サイト障害などが発生した際に、直近のバックアップ取得のタイミングに復旧できる。
シルバーでは、ブロンズのリージョン1のシステムをRAC構成にする。これによりリージョン1でノード障害が発生してもサービスは継続できる。OSのパッチやデータベースのパッチを適用する際には、ノードを縮退運用し順番に当てることでサービスを止めずに行える。
オンプレミスでRAC構成を構築するのにはそれなりに手間がかかるが、Database Cloud ServiceであればRACを構成するにはチェックボックスにチェックを入れるだけだ。シルバーでは、計画外の停止においてもシステムの停止時間は数秒程度で収まり、計画停止はゼロダウンタイムを実現できる。
シルバー構成では、Data Guardを活用する方法もある。Data Guardの利用も、Database Cloud Serviceならば「HA」の項目にチェックを入れるだけだ。これで同じリージョン内にスタンバイを置ける。Data Guardの場合も、計画外停止でも数秒から数分の停止で復旧する。データベースのアップグレードも短時間化でき、アプリケーションをスタンバイと切り替えながら更新することで数秒から数時間の停止で可能だ。
ゴールドの構成は、それぞれのリージョンでRACを組みリージョン間はData Guardで連携する。ここまで実施すれば、サイト障害が発生しても運用を継続できる。この場合のData Guardの利用も「DR」にチェックを入れるだけだ。この構成では、メンテナンスによる停止時間もゼロにできる。
さらにプラチナ構成では全てをRAC構成にする。その上でローカルリージョン内でもData Guardを利用し、リージョン間もData Guardで連携する。加えて適宜Golden Gateも組み合わせる。さらにApplication Continuityも利用すれば、計画外停止もゼロダウンタイムを実現できる。
このようにパブリッククラウドを利用することで、さまざまなレベルの高可用性構成を容易に実現できる。とはいえ規制やレイテンシーの要件が厳しいなどで、パブリッククラウドに持って行けないこともあるだろう。Oracleの場合には、パブリッククラウドと同じような使用感で使え、その上で顧客のデータセンターにシステムを置きOracleが下位レイヤーを管理するOracle Cloud at Customerもある。これであればクラウドのメリットを享受しながら、ネットワークの遅延などの影響も受けにくい環境が実現できる。
「Oracleでは、オンプレミスでMAAを実現してきました。この考え方はクラウドにも適用できます。MAAはオンプレミスかクラウドかにかかわらずミッションクリティカル環境を実現できるアーキテクチャです」と、クラウドで高可用性を実現するためにもMAAのアーキテクチャを適用してほしいと、佐々木氏は締めくくった。