理解して拡げる分散システムの基礎知識

20200725の #JTF2020 セッションスライド。

（資料内で説明した資料へのリンク）
・昨年のJTF発表資料
https://speakerdeck.com/tzkoba/cloud-nativekai-fa-zhe-falsetamefalsedatabase-with-kubernetes
・「2020年のNewSQL」
https://qiita.com/tzkoba/items/5316c6eac66510233115
・「NewSQLのコンポーネント詳解」
https://qiita.com/tzkoba/items/3e875e5a6ccd99af332f
・Saga
https://www.infoq.com/jp/news/2018/03/data-consistency-microservices/
・「マイクロサービスとは分散システムである」
https://www.infoq.com/jp/news/2016/10/microservices-distributed-system/
・Atomic Visibility
https://speakerdeck.com/pbailis/scalable-atomic-visibility-with-ramp-transactions
・Spanner（Witness）
https://cloud.google.com/spanner/docs/replication?hl=ja#witness

Transcript

1. クラウドマイクロサービス時代の今こそ！ _ 理解して拡げる 分散システムの基礎知識 July Tech Festa 2020 , 7/25 @tzkb
2. 2 最近やっていること • PGConf.Asia 2019 “Building PostgreSQL as a Service with Kubernetes” • NewSQL関連のブログ投稿 “2020年現在のNewSQLについて” “NewSQLコンポーネント詳解” ＋ ＝∞
3. 3 1. 新たなムチャブリ 2. モノリスからマイクロサービスへ 3. それでも残る課題 4. 真にスケーラブルなDBを探して 5. まとめ アジェンダ
4. 4 新たなムチャブリ 1
5. 5 昨年のことです。 LB AP AP AP • 古きよきLB-AP-DBのWebシステムがありました。 • VMかもしれないし、 ベアメタルかも。 • 機器は老朽化、アーキ テークチャも陳腐化。 • ある日、 偉い人は言いました。 「これからはクラウド」 ＃jtf2019 の話
6. 6 Lift & Shift だ！ • 担当者は不眠不休でがんばりました。 • クラウド上へシステムを 移行。 • アプリケーションをコン テナ化、Kubernetesに デプロイ。 • データベースはManaged Serviceを使った。 良くありますよね？ (むしろ頑張ったほう） AP AP AP ＃jtf2019 の話
7. 7 Database with Kubernetesという選択肢 電源、ラック サーバ管理 OSインストール OSパッチ DBインストール DBパッチ バックアップ/リストア HA スケール アプリケーション Database w/ K8sクラスタ による管理 バージョン選択 任意のバージョンを選べる リソース上限 Nodeのキャパシティ次第 リソース下限 CPUはmill core単位で指定可 パラメータ 全て変更可能 Extension 全て導入可能 OSログイン 可能（任意のユーザ作成も可） ＃jtf2019 の話
8. 8 時はDX時代、 • 2020年の偉い人はこう言いました。 注：フィクションです。 「これからは、 マイクロサービスでDXだ。」 「クバ何とか使ってるから、 マイクロサービスできるな？」
9. 9 そしてマイクロサービスへ • 担当者は不眠不休でがんばりました（N回目）。 BFF 注文管理 商品 配送 顧客 参照系 Pod Pod Pod Pod Pod Pod
10. 10 これって、分散システムってやつですよね。  アーキテクチャの変更はとても大変。  モノリス内の同期通信 ⇒ サービス間の非同期通信  一つの巨大データベース ⇒ 小さな沢山のデータベース  上手くいっているときは良い。でも、障害時は大丈夫？  メインサイトだけ？DRサイトも必要と言われたら？  結局、何が問題なのか？？
11. 11 今日のゴール ～ 怖くない分散システム ～  “あなたがマイクロサービスをのぞくとき、 分散システムもまたあなたをのぞいているのだ。”  分散システムの大きな課題＝トランザクション  あなたのマイクロサービス、スケールしますか？  局所的な高負荷に対して拡張できますか？  DRまたは地理分散はできますか？
12. 12 モノリスからマイクロサービスへ 2
13. 13 Youは何しにマイクロサービスへ？ • 目的が間違ったマイクロサービス化は失敗する。 【 Devの視点から見た目的の例】 • コードベースに、適切なコントロールとアジリティを。 • 小さなデプロイ単位、迅速なリリース。 • サービス毎に技術を選択可、新規性への取り組み。 【 Opsの視点から見た目的の例】 • アーキテクチャに、適切な拡張性と可用性を。 • サービス単位で局所的に拡張可能。 • 障害は分離され、全体へ波及しない。
14. 14 マイクロサービスとは分散システムなのか。 • 「マイクロサービスとはすなわち分散システムである」 by Sander Hoogendoorn • 分散システムの4つのデザインゴール by Tanenbaum • Distribution transparency ⇒透過的に分散され、内部の障害は隠蔽される。 • Scalability (Size/Geographical/Administrative) ⇒量的・地理的な意味で拡張性を持つ • Support sharing resources • Openness
15. 15 そもそも、あなたのシステムはモノリスですか。 • モノリスではないが、完全にマイクロサービスでもないもの？ 共有データベース 顧客 Pod 注文管理 Pod 在庫 Pod 配送 Pod • 適切に分割された、 Cloud Nativeなアプリ ケーション。 • 非同期処理も併用し、 障害の波及範囲を限定。 • データベースは共有。 • 十分な可用性を持つが、 ≠マイクロサービス （※私個人の考えです。）
16. 16 マイクロサービスの大きな課題：分散トランザクション • マイクロサービスではDatabase per Serviceが原則。 顧客 注文管理 在庫 配送 • データベースを分割する と始まるのが、分散トラ ンザクションの戦い。 • 共有データベースではで きた、ACIDなトランザ クションは実現できない。 • ロールバックもDBには 任せられない。 Pod Pod Pod Pod
17. 17 どうマイクロサービス化するか？ BFF 注文管理 在庫 配送 顧客 参照系 Saga orchestrator • Saga(オーケストレータ)パターン、そしてKafkaを使ってみる。 • データベースは各サービス内に配置。 consumer consumer consumer Pod
18. 18 Sagaの概要① • サービス毎にローカルトランザクションを順次実行。 • ロールバックは補償トランザクションで行う。 注文管理 顧客 create Order 在庫 発送 reserve Credit update Inventory arrange Shipment complete Order cancel Credit adjust Inventory cansel Order
19. 19 Sagaの概要② • トランザクションを3種類に分けて、Go/No Goの境界を設ける。 ① Compensatable Transaction … ロールバックができる ② Pivot Transaction … ①と③の境界、超えたら進むのみ ③ Retriable Transaction … 成功するまでリトライ 注文管理 顧客 在庫 発送 arrange Shipment cancel Credit adjust Inventory cansel Order create Order reserve Credit update Inventory ①ロールバックが可能 ②Pivot ③リトライ
20. 20 Sagaに欠けているもの：Isolation • 「ローカルトランザクションの結果が、他サービスに 見えてしまうのでは？」 ⇒その通りです。 • 対策として、CQRS(Command and Query Responsibility Segregation )など。 注文管理 顧客 在庫 参照系 View更新 発送 Sagaの途中でデータが 見えてしまうと、 Isolationが崩れる。 Saga終了後に、一貫性のあるViewを非同期で更新する。 ReadをこちらのViewに行うことで、Isolationを担保。 ※但し、Eventual Consistency。
21. 21 Atomic Visibility という考え方 • “Scalable Atomic Visibility with RAMP Transactions(2016)” by P Bailis • 基本的な考え方は、トランザク ション(WRITE X,WRITE Y)の 途中の状態が見えないこと。 • 単一DB内のトランザクションで はロックで実現。 • 分散システムでは、ノード間の 通信遅延が発生するため、簡単 ではない。 https://speakerdeck.com/pbailis/scalable-atomic-visibility-with-ramp-transactions
22. 22 それでも残る課題 3
23. 23 あなたのマイクロサービス、本当にスケーラブルですか？ • 単一サービスとして十分な拡張性がありますか？ • 地理的に分散された環境へも拡張できますか？ • Distribution transparency ⇒透過的に分散システムされ、内部障害は隠蔽される。 • Scalability (Size/Geographical/Administrative) ⇒量的・地理的な意味で拡張性を持つ • Support sharing resources • Openness
24. 24 ボトルネックとなるのはデータベース BFF 注文管理 在庫 配送 顧客 参照系 Saga orchestrator • サービスが適切に分割され、分散トランザクションが実現されても、 データベースの拡張性には制約がある。 consumer consumer consumer Pod Size/Geopraphicalな Scalabilityが必要
25. 25 どう実現するか：量的な拡張性① • シンプルな実現方法はReplicationによるリード・レプリカ。 • 単一LeaderでWriteを全て受け付け、log shippingでデータ複製。 【メリット】 • 多くのDBで組込みで提供され、実績も 豊富な構成。 • read queryのオフロードが可能。 【デメリット】 • 非同期ではラグあり、同期では耐障害性↓ • write queryは全てPrimary(P)で捌く 必要があり、スケールできない。 （単一サービス内） WAL Write S P S Read
26. 26 どう実現するか：量的な拡張性② • 理想はMulti-Leaderで水平スケールが可能なデータベース。 （単一サービス内） Write Read 処理の 振分け・集約 【VitessによるSharding】 【Oracle RAC】 （単一サービス内） Write Read
27. 27 どう実現するか：地理的な拡張性① BFF 注文管理 在庫 • ステートレスなアプリケーションはメイン・DRサイト双方で 稼働させればよいが、データベースはレプリカが必要。 BFF 注文管理 在庫 メインサイト DRサイト 距離の壁
28. 28 実際、遠隔地へのレイテンシはどれぐらい？ 60-80ms 20-30ms 90-110ms • 東京-米国西海岸だと約150ms、 EU圏だと300ms • レイテンシが大きいほど、 レプリケーションのラグも大きく、 ハートビート等がタイムアウト するリスクも増大する。
29. 29 どう実現するか：地理的な拡張性② • ここでも商用製品は機能・実績が豊富。 • 近郊には同期レプリカ、更に複数のDRサイトへ非同期転送も可。 • Oracle Active Data Guardの例。 • Fast Syncの機能で、メモリ内のRedo を同期転送し、レイテンシ短縮。 • Far Syncの機能で、近郊サイトにRedo を同期転送、近郊‐DRサイトは非同期の 転送となり、レイテンシと可用性を向上。 ※近郊サイトはデータを保持しない。 同期転送 非同期転送 非同期転送
30. 30 真にスケーラブルなDBを探して 4
31. 31 量的・地理的どちらの拡張性も満たすデータベースは？ • Multi-Leader、同期レプリカ、距離の壁を超えられるDBが必要。 • 一つの答えはGoogle Cloud Spanner。 Witness リージョン Read-Write リージョン • 東京ー大阪で地理分散が可能な SQLデータベース。 • ソウルはWitnessリージョン。 (Writeのコミット、投票に参加) • 当然、ACIDトランザクションを サポート。
32. 32 • Spannerの論文を元に開発された、OSSの分散SQLデータベースは 下表のように既に市場に投入されている。 • SQLに限らなければ、CassandraやDynamoDBやCosmos DBも地理分散・高い拡張性等の 特徴を持つが、トランザクションがACIDとは言えない。 Spannerと類似の分散SQLデータベース 名称 開発元 提供形態 Cloud Spanner Google クラウド(managed)のみ Cockroach Labs オンプレ/独自managed等 Yugabyte オンプレ/独自managed等 PingCAP オンプレ/独自managed等
33. 33 Multi-Leaderとはどういうことか？ Follower2 Leader1 Follower Leader2 Follower1 Follower Follower2 Follower1 Leader Follower3 Follower3 Leader3 • etcdなどはシングル Raftで構成される分散 KVS。Leaderも単一 になる。 • YugaButeDBなどは マルチRaftで、複数の Leaderが存在。 これにより、Read- Write双方の分散を実 現している。 • データのレプリケーションにPaxosやRaft が使われる。 • Sharding＋マルチRaftで、Multi-Leaderの構成を実現している。
34. 34 Follower3 同期レプリカは実現可能か？ Write Read • Raft(合意プロトコル)を用いて、同期レプリカのような耐障害性と、 非同期に近いレイテンシを同時に実現する。 Follower2 Leader1 Leader3 Follower2 Follower1 Follower3 Leader2 Follower1 【Write Path 】 ①WriteはLeaderに送られ、Leaderのlogに 更新内容が記録される。 ②全てのFollowerにlogを複製。 ③Followerの過半数から複製済の応答が返る。 ④Leaderは更新をコミット。 【Read Path 】 ①Readも原則はLeaderへ送られる。 ②LeaderはFollowerへハートビートを送信し、 過半数からの応答を待つ。 ③自身がLeaderあることが確認できたので、 Read結果を返す。
35. 35 Raftの概要 • Raft自体はsimple & easyを目指した合意プロトコル。 • 主な機能は2つ。 【 Leaderの選出 】 • ある期間に、クラスタに1人だけのLeaderがいることを保証。 • 一定期間、ハートビートが送られて来なければLeader選出を開始する。 • 過半数の投票が得られれば、Follower(Candidate)がLeaderになることが出来る。 • ネットワークが分断されても、複数のLeaderが発生しないことがポイント。 【 logの複製 】 • log≒コマンドと考えて良い。コマンドの実行順序を合意する仕組み。 • 全てのノードで同じ順序で同じ処理が行われれば、データは同一になるという考え方。 • 障害発生時も合意された結果は戻ったり、覆ることがないのがポイント。 ※詳しくは「NewSQLコンポーネント詳解」で
36. 36 こんな構成はどうだろう？ Raft Leader サイト • 量的・地理的双方の拡張性を満たす、マイクロサービスのバック エンドとして適切な、分散データベースの検証を行っていく。 Followerサイト Followerサイト • 多くの分散SQLデータベースでは、 Leaderを1サイトに配置する設定が存在。 • Raftによる合意は近郊サイトのFollower で完了するため、レイテンシも短縮可。 • 大きなポイントとして、合意ベースの システムには3つ以上のサイトが必要。 • この図では関東近郊が全面障害の場合、 関西サイト単独では稼働できない。 （合意に達しないため）
37. 37 まとめ 5
38. 38 （再掲）今日のゴール ～ 怖くない分散システム ～ 分散システム(≒マイクロサービス)は、 データストアの拡張性も理解して適切な設計を！  “あなたがマイクロサービスをのぞくとき、 分散システムもまたあなたをのぞいているのだ。”  分散システムの大きな課題＝トランザクション  あなたのマイクロサービス、スケールしますか？  局所的な高負荷に対して拡張できますか？  DRまたは地理分散はできますか？
39. 39 Questions? @tzkb @tzkoba