AWSのRedis互換KVS MemoryDBの論文を読んでみた 第17回 分散システム集会 on VRChat @bootjp / ぶーと 

本日の発表の流れ ● 自己紹介 ● MemoryDBとは ● なぜAWSはMemoryDBを作ったのか ○ Redisが抱える課題と限定された用途 ● MemoryDBの仕組み ○ Auroraのようなスタックの分割 ○ Redisの非決定論的な操作に対するアプローチ ○ トランザクションストレージを用いたリーダー選出 ○ オフボックス・スナップショットシステム ● 評価手法 ● まとめと議論 

自己紹介 HN: ぶーと 分散システム集会の主催の一人。 RaftやKVS、TiKVが好きです。 仕事では、マイクロサービス／マルチプロダク トに向けた分散基盤の設計や実装をしていま す。 前の仕事ではRaftベースの分散ストレージを 作っていました。 @bootjp 

本日の発表の流れ ● 自己紹介 ● MemoryDBとは ● なぜAWSはMemoryDBを作ったのか ○ Redisが抱える課題と限定された用途 ● MemoryDBの仕組み ○ Auroraのようなスタックの分割 ○ Redisの非決定論的な操作に対するアプローチ ○ トランザクションストレージを用いた一貫性の維持 ○ オフボックス・スナップショットシステム ● 評価手法 ● まとめと議論 

MemoryDBとは ● Amazon Web Serviceが作成したRedis互換のインメモリデータベース（KVS） ● 低レイテンシーかつ高可用性を実現しつつ耐久性と強い一貫性を実現 ○ 今までのRedisではデータの耐久性（永続化）に問題がありそれを改善した（後述） ○ ● 

本日の発表の流れ ● 自己紹介 ● MemoryDBとは ● なぜAWSはMemoryDBを作ったのか ○ Redisが抱える課題と限定された用途 ● MemoryDBの仕組み ○ Auroraのようなスタックの分割 ○ Redisの非決定論的な操作に対するアプローチ ○ トランザクションストレージを用いたリーダー選出 ○ オフボックス・スナップショットシステム ● 評価手法 ● まとめと議論 

なぜAWSはMemoryDBを作ったのか ● Redisではデータの耐久性に問題があった ○ Redisはプライマリからのレプリケーション時に分散合意を用いない ○ フェイルオーバー時にプライマリーに選出されるノードがすべてのデータがある保証がない ○ Redis利用時は耐久性のあるデータベースと組み合わせる必要がある ■ 一時データなどのキャッシュに限定される ● キャッシュでもかなり実装が複雑 ○ アプリケーションがDBからの読み取り後セット ○ DynamoDB Streamのようなパイプラインの構築 

本日の発表の流れ ● 自己紹介 ● MemoryDBとは ● なぜAWSはMemoryDBを作ったのか ○ Redisが抱える課題と限定された用途 ● MemoryDBの仕組み ○ Auroraのようなスタックの分割 ○ Redisの非決定論的な操作に対するアプローチ ○ トランザクションストレージを用いたリーダー選出 ○ オフボックス・スナップショットシステム ● 評価手法 ● まとめと議論 

MemoryDBの仕組み ● MemoryDBの仕組み ○ Auroraのようなスタックの分割 ○ Redisの非決定論的な操作に対するアプローチ ○ トランザクションストレージを用いた一貫性の維持 ○ オフボックス・スナップショットシステム 

本日の発表の流れ ● 自己紹介 ● MemoryDBとは ● なぜAWSはMemoryDBを作ったのか ○ Redisが抱える課題と限定された用途 ● MemoryDBの仕組み ○ Auroraのようなスタックの分割 ○ Redisの非決定論的な操作に対するアプローチ ○ トランザクションストレージを用いたリーダー選出 ○ オフボックス・スナップショットシステム ● 評価手法 ● まとめと議論 

MemoryDBの仕組み > Auroraのようなスタックの分割1 ● インメモリ実行エンジンと耐久性レイヤーの分離している ○ 耐久性レイヤー: マルチAZトランザクションログサービス ● MemoryDBではAuroraのようにトランザクションログを管理するコンポーネントなどを スタックごとに複数のレイヤーに分割している ● RedisのOSS版のソースコードをインメモリ実行とストレージエンジンとしてのみ使って いる 

MemoryDBの仕組み > Auroraのようなスタックの分割2 ● RedisのレプリケーションストリームをマルチAZのトランザクションログストレージにリダ イレクトすることで耐久性を確保している ○ 書き込みには複数AZに書き込みが行われるまでブロックされる ■ トランザクションログストレージに書き込みができなかった場合はエラーが返される ● ネットワーク分断など ● 変更を伴う命令はトラッカーにkeyが保存されたうえで、トランザクションログストレージ にコミットされるまでブロックされる ● 変更中であっても非変化系の操作はブロックされない ○ しかし、非変化系の操作であってもトラッキングされている（変更中の）keyを含む場合はトランザクション ログストレージがあるまでブロックされる 

MemoryDBの仕組み > Auroraのようなスタックの分割3 ● RedisのレプリケーションストリームをマルチAZのトランザクションログストレージにリダ イレクトすることで耐久性を確保している ○ 書き込みには複数AZに書き込みが行われるまでブロックされる ■ トランザクションログストレージに書き込みができなかった場合はエラーが返される ● ネットワーク分断など ● 変更を伴う命令はトラッカーにkeyが保存されたうえで、トランザクションログストレージ にコミットされるまでブロックされる ● 変更中であっても非変化系の操作はブロックされない ○ しかし、非変化系の操作であってもトラッキングされている（変更中の）keyを含む場合はトランザクション ログストレージがあるまでブロックされる 

本日の発表の流れ ● 自己紹介 ● MemoryDBとは ● なぜAWSはMemoryDBを作ったのか ○ Redisが抱える課題と限定された用途 ● MemoryDBの仕組み ○ Auroraのようなスタックの分割 ○ Redisの非決定論的な操作に対するアプローチ ○ トランザクションストレージを用いたリーダー選出 ○ オフボックス・スナップショットシステム ● 評価手法 ● まとめと議論 

MemoryDBの仕組み > Redisの非決定論的な操作に対するアプローチ ● Redisはランダムな要素を削除するコマンドがある ○ SPOP: 集合の要素からランダムに削除する ● RedisにはLua Scriptの実行機能がある ○ Lua Scriptは実行後に操作が確定 ● 非決定論的な操作をトランザクションのログに保存するには決定論的な操作として扱 う必要がある ● MemoryDBではWAL (Write-Ahead Log）ではなくWBL（Write-Behind Log）を採用し た ● これによりRedisのエンジンに操作を適用した結果を決定論的なトランザクションログと して出力することが可能になった 

本日の発表の流れ ● 自己紹介 ● MemoryDBとは ● なぜAWSはMemoryDBを作ったのか ○ Redisが抱える課題と限定された用途 ● MemoryDBの仕組み ○ Auroraのようなスタックの分割 ○ Redisの非決定論的な操作に対するアプローチ ○ トランザクションストレージを用いたリーダー選出 ○ オフボックス・スナップショットシステム ● 評価手法 ● まとめと議論 

MemoryDBの仕組み > トランザクションストレージを用いたリーダー選出1 ● トランザクションログシステム上に構成されたリーダー選出とリースシステムによる故 障時の強い一貫性の保証 ● リーダーの獲得にはトランザクションログストレージに特定のログエントリを書き込む必 要がある ● リーダーの獲得のエントリに書き込みを行うには、トランザクションログストレージにあ るデータをすべて持っている必要がある ○ この制約を課すことで十分なデータを持たないノードがリーダーに昇格することを防いでいる ○ 仮にネットワーク分断から復帰したノードがリーダーになろうとしても失敗する 

MemoryDBの仕組み > トランザクションストレージを用いたリーダー選出2 ● リーダーを持つプライマリーノードはトランザクションログストレージにリースに関する書 き込みを行う ● リースに関する書き込みを観測したレプリカノードはその時間を超えるバックオフ時間 を持ち、その間はリーダー選出を行わない ● バックオフ期間を超えてもリースに関する書き込みが観測されなければ、リーダー選 出を開始する 

本日の発表の流れ ● 自己紹介 ● MemoryDBとは ● なぜAWSはMemoryDBを作ったのか ○ Redisが抱える課題と限定された用途 ● MemoryDBの仕組み ○ Auroraのようなスタックの分割 ○ Redisの非決定論的な操作に対するアプローチ ○ トランザクションストレージを用いたリーダー選出 ○ オフボックス・スナップショットシステム ● 評価手法 ● まとめと議論 

MemoryDBの仕組み > オフボックス・スナップショットシステム ● RedisはforkによるCoWを用いつつ、別のプロセスでスナップショットを作成する ● しかし、これは顧客にとって次のデメリットがある ○ fork時にはメモリ使用量が増大し、通常の2倍のメモリ容量が必要になる ○ スナップショット作成中はIO性能が低下するため、レイテンシーが悪化する ○ IO以外にもスナップショット作成にはCPUリソースを使用する ● MemoryDBでは顧客に見えない一時的なクラスタを追加しスナップショットを作成する ことで解決 ○ スナップショットはS3に保存される ● ノードの追加時にはS3のスナップショットとトランザクションログストレージにあるスナッ プショットからの差分を用いることで高速にノード追加される 

MemoryDBの仕組み > オフボックス・スナップショットシステム ● RedisはforkによるCoWを用いつつ、別のプロセスでスナップショットを作成する ● しかし、これは顧客にとって次のデメリットがある ○ fork時にはメモリ使用量が増大し、通常の2倍のメモリ容量が必要になる ○ スナップショット作成中はIO性能が低下するため、レイテンシーが悪化する ○ IO以外にもスナップショット作成にはCPUリソースを使用する ● MemoryDBでは顧客に見えない一時的なクラスタを追加しスナップショットを作成する ことで解決 ○ スナップショットはS3に保存される ● ノードの追加時にはS3のスナップショットとトランザクションログストレージにあるスナッ プショットからの差分を用いることで高速にノード追加される 

本日の発表の流れ ● 自己紹介 ● MemoryDBとは ● なぜAWSはMemoryDBを作ったのか ○ Redisが抱える課題と限定された用途 ● MemoryDBの仕組み ○ Auroraのようなスタックの分割 ○ Redisの非決定論的な操作に対するアプローチ ○ トランザクションストレージを用いたリーダー選出 ○ オフボックス・スナップショットシステム ● 評価手法 ● まとめと議論 

評価手法 > 正確性と一貫性の検証 ● 形式手法（TLA+、P言語）によるモデル検証 ● 線形化チェッカー（porcupine）を用いた並行操作の正当性検証 

評価手法 > パフォーマンス ● redis-benchmarkを使用 ○ 各redis‑benchmarkプロセスはシンプルなGET/SET操作においてパイプライニングを使用せず、各クライ アント接続が直列にコマンド を発行する設定とした ● 読み取り専用・混合ワークロードで中央値がサブミリ秒、テールがシングルミリ秒台を 実現 ● 書き込み専用では耐久性確保のため若干のレイテンシ増加があるが、高耐久性・高 可用性を確認 ● スナップショット取得が性能に影響を与えないことを確認 

本日の発表の流れ ● 自己紹介 ● MemoryDBとは ● なぜAWSはMemoryDBを作ったのか ○ Redisが抱える課題と限定された用途 ● MemoryDBの仕組み ○ Auroraのようなスタックの分割 ○ Redisの非決定論的な操作に対するアプローチ ○ トランザクションストレージを用いたリーダー選出 ○ オフボックス・スナップショットシステム ● 評価手法 ● まとめと議論 

まとめ ● AWSは耐久性のあるRedis互換データベースが必要でMemoryDBを設計した ● Redis OSS版をインメモリ実行とストレージエンジンとして使っている ○ MemoryDBはRedisのエンジンを通した後のWBLをトランザクションログストレージに書く ○ 書き込み完了までクライアントにレスポンスは返されない ○ MemoryDBでは変更中のキーはトラッカーに保持される ○ 読み込みはブロックされない ■ しかし、変更中のキーの読み取りはトランザクションログストレージの応答を待つ ● スナップショットの作成はレイテンシーへの影響があるため、顧客から隠ぺいされた環 境で作成 ● リーダー選出にすべてのログがあることとトランザクションログストレージを用いて一貫 性を維持している 

議論 ● 評価手法のパイプライニングなしはMemoryDBにとって有利な条件になっていない か？