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

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

View Slide

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

View Slide

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

View Slide

4
新たなムチャブリ
1

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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
それでも残る課題
3

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

37
まとめ
5

View Slide

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

View Slide

39
Questions?
@tzkb
@tzkoba

View Slide

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

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

tzkoba

More Decks by tzkoba

Other Decks in Technology

Featured

Transcript