Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

tzkoba

July 25, 2020
Tweet

More Decks by tzkoba

Other Decks in Technology

Transcript

  1. 2 最近やっていること • PGConf.Asia 2019 “Building PostgreSQL as a Service

    with Kubernetes” • NewSQL関連のブログ投稿 “2020年現在のNewSQLについて” “NewSQLコンポーネント詳解” + =∞
  2. 5 昨年のことです。 LB AP AP AP • 古きよきLB-AP-DBのWebシステムがありました。 • VMかもしれないし、

    ベアメタルかも。 • 機器は老朽化、アーキ テークチャも陳腐化。 • ある日、 偉い人は言いました。 「これからはクラウド」 #jtf2019 の話
  3. 6 Lift & Shift だ! • 担当者は不眠不休でがんばりました。 • クラウド上へシステムを 移行。

    • アプリケーションをコン テナ化、Kubernetesに デプロイ。 • データベースはManaged Serviceを使った。 良くありますよね? (むしろ頑張ったほう) AP AP AP #jtf2019 の話
  4. 7 Database with Kubernetesという選択肢 電源、ラック サーバ管理 OSインストール OSパッチ DBインストール DBパッチ

    バックアップ/リストア HA スケール アプリケーション Database w/ K8sクラスタ による管理 バージョン選択 任意のバージョンを選べる リソース上限 Nodeのキャパシティ次第 リソース下限 CPUはmill core単位で指定可 パラメータ 全て変更可能 Extension 全て導入可能 OSログイン 可能(任意のユーザ作成も可) #jtf2019 の話
  5. 10 これって、分散システムってやつですよね。  アーキテクチャの変更はとても大変。  モノリス内の同期通信 ⇒ サービス間の非同期通信  一つの巨大データベース

    ⇒ 小さな沢山のデータベース  上手くいっているときは良い。でも、障害時は大丈夫?  メインサイトだけ?DRサイトも必要と言われたら?  結局、何が問題なのか??
  6. 11 今日のゴール ~ 怖くない分散システム ~  “あなたがマイクロサービスをのぞくとき、 分散システムもまたあなたをのぞいているのだ。”  分散システムの大きな課題=トランザクション

     あなたのマイクロサービス、スケールしますか?  局所的な高負荷に対して拡張できますか?  DRまたは地理分散はできますか?
  7. 13 Youは何しにマイクロサービスへ? • 目的が間違ったマイクロサービス化は失敗する。 【 Devの視点から見た目的の例】 • コードベースに、適切なコントロールとアジリティを。 • 小さなデプロイ単位、迅速なリリース。

    • サービス毎に技術を選択可、新規性への取り組み。 【 Opsの視点から見た目的の例】 • アーキテクチャに、適切な拡張性と可用性を。 • サービス単位で局所的に拡張可能。 • 障害は分離され、全体へ波及しない。
  8. 14 マイクロサービスとは分散システムなのか。 • 「マイクロサービスとはすなわち分散システムである」 by Sander Hoogendoorn • 分散システムの4つのデザインゴール by

    Tanenbaum • Distribution transparency ⇒透過的に分散され、内部の障害は隠蔽される。 • Scalability (Size/Geographical/Administrative) ⇒量的・地理的な意味で拡張性を持つ • Support sharing resources • Openness
  9. 15 そもそも、あなたのシステムはモノリスですか。 • モノリスではないが、完全にマイクロサービスでもないもの? 共有データベース 顧客 Pod 注文管理 Pod 在庫

    Pod 配送 Pod • 適切に分割された、 Cloud Nativeなアプリ ケーション。 • 非同期処理も併用し、 障害の波及範囲を限定。 • データベースは共有。 • 十分な可用性を持つが、 ≠マイクロサービス (※私個人の考えです。)
  10. 16 マイクロサービスの大きな課題:分散トランザクション • マイクロサービスではDatabase per Serviceが原則。 顧客 注文管理 在庫 配送

    • データベースを分割する と始まるのが、分散トラ ンザクションの戦い。 • 共有データベースではで きた、ACIDなトランザ クションは実現できない。 • ロールバックもDBには 任せられない。 Pod Pod Pod Pod
  11. 17 どうマイクロサービス化するか? BFF 注文管理 在庫 配送 顧客 参照系 Saga orchestrator

    • Saga(オーケストレータ)パターン、そしてKafkaを使ってみる。 • データベースは各サービス内に配置。 consumer consumer consumer Pod
  12. 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 ③リトライ
  13. 20 Sagaに欠けているもの:Isolation • 「ローカルトランザクションの結果が、他サービスに 見えてしまうのでは?」 ⇒その通りです。 • 対策として、CQRS(Command and Query

    Responsibility Segregation )など。 注文管理 顧客 在庫 参照系 View更新 発送 Sagaの途中でデータが 見えてしまうと、 Isolationが崩れる。 Saga終了後に、一貫性のあるViewを非同期で更新する。 ReadをこちらのViewに行うことで、Isolationを担保。 ※但し、Eventual Consistency。
  14. 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
  15. 24 ボトルネックとなるのはデータベース BFF 注文管理 在庫 配送 顧客 参照系 Saga orchestrator

    • サービスが適切に分割され、分散トランザクションが実現されても、 データベースの拡張性には制約がある。 consumer consumer consumer Pod Size/Geopraphicalな Scalabilityが必要
  16. 25 どう実現するか:量的な拡張性① • シンプルな実現方法はReplicationによるリード・レプリカ。 • 単一LeaderでWriteを全て受け付け、log shippingでデータ複製。 【メリット】 • 多くのDBで組込みで提供され、実績も

    豊富な構成。 • read queryのオフロードが可能。 【デメリット】 • 非同期ではラグあり、同期では耐障害性↓ • write queryは全てPrimary(P)で捌く 必要があり、スケールできない。 (単一サービス内) WAL Write S P S Read
  17. 28 実際、遠隔地へのレイテンシはどれぐらい? 60-80ms 20-30ms 90-110ms • 東京-米国西海岸だと約150ms、 EU圏だと300ms • レイテンシが大きいほど、

    レプリケーションのラグも大きく、 ハートビート等がタイムアウト するリスクも増大する。
  18. 29 どう実現するか:地理的な拡張性② • ここでも商用製品は機能・実績が豊富。 • 近郊には同期レプリカ、更に複数のDRサイトへ非同期転送も可。 • Oracle Active Data

    Guardの例。 • Fast Syncの機能で、メモリ内のRedo を同期転送し、レイテンシ短縮。 • Far Syncの機能で、近郊サイトにRedo を同期転送、近郊‐DRサイトは非同期の 転送となり、レイテンシと可用性を向上。 ※近郊サイトはデータを保持しない。 同期転送 非同期転送 非同期転送
  19. 31 量的・地理的どちらの拡張性も満たすデータベースは? • Multi-Leader、同期レプリカ、距離の壁を超えられるDBが必要。 • 一つの答えはGoogle Cloud Spanner。 Witness リージョン

    Read-Write リージョン • 東京ー大阪で地理分散が可能な SQLデータベース。 • ソウルはWitnessリージョン。 (Writeのコミット、投票に参加) • 当然、ACIDトランザクションを サポート。
  20. 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の構成を実現している。
  21. 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結果を返す。
  22. 35 Raftの概要 • Raft自体はsimple & easyを目指した合意プロトコル。 • 主な機能は2つ。 【 Leaderの選出

    】 • ある期間に、クラスタに1人だけのLeaderがいることを保証。 • 一定期間、ハートビートが送られて来なければLeader選出を開始する。 • 過半数の投票が得られれば、Follower(Candidate)がLeaderになることが出来る。 • ネットワークが分断されても、複数のLeaderが発生しないことがポイント。 【 logの複製 】 • log≒コマンドと考えて良い。コマンドの実行順序を合意する仕組み。 • 全てのノードで同じ順序で同じ処理が行われれば、データは同一になるという考え方。 • 障害発生時も合意された結果は戻ったり、覆ることがないのがポイント。 ※詳しくは「NewSQLコンポーネント詳解」で
  23. 36 こんな構成はどうだろう? Raft Leader サイト • 量的・地理的双方の拡張性を満たす、マイクロサービスのバック エンドとして適切な、分散データベースの検証を行っていく。 Followerサイト Followerサイト

    • 多くの分散SQLデータベースでは、 Leaderを1サイトに配置する設定が存在。 • Raftによる合意は近郊サイトのFollower で完了するため、レイテンシも短縮可。 • 大きなポイントとして、合意ベースの システムには3つ以上のサイトが必要。 • この図では関東近郊が全面障害の場合、 関西サイト単独では稼働できない。 (合意に達しないため)
  24. 38 (再掲)今日のゴール ~ 怖くない分散システム ~ 分散システム(≒マイクロサービス)は、 データストアの拡張性も理解して適切な設計を!  “あなたがマイクロサービスをのぞくとき、 分散システムもまたあなたをのぞいているのだ。”

     分散システムの大きな課題=トランザクション  あなたのマイクロサービス、スケールしますか?  局所的な高負荷に対して拡張できますか?  DRまたは地理分散はできますか?