こんにちは！インサイトテクノロジーの松尾です。
本記事では、AWS 上で Oracle を運用する際の可用性の選択肢について解説します。
なお、「Oracle Database@AWS」については詳細が不明なため、本記事では考慮しません。
では、Oracle を AWS で運用するには、どのような選択肢があるのでしょうか？
本記事では、主要な選択肢を整理し、それぞれの特徴を可用性の観点から解説します。
はじめに：パブリッククラウドにおける可用性の重要性
AWS のようなパブリッククラウドを利用する際、どの程度可用性を考慮すべきでしょうか？
システムの重要度によりますが、クラウド環境でも障害は発生し得るため、適切な対策が必要です。
以下に、過去のパブリッククラウドの障害事例を示します。
| 時期 | クラウド | 分類 | 概要 |
|---|---|---|---|
| 2024年8月 | Azure | 設定変更 | Azure Front Door (AFD) の設定変更により、北米と南米で大規模障害 |
| 2024年7月 | Azure | 設定変更 | Azure の構成変更により Microsoft 365 全体が影響を受け、Teams や Power BI などが利用不能 |
| 2024年5月 | GCP | 人為的ミス | Google Cloud の設定ミスにより UniSuper のプライベートクラウドアカウントが削除 |
| 2023年6月 | Azure | DDoS攻撃 | 「Anonymous Sudan」による DDoS 攻撃で Azure ポータルや OneDrive へのアクセスが影響 |
| 2023年6月 | AWS | 障害 | AWS のネットワーク障害により EC2 や RDS などが一時停止し、数時間影響が継続 |
| 2023年4月 | GCP | 災害 | パリの Google データセンター火災により、Google Cloud Storage など 90 以上のサービスが停止 |
これらの事例からも、パブリッククラウド環境においても障害対策は不可欠であることがわかります。
継続性が求められるシステムでは、単一クラウドに依存せず、複数リージョンやマルチクラウド戦略を組み合わせた DR 対策が重要です。
本記事では、AWS 上で Oracle を運用することを想定し、DR 対策の選択肢を整理します。
- 本記事ではデータベースの DR 対策に焦点を当てていますが、システム全体の DR 対策も同様に重要です。
- 重要なデータが残っていれば、システムの復旧が容易になるのも事実です。
- システム全体の DR 計画として、以下の点を総合的に検討する必要があります。
- アプリケーションの復旧
- データの復旧
- システム全体の復旧
AWS で Oracle を運用する際には、以下の 4 つの選択肢があります。
- RDS for Oracle
- RDS Custom for Oracle
- Oracle on EC2
- Oracle Database@AWS（※詳細不明のため本記事では触れません）
一般的によく聞く選択肢
- RDS for Oracle は便利
- RDS for Oracle を使うなら SE でないとコストメリットが出しにくい
- RDS for Oracle を使えない場合は EC2 で対応
Amazon RDS Custom は、通常の RDS と EC2 の中間的なサービスです。
RDS のマネージド機能を持ちつつ、OS へのアクセスが可能なため、必要なソフトウェアをインストールできます。
ただし、完全なマネージドサービスではないため、運用負荷が増す点には注意が必要です。
詳細はこちら → Amazon RDS Custom
各選択肢の比較
| Oracle on EC2 | RDS for Oracle | RDS Custom for Oracle | |
|---|---|---|---|
| 特徴 | OS から DB まで完全カスタマイズ可能 | フルマネージド、簡単設定 | カスタム構成が可能なマネージドサービス |
| メリット | Oracle の全機能対応、柔軟な設定 | マルチ AZ 高可用性、自動バックアップ | OS レベルのアクセス、Data Guard、一部サードパーティ製品対応 |
| 制約 | 管理負担が大きく、手動運用が必要 | 一部エンタープライズ機能非対応 | 一部マネージド機能制限、コストが高め |
| 利用可能バージョン | 11g〜21c（フルサポート） | 19c、21c | 12c R1、12c R2、18c、19c、21c |
| HA オプション | Data Guard（同期・非同期）で別 AZ・リージョンにレプリケーション | マルチ AZ、リードレプリカ、クロスリージョンリードレプリカ | Data Guard（非同期）で別 AZ・リージョンにレプリケーション |
| RPO | RPO：0（同期）〜数分（非同期） | RPO：0 | RPO：数秒〜数分（非同期） |
| RTO | RTO：数分〜数十分（手動フェイルオーバー） | RTO：数分（自動フェイルオーバー） | RTO：数分〜数十分（手動フェイルオーバー） |
RDS for Oracle は最も手軽な選択肢ですが、対応バージョンの制約や SE 以外のコスト面の課題があります。
要件に応じて EC2 や RDS Custom も検討する必要があります。
Amazon RDS for Oracle を使う場合の可用性オプション
Amazon RDS for Oracle を利用する際に選択可能な可用性オプションについて、詳細に整理します。
| 可用性オプション | 機能概要 | RPO | RTO | エディション |
|---|---|---|---|---|
| マルチAZ配置 | プライマリとスタンバイ DB を異なる AZ に配置し、同期レプリケーションを実行。障害時には AWS が自動でスタンバイにフェイルオーバー。 | RPO: 0（同期レプリ） | RTO: 数分（自動フェイルオーバー） | EE、SE |
| リードレプリカ (Active Data Guard) | 同一リージョン内で読み取り専用のレプリカを作成し、負荷分散やバックアップ用途に利用可能。 | RPO: 数秒〜数分（非同期レプリ） | RTO: 数分（手動でレプリカを昇格） | EE |
| マウントされたレプリカ (Data Guard) | ユーザー接続を受け付けない、クロスリージョンの災害対策用途。 | RPO: 0〜数分（同期・非同期レプリ） | RTO: 数分（リードレプリカより早い） | EE |
| クロスリージョンリードレプリカ (Active Data Guard) | 別リージョンに読み取り専用のレプリカを作成し、DR 用途に利用可能。障害時には手動で昇格しプライマリとして使用可能。 | RPO: 数秒〜数分（非同期レプリ） | RTO: 数分〜数時間（手動でレプリカを昇格） | EE |
| クロスリージョンバックアップ | プライマリ DB のスナップショットを別リージョンにバックアップし、災害発生時のリカバリに使用。 | RPO: バックアップ間隔に依存（通常 24 時間） | RTO: 数時間〜数日（バックアップから復元） | EE、SE |
これらのオプションから、特に EE（Enterprise Edition）向けに多くの可用性機能が提供されていることがわかります。
また、Amazon RDS for Oracle の強みは、これらのオプションを比較的簡単に設定・利用できる点にあります。
一般的な可用性オプションの選択例
- まずはマルチ AZ を有効化する（AZ 障害対策として基本）
-
リージョン障害にも備えたい場合
- EE ユーザー: Data Guard のライセンスを利用し「マウントされたレプリカ」を設定
- SE ユーザー: RPO/RTO を妥協し、「クロスリージョンバックアップ」を利用
この選択肢でも多くのケースでは十分対応できますが、SE を利用している場合で RPO/RTO を妥協できないケース ではどうすればよいでしょうか？
Amazon RDS for Oracle で DR やその他の要件を満たせない場合の選択肢
以下のような場合には、RDS for Oracle を使うことができないため、その他の選択を考える必要があります。
以下のようなケースでは、RDS for Oracle を利用できないため、別の選択肢を検討する必要があります。
SE を使いたいが、リージョン障害にも備えたい
バックアップ運用では RPO/RTO 要件を満たせない
この場合、RDS for Oracle では対応が難しくなります。
そのため、以下の選択肢を検討する必要があります。
- EC2 や RDS Custom for Oracle を利用
- 3rd Party の DR ソフトウェアを活用
これにより、必要な DR 対策を講じることが可能です。
ただし、RDS for Oracle が提供する運用の省力化は一部犠牲になるため、運用負担とのバランスを考慮する必要があります。
10g、11g、12c、18c を利用したい
アプリケーションの制約などにより、10g、11g、12c、18c を使用する必要がある場合、RDS for Oracle では対応できません。
この場合も、以下の選択肢を検討する必要があります。
- EC2 を利用し、手動で環境を構築
- RDS Custom for Oracle を活用
- 必要に応じて DR 対策を併用
特に、古いバージョンの Oracle を運用する場合は、セキュリティやサポートの問題も考慮しながら適切なアプローチを選択することが重要です。
おわりに
パブリッククラウドでも、散発的にリージョンレベルの障害が発生します。重要なシステムであれば、適切な DR 対策を講じることが不可欠です。
AWS で Oracle を運用する場合、まず候補となるのは Amazon RDS for Oracle です。
RDS for Oracle には複数の可用性オプションがありますが、選択するエディションやバージョンによって利用できる機能が異なります。
RDS for Oracle では DR 要件を満たせない場合、以下の選択肢を検討する必要があります。
- EC2 を活用し、柔軟な構成を組む
- RDS Custom for Oracle を利用
- 3rd Party の DR 対策ソフトウェアを導入
これらの選択肢を組み合わせることで、より強固な DR 戦略を構築できる可能性があります。
お知らせ
弊社インサイトテクノロジーは、Oracle SE で利用可能な DR ソフトウェア Dbvisit StandbyMP の総販売代理店です。
Oracle SE での DR 対策に 3rd Party ソフトウェアの導入を検討されている方は、ぜひお問い合わせください。
関連投稿のご案内
必要に応じて以下の投稿もぜひご参照ください。