天下一InfluxDB勉強会

goraft & InfluxDB @nobu_k

1

誰？❖ 久保田展行(@nobu_k)!

❖ CTO at Preferred Infrastructure America, Inc.!

❖ PFI(ピーFI)のアメリカ支部!

❖ (Relational) Database, Search Engine, Distributed Systems!

❖ C++, Go!

❖ MessagePack for C/C++メンテナ!

❖ beatmania IIDX DP皆伝

2

Raft?

❖ 非常にわかりやすいコンセンサスプロトコル(アルゴリズム)!

❖ 一般的に難しいものが多かった(Paxosとか)!

❖ 今日は小難しいアルゴリズムの話はなし！!

❖ 参考!

❖ 公式：http://raftconsensus.github.io/!

❖ 分かりやすい資料：http://thesecretlivesofdata.com/raft/!

❖ 自分のスライド(///)：http://www.slideshare.net/pfi/raft-36155398

3

Raftが提供するもの❖ 協調して合意を取る枠組み!

❖ リーダー選出!

❖ (ログ)レプリケーション!

❖ State machine replication!

❖ 異常系はある程度Raftが面倒を見る!

❖ 合意を取って何をするかはアプリケーションにお任せ

Raft cluster

全ノードが同じ状態を維持

同じ状態を冗長化して可用性UP

R

R R

R R

4

Leader

Follower

ZooKeeper?

?

5

ZooKeeper

ZAB

Storage

Rich featuresZK cluster

Application clusters

Storm

❖ File system like KVS!❖ ephemeral nodes

❖ KVSの操作!❖ watch!❖ ACL!❖ etc

❖ ZooKeeper Atomic Broadcast!❖ コンセンサスプロトコル !❖ 理論的証明はなし

6

Raft

ZAB

Storage

Rich features

Raft

DIY

DIY

Consensus protocol

❖ Raftはただのプロトコル！!❖ 一番難しい部分をカバー!

❖ 疎結合なので夢は広がる!❖ 好きなストレージ!❖ 好きな通信手段!❖ 好きなAPI

7

goraft❖ https://github.com/goraft/raft!

❖ Goで書かれたRaftのライブラリ!

❖ goraftの使用例!

❖ Raftd：goraftを使ったサンプル、学習用にどうぞ!

❖ etcd!

❖ InfluxDB!❖ 他にもたくさん！

8

InfluxDB での goraft

9

InfluxDBがRaftで管理する情報❖ Raftに入っている情報!

❖ InfluxDBのクラスタに含まれるサーバ!

❖ 作成済みのデータベース!

❖ ユーザの情報!

❖ シャードの情報!

❖ 作成済み(実行中？)のContinuous query!

❖ これらをRaftで管理することで安全に冗長化、耐障害性を持たせる参考：https://speakerdeck.com/pauldix/the-internals-of-influxdb?slide=50

10

goraft関連のパッケージ❖ api/http!

❖ HTTPサーバ!

❖ coordinator!❖ 分散関連の処理を担当!

❖ Raft関係もここ!

❖ cluster!

❖ InfluxDBクラスタの情報、shard情報

11

データベース作成の例api/http coordinator

cluster

POST /db

CreateDatabaseCommand

raft

CreateDatabase

Apply

CreateDatabase

ClusterConfiguration

DatabaseReplicationFactors

①

②③

④ブロードキャスト完了後、!コミット時にApplyを呼び出す

12

時系列データは？

❖ 時系列データもRaftで冗長化してはダメなのか？!

❖ ダメ!

❖ Raftのプロトコルは安全だがオーバーヘッドが大きい!

❖ InfluxDBが想定するワークロードには合わない!

❖ InfluxDBでは時系列データは自分で管理している

13

Raftの観点から見た

InfluxDBの注意点

14

問題1: 全ノードがRaftのノードとして動く

I

I

II

II

II

R

R

R

R

R

R

R

R

❖ 頻繁な1対全の通信!

❖ Heartbeat: 数10ms単位!

❖ 合意コスト増

“CPU and networking resources can quickly be bottlenecked under stress in a large cluster.”

“It is unlikely that 4 nodes will simultaneously fail so clusters larger than 9 nodes are not common.”

15

妄想: 将来の構成

I

I I

I I

R

R

R

or

I

I I

I I

部分的にRaftノードとして機能Raftを別クラスタで運用

タイムアウトがシビアなので!こっちの方が良さそう。

R

R R

16

問題2: ReadにRaftを使ってない❖ RaftではLeaderとFollowerでコミットのタイミングが違う!

❖ Followerが持っている情報を読んではいけない!

❖ Leaderが持っている情報も、本当は直接読んじゃダメ!

❖ 自分の書いた値を読めないことがある!

❖ 読み込みもRaftのコマンドとして実行することで解決

R

R

R

この状態でLeaderが切り替わった瞬間に!直readが発生すると、元々コミット済みだった!情報を読めない。レアだが、実際に起こると!非常に原因を特定しづらい。殺人事件に発展!することもあるため注意が必要だ。

未コミットコミット済み 17

問題3: 処理の冪等性❖ Raftのログレプリケーションの仕組みは冪等!

❖ しかし、アプリケーションレベルでの冪等性は考慮されない!

❖ 例：!

❖ クライアントが100円送金するリクエストを投げる!

❖ コミット前にクライアントがタイムアウト!

❖ 実際は処理は継続しており、送金リクエストはコミットされる!

❖ しかしクライアントはその事実を知らないのでリトライ!

❖ 結果として200円送金されてしまう!

❖ Raftは内容が同一のリクエストが2つ来たと解釈する

18

InfluxDBで問題になるか❖ そもそもInfluxDBのコマンドは冪等か？!

❖ コマンドが冪等であればそもそも問題ない!

❖ 冪等なもの：DB作成とか!

❖ 冪等じゃないもの：CreateContinuousQuery!

❖ 同じものが複数個作られちゃう!

❖ InfluxDBのユーザがタイムアウト時にリトライするとまずい

19

どう保証するか？

❖ 論文ではTCPのようにIDを振るアプローチを紹介!

❖ リトライと冪等性のデザインパターン by frsyuki!

❖ http://frsyuki.hatenablog.com/entry/2014/06/09/164559!

❖ http://frsyuki.hatenablog.com/entry/2014/06/12/123856

20

その他: goraftのメンバシップ管理が不完全

❖ Raft公式サイトのgoraftの項目にて・・・!

❖ Membership Changes: partial?!

❖ Raft的にはJoint Consensusを使うことになってる!

❖ 課題!

❖ ログ同期完了のタイミングを把握するのが難しい!

❖ 特に複数台のノードをまとめて追加・削除するときに大変!

❖ InfluxDBがRaftで管理している情報は小さいのでたぶん大丈夫

21

まとめ❖ Raft!

❖ コンセンサスプロトコル!

❖ goraft!

❖ Raftのライブラリ!

❖ ZooKeeperのようにフルスタックな機能は提供しない!

❖ InfluxDB!

❖ 主にクラスタ情報の管理にgoraftを使用

22