分散ストレージシステムの機能に関する簡単な説明

異常分類

分散ストレージ システムが重点を置く例外の種類は、モノリシック システムの場合とは異なります。それらは次のとおりです。

• サーバーのダウンタイム: ストレージ システムを設計するときは、永続的なメディア (機械式ハード ドライブやソリッド ステート ドライブなど) からデータを読み取ってメモリ情報を復元する方法を考慮する必要があります。
• ネットワーク異常: フォールト トレラント システムを設計する際の基本原則は、ネットワークは常に信頼できないということです。メッセージは、相手からの返信を受け取った場合にのみ、正常に送信されたとみなされます。システムを設計する際には、ネットワークに異常が発生することを常に想定し、それに応じた対策を講じます。
• ディスク障害: ディスク データ エラーは、多くの場合、チェックサム メカニズムを使用して解決できます。

例外に加えて、「タイムアウト」状態もあります。 RPC 実行の結果には、「成功」、「失敗」、「タイムアウト」(不明な状態) の 3 つの状態があり、これらは分散ストレージ システムの 3 つの状態とも呼ばれます。

[[206045]]

一貫性の保証

レプリケーションは、分散ストレージ システムにおけるフォールト トレランスの唯一の手段です。複数のレプリカが存在するため、レプリカ間の一貫性をどのように確保するかが、分散システム全体の理論的な中核となります。クライアントの観点から見ると、一貫性には次の 3 つの状況が含まれます。

1. 強い一貫性:

2. 一貫性が弱い:

3. 結果的一貫性: 結果的一貫性は弱い一貫性の特殊なケースです。 「最終的な」一貫性には「不整合ウィンドウ」（時間遅延）があります。結果的一貫性の説明は比較的大まかですが、一般的なバリエーションは次のとおりです。

• 書き込みの一貫性の読み取り
• セッション一貫性
• 単調な読み取り一貫性
• 単調な書き込み一貫性

ストレージ システムの観点から見ると、一貫性には主に次の側面が含まれます。

1) レプリカの一貫性: ストレージ システムの複数のレプリカ間のデータが一貫しているかどうか、一貫性のない時間ウィンドウなど。

2) 更新順序の一貫性: ストレージ システムの複数のコピーが同じ順序で更新操作を実行するかどうか。

メトリクス

分散ストレージ システムを評価するために一般的に使用される指標がいくつかあります。

パフォーマンス: スループット (QPS、TPS)、応答遅延。

可用性: システムの可用性は、システムが稼働していない時間と通常稼働している時間の比率で測定できます。

一貫性: 一貫性モデルが強力であればあるほど、ユーザーにとって使いやすくなります。システムが同じデータセンターに導入されている場合、システムが合理的に設計され、強力な一貫性が確保されている限り、パフォーマンスと可用性に大きな影響はありません。

スケーラビリティ: システムのスケーラビリティとは、クラスター サーバーの規模を拡大することで、システムのストレージ容量、コンピューティング能力、パフォーマンスを向上させる分散ストレージ システムの能力を指します。

パフォーマンス分析

一般的に言えば、分散システムのパフォーマンス分析の結果は不正確です。ただし、少なくとも推定結果が実際の値と桁違いに異なることはないと保証できます。たとえば、Google の BigTable でのランダム書き込みとシーケンシャル書き込みのパフォーマンスは似ています。書き込み操作では、まず操作ログを GFS に書き込み、次にローカル メモリを変更する必要があります。パフォーマンスを向上させるために、BigTable はグループ化されたヒント テクノロジを実装します。

ストレージ システムの基盤となる設計と実装を理解し、それを実際に継続的に実践することによってのみ、パフォーマンスの推定はより正確になります。

データ配信

1. ハッシュ分散（代表例：Dynomo）：ハッシュ関数のハッシュ特性が優れている場合、ハッシュ方式はクラスター内でデータをより均等に分散できます。ただし、ハッシュ特性が優れたハッシュ関数を見つけるのは困難です。これは、主キーに従ってハッシュ化を行うと、同じユーザー ID のデータが複数のサーバーに分散され、同じユーザー ID の複数のレコードを一度に操作することが困難になるためです。ユーザー ID に従ってハッシュ化を実行すると、「データ スキュー」問題が発生しやすくなります。つまり、一部の大規模ユーザーのデータ量は非常に大きく、クラスターの規模に関係なく、これらのユーザーは常に 1 つのサーバーによって処理されます。もう 1 つのアイデアは、分散ハッシュ テーブル (DHT) アルゴリズム (時計回りの検索) を使用することです。一貫性ハッシュの利点は、ノードが追加または削除された場合、ハッシュ リング内の隣接ノードにのみ影響し、他のノードには影響がないことです。一貫性のあるハッシュ アルゴリズムにより、データの移行が大幅に回避されます。 Dynamo システムは、時間のためにスペースを犠牲にし、各サーバー上でクラスター全体のすべてのサーバーの位置情報を保持し、サーバーの検索にかかる時間の複雑さを O(l) に削減します。一貫性のあるハッシュでは、負荷分散も考慮する必要があります。より良いアプローチは、「仮想ノード」の概念を導入することです。

2. シーケンシャル分散（代表例：BigTable）：ハッシュハッシュはデータの秩序性を破壊し、ランダム読み取り操作のみをサポートし、シーケンシャルスキャンはサポートしません。分散テーブル システムでは、順次分散が一般的です。一般的なアプローチは、大きなテーブルを連続した範囲に順番に分割し、各範囲をサブテーブルと呼ぶことです。 Bigtable は、主キーに基づいて大きなテーブルを順序付けられた範囲に分割し、各順序付けられた範囲がサブテーブルになります。より大きなクラスター サイズをサポートするために、Bigtable などのシステムでは、インデックスをルート テーブルとメタデータ テーブル (メタ テーブル) の 2 つのレベルに分割します。 Meta テーブルは、User テーブルの場所情報を保持します。シーケンシャル分散は、B+ ツリー データ構造に似ています。各サブテーブルはリーフノードに相当します。データが挿入および削除されると、一部のサブテーブルが非常に大きくなり、一部のサブテーブルが非常に小さくなる可能性があり、その結果、データの分散が不均一になります。順次配布を使用する場合は、システムを設計するときにサブテーブルの分割と結合を考慮する必要があります。サブテーブルをマージする目的は、システム内に小さなサブテーブルが多すぎるのを防ぎ、システム内のメタデータを削減することです。

3. 負荷分散: 動作中のノードは、CPU、メモリ、ディスク、ネットワークなどのリソースの使用状況、読み取りおよび書き込み時間、読み取りおよび書き込みデータ量などのノード負荷に関連する情報を、ハートビートパケット (Heartbeat、定期的に送信される) を通じてマスターノードに送信します。負荷分散操作はリズムを制御し、比較的スムーズに行う必要があります。一般的に、新しいマシンが追加されてから、クラスターの負荷が比較的バランスの取れた状態になるまでには、30 分から 1 時間といった長い時間がかかります。

コピー

レプリケーション プロトコルには、図 1 に示すように、強力な同期レプリケーションと非同期レプリケーションの 2 種類があります。

図1 マスタースレーブレプリケーションプロトコルのデモンストレーション

強力な同期レプリケーションと非同期レプリケーションはどちらも、プライマリ レプリカのデータを何らかの形式で他のレプリカに送信します。このレプリケーション プロトコルはプライマリ ベース プロトコルと呼ばれます。この方法では、書き込み操作の順序を決定するプライマリ レプリカは常に 1 つだけ存在する必要があります。プライマリ レプリカに障害が発生した場合は、バックアップ レプリカを新しいプライマリ レプリカとして選択する必要があります。この操作は選挙と呼ばれ、古典的な選挙プロトコルは Paxos プロトコルです。

プライマリ コピーとバックアップ コピー間のレプリケーションは、通常、操作ログを通じて実行されます。操作ログの原理は非常に単純です。ディスクの順次読み取りおよび書き込み特性を有効活用するために、クライアントの書き込み操作は最初にディスクに順次書き込まれ、次にメモリに適用されます。メモリはランダムに読み書きされるデバイスであるため、B+ ツリーなどのさまざまなデータ構造を通じてデータを効率的に整理することが容易です。サーバーがクラッシュして再起動した場合は、操作ログを再生するだけでメモリ状態を復元できます。システムの同時実行性を向上させるために、システムは一定量の操作ログを蓄積し、それらを一括してディスクに書き込みます。この技術は一般にグループ提出と呼ばれます。

サーバーに障害が発生するたびにすべての操作ログを再生する必要がある場合、効率が悪くなります。チェックポイントは、この問題を解決するために設計されています。システムは、メモリの状態をチェックポイント ファイルの形式で定期的にディスクにダンプし、チェックポイントの瞬間に対応する操作ログの再生ポイントを記録します。チェックポイント ファイルが正常に作成された後、再生ポイントより前のログをガベージ コレクションできます。将来サーバーに障害が発生した場合、チェックポイント以降の操作ログのみを再生する必要があります。 （「チェックポイント」以降のデータのみがメモリ内にあります）

分散ストレージ システムでは、自動フォールト トレランス、つまり CAP 理論の「パーティション トレランス」を常に満たす必要があるため、一貫性と書き込み操作の可用性を同時に満たすことはできません。たとえば、Oracle Database の DataGuard レプリケーション コンポーネントには、次の 3 つのモードが含まれています。

最大保護モード: つまり、強力な同期レプリケーション モードです。書き込み操作では、操作ログをクライアントに正常に返す前に、プライマリ データベースが操作ログ (データベースの redo/undo ログ) を少なくとも 1 つのスタンバイ データベースに同期する必要があります。

最大パフォーマンス モード: 非同期レプリケーション モードでは、プライマリ データベースで書き込み操作が正常に実行されるだけで、クライアントに成功メッセージが返されます。

最大可用性モード: 上記の 2 つのモードの妥協点です。

フォールトトレランス

一般的な障害の中で、単一マシン障害とディスク障害の発生確率が最も高くなります。分散システムでは、リース メカニズムを通じて障害検出を実行できます。

リース メカニズムは、タイムアウト付きの認証の一種です。マシン A がマシン B に障害があるかどうかを検出する必要がある場合、マシン A はマシン B にリースを発行できます。マシン B はリースの有効期間内にのみサービスを提供できます。それ以外の場合は、自動的にサービスの提供を停止します。リースの仕組みを実装する際には、前払い金額を考慮する必要があることに注意してください。

障害回復中、マスター制御ノードは通常、1 時間などの一定期間待機する必要があります。以前オフラインだったノードがオンラインに戻った場合、一時的な障害とみなすことができます。それ以外の場合は、永久的な障害とみなされます。停止時間は、障害検出時間と障害回復時間の 2 つの部分で構成されます。障害検出時間は通常、数秒から 10 秒以上であり、これはクラスターのサイズと密接に関係しています。クラスターのサイズが大きいほど、障害検出がマスター制御ノードに与える負荷が大きくなり、障害検出時間が長くなります。

図2 障害回復

スケーラビリティ

ほとんどの分散ストレージ システムには、マスター制御ノードが装備されています。これを踏まえると、マスター制御ノードにはボトルネックの問題があり、分散型 P2P アーキテクチャの方が利点が多いと多くの人が当然考えるでしょう。しかし、そうではありません。主流の分散ストレージ システムのほとんどにはマスター制御ノードがあり、数万ユニットのクラスターをサポートできます。スケーラビリティは、ノード障害後の回復時間、容量拡張の自動化の程度、容量拡張の柔軟性などを総合的に考慮する必要があります。

分散ストレージ システムには、データ分散情報を維持し、ワーカー管理、データの場所、障害検出と回復、負荷分散などのグローバル スケジューリング タスクを実行するために使用されるマスター コントロール ノードが存在することがよくあります。マスター制御ノードを導入することで、システム設計が簡素化され、強固な一貫性とユーザーフレンドリーな操作性を実現しやすくなります。それで、マスター制御ノードはパフォーマンスのボトルネックになるのでしょうか?マスター制御ノードがボトルネックになる場合、たとえば 10,000 台を超えるデバイスのクラスター サイズをサポートする必要がある場合や、多数の小さなファイルをサポートする必要がある場合は、図 3 に示すように 2 レベル構造を採用できます。

図3 2レベルのメタデータ構造

データベースを拡張する際に、システムの読み取り容量が不足する場合は、レプリカを追加することで解決できます。システムの書き込み容量が不足する場合は、業務の特性に応じてデータを再分割することができます。一般的な方法は、容量を 2 倍にすること、つまり各シャードのデータを 2 つのシャードに分割することです。拡張プロセス中に、データの半分を新しく追加されたストレージ ノードに移行する必要があります。従来のデータベース アーキテクチャでは、スケーラビリティに関して次のような問題があります。

1. 容量拡張の柔軟性が十分ではありません。

2. 容量拡張が十分に自動化されていません。

3. コピー時間を長くします。

同じグループ内のノードは同じデータを提供するため、このようなシステムは同種システムと呼ばれます。同種システムの問題は、レプリカを追加するときに移行する必要があるデータの量が多すぎることです。データのコピー処理中にストレージ ノードが再び障害を起こす可能性が非常に高いため、このようなアーキテクチャは自動化が難しく、大規模な分散ストレージ システムには適していません。異機種混合システムでは、データを同様のサイズの多数のシャードに分割し、各シャードの複数のコピーをクラスター内の任意のストレージ ノードに分散できます。クラスター全体がノードの障害回復プロセスに参加するため、障害回復時間は非常に短く、クラスターのサイズが大きいほどその利点は明らかになります。

図4 同質システムと異質システムの違い

分散プロトコル

コンピュータの世界では、一つの問題を解決すると、他の問題も発生します。これは、IT アーキテクチャが常にバランスの芸術であることを別のレベルから証明しています。

「BASE」の核となる考え方は、ビジネス特性に応じて適切な方法を使用してシステムが最終的な一貫性を実現するようにすることです。インターネット分野では、通常、システムの高可用性と引き換えに強力な一貫性を犠牲にする必要があります。データの「最終的な一貫性」を確保することだけが必要ですが、この最終時間はユーザーが許容できる範囲内である必要があります。しかし、金融関連の取引の分野では、取引の正確性と信頼性を確保するために、依然として強力な一貫性方式を使用する必要があります。

業界には、2 フェーズ コミット、3 フェーズ コミット、Sagas ロング トランザクション、補正モード、信頼性の高いイベント モード (ローカル イベント テーブル、外部イベント テーブル)、信頼性の高いイベント モード (非トランザクション メッセージ、トランザクション メッセージ)、TCC、Paxos とその関連バリアントなど、一般的なトランザクション処理モードが多数あります。異なるトランザクション モデルは、異なるデータ一貫性をサポートします。ここでは各プロトコルについて詳しく説明しません。分散ストレージに関しては、2 フェーズ コミット プロトコルと Paxos プロトコルが最も一般的に使用されています。以下では、これら 2 つのプロトコルに焦点を当てます。

1. 2 フェーズ コミット (2PC): 分散トランザクションを実装するためによく使用されます。 2 フェーズ プロトコルでは、システムには通常 2 種類のノードが含まれます。1 つはコーディネーターで、通常、システム内に 1 つだけ存在します。もう 1 つはトランザクション参加者 (コホートまたはワーカー) であり、通常は複数の参加者が含まれます。

このプロトコルでは、各ノードが操作ログを記録し、それを不揮発性ストレージ メディアに保存することを想定しているため、ノードに障害が発生してもログが失われることはありません。提出フェーズでは、コーディネーターが第 1 フェーズの投票結果に基づいて、提出するかキャンセルするかを決定します。また、トランザクションタイムアウトメカニズムを導入することで、リソースを解放できない状況を防ぐことができます。

2 フェーズ コミット プロトコルでは、次の 2 種類の障害が発生する可能性があります。

トランザクション参加者が失敗しました。各トランザクションにタイムアウトを設定します。トランザクション参加者が応答しない場合は、タイムアウト期間後にトランザクション全体が失敗します。

コーディネータが失敗しました。コーディネーターは、トランザクション関連の情報を操作ログに記録し、バックアップ コーディネーターと同期する必要があります。コーディネーターが失敗した場合、バックアップ コーディネーターが引き継いで後続の作業を完了できます。バックアップコーディネーターが存在せず、コーディネーターが永久に失敗した場合には、トランザクション参加者はトランザクションを完了できず、永久に待機する必要があります。

要約すると、2 フェーズ コミット プロトコルはブロッキング プロトコルです。

2. Paxos プロトコル: 複数のノード間の一貫性の問題を解決するために使用されます。複数のノード間の操作ログの一貫性が保証されている限り、分散ロック サービス、グローバル命名および構成サービスなどの高可用性グローバル サービスをこれらのノード上に構築できます。高可用性を実現するために、マスター ノードは操作ログの形式でスタンバイ ノードにデータを同期することがよくあります。マスター ノードに障害が発生した場合、スタンバイ ノードが自身をマスター ノードにすることを提案します。ネットワークが分割されている場合、プライマリ ノードになることを提案するスタンバイ ノード (Proposer) が複数存在することがあります。 Paxos プロトコルは、複数の提案者が同時に存在する場合でも、すべてのノードが最終的に合意に達し、一意のマスター ノードを選出できることを保証します。

（３）Paxosと2PCの違い：Paxosプロトコルと2PCプロトコルは分散システムにおいて異なる役割を果たします。 Paxos プロトコルは、同じデータ シャードの複数のコピー間のデータの一貫性を確保するために使用されます。この要件は、これらのレプリカが異なるデータ センターに分散されている場合に特に強くなります。 2PC プロトコルは、複数のデータ シャードに対する操作のアトミック性を保証するために使用されます。これらのデータ フラグメントは異なるサーバーに分散される可能性があり、2PC プロトコルにより、複数のサーバーでの操作がすべて成功するか、すべて失敗することが保証されます。

Paxos プロトコルには 2 つの用途があります。1 つは、Google Chubby や Apache Zookeeper などのグローバル ロック サービスまたは命名および構成サービスを実装するために使用することです。もう 1 つの用途としては、Google Megastore や Google Spanner などの複数のデータセンターにユーザー データを複製するために使用することが挙げられます。

2PC プロトコルの最大の欠点は、コーディネータのクラッシュの問題に対処できないことです。コーディネータがダウンした場合、2PC プロトコルの各参加者は、トランザクションをコミットするかロールバックするかを認識できない可能性があります。プロトコル全体がブロックされ、実行プロセス中に要求されたリソースを解放できません。したがって、一般的な方法は、2PC と Paxos プロトコルを組み合わせ、2PC を使用して複数のデータ シャードに対する操作の原子性を保証し、Paxos プロトコルを使用して同じデータ シャードの複数のコピー間の一貫性を実現することです。さらに、Paxos プロトコルは、2PC プロトコルにおけるコーディネータのダウンタイムの問題を解決するために使用されます。 2PC プロトコルのコーディネータに障害が発生すると、Paxos プロトコルを通じて新しいコーディネータが選出され、サービスの提供を継続します。

データセンター間の展開

コンピュータ ルーム間のデータ同期モードは、強力な同期または非同期になります。非同期モードを使用すると、バックアップ コンピュータ ルームのデータはメイン コンピュータ ルームのデータより常に遅れます。強力な同期モードを使用すると、バックアップ コンピュータ ルームのデータはメイン コンピュータ ルームのデータと一致します。メインコンピュータ室に障害が発生した場合、手動切り替えに加えて、分散ロックサービスを使用してメインコンピュータ室のサービスを検出する自動切り替えも使用できます。メインコンピュータ室に障害が発生した場合、バックアップコンピュータ室が自動的にメインコンピュータ室に切り替わります。