wtatsuru's blog

id:wtatsuru のメモ

ISUCON5 予選通過しました

ISUCON5 予選に参加し、無事に決勝に進むことができました。今年は、社内で id:motemen id:ichirin2501 と、 2nd Party Cookies というチームで出場しました。id:motemen がアプリ、id:ichirin2501 はアプリ / DBまわり、自分はインフラ全般を担当しました。結果は総合10位で決勝進出ですが、同じく社内若手エンジニアのチーム「はむちゃん」に負けてしまって悔しさいっぱいです。

やったこと

  • 事前準備として、分析等の環境整備用セットアップスクリプト、nginx / slowlog の解析準備、ミドルウェアよくある設定復習、デプロイ雛形あたりまではやって臨む。
  • 最初1時間とってた準備時間でサーバ構成を把握して、サーバ環境整備+最初のログ取得・解析。2台立てて1台はsandbox化。
    • 普段あまり使っていない systemd でちょっと手間取る。
    • ログの分析結果とサーバリソース・使用状況を見つつ作戦会議。
  • リクエストに加えてベンチマーカーの特性も観察する。
    • ヘッダにルーティング情報入れて、alp で URL ではなくそちらで分析できるようにしたのではかどる。
  • あとは MySQL, nginx, Plack あたりのチューニングをちまちま。/etc/my.cnf がダミーとは..。
  • 昼過ぎくらいで一通り終わったので、やり残しを消化しながらクエリを見たり再起動対策したり。このへん、細かめの施策で時間を潰してしまいがちだったかも。
  • 最後に再起動試験と変更コストの大きな変更トライ、そしてベンチマークガチャ。

振り返る

予選は堅実にやろうと考えて、ある程度の事前準備はやる、使ったことないものはなるべく使わない・副作用のありそうなことは必要に応じて最低限、という原則で臨みました。最低限の役割は果たせたと思いますが、攻めが足りなかったことと、もっとやりたいけど知見が足りなくて手を出せていない部分が少し残ってしまった感じがあったので反省です。とくに、普段使わないけどISUCONでは必要になるノウハウあたりはもう少し手を動かしておこうかなと思っています。

冒頭にも書いた通り若手に負けて悔しいというのは本当に大きいのですが、ISUCON3以来の出場でチーム数見てびびってた身としては、決勝進出できて若干ほっとしている部分があります。少し自信戻ったし、優秀なチームメイト2人もいるので、ぜひ優勝狙っていきたいと思っています。

運営の皆様、この規模は本当に大変だと思います。ありがとうございました。手ごたえのある問題、快適なベンチマーカーもよかったです。決勝も期待しています。

こちらもどうぞ

アプリとクエリ改善の戦略などは motemen さんのエントリにまとまっています。
ISUCON5 予選通過したが若手に負けました #isucon - 詩と創作・思索のひろば

はてなにおけるサーバリソース可視化とMackerel

こんにちは。id:wtatsuru です。
この記事は はてなエンジニアアドベントカレンダー2014 の19日目です。昨日は、 id:hakobe932 による golangで書かれたSlack bot でエンジニアに話題提供しよう - はこべブログ ♨ でした。
今日は、Webサービスのシステム運用において不可欠なサーバリソース可視化の、はてなにおける運用の簡単な紹介をします。

はてなとサーバ管理ツールと可視化

サーバを運用する上で、日頃のサーバのリソース等の可視化と監視は必要不可欠なものです。その対象はCPU使用率やメモリ使用量などのOSレイヤから、ミドルウェアプロセス状況、レスポンスタイムまで多岐にわたります。このデータを蓄積しておくことで、システムの状態を正確に把握し、問題に対処することが可能となります。*1

f:id:wtatsuru:20141219200526p:plain

はてなでは以前から、内製のサーバ管理ツールでサーバの管理を行っていました。サーバが作られると中央の管理ツールに登録され、その役割から必要な情報を自動で取得・可視化する仕組みを作っていました。
はてな社内のサーバ管理ツールに関しては、id:y_uuki による以下のスライドが詳しいです。
YAPC::Asia 2013ではてなのサーバ管理ツールの話のはなしをしました - ゆううきブログ

システムが大きくなるほど、可視化の仕組みが大きくなるほど、気軽に新しいグラフを組み込むのが難しい、という課題が出てきていました。GrowthForecast 等の簡単に投稿・可視化できるツールを導入していたものの、やはりマスタ情報と一元管理された場所で見える、というメリットは捨てがたいものです。

Mackerelを使った可視化

f:id:wtatsuru:20141219200556p:plain

今年リリースされた Mackerel には、そんな可視化のノウハウも詰め込まれています。
Mackerel は標準のエージェントを入れるだけで基本的な情報は可視化されますが、さらに独自のカスタムメトリックを登録することが可能になっています。カスタムメトリック取得は、下記のようなSensu形式の出力をするコマンドを登録する形をとっています。

{metric name}\t{metric value}\t{epoch seconds}

これにより、スクリプトをさっと書いてとりあえず入れておき、必要であれば全体に展開する、などの柔軟な運用が可能となっています。

実際に使用している、「さっと書いた」プラグインはこのような感じになります。

f:id:wtatsuru:20141219200628p:plain


カスタムメトリックについて、詳しくはヘルプを参照してください。
ホストのカスタムメトリックを投稿する - Mackerel ヘルプ

公式プラグイン

ミドルウェアのメトリック可視化に公式プラグイン集を使う - Mackerel ヘルプ
公式プラグイン集には、はてなで実際に試用されているミドルウェアプラグイン等が取り込まれています。ここでは、「グラフの出力と定義を同時に配布できる」というもうひとつの特徴が試用されています。
はてなでも、基本的に全サーバにMackerelを投入しさまざまなメトリックを収集しております。
MySQL のグラフなど、ユースケースによってもっとこういうのが欲しい!というものがありそうなので Issue, Pull Request お待ちしております。

f:id:wtatsuru:20141219200653p:plain

プラグインの作り方に関しては、以下の記事がとてもわかりやすいです。
Mackerel プラグインを書いてみよう - インフラエンジニアway - Powered by HEARTBEATS

まとめ

以上、はてなでのサーバリソース可視化の運用の簡単な紹介でした。社内の運用にも Mackerel を使用しつつサービス運用・改善に取り組んでおります。
明日は id:sakahara さんです。よろしくお願いします!

*1:まあ単純にグラフが並んでいるとわくわくしますよね。

crontab の割り算と大きな数字

crontab にこんなのが書いてありました

*/120 * * * * $COMMANDS

書いた人は2時間おきに実行したかったんだと思いますが、まあうそっぽいですよね。
ちなみに crontab(5) には "steps" と書いてあります。

       Ranges can include "steps", so "1-9/2" is the same as "1,3,5,7,9".

ISC cron 3.0 の entry.c を観察。
まず * は最小から最大まで、と同じ意味。なるほど。

	if (ch == '*') {
		/* '*' means "first-last" but can still be modified by /step
		 */
		num1 = low;
		num2 = high;

で、num1-num2/num3 の形式で記述されてると num3 を step として単純に num1 から num2 まで増やしてる。大きすぎる数字を入れると一発目しか実行されない。

	/* range. set all elements from num1 to num2, stepping
	 * by num3.  (the step is a downward-compatible extension
	 * proposed conceptually by bob@acornrc, syntactically
	 * designed then implmented by paul vixie).
	 */
	for (i = num1;  i <= num2;  i += num3)
		if (EOF == set_element(bits, low, high, i))
			return EOF;

結論

大きな数字を書いても意味がない

Twitterでのやりとり

@songmu さんの言う通りの結論でした。

新しいReserved Instance

AWSの新Reserved Instanceの話です。

Amazon Web Services ブログ: 【AWS発表】EC2のリザーブドインスタンスモデルがシンプルに
購入オプションを見ると、Heavy Usage がなくなって焦ったのでがんばって追いつきました。こちらの記事がたいへん参考になりました。

Amazon EC2のリザーブドインスタンスで重度の購入オプション拡充&軽度/中度の廃止 | cloudpack技術情報サイト

どうなったのか

三行で

  • 従来の "Heavy Utilization" のみに集約された
  • 初期費用の払い方で、最初に一括・半分払って残りは月々・初期費用無し月額のみ、の3つのオプションあり。真ん中が従来のと同じ
  • インスタンス起動の有無に関わらず料金は同じ

感想

基本Heavyで買って、AutoScale な部分をどうするか、〜〜〜、これは人間が考えるものではない!!!という議論をしていましたが、過去のものとなりました。使う分だけ買いましょう。
リソース確保のためだけに light っていうやり方ができなくなりました(最近はそんなに困らなくなったんでしょうか)。料金面では、頑張らなくて良くなった分、頑張っていたよりは高くなることもあるかもしれませんね。

おまけ

こういうので表にしました https://gist.github.com/tatsuru/fd048d331135b00b30b0

multilog が作るディレクトリのパーミッション

ここで固定されてる。
https://github.com/daemontools/daemontools/blob/master/src/multilog.c#L312
damontools-toaster で堅いこと言うなよ、というパッチを当てたりする。よい子は真似してはいけない。

diff -Naur ./src/multilog.c ../daemontools-0.76/src/multilog.c
--- ./src/multilog.c    2014-09-16 15:52:28.654130526 +0000
+++ ../daemontools-0.76/src/multilog.c  2014-09-16 15:51:25.779141973 +0000
@@ -309,7 +309,7 @@
   if (fchdir(fdstartdir) == -1)
     strerr_die2sys(111,FATAL,"unable to switch to starting directory: ");
 
-  mkdir(d->dir,0700);
+  mkdir(d->dir,0755);
   d->fddir = open_read(d->dir);
   if ((d->fddir == -1) || (fchdir(d->fddir) == -1))
     strerr_die4sys(111,FATAL,"unable to open directory ",d->dir,": ");

Docker Index Trusted Build してみた

Docker Index の Trusted Build ってやつをやってみた。
tatsuru/ikachan Repository | Docker Index
やり方はこの辺に書いてある通り Docker Index Help Documentation and Support | Docker Index

  • まずは適当にリポジトリを作る tatsuru/docker-images · GitHub
    • Dockerfile 1枚のリポジトリが並ぶのは嫌だったので、ikachan/ 以下に Dockerfile と README を置く。
  • Trusted Build のページから適当に Build 追加。Github の hook が作られる。
  • 自動ビルドされるので、 build statusのページ を眺めるだけ
    • Build Queue ってのがあって、自分の場合は20分くらい時間がかかった。CI的に使うには向いてなさそう。
  • ビルドされたら Transfer Queue に入って転送される。これはすぐに終わった。

repository information には README.md と Dockerfile がうまいこと結合されたやつが入ってた。
公開用のビルドは全部これでやると、たしかに安心できる。もうちょっと速くなればなぁ。

ikachan docker image

Ikachan が動く docker image 作った。
tatsuru/ikachan Repository | Docker Index
ikachan 動かしたいことがたまにあるけど、モジュールが入らなかったりして面倒だったので公開 docker コンテナにしてさくっと動かすようにした。何かツールを動かしたい時も、一式全部 docker コンテナにしておくと何も考えなくてよくなっていいな。
docker push が耐えられないほど遅くて、しかもたまにこけるので、よく使うやつじゃないとやる気がでない。

はてなで一緒に働きませんか?