5.4 リーダーレスレプリケーション

「データ指向アプリケーションデザイン」輪講資料

補足

Amazon DynamoDBはトランザクション対応していました

https://docs.aws.amazon.com/ja_jp/amazondynamodb/latest/developerguide/transaction-apis.html

Transcript

1. データ指向アプリケーションデザイン 5.4 リーダーレスレプリケーション
2. 目次 レプリケーション レプリケーションのアプローチ リーダーレスレプリケーション DynamoDB概要 DynamoDBを構成する技術 Consistent Hashing DynamoDBにおけるレプリケーション DynamoDBの一貫性 モノトニックな読み取り一貫性 自分が書いた内容の読み取り一貫性 ノードがダウンしている状態での書き込み 読み取り修復（Read repair） 反エントロピー（Anti-entropy）処理 読み書きのためのクオラム（Quorum） いい加減なクオラムとヒント付きのハンドオフ クオラムの一貫性の限界
3. レプリケーション レプリケーションの目的 高可用性 高いパフォーマンス 複製の一貫性がどのくらい保証されているかはシステムによる 一般的に、弱い保証であるほど同期コストが下がるのでパフォーマンスが高くなる ネットワークで接続された複数のマシンに同じデータのコピーを保持しておくこと
4. レプリケーションのアプローチ シングルリーダー（e.g. PostgreSQL、MySQL、MongoDB） マルチリーダー（e.g. OpenLDAP、Amazon Aurora、Apache CouchDB） リーダーレス（e.g. Amazon DynamoDB、Riak、Cassandra） 今回はリーダレスレプリケーションを紹介する 広く使われているアプローチは３つ
5. リーダーレスレプリケーション どのレプリカも直接クライアントからの書き込みを受け付ける 誰がレプリカに書き込むのかは実装によって異なる 例えば、 クライアントが複数のレプリカに直接書き込みを要求する コーディネータがクライアントに代わって複数のレプリカに書き込みを要求する リーダーが存在しない
6. DynamoDB概要 Amazon DynamoDB は、規模に関係なく数ミリ秒台のパフォーマンスを実現する、key-value およびドキュメントデータベースです。こ れはフルマネージド型でマルチリージョン、マルチアクティブで耐久性があるデータベースであり、セキュリティ、バックアップと復 元、インターネット規模のアプリケーション用のインメモリキャッシュが組み込まれています。 DynamoDBの詳細はDynamo: Amazon’s Highly Available Key-value Storeに書いてある リーダーレスレプリケーションを採用している最も有名なデータベースの１つ https://aws.amazon.com/jp/dynamodb/ より
7. DynamoDBを構成する技術 問題 技術 Partitioning Consistent Hashing High Availability for writes Vector clocks with reconciliation during reads Handling temporary failures Sloppy Quorum and hinted handoff Recovering from permanent failures Anti-entropy using Merkle trees Membership and failure detection Gossip-based membership protocol and failure detection このうち一部を紹介する
8. Consistent Hashing ハッシュ関数hを使ってキーを特定の範囲にマッピ ングする（x , x ...） ノードもマッピングする（s , s ...） 各ノードは、隣のノードまでの間にあるキーを管 理する ノードの追加削除をO(K/N + logN)で出来る あるキーxを管理しているノードをxのcoordinator と呼ぶ https://web.stanford.edu/class/cs168/l/l1.pdf より引用 0 1 0 1
9. Consistent Hashing（２） １つのノードが複数の範囲を管理する virtual nodes virtual nodesはノード数が多いほど、均等にマッピ ングされるはず ノードを均等にマッピングすることで、負荷を分散したい
10. DynamoDBにおけるレプリケーション coordinatorは自身が管理する範囲を後続のN − 1 ノードに複製する 実際には、物理ノードが重複しないように後続を 選択する 後続のノードがダウンしていた場合は、後述 https://dl.acm.org/doi/10.1145/1323293.1294281 より引用
11. DynamoDBの一貫性 モデル 保証しているか？ Strict consistency（厳密な一貫性） x Sequential consistency（逐次一貫性） x Causal consistency（因果一貫性） x Eventual consistency （結果整合性） o 結果整合性とは、複製に非常に長い時間がかからない場合、すべてのレプリカが最終的に一貫性を持つよう になることを保証する性質 他の性質と比較して弱い Data-centric consistency models（データ中心一貫性モデル）から見たDynamoDBが保証する性質
12. DynamoDBの一貫性（２） モデル 保証しているか？ Monotonic read consistency △ ※ Monotonic write consistency x Read-your-writes consistency △ ※ Writes-follows-reads consistency x ※　オプションで強い読み込み一貫性を指定できる https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadConsistency.html Client-centric consistency models（クライアント中心一貫性モデル）から見たDynamoDBが保証する性質
13. モノトニックな読み取り一貫性 Monotonic read consistencyを保証していないと一度読み取ったデータが削除されたように見えることがある Write X X exists? Yes X exists? No Sync X X exists? Yes 誰かが連続して行った複数の読み取りにおいて、時間が巻き戻らないことの保証
14. 自分が書いた内容の読み取り一貫性 Read-your-writes consistencyを保証していないと直前の書き込みが読み込めないことがある Write X X exists? No 誰かが行った書き込み直後の読み取りにおいて、直前の書き込みが反映されていることの保証
15. ノードがダウンしている状態での書き込み ３台ノードがあれば１つが一時的に使用出来なくなっていても書き込み・読み込みが出来る Write X X exists? No Yes Offline 過半数のノードに書き込みし、過半数のノードから読み取れば、必ず重複するので
16. 読み取り修復（Read repair） 古い値を返してきたレプリカに新しい値を書き戻す。頻繁に書き換わる値において有効 Write X X exists? No Yes Offline Write X 結果整合性を保証しているシステムでは、最終的に全てのレプリカにデータを複製する必要がある
17. 反エントロピー（Anti-entropy）処理 あまり読み取られない値においても有効 いつ複製されるか保証はない Merkle tree(Hash tree)と呼ばれるデータ構造を用いる ことでデータの差異を高速に探す レプリカ間のデータの差異を探し、修復するバックグラウンドプロセス
18. 読み書きのためのクオラム（Quorum） n台のノードで構成されている w個のノードで書き込みが成功したときに書き込みが成功したと判断する r個のノードで読み込みが成功したときに読み込みが成功したと判断する w + r > nである限りにおいて、少なくとも読み取り対象のr個のノードのうちの1つは最新 wとrの値に従って行う読み書きのことを、クオラム読み取りあるいは書き込みと呼ぶ w < nであれば、n − w台のノードが利用できなくても書き込み出来る r < nであれば、n − r台のノードが利用出来なくても読み込み出来る w, rはパラメータとして設定可能なシステムもある w + r > nを満たしていれば、最新の値を得られることが期待できる
19. いい加減なクオラムとヒント付きのハンドオフ ネットワーク障害によりあるキーを管理するn台のノードに接続できないとする 他の一部のノードに接続できるとき、とりあえずそこに書き込むことで可用性を高める これをいい加減なクオラム（Sloppy quorum）と呼ぶ 一時的に書き込んだデータは、本来管理するべきノードが復旧すると、そのノードに転送する。 これをヒント付きのハンドオフ（Hinted Handoff）と呼ぶ 転送が終わると一時的に書き込んだデータを削除する 大規模なクラスタではネットワーク障害が起きても一部のノードに接続出来るかもしれない
20. クオラムの一貫性の限界 いい加減なクオラムが使われていた場合、r個のノードとw個のノードに重複が存在する保証がなくなる 読み取りと書き込みが並行して行われると、一部のレプリカでのみ書き込みが反映されてしまい、読み 取られるのが新しい値か古い値かどちらになるのかわからない wノード未満でしか複製に成功しなかった書き込みが後で読み込まれてしまう可能性がある 強い保証が必要なのであればトランザクションや合意が必要になる r + w > nの場合でも、古い値が返されるようなエッジケースはあり得る