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