2016/03/17

1. 社内の画像変換サーバーを
Goで置き換えた話
@ieee0824

2. プロフィール
ID/ ieee0824
かく言語
趣味 / C, C++, Go, x86 asm
仕事 / JavaScript, PHP, Ruby
エディタ/ Viぽい動きする何か
株式会社リブセンス/転職会議エンジニア

3. やったこと
社内に存在していた画像変換サーバーを
Go言語で置き換えました

4. 置き換えの動機
昔からある画像サーバを見てテンション上が
らない
PHP + imagemagickである
全社的に使ってるものから画像サーバーを切
り離したい

5. Go言語は良い落とし所だっ
た
CPU処理がボトルネックになりそうなところ
リクエストが沢山飛んで来る
レスポンス速度を要求される
CPUの処理が多い
他にもいろいろといいところが

6. いろいろな利点
コンパイル言語なので速い
それなりの量のリクエストにも耐えやすい
ネットワーク関連のpackageが多い
サーバーアプリを書きやすい
画像処理がGo言語のみでも十分行える
画像formatを気にしなくてもだいたい扱える

7. いろいろな利点
曖昧な文法が少ない
C/C++のような闇のコードが生まれにくい
型が違うと必ずcastが必要
クロスコンパイルが優秀
mac上で開発してLinuxのバイナリを出したりとかが簡単
割り込みっぽい処理も書きやすい

8. いろいろな利点
Gopherくん可愛い
mattnさんの熱意の伝わる資料
“http://qiita.com/mattn/items/b7889e3c036b
408ae8bd”

9. ところで転職会議の画像事情は
1ページ開いた時の画像は地味に多い
1ページ開くごとに20~50枚くらい画像を処
理する
それを毎回リサイズしている
次の日にキャッシュが使えない可能性もあ
る

10. 主な仕様
ロードバランサーにAWSのELBを使う
cacheとしてnginxを使う
アプリケーションをGoでかく
Circle CI + CodeDeployでdeployをする
負荷がかかったらauto scaleされる
ストレージの代わりにS3を使う

11. だいたいこんな感じ

12. だいたいこんな感じ

13. Goで主にやった処理

14. Goで画像を開く
jpeg, PNG, gif, bmp, webpが扱える
image.Decodeを使えばだいたい開ける
ヘッダーとか壊れてると開けないけど
imagemagickはなんとかしてくれてた
なんか問題ありそうだったら今後どうにかする
確率低いから良いのではないかという割り切り

15. Goで画像を処理する
go-libjpegとか使えば速い
今回はデコードがボトルネックじゃないので標準のimage/jpegを使う
resizeはntftのLanczos3を使った
vipsthumbnail使えば速くなっただろうが特に問題にもならなかったの
で使わなかった
何も気にせず動くほうが嬉しい
アス比を維持してリサイズする処理とかは自分で書いた

16. nfnt/resizeは優秀である
“github.com/nfnt/resize”を使った
有名どころのアルゴリズムが困らない
NearestNeighbor
Bilinear
Bicubic
Lanczos2、Lanczos3

17. S3にデータを投げる
社内データサーバーとS3のデータの同期
“github.com/aws/aws-sdk-go”使ってNASからS3にデータを投げるの
を書く
管理が自分の部署じゃないサーバーでも外でコンパイルしたバイナ
リ１個設置するだけなので楽である
転送速度が上がり過ぎないように制御しながらデータを投げた
送った量を監視しながらゴルーチンとタイムアウトを使って制御し
た

18. 設定ファイルを定義する
設定ファイルを素jsonだけで書くのは辛い
apache.confみたいにimportとかやりたい
作った
“https://github.com/ieee0824/configure”

19. github.com/ieee0824/configu
re
{
"hoge":"hage",
"include":[
"confiugre0.json",
"confiugre1.json",
"./foo/confiugre2.json",
"/bar/confiugre3.json",
]
}
keyにinclude指定すると設置した場所のjsonも含めれる

20. 困ったこと1
ただ後々にViperといういいものがあること
に気がつく
“https://github.com/spf13/viper”
jsonだけでなくyamlも扱える

21. logの扱い
標準のlog packageが貧弱
logrusを使うがそれでも貧弱
warningをerrorで上書きしたい時とか
ちょっとだけ自分で拡張する
logrotateのことを考えてないとfileをどうやってcloseするか悩むこと
になる
copytruncateで対処

22. その他やったこと
作ったサーバーがちゃんと動くか適当なURL
にアクセスして叩くクライアント
負荷試験をやりたかったのでベンチマーク用
controllerとnode
通信周りをチャネルにほとんど任せたので
細かい制御とかに関して手を抜けた

23. Goでやらなかったこと
アプリケーションのデーモン化
upstartに任せました
キャッシュとかの処理
nginx素晴らしいから書かなくていいやん

24. 感想
Go言語的なところで困ることは意外に少ない
やりたいことのpackageがだいたいある
自分が仕込んだバグとか意外では今のところ問題が
起こってない
Go言語は自分でなんでも書くイメージがあるが意
外と部品が揃ってて作る部分が少ない

25. おわり