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

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

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

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. クラウドマイクロサービス時代の今こそ! _
    理解して拡げる
    分散システムの基礎知識
    July Tech Festa 2020 , 7/25
    @tzkb

    View Slide

  2. 2
    最近やっていること
    • PGConf.Asia 2019
    “Building PostgreSQL as a Service
    with Kubernetes”
    • NewSQL関連のブログ投稿
    “2020年現在のNewSQLについて”
    “NewSQLコンポーネント詳解”
    + =∞

    View Slide

  3. 3
    1. 新たなムチャブリ
    2. モノリスからマイクロサービスへ
    3. それでも残る課題
    4. 真にスケーラブルなDBを探して
    5. まとめ
    アジェンダ

    View Slide

  4. 4
    新たなムチャブリ
    1

    View Slide

  5. 5
    昨年のことです。
    LB
    AP
    AP
    AP
    • 古きよきLB-AP-DBのWebシステムがありました。
    • VMかもしれないし、
    ベアメタルかも。
    • 機器は老朽化、アーキ
    テークチャも陳腐化。
    • ある日、
    偉い人は言いました。
    「これからはクラウド」
    #jtf2019 の話

    View Slide

  6. 6
    Lift & Shift だ!
    • 担当者は不眠不休でがんばりました。
    • クラウド上へシステムを
    移行。
    • アプリケーションをコン
    テナ化、Kubernetesに
    デプロイ。
    • データベースはManaged
    Serviceを使った。
    良くありますよね?
    (むしろ頑張ったほう)
    AP
    AP
    AP
    #jtf2019 の話

    View Slide

  7. 7
    Database with Kubernetesという選択肢
    電源、ラック
    サーバ管理
    OSインストール
    OSパッチ
    DBインストール
    DBパッチ
    バックアップ/リストア
    HA
    スケール
    アプリケーション
    Database w/
    K8sクラスタ
    による管理
    バージョン選択 任意のバージョンを選べる
    リソース上限 Nodeのキャパシティ次第
    リソース下限 CPUはmill core単位で指定可
    パラメータ 全て変更可能
    Extension 全て導入可能
    OSログイン 可能(任意のユーザ作成も可)
    #jtf2019 の話

    View Slide

  8. 8
    時はDX時代、
    • 2020年の偉い人はこう言いました。 注:フィクションです。
    「これからは、
    マイクロサービスでDXだ。」
    「クバ何とか使ってるから、
    マイクロサービスできるな?」

    View Slide

  9. 9
    そしてマイクロサービスへ
    • 担当者は不眠不休でがんばりました(N回目)。
    BFF
    注文管理
    商品
    配送
    顧客
    参照系
    Pod
    Pod
    Pod
    Pod
    Pod
    Pod

    View Slide

  10. 10
    これって、分散システムってやつですよね。
     アーキテクチャの変更はとても大変。
     モノリス内の同期通信 ⇒ サービス間の非同期通信
     一つの巨大データベース ⇒ 小さな沢山のデータベース
     上手くいっているときは良い。でも、障害時は大丈夫?
     メインサイトだけ?DRサイトも必要と言われたら?
     結局、何が問題なのか??

    View Slide

  11. 11
    今日のゴール ~ 怖くない分散システム ~
     “あなたがマイクロサービスをのぞくとき、
    分散システムもまたあなたをのぞいているのだ。”
     分散システムの大きな課題=トランザクション
     あなたのマイクロサービス、スケールしますか?
     局所的な高負荷に対して拡張できますか?
     DRまたは地理分散はできますか?

    View Slide

  12. 12
    モノリスからマイクロサービスへ
    2

    View Slide

  13. 13
    Youは何しにマイクロサービスへ?
    • 目的が間違ったマイクロサービス化は失敗する。
    【 Devの視点から見た目的の例】
    • コードベースに、適切なコントロールとアジリティを。
    • 小さなデプロイ単位、迅速なリリース。
    • サービス毎に技術を選択可、新規性への取り組み。
    【 Opsの視点から見た目的の例】
    • アーキテクチャに、適切な拡張性と可用性を。
    • サービス単位で局所的に拡張可能。
    • 障害は分離され、全体へ波及しない。

    View Slide

  14. 14
    マイクロサービスとは分散システムなのか。
    • 「マイクロサービスとはすなわち分散システムである」
    by Sander Hoogendoorn
    • 分散システムの4つのデザインゴール by Tanenbaum
    • Distribution transparency
    ⇒透過的に分散され、内部の障害は隠蔽される。
    • Scalability (Size/Geographical/Administrative)
    ⇒量的・地理的な意味で拡張性を持つ
    • Support sharing resources
    • Openness

    View Slide

  15. 15
    そもそも、あなたのシステムはモノリスですか。
    • モノリスではないが、完全にマイクロサービスでもないもの?
    共有データベース
    顧客
    Pod
    注文管理
    Pod
    在庫
    Pod
    配送
    Pod
    • 適切に分割された、
    Cloud Nativeなアプリ
    ケーション。
    • 非同期処理も併用し、
    障害の波及範囲を限定。
    • データベースは共有。
    • 十分な可用性を持つが、
    ≠マイクロサービス
    (※私個人の考えです。)

    View Slide

  16. 16
    マイクロサービスの大きな課題:分散トランザクション
    • マイクロサービスではDatabase per Serviceが原則。
    顧客
    注文管理 在庫 配送
    • データベースを分割する
    と始まるのが、分散トラ
    ンザクションの戦い。
    • 共有データベースではで
    きた、ACIDなトランザ
    クションは実現できない。
    • ロールバックもDBには
    任せられない。
    Pod
    Pod Pod Pod

    View Slide

  17. 17
    どうマイクロサービス化するか?
    BFF
    注文管理
    在庫
    配送
    顧客
    参照系
    Saga
    orchestrator
    • Saga(オーケストレータ)パターン、そしてKafkaを使ってみる。
    • データベースは各サービス内に配置。
    consumer
    consumer
    consumer
    Pod

    View Slide

  18. 18
    Sagaの概要①
    • サービス毎にローカルトランザクションを順次実行。
    • ロールバックは補償トランザクションで行う。
    注文管理 顧客
    create
    Order
    在庫 発送
    reserve
    Credit
    update
    Inventory
    arrange
    Shipment
    complete
    Order
    cancel
    Credit
    adjust
    Inventory
    cansel
    Order

    View Slide

  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 ③リトライ

    View Slide

  20. 20
    Sagaに欠けているもの:Isolation
    • 「ローカルトランザクションの結果が、他サービスに
    見えてしまうのでは?」 ⇒その通りです。
    • 対策として、CQRS(Command and Query Responsibility Segregation )など。
    注文管理 顧客 在庫
    参照系
    View更新
    発送
    Sagaの途中でデータが
    見えてしまうと、
    Isolationが崩れる。
    Saga終了後に、一貫性のあるViewを非同期で更新する。
    ReadをこちらのViewに行うことで、Isolationを担保。
    ※但し、Eventual Consistency。

    View Slide

  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

    View Slide

  22. 22
    それでも残る課題
    3

    View Slide

  23. 23
    あなたのマイクロサービス、本当にスケーラブルですか?
    • 単一サービスとして十分な拡張性がありますか?
    • 地理的に分散された環境へも拡張できますか?
    • Distribution transparency
    ⇒透過的に分散システムされ、内部障害は隠蔽される。
    • Scalability (Size/Geographical/Administrative)
    ⇒量的・地理的な意味で拡張性を持つ

    Support sharing resources
    • Openness

    View Slide

  24. 24
    ボトルネックとなるのはデータベース
    BFF
    注文管理
    在庫
    配送
    顧客
    参照系
    Saga
    orchestrator
    • サービスが適切に分割され、分散トランザクションが実現されても、
    データベースの拡張性には制約がある。
    consumer
    consumer
    consumer
    Pod
    Size/Geopraphicalな
    Scalabilityが必要

    View Slide

  25. 25
    どう実現するか:量的な拡張性①
    • シンプルな実現方法はReplicationによるリード・レプリカ。
    • 単一LeaderでWriteを全て受け付け、log shippingでデータ複製。
    【メリット】
    • 多くのDBで組込みで提供され、実績も
    豊富な構成。
    • read queryのオフロードが可能。
    【デメリット】
    • 非同期ではラグあり、同期では耐障害性↓
    • write queryは全てPrimary(P)で捌く
    必要があり、スケールできない。
    (単一サービス内)
    WAL
    Write
    S
    P
    S
    Read

    View Slide

  26. 26
    どう実現するか:量的な拡張性②
    • 理想はMulti-Leaderで水平スケールが可能なデータベース。
    (単一サービス内)
    Write
    Read
    処理の
    振分け・集約
    【VitessによるSharding】 【Oracle RAC】
    (単一サービス内)
    Write
    Read

    View Slide

  27. 27
    どう実現するか:地理的な拡張性①
    BFF 注文管理 在庫
    • ステートレスなアプリケーションはメイン・DRサイト双方で
    稼働させればよいが、データベースはレプリカが必要。
    BFF
    注文管理 在庫
    メインサイト
    DRサイト
    距離の壁

    View Slide

  28. 28
    実際、遠隔地へのレイテンシはどれぐらい?
    60-80ms
    20-30ms
    90-110ms
    • 東京-米国西海岸だと約150ms、
    EU圏だと300ms
    • レイテンシが大きいほど、
    レプリケーションのラグも大きく、
    ハートビート等がタイムアウト
    するリスクも増大する。

    View Slide

  29. 29
    どう実現するか:地理的な拡張性②
    • ここでも商用製品は機能・実績が豊富。
    • 近郊には同期レプリカ、更に複数のDRサイトへ非同期転送も可。
    • Oracle Active Data Guardの例。
    • Fast Syncの機能で、メモリ内のRedo
    を同期転送し、レイテンシ短縮。
    • Far Syncの機能で、近郊サイトにRedo
    を同期転送、近郊‐DRサイトは非同期の
    転送となり、レイテンシと可用性を向上。
    ※近郊サイトはデータを保持しない。
    同期転送
    非同期転送
    非同期転送

    View Slide

  30. 30
    真にスケーラブルなDBを探して
    4

    View Slide

  31. 31
    量的・地理的どちらの拡張性も満たすデータベースは?
    • Multi-Leader、同期レプリカ、距離の壁を超えられるDBが必要。
    • 一つの答えはGoogle Cloud Spanner。
    Witness
    リージョン
    Read-Write
    リージョン
    • 東京ー大阪で地理分散が可能な
    SQLデータベース。
    • ソウルはWitnessリージョン。
    (Writeのコミット、投票に参加)
    • 当然、ACIDトランザクションを
    サポート。

    View Slide

  32. 32
    • Spannerの論文を元に開発された、OSSの分散SQLデータベースは
    下表のように既に市場に投入されている。
    • SQLに限らなければ、CassandraやDynamoDBやCosmos DBも地理分散・高い拡張性等の
    特徴を持つが、トランザクションがACIDとは言えない。
    Spannerと類似の分散SQLデータベース
    名称 開発元 提供形態
    Cloud Spanner Google クラウド(managed)のみ
    Cockroach Labs オンプレ/独自managed等
    Yugabyte オンプレ/独自managed等
    PingCAP オンプレ/独自managed等

    View Slide

  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の構成を実現している。

    View Slide

  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結果を返す。

    View Slide

  35. 35
    Raftの概要
    • Raft自体はsimple & easyを目指した合意プロトコル。
    • 主な機能は2つ。
    【 Leaderの選出 】
    • ある期間に、クラスタに1人だけのLeaderがいることを保証。
    • 一定期間、ハートビートが送られて来なければLeader選出を開始する。
    • 過半数の投票が得られれば、Follower(Candidate)がLeaderになることが出来る。
    • ネットワークが分断されても、複数のLeaderが発生しないことがポイント。
    【 logの複製 】
    • log≒コマンドと考えて良い。コマンドの実行順序を合意する仕組み。
    • 全てのノードで同じ順序で同じ処理が行われれば、データは同一になるという考え方。
    • 障害発生時も合意された結果は戻ったり、覆ることがないのがポイント。
    ※詳しくは「NewSQLコンポーネント詳解」で

    View Slide

  36. 36
    こんな構成はどうだろう?
    Raft Leader
    サイト
    • 量的・地理的双方の拡張性を満たす、マイクロサービスのバック
    エンドとして適切な、分散データベースの検証を行っていく。
    Followerサイト
    Followerサイト
    • 多くの分散SQLデータベースでは、
    Leaderを1サイトに配置する設定が存在。
    • Raftによる合意は近郊サイトのFollower
    で完了するため、レイテンシも短縮可。
    • 大きなポイントとして、合意ベースの
    システムには3つ以上のサイトが必要。
    • この図では関東近郊が全面障害の場合、
    関西サイト単独では稼働できない。
    (合意に達しないため)

    View Slide

  37. 37
    まとめ
    5

    View Slide

  38. 38
    (再掲)今日のゴール ~ 怖くない分散システム ~
    分散システム(≒マイクロサービス)は、
    データストアの拡張性も理解して適切な設計を!
     “あなたがマイクロサービスをのぞくとき、
    分散システムもまたあなたをのぞいているのだ。”
     分散システムの大きな課題=トランザクション
     あなたのマイクロサービス、スケールしますか?
     局所的な高負荷に対して拡張できますか?
     DRまたは地理分散はできますか?

    View Slide

  39. 39
    Questions?
    @tzkb
    @tzkoba

    View Slide