Whimlog

寝るまでが一日

Furichan でふりかえろう

これはなに?

僕が作った週次ふりかえりgem Furichan の紹介と活用方法についてです。

github.com

Furichan とは

もともと futik を使って日々の記録は付けていたのですが、ディレクトリを作ってファイルを作って、ファイルに furik の出力結果を貼ってという作業がだんだん煩わしくなってきました。 その次に活用したのが Raketask だったのですが、コマンドが多くなってきたのでいい感じにまとめたくなり作成ししたのがこの furichan になります。

その週に行なった GitHub, GH:E の活動(issue, PR)をまとめて出力してくれる便利な gem です。以下の画像のようなフォーマットで出力してくれます。(Keep, Problem の内容は手入力)

f:id:asuforcegt:20180209133040p:plain

週に行なった事を見ながら Keep, Problem を書き出し保存するだけで、自分の活動記録をつけることができます。

Furichan は furik に依存しているライブラリなので、そちらの設定をすると使えるようになります。 furik については以下の記事をご覧ください

tech.pepabo.com

おすすめの使い方

Furichan は金曜日に使うと一週間分の記録がうまく取れるようになってるので、毎週金曜日の使用をおすすめします。

  1. 適当な場所にリポジトリを作る
    • GH:E 使ってる人はそちらで
  2. $ gem install furichan
  3. furik の設定をする
  4. $ furichan

これでディレクトリ、ファイルの作成からトピックブランチの作成まで行われます。

コマンド群はこのような感じです

Commands:
  furichan furichan        # Create file and write about this week's reflection
  furichan furik           # write stdout this week's furik
  furichan help [COMMAND]  # Describe available commands or one specific command
  furichan init            # initialize of week setting
  furichan reflection      # write file about this week's furik

どう活用できるのか

日々の記録をつけるのもよし、評価資料をいい感じにするために使うのもよしです。 僕は毎週毎の記録をまとめるリポジトリを作って1ヶ月毎にまとめて評価資料に実績を書くという流れを作ってます。 まだまだ足りない機能も多いと思うので、要望 or PR お待ちしております〜

ファイルの分散配布に挑戦した 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 を導入してみてはいかがでしょうか?