高可用アーキテクチャの概要

OceanBaseデータベースのアーキテクチャと実装方法は、データの強整合性、完全性、および高可用性を保証します。

OceanBaseデータベースのアーキテクチャ

図に示すように、データサービス層はOceanBaseデータベースクラスタを表します。このクラスタは3つのサブクラスタ（Zone）で構成され、1つのZoneは複数の物理マシンで構成されます。各物理マシンはデータノード（OBServerノード）と呼ばれます。OceanBaseデータベースはShared-Nothingの分散アーキテクチャを採用しており、各データノードは対等です。

OceanBaseデータベースに保存されるデータは、1つのZone内の複数のデータノードに分散配置され、他のZoneには複数のデータレプリカが格納されます。図に示すOceanBaseデータベースクラスタのデータには3つのレプリカがあり、各Zoneに1つずつ格納されています。これら3つのZoneが一体となったデータベースクラスタを形成し、ユーザーにサービスを提供します。

デプロイ方法の違いにより、OceanBaseデータベースはさまざまなレベルの災害復旧機能を実現できます：

• サーバー（Server）レベルの無損失ディザスタリカバリ：単一サーバーの障害を許容し、自動的に無損失で切り替えます。

• データセンター（Zone）レベルの無損失ディザスタリカバリ：単一データセンターの障害を許容し、自動的に無損失で切り替えます。

• リージョン（Region）レベルの無損失ディザスタリカバリ：特定の都市全体の障害を許容し、自動的に無損失で切り替えます。

データベースクラスタが1つのデータセンターの複数のサーバーにデプロイされている場合、サーバーレベルのディザスタリカバリが実現されます。クラスタのサーバーが1つの地域内の複数のデータセンターにある場合、データセンターレベルのディザスタリカバリが実現されます。クラスタのサーバーが複数の地域の複数のデータセンターにある場合、リージョンレベルのディザスタリカバリが実現されます。

OceanBaseデータベースのディザスタリカバリ機能は、RPO=0、RTO<8秒の国家標準最高レベル6の基準を達成できます。

高可用性

OceanBaseの分散型クラスタでは、複数のマシンが同時にデータベースサービスを提供し、その高可用性を実現します。上記の図では、アプリケーション層はリクエストをプロキシサービス（ODP、別名obproxy）に送信します。プロキシサービスでルーティングされた後、実際にサービスを提供するデータベースノード（OBServerノード）に送信され、リクエストの結果は逆の経路でアプリケーション層に返されます。このプロセス全体を通じて、異なるコンポーネントが様々な方法で高可用性を実現しています。

データベースノード（OBServerノード）で構成されるクラスタでは、すべてのデータがパーティション単位で保存され、高可用性サービスを提供します。各パーティションには複数のレプリカがあります。一般的に、1つのパーティションの複数のレプリカは複数の異なるZoneに分散されています。複数のレプリカのうち、変更操作を受け付けるのは1つだけで、これをリーダーレプリカ（Leader）と呼び、他のものをフォロワーレプリカ（Follower）と呼びます。リーダーレプリカとフォロワーレプリカの間では、Multi-Paxosに基づく分散型コンセンサスプロトコルにより、レプリカ間のデータ一貫性が実現されています。リーダーレプリカが存在するノードに障害が発生した場合、フォロワーノードの1つが新しいリーダーノードに選出され、サービスを継続します。

選挙サービスは高可用性の基盤です。OceanBaseデータベースの以前のバージョンとは異なり、V4.xバージョンでは、選挙サービスの粒度がパーティションからログストリームに変更され、パーティションはログストリームにマウントされます。ログストリームの複数のレプリカは選挙プロトコルによりそのうちの1つをリーダーレプリカ（Leader）として選出します。このような選挙は、クラスタが再起動したときやリーダーレプリカに障害が発生したときに行われます。

さらに、V4.xバージョンでは、選挙サービスはNTPや他の時刻同期サービスに依存せず、ローカル時計および改良されたリースメカニズムによってクラスタ内の各マシンの時計の一貫性を保証します。選挙サービスは優先順位メカニズムにより、より優れたレプリカをリーダーレプリカとして選出することを保証し、この優先順位メカニズムはユーザーが指定したPrimary Zoneやマシンの異常状態などを考慮します。

リーダーレプリカがサービスを開始すると、ユーザーの操作によって新しいデータ変更が生じ、すべての変更はログとして生成され、他のフォロワーレプリカ（Follower）に同期されます。OceanBaseデータベースがログ情報を同期するプロトコルはMulti-Paxos分散型コンセンサスプロトコルです。Multi-Paxosプロトコルは、コンセンサスに達する必要があるすべてのログ情報が、レプリカリスト内の過半数のレプリカに正常に永続化された後は保証され、任意の少数派レプリカに障害が発生しても情報が失われないことを保証します。Multi-Paxosプロトコルによって同期された複数のレプリカは、少数のノードに障害が発生した場合のシステムの2つの重要な特性を保証します：データが失われないこと、サービスが停止しないこと。ユーザーが書き込んだデータは少数のノードの障害を許容でき、同時に、ノードに障害が発生した場合、システムは常に自動的に新しいレプリカをリーダーレプリカとして選出し、データベースのサービスを継続します。

OceanBaseデータベースの各テナントにはグローバルタイムスタンプサービス（GTS）も備えており、テナント内で実行されるすべてのトランザクションに対して、読み取りスナップショット版とコミット版を提供し、グローバルなトランザクション順序を保証します。グローバルタイムスタンプサービスに異常が発生した場合、テナントのトランザクション関連操作はすべて影響を受けます。OceanBaseデータベースは、パーティションレプリカと一致する方式を使用して、グローバルタイムスタンプサービスの信頼性と可用性を保証します。テナント内のグローバルタイムスタンプサービスの実際の位置は、特殊なパーティションによって決定されます。この特殊なパーティションも他のパーティションと同様に複数のレプリカを持ち、選挙サービスによってリーダーレプリカが選出されます。リーダーレプリカが存在するノードがグローバルタイムスタンプサービスのノードとなります。このノードに障害が発生した場合、特殊なパーティションは別のレプリカをリーダーレプリカとして選出し、作業を継続します。グローバルタイムスタンプサービスも自動的に新しいリーダーレプリカが存在するノードに移動し、サービスを継続します。

以上がデータベースクラスタノードが高可用性を実現するための主要なコンポーネントです。プロキシサービス（ODP、別名obproxy）も高可用性を備えている必要があり、そのサービスを保証するために使用されます。ユーザーのリクエストは最初にプロキシサービスに到達し、プロキシサービスが正常でなければユーザーのリクエストも正常に処理できません。プロキシサービスはまた、データベースクラスタノードの障害を処理し、適切なフォールトトレランス処理を行う必要があります。

プロキシサービスはデータベースクラスタとは異なり、永続化された状態を持ちません。その業務はデータベースサービスへのアクセスに依存しているため、プロキシサービスの障害はデータの損失を引き起こしません。プロキシサービスも複数のノードでクラスタサービスを構成しており、ユーザーのリクエストを具体的にどのプロキシサービスノードが実行するかは、ユーザーのF5キーまたは他のロードバランシングコンポーネントが担当します。同時に、プロキシサービスの特定のノードに障害が発生した場合も、ロードバランシングコンポーネントが自動的に除外し、その後のリクエストが障害ノードに送信されないようにします。

プロキシサービスの動作プロセスでは、データベースクラスタの状態をリアルタイムで監視します。一方で、プロキシサービスはクラスタのシステムテーブルをリアルタイムに取得し、システムテーブルから各マシンのヘルス状態やパーティションのリアルタイム位置を把握します。また、もう一方で、プロキシサービスはネットワーク接続を通じてデータベースクラスタノードのサービス状態を検出し、異常が発生した場合は該当ノードの障害状態をマークして対応するサービス切り替えを実行します。