データベース 大規模,分散型データ管理のシステムアーキテクチャ前提
前段
リアルタイム性が求められて、厳密性が求められる場合はどうするんだろう。例えば、グローバルの決済企業(Visa, Materとか), ECプラットフォーム(shopifyとか, eBay)ってどんな構成にしているんだろうか。以下をヒントに調べてみたいと思う。
参考記事
大規模な決済システムを構築する際に学んだ分散型アーキテクチャの考え方 – 前編　https://postd.cc/distributed-architecture-concepts-i-have-learned-while-building-payments-systems/
規模対応へのインフラ戦略は、垂直スケーリング OR 水平スケーリング
新たに構築したシステムを使っている事業が成長した場合、システムにかかる負荷はどんどん増えていくことになります。そしてある時期からは、既存のシステム基盤ではその負荷をサポートできなくなり、許容量を拡張する必要性が生じることになるはずです。その際、最も一般的な拡張戦略として考えられるのが、水平スケーリングと垂直スケーリングです。
水平スケーリングとは、システムにマシン（またはノード）を追加して容量を増やすこと。クラスタに（仮想）マシンを追加し、分散型システムの拡張には最も一般的とされています。
垂直スケーリングは、基本的には”より強力な大型のマシン（より多くのコア、より多くのプロセッサ、より多くのメモリを備えた（仮想）マシン）を購入する”というもの。分散型システムの場合、水平スケーリングに比べると垂直スケーリングはコストがかかるため、通常はあまり行われません。( https://postd.cc/distributed-architecture-concepts-i-have-learned-while-building-payments-systems/ )
水平スケーリングがコストや継続的に増加するロード量を考えるとbetter。
https://gyazo.com/c88692c318d25b4502fa25e91e57f29e
注釈：（横軸）余分に必要となる容量
（縦軸）容量を確保するユニットごとの価格
（上）垂直スケーラビリティだと、あるポイントを超えてからコストが急に上がり始める
（左下）水平スケーラビリティだと、イニシャルコストが高くなりがち
（右下）水平スケーラビリティだと、あるポイントを超えてから非常に効率的になる
水平スケールはある閾値を境にコストがずっと低くなります ( https://postd.cc/a-thorough-introduction-to-distributed-systems-3/ )
一貫性と可用性のトレードオフは、落としどこを探ること
水平スケーリング, 分散コンピュータのデータ管理の大前提としてCAP定理がある。
分散コンピュータシステムのマシン間の情報複製に関する定理
分散システムはこの3つ(一貫性/Consistency, 可用性/Availability, 分断耐性/Partition-tolerance)の保証のうち、同時に2つの保証を満たすことはできるが、同時に全てを満たすことはできない ( https://ja.wikipedia.org/wiki/CAP定理 )
https://gyazo.com/35867871d4e697bf21e1ebaf299f114f
(to read)Visual Guide to NoSQL Systems https://blog.nahurst.com/visual-guide-to-nosql-systems
https://gyazo.com/1e74ed35a88234759f2977dc65fbef18
(to read)An Illustrated Proof of the CAP Theorem https://mwhittaker.github.io/blog/an_illustrated_proof_of_the_cap_theorem/
3つをバランスを取ることが大事である。2つを選び1つを捨てる、ということではない。
3つの属性は満たす/満たせないのふたつの選択肢しかないのではなく、度合いがあります。可用性は明らかに0%から100%まで度合いがありますが、一貫性にも多様なレベルがあります。分割耐性にも同様です。システムに分割があるかどうかについての意見の相違も含んだ度合いがあります。
(to read)12年後のCAP定理: "法則"はどのように変わったか https://www.infoq.com/jp/articles/cap-twelve-years-later-how-the-rules-have-changed/ , https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed/
例えば、一貫性の「強さ」は分散システムにおいてはさほど重視しない考えもある。
AmazonのCTOであるWerner Vogelsは「並行処理における書き込み・読み込みパフォーマンスの担保」と「データロックによるノードの可用性の低下の抑止」の２つの観点から、データの一貫性はスケーラブルな大規模システムにおいてはさほど重視される必要はないと考えている ( https://www.allthingsdistributed.com/2008/12/eventually_consistent.html )
参考
(to read)Consistency in Distributed Systems　https://www.cl.cam.ac.uk/teaching/0910/ConcDistS/11a-cons-tx.pdf
整合性, 強い弱い整合性, 結果整合性の解説
各ノードに確実に同じ情報を持たせるには、互いに通信し合って同期し続けなければなりません。しかし、相互間の通信に失敗したり、メッセージを消失したりしてノードの一部が使用不可になる可能性がある。基本的には、求められる一貫性が弱いほど、システムは速くなりますが、直近のデータセットを返す確率が下がる。( https://postd.cc/distributed-architecture-concepts-i-have-learned-while-building-payments-systems/ )
一貫性には種類, 分類があり、グラデーションとして考えたほうが適切な評価ができる
強い一貫性と結果整合性
（良い記事）結果整合性について　https://izumisy.work/entry/2018/06/11/224719
強整合性 の場合、データの更新の際にデータベースをロックすることによってデータの一貫性（Consistency）を担保するが、ロックされる期間が長いほどその間のデータベース・アクセスがブロックされ、可用性（Availability）を犠牲にすることになる。
結果整合性 はデータの更新でデータベースがロックされることはないため、可用性とスケーラビリティを維持することができる。その代わりノード間でのデータの一貫性はデータ複製にかかる時間に依存することになるため、必ずしも担保されない。
結果整合性 は「分散データベースの文脈で使われることが多く、データの更新の一貫性を即時担保するものではなく、更新後に一定時間経過していれば正しく更新データを取得できるという整合性の考え方」( https://shinkufencer.hateblo.jp/entry/2018/12/30/233000 )
table:強整合性と結果整合性の違い
強整合性 結果整合性
データのロック あり なし
スケーラビリティ 低い 高い
一貫性 担保される すぐには担保されない
(to read)Eventual vs Strong Consistency in Distributed Databases　https://hackernoon.com/eventual-vs-strong-consistency-in-distributed-databases-282fdad37cf7
強い整合性, 結果整合性の比較
--.icon
参考記事
大規模な決済システムを構築する際に学んだ分散型アーキテクチャの考え方 – 後編　https://postd.cc/distributed-architecture-concepts-i-have-learned-while-building-payments-systems-2/
分散型システム徹底入門 – Part 1. https://postd.cc/a-thorough-introduction-to-distributed-systems-3/
分散型システム徹底入門 – Part 2. https://postd.cc/a-thorough-introduction-to-distributed-systems-2/
分散型システム徹底入門 Part 3. https://postd.cc/a-thorough-introduction-to-distributed-systems/
じゃあ実際にシステムはどのように構成, 構築されるのか？
分散型システムのノードは演算し、データを保存し、互いにメッセージを送信し合います。メッセージ送信の重要な指標は、これらのメッセージがどれだけ確実に届くか
分散型システムにおける通信は、RabbitMQ、Kafkaなどの分散型メッセージングサービスを用いることがほとんど ( https://postd.cc/distributed-architecture-concepts-i-have-learned-while-building-payments-systems-2/ )
(wanna read)Persistence vs. Durability in Messaging. Do you know the difference? https://developers.redhat.com/blog/2016/08/10/persistence-vs-durability-in-messaging/
メッセージの永続性と持続性が非常に重要
メッセージの永続性とは、メッセージを処理しているノードで何らかの問題が起こった時、その問題の解決後に処理されるよう、メッセージはそこに残ること。消失しないこと。
メッセージの持続性はメッセージ送信時にキュー（またはノード）がオフライン状態だったとしても、オンライン状態に戻り次第メッセージを受信します。処理がアクティブであり続けること。( https://postd.cc/distributed-architecture-concepts-i-have-learned-while-building-payments-systems-2/ )
それでも消失したりシステム間で不整合が発生するから冪等性が重要
分散型システムでは、途中で接続が切れたり、リクエストがタイムアウトになったりして挙動がおかしくなることがあります。クライアント側はそのようなリクエストをよく再試行します。冪等性を備えたシステムでは、特定のリクエストが何度実行されたとしても、そのリクエストに対する実際の実行は必ず1度限りです。
冪等性を持たせる設計には、分散型システムにある種の分散型ロッキングの戦略が求められます。楽観的なロックインの場所を設けて冪等性を実装し、同時更新を防ぐとします。楽観的なロックを備えるには、強い整合性を持つシステムが必須です。ヴァージョニングを使い、操作時に別の操作が開始されているかどうかをチェックできるようにする( https://postd.cc/distributed-architecture-concepts-i-have-learned-while-building-payments-systems-2/ )
Shard https://en.wikipedia.org/wiki/Shard_(database_architecture)
分散型システムでは、ノードひとつで格納できるデータより、ずっと多くのデータを格納しなくてはなりません。一般的な方法は、シャーディングを使うやり方です。データを、パーティション割り当てを決めるある種のハッシュを使って、水平に分割します。多くの分散型データベースが内部に実装している( https://postd.cc/distributed-architecture-concepts-i-have-learned-while-building-payments-systems-2/ )
Quorum https://ja.wikipedia.org/wiki/Quorum
多くの分散型システムは、データや演算を複数のノードにコピーさせています。オペレーションが一貫した方法で実行されるようにするために、このうち一定数のノードで同じ結果が返されなければ操作が成功しない、という投票ベースのアプローチ( https://postd.cc/distributed-architecture-concepts-i-have-learned-while-building-payments-systems-2/ )
アクターモデル https://ja.wikipedia.org/wiki/アクターモデル
The actor model in 10 minutes (https://www.brianstorti.com/the-actor-model/)
リアクティブアーキテクチャ https://qiita.com/crossroad0201/items/7c8892c459ecef39ccef
補足
データベース 大規模,分散型データ管理のシステムアーキテクチャ実践編
#Database