1 SHIEDLにおけるGKE/CircleCIを活用した サービス、フルノードの基盤開発 2019/9/25 Naochika Hanamura

2 自己紹介 名前：花村直親(@naomasabit) 経歴： ITコンサル・エンジニア => データアナリスト / ブロックチェーンR&D / エンジニアリード => ブロックチェーンスタートアップ共同創業（catabira） => ITコンサル・エンジニアでフリーランス [最近よく使うもの] Go, Python, Solidity, Kubernetes, Ethereum フリーランスのブロックチェーンエンジニアとして BUIDLを手伝っています 「ブロックチェーン×分析」のプロダクト開発に関わるのは３度目 やってきたこと：

3 SHIEDLのインフラ周りでやったこと 7/22 MVPリリース 6/22 BUIDLジョイン 7/4 CI/CD完成 CI/CDのパイプライン整備 GKE基盤整備（フルノード含） プロダクション環境作成 7/15 プロダクション環境作成 運用テスト 1.高速開発のためのCI/CDのパイプライン整備 2.GKEでのフルノード運用

4 SHIEDLのインフラ周りでやったこと 7/22 MVPリリース 6/22 BUIDLジョイン 7/4 CI/CD完成 CI/CDのパイプライン整備 GKE基盤整備（フルノード含） プロダクション環境作成 7/15 プロダクション環境作成 運用テスト 1.高速開発のためのCI/CDのパイプライン整備 2.GKEでのフルノード運用

5 ジョイン時のSHIEDL ・プロダクトはほとんどできていたが、リリース後の運用体制作りのためのピースが必要 ・GKEはできていたが、デプロイで kubectl applyを手動で叩いている状況 ・リサーチャーのカナゴールドさんもコア業務以外の手動テストやデプロイしたりしていて貴重 なリソースが勿体無い

6 とりあえずCI/CDのパイプライン整備して速度を上げた ・まずgithubにpushすると自動ビルド、自動テスト、自動デプロイするまでを構築 ・ステージング環境、プロダクション環境に対応するブランチを分ける ・ビルド、テストが通らないとデプロイさせないようにコードで制御 Container Registry Container Infra GKE/Kubernetes ローカル 環境 [デプロイの流れ] push ビルド・テスト docker image push kubernetesにデ プロイ

7 ・jobs circleciの実行単位。jobの実行主体はdocker / machine な どを選べて、dockerを選ぶと仮想環境上のdockerで実行。 machineを選ぶとcircleciのリモート環境で実行。 ・steps 最小の実行単位（コマンドなど）。job内に書き込む。 ・workflow CircleCIはこれをみて実行する。workflow内にjobを書き込ん で実行する CircleCI基本の書き方 version: 2.1 jobs: #ジョブ定義 test: docker: - image: node:xxxx-alpine # 軽いalpineを使う steps: # 実行単位のコマンド - checkout # コードのチェックアウト - run: npm install # 事前準備 - run: name: npm test # 名前 command: npm run test:cov # テストコマンド no_output_timeout: 1m # 1分以上返事がなかったらタ イムアウト workflows: # CircleCIはここ見て実行する test: jobs: - test 自動テスト例

8 CircleCI & GCR, GKEとの連携 ・GCR,GKEとの連携 google/cloud-sdkの公式docker imageや、 circleci/gcp-gcrの公式CircleCI orbがあるので組み合わせは楽 ・Docker Imageのタグ管理 ”CIRCLE_SHA1”を使うとコミットハッシュを利用できるのでビルドタグ管理が簡単 デプロイするイメージを`hogehoge-image:${TAG}`と書いておき、 テンプレートのk8s用ymlを用意しておきイメージタグ置き換えはKustomizeか簡単にやるならenvsubstで ・k8sへデプロイ gke系のorbを使うか “kubectl apply”をstepで用いたジョブを定義して使う

9 リサーチャー等、エンジニアリングが本 業でないメンバーがコア業務に集中でき るようになった 開発、デプロイサイクルが高速化、標準化 GKEはできていたが、デプロイで kubectl applyを手動で叩いている状況 プロダクトはほとんどできていたが、リ リース後の運用体制作りのためのピースが 必要 できたこと リサーチャーのカナゴールドさんも手動テ ストやデプロイしたりリソースが勿体無い 運用で多くのメンバーが入ってきてもテス トが通らないコードはデプロイさせないよ うにした

10 SHIEDLのインフラ周りでやったこと 7/22 MVPリリース 6/22 BUIDLジョイン 7/4 CI/CD完成 CI/CDのパイプライン整備 GKE基盤整備（フルノード含） プロダクション環境作成 7/15 プロダクション環境作成 運用テスト 1.高速開発のためのCI/CDのパイプライン整備 2.GKEでのフルノード運用

11 GKE(Google Managed Kubernetes)でよく使うリソース アプリ系 ● StatefulSet / Deployment ○ podをまとめて管理するツール ○ StatefulSetはディスクの状態を保持する ○ Deploymentはディスクの状態を保持しない ● Pod ○ コンテナを動かすセット 通信系 ● Service ○ k8s内での通信を経由するためのリソース ● Ingress ○ k8s外部との通信を設定するためのリソース ディスク系 ● PersistentVolume ○ ディスクを永続化するためのリソース ● PersistentVolumeClaim ○ PersistentVolumeの利用請求をするためのリ ソース 設定系 ● ConfigMap ○ Config相当の設定ファイルを管理するため のリソース ● Secret ○ 秘匿性の高い設定ファイルを管理するため のリソース。ただbase64で簡易な可逆エン コード オートスケール系 ● HorizontalPodAutoscaler ○ 水平オートスケール用のリソース ジョブ系 ● Cronjob ○ Cronjobを動かすリソース

12 フルノードもGKE(Google Managed Kubernetes)で動かす Kubernetes cluster 動かす利用 ● ストレージ管理やサービスディスカバリーなどのオーケストレー ションが容易 ● SHIEDLの他アプリケーションもGKEで管理しており、k8sで管理 すると監視の点でも一元化できて楽 ● 今後も通貨を増やすことを想定して、Infrastructure as a codeと して実行構成を保存できる ● Kubernetesで管理する事でポータビリティ担保 ●

13 ブロックチェーンのフルノードとは ● P2Pで他ノードと繋がり、全てのブロック、トランザクショ ンデータを同期する ● 初回の同期は稼働開始から現在までのデータを落とし てくるので、時間がかかる事が少なくない ● 各種configファイルによってポート番号やWallet機能を 使うかなどが定められる ● 各種チェーンによって必要なディスク容量が異なる。 BTCで250GB程度必要だが、MONAは15GB程度で 足りる

14 ● deployment / statefulset pod運用で利用する ● PersistentVolume / PersistentVolumeClaim 同期データを永続化して利用するためのリソース ● ConfigMap / Secret bitcoin.confなどconfigを管理するためのリソース フルノード運用でよく使うリソース

15 PersistentVolumeリソースで”gcePersistentDisk”のGCEの外 付けディスクを指定してResizeしやすいようにする 外付けディスクのバックアップ稼働で復旧可能なオペレーション を整える nodeSelectorで動かすnodeプールを指定。nodeプールは machine-typeを指定したノードインスタンス群 過去データを保持するためディスク使用量は増え続ける ParityなどRocksDBを使うブロックチェーンはインデックス が脆く、復旧できない事がある 各ノードによって必要なスペックが異なる。MONAは低ス ペックで良いがETHは高スペックなど ブロックチェーンノード特有の点とGKEで対応した内容 特有なところ GKEでの対応

16 ● 学習コスト < 削減できる運用コスト ● マネージドなので初期設定が楽 ● Infrastructure as a codeのため、近しい種類のノードは yml設定を変えるだけで簡単に追加できる ● kubernetesが元々Googleの社内プロジェクトだからか、 kubernetesでGCP上のリソースを使うオプション が多く用意されていて楽 ● アプリ間の通信も含めて一括で管理できる ● 予期せぬ事が起こってもとりあえずオートヒーリングしてくれる GKEでやってよかったところ

17 おまけ：オートスケーリングの負荷テストによかったツールvegeta ● `vegeta attack`で負荷をかける ● `vegeta plot`でattackの結果をプロット出力 ○ レイテンシ速度 ○ HTTPのレスポンスコード などのプロットもコマンド一つで出力

18 まとめ：少ないコストで早めに開発、拡張できるようにインフラを整備した ● SHIEDLは少人数スピード開発かつ、エンジニア以外も関わりやすいように、 CI/CD整備で業務の一 部を自動化 ● 運用コストの削減や、今後の対応通貨を効率的に増やすためにブロックチェーンノードは GKEでイン フラ管理した

19