金融グレードの分散データベースアーキテクチャの設計を1つの記事で理解する

【51CTO.comオリジナル記事】業界背景

当初の手作業による簿記から会計のコンピュータ化、金融の電子化、そして現在の金融テクノロジーに至るまで、金融とテクノロジーの融合がますます緊密になっていることがわかります。人工知能、ビッグデータ、モノのインターネット、ブロックチェーンなどの新興技術は、金融取引の方法を変え、金融業界におけるイノベーションの継続的な原動力となっています。同時に、インターネット金融の台頭は諸刃の剣であり、機会と課題をもたらします。

包括的金融により金融のハードルが下がり、より多くの一般人が金融活動に参加できるようになり、金融情報システムへの圧力が高まっています。その結果、大手商業銀行、保険会社、証券会社、取引所などの基幹取引システムはすべて分散化の道を歩んでいることがわかります。その中で、データベースは、ステートフル アプリケーションとして、上位レベルのアプリケーションからのすべての負荷を負う、情報システム内の唯一の単一ポイントになっています。データベースのボトルネックが顕著になるにつれて、分散型変革が差し迫っています。

データベースを分散型データベースに変換する方法

データベースを分散データベースに変換する主な方法は、分散アクセス クライアント、分散アクセス ミドルウェア、分散データベースの 3 つです。分散機能はさまざまなレベル (アプリケーション層、中間層、データベース層) で実装されているため、アプリケーションへの侵入の度合いが異なります。その中で、分散アクセス クライアントはアプリケーションに対する侵襲性が最も高く、変換が最も困難です。一方、分散データベース ソリューションはアプリケーションに対する侵襲性は最も低いですが、アーキテクチャの設計と開発が最も困難です。

分散データベースの全体アーキテクチャ

実際、現在市場に出回っている分散データベースの全体的なアーキテクチャは似ており、アクセス ノード、データ ノード、グローバル トランザクション マネージャーという 3 つの重要なコンポーネントで構成されています。全体的なアーキテクチャは次のとおりです。アクセス ノードは、SQL 解析、分散実行プランの生成、SQL 転送、データ集約などを担当します。データノードはデータの保存と計算を担当します。グローバル トランザクション マネージャーは、トランザクションのグローバルな一貫性を確保するために、グローバル トランザクション番号を生成する役割を担います。このアーキテクチャは、Google Spanner F1 ペーパーに多かれ少なかれ影響を受けています。この記事では、主にこれらのコンポーネントを実装する際の難しさやアーキテクチャの設計方法を分析します。

2フェーズコミットの問題点

2 フェーズ コミットはブロッキング プロトコルであることはわかっていますが、これが最大の問題でもあります。次の図は、pgxc アーキテクチャでの 2 フェーズの送信を例として示しており、主にいくつかのステージに分かれています。

①: CN準備 -> ②: 全DN準備 -> ③: CNコミット -> ④: 全DNコミット

cn コミット フェーズ中に cn/dn がクラッシュしたらどうなるか想像してみてください。

cn commit コマンドを送信した後に cn がクラッシュした場合、dn は commit コマンドを受信した後にトランザクションをコミットします。ただし、コミット OK を返すときに cn がクラッシュし、トランザクションがブロック状態になります。 CN がコミットを送信した後に DN がクラッシュすると、一部の DN コミットは成功しますが、他の DN コミットは失敗し、不整合が発生します。ただし、DN が再起動されると、CN からトランザクション コミット情報を取得し続けます。コミット状態であることが判明した場合、コミット操作の実行を継続し、以前のトランザクションをコミットします。

この時点で、より極端な状況について議論することができます。この時点で CN もクラッシュした場合、失敗した DN は再起動後に CN からステータスを取得しようとしますが、ステータスを取得できないことがわかります。この時点では、失敗した DN のトランザクションは保留状態にあり、コミットするかロールバックするかは不明です。このとき、他の DN からステータスを検出し、失敗した DN に報告してコミットするように通知できるプロセスが存在する必要があります。この役割は pgxc_clean プロセスです。実際、前の場合のトランザクションのロールバックもこのプロセスによる作業です。詳しく見てみましょう。 DN がトランザクションの唯一の参加者である場合、pgxc_clean は他の DN および cn からステータスを取得できません。現時点では、DN は実際に保留中です。

2 フェーズ コミットのブロッキング問題を解決するために、3 フェーズ コミットが導入されました。 3 フェーズ コミットでは、コミット前に cancommit プロセスが導入され、タイムアウト メカニズムが追加されました。コーディネーターがダウンした場合、参加者はコーディネーターがコミットを発行したのか中止を発行したのかを知ることができないためです。 3 フェーズ コミットのコミット プロセスは、コミットまたは中止コマンドを送信したことを参加者に通知することです。このとき、コーディネータが失敗した場合、参加者はタイムアウト期間を待ってから新しいコーディネータを選択でき、コーディネータはどのようなコマンドを発行すべきかを認識します。

3 フェーズ コミットはブロッキングの問題を解決しますが、パフォーマンスの問題は解決できません。分散システムでトランザクションの一貫性を確保するには、各参加者と通信する必要があります。トランザクションの送信と参加には、分散システム内の各ノードの参加が必要であり、必然的に遅延が発生します。ただし、10G、Infiniband、Roce 高速ネットワークのサポートにより、これはもはや問題ではありません。

CAPとBASEの選択

分散システムが CAP に勝てないことはわかっています。では、分散システムを設計する際にはどのようにトレードオフを行うべきでしょうか?まず、分散システムではネットワークを介して相互接続された複数のノード (パーティション) が必要であり、ネットワークは信頼できないため、P (パーティション耐性) が保証される必要があります。分散システムは、単一点障害を回避するように設計されています。ネットワークの問題や特定のノードの障害によりシステム全体が利用できない場合は、分散システムの本来の設計意図に準拠しません。 A (可用性) が保証されている場合、ネットワークに障害が発生すると、ネットワークによって分離された異なる領域が引き続きサービスを提供する必要があり、異なるパーティションでデータの不整合が発生します (スプリット ブレイン)。 C (一貫性) が保証されている場合、ネットワークに障害が発生すると、異なるネットワーク パーティション内のノードがデータを同期するまで待機する必要があります。ネットワークに継続的に障害が発生すると、同期ができないため、システムは使用できなくなります。

2PC は、一貫性を確保するために可用性を犠牲にする典型的な例ですが、BASE (基本的に利用可能、ソフト ステート、最終的な一貫性) は、可用性を確保するために一貫性を犠牲にする例です。リアルタイムの強力な一貫性を実現するためのコストが高すぎるため、特定の時間枠内でデータの不整合が発生する可能性があります。ウィンドウ内に各一時状態ログを記録することで、システムに障害が発生した場合に、ログを通じて未完了の作業を続行したり、完了した作業をキャンセルして初期状態にロールバックしたりすることができます。この方法により、最終的な一貫性が保証されます。 BASE は実際には従来の ACID 理論に反しています。 BASE 理論を満たすトランザクションは、柔軟なトランザクションとも呼ばれます。障害が発生した場合、それに応じた補償メカニズムが必要となり、ビジネスと密接に結びついています。実際、私は BASE アプローチにあまり賛成できません。なぜなら、このアプローチはデータベースの最も基本的な設計概念から逸脱しているからです。

ラフトの利点

上記の XA も BASE も一貫性の問題を完全に解決することはできません。真の強力な一貫性は、強力な一貫性プロトコルに基づく必要があります。現在、Paxos と Raft の 2 つが主流のコンセンサス アルゴリズムです。 Paxos は学術界で生まれ、分散環境でのメッセージ パッシングに基づくコンセンサス アルゴリズムです。実際の用途をあまり考慮せずに、一般的なモデルとして設計されました。さらに、Paxos は複数のノードが同時に書き込む状況を考慮しているため、Paxos の状態マシンは非常に複雑で理解しにくくなっています。人によって意味の理解が異なる可能性があり、これは常に批判されてきました。たとえば、MGR は、同時実行性の高いホットスポット データのシナリオでは受け入れられない、マルチポイント書き込み競合の問題に対処するために書き込みセットの概念を導入しました。 paxos は理解するのが難しいため、スタンフォード大学の学生 2 人がラフト アルゴリズムを設計しました。それに比べて、いかだはインダストリアルスタイルです。同時にリーダーは 1 人のみ存在し、フォロワーはログのレプリケーションを通じて一貫性を実現します。 paxos と比較すると、raft のステート マシンは理解しやすく、実装も簡単です。そのため、TiDB、RadonDB、etcd、kubernetes などの分散環境で広く使用されています。

Raft プロトコルは、コンセンサス問題を、リーダー選出、ログ複製、セキュリティという個別に解決する必要がある 3 つのサブ問題に分割します。

リーダー選挙:

サーバー ノードには、リーダー、フォロワー、候補の 3 つの状態があります。通常の状況では、システムにはリーダーが 1 つだけ存在し、他のすべてのノードはフォロワーです。リーダーはすべてのクライアント要求を処理します。フォロワーは積極的にリクエストを送信するのではなく、リーダーまたは候補者からのリクエストに応答するだけです。フォロワーがメッセージを受信しなかった場合（選挙がタイムアウトした場合）、フォロワーは候補者となり、選挙を開始します。クラスター内で過半数の票を獲得した候補がリーダーとなり、消滅するまでリーダーの地位を維持します。

Raft アルゴリズムは時間を任意の長さに分割します。各任期は、1 人以上の候補者がリーダーの座を目指す選挙から始まります。候補者が選挙に勝利した場合、その候補者はその任期中リーダーを務めます。選挙を開始するには、フォロワーはまず現在の任期番号を増やし、候補状態に移行します。次に、クラスター内の他のサーバーに RPC を並行して送信し、自分自身に投票します。候補者は、次の 3 つのうちのいずれかが発生するまでこの状態のままになります: (a) 選挙に勝利する、(b) 別のサーバーがリーダーになる、(c) どの候補者も選挙に勝利しない。候補者がクラスター内のノードの過半数から同じ任期番号の投票を獲得すると、その候補者が選挙に勝利し、リーダーになります。次に、権限を確立し、新しいリーダーが生成されないようにするために、他のサーバーにハートビート メッセージを送信します。次の図は、3 つの役割の遷移状態マシンを示しています。

ログのレプリケーション:

リーダーが選出されると、リーダーはクライアントの要求を処理するサーバーとして機能します。クライアントからの各要求は、レプリケーション ステート マシンによって実行される命令と見なされます。リーダーは、指示を新しいログ エントリとしてログに追加し、他のサーバーに対して並行してエントリ追加 RPC を開始して、ログ エントリを複製するように要求します。ログ エントリが安全に複製されると、リーダーはログ エントリをステート マシンに適用し、実行結果をクライアントに返します。フォロワーがクラッシュしたり、ネットワーク パケットが失われたりした場合、リーダーは、すべてのフォロワーが最終的にすべてのログ エントリを保存するまで、ログ エントリ追加 RPC を再試行し続けます (すでにクライアントに応答している場合でも)。次の図は、レプリケーション ステート マシン モデルを示しています。

安全：

安全性とは、各レプリケーション ステート マシンが同じ命令を同じ順序で実行して、各サーバーのデータの一貫性を確保することを意味します。フォロワーが一定期間利用できず、後にリーダーとして選出されると、以前のログが上書きされることになります。 Raft アルゴリズムは、リーダー選出時にいくつかの制限を追加することでこの問題を回避します。この制限により、特定のターム番号のすべてのリーダーが、前のタームのコミットされたログ エントリをすべて持つことが保証されます。ログ エントリはリーダーからフォロワーにのみ渡されます。新しいリーダーにログがないため、フォロワーがリーダーにログを渡す必要がある状況は発生せず、リーダーはローカル ログ内の既存のエントリを上書きすることはありません。 Raft アルゴリズムにより、投票者は投票時に新しい投票要求が含まれていないログを拒否することができ、それによって候補者が投票に勝つことを防ぐことができます。

CNデザイン

アクセス ノードの設計は単純に見えますが、そこにはいくつかの謎があります。 CN を設計する際に考慮すべき重要なポイントは、CN を重いものにするか軽いものにするかということです。これは諸刃の剣であり、主に 2 つの問題があります。

1. SQL 構文の互換性を実現するにはどうすればよいですか?

アクセス ノードは主に、SQL の解析、実行プランの生成および配布を担当します。これらは実際には SQL パーサーによって実行されます。 MySQL または PG パーサー、あるいはサーバー層を直接使用して SQL 解析と実行プラン生成を行うことができ、当然 MySQL または PG 構文と互換性があります。

2. メタデータの問題にどう対処するか?

上記のソリューションは完璧に思えますが、問題があります。MySQL または pg サーバー レイヤーが直接移動された場合、メタデータをどうすればよいのでしょうか。メタデータを cn に配置する必要がありますか?そうでない場合は、メタデータを保存および管理するための統一された場所が必要です。 cn 上に構築したテーブルは、メタデータ情報のために固定された場所で更新する必要があり、クエリにも同じことが当てはまります。メタデータが CN に保存されている場合、メタデータの更新はすべての CN 間で同期される必要があります。 CN がダウンすると、すべての DDL 操作がハングします。このとき、CN がタイムアウトして応答しなくなった後に CN をクラスターから削除するメカニズムが必要です。

DNの設計

データノードの設計では、主に次の側面を考慮します。

1. データノードの高可用性を実現するにはどうすればよいでしょうか?

もちろん、データベース内のデータが最も価値があります。どのデータベースにもデータ冗長性計画が必要であり、データ ノードは高可用性である必要があり、RPO=0 を確保しながら RTO を可能な限り短縮する必要があります。よく考えてみると、各 dn は実際にはデータベース インスタンスです。 MySQL や pg を例にとると、MySQL と pg 自体には高可用性ソリューションが備わっています。マスタースレーブ半同期またはストリーミングレプリケーションのどちらをベースにしても、dn レベルでのデータ冗長性およびスイッチング ソリューションとして使用できます。もちろん、一部のデータベースでは、DN レベルで Paxos、Raft、Quorum などの強力な一貫性ソリューションが導入されており、これは分散データベースでは非常に一般的な設計でもあります。

2. オンライン容量拡張を実現するにはどうすればよいでしょうか?

オンラインでの容量拡張は分散データベースの大きな利点であり、データ ノードを拡張するには必然的にデータを新しいノードに移行することが必要になります。現在、市場に出回っている分散データベースは、基本的に自動データ再分散を実現しています。ただし、自動データベース再配布だけでは不十分です。重要な問題は、サーバーの IO 負荷を軽減するために、いかにして少量のデータのみを移行するかということです。

従来のハッシュ方式では、パーティション キーのハッシュ値に基づいてパーティションの数に対してモジュロ演算を実行します。結果が、データが分類されるパーティションになります。ただし、この分散方法では、ノードを追加または削除するときに大量のデータの再分散が発生します。コンシステント ハッシュの基本的な考え方は、各パーティションが数値ではなく範囲に対応し、計算されたハッシュ値がその範囲内で一致するというものです。一般的な考え方は、データノードとキーハッシュ値を0〜2^32のリングにマッピングし、マッピングされた値の位置から時計回りに検索し、最初に見つかったノードにデータを保存することです。 2^32 経過してもサービス ノードが見つからない場合は、最初のノードに保存されます。一貫性のあるハッシュは、データの再配布の問題を最大限に解決しますが、ノード データの不均一な配布を引き起こす可能性があります。もちろん、仮想ノードの追加など、この問題を改善する方法はいくつかあります。

GTMデザイン

名前が示すように、GTM はグローバルなコンセプトです。分散データベースは、スケーラブルでパフォーマンスを向上させ、グローバルなリスクを軽減するように設計されています。しかし、GTM はこれらすべてを破壊します。

1. GTM が必要な理由は何ですか?

一言でまとめると、GTM はグローバル読み取り一貫性を確保するためのものであり、2 フェーズ コミットは書き込み一貫性を確保するためのものです。ここで誤解があるかもしれません。 GTM がない場合、データの不整合が発生しますか?はい、しかしそれはある時点での読み方の不一致にすぎません。この不整合も一時的なものですが、データの書き込みに不整合が生じることはありません。書き込みの一貫性は 2 フェーズ コミットによって保証されます。

postgresql はスナップショットを通じて MVCC とトランザクションの可視性判断を実装していることがわかっています。読み取りコミット分離レベルでは、各トランザクションのクエリでは、トランザクションが開始される前にコミットされた変更と、現在のトランザクションのクエリの前に行われた変更のみを確認する必要があります。これはスナップショットを通じて実現されます。スナップショット データ構造には、トランザクションの xmin (タプルを挿入するためのトランザクション番号)、xmax (トランザクションを更新または削除するためのトランザクション番号)、実行中のトランザクションのリストなどの関連情報が含まれます。トランザクションの xmin および xmax 情報も、pg の各タプル ヘッダーに記録されます。スナップショットを取得した後、Pg はトランザクションの可視性判定を実行します。 xmin 未満の ID を持つすべてのタプルは現在のスナップショットに表示され、xmax より大きい ID を持つタプルは現在のトランザクションに表示されます。分散クラスターに拡張すると、各マシンに pg のインスタンスが存在します。グローバル読み取り一貫性を確保するには、スナップショット情報をさまざまなノード間で共有できるように、スナップショットの割り当てを担当するグローバル コンポーネントが必要です。これがGTMの仕事です。

2. GTM の高可用性に関する問題は何ですか?

GTM は、グローバル スナップショットとトランザクション ID を割り当てる唯一のコンポーネントです。 GTM は 1 つだけ存在できます。もちろん、GTM は高可用性のために使用できますが、同時に動作できる GTM は 1 つだけです。 gxid 情報はプライマリとバックアップ間で同期されます。これにより問題が発生します。他のノードは分散されていますが、GTM は常に単一のポイントです。 1 つのポイントに障害が発生すると、切り替えが必要になります。切り替えプロセスは世界情勢に影響を及ぼします。さらに、切り替え後に gxid 情報が失われないようにするには、GTM 間で gxid を同期する必要があります。

高可用性の問題に対処するには、GTM のトランザクション番号ストレージ情報を削除し、トランザクション番号情報をサードパーティのストレージに保存することができます。たとえば、etcd は良い選択です。 etcd は、一貫性と可用性に優れた分散ストレージ クラスターです。 etcd は比較的軽量で、トランザクション番号情報を保存するのに適しています。同時に、それ自体が高可用性と強力な一貫性を保証します。この場合、GTM はプライマリ ノードとスタンバイ ノード間で gxid を同期する必要はありません。プライマリとスタンバイの切り替えが発生した場合、新しいプライマリ GTM は etcd から最新のトランザクション番号を取得するだけで済みます。取引番号の書き込みについても同様です。プライマリ GTM は、トランザクション番号情報をプライマリ etcd ノードに書き込み、etcd 独自の raft レプリケーション プロトコルを通じて一貫性を確保します。この設計により、GTM への負担が大幅に軽減されます。

3. GTM パフォーマンスの問題ですか?

GTM はほとんどの分散データベースのパフォーマンスのボトルネックであり、クラスターの全体的なパフォーマンスを単一のマシンよりもさらに低下させます。分かりやすいです。開始されたトランザクションは、まず cn を経由して GTM に行き、トランザクション番号とスナップショット情報を取得し、次に結果を解析して dn に送信して実行し、その後 cn が要約してアプリケーションに返します。経路が明らかに長くなったので、効率は確実に低下します。現状のメリットとしては、複数のマシンの能力を組み合わせて計算できるようになり、計算リソースが拡張されたことが挙げられます。

もちろん、GTM のボトルネック問題には解決策があります。たとえば、Huawei GaussDB は GTM-Free と GTM-Lite を提案しています。 GTM フリーとは、強力な一貫性のある読み取りの要件が高くないシナリオで GTM 機能をオフにすることです。すべての取引が GTM を経由するわけではありません。この場合、パフォーマンスは基本的に直線的に向上します。この機能は実装されました。 GTM-lite はトランザクションを分類します。グローバルトランザクションは GTM を経由し、ローカルトランザクションは直接発行されます。ほとんどの場合はローカルトランザクションなので、パフォーマンスの向上も明らかです。この機能はまだ研究開発段階にあります。

分散データベースでPITRを実装する方法

データベースの PITR は通常、ベース バックアップと継続的な WAL アーカイブによって実現されます。このベース バックアップは、その時点でデータベースが一貫した状態である必要がないため、オンラインで実行できます。一貫性は redo を再生することで実現できるため、ファイル システム レベルのスナップショットを必要とせずに、ファイル システム tar コマンドでベース バックアップを実行できます。

PITR は、基本バックアップと REDO ログを使用して任意の時点に復元できます。この時点の定義は、データベースによって異なります。特定の lsn、特定のスナップショット、または特定のタイムスタンプである可能性があります。 Postgresql データベースでは、REDO に基づいて任意のタイムスタンプにデータを復元できます。

理論的には、分散データベースの PITR は単一マシンの PITR とそれほど変わりません。各ノードは独自の基本データをバックアップしますが、一貫性は必要ありません。ただし、分散トランザクションの問題を考慮する必要があります。基本的なバックアップを実行するときは、以前のすべての分散トランザクション (存在する場合) が完了していることを確認する必要があります。これは、分散トランザクションが 2 フェーズ コミット プロトコルに従うためです。 2PC コミット フェーズでは、異なるマシンのコミット間に時間差が存在する必要があります。この時間差の間にバックアップを作成すると、最後のマシンにはこのトランザクションのやり直しがあるが、他のマシンにはないことがわかります。復元するとデータの不整合が発生します。この問題は、PG のバリアの概念を通じて解決できます。分散トランザクションが完了した後、整合性ポイントを取得するためのバリアが設定され、基本的なバックアップが実行されます。再実行ロールフォワードの場合、すべてのノードの再実行を一貫した場所にロールフォワードするだけで済みます。

著者について:

張小海さんは大手商業銀行に勤務しています。現在、データベース管理と新技術研究を担当しています。彼は PostgreSQL テクノロジの推進者であり、彼の個人公開アカウントは「データベース アーキテクチャの美しさ」です。

[51CTO オリジナル記事、パートナーサイトに転載する場合は、元の著者とソースを 51CTO.com として明記してください]