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

Cd891a89dfec6ca7bd278b5f5bd87c90?s=47 tzkoba
July 25, 2020

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

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

Cd891a89dfec6ca7bd278b5f5bd87c90?s=128

tzkoba

July 25, 2020
Tweet

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