バッチをGoにリプレイスして高速化した話 / GoGoGolangEdition!

by yuma iwasaki

Slide 1

Slide 1 text

バッチをGo にリプレイスして高速化した話株式会社Speee エンジニア岩崎裕馬 (@suthio_) バッチをGo にリプレイスして高速化した話

Slide 2

Slide 2 text

自己紹介岩崎裕馬（@suthio_）趣味はおいしいお店探し株式会社Speee でネイティブ広告の配信システムを開発 2

Slide 3

Slide 3 text

アジェンダ Go の良いところを紹介移行の背景パフォーマンスチューニングおまけまとめ 3

Slide 4

Slide 4 text

Go の良いところを少しだけ紹介 4

Slide 5

Slide 5 text

Slide 6

Slide 6 text

実行ワンバイナリで実行可能 scp で送るだけでどこでも実行可能 - ライブラリの依存などを考える必要がない高速な実行速度 6

Slide 7

Slide 7 text

開発言語仕様がシンプル型安全性コンパイルが早い並列/ 並行処理が行いやすい 7

Slide 8

Slide 8 text

移行した話 8

Slide 9

Slide 9 text

結果から先に共有 9

Slide 10

Slide 10 text

移行前 10

Slide 11

Slide 11 text

移行後 11

Slide 12

Slide 12 text

移行前 12

Slide 13

Slide 13 text

移行後 13

Slide 14

Slide 14 text

移行前のバッチについて Amazon EMR(Spark) を使用 Spark（Scala）を実行 14

Slide 15

Slide 15 text

移行後のバッチについて EC2 Container Service（ECS）を使用 Go のバッチアプリケーションを実行 15

Slide 16

Slide 16 text

移行前のバッチが抱えていた課題遅い 10 時間ぐらいかかる高い r4.2xlarge インスタンスを12 台（6 台 × 2 クラスタ）で運用 0.64 * 720 * 12 = 5529.6 ドルローカルで実行しずらいよく失敗している原因不明のものが多数修正しずらい雰囲気 16

Slide 17

Slide 17 text

移行する際に求めたこと高速安価ローカルで実行可能失敗時の原因究明が容易 17

Slide 18

Slide 18 text

パフォーマンスが良くて、ローカルでも実行が簡単でエラーが起こった際も復旧しやすいバッチが求められた 18

Slide 19

Slide 19 text

パフォーマンスチューニング並列化アルゴリズム最適化データ量の削減 19

Slide 20

Slide 20 text

パフォーマンスチューニングを行う際に大切な考え方コンピューティングリソースを使えきれているかどうか CPU リソースを使い切れるようにするディスクIO、ネットワークIO で詰まらせない計算量は必要最小限となっているかどうか適切なアルゴリズムを使って計算量を減らす不必要なオブジェクト生成や計算は極力減らす 20

Slide 21

Slide 21 text

並列化実行単位が細かく分けられることがわかったため、実行単位ごとに並列で処理を行うようにした通信処理の並列化 21

Slide 22

Slide 22 text

アルゴリズム最適化アプリケーション内でデータのJoin が多く発生していたのでそういった処理をO(1) でできるように多くのデータをMap で保持して使用できる形に修正事前に使用するメモリサイズを予測し、メモリを確保ループ処理を削減（関数っぽく書かない） 22

Slide 23

Slide 23 text

データ量削減 Input のデータサイズ削減不要なデータが含まれていたので削除 Output データサイズの削減圧縮してSQS に送信（DynamoDB にも圧縮して保持）使う際に解凍するようにした 23

Slide 24

Slide 24 text

圧縮について圧縮にはSnappy を使用 http://s-yata.jp/docs/snappy/ 今回のデータを圧縮した結果、圧縮率は0.783 だったので、 35KB が7.6KB のデータになったデータ自体を圧縮したことにより、結果的にDynamoDB のRead、Write のCapacity がより少ない状態でも動作するようになり、コスト削減に繋がった 24

Slide 25

Slide 25 text

移行する際に求めたこと早い安いローカルで実行可能失敗時の原因究明が容易 25

Slide 26

Slide 26 text

結果早い：実行時間は1/10 安い：サーバー台数は1/6（5529.6 ドルから921.6 ドルに削減）ローカルで実行可能：簡単にできるようになった失敗時の原因究明が容易：今のところ困ったことはない 26

Slide 27

Slide 27 text

おまけ 27

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Lambda のバッチについて SQS のデータを定期的にDynamoDB にPut するだけのバッチ Python で実装 29

Slide 30

Slide 30 text

起こった問題 Lambda を使って、DynamoDB へのPut 処理を行っていたが IO で詰まり、DynamoDB のWriteCapacity を余らせてしまっている状態となっていた今回のバッチを高速化したために、次のボトルネックとなった 30

Slide 31

Slide 31 text

Lambda のバッチもGo 化しよう！！！ 31

Slide 32

Slide 32 text

Lambda のバッチをGo 化 Lambda 上でGo を実行 Go はワンバイナリなので、NodeJS から実行ファイルをキックするだけで実行可能 IO でネックが発生していたので、並列処理が得意なGo を使うことにより、解決ローカルでテストしやすい 32

Slide 33

Slide 33 text

まとめ処理時間が長くなりがちなバッチは特にパフォーマンスを意識コンピューティングリソースを使えきれているかどうか計算量は必要最小限となっているかどうか今回のようなバッチではパフォーマンスチューニングがしやすく、並列処理が得意なGo を使うのは良い選択だった 33