「RDBMS in the Cloud: Oracle Database on AWS」を読んだ (4) ～高可用性～

cloudpackエバンジェリストの吉田真吾（@yoshidashingo）です。

AWS クラウドコンピューティング ホワイトペーパー に、AWS で Oracle Database を利用する際のホワイトペーパー「RDBMS in the Cloud: Oracle Database on AWS」が掲載されたので、読んでみました。
第4章は「High Availability」
高可用性と書かれている部分は「HA構成（アクティブ-スタンバイ構成）」と読んでもらったほうが意味が分かりやすい部分が多いと思う。

高可用性

Oracle と AWS から提供されるツールを組み合わせることで、アプリケーションにとって堅牢な基盤となる、高い冗長性と可用性のあるデータベースを構築することができる。

■AWS の高可用性機能

AWS は高い冗長性と高い可用性のあるデータベースソリューションであるいくつかの機能を提供している。いくつかの機能とそれが解決する範囲について記載する。

■Oracle の高可用性機能

Oracle データベースエンジンはデータベースの可用性を強化するためのさまざまな機能を提供している。 以下の機能は Amazon RDS でも Amazon EC2 でも利用可能である。

• Oracle のフラッシュバック・テクノロジーでは、人為的なエラー操作を選択して効率的に巻き戻すことができる。Amazon RDS も EC2 も複数のデータリカバリー方法をサポートしている。
  • FLASHBACK TABLE文は、1つのテーブルや、テーブルセットにおける論理的なデータ破損を、特定のリストア・ポイント（訳者注：特定のSCN、タイムスタンプ、作成済みのリストア・ポイント）までリストアすることができる。
  • Flashback Transaction Query は、特定のトランザクションによる変更箇所を全て確認することができる。
  • Flashback Query は、過去の特定時点のクエリー結果を再現できる。
• Total Recall は Flashback 機能に基づき（訳者注：Flashback Data Archive 機能）、クエリーが”特定の過去時点で”取得しえたデータを取得できる機能である。これにより企業は監査やコンプライアンスのためのデータを”アーカイブ”しておくことができる。Flashback と Total Recall の主な違いは、Total Recall ではデータは半永久的にアーカイブ表領域に格納され、ユーザーの定義している保存期間を杉田もののみエージアウトする点である。

くわえて以下の機能は Oracle データベースを EC2 上で稼働している場合に利用できる機能である。

• 前の項で説明した Flashback 機能にくわえて次の Flashback 機能も利用可能である：
  • Flashback Drop 機能は誤ってdropしたテーブルをリカバーする
  • Flashback Transaction 機能は単一のトラザクションによる変更箇所を元に戻す
  • Flashback Database を使って、（バックアップを利用せず）Oracle用に最適化されたフラッシュバックログを使用して、特定時点にデータベース全体をリストアできる。Amazon RDS にはpoint-in-timeリカバリと同様の機能がある。
• オンライン・データ再編成および再定義は、ユーザーのデータベースへのフルアクセスを提供したまま、テーブルの物理的な属性の変更やデータやテーブル構造の変更を行える柔軟性を提供する。たとえば、テーブルが読み書きできるので、異なる表領域にテーブルを移動したり、パーティショニングしたり、カラムを追加や削除したり、インデックスを作ったり再構築したりできる。
• トランスポータブル表領域はOracleデータベース間でユーザー表領域を素早く移動できる機能である。これを利用し、ユーザー表領域を旧バージョンが稼働しているデータベースから新しいバージョンが稼働する空のデータベースに移動するなどしてデータベースのアップグレード期間を短縮することができる。
• エディション・ベースの再定義ではオンラインでアプリケーションのアップグレードができる。コードの変更は新しいエディションの領域にインストールされる。データの変更は古いエディションからは見えないように列やテーブルに書き込まれるため安全である。”エディション”ビューはそれぞれのエディションが自身のカラムだけ表示されるように異なった射影を提供する。クロスエディショントリガーは、古いエディションで発生したデータの変更を新エディションへ、あるいは逆についても同様に、変更の伝播を行う。

これらデータベースエンジンの機能に加えて、レプリケーション技術を使い、ハードウェア故障やデータセンターの問題や災害から守れるアーキテクチャをデザインすべきである。以下の章でどのようにOracleのレプリケーションをセットアップすればよいか説明しよう。

■Amazon RDS の高可用性アーキテクチャ

Amazon RDS は高可用性のアーキテクチャでできている。１つめに、Amazon RDS はハードウェア故障時に、自動的にインスタンスをリプレースする。２つめに、Amazon RDS は同一リージョン内の別アベイラビリティゾーンにセカンダリのOracleデータベースを用意する、Multi-AZ配備をサポートしている。このアーキテクチャは、データベースインスタンスやネットワークやストレージ、果てはアベイラビリティゾーン自体の障害からデータベースを保護するものである。アプリケーションサーバーやWebサーバーといったその他のインフラについてはアベイラビリティゾーンの障害が起きても運用を継続したいなら、最低2つのアベイラビリティゾーンに配備しておく必要がある。HAの実装設計において、複数ゾーンにインスタンスを配備すると自動的に複数ゾーンに負荷分散してくれる Elastic Load Balancing が有効である。プライマリのインスタンスに対する全ての書込みは2つめのインスタンスにも確実にレプリケートされることで、2つのOracleインスタンスは同期している。この機能は Oracle Data Guard を含まないエディションも含め、全てのOracleのエディションで利用可能である。これは顧客に対し、今までの常識を超えた可用性を、きわめてコスト競争力高く提供している。図3（オリジナル資料参照）はAmazon RDSの高可用性アーキテクチャの例である。
スタンバイデータベースへのフェイルオーバーは一般的に3分くらいかかる、また、次のような場合に発生する：

• プライマリデータベースが配置されているアベイラビリティゾーンに可用性が失われた場合
• プライマリデータベースとのネットワーク接続が切れた場合
• プライマリデータベースのECU障害
• プライマリデータベースのストレージ障害
• データベースのインスタンスクラスをスケールアップしたりスケールダウンしたりする場合
• データベースソフトへのパッチ適用時

Multi-AZオプションを選択するには、データベース作成時に選択すればよいだけである。図４（オリジナル資料参照）はAWS Management Consoleでの選択方法である。
既に稼働中のOracle RDSデータベースをMulti-AZモードに変更することもできる。 Multi-AZでAmazon RDSを稼働させると、追加で以下のようなメリットもある。

• 日次バックアップはスタンバイインスタンスから取得されるため、プライマリのRDSインスタンスに対するI/O負荷がかからない。
• （自動マイナーバージョンアップを選択している場合）データベースエンジンのアップグレードが必要な場合にパッチはまずスタンバイ側に適用される。完了するとスタンバイをプライマリに昇格させる。可用性への影響はフェイルオーバー中の時間に限られるため、メンテナンスウィンドウの指定期間よりは結果的に短い。

■Amazon EC2 の高可用性アーキテクチャ

Amazon RDSのMulti-AZのようにスタンバイ・データベースを、好ましいのは異なるアベイラビリティ・ゾーンに準備することでOracle Databaseの可用性を高めることができる。プライマリのデータベースがフェイルしたら、スタンバイ・データベースにフェイルオーバーして新しいプライマリにすることができる。スタンバイ・データベースを構成するために、Oracleから2つの関連製品が提供されている。

• Oracle Data Guard を使っていくつかのスタンバイ・データベースが構成できる。スタンバイ・データベースは、プライマリ・データベースのバックアップコピーから初期構築される、Oracleの本番データベースとトランザクション的に一貫性のあるコピーである。いったんスタンバイ・データベースを作成して設定すれば、Oracle Data Guard がREDOログデータをスタンバイ・データベースに転送し、適用することで、自動的に整合性を維持する。Oracle Data Guard では3種類のスタンバイ・データベースが構築できる：

1. フィジカル（物理）：フィジカル・スタンバイ・データベースはプライマリ・データベースの内容を正確にレプリケーションする。データベース内のデータはプライマリ・データベースと同一になる。
2. ロジカル（論理）：ロジカル・スタンバイ・データベースはプライマリ・データベースのREDOログからデータとSQLを生成し、SQLのトランザクションとしてロジカル・スタンバイに再適用する。このようなことから、物理構造や構成はプライマリ・データベースと異なることになる。レプリケーションによる維持ではないため、変更が適用されている間もユーザーはロジカル・スタンバイ・データベースからの読取や、ロジカル・スタンバイ・データベースへの書込みを行う事ができる。しかし、データベースが利用できなくなりうるために、サポートされないオブジェクトもいくつかある。
3. スナップショット：スナップショット・スタンバイ・データベースはプライマリ・データベースからのREDOログの受信とアーカイブは行うが、適用は行わないため、リードレプリカや高可用性のために利用できるものではない。

• ロジカルあるいはスナップショット・スタンバイ・データベースには制限があるため、以降はフィジカル・スタンバイのみについて議論する。

• Oracle Data Guard はプライマリ・データベースとトランザクション一貫性のあるスタンバイ・データベースを維持し、プライマリ・データベースとスタンバイ・データベースの間のレプリケーションは同期あるいは非同期どちらかで構成ができる。Oracle Data Guard には保護性、可用性、パフォーマンスを最大化する3つのプロテクション・モードがある。AWS環境を最大限に活用するためには、これらのインスタンスを異なるアベイラビリティ・ゾーンに配置する必要がある。本番データベースが使用不可になったら、スタンバイ・データベースのいずれかを新しいプライマリとして切替えることで、インシデントによるダウンタイムを最小限に抑えることができる。

• Oracle Data Guard では、フィジカル・スタンバイ・データベースが読み込みオープン処理と、プライマリ・データベースのトランザクションのアーカイブ処理を同時にできないため、リードレプリカ構成はサポートされていない。Oracle Data Guard はマネージド・リカバリ・モードあるいは読取専用モードいずれかで機能させることはできるが、同時に両方のモードにはできない。Oracle Data Guard はデータ保護、高可用性、災害対策のためのものである。

• “Amazon EC2 でリードレプリカを作成する”の項で説明した Oracle Active Data Guard は、リードレプリカを構成するための Oracle Data Guard 上のオプションである。すでに記述したとおり Oracle Active Data Guard は、プライマリ・データベースからトランザクションのアーカイブを適用し続けながら、スタンバイ・データベースへの読取専用アクセスを可能にする。これにより、読込みのクエリやレポートをスタンバイ・インスタンスで稼働させたり、スタンバイ・インスタンスからバックアップを取得することができる。

Oracle Data Guard と Oracle Active Data Guard はともに、プライマリ・データベースの障害や災害によりフェイルオーバーするためのスレーブ・データベースを1つないし複数構築できるので、高可用性の基本構成として頻繁に利用されている。図５（オリジナル参照）はこのアーキテクチャの例である。

■サードパーティ製の高可用性ツール

Oracle Data Guard 以外にも、Amazon EC2 上でHA構成のデータベースを構成できるサードパーティ製のツールがある。たとえば、Dbvisit Standby は、Oracleスタンダード・エディションでもエンタープライズ・エディションでも、Oracleのスタンバイ・データベースを作成して管理することができる。（訳者注：Oracle Data Guard はEEのみの機能。Oracle Active Data Guard はEEのみで、さらにオプションライセンス）

■レプリケーション

レプリケーションは分散データベースシステムを構成する複数のデータベースで、テーブルなどのデータベース・オブジェクトをコピーして維持するためのプロセスである。一つのデータベースに適用された変更は、リモート・データベースに転送されて適用される前に、ローカルでキャプチャされて一時的に格納される。レプリケーションはさまざまな場所にある複数のサイトで同一のデータを共有するための分散データベース技術である。代替となるデータのアクセス方法を提供できるために、レプリケーションでアプリケーションの可用性を引き上げることができる。たとえば、アプリケーションは一部の分散データベースがダウンしていても、データのレプリカにアクセス可能であれば機能し続けることができる。Amazon EC2 では、レプリケーションは複数のアベイラビリティ・ゾーンにまたがってデータベースのコピーを構成できる、または複数のAWSリージョン間で災害対策戦略としてデータをレプリケーションすることができる。このセクションの論点は高可用性であるが、以下にリストしたレプリケーション技術は、複数データベースにワークロードを分散することでパフォーマンスを向上するために使用することもできる。

• Oracle Basic and Advanced Replication
  • Oracle Basic replication はデータをレプリケーションできるが、プロシージャやインデックスのようなその他のオブジェクトはレプリケーションできない。レプリケーションは一方向であり、スナップショット・コピーは読取専用である。
  • Oracle Advanced replication はマルチ・マスター設定をサポートし、レプリケーションされたどのインスタンスでもデータの更新が可能である。こちらはデータと、インデックスやプロシージャといったその他のオブジェクトもレプリケーションできる。

• Oracle GoldenGate
  • Oracle GoldenGate はリアルタイムにトランザクションデータをキャプチャ、変換、配信をするための高性能なソフトウェア・アプリケーションである。ログベースの双方向データ・レプリケーションも含まれる。これを使って、計画外の停止あるいは計画停止どちらのダウンタイムも排除するべく、システムのパフォーマンスやスケーラビリティを向上させることができる。このソフトウェアは、システムのアップグレード、移行、メンテナンス作業時のダウンタイムを最小化するように構成することができる。直近のデータで即時フェイルオーバーすることで災害対策という意味で使うこともできる。これは地域をまたいでリアルタイムに分散アプリケーションのデータを同期する。AWSでいえば、同一リージョン内のアベイラビリティゾーン間、あるいは別のリージョン間となりうる。

• サードパーティ製のレプリケーションソリューション
  • 前述の Oracle のツールにくわえて、複数のOracleデータベース間でレプリケーションを構成できるサードパーティ製のソリューションがある。Dbvisit Replicate や Quest SharePlex for Oracle がサードパーティ製ソリューションの例だ。

こちらの記事はなかの人（yoshidashingo）監修のもと掲載しています。
元記事は、こちら