システムの高可用性とは何ですか？
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です。データ変更が発生すると、リクエストはLeaderレプリカが存在するノードに到達し、データ変更リクエストがMemTableに更新され、トランザクションがコミットされます。Leaderはローカルのclogを更新し、Paxosプロトコルを通じてログを他のFollowerのレプリカノードに同期書き込みます。多数派ノードのログがディスクに書き込まれた後、データ変更は成功し、クライアントに返却されます。 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レプリカが障害に遭遇してサービスを継続できなくなった場合、残りのFollowerレプリカが多数派を維持し一致に達している限り、新しいLeaderを選出してサービスを引き継がせることができます。サービスを提供中のLeader自身が多数派条件を満たせない場合、自動的にLeader資格を失います。Leaderレプリカに障害が発生した場合、Followerがどの程度の時間でLeaderの障害を検知し新しいLeaderを選出できるかが、RTOの大きさを直接決定します。
OceanBaseデータベースの選挙モデルは、Paxosに基づいて再設計された選挙方式であり、同一ログストリームのマルチレプリカがコンセンサス協議を行い、各レプリカの優先順位を組み合わせて唯一のプライマリレプリカを選出します。選挙が成功すると、各レプリカはLeader認定のリース（Lease）に署名します。リース期間が満了する前に、Leaderは継続的に再選を試み、通常は継続的に成功します。Leaderが再選に失敗した場合、リース期間満了後は定期的に無主選挙を開始し、レプリカの高可用性を保証します。3レプリカ（全能レプリカ）シナリオでは、1つのレプリカに異常が発生した場合（例えば、そのノードのマシン障害、OBServerノードのオフラインなどの単一障害点）、OceanBaseデータベースの選挙モジュールは以下のように動作します：元のプライマリレプリカが再選に成功した場合、元のプライマリはプライマリレプリカサービスを継続して提供できます；元のプライマリレプリカがオフラインとなり、Leaderの再選が失敗した場合、OceanBaseデータベースは無主選挙を行い、新しいプライマリの就任は8秒以内に完了します。
同時に、OceanBaseデータベースはPaxosプロトコルを用いて多数派clogの強整合性同期永続化を実現しており、Paxosグループ内で任意の少数派レプリカに障害が発生した場合でも、残りの多数派レプリカは最新のClogを保証するため、個別のハードウェア障害によるデータ損失を回避し、データの信頼性を保証します。
OceanBaseデータベースの選挙は、スプリットブレイン問題をどのように回避しますか？
高可用性ソリューションにおいて、典型的なスプリットブレイン（Split Brain）問題があります：もし2つのデータレプリカがネットワーク問題で互いの状態を知らず、それぞれが自分がプライマリレプリカとしてデータサービスを提供すべきだと考えた場合、典型的なスプリットブレイン現象が発生し、最終的にはシステムの混乱とデータ破損に至ります。OceanBaseデータベースは、Paxosプロトコルの多数派コンセンサスメカニズムを利用して、データの信頼性とプライマリレプリカの一意性を保証します：いかなる時点においても多数派レプリカが一致に達した場合にのみ、リーダーを選出します。サービスを提供中のLeaderレプリカが障害に遭遇してサービスを継続できなくなった場合、残りのFollowerレプリカが多数派を維持し一致に達している限り、新しいLeaderを選出してサービスを引き継がせることができます。サービスを提供中のLeader自身が多数派条件を満たせない場合、自動的にLeader資格を失います。
したがって、OceanBaseデータベースの分散選挙は高可用性において明らかな利点があります：理論的基盤において、いかなる時点でも至多1つのLeaderしか存在しないことを保証し、スプリットブレインの状況を根本的に排除しています。スプリットブレインを心配する必要がなくなったため、Leaderが障害でサービスを提供できない場合、Followerは自動的に選挙をトリガーして新しいLeaderを選出しサービスを引き継がせることができ、全過程で人為的介入は不要です。これにより、スプリットブレインの問題を根本的に解決するだけでなく、自動再選挙を利用してRTOを大幅に短縮することもできます。もちろん、ここにはもう一つ重要な要素があります。それは、Leaderに障害が発生した場合、Followerがどの程度の時間でLeaderの障害を検知し新しいLeaderを選出できるかということであり、この時間が直接RTOの大きさを決定します。
OceanBaseクラスタの多数派が失敗した場合でもサービスを提供できますか？
OceanBaseクラスタの多数派が失敗した場合、該当するパーティションは外部にデータサービスを提供できません。データの高可用性を保証するためには、システムアーキテクチャの設計と運用保守の際に、2つのレプリカに関係のない連続する障害が発生する時間も考慮し、最適化する必要があります。最終的に、MTTF（平均故障までの時間）を障害の修理時間MTTR（平均修理時間）よりも十分に小さく保つことで、データサービス全体の高可用性を保証する必要があります。OceanBaseクラスタの多数派が失敗した場合、問題分析に必要な情報とログを保持する前提の下、緊急措置を速やかに講じてクラスタをできるだけ早く利用可能な状態に復旧する必要があります。
OceanBaseクラスタのレプリカ自動補完機能はどのように動作し、レプリカ自動補完はノードがダウンした場合でも対応するパーティションのレプリカが完全であることを保証できますか？
observerプロセスが異常終了した場合、終了時間がserver_permanent_offline_time未満であれば処理せず、その場合一部のパーティションのレプリカ数は2つになります（3レプリカの場合）。終了時間がserver_permanent_offline_timeを超えた場合は、そのServerを永久にオフライン扱いとし、OceanBaseクラスタは同一Zone内の他のServer（リソースに余裕のあるServer）で領域を開設し、レプリカ数を維持します。十分なリソースがある場合、Unit移行を開始します。
OceanBaseクラスタは複数データセンター・複数リージョンのデプロイメント方式をサポートしていますか？デプロイ時のインフラ要件は何ですか？どのようにしてプランを選択すればよいですか？
OceanBaseクラスタの構築では、複数のレプリカ（ノード）を複数のデータセンターや複数の都市に分散配置し、データセンター間・都市間でPaxosグループを実現することが可能です。複数データセンター・複数都市のクラスタアーキテクチャを選択する際、通常はデータセンターレベルや都市レベルの災害復旧能力を獲得するためです。技術的には、OceanBaseクラスタの異なるレプリカノードをサポートするインフラが十分に優れており、合理的なレプリカ分散があれば、OceanBaseクラスタは異なるノードにデータを分散配置し、外部にデータサービスを提供できます。一般的に、複数データセンター・複数都市のデプロイメントプランを検討する際、最も重要なのはビジネスニーズや様々なアーキテクチャ要件です。複数データセンター・複数都市のデプロイメント方式は、システム全体のコストを大幅に増加させる可能性もあるからです（例えば、都市間の専用回線を利用したデプロイメントなど）。そのため、異なるデプロイメントプランは、コスト、要件、製品機能、プランの実現可能性など、複数の観点からのトレードオフの結果として生まれます。
技術的に、データセンターレベルまたは都市レベルの災害復旧を実現できるクラスタソリューションには以下のものがあります：
同一都市内の3データセンター・3レプリカデプロイメント
- 同一都市内の3つのデータセンターで1つのクラスタを構成します（各データセンターが1つのゾーン）。データセンター間のネットワーク遅延は通常0.5～2msです。
- データセンターレベルの障害発生時、残りの2つのレプリカが多数派を維持し、Redoログの同期を継続することで、RPO=0を保証します。
- 都市レベルの障害には対応できません。
3地域・5データセンター・5レプリカデプロイメント：
- 3つの都市で5レプリカのクラスタを構成します。
- いずれかのIDCまたは都市で障害が発生しても、多数派が維持され、RPO=0を保証します。
- 多数派を維持するには3つ以上のレプリカが必要ですが、各都市に最大でも2つのレプリカしか配置できません。遅延を低減するため、都市1と都市2は互いに近距離に配置する必要があります。
- コストを削減するため、都市3にはログ型レプリカ（ログのみ）をデプロイすることも可能です。
実際のデプロイメントプランでは、OceanBaseクラスタは顧客の要件に応じて、同一都市内の2データセンターや2地域・3データセンターのプランもカスタマイズしています。これら2つのデプロイメントプランは、それぞれ対応するシナリオにおけるシステムの高可用性要件の一部を解決していますが、同時に一定の災害復旧能力の短所もあります。一定期間、システムアーキテクチャの中間状態として、顧客の初期デプロイメントの選択肢となる可能性があります。また、顧客はOceanBaseのプライマリ/スタンバイデータベースアーキテクチャを組み合わせて使用し、期待される災害復旧能力を実現することも可能です。具体的なプランの検討には、複数の要因と側面を考慮する必要があります。実際の具体的なシナリオがある場合は、OceanBaseデータベースの技術アーキテクトに連絡し、プランの議論と調整を行ってください。