結果整合性とは? 時間をかけて収束する

結果整合性は、変更のあと、レプリカやread modelが即座にではなく時間をかけて整合するモデルです。

分散システムでは、可用性や速度を犠牲にせずに、あらゆる場所で即座に整合したデータを得ることはしばしばできません。結果整合性は、異なる部分が異なる値を見る短い期間を受け入れつつ、新しい書き込みがなければすべてが収束するという保証を伴います。この期間を理解することは、分散システムを構築し、そしてテストするうえで不可欠です。

保証が実際に述べていること

結果整合性は、新しい更新が起きなければ、すべてのレプリカが最終的に最後に書き込まれた値を返すことを約束します。いつかは約束しません。収束の期間中、二人の読み手が正当に異なるデータを見ることがあります。

システムが受け入れる理由

より高い可用性: ノードはグローバルな合意を待たずに読み取りを提供します。
より低いレイテンシ: リージョン間の同期的な調整が不要です。
レプリカやリージョンをまたいだ、より高いスケーラビリティ。
イベント駆動設計では、しばしば唯一の現実的な選択肢です。

期間を前提とした設計

ラグを隠すか受け入れます。read-your-own-writesの保証、楽観的UI、バージョンスタンプ、あるいは競合解決です。整合していないのに強整合であるかのように装うことが、結果整合性のバグの発生源です。

テストの落とし穴

結果整合性はflakyなテストの筆頭の原因です。書き込んですぐ読むテストは、read modelが追いついていないために断続的に失敗しえます。修正策は、固定のsleepを追加することではなく、タイムアウト付きでポーリングするか収束のシグナルを待つことです。

デプロイと古い読み取り

デプロイ中、レプリカやprojectionが短時間、古いデータを提供することがあります。それを許容するよう機能を設計し、書き込みが即座にあらゆる場所で見えると仮定しないことが、ロールアウトを驚きのないものに保ちます。

収束テストを安定させる

ポーリングして待つ収束テストは、即座のアサーションより時間がかかります。高速で一貫したrunner (Latchkeyが提供するもの) はタイミング関連のflakinessを減らし、これらのテストを信頼できるままに保ちます。

重要なポイント

結果整合性は、即座の一致ではなく、時間をかけた収束を保証します。
即座の整合性を、可用性・レイテンシ・スケールと引き換えにします。
flakyなテストの主要な原因なので、sleepするのではなく収束を待ちましょう。