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.3k
闇のBashをGoに置き換える技術 / golang.tokyo #11
golang.tokyo #11 の発表資料です。
nashiox
December 11, 2017
Tweet
Share
Other Decks in Programming
See All in Programming
ATDDで素早く安定した デリバリを実現しよう!
tonnsama
1
1.9k
“あなた” の開発を支援する AI エージェント Bedrock Engineer / introducing-bedrock-engineer
gawa
3
130
Lookerは可視化だけじゃない。UIコンポーネントもあるんだ!
ymd65536
1
130
サーバーゆる勉強会 DBMS の仕組み編
kj455
1
300
php-conference-japan-2024
tasuku43
0
430
Flatt Security XSS Challenge 解答・解説
flatt_security
0
730
return文におけるstd::moveについて
onihusube
1
1.4k
Fibonacci Function Gallery - Part 2
philipschwarz
PRO
0
210
Alba: Why, How and What's So Interesting
okuramasafumi
0
210
QA環境で誰でも自由自在に現在時刻を操って検証できるようにした話
kalibora
1
140
BEエンジニアがFEの業務をできるようになるまでにやったこと
yoshida_ryushin
0
200
週次リリースを実現するための グローバルアプリ開発
tera_ny
1
1.2k
Featured
See All Featured
Designing for humans not robots
tammielis
250
25k
Building Adaptive Systems
keathley
38
2.4k
Designing for Performance
lara
604
68k
The Invisible Side of Design
smashingmag
299
50k
How GitHub (no longer) Works
holman
312
140k
The Cost Of JavaScript in 2023
addyosmani
46
7.2k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
3
240
Git: the NoSQL Database
bkeepers
PRO
427
64k
Agile that works and the tools we love
rasmusluckow
328
21k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Become a Pro
speakerdeck
PRO
26
5.1k
Why Our Code Smells
bkeepers
PRO
335
57k
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化もした - メンテナンス出来るって素晴らしい - 動き続けてても放置はダメ - 先々を考えた技術選定も大切