DDIA Chapter 5

Transcript

1. DDIA Chapter5. Replication 石飛、戸田
2. Table of contents 01 04 02 03 Leaders and Followers Problems with Replication Lag Multi-Leader Replication Leaderless Replication
3. What is Replication? ネットワークで接続された複数のマシン（ノード）に同じデータを複製しておくこと。 このChapterでは複製の方法論について考えていくことを目標にする。
4. Replication / Partitioning • 複数のマシンにデータのコピーを複製する こと • 大規模データセットを複数マシンで分割して 保持すること Replication Partitioning ReplicationとPartitioningを組み合わせて、可用性・パフォーマンスを提供する 製品も多数存在 (e.g. Apache Kafka)
5. Why Replication is essential? パフォーマンス（レイテンシ） パフォーマンス（スループット） 可用性(耐障害性) マシンを地理的に分散させて、 ユーザーとの距離を近くするこ とで、レイテンシを低減 マシンをスケールアウト（e.g. 読み取り専用レプリカ）すること で、スループット向上 一部にフォールトがあってもシ ステムが動作できるので、可用 性向上
6. Leaders and Followers 01 リーダーとフォロワー
7. Leader / Follower • 書き込みクエリを受け付ける • 自分のストレージに適用後、全Followerに レプリケーションログを送信 • 読み込みクエリのみを受け付ける • レプリケーションログを受信後、自分のスト レージに適用しデータを最新化 Leader (Master/Primary) Follower (Slave/Secondary/Read Replica)
8. Sync / Async Replication • フォロワーの書き込みを同期的に行う（=待つ） • データは最新なのでL/F間で一貫性が保証 • レスポンスタイムの増大 • フォロワーの死活に大きく左右される • フォロワーに非同期で書き込み要求 • データの読み取り一貫性はない • レスポンスタイムの低減 • リーダーに障害が発生し、リカバリ不可能な場合デ ータは失われる 同期 非同期 同期的なレプリカ・非同期的なレプリカどちらも採用する準同期型も存在 ※ フォロワー1が同期、 フォロワー2が非同期
9. Setting Up New Followers 一貫性のあるスナップショット 追加分のログレプリケーション • リーダーから一貫性のあるスナップショットをとる。（DB 全体にロックを取らないとbetter） • 取得したスナップショットを新しいノードにレプリケーショ ンする。 • スナップショットのレプリケーションログの位置（ログシ ーケンス番号）を保持。 • ログシーケンス番号以降のデータ変更のログをレプリケー ションする。 • キャッチアップできたら、従来のレプリケーションを始める。 1 ２ 3 1 ２ 3 スナップショットからレプリケーション 1 ２ 3 4 5 4 5 1 ２ 3 追加ログのレプリケーション
10. Handling Node Outages - Follower 1 ２ 3 4 5 4 5 1 ２ 3 障害時以降ログのレプリケーション システム内のノードは、想定内・想定外のダウンが生じる。想定内であればパッチ適用などの計画的メ ンテナンスがある。システム全体としてダウンタイムなしにノードを復旧できれば大きなメリットになる。 フォロワーの障害はキャッチアップリカバリによって対処される。New Followerの対処の時と同様に、 障害前最後のトランザクションをログから判断し、それ移行のデータ変更をリーダーに要求し適用。
11. Handling Node Outages - Leader フォロワーのキャッチアップリカバリと比べて複雑な対処が必要。フォロワーをリーダーに昇格させ、ク ライアントの書き込み要求先を新たなリーダーに変更させるフェイルオーバーで対応。管理者による手 動で行うタイプと、障害検知をはじめ自動で行うタイプがある。 障害検知 新しいリーダーの選出 システムの再設定 • 障害の原因を特定するのではなく、 検知する • タイムアウトを利用し、反応がなけれ ばダウンしていると判断 • コントローラーノードが選出したり、レ プリカのうち一番追従しているものを 選出したり、様々なプロセスがある • 新しいリーダーの選出はノードが合 意形成する必要がある(Chapter 9.) • クライアントに新しいリーダーを知ら せる（サービスディスカバリ） • 古いリーダーをフォロワーに降格させ、 復帰時にリーダーだと認識させない F L F L Heartbeatが帰ってこない 選挙後、リーダーに昇格 F L ルーティング層
12. Handling Node Outages - Leader - Problems • 非同期レプリケーションで、新しいリーダーが古いリ ーダーの全ての書き込みをキャッチアップできてい ない場合 • 再度古いリーダーがクラスタに参加し、競合データ を持っている場合 • 同時に2つのノードが自分をリーダーだと認識する スプリットブレイン • どちらも書き込みを受け付けるがデータ競合解決の 仕組みがないのでデータの破損や損失が生じうる • 競合しているデータの書き込みを破棄し、外部デー タソースとの連携がうまくいかなくなる場合 • Heartbeatのタイムアウトに設定する時間の問題 • 長すぎるとリーダーが実際に障害にあった場合のリ カバリの時間が長くなる • 短すぎると不要なフェイルオーバーが頻繁に発生す る 一見うまくいきそうなフェイルオーバーだが、問題点も多く抱えている。ノード障害時のレプリカの一貫 性や永続性、レイテンシなどの問題は分散システムの基本的問題。
13. Implementation of Replication Logs レプリケーションログの実装は複数種類存在し、DBMSごとに実装が異なる。各方法にはメリット・デメ リットがあることに留意。 ステートメントベース WALの転送 論理（行）ベース トリガベース • SQLなどのクエリのステート メント（INSERT, UPDATE, DELETE）をそのまま転送。 • NOW()などの非決定的な関 数は値に置き換える。 • 複数ステートメントの場合、 リーダーと完全に同じ順序 で実行する。 (INSERT→UPDATE WHEREなどの組み合わせ では適用順が大事) • エッジケースが多数存在す るので他のレプリケーション 方法が良い。 • 「ストレージエンジンでは全 ての書き込みはログに追記 されていく」ことを利用。 • リーダーはログを自身のディ スクに書き込みつつフォロワ ーに高速に転送。 • フォロワーは受信後高速に 適用していくことでデータを 複製できる。 • 低レベルなバイナリログで柔 軟性がないので、ストレージ エンジンの種類やバージョン を同一のものにする必要有。 • PostgreSQLやOracleで利 用。 • ストレージエンジン固有のロ グフォーマットではない論理 ログを利用、表現力が高い。 • 挿入された行、削除された 行、変更された行という様に 行でログレコードを作成。 • 表現力が高く、パースも容易 なのでCDC(Change Data Capture)に利用され、DWH 構築やインデックス構築など 外部ソース連携可能。 • DynamoDB Streamsなども これにあたる。 • RDBMSのトリガやストアド プロシージャを利用してレプ リケーションを行う。 • 異なるデータベース間での レプリケーション、限定的な 複製、複製ロジックなどアプ リケーションレイヤに上がっ てきた時に利用。 • データの変更時に実行され るカスタムアプリケーションコ ードを登録できる。 • DBMSによって実装されな いので柔軟性が高いが、オ ーバーヘッドが大きい、バグ が生じやすい、制約が大き いなどのデメリットもある。
14. Problems with Replication Lag 02 レプリケーションラグにまつわる問題
15. What is Eventual Consistency? 読み取りスケーリングアーキテクチャで非同期レプリケーションを採用している場合(大半)、非一貫性 の読み取りになる。このように遅延度合いに限界のないレプリケーションラグを持つ整合性を結果整 合性という。 特定のデータ だけ古い
16. Read Your Own Writes read-after-write(read-your-write)一貫性は、自分で投入した更新は直後からその後のいつでも反映 していることを保証する。他の人の更新は保証しないので古い値を見る可能性がある。基本的にはリ ーダーから最新の値を読み取ることができることに留意。 • 自分しか変更できないデータ(e.g. SNSにおけるプ ロフィール(/me))を参照するときはリーダーから読 みとる。 • クライアントが書き込んだタイムスタンプを持ってお く。レプリカも更新したタイムスタンプを保持し、それ らを比較することで一貫性を保証する。(論理タイム スタンプ) • クライアント側で書き込みタイムスタンプを保持し、 60秒以内の読み取りであればリーダーから、そうで なければフォロワーから読み取るようにする。 • クロスデバイスread-after-write一貫性は、タイムス タンプのようなメタデータの集中配置のケアが必要。 実装方針
17. Monotonic Reads Monotonic Reads一貫性では、一度読み取った値が変わらないことを保証する。古いデータを読み取 る可能性はあるが、連続して行った複数の(1ユーザーが行う)読み取りにおいて時間は巻き戻らない。 強い一貫性ほどではないが結果整合性よりは強い。 • 各ユーザーが常に読み取りを同じレプリカから行う ようにする。 • ユーザーごとには異なる値を読んでしまうことには 注意。 • 読み取りレプリカをランダムに決めるのではなく、ユ ーザーに基づく情報(e.g. ユーザーID)のハッシュで 決める。 • レプリカに障害が起きたら、他のレプリカにルーティ ングする。 実装方針
18. Consistent Prefix Reads 一貫性のあるプレフィックス読み取り一貫性では、因果律を保証する。因果律とは、例えばある順序で 一連の書き込みが行われた場合、それらの書き込みを読み取るものには必ず書き込まれた際と同じ 順序でそれらが見えること。 • 互いに因果関係を持つ書き込みを同じパーティショ ンに書き込む。(因果関係を明示的に追跡できるア ルゴリズムについては後述) 実装方針
19. Multi-Leader Replication 03 マルチリーダーレプリケーション
20. What is Multi-Leader Replication? マルチリーダー構成(マスター-マスター、アクティブ/アクティブ)シングルリーダーアプリケーションにお けるリーダーの単一障害点を克服するべく、複数のリーダーを用意し書き込みを受け付ける手法。レ プリケーションの手法はこれまでと同じ。代表的なユースケースは以下。 マルチデータセンターでの利用 オフラインで運用されるクライアント コラボレーティブな編集 • 複数のデータセンターにリーダーを配置 • DC間では非同期に連携 • 障害にも対応可 • DC間の接続は公開ネットワークを使用 • 異なるDCで同じデータを書き換える衝 突が起こる可能性がある • クライアントがインターネットに接続され ていない時でもアプリケーションが動作さ れるユースケース • デバイス(クライアント)が次にオンライン になったらサーバーに同期 • このユースケースでは全てのデバイスは ローカルDBを持つリーダーの役割 • 複数のユーザーがドキュメントを同時に 編集するユースケース(Google Docs) • ユーザーのローカルにはすぐに反映され るべきで。他のユーザーには非同期で 反映されるべき • 編集の衝突を避けるには変更している 箇所のロックを取る • パフォーマンスを改善するならコミットす る単位を小さくするとロックを回避できる が、衝突の完全な解決にはならない
21. Handling Write Conflicts マルチリーダーの最大の問題は書き込みの衝突が起きること。衝突の処理を4つ紹介。 ドキュメント同時編集機能における衝突の例。 各々ローカルには適用できるがオンラインになった時 に衝突してしまう。 1. 衝突の検出 2. 衝突の回避 3. データの収束 4. カスタムの衝突解決ロジック
22. Handling with Conflicts 衝突の検出 衝突の回避 データの収束 カスタムの衝突解決ロジック • 非同期検出 • 衝突しうる場合でも書 き込みを成功させて、 後に非同期的に衝突 を検出する • この時点ではユーザ ーに解決を求めても 遅すぎるかもしれな い • 同期検出 • 書き込みが全てにレ プリケーションされる のを待つ • この方法はマルチリ ーダーレプリケーショ ンのメリットが失われ る • 推奨されることが多 いアプローチ • あるレコードに対する 書き込みが同じリー ダーに送られることを 保証する • 書き込む個人から見 ると、シングルリーダ ー構成と変わらない • フェイルオーバーなど で、ルーティングされ るデータセンターが変 わり得るなら、結局他 の方法で対処しない といけない • マルチリーダーでは 書き込みに定まった 順序がないので、受 け付けた順序で書き 込むとレプリカ間で整 合性が取れない • 書き込み or レプリカ にユニークなIDを与 えて、衝突時はIDの 大きいもの以外は破 棄する（LWW） • 何らかの方法で衝突 した値をマージする • 全ての情報を保存し、 ユーザーに後で解決 してもらう • 書き込み時の解決 • 変更ログから衝突を 検出した際に、衝突 解決のハンドラを呼 ぶ • ハンドラはバックグラ ウンドプロセス内で高 速に動作する必要が ある • 読み込み時の解決 • 衝突が検出された際 に、全ての書き込み を保存し、アプリケー ションに全て返す • アプリケーションが解 決したり、ユーザーが 解決したりする
23. Replication Topology あるノードからほかのノードへと書き込みを伝播する通信経路をレプリケーションのトポロジーという 循環トポロジー スタートポロジー • 書き込みが全てのレプリカに行き渡る までに複数のノードを経由する • 無限ループ防止のため、各ノードに識 別子を与え、ログに識別子をタグ付け し、自身の識別子がタグづけされたロ グを無視する • 1つのノード障害が全てのレプリケーシ ョンを止めてしまう • ノード障害時のトポロジーの再構成は 通常手作業で行う必要がある
24. Replication Topology All-to-all トポロジー • 単一障害点を持たないため耐障害性 が高い • 一部のレプリケーションメッセージが他 のメッセージを追い越すことで、因果律 の問題が起きる可能性がある • メッセージを正しく順序づけるには、後 述のバージョンベクトルが利用できる
25. Leader-Less Replication 04 リーダーレスレプリケーション
26. What is Leader-Less Replication? どのレプリカもクライアントからの書き込みを受け付けるDB。Dynamoスタイルとも呼ばれ、 CassandraやRiak、Voldemortで採用されている。（DynamoDBはリーダーレスではない） • 書き込みリクエストを複数のレプリカに送 信し、書き込みできなかったレプリカは無 視する • 読み取りリクエストも複数のノードに送信 し、より新しいバージョンの値を真とする • 古いデータは新しいデータに更新する 実装方針
27. Eventual Consistency Mechanisms 読み取り修復と反エントロピー処理 読み書きのためのクオラム • 読み取り修復 • ノードから並列に読み取りを行った結果、 古いレスポンスが返ってきた場合は、 新しい値を書き戻す • 反エントロピー処理 • バックグラウンドプロセスで、レプリカ間 でデータの差異を探し、欠けて入るデ ータがあれば、他のレプリカへコピーす る • n個のレプリカのうち、w個のノードで書 き込みが成功し、読み取りの時にr個の ノードにクエリしたとする時、w + r > nで ある限り最新の値が得られる • n = 5, w = 3, r = 3の時は以下の図の ようになる
28. Limitation of Quorum Consistency 2つの書き込みが並行して行われる時 読み取りと並行して書き込みが行われる時 書き込みが部分的に失敗する時 ノード障害からのリストアの時 遅延のモニタリング 並行の書き込みによる衝突は、マルチリーダーレプリケーションと同様に発生しうる 並行して書き込まれている新しい値が読み取られるかどうかがわからない 部分的に書き込みが成功してしまっている時にロールバックされないので、そのデータがどうなるのかわから ない 古いデータを持つノードからリストアされることで、新しい値を持つレプリカの数がwを下回るかもしれない リーダーベースと違い、書き込みが適用される順序が決まっていないので、レプリカのデータの古さの計測が 難しい
29. Sloppy Quorums and Hinted Handoff n = 6 個のノード 障害解消時に転送 （ヒント付きのハンドオフ） n以外のノードで w = 3 を満たす • 障害により、一部のノードにしか接続できな い時に、別の場所で書き込みを受けるける ことでクオラムを満たしたとすることをいい加 減なクオラムという • 障害が解消したときに、一時的に受けるけ ていた書き込みはホームノードに転送される （ヒント付きのハンドオフ） • 書き込みの可用性が高まる • ヒント付きのハンドオフが完了するまでは、r 個からの読み取りで最新の情報が読み取 れる保証はない
30. Detecting Concurrent Writes 結果整合性を実現するためには、レプリカは同じ値に収束しなければならない。衝突したデータを失わ ないために、アプリケーション開発者は使用するデータベースの衝突に対する処理を知る必要がある。 リーダーレスレプリケーションによる平行書き込みの例。順序は非決定的。
31. What is Concurrent? 並行とは2つの操作が依存関係にないことを意味し、時間的重なりの有無は関係ない。 並行でない 並行 • 操作Bは操作Aに依存しているので、操作B は操作Aに対して因果関係を持つ。 • 因果関係を持つ操作は並行でない。 • 操作Aと操作Bの関係を事前発生(happens- before)関係という。 • 操作Aと操作Bは、お互いに独立して行われるので、 因果関係を持たない。 • 因果関係を持たない操作は並行。
32. Capturing the happens-before relationship サーバーはバージョン番号を見ることで事前発生関係(or 並行性)を検出できる。 1. S: 全てのキーに対してバージョ ンを管理 2. C: 書き込む前にキーを読み取る 3. S: 上書きされていない全ての値 をバージョン番号を合わせて返 す 4. C: 読み取ったバージョン番号と、 マージ済みの値を書き込む。 5. S: 受信したバージョン以下の値 を上書きするが、より大きいバ ージョンは上書きしない。 S: サーバー C: クライアント クライアントのsiblingなデータのマージは和集合を取るだけ でなく、削除記録を残すためにtombstoneを残す必要があっ たり…(RiakはCRDTでサーバー側で解決するらしい) https://qiita.com/everpeace/items/bb73ec64d3e682279d26
33. Version vectors レプリカが複数ある、リーダーレス(マルチリーダー)の構成ではバージョンベクトルを使用する。 参考 - https://docs.riak.com/riak/kv/2.2.3/learn/concepts/causal-context/index.html - https://github.com/ricardobcl/Dotted-Version-Vectors