Whimlog

寝るまでが一日

ファイルの分散配布に挑戦した tuggle 完結編

GMOペパボ Advent Calendar 2017の12日分のエントリーになります。

 

どうも!本日は分散デプロイについての記事になります。2年目氏のスンがお送りいたします。

今年最大のバリューは自分の担当サービスに分散デプロイを導入したことだと思うので、ふりかえりも兼ねて紹介します。書こうと思っていたのですが、なかなか筆が進まなかったです。デプロイを高速化したいという方にぜひご覧いただきたいです。

挫折

僕の上期の目標は、デプロイの高速化でした。下記の資料をご覧いただくとわかるのですが、色々挑戦した後、ファイルの分散配布への挑戦を行い挫折しました。その時導入を検討したのが @fujiwara さんが作成した、 tuggle というプロダクトでした。

 https://speakerdeck.com/asuforce/distributed-deployment

資料をご覧いただくとわかるように、プライベートクラウドの母艦のネットワーク負荷が上がり、ファイルの配布をするにつれて帯域を圧迫する問題が発生しました。その結果、配布待ちのノードがリトライを諦め、次々に fail するという事態になりました。この時は十分な対策ができなかったので導入は見送りました。

tuggle とは

sfujiwara.hatenablog.com

 

この記事に書いてあるように、 consul クラスタ内での分散配布を実現するプロダクトです。stretcher の src に tuggle のエンドポイントを指定すると、親ノードがファイルを配布。ファイルを取得したノードは、取得後に配布ノードに切り替わるという便利プロダクトになります。

fujiwara さんの協力

上記のスライドを Twitter で共有したところ、 fujiwara さんからレスポンスをいただき、更に fetch-timeout というオプションを追加していただきました。リトライのデフォルトが10分になりました。

github.com

 

このオプションと、fetch-rate オプションによる帯域制限、プライベートクラウドの flavor に帯域制限による設定で再検証することになりました。

50 台までは捌けることがわかったのですが、全ての終了までに 30分かかりました。本番環境では倍以上のインスタンスに配布しなければならないのでこのままではデグレになってしまいます...1.4GB の tarball は予想以上に重いようです。

最後は物理で

このままではいかんと考えていた時、ちょうどプライベートクラウドSSD 搭載母艦が追加されたのを思い出しました。デプロイ先の www インスタンスはサービスの構成的に I/O はそこまで必要ないロールだったので、HDD 搭載母艦が使われていました。

「tarball の書き込み処理が早くなれば高速化されないだろうか?」なんの根拠も無い考えでしたが、もうアイディアも残ってなかったので思い切ってやってみました。

条件は同じ50台で行なった結果、全ての終了までの時間が3分になりました。そこから思い切って 100, 150 台とインスタンスを増やしましたが、どれも 3分台に収まる好成績を残しました。

HDD, SSD 共にベンチマークを測定したところ、SSD は HDD の 6倍の read 1.7倍の write という結果になり、2017 年ですが SSD すげぇという意識が広まりました。

デプロイタイムも 50% カットという驚異的な成績を残すことができました。

まとめ

結局、物理かよ!という感じの結論になりましたが、この調査をフィードバックした結果、SSD 搭載母艦にマイグレーションしていくという一つのきっかけになりました。配属1年目だったこともあり、全ての調査、検証が貴重な経験になりました。今回は SSD による解決になりましたが、スイッチが 10G などであればこの問題は起きないでしょう。また配布物がもっと小さい場合も起きづらい問題だと思います。

tuggle が無ければこのような調査や認識を持つことができなかったと思います。開発者の @fujiwara さんと Twitter で直接やりとりができたことによって解決することができました。この場を借りて、お礼申し上げます。

複数のインスタンスへのデプロイ時間に悩まされている方、この機会に tuggle を導入してみてはいかがでしょうか?