システムの高可用性とは？
ITシステムの高可用性（High Availability）とは、システムが中断することなく機能を実行し続ける能力であり、システムの可用性の度合いを表します。高可用性は、システム設計、エンジニアリング実践、製品能力の各段階にわたる総合的な取り組みによって、ビジネスの継続性と連続性を保証します。システムの高可用性を確保する上で最も重要な焦点は、単一障害点（Single Point of Failure）を可能な限り排除または冗長化し、単一障害点やシステムが利用不能になった場合に迅速にリストアする能力を提供することです。エンタープライズアプリケーションでは、ビジネスの継続的な可用性を保証するため、システムの可用性に対して非常に高い要求があり、障害や災害発生時において、システムのRTOをできるだけ低く、RPOをできるだけ0に近づける必要があります。
高可用性は分散システム設計において必ず考慮すべき要素であり、OceanBaseデータベースはネイティブな分散データベースとして、一貫性のある高可用性のデータサービスを外部に提供できます。OceanBaseデータベースのトランザクションの一貫性とストレージの永続性により、OBServerノードが停止・再起動した場合でも、再起動前と同じデータと状態にリストアできることが保証されます。さらに、OceanBaseデータベースのバックアップ・リストアやプライマリ/スタンバイデータベースソリューションも、さまざまなシナリオにおけるOceanBaseデータベースの高可用性を保証しています。
OceanBaseデータベースのどのような製品機能がデータサービスの高可用性を保証していますか？
プロダクト機能とソリューション |
故障シナリオ |
動作原理 |
|---|---|---|
| OceanBase分散型選挙 | OceanBaseクラスタの少数派が様々な理由で利用不能になった場合の故障リストア：
|
OceanBaseクラスタの選挙モジュールは、唯一のリーダーレプリカを選出し、外部にデータサービスを提供することを保証します。同時に、Paxosプロトコルを通じて多数派clogの強整合性同期永続化を実現しており、Paxosグループ内で任意の少数派レプリカに障害が発生した場合でも、残りのすべての多数派clogを合わせることで完全なClogが保証され、個別のハードウェア障害によるデータ損失を回避し、データの信頼性を確保します。 OceanBaseクラスタ全体の少数派で障害が発生した場合、非 Leader レプリカの少数派が利用不能であっても、システムの可用性やデータベースのパフォーマンスに影響はありません。少数派の障害に Leader レプリカが含まれる場合、OceanBaseクラスタは残りのレプリカから唯一の新しいリーダーを選出し、データサービスを提供することを保証します。これは主にOceanBaseクラスタの構築・デプロイメントモードに基づいています。OBServerノードの複数のZoneが異なるデータセンターや異なる都市に分散している場合、OceanBaseクラスタの分散型選挙とOceanBase Paxos clog同期により、データセンター間または都市間の高可用性ソリューションを実現できます。 |
| OceanBase clogおよびストレージエンジン |
|
OceanBaseクラスタのストレージエンジンは、ベースラインデータをSSTableに、増分データをMemTableに保存します。OceanBase clogはデータのredo logです。データ変更が発生すると、リクエストはリーダーレプリカが存在するノードに到達し、データ変更リクエストがMemTableに更新され、トランザクションがコミットされます。 Leader はローカルのclogを更新し、Paxosプロトコルを通じてログを他のフォロワーのレプリカノードに同期書き込みます。多数派ノードのログがディスクに書き込まれた後、データ変更は成功し、クライアントに返されます。 Followerレプリカは、clogをローカルのMemTableにリプレイし、弱整合性読み取りサービスを提供します。MemTableがしきい値に達すると、フリーズとダンプがトリガーされ、SSTable層に永続化されます。この時点でのclogリプレイポイントが進み、チェックポイントを取ったかのようになります。OBServerノードが再起動する際、SSTableからソースデータをリストアし、最新情報に更新することができます。その後、パーティションのメタ情報からclogのリプレイポイントを取得し、clogログのリプレイを開始してMemTableを生成します。これにより、OceanBaseクラスタはディスク上の永続化情報を障害発生前の状態にリストアし、データの完全性を保証します。 OceanBaseクラスタが障害（ソフトウェア終了、異常再起動、停電、機器障害など）により再起動するか、計画的な停止メンテナンス後に再起動する場合、OBServerノードは起動中にリストアし、OBServerノードのstoreディレクトリ下のログとデータをメモリにリストアし、プロセスの状態を障害発生前の状態にリストアします。多数派レプリカに障害が発生し、再起動が必要な場合、データサービスは中断されますが、OceanBaseクラスタは多数派がダウンして再起動した後、データを障害発生前の状態に完全にリストアすることを保証します。 OBServerノードは多数派のダウン再起動に対してもさらに最適化された処理を行い、データレプリカのリストアとMemTableへのロード速度を向上させ、早期に外部にデータサービスを提供します。クラスタ全体が再起動するシナリオでは、ディスク上の最新のclogを再度MemTableにリプレイしてから外部にデータサービスを提供する必要があります。OceanBaseクラスタがデータサービスを再開できるとき、データはクラスタ再起動前の状態にリストアされます。 |
| OceanBaseバックアップとリカバリ | OceanBaseクラスタでデータ破損、ノードCrash、またはクラスタ障害が発生した場合、OceanBaseクラスタはバックアップされたベースラインデータとclogバックアップからリストアできます。 | OceanBaseクラスタでデータ破損、ノードcrash、またはクラスタ障害が発生した場合、OceanBaseクラスタはバックアップされたベースラインデータとclogバックアップからリストアできます。 |
| OceanBaseプライマリ/スタンバイデータベースソリューション | データセンターレベルの障害または都市レベルのディザスタリカバリ：
|
OceanBaseクラスタは従来のプライマリ/スタンバイデータベースアーキテクチャもサポートしています。OceanBaseクラスタのマルチレプリカメカニズムは豊富なディザスタリカバリ機能を提供し、マシンレベル、データセンターレベル、都市レベルの障害状況下で自動切り替えを実現し、データ損失なく、RPO = 0を保証します。プライマリクラスタが計画的または計画外（多数派レプリカの障害）により利用不能となった場合、スタンバイクラスタがサービスを引き継ぎ、無損失切り替え（RPO = 0）と有損失切り替え（RPO > 0）の2種類のディザスタリカバリ機能を提供し、サービス停止時間を最大限に短縮します。 OceanBaseクラスタは、1つ以上のスタンバイクラスタの作成、維持、管理、監視をサポートします。スタンバイクラスタは本番データのホットバックアップです。管理者は、負荷の高い読み取り専用業務処理をスタンバイクラスタに割り当てることで、システムのパフォーマンスとリソース利用率を向上させることができます。 |
OceanBaseデータベースで少数派のダウンが発生した場合はどうなりますか？リストアまでにどれくらいかかりますか？
OceanBaseデータベースは、Paxos分散一貫性プロトコルに基づいており、常に過半数のレプリカが合意に達した場合にのみ Leader を選出することで、プライマリレプリカの一意性を保証し、外部にデータサービスを提供します。サービスを提供している Leader レプリカが障害によりサービスを継続できなくなった場合でも、残りの Follower レプリカが過半数を維持し合意に達していれば、新しい Leader を選出してサービスを引き継がせることができます。サービス中の Leader 自身が過半数条件を満たせない場合は、自動的に Leader 資格を失います。 Leader レプリカに障害が発生した際、 Follower がその障害を検知して新しい Leader を選出できるまでの時間は、RTOの大きさを直接決定します。
OceanBaseデータベースの選挙モデルは、Paxosに基づいて再設計された選挙方式であり、同一ログストリームの複数レプリカ間でコンセンサス協議を行い、各レプリカの優先順位を組み合わせて唯一のプライマリレプリカを選出します。選挙が成功すると、各レプリカは Leader を認定するリース（Lease）を締結します。リース期間が満了するまで、 Leader は継続的に再選を試み、通常は継続的に成功します。 Leader が再選に失敗した場合、リース期間満了後は定期的にリーダー不在の選挙を開始し、レプリカの高可用性を保証します。3レプリカ（フル機能レプリカ）構成では、あるレプリカに異常が発生した場合（例えばノードマシンの障害やOBServerノードのオフラインなどの単点障害）、OceanBaseデータベースの選挙モジュールは以下のように動作します：元のプライマリレプリカが再選に成功した場合、元のプライマリはプライマリレプリカサービスを継続して提供できます。元のプライマリレプリカがオフラインとなり、 Leader の再選が失敗した場合、OceanBaseデータベースは無主選挙を行い、新しいプライマリの就任は8秒以内に完了します。
同時に、OceanBaseデータベースはPaxosプロトコルを通じて、過半数のclog強整合性同期永続化を実現しています。Paxosグループ内で任意の少数派レプリカに障害が発生した場合でも、残りの過半数レプリカは最新のClogを保持できるため、個々のハードウェア障害によるデータ損失を回避し、データの信頼性を保証します。
OceanBaseデータベースの選挙はスプリットブレイン問題をどのように回避しますか？
高可用性ソリューションにおいて、典型的なスプリットブレイン（Split Brain）問題とは、2つのデータレプリカがネットワーク問題により互いの状態を認識できず、それぞれが自身をプライマリレプリカとして認識しデータサービスを提供すべきだと考える場合に発生します。これにより典型的なスプリットブレイン現象が生じ、最終的にはシステムの混乱やデータの破損につながります。OceanBaseデータベースは、Paxosプロトコルの過半数コンセンサスメカニズムを利用して、データの信頼性とプライマリレプリカの一意性を保証します。常に過半数のレプリカが合意に達した場合にのみ、 Leader を選出します。サービスを提供している Leader レプリカが障害によりサービスを継続できなくなった場合でも、残りの Follower レプリカが過半数を維持し合意に達していれば、新しい Leader を選出してサービスを引き継がせることができます。サービス中の Leader 自身が過半数条件を満たせない場合は、自動的に Leader 資格を失います。
したがって、OceanBaseデータベースの分散型選挙は高可用性において明確な利点があります。理論的基盤から、常に最大でも1つの Leader しか存在しないことが保証され、スプリットブレインの状況が完全に排除されています。スプリットブレインを心配する必要がなくなったため、 Leader が障害でサービスを提供できなくなった場合、Follower は自動的に選挙をトリガーして新しい Leader を生成し、サービスを引き継がせることができます。このプロセス全体で人の手を借りる必要はありません。これにより、スプリットブレインの問題が根本的に解決されるだけでなく、自動再選挙を利用してRTOを大幅に短縮することも可能です。もちろん、ここで重要な要素がもう一つあります。それは、 Leader に障害が発生した際、Follower がその障害を検知して新しい Leader を選出できるまでの時間であり、この時間がRTOの大きさを直接決定します。
OceanBaseクラスタで過半数が失敗した場合でもサービスを提供できますか？
OceanBaseクラスタで過半数が失敗した場合、該当するパーティションは外部にデータサービスを提供できません。データの高可用性を保証するためには、システム全体のアーキテクチャ設計および運用保守時に、2つのレプリカに関連しない連続する障害発生の時間も考慮し、最適化する必要があります。最終的に、平均故障までの時間（MTTF：Mean Time To Failure）が障害の修復時間（MTTR：Mean Time To Repair）より十分に短いことを保証し、データサービス全体の高可用性を確保する必要があります。OceanBaseクラスタで過半数が失敗した場合、問題分析に必要な情報とログを保持する前提の下、緊急措置を迅速に講じてクラスタを可能な限り早く可用状態に戻す必要があります。
OceanBaseクラスタのレプリカ自動補完機能はどのように動作するのでしょうか？また、レプリカ自動補完はノードがダウンした場合でも、対応するパーティションのレプリカが完全に保たれることを保証しますか？
observerプロセスが異常終了した場合、終了時間がserver_permanent_offline_timeより短い場合は処理せず、このとき一部のパーティションのレプリカ数は2つになります（3レプリカ構成の場合）。終了時間がserver_permanent_offline_timeを超えた場合は、そのServerを永久オフラインとして扱い、OceanBaseクラスタは同一ゾーン内の他のServer（リソースに余裕のあるServer）で領域を開設し、レプリカ数を維持します。十分なリソースがある場合はUnit移行を開始します。
OceanBaseクラスタは複数データセンター・複数地域へのデプロイメント方式をサポートしていますか？デプロイ時のインフラ要件は何ですか？どのようにしてプランを選択すべきですか？
OceanBaseクラスタの構築では、複数のレプリカ（ノード）を複数のデータセンターや都市に分散配置し、データセンター間・都市間でPaxosグループを実現することが可能です。複数データセンター・複数都市のクラスタアーキテクチャを選択する際、通常はデータセンターレベルや都市レベルのディザスタリカバリ能力を確保するためです。技術的には、OceanBaseクラスタの異なるレプリカノードをサポートするインフラが十分に整っていれば、合理的なレプリカ分布の下で、OceanBaseクラスタは異なるノードにデータを分散配置し、外部にデータサービスを提供できます。一般的に、複数データセンター・複数都市のデプロイメント方式を採用する際、最も重要なのはビジネスおよび様々な側面から生じるアーキテクチャ要件を考慮することです。複数データセンター・複数都市のデプロイメント方式は、システム全体のコストを大幅に増加させる可能性もあります（例えば、都市を跨ぐ専用回線のデプロイなど）。したがって、異なるデプロイプランは、コスト、要件、製品能力、プランの実現可能性など、複数の観点からのトレードオフの結果として生まれます。
技術的に、データセンターレベルまたは都市レベルのディザスタリカバリを解決できるクラスタソリューションは以下の通りです：
同一都市内の3データセンター・3レプリカ構成
- 同一都市内の3つのデータセンターが1つのクラスタを形成します（各データセンターが1つのゾーン）。データセンター間のネットワーク遅延は通常0.5～2msです。
- データセンターレベルの災害発生時、残りの2つのレプリカが多数派を維持し、 Redo-Log ログの同期を続行できるため、RPO=0を保証します。
- 都市レベルの災害には対応できません。
3リージョン・5データセンター・5レプリカ構成：
- 3つの都市が1つの5レプリカクラスタを形成します。
- いずれかのIDCまたは都市で障害が発生しても、多数派が維持され、RPO=0を保証できます。
- 多数派を維持するには3つ以上のレプリカが必要ですが、各都市に最大で2つのレプリカしか配置できません。遅延を低減するため、都市1と都市2は近距離に配置し、 Redo-Log ログの同期遅延を抑える必要があります。
- コストを削減するため、都市3にはログ型レプリカ（ログのみ）を配置することができます。
実際のデプロイメントプランでは、OceanBaseクラスタは顧客の要件に応じて、同一都市内の2データセンターや2リージョン・3データセンターのプランもカスタマイズしています。これら2つのデプロイプランは、それぞれ対応するシナリオにおけるシステムの高可用性要件の一部を解決していますが、同時に一定のディザスタリカバリ能力に制約もあります。一定期間、システムアーキテクチャの中間状態として、顧客の初期デプロイメントの選択肢となる可能性があります。また、顧客はOceanBaseのプライマリ/スタンバイデータベースアーキテクチャを組み合わせて使用し、期待されるディザスタリカバリ能力を達成することもできます。具体的なプランの検討には、複数の要因と側面を考慮する必要があります。実際の具体的なシナリオがある場合は、OceanBaseデータベースの技術アーキテクトに連絡し、プランの議論と調整を行ってください。