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
760
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
27k
デジタル空間でのブロックチェーン応用事例 / Blockchain use cases in digital space
naomasabit
0
720
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
830
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
【NoMapsTECH 2025】AI Edge Computing Workshop
akit37
0
230
20250913_JAWS_sysad_kobe
takuyay0ne
2
250
Evolución del razonamiento matemático de GPT-4.1 a GPT-5 - Data Aventura Summit 2025 & VSCode DevDays
lauchacarro
0
210
エンジニアが主導できる組織づくり ー 製品と事業を進化させる体制へのシフト
ueokande
1
100
Snowflake×dbtを用いたテレシーのデータ基盤のこれまでとこれから
sagara
0
120
S3アクセス制御の設計ポイント
tommy0124
3
200
Generative AI Japan 第一回生成AI実践研究会「AI駆動開発の現在地──ブレイクスルーの鍵を握るのはデータ領域」
shisyu_gaku
0
330
開発者を支える Internal Developer Portal のイマとコレカラ / To-day and To-morrow of Internal Developer Portals: Supporting Developers
aoto
PRO
1
480
[ JAWS-UG 東京 CommunityBuilders Night #2 ]SlackとAmazon Q Developerで 運用効率化を模索する
sh_fk2
3
460
共有と分離 - Compose Multiplatform "本番導入" の設計指針
error96num
2
1.1k
Aurora DSQLはサーバーレスアーキテクチャの常識を変えるのか
iwatatomoya
1
1.2k
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
8.8k
Featured
See All Featured
Designing for humans not robots
tammielis
253
25k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
530
YesSQL, Process and Tooling at Scale
rocio
173
14k
Site-Speed That Sticks
csswizardry
10
820
Docker and Python
trallard
46
3.6k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
36
2.5k
Intergalactic Javascript Robots from Outer Space
tanoku
272
27k
GitHub's CSS Performance
jonrohan
1032
460k
Documentation Writing (for coders)
carmenintech
74
5k
Facilitating Awesome Meetings
lara
55
6.5k
Side Projects
sachag
455
43k
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