Quorum on AWS

Transcript

1. Quorum ----------› AWS blockchain.tokyo#24 LIFULL Co., Ltd. 秀野 亮@ryo0301
2. 自己紹介 • 物件検索エンジン • AWS移行 • 不動産情報コンソーシアム ADRE • 社内通貨 LIFULL COIN
3. 話すこと 1. 社内通貨の取組み 2. Quorumの仕様とシステム構成 3. AWSのマネージドサービスを使ったノード管 理
4. 社内通貨の取組み
5. 社内通貨の取組み • LIFULL COIN • ブロックチェーン上に御天道様を作 るプロジェクト • 「御天道様が見ている」という 日本古来のアレ • ほぼ1人で開発 ◦ ボランティアで月1回参加が数人
6. 社内通貨での構成(理想) Cognito AppSync ALB KMS LIFULL COIN Wallet Quorum
7. QuorumとRaftの特性
8. Quorum • コンセンサスアルゴリズムにはRaftを採用 ◦ リーダーがブロックを生成、リーダーのブロックをレプリケーション ◦ リーダーは選挙で決める ◦ 過半数のノードが生きてれば大丈夫 • Raft Visualization ◦ https://raft.github.io/ ◦ 可視化されてて分かった気になれる
9. Quorum+Raftの利点 • トランザクション発生時にブロックが生成される ◦ 無駄なブロックが出ないので容量節約 /同期高速 • ブロックがほぼリアルタイムに生成される ◦ 初期値だと最低50ms間隔 • フォークがない ◦ Leaderが正義 • ブロックタイムスタンプに信憑性がある ◦ Raftの場合は block.timestamp がナノ秒単位
10. Quorum+Raftの欠点 • BFTでなくCFT ◦ ビザンティン障害耐性はない • Leader盲信 ◦ 全ブロック作り直せる ◦ extraDataに署名があるので検証はできるっぽい • Leaderが高負荷 ◦ 全てのブロックはLeaderからレプリケーションされる • プライベートチェーンにしか向かなそう ◦ コンソーシアムチェーンの規模や信頼に依る？
11. Quorum小話 • 現状、Quorum 2.2.5を使っている • 2.2.6〜2.4.0で色々機能が追加されてる • RaftのLearnerノード ◦ ノード追加時はLearnerとして追加 ◦ 同期完了後Verifierに昇格、という方法が推奨されてる • RBACコントラクトによるパーミッション管理(β版) ◦ スマートコントラクトで Role Base Access Control ◦ Network、Org.、Sub-Org.、Node、Account を管理 • DNSサポート ◦ enodeにIPでなくホスト名を使える ◦ 実装するなら先に言って欲しかった
12. ノード起動時の仕様
13. 起動時の仕様 • Raftでは各ノードにRaftIDが振られる ◦ RaftIDは1から連番で振られる ◦ 1度使ったIDは再利用されない ◦ 新規ノード追加時は最大値 +1 • クラスターの初期ノードか追加ノードかで起動方法が違う
14. クラスターメンバー全員のenodeを列挙しておく 同じ内容のstatic-nodes.jsonを全員が持っておく 起動方法の違い(初期ノード) • 初期クラスターの構築時 a. 各ノードのローカルに static-nodes.json を用意する必要がある b. 各ノードのenodeが必要＝公開鍵とIPが必要 c. static-nodes.json に enode をJSON配列で記述 d. 配列順に上から RaftID が振られる e. 各ノードの static-nodes.json には enode が同じ順序で記述されている必要がある
15. static-nodes.json [ "enode://8b4644877b07ec93a261b...41d421@10.0.5.73:30303?raftport=50400&discport=0", "enode://120a8cd56b307fed8eb96...ca6bf08@10.0.4.145:30303?raftport=50400&discport=0", "enode://4b418ddda72396555f185...808d3b@10.0.4.21:30303?raftport=50400&discport=0", "enode://e5377bcf8bbc3e37c713b...b5146e1@10.0.5.221:30303?raftport=50400&discport=0", "enode://85f5d0b8f8ea6396749d7...67b2bce@10.0.5.115:30303?raftport=50400&discport=0" ]
16. 起動方法の違い(追加ノード) • 既存クラスターに新規ノードを追加する場合 a. static-nodes.jsonには自分のenodeだけ記述すればよい b. geth の起動前に raft.addPeer(enode) しておく必要がある c. raft.addPeer することで RaftID が発番される d. RaftIDを指定して geth を起動する(--raftjoinexisting) geth 起動前にノード情報をクラスターに事前通知しておく RaftIDを指定して起動すると既存メンバーからの接続待受けモードになる static-nodes.json はもうどうでもいい
17. 無限ループして起動できない問題 起動には RaftID が必要 ↓ RaftID を取得するには raft.addPeer を実行する必要 ↓ raft.addPeer を実行するには引数として enode が必要 ↓ enode を作るには IP が必要 ↓ Fargateはタスクの IP を指定できない (ElasticIPは指定できた気がする ) ↓ IP は起動時に決まる ↓ 起動には RaftID が必要 (振り出しに戻る)
18. 起動スクリプト 解決策 • Fargateタスクの起動からgethの起動の間にraft.addPeerすればいける • 起動スクリプトより別コンテナに分けたほうがいいかも Fargateタスク起動 ↓ IP取得、enode作成 ↓ raft.addPeer(enode)でRaftID取得 ↓ RaftIDを指定してgethを起動
19. Quorumの全体構成
20. 起動イベント 停止イベント Event Bridge default イベントバス Fargate Quorumクラスター Step Functions Expressワークフロー Cloud Map ノード情報参照 ノード情報 登録・削除 その他、 ・ALBへのIP登録・削除 ・raft.removePeer ・CloudMap更新の進捗確認 なども行っている
21. Fargate Quorumクラスター Event Bridge default イベントバス Step Functions Expressワークフロー 起動イベント StartExecution Cloud Map RegisterInstance WaitOperation ALB TargetGroup RegisterTargets ヘルスチェック ノード情報参照
22. Fargate Quorumクラスター Event Bridge default イベントバス Step Functions Expressワークフロー 停止イベント StartExecution Cloud Map DeregisterInstance WaitOperation ALB TargetGroup DeregisterTargets raft.removePeer
23. Fargateでいいのか • 全ノードが同じデータを持ってる単純で非効率な構成 • Raftの過半数割れ前にノード追加すれば大丈夫 • 用途やRaftのせいでブロックがさほど増えない • なので「Fargateでええじゃろ・・・」 • 初期ノードと追加ノードで起動方法が違うのでECSのサービ スは使えなかった=個別にタスク起動
24. CloudMapでのノード管理 • フルマネージドなサービスディスカバリ • DNSかAPIかその両方で情報を取得(今回はAPIのみ利用) ◦ QuorumのDNSサポートが実装されたので DNSを使ってもいいかも • ノード管理のためのプロセスを運用したくなかったので使っ てみた • consul-templateのような構成の変化をイベントで検知する 機能はなかった ◦ Event BridgeにはCloudMap関連のイベントはなさそうだった ◦ 定期的にプルしてくる処理を実装した
25. StepFunctions Expressワークフ ロー • 最長5分の高速ワークフロー • 標準ワークフローはat-most-onceだが、こちらは at-least-once • 同じ入力の複数の同時実行が考慮されてること(冪等性) ◦ CloudMapあたりの処理はあまり自信がない …
26. 起動処理
27. 起動イベント • カスタムイベント • Dockerの起動スクリプト内で送信している cat << EOJ | aws events put-events --entries file:///dev/stdin [ { "Source": "lifull-coin.quorum", "Detail": "$json", "Resources": [ "$task_arn" ], "DetailType": "Quorum Node State Change" } ] EOJ
28. 初期クラスターの構築 • 各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
29. 初期クラスターの構築 ノード情報を揃える ノード情報を含めて起動イベント発火 EventBridgeで起動イベント受信 StepFunctionsのワークフロー開始 CloudMapにノード情報登録 指定台数が起動するまで CloudMap監視 指定台数揃ったらstatic-nodes.json生成 ALBターゲットグループに IP登録 geth起動 ALBヘルスチェックOK
30. ノードの追加 • Dockerの起動スクリプトで諸々初期化 • 同じenvの既存ノード一覧をCloudMapから取得 • 必要な情報を用意してJSON-RPCで raft.addPeer(enode)を実行→RaftIDゲット ◦ どれかのノードで成功すればあとはクラスター内で新参者情報 は共有される • 必要な情報を用意してEventBridgeに起動イベントを送 信 • RaftIDを付けてgethを起動 ◦ CloudMapへの登録は待たない ◦ static-nodes.jsonには自身のenodeだけ記述 5 5 raft.addPeer 6
31. ノードの追加 ノード情報を揃える CloudMapから既存ノード情報を取得 EventBridgeで起動イベント受信 StepFunctionsのワークフロー開始 CloudMapにノード情報登録 ALBターゲットグループに IP登録 geth起動 (RaftID付き) ALBヘルスチェックOK ノード情報を含めて起動イベント発火 既存ノードに対してraft.addPeerを実行
32. 停止処理
33. 停止イベント • ECSのTaskStateChangeイベント • FargateタスクのlastStatus, desiredStatusが変化すると発火
34. ノードの停止 • 停止したノードと同じenvのALBターゲットグループARNを取 得 • ALBからIPを登録解除 • 既存ノードに対してJSON-RPCで raft.removePeer(RaftID) を実行 • CloudMapから該当ノードの情報を削除
35. その他の処理
36. ALBのターゲットグループも CloudMapで管理 • envごとにALBのターゲットグループもCloudMapで管理して いる • 起動/停止イベントの対象ノードのenvでターゲットグループ を探す ◦ 登録は手作業で、あまりちゃんと設計してない
37. Learnerの同期→Verifier昇格→ALB 追加 • ブロックの同期が終わるまで最新の情報が取得できない • 取得できないがALBには登録されてしまう • 同期完了イベントが発火できれば、昇格→ALB追加まで出 来そう ◦ まだ実装してない
38. 完