Quorum on AWS - Speaker Deck

Slide 1

Slide 1 text

Quorum ----------› AWS blockchain.tokyo#24 LIFULL Co., Ltd. 秀野亮@ryo0301

Slide 2

Slide 2 text

自己紹介 ● 物件検索エンジン ● AWS移行 ● 不動産情報コンソーシアム ADRE ● 社内通貨 LIFULL COIN

Slide 3

Slide 3 text

話すこと 1. 社内通貨の取組み 2. Quorumの仕様とシステム構成 3. AWSのマネージドサービスを使ったノード管理

Slide 4

Slide 4 text

社内通貨の取組み

Slide 5

Slide 5 text

社内通貨の取組み ● LIFULL COIN ● ブロックチェーン上に御天道様を作るプロジェクト ● 「御天道様が見ている」という日本古来のアレ ● ほぼ1人で開発 ○ ボランティアで月1回参加が数人

Slide 6

Slide 6 text

社内通貨での構成(理想) Cognito AppSync ALB KMS LIFULL COIN Wallet Quorum

Slide 7

Slide 7 text

QuorumとRaftの特性

Slide 8

Slide 8 text

Quorum ● コンセンサスアルゴリズムにはRaftを採用 ○ リーダーがブロックを生成、リーダーのブロックをレプリケーション ○ リーダーは選挙で決める ○ 過半数のノードが生きてれば大丈夫 ● Raft Visualization ○ https://raft.github.io/ ○ 可視化されてて分かった気になれる

Slide 9

Slide 9 text

Quorum+Raftの利点 ● トランザクション発生時にブロックが生成される ○ 無駄なブロックが出ないので容量節約 /同期高速 ● ブロックがほぼリアルタイムに生成される ○ 初期値だと最低50ms間隔 ● フォークがない ○ Leaderが正義 ● ブロックタイムスタンプに信憑性がある ○ Raftの場合は block.timestamp がナノ秒単位

Slide 10

Slide 10 text

Quorum+Raftの欠点 ● BFTでなくCFT ○ ビザンティン障害耐性はない ● Leader盲信 ○ 全ブロック作り直せる ○ extraDataに署名があるので検証はできるっぽい ● Leaderが高負荷 ○ 全てのブロックはLeaderからレプリケーションされる ● プライベートチェーンにしか向かなそう ○ コンソーシアムチェーンの規模や信頼に依る？

Slide 11

Slide 11 text

Quorum小話 ● 現状、Quorum 2.2.5を使っている ● 2.2.6〜2.4.0で色々機能が追加されてる ● RaftのLearnerノード ○ ノード追加時はLearnerとして追加 ○ 同期完了後Veriﬁerに昇格、という方法が推奨されてる ● RBACコントラクトによるパーミッション管理(β版) ○ スマートコントラクトで Role Base Access Control ○ Network、Org.、Sub-Org.、Node、Account を管理 ● DNSサポート ○ enodeにIPでなくホスト名を使える ○ 実装するなら先に言って欲しかった

Slide 12

Slide 12 text

ノード起動時の仕様

Slide 13

Slide 13 text

起動時の仕様 ● Raftでは各ノードにRaftIDが振られる ○ RaftIDは1から連番で振られる ○ 1度使ったIDは再利用されない ○ 新規ノード追加時は最大値 +1 ● クラスターの初期ノードか追加ノードかで起動方法が違う

Slide 14

Slide 14 text

クラスターメンバー全員のenodeを列挙しておく同じ内容のstatic-nodes.jsonを全員が持っておく起動方法の違い(初期ノード) ● 初期クラスターの構築時 a. 各ノードのローカルに static-nodes.json を用意する必要がある b. 各ノードのenodeが必要＝公開鍵とIPが必要 c. static-nodes.json に enode をJSON配列で記述 d. 配列順に上から RaftID が振られる e. 各ノードの static-nodes.json には enode が同じ順序で記述されている必要がある

Slide 15

Slide 15 text

static-nodes.json [ "enode://[email protected]:30303?raftport=50400&discport=0", "enode://[email protected]:30303?raftport=50400&discport=0", "enode://[email protected]:30303?raftport=50400&discport=0", "enode://[email protected]:30303?raftport=50400&discport=0", "enode://[email protected]:30303?raftport=50400&discport=0" ]

Slide 16

Slide 16 text

起動方法の違い(追加ノード) ● 既存クラスターに新規ノードを追加する場合 a. static-nodes.jsonには自分のenodeだけ記述すればよい b. geth の起動前に raft.addPeer(enode) しておく必要がある c. raft.addPeer することで RaftID が発番される d. RaftIDを指定して geth を起動する(--raftjoinexisting) geth 起動前にノード情報をクラスターに事前通知しておく RaftIDを指定して起動すると既存メンバーからの接続待受けモードになる static-nodes.json はもうどうでもいい

Slide 17

Slide 17 text

無限ループして起動できない問題起動には RaftID が必要 ↓ RaftID を取得するには raft.addPeer を実行する必要 ↓ raft.addPeer を実行するには引数として enode が必要 ↓ enode を作るには IP が必要 ↓ Fargateはタスクの IP を指定できない (ElasticIPは指定できた気がする ) ↓ IP は起動時に決まる ↓ 起動には RaftID が必要 (振り出しに戻る)

Slide 18

Slide 18 text

起動スクリプト解決策 ● Fargateタスクの起動からgethの起動の間にraft.addPeerすればいける ● 起動スクリプトより別コンテナに分けたほうがいいかも Fargateタスク起動 ↓ IP取得、enode作成 ↓ raft.addPeer(enode)でRaftID取得 ↓ RaftIDを指定してgethを起動

Slide 19

Slide 19 text

Quorumの全体構成

Slide 20

Slide 20 text

起動イベント停止イベント Event Bridge default イベントバス Fargate Quorumクラスター Step Functions Expressワークフロー Cloud Map ノード情報参照ノード情報登録・削除その他、・ALBへのIP登録・削除・raft.removePeer ・CloudMap更新の進捗確認なども行っている

Slide 21

Slide 21 text

Fargate Quorumクラスター Event Bridge default イベントバス Step Functions Expressワークフロー起動イベント StartExecution Cloud Map RegisterInstance WaitOperation ALB TargetGroup RegisterTargets ヘルスチェックノード情報参照

Slide 22

Slide 22 text

Fargate Quorumクラスター Event Bridge default イベントバス Step Functions Expressワークフロー停止イベント StartExecution Cloud Map DeregisterInstance WaitOperation ALB TargetGroup DeregisterTargets raft.removePeer

Slide 23

Slide 23 text

Fargateでいいのか ● 全ノードが同じデータを持ってる単純で非効率な構成 ● Raftの過半数割れ前にノード追加すれば大丈夫 ● 用途やRaftのせいでブロックがさほど増えない ● なので「Fargateでええじゃろ・・・」 ● 初期ノードと追加ノードで起動方法が違うのでECSのサービスは使えなかった=個別にタスク起動

Slide 24

Slide 24 text

CloudMapでのノード管理 ● フルマネージドなサービスディスカバリ ● DNSかAPIかその両方で情報を取得(今回はAPIのみ利用) ○ QuorumのDNSサポートが実装されたので DNSを使ってもいいかも ● ノード管理のためのプロセスを運用したくなかったので使ってみた ● consul-templateのような構成の変化をイベントで検知する機能はなかった ○ Event BridgeにはCloudMap関連のイベントはなさそうだった ○ 定期的にプルしてくる処理を実装した

Slide 25

Slide 25 text

StepFunctions Expressワークフロー ● 最長5分の高速ワークフロー ● 標準ワークフローはat-most-onceだが、こちらは at-least-once ● 同じ入力の複数の同時実行が考慮されてること(冪等性) ○ CloudMapあたりの処理はあまり自信がない …

Slide 26

Slide 26 text

起動処理

Slide 27

Slide 27 text

起動イベント ● カスタムイベント ● Dockerの起動スクリプト内で送信している cat << EOJ | aws events put-events --entries ﬁle:///dev/stdin [ { "Source": "lifull-coin.quorum", "Detail": "$json", "Resources": [ "$task_arn" ], "DetailType": "Quorum Node State Change" } ] EOJ

Slide 28

Slide 28 text

初期クラスターの構築 ● 各Fargateタスクでクラスターサイズを指定して起動 ○ Consulの-bootstrap-expectオプションのような感じ ○ 指定台数に達したらクラスターの起動処理を開始するオプション ● Dockerの起動スクリプトで諸々初期化 ● 必要な情報を用意してEventBridgeに起動イベントを送信 ○ order (=nodeID) ○ raftId ○ env ○ publicKey ○ IP ○ p2pPort ○ raftPort ● 起動スクリプトはCloudMapのノード情報を参照して指定台数が起動するまで待機 ● CloudMap上に指定台数のノード情報が集まったら各ノードでstatic-nodes.jsonを生成→geth起動 2/5 4/5 Waiting Waiting 5/5

Slide 29

Slide 29 text

初期クラスターの構築ノード情報を揃えるノード情報を含めて起動イベント発火 EventBridgeで起動イベント受信 StepFunctionsのワークフロー開始 CloudMapにノード情報登録指定台数が起動するまで CloudMap監視指定台数揃ったらstatic-nodes.json生成 ALBターゲットグループに IP登録 geth起動 ALBヘルスチェックOK

Slide 30

Slide 30 text

ノードの追加 ● Dockerの起動スクリプトで諸々初期化 ● 同じenvの既存ノード一覧をCloudMapから取得 ● 必要な情報を用意してJSON-RPCで raft.addPeer(enode)を実行→RaftIDゲット ○ どれかのノードで成功すればあとはクラスター内で新参者情報は共有される ● 必要な情報を用意してEventBridgeに起動イベントを送信 ● RaftIDを付けてgethを起動 ○ CloudMapへの登録は待たない ○ static-nodes.jsonには自身のenodeだけ記述 5 5 raft.addPeer 6

Slide 31

Slide 31 text

ノードの追加ノード情報を揃える CloudMapから既存ノード情報を取得 EventBridgeで起動イベント受信 StepFunctionsのワークフロー開始 CloudMapにノード情報登録 ALBターゲットグループに IP登録 geth起動 (RaftID付き) ALBヘルスチェックOK ノード情報を含めて起動イベント発火既存ノードに対してraft.addPeerを実行

Slide 32

Slide 32 text

停止処理

Slide 33

Slide 33 text

停止イベント ● ECSのTaskStateChangeイベント ● FargateタスクのlastStatus, desiredStatusが変化すると発火

Slide 34

Slide 34 text

ノードの停止 ● 停止したノードと同じenvのALBターゲットグループARNを取得 ● ALBからIPを登録解除 ● 既存ノードに対してJSON-RPCで raft.removePeer(RaftID) を実行 ● CloudMapから該当ノードの情報を削除

Slide 35

Slide 35 text

その他の処理

Slide 36

Slide 36 text

ALBのターゲットグループも CloudMapで管理 ● envごとにALBのターゲットグループもCloudMapで管理している ● 起動/停止イベントの対象ノードのenvでターゲットグループを探す ○ 登録は手作業で、あまりちゃんと設計してない

Slide 37

Slide 37 text

Learnerの同期→Veriﬁer昇格→ALB 追加 ● ブロックの同期が終わるまで最新の情報が取得できない ● 取得できないがALBには登録されてしまう ● 同期完了イベントが発火できれば、昇格→ALB追加まで出来そう ○ まだ実装してない

Slide 38

Slide 38 text

完