見出し画像

第9章 一貫性と合意

前の章

前の章である第8章 分散システムの問題はこちらです。

一貫性の保証

結果整合性は、複数のノード間でデータをレプリケートする際に遅延が発生する可能性があっても、データは最終的にはすべてのノードに到達します。

ただし、これは弱い保証になります。レプリカがいつ収束されるかについては言及されておらず、単に収束します。

線形化可能性

線形化可能性とは Register (key/行) の読み書きにおける最新性を保証することです。

これは最新性の保証でもあり、読み取られる値は最新の値である必要があり、古いキャッシュからのものではないことを意味します。
基本的に、クライアントが書き込みを正常に完了するとすぐに、他のすべてのクライアントは書き込まれた値を参照する必要があります。

線形化可能性と直列化可能性

線形化可能性は、単一オブジェクトの読み取りおよび書き込みにおける最新性の保証です。

直列化可能性は、トランザクションが何らかの直列順序で実行されたかのように動作することです。つまり、次のトランザクションが開始される前に各トランザクションが完了することを保証する、トランザクションの分離特性です。

第7章で登場した「直列化可能なスナップショット分離」は線型化可能では無いということが強調されています。つまり、最新性の保証が弱いということです。

線形化可能性への依存

線形化可能性は最新性の保証のメリットがありますが、すべてのアプリケーションで重要というわけではありません。ただし、システムを正しく動作させるために線形化可能性が重要であるケースがあります。

ロックとリーダーの選出

シングル リーダーレプリケーションを備えたシステムでは、すべてのノードの中で1つのリーダーのみが存在することを保証する必要があります。
リーダーの選出を実装する 1 つの方法は、ロックを使用することです。

Apache ZooKeeper と etcd は、分散ロックとリーダー選出の実装によく使用されます。

線形化可能性のコスト

ネットワークの分断や障害に直面した場合、システムは可用性か線形化のどちらかを選択する必要があります。簡単に言えば、それが CAP 定理です。

線形化可能性を必要としないアプリケーションは、ノードがリクエストを処理し続けることができるため、ネットワークの問題に対する耐性が高くなります。

線形化可能性とネットワーク遅延

線形化可能性は、ネットワーク障害時だけでなく常に遅くなります。

線形化可能性が必要な場合、読み取りおよび書き込みリクエストの応答時間はネットワークの遅延の不確実性に少なくとも比例するという証明があります。

Sequential Consistency versus Linearizability

遅延が大きく変動するネットワークでは、応答時間は確実に長くなります。一貫性モデルが弱いと、線形化可能性よりもはるかに高速になる可能性があり、すべてのことに言えることですが、常にトレードオフが存在します。

正確さを犠牲にすることなく線形化可能性を回避するために提案されたアプローチがいくつかを第12章では紹介します。

分散トランザクションと合意

合意 (consensus) とは、複数の node を「何かについて」合意させることです。
リーダーの選出やアトミックコミットなど、特にいくつかのケースでは合意が重要になります。
リーダーの選択で合意がない場合 (つまり、単一リーダー構成のシステムで 2 つのリーダーが書き込みを受け入れる場合)、データは不整合になります。

アトミックコミットと 2相コミット (2PC)

2相コミットは、準備とコミットの 2 つのフェーズを実装することでアトミック性を提供することで、単一ノードのトランザクションから分離します。トランザクションマネージャー (またはコーディネーター) はこのプロセスを管理し、すべてのノードが確実にコミットまたは中止されるようにします。

comeshareより)

耐障害性を持つ合意

形式的には、1 つ以上のノードが値を提案し、コンセンサス アルゴリズムが提案された値の 1 つを決定します。コンセンサス アルゴリズムはすべて、次の特性を満たす必要があります。

  • 一様同意: 2 つのノードが異なる決定をすることはありません。

  • 整合性:二度決定するノードはありません。

  • 妥当性:ノードが値 v を決定した場合、v はあるノードによって提案されたものです。

  • 終了性:クラッシュしなかったすべてのノードは、最終的に何らかの値を決定します。

合意の限界

これまで合意の種類や方法について述べてきましたが、下記のような問題点も顕在です。

  • 提案プロセスに対する投票は、同期レプリケーションと非常に似ています。コミットされたデータは失われる可能性があります。

  • コンセンサスでは、ノードの厳密な過半数が動作する必要があります。 3 つのノードがある場合は、1 つのノードの障害を許容できます。ネットワーク障害が発生した場合、非多数派がブロックされる可能性があります。

  • システムへのノードの追加と削除は困難です。基本的に合意には、固定されたノードのセットが必要です。

  • 合意は、障害が発生したノードを検出するためにタイムアウトに依存します。頻繁にリーダーが選出されるため、際限のない遅延が発生するとパフォーマンスが低下する可能性があります。

補足

データベースによって保証される整合性レベルは外部整合性であるという主張もあります。

まとめ

以上、分散システムの問題について解説しました。

この章は少し難しい内容が多く、また、アカデミックな内容も一部含まれているので理解するのに時間がかかる可能性があります。
もし、内容が入ってこなければ、一旦次の章を読むことをオススメします。

分散システムの問題について特に重要な点を解説しました。ただし、非常に量が多いため解説していない部分が多々あります。詳細は本書を手にとってみて下さい。


いいなと思ったら応援しよう!

zono
よろしければ応援お願いします! いただいたチップはデータエンジニアとしての活動費や勉強代、教育に使わせていただきます!