クライアント中心一貫性について

これはSupership株式会社の 「データソリューションスタジオ 開発2グループ」における社内勉強会の発表資料を外部公開向けに再編したものになります．

アジェンダ

・データの一貫性について
・なぜ一貫性を考える必要があるのか
・よく使われる代表的な一貫性モデルの例
　・データ中心一貫性
　・クライアント中心一貫性
・クライアント中心一貫性とは？
・どのようなところで利用できるのか？
・どのように実装するのか？
・参考論文

データの一貫性について

データの一貫性を考えたことありますか？

何気なく使っているAWS S3やGoogle Cloud Storage，Redisやmemcachedのストレージに書き込んだデータが必ずすぐに読めると思っていませんか？

実際には書いたデータがすぐに読めることを保証している一貫性は少なくユースケースに応じて使い分ける必要があります．

なぜ一貫性を考える必要があるのか

■ パフォーマンスのため

Consistency Tradeoffs in Modern Distributed Database System Design: CAP is Only Part of the Story では データの一貫性とパフォーマンス（スループットやレイテンシ・IOPS）はトレードオフの関係にあるとしている

つまりパフォーマンスを求めるためにアプリケーションにマッチしたトレードオフを適切に選択することが非常に重要であるといえる

例えば…一般的なwebサービスの殆どは強い一貫性を要求せず結果整合性で十分であることが多い

言い換えると，要件に対してより最適な一貫性を採用することでよりパフォーマンスを出すことができる

⇢つまり最適なパフォーマンスを得るために一貫性について知る必要がある

■ 複雑化するシステムアーキテクチャの適切な設計や運用のため

昨今のシステムのほとんどがネットワーク越しに協調動作することによって成立している「分散システム」である

この分散システムでは複数の状態が個々のノードに存在することがあり，これを適切に設計・運用する必要がある

⇢つまりデータの一貫性について考えることが避けられない

よく使われる代表的な一貫性モデル

データ中心一貫性モデル

・「データ中心一貫性モデル」は一貫性モデルの1つ
・一貫性といった場合はほとんどのケースでデータ中心の一貫性を指すことが多い
・論文 Distributed systems では「整合性モデルをソフトウェアとメモリ実装間の契約」としている
・一貫性をデータごとに考える

データ中心一貫性モデルの一貫性の例

厳密な直列化可能性 - strict serializable

■特徴
・不整合が許されない決済などに使われることが多い
・データストアの操作が実時間での操作と一致する

■メリット
・直列実行で実行順序が保証されているので直感的であり意図した結果が得やすい
・直前に書き込みをした内容が直後に読むことができる

■デメリット
・直列実行のためパフォーマンスはでない

結果整合性 - eventual consistency

■特徴
・DNSや多くのレプリケーション構成のKVSやRDBで採用されている
・1つのデータに対して同時更新がない状況が想定されている
・時間経過で最終的に書き込み内容が伝播し一貫性を持つようになる

■メリット
・常に最新の値を返す必要がなく，複製データのキャッシュからの応答が可能なため高速化が可能である
・システムアーキテクチャを疎結合にすることが容易になる

■デメリット
・データが一時的にロールバックしたように見えることがある
・データの一貫性の扱いが複雑である

クライアント中心一貫性とはなにか？

・「クライアント中心一貫性モデル」は一貫性モデルの1つ
・Client Centric Consistency と言われるものである
・クライアント（≒ユーザー）から観測した際の一貫性のモデル
・実時間でデータを見たときには一貫性が保たれていないが，クライアントには一貫性がある振る舞いをするモデル
・1つのデータの同時更新は想定されていない
・ユーザAとBがいたとき互いに，データXで同一の値が見えることは保証していないが，ユーザAのセッションではデータXに変更を加えてもロールバックをしたりせずに一貫したデータが提供される

クライアント中心一貫性モデルの一貫性の例

Monotonic read consistency

論文 Distributed systems では「プロセスがデータxを読み取る場合、そのプロセスによるxの連続読み取り操作は、常に同じ値またはより新しい値を返す」とされている
言い換えるとプロセス自身が読み取った値より古い値が読み出されることがない
ただし，いつ新しいデータになるかは定義されていない

Read-your-writes consistency
論文 Distributed systems では「データ項目Xのプロセスによって書き込まれた値は、データ項目Xの同じプロセスによって実行される連続読み取り操作で常に使用可能になる」とされている
言い換えると，プロセス自身が書き込んだ値は常に読める
ただし，いつ新しいデータになるかは定義されていない

どのようなところで利用できるのか？

■クライアント（≒ユーザ）ごとに異なるデータを用いるとき
・通知の既読管理を行うシステム

■クライアント間で実時間で同一の値が表示されなくとも大きな影響が無いシステム
・ブログパーツのアクセスカウンター
・SNSのLIKE数

どのように実装するのか？

・ロードバランサでスティッキーセッションを用いる
　・スティッキーセッションはクライアントを特定のノードに固定してロードバランスをを行う機能
・この状態でAppと同一ノード，もしくはApp自体にキャッシュ機構があってもユーザからは一貫性が保証される

実装方法の詳細について

書き込み可能なクライアント中心一貫性を用いた分散KVSを実装し評価を行った「パーソナライズされたコンテンツ配信のための低遅延分散KVSの構築」という査読なしの論文を情報処理学会の第82回全国大会で発表した

論文公開時にリンクを追加予定

参考論文

[1] D. Abadi, "Consistency Tradeoffs in Modern Distributed Database System Design: CAP is Only Part of the Story," in Computer, vol. 45, no. 2, pp. 37-42, Feb. 2012.
・いわゆるCAPの定理
[2] Tanenbaum, Andrew; Maarten Van Steen (2007). "Distributed systems". Pearson Prentice Hall.
・分散システムの論文
[3] Yuqing Zhu and Jianmin Wang. Client-centric consis-tency formalization and verification for system withlarge-scale distributed data storage.Future Genera-tion Computer Systems, Vol. 26, pp. 1180–1188, 2010.
・クライアント中心一貫性に関する論文