こんにちは、GoodwaysのITチームです。私たちは15年以上にわたり、お客様のビジネスを支える複雑なITインフラの世界を共に歩んできました。そして、私たちが最も強調しているのはビジネス継続性です。今日の24時間365日休みなく動き続けるグローバル市場では、「データベースのダウンタイム」は単なる不便ではなく、収益損失・評判の毀損・顧客離れを招く潜在的災難です。
Oracleは、データベースを稼働させ、ビジネスを運営し続けるための強力な技術群を提供しています。しかし、これらの技術を導入することが単に手順書をなぞるだけのことではありません。お客様のビジネス要件、実際に直面する可能性のある問題を深く理解し、「理論上のHA」ではなく真の耐障害性を持つソリューションを構築することが重要です。
ここでは、Oracleの機能について無味乾燥な説明ではありません。数多の徹夜作業、困難な顧客事例、そして成功したHA実装から得た知見を共有したいと思います。RAC、Data Guard、そしてMAA哲学といった主要技術を、私たちの実践経験を通して解説します。私たちの目標は、Oracle HAの概念を解き明かし、お客様のビジネスを真に守るシステム構築手法をお見せすることです。
RPO & RTO – HA戦略の二本柱
具体的な解説の前に、よく耳にする2つの略語について簡単に触れておきましょう：
- RPO (Recovery Point Objective)：データ損失許容範囲を定義します。災害が発生した場合、「どの時点までのデータが復旧できれば許容範囲なのか？」という問いに答えるものです。ゼロデータ損失が求められるのか、数秒前の状態か、数分前か、あるいは1時間前でも問題ないのか、といった判断が求められます。
- RTO (Recovery Time Objective)：目標復旧時間を示します。障害発生後、「どれくらいの時間で業務を再開する必要があるか？」という問いに、秒単位での復旧が必要なのか、分単位、あるいは数時間でも許容されるのかを明確にします。
この2つの指標は、すべてのHA／DR（災害復旧）計画の不可欠な基盤です。採用する技術やシステム構成の複雑さ、さらにはコストにも大きく影響を与える要素です。これらの目標が全てのステークホルダー（IT部門とビジネス部門）によって最初に明確に定義・合意されていなかったために、うまくいかなかったプロジェクトが数多くあります。
基盤：Oracle Real Application Clusters (RAC) – フェイルオーバーだけではない
「Oracle高可用性」と聞いて真っ先に想起されるのがOracle RACです。中核機能として、Oracle RACは異なるサーバー（ノード）上で動作する複数のOracleデータベース・インスタンスが、同一の共有データベース・ストレージに同時にアクセスすることを可能にします。
航空機の複数エンジンに例えましょう。1つのエンジンが故障しても、他のエンジンが飛行機を飛ばし続けることができます。
RACが提供するもの：
- インスタンスレベルでの高可用性：**RACの中核的な利点です。クラスター内のサーバ（ノード）がハードウェア障害や計画メンテナンスでダウンした場合、データベースサービスは自動的に生存ノードにフェイルオーバーします。アプリケーションが適切に構成されていれば（SCANリスナー、接続負荷分散、透明なアプリケーションフェイルオーバー-TAFを使用）、ユーザーは最小限の中断でサービスを受けることができます。
- スケーラビリティ（HAの議論で見落とされがち）：**高可用性（HA）が主要な目的ですが、RACは優れたスケーラビリティを提供します。処理能力が不足している場合は、クラスターにノードを追加できます。この「スケールアウト」機能は、成長するアプリケーションにとって非常に有用です。
- ローリングパッチ適用とアップグレード：**適切な計画のもとで、ノード単位でパッチ適用やマイナーアップグレードを実行可能です。これにより、データベース・サービス全体の稼働状態を維持しつつ、計画停止時間を大幅に削減できます。
私たちの「現場からの」RAC評価：
- インスタンスレベルで「アクティブ-アクティブ」：すべてのインスタンスは稼働しており、積極的にトランザクションを処理しています。しかし、真のアプリケーションレベルでのアクティブ-アクティブには、アプリケーション自体が全ノード跨いだ作業分散・接続制御を可能とする設計が必要です。RACがあらゆるアプリケーションをアクティブ-アクティブ化すると誤解されているケースが多く見られます。
- 複雑さは現実：RACは共有ストレージインフラ（通常SAN）、ノード間通信用高速なプライベートインターコネクト（「キャッシュ・フュージョン」の中核）、Oracle Grid Infrastructure（クラスターウェア）を伴います。これらのコンポーネントは正しく設計され、設定され、管理される必要があります。「セットして放置する」だけではありません。例えば、プライベートインターコネクトは神経系のようなもので、低遅延性と堅牢性が不足すればRAC性能は低下します。
- ライセンスコスト：正直なところ、Oracle RACは安くはありません。Enterprise EditionとRACオプションが必須であり、多くの企業にとって重要な要因です。そのため、RPO/RTOに基づく真の高可用性(HA)要件とスケーラビリティニーズを理解することが重要です。
- RACが適切なのはいつか？：インスタンスレベルでの高可用性が最も重要であり、コンピュータ容量をスケールアウトする必要がある場合や、パッチ適用のために計画的ダウンタイムの最小化が不可欠な場合です。サイトレベル災害復旧が主な目的なら、RAC単体では不十分---更なる対策が必要です。
単一データセンターを超えて：Oracle Data Guard – 災害時のライフライン
RACがデータセンター内の障害（サーバーの故障など）から保護する一方、火災、洪水、または大規模な停電によってデータセンター全体がオフラインになった場合はどうなりますか？ここでOracle Data Guardが登場します。
Data Guardは、本番用データベースの1つ以上のスタンバイ（バックアップ）コピーを作成し、維持します。これらのスタンバイデータベースは、同じデータセンター内（ストレージ障害からの迅速なローカルリカバリのため、純粋なDRではあまり一般的ではありません）または、より一般的には地理的に離れたデータセンターに配置できます。
Data Guardがどのように魔法をかけるのか：
- ログ配送と適用：REDOデータ（プライマリデータベースに加えられたすべての変更の記録）がプライマリデータベースからスタンバイデータベースに継続的に送信されます。スタンバイデータベースは、このREDOデータを適用して同期状態を維持します。
-
保護モード：Data Guardは、データ保護とパフォーマンスのバランスを取るためのさまざまな保護モードを提供します：
- 最大パフォーマンス（デフォルト）：非同期配送。プライマリデータベースの最高性能を発揮するが、未転送REDOデータが存在する場合のデータ損失リスクあります。これは実運用で最も一般的な選択肢です。
- 最大可用性：主に同期転送。プライマリパフォーマンスよりデータ保護を優先し、可能な限りゼロのデータ損失を目指しますが、スタンバイとのネットワークが遅い場合、プライマリのパフォーマンスに影響が出ることがあります。
- 最大保護：同期転送。1つ以上のスタンバイへのREDO書込みが不能になるとプライマリデータベースが停止します。ゼロデータ損失を保証しますが、スタンバイリンクが失敗した場合、最も高いパフォーマンスへの影響とプライマリ障害のリスクがあります。厳格な要件から採用頻度は低いです。
-
ロール移行：
- スイッチオーバー：計画的な主従逆転。プライマリがスタンバイになり、スタンバイが新しいプライマリになります。プライマリサイトの計画的なメンテナンスに使用されます。
- フェイルオーバー：プライマリデータベースが利用不能時の非計画移行。スタンバイが有効化され、新しいプライマリになります。これがDRの発動です。
私たちの「現場からの」Data Guard評価
- RPO/RTOがモード選択を左右する：データ損失（RPO）とダウンタイム（RTO）に対する許容度は、どのData Guard保護モードと構成を選択するかに大きく影響します。「ただなんとなく」という理由で最大保護を選ばないでください。
- Active Data Guard (ADG)はゲームチェンジャー：Enterprise Editionオプションにより、物理スタンバイデータベースはRedo適用中に読み取り専用アクセスを可能になります。レポート、バックアップ、クエリをスタンバイにオフロードして、プライマリの負荷を軽減し、DR投資をより有効に活用できます。可能な限りADGを強く推奨します。
- フェイルオーバーを定期的にテストしてください：テストされていないDR計画は単なる紙切れです。定期的なスケジュール化されたDR訓練は絶対条件です。これにより、実際の災害が発生する前に、ネットワーク、ストレージ、アプリケーション切り替え手順、および人的エラーの問題を発見できます。私たちは厳格なテストを通じて、クライアントが「動作する想定」から「動作を確認済み」に移行するのを支援してきました。
- **ネットワークが鍵：**プライマリサイトとスタンバイサイト間のネットワークリンクの品質と帯域幅は、特に同期モードやREDO生成率が高い場合に重要です。REDO適用遅延はRPOを危険にさらす可能性があります。
- 「Far Sync」インスタンス：ゼロデータ損失（最大可用性のような）を望むが、DRサイトが同期レプリケーションが効率的に機能するには遠すぎる場合、OracleはFar Syncインスタンスを提供しています。これらの軽量インスタンスはプライマリにより近く配置され、REDOデータを同期的に受け取り、その後リモートスタンバイに非同期で転送します。これは地理的制約を克服する巧妙な方法です。
最高峰：Oracle Maximum Availability Architecture (MAA) – 総合的な設計図
これまでに、ローカルHA用のRACと災害復旧（DR）用のData Guardを紹介しました。しかし、これらはどのように組み合わさるのでしょうか？また、バックアップ、データ破損保護、アプリケーション統合などの他の重要な側面はどうでしょうか？ここで登場するのが、Oracle Maximum Availability Architecture (MAA) です。
MAAは単一の製品ではなく、最適な高可用性、データ保護、および災害復旧を実現するためのOracleのベストプラクティス設計図です。これは、Oracleの技術、機能、および運用実践の組み合わせを活用しています。
MAAの主要な原則：
- あらゆるレベルでの冗長性：サーバー、ストレージ、ネットワーク、データベースインスタンス
- 単一障害点なし：中核的な原則
- データ保護：様々なメカニズムによるデータ損失の防止
- 迅速な回復：RTOの最小化
- 検出と修復：積極的な監視と問題の迅速な解決
MAAは通常、ローカルHAのためにプライマリサイトにRACを配置し、そのRACデータベースをData Guardを使用してDRサイトのスタンバイRACデータベースにレプリケートすることを含みます。これにより、各サイト内でのインスタンスフェイルオーバーとサイト間でのサイトフェイルオーバーが可能になります。
私たちの「現場からの」MAA評価：
- **階層的アプローチ：**Oracleは、可用性とデータ保護のレベルを高めるために、MAAの異なる階層（ブロンズ、シルバー、ゴールド、プラチナ）を定義しています。最初から「フルプラチナ」を目指す必要はありません。目標は、ビジネス要件と予算に合った階層を選ぶことです。
-
RACとData Guardを超えて、MAAは以下も重視します：
- フラッシュバック技術：完全な復元なしに論理的エラー（例：誤ったDROP TABLE）を素早く元に戻すため。非常に強力です。
- RMAN（Recovery Manager）：堅牢なバックアップと復旧戦略のため。
- ASM（Automatic Storage Management）：簡素化された弾力性のあるストレージ管理のため。
- Oracle GoldenGate（オプションだが強力）：ゼロダウンタイム移行、アップグレード、またはサイト間のアクティブ-アクティブレプリケーションなどのより複雑なシナリオのため（これには独自の複雑さがあり、単純なMAAのチェックボックスではありません）。
- 人的要素が重要：MAAは技術だけではありません。これらの相互接続されたシステムを理解し、DR訓練を効果的に実行し、複雑な問題をトラブルシューティングできる熟練したDBAが必要です。チームのスキルへの投資は、ソフトウェアへの投資と同じくらい重要です。
- 強固な基盤から始める：最初はより単純なHAセットアップを目指していても、MAA原則を念頭に置いて設計することで、後で進化させ、より多くの保護層を追加することが容易になります。私たちは常に将来を見据えて構築することを心がけています。
私たちの指針となる哲学：HAは製品ではなく、パートナーシップである
過去15年間で得られた最大の教訓は、真に堅牢なOracleの高可用性を実現するには、技術を問題に盲目的に適用するだけでは不十分だということです。それは、お客様のビジネスに関する深い対話から始まります。何が絶対に稼働し続けなければならないのか、どのようなデータ損失を許容できないのか、そして問題が発生した場合にどれだけの速さで復旧する必要があるのかということです。
私たちの初心は、単にHA「ソリューション」を販売することを超え、クライアントのビジネス継続性の旅における本物のパートナーとなることでした。私たちは以下のことを学びました：
- シンプルさは過小評価されがちである：時には、適切に構成された単一インスタンスのデータベースに、しっかりと構築されたData Guardスタンバイと厳密にテストされたリカバリ手順を組み合わせた方が、完全に理解されておらず適切に管理されていない複雑なRAC設定よりも信頼性が高く、コスト効率が良い場合があります。
- テストはすべてである：私たちが常に主張するように、バックアップをテストせよ、フェイルオーバーをテストせよ、フェイルオーバー時のアプリケーション動作特性をテストせよ。テストしなければ、実態はわかりません。
- ドキュメンテーションは重要である：HA/DR手順に関する明確で簡潔、かつ最新のドキュメンテーションは、実際の障害発生時にプレッシャーのかかる中で特に重要です。
- それは継続的なプロセスである：ビジネスニーズは変化し、技術は進化します。HA戦略は静的であってはなりません。定期的なレビューと改善が不可欠です。