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
闇のBashをGoに置き換える技術 / golang.tokyo #11
Search
nashiox
December 11, 2017
Programming
13
6.5k
闇のBashをGoに置き換える技術 / golang.tokyo #11
golang.tokyo #11 の発表資料です。
nashiox
December 11, 2017
Tweet
Share
Other Decks in Programming
See All in Programming
AWS re:Invent 2025参加 直前 Seattle-Tacoma Airport(SEA)におけるハードウェア紛失インシデントLT
tetutetu214
2
120
QAフローを最適化し、品質水準を満たしながらリリースまでの期間を最短化する #RSGT2026
shibayu36
2
4.4k
FOSDEM 2026: STUNMESH-go: Building P2P WireGuard Mesh Without Self-Hosted Infrastructure
tjjh89017
0
170
2026年 エンジニアリング自己学習法
yumechi
0
140
CSC307 Lecture 10
javiergs
PRO
1
660
それ、本当に安全? ファイルアップロードで見落としがちなセキュリティリスクと対策
penpeen
7
3.9k
今こそ知るべき耐量子計算機暗号(PQC)入門 / PQC: What You Need to Know Now
mackey0225
3
380
責任感のあるCloudWatchアラームを設計しよう
akihisaikeda
3
180
なるべく楽してバックエンドに型をつけたい!(楽とは言ってない)
hibiki_cube
0
140
OCaml 5でモダンな並列プログラミングを Enjoyしよう!
haochenx
0
140
CSC307 Lecture 09
javiergs
PRO
1
840
AI時代のキャリアプラン「技術の引力」からの脱出と「問い」へのいざない / tech-gravity
minodriven
21
7.4k
Featured
See All Featured
What does AI have to do with Human Rights?
axbom
PRO
0
2k
The agentic SEO stack - context over prompts
schlessera
0
640
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
254
22k
Building a A Zero-Code AI SEO Workflow
portentint
PRO
0
320
The State of eCommerce SEO: How to Win in Today's Products SERPs - #SEOweek
aleyda
2
9.6k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
12
1k
Principles of Awesome APIs and How to Build Them.
keavy
128
17k
We Are The Robots
honzajavorek
0
170
Producing Creativity
orderedlist
PRO
348
40k
Claude Code のすすめ
schroneko
67
210k
Crafting Experiences
bethany
1
49
Building a Modern Day E-commerce SEO Strategy
aleyda
45
8.7k
Transcript
闇のBashをGoに 置き換える技術 @nashiox 2017/12/11 golang.tokyo #11
@nashiox 水野 拓 (Taku MIZUNO) - インフラエンジニア@リブセンス - オンプレ/クラウドのサーバ構築・運用 -
Go歴 - 約3年 - 最近のGo実装 - Mackerel プラグイン - Packer プラグイン
身の回りにこんなスクリプト ありませんか?
怖くて触れないけどなぜか 動いているBashスクリプト
インフラ運用に携わるとよく見かけます - 運用で利用するシェルスクリプト - 長い間メンテナンスされてない - メンテナーがいるかすらわからない - 読み解ける人がいない -
怖くて触れないけどなぜか動いている - Ex - サーバ構築スクリプト - 便利CLI - バッチスクリプト
リブセンスにもありました
10年を超える運用で積み重なった闇 - なにがどこで行われてるかわからない - けれどなぜか動いてる - それを実行しないと仕事にならない - どこを直せば良いのかすらわからない -
作成者はすでにいない - etc…
10年を超える運用で積み重なった闇 - なにがどこで行われてるかわからない - けれどなぜか動いてる - それを実行しないと仕事にならない - どこを直せば良いのかすらわからない -
作成者はすでにいない - etc… 闇を感じていただけたでしょうか?
気合を入れて直しています
リブセンスの場合 - 積み重なった闇のBash群 - サーバ構築スクリプト - Bash -> Chef ->
Ansible と変遷 - 便利CLI - PythonやGoに置き換え - バッチスクリプト - Goに置き換え
リブセンスの場合 - 積み重なった闇のBash群 - サーバ構築スクリプト - Bash -> Chef ->
Ansible と変遷 - 便利CLI - PythonやGoに置き換え - バッチスクリプト <- 今日はここの話 - Goに置き換え
強敵のバッチスクリプト
その名も開発DB構築スクリプト
こんな動作をします
10 ファイル 2128 行におよぶ Bashスクリプト
※ 事実ではありません
読めるわけがない
スクリプトの動作 - データ加工 - 元データのリストア - 並行で加工処理 - ダンプ -
データ加工後のデータをテーブルごとに並行でダンプ - DBを一度に作れるフルダンプも生成 - インポート - フルダンプからの開発DB生成 - 日次更新が必要なテーブルを並行で部分インポート
他にはこんなことをしています - 失敗した時点から再実行するためのファイルキュー - Bashで書かれたファイルキュー実装 - それを利用したリトライ処理 - GNU parallel
を使った並行実行 - データ加工 - ダンプ - インポート
※ 事実ではありません
読めるわけがない
よしGoに置き換えよう 読めるわけがないと言ったが読むしかない
Goの選定理由 - 並行実行の実装が容易 - Goroutineを使うだけで並行処理の実装が可能 - バッチなのでGoroutineのコストを気にしなくていい - Goの言語仕様のシンプルさ -
実装も利用するのもインフラエンジニア - コードを書くことが本職ではない - 複雑な実装が出来るよりも制約されるほうがいい - go testが言語仕様に組み込まれてるのもよい - IDEが使える - 補完・コードジャンプは重要
リプレースの方針 - いきなり全部Goに置き換えない - 読み解ける範囲、置き換えやすいところから - 難しいところはos/execでのBashの実行を許容 - Goらしさよりもまずは読み解けることを優先 -
置き換え中はBashっぽくなることを許容 - 徐々にGoらしく置き換えていく
ファイルキュー実装(Bash版)
ファイルキュー実装(Go版)
並行実行実装(Bash版)
並行実行実装(Go版)
Bash実行 - パイプ・リダイレクトに対応するためbash -cを使用
Bash実行(ログつき)
最近ハマった - io.MultiReader() は複数Readerの”連結” - stdoutとstderrを時系列順でログに吐きたかった - “連結”なのでstdoutがcloseされてからstderrを書く - stdoutがほとんど出ないコマンドを実行していた
- 実行後30分ほどたってドバっとログが吐かれた
初回リプレースから約9ヶ月 - 動作は順調 - 問題なく動いています - 開発・リプレースも順調 - 現在 v0.0.8
- 読める・手を入れやすくなったため、変更が容易 - 外部コマンドに頼っていた部分もリプレース開始 - ダンプ・インポート部分(mysqldump) - Pure Goで実装してOSSとして出すつもり - (今日に実装間に合わなかった)
まとめ - 闇のBashをGoに置き換えたのは良い選択だった - 読みやすい・書きやすいことは大事 - 無理に全部置き換えようとしないのはもっと大事 - Goroutineのパワーすごい -
1バイナリになるので管理も楽 - 最近自前RPM化もした - メンテナンス出来るって素晴らしい - 動き続けてても放置はダメ - 先々を考えた技術選定も大切