OceanBaseのアービトレーションサービスとは？ 2F1A構成で実現するRPO=0の高可用性

分散データベースで高可用性を設計する際、2ノードのプライマリ・スタンバイのような偶数レプリカ構成には根本的な弱点があります。ノード障害やネットワーク分断が起きると過半数を確保できず、安全に新しいリーダーを選べなくなるためです。

この問題への一般的な対策は、3つ目の参加者を加えて投票総数を奇数にすることです。そうすれば、スプリットブレインを防ぎながら合意形成を進めやすくなります。

ただし、この3つ目の参加者が必ずしも完全なデータレプリカである必要はありません。必要なのは、投票に参加し、障害時にクラスタの合意形成を支えることです。OceanBase 4.xでは、この役割を「アービトレーションサービス」が担います。3台目のフルレプリカを置かずに、投票と裁定に必要な役割だけを低コストで補うのが狙いです。

従来の手法：データ安全性とインフラコストのトレードオフ

プライマリ・スタンバイ構成は、もっとも一般的な構成のひとつです。最大パフォーマンスのような非同期レプリケーションでは、スタンバイ側のデータは通常プライマリより遅れます。そのため、プライマリ障害時には直前にコミットされたデータが失われる可能性があり、RPOはゼロになりません。

一方、最大保護のような完全同期モードでは、トランザクションのコミット時にスタンバイ側でログ受信や永続化が完了するまで待つ必要があります。これによりRPOはゼロにできますが、そのぶん書き込みレイテンシは増えます。ネットワークの揺らぎが、そのままアプリケーションの応答時間に影響しやすくなる点も無視できません。こうしたデータ保護と性能のトレードオフに加え、どちらのモードでも待機系のサーバーやストレージを別途用意する必要があり、コストが二重にかかる点も共通の課題です。

もうひとつの代表的な方法が、分散コンセンサスに基づく3レプリカ構成です。クラスタは3つのフル機能レプリカで構成され、PaxosやRaftのようなコンセンサスアルゴリズムで投票を行います。少数側のノードに障害が起きても、コミット済みデータは失われず、RPOゼロを維持できます。

その代わり、必要なコンピュート、ストレージ、運用コストは大きくなります。インフラ予算が限られているチームや、AZ間・リージョン間の帯域に制約がある環境では、この構成が負担になりやすいのも事実です。

多くのチームにとって悩ましいのはここです。プライマリ・スタンバイではデータ保護に不安が残る一方、3レプリカ構成はコストが重い。その中間をどう取るかが課題になります。

---

アービトレーションサービス：データを持たない投票専用メンバー

OceanBaseはバージョン4.1.0からアービトレーションサービスを導入しました。これはデータベースクラスタとは別に配置される軽量なOceanBaseプロセスで、レプリケーショングループの特別なメンバーとして動作します。

主な役割と特徴

• 役割: リーダー選出への参加、メンバー変更時の投票、障害時の縮退判断の補助
• 制限事項: ログ書き込み時の過半数承認（Paxos Accept）には参加せず、ユーザーデータやトランザクションログも保持しない。リーダーとして外部にサービスを提供することもなし。

このため、CPU、メモリ、ディスク、ネットワーク帯域の負荷はごく小さく抑えられます。以前のOceanBaseでは、第3ノードとしてログ専用レプリカを使う方式がありましたが、こちらはデータ本体を持たない代わりに、トランザクションログの同期と保存は必要でした。アービトレーションサービスはそこをさらに切り詰め、投票と障害判定の補助に役割を絞っています。

そのため、独立したマシン上に軽量プロセスを立ち上げるだけで運用でき、複数のOceanBaseクラスタに対してアービトレーションサービスを提供することも可能です。

障害時の挙動

フル機能レプリカの半数に障害が発生してログ同期が止まり、その状態が設定されたタイムアウト値（デフォルト5秒）を超えると、アービトレーションノードは障害レプリカを一時的にメンバーリストから外す判断を支援します。これにより、残った健全なレプリカだけで過半数を再構成し、RPO=0を維持したまま書き込みを継続できます。

想定される障害としては、ノードクラッシュ、ネットワーク分断、ディスクフル、AZ単位の障害などがあります。障害レプリカが復旧すれば、自動的にクラスタへ再参加し、最新データに追いつきます。

2F1A構成：フル機能レプリカ2つ + アービトレーションノード1つ

アービトレーションサービスを使う代表的な構成が「2F1A」です。これは、2つのフル機能レプリカ（F: Full）と1つのアービトレーションノード（A: Arbitration）で構成されます。

OceanBaseでは、Locality（レプリカの配置ポリシー）で2つのフル機能レプリカの配置を定義し、アービトレーションノードを有効にすることで実現できます。たとえば、同一都市内の異なる2つのAZにフル機能レプリカを置き、別の場所にアービトレーションノードを配置する形です。

メリットとトレードオフ

• 従来の非同期プライマリ・スタンバイとの比較:
• 3F構成との比較:

クロスリージョン／マルチAZ構成での効果

クロスリージョンやマルチAZのDR構成でも、アービトレーションサービスは帯域負荷の軽減に役立ち、障害時の応答時間の悪化を抑えやすい点も利点です。

たとえば「4F1A」構成では、メインリージョン内の2つのAZにそれぞれ2つずつフル機能レプリカを置き、リモートリージョンにアービトレーションノードを1つ配置します。

この構成で、メインリージョン内の一方のAZに障害が起き、そこにある2つのフル機能レプリカが同時に停止した場合：

1. アービトレーションサービスが障害側レプリカの切り離しを支援。
2. 残ったAZ内の2つのフル機能レプリカがローカル同期を続けながら書き込みを引き継ぐ。
3. 以降の書き込みパスではリージョンをまたぐ合意形成を待たずに済むため、応答時間の大きな悪化を回避可能。

適したユースケース

アービトレーションサービスは、特に次のようなケースに向いています。

• 同一リージョンのマルチAZ構成で、アービトレーションノードを独立配置するための最小限のリソースを確保できる
• AZ間またはリージョン間のネットワーク帯域がボトルネックになりやすい
• 3F構成ほどのコストはかけにくいが、RPO=0は確保したい
• フルレプリカ構成より可用性がわずかに下がる点を理解したうえで、コストとのバランスを取りたい

【実例：クロスボーダー決済プラットフォーム】データ整合性への要求が厳しいコア決済システムにおいて、RPO=0を追求した事例があります。コストと可用性のバランスを検討した結果、従来の3FではなくOceanBase Cloud上で2F1A構成を採用し、アービトレーションサービスを独立配置しました。Paxosとアービトレーションメカニズムを組み合わせることで、さまざまな障害シナリオでデータロスゼロを実現し、秒単位のRTOも達成しています。

まとめ

アービトレーションサービスを使うと、2つのフル機能レプリカでもRPO=0を狙えます。3台目のフルレプリカがいらないぶん、3Fよりコストを抑えやすいのも利点です。

可用性ではフルレプリカ構成に一歩譲るものの、コストとデータ保護のバランスを取りたい場面ではかなり現実的な選択肢です。