Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
SHIEDLにおけるGKE, CircleCIを活用したサービス、フルノードの基盤開発 / S...
Search
Nao Hanamura
September 25, 2019
Technology
1
720
SHIEDLにおけるGKE, CircleCIを活用したサービス、フルノードの基盤開発 / SHIEDL-blockchain-full-node-infrastructure
2019/9/25に話した、GKEとCircleCIを使ったSHIEDLのインフラ開発の発表資料です。
Nao Hanamura
September 25, 2019
Tweet
Share
More Decks by Nao Hanamura
See All by Nao Hanamura
PMFを生み続ける意志力 #pmconf2022
naomasabit
6
11k
寄り道禁止!LayerX インボイスの爆速開発を支えるロードマップ作り / how-to-create-layerx-invoice-roadmap
naomasabit
7
26k
デジタル空間でのブロックチェーン応用事例 / Blockchain use cases in digital space
naomasabit
0
700
DEXのデータを分析してインサイトを掘り出す / DEX Analysis
naomasabit
1
1.1k
セキュリティインシデント事例とブロックチェーンモニタリング・分析サービスcatabiraのご紹介 / Case of security incidents of cryptocurreny and introduction of blockchain monitoring and analysis service "catabira"
naomasabit
0
800
Yellow Paper から読み解くEthereumブロックチェーンの詳細仕様 / Reading out specifications from Ethereum Yellow Paper
naomasabit
10
11k
有名なスマートコントラクト脆弱性・ハックについての復習 / Widely known vulnerability of smart contract
naomasabit
2
1.3k
ブロックチェーンサービスのセキュリティを考える
naomasabit
12
8.2k
Other Decks in Technology
See All in Technology
伝わるコードレビュー
abenben
1
100
DynamoDB のデータを QuickSight で可視化する際につまづいたこと/stumbling-blocks-when-visualising-dynamodb-with-quicksight
emiki
0
140
クラウドネイティブ環境の脅威モデリング
kyohmizu
1
400
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
7
63k
Computer Use〜OpenAIとAnthropicの比較と将来の展望〜
pharma_x_tech
6
1k
Why Platform Engineering? - マルチプロダクト・少人数 SRE の壁を越える挑戦 -
nulabinc
PRO
4
370
MySQL Indexes and Histograms – How they really speed up your queries
lefred
0
160
Part2 GitHub Copilotってなんだろう
tomokusaba
2
750
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
5.5k
C++26アップデート 2025-03
faithandbrave
0
1.2k
Part1 GitHubってなんだろう?その2
tomokusaba
2
720
グループ ポリシー再確認 (2)
murachiakira
0
230
Featured
See All Featured
Build The Right Thing And Hit Your Dates
maggiecrowley
35
2.7k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
A designer walks into a library…
pauljervisheath
205
24k
Visualization
eitanlees
146
16k
Rails Girls Zürich Keynote
gr2m
94
13k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
780
Measuring & Analyzing Core Web Vitals
bluesmoon
7
420
A Tale of Four Properties
chriscoyier
159
23k
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.2k
The World Runs on Bad Software
bkeepers
PRO
68
11k
Why Our Code Smells
bkeepers
PRO
336
57k
Transcript
1 SHIEDLにおけるGKE/CircleCIを活用した サービス、フルノードの基盤開発 2019/9/25 Naochika Hanamura
2 自己紹介 名前:花村直親(@naomasabit) 経歴: ITコンサル・エンジニア => データアナリスト / ブロックチェーンR&D /
エンジニアリード => ブロックチェーンスタートアップ共同創業(catabira) => ITコンサル・エンジニアでフリーランス [最近よく使うもの] Go, Python, Solidity, Kubernetes, Ethereum フリーランスのブロックチェーンエンジニアとして BUIDLを手伝っています 「ブロックチェーン×分析」のプロダクト開発に関わるのは3度目 やってきたこと:
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