OceanBaseで実現する災害対策：バックアップからマルチクラウド構成まで

1. クラウド時代の事業継続とデータベースの役割

DX（デジタルトランスフォーメーション）が進むなか、事業継続は技術上の課題にとどまらず、経営戦略に関わる重要なテーマとなっています。ECサイトが大型セール中に1時間停止すれば、多額の売上を失う可能性があります。金融機関のシステム停止は規制当局による厳しい処分につながり、SaaSのサービス停止は顧客の大量解約を招くおそれがあります。

データは、こうした事業の中核をなす資産です。大規模な障害が発生しても事業を継続できるかどうかは、データベースの災害対策（DR）に大きく左右されます。

多くの企業が、すべてのリソースを単一のクラウドベンダーに集約しています。しかし、この構成には明確なリスクがあります。どのプロバイダーも100%の可用性を保証できるわけではなく、リージョン規模の障害やネットワークの停止は起こり得ます。また、特定のプロバイダーに過度に依存すると、契約交渉や将来の構成変更を自社主導で進めにくくなります。業種によっては、規制によりデータの保管先を複数拠点に分散することが求められます。

ここで押さえておきたいのは、高可用性（HA） と 災害対策（DR） では、対処する障害の規模が異なるという点です。

• 高可用性（HA）： 個々のノードなどの障害が発生しても、自動的に切り替えてサービスを継続するための仕組みです。OceanBaseでは、Paxos合意アルゴリズムに基づく3レプリカ構成により、単一ノードの障害時に RPO＝0、RTO＜8秒 で自動フェイルオーバーを実現します。
• 災害対策（DR）： データセンター全体の停電やリージョン全体の停止といった大規模障害に備えます。そのためには、複数のデータセンターやリージョン、さらには複数のクラウドにまたがる構成が必要です。

本記事ではDRに焦点を当て、OceanBaseが提供する各種構成の仕組みと選び方を解説します。

2. DRの基本指標と構成

DR構成を評価する際には、次の3つの指標が重要になります。

• RTO（Recovery Time Objective：目標復旧時間）
  障害の発生から業務の復旧までに許容できる最大時間です。金融の基幹システムでは、通常、30秒未満のRTOが求められます。一方、一般的な業務システムでは、数時間を許容できる場合もあります。
• RPO（Recovery Point Objective：目標復旧時点）
  障害発生時に許容できるデータ損失を時間で表す指標です。金融の基幹取引ではRPO＝0、つまりデータ損失ゼロが求められる一方、開発・テスト環境では数時間分のデータ損失を許容できる場合もあります。
• SLA（Service Level Agreement：サービスレベル合意）
  業務システムの可用性などについて、サービス提供者が保証する水準を定めたものです。DR構成は、SLAに定められたRTOとRPOの要件を満たすように設計します。

OceanBaseのDR構成を比較する

OceanBaseは、バックアップによる基本的なデータ保護から、高度な事業継続対策まで、幅広いDR構成を提供しています。それぞれ、復旧時間、データ保護の水準、コスト、構築・運用の複雑さが異なります。

障害への対応範囲という観点では、OceanBaseのDR構成は次の3段階に分けられます。

1. 単一クラスター内の複数レプリカ構成：Paxosに基づき、ノードやデータセンター単位の障害に備えます。
2. リージョン間のプライマリ／スタンバイ構成：都市をまたいで拠点を分散し、リージョン規模の障害に備えます。
3. クラウド間のアクティブ／アクティブ構成：最も高いレベルのDR対策を実現します。

これらは段階的に保護を強化するための構成です。多くの企業では、業務の重要度に応じて保護レベルを分けています。最重要システムにはアクティブ／アクティブ構成、重要システムにはプライマリ／スタンバイ構成、それ以外にはバックアップからの復旧を採用することで、保護の水準とコストのバランスを取ります。

3. 業務要件に合ったDR構成を選ぶ

どの業務にも最適なDR構成があるわけではありません。業務ごとの要件に合わせて選ぶことが重要です。

• スタートアップや非基幹システム：コストを重視し、復旧まで数時間を許容できる場合は、バックアップからの復旧が適しています。
• オンライン教育やECなどのオンラインサービス：分単位での復旧が必要で、費用対効果も重視する場合は、リージョン間のプライマリ／スタンバイ構成が適しています。
• フィンテックや基幹取引システム：規制上、秒単位での切り替えとデータ損失ゼロが求められる場合は、クラウド間のアクティブ／アクティブ構成が適しています。

ここからは、それぞれの仕組みを詳しく見ていきます。

バックアップからの復旧

定期的にバックアップを取得し、必要なときに復元するという方法です。リアルタイムのデータ保護を目的とするものではありませんが、最小限のコストで基本的なデータ保護を実現できます。

クラウドデータベースサービスのOceanBase Cloudは、次のバックアップ・復元機能を提供しています。

バックアップの種類

• 物理バックアップ： データのコンパクション処理時点のベースラインデータを取得し、それ以降に蓄積されたコミットログと組み合わせて、データベース全体の状態を物理レベルで復元します。
• 論理バックアップ： テーブル、インデックス、ビュー、ストアドプロシージャなどの論理構造に基づいてバックアップを取得します。データベース、テーブル、テナントなど、必要な単位で対象を柔軟に選択できます。

バックアップの設定

• データバックアップ： スケジュールは週単位または月単位で設定でき、実行時刻や保存期間も指定できます。保存期間は2〜7,200日です。実行時刻は、業務負荷の低い時間帯に設定することを推奨します。
• ログバックアップ： 自動的に有効になり、任意の時点に復元するポイントインタイムリカバリ（PITR）を可能にします。

複数のバックアップ方式による保護

• ローカルバックアップ： 日常的な復旧に使用する一次バックアップです。
• アーカイブバックアップ： 長期保存に対応し、過去データの保管に適しています。
• 遠隔地バックアップ： リージョンをまたいでデータを保護します。
• スパースバックアップ： 複数の保持ポリシーを組み合わせ、必要なバックアップを選択的に保存することで、ストレージコストを削減します。

復元機能

• 任意の時点への復元（PITR）に対応しています。

この方式は、開発・テスト環境、社内管理システム、過去データのアーカイブに適しています。また、より高度なDR構成を補完する最後の復旧手段としても役立ちます。

リージョン間のプライマリ／スタンバイ構成

クラウド間のプライマリ／スタンバイ構成では、プライマリが業務を処理し、スタンバイがリアルタイムにデータを同期します。 プライマリが読み書きを処理する一方、スタンバイはデータ同期によってプライマリとの整合性を維持します。

プライマリに障害が発生した場合は、スタンバイが数分以内に業務を引き継ぎます。プライマリとスタンバイを異なるクラウドに配置することで、クラウド単位の障害に備えられます。

OceanBase Cloudのクラウド間プライマリ／スタンバイ機能は、次の仕組みを備えています。

共通の接続エンドポイント

プライマリとスタンバイで共通の接続エンドポイントを提供します。通常時はプライマリに接続し、障害による切り替え後は、スタンバイから昇格した新しいプライマリに接続するように名前解決先が自動的に更新されます。

アプリケーション側で接続先アドレスを変更せずにアクセスを再開できるため、DR対応に伴うアプリケーションの改修を大幅に抑えられます。

2つのデータ同期方式

業務要件に応じて、ネットワーク経由でログを直接転送する方式と、アーカイブログを経由する方式を選択できます。

• 直接転送方式： VPC間接続、専用線、インターネットなどを使ってプライマリとスタンバイを接続します。ログ転送サービス（Log Transport Service）がトランザクションログをリアルタイムに転送し、スタンバイ側のログ再生サービス（Log Replay Service）がメモリ上のMemStoreに適用します。これにより、ミリ秒単位の遅延での同期を実現します。
• アーカイブログ方式： プライマリがトランザクションログを定期的にオブジェクトストレージに保存します。スタンバイはオブジェクトストレージからアーカイブログを読み込み、自身のデータに適用します。ある程度の同期遅延を許容でき、コストを抑えたい業務に適しています。

単一または複数のスタンバイを配置

1つのプライマリに対して、1つまたは複数のスタンバイを配置できます。

クラウドAにプライマリ、クラウドBにスタンバイを配置する1対1の構成は、標準的なDR用途に適しています。複数のスタンバイを配置する構成では、冗長性をさらに高めながら、複数リージョンのDR要件にも同時に対応できます。

フェイルオーバーとスイッチオーバー

障害発生時のフェイルオーバーと、計画的に役割を切り替えるスイッチオーバーに対応しています。

• フェイルオーバー： プライマリの障害を受けて、システムが業務トラフィックをスタンバイへ自動的に切り替えます。通常時のスタンバイは業務トラフィックを処理せず、DRに備えて待機します。プライマリに障害が発生すると、共通エンドポイントの名前解決先が更新され、スタンバイがすべての読み書きを引き継ぎます。
• スイッチオーバー： 運用上の判断によってプライマリとスタンバイの役割を切り替えます。スタンバイが新しいプライマリとして速やかに業務を引き継ぎ、利用者は切り替えを意識せずに業務を再開できます。

どちらの場合も、共通エンドポイントと連携して、トラフィックを新しいプライマリへ自動的に振り分けます。

この構成は、オンライン教育やECなど、サービス停止の影響が大きいオンラインサービスに適しています。企業の基幹ERP・CRM、秒単位の復旧までは求められないものの分単位での復旧が必要な業務、リージョンをまたぐDR対策が必要な金融・保険システムにも適用できます。

クラウド間のアクティブ／アクティブ構成

アクティブ／アクティブ構成の特長は、2つのクラウド環境で同時に業務を処理し、障害時にも利用者に意識させることなく切り替えられる点です。

OceanBase Cloudは、AWS、Google Cloud、Alibaba Cloud、Tencent Cloudなどのクラウドベンダーへのインスタンスのデプロイに対応し、クラウドをまたぐアクティブ／アクティブ構成の基盤を提供します。

プライマリ／スタンバイ構成と異なり、アクティブ／アクティブ構成では両拠点が読み書きを処理し、リアルタイムの双方向同期によってデータの整合性を維持します。一方のクラウド環境に障害が発生すると、もう一方がすべての業務トラフィックをシームレスに引き継ぎます。

金融取引、オンライン決済、リアルタイム通信など、高い事業継続性が求められる業務では、アクティブ／アクティブ構成が有力な選択肢の一つとなります。

OceanBase Cloudでは、クラウド間ネットワーク、データ同期、競合処理を中心に、この構成を支える仕組みを最適化しています。

クラウド間接続の構築・運用を提供

異なるクラウドを接続するには、専用線、インターネット、クラウドの広域ネットワークサービスなどが必要です。OceanBase Cloudでは、クラウド間ゲートウェイサービスを通じて、ネットワークの構築、監視、運用をプラットフォーム側で行います。

ユーザーが同期元と同期先のクラウドベンダーおよびリージョンを選択すると、データ同期タスクが必要なネットワークサービスを自動的に判定します。ユーザー自身がクラウド間ネットワークの構築方法を意識する必要はありません。

同期元・同期先に応じたコンポーネント配置

クラウド間のネットワーク遅延が転送性能に与える影響を抑えるため、OceanBase Cloudではコンポーネントの配置を最適化しています。ログ解析コンポーネントは同期元と同じクラウド・リージョンに、データ書き込みコンポーネントは同期先のリージョンに配置します。

同期元の解析コンポーネントで同期対象外のデータの大部分を除外し、不要なデータ転送を抑えます。また、書き込みコンポーネントを同期先の近くに配置することで、ネットワーク遅延による書き込み性能の問題を回避します。

転送データの暗号化

クラウド間ゲートウェイの通信は、AES-128-GCMを用いてネットワーク層で暗号化します。ゲートウェイ間のセッション鍵は、OMSのプライベートネットワーク内にある安全な制御用トンネルを通じて配布し、定期的にローテーションすることで、クラウド間のデータ転送の安全性を確保します。

双方向同期とレプリケーションループの防止

両拠点で読み書きを行うには、リアルタイムの双方向同期が必要です。OceanBase Cloudのデータ同期機能は、MySQL、Oracle、OceanBaseを対象に、異種データベース間の双方向同期に対応しています。

双方向同期で課題となるのが、レプリケーションループです。一方で発生した更新を他方に適用すると、その適用によって新たなログが生成されます。このログを再び同期対象にすると、同じ更新が元のデータベースに送り返されてしまいます。

OceanBase Cloudでは、データベースごとに異なる方法でループを防止します。

• MySQL・Oracle： 同期による更新をトランザクション管理用テーブルに記録します。ログ解析前にこのテーブルを参照し、該当する更新を同期対象から除外します。
• OceanBase： 書き込みコンポーネントの thread_id を使って同期による更新を識別し、ログ解析時に自動的に除外します。

リアルタイムの競合検出

両拠点で同じ一意キーを持つデータに対して同時に書き込みや更新を行うと、競合が発生する可能性があります。

OceanBase Cloudの双方向レプリケーションでは、こうした競合をリアルタイムに検出し、あらかじめ設定した方針に従って処理します。同期先のデータを上書きする、競合した更新を適用せず同期先のデータを保持する、競合を記録して手動で対応する、といった方法を選択できます。競合の記録はダウンロードでき、原因調査に利用できます。

クラウド間のアクティブ／アクティブ構成は、単一クラウド内でPaxosにより実現される高可用性を基盤としています。3レプリカ構成は、単一クラウド内のノード障害に対し、RPO＝0、RTO＜8秒で自動フェイルオーバーを実現します。クラウド間のアクティブ／アクティブ構成は、そのうえでクラウドベンダー単位の障害に対応します。

両者は互いを補完し、ノード単位からクラウド単位までをカバーする高可用性の仕組みを構成します。

主な用途は、金融の基幹取引、決済・清算システム、オンライン決済、リアルタイム通信など、無停止での運用が求められる業務です。また、規制上、クラウド間のDR対策が必須となる金融機関にも適しています。

4. DR構成を導入する際のポイント

3つのDR構成には、それぞれ適した役割があります。バックアップからの復旧は、最小限の費用で基本的なデータ保護を実現し、コストを優先する場面に適しています。リージョン間のプライマリ／スタンバイ構成は、適切な費用で確かな保護を確保し、費用対効果を重視する構成です。クラウド間のアクティブ／アクティブ構成は、必要なリソースを投入することで最高水準の保護を実現し、遵守が求められるコンプライアンス要件に対応します。

導入にあたっては、次の4点が重要です。

1. 業務の重要度に応じて保護レベルを分ける
   すべてのシステムに同じ構成を適用する必要はありません。最重要システムにはアクティブ／アクティブ、重要システムにはプライマリ／スタンバイ、それ以外にはバックアップからの復旧というように、要件に応じて選びます。
2. DR構成を導入してもバックアップを継続する
   拠点障害に備えるDR構成と、誤削除や誤更新などに備えるバックアップでは、役割が異なります。アクティブ／アクティブ構成を導入していても、バックアップは欠かせません。
3. 定期的に復旧訓練を行う
   復旧訓練を行っていないDR構成は、理論上の実現可能性にとどまります。実際に機能することを確かめる必要があります。
4. シンプルな構成から段階的に拡張する
   まずバックアップからの復旧を整備し、事業の成長に合わせて、プライマリ／スタンバイ、アクティブ／アクティブへと構成を発展させることができます。

OceanBaseは、Paxosに基づく分散アーキテクチャとテナント単位のプライマリ／スタンバイ技術を基盤に、バックアップからの復旧からアクティブ／アクティブ構成まで、幅広いDR対策を提供します。シンプルで経済的な構成から、より高度な保護を実現する構成まで、業務要件に応じて選択できます。