読者です 読者をやめる 読者になる 読者になる

ISUCON 6 予選通過しました

ISUCON 6 にチーム「morimoto組」で参加して、予選を通過して決勝進出することになりました。

ISUCONは過去5回のうち優勝3回、3位1回、出題1回、ということでもう引退(勝ち逃げ)しようかな…とも思ったのですが、今年は出題にも関わっていないので参加しないと完全に縁が切れてしまうし、それも寂しい。ということで。

チームメンバーは直前まで決まらなかったのですが、結局会社の新卒1,2年目( id:amusan , id:moshisora ) と組むことにしました。若いとはいえ去年と今年の社内ISUCON優勝メンバーです。(歳の差何歳だろう)

当日やったこと

天気は悪いが見晴らしはいい会議室を確保して万全の体制 (まぶしいのですぐブラインドは下ろされました)。

言語は Perl です。

  • インスタンス起動、事前に用意していたChefを実行して環境整備
  • isutar を isuda 内に取り込み
  • 正規表現の生成を Regexp::Trie に変更
    • 各プロセスで生成すると重いのと整合性を確保しづらいので、POST /(initialize|keyword) を処理するアプリケーションを1プロセスだけ起動するようにして分離。生成された正規表現を Redis に保存し、htmlify を処理するプロセスはその正規表現を使う
    • 1プロセスのみにしたので、keywordがpostされてきた順番に $trie->add($keyword) していくだけで整合性が維持できる
  • 静的ファイルは nginx で static_gzip、expires max を付与する
    • 304が返せるようになる

nginx.confはこんなかんじ。

 http {
    upstream app {
       server unix:/var/tmp/app.sock;
    }
    upstream app_post {
       server unix:/var/tmp/app_post.sock;
    }
    include /etc/nginx/mime.types;
    server {
        location ~ ^/(css|img|js|favicon\.ico) {
           gzip_static on;
           expires max;
           access_log off;
           root /home/isucon/webapp/public;
        }
        location /initialize {
            proxy_pass http://app_post;
        }
        location /keyword {
            set $app "app";
            if ($request_method = "POST") {
              set $app "app_post";
            }
            proxy_pass http://$app;
        }
        location / {
            proxy_pass http://app;
        }
  }
}

ここまでやった状態で14:40すぎに8万点ほどでトップに躍り出る。

ここで、アプリケーションのプロセスを再起動せずにベンチを回していくと、どんどんスコアが上がっていくという現象を確認。2回目だと12万点ぐらい。 特にメモリ内に cache は作っていない (つもりだった) ので、何が原因なのかさっぱり分からず。

ここから、他のチームがスコアを上げてきたのになかなか上げられず苦しむ時間帯。

  • / でoffsetが大きいクエリをentry using(id) の自己結合に
  • /stars を Resis にキャッシュ (get_multiで一気に取る)
  • uri_forを消す
  • user_nameもセッションに入れてクエリを消す
  • isupam は何とかできないかと考えたが結局手を入れられず

これでだいたい9万ぐらいだったので、このままだと予選通過はボーダー付近だった模様。

17:30ごろから2度目のベンチでスコアが上がる現象を解明するべく、個別にプロセスを再起動して切り分けしたところ、POSTを担当するプロセスを再起動しなければ速度が出る、ということを確認。こいつは Regexp::Trie のオブジェクトを永続化して持っているので、二回目は既に初回のベンチでキーワードが追加済みの状態になっていた (ので速かった)。

つまりこの状態では本来リンクになってはいないはずのキーワードがリンクになる状態。アプリケーションとしてはまずいんだけども、ベンチマーカーがそれを検出しても結果がPASSとされていればスコアも有効である、ということを運営とのやりとりで確認していたので、(多少良心が痛むものの) 突っ込むことに。

1回ベンチが走って追加された状態のキーワードをテキストファイルに書き出しておいて、initialize でそれを Regexp::Trie にaddしておくというコードを追加して、終了1分前にベンチqueue投入。18時の終了3秒前ぐらいにベンチが始まり、その状態で dstat をみていた限りでは14万点だしたときとおなじぐらい捌けてそう、というところで(最終的にスコアは知れずに) 競技終了。

結果、143,366で通過できました。

予選を終えて

チームメイト二人ともなぜか Perl-5.24 を手元で動かせずに、手元でコードの確認ができない状態だったのが完全に想定外 (環境構築で30分ぐらいハマってたので「もうそれは諦めて、こっちで動かすので」という判断を早めにできたのがよかった…)。それ以外は、結構ちゃんと戦えたのかな、という感想です。

聞くところによると、htmlfy()の結果cacheは結構雑でも (リンク関係を検出はされるものの) スコアが出せたようなので、ここがもっと厳密だったら展開も変わってきたのかなあ、という印象はあります。(とはいえ、一発アウトにするのは出題側も誤検知が怖いんですよね…)

幸いにも、これで ISUCON 本選は6年連続で出場できるので、精一杯戦いたいと思います。運営の皆様、楽しいイベントを本当にありがとうございます!

「みんなのGo言語」の執筆に参加しました

技術評論社から発行される「みんなのGo言語」という書籍の執筆に参加しました。本日、9月9日発売です!

gihyo.jp

みんなのGo言語【現場で使える実践テクニック】

みんなのGo言語【現場で使える実践テクニック】

Goと自分

Goは2009年に一番最初にリリースされたときにちょっと触っていて、このblogにもいくつかエントリを書いていました。 golang カテゴリーの記事一覧 - 酒日記 はてな支店

その後、実際にプロダクションで使うことがなかったのでしばらく離れていたのですが、 2013年頃からGoが盛り上がってるなという雰囲気もあり、

で、ここ数年はもっぱら Go をメインで書くようになっていました。公開している OSS としては

をはじめ、いろいろあります。Perlをメインで書いていたときも CPANに上げていたもの があるのですが、ほとんどがライブラリで、いわゆるアプリケーションは少数でした。

Goではライブラリよりもアプリケーションを多く公開するようになったのが面白いなと、今振り返って思います。これはGoが、デプロイのしやすいシングルバイナリで動作するアプリケーションを書くのに向いている、ということ無関係ではないでしょう。

執筆について

Go製の OSS をいくつか公開していたことからか suzuken (id:suzu_v) さん、id:mattn さん経由で声を掛けていただいて、共著で執筆することになりました。雑誌記事は WEB+DB PRESS に書いたことがあるのですが、書籍は初めての経験です。

自分がどういうことについて書けるかを考えた結果 (言語自体には特に詳しくもないですし)、Goでこれまで書いて、本番で運用してきた実用アプリケーションを作り上げることについてのTips的なことならば書けそう。ということで、本書では第3章の「実用的なアプリケーションを作るために」という内容で執筆させていただきました。

内容は本当にTips的で、最初に一通り書いたところではあまりに断片的すぎた感があったのですが、編集のかたや共著者のレビューでお力添えをいただいて、なんとかまとめることができました。

本書について

本書は、最初からGo自体の入門書ではなく応用のための実用書、という位置づけで書かれていて、どの章も現場でGoをつかって仕事をする人に役に立つ内容になっていると思います。A Tour of Go や プログラミング言語Go (ADDISON-WESLEY PROFESSIONAL COMPUTING SERIES) で言語自体を学んだ上で、実際になにかまとまったものを書き始める時に、よいお供になると思います。144ページと気軽に読める分量で、お値段も1980円(本体)と比較的安価ですので、是非お手にとっていただければと思います。

最後に

connpass.com

リリースパーティーを開いていただけるそうで、自分もビールを美味しく飲みにお邪魔する予定です。まだ定員に余裕があるようなので、こちらも是非よろしくお願いします。

WEB+DB PRESS vol.94 特集「実践スケーラブルAWS」を執筆しました

機会をいただいて、技術評論社 WEB+DB PRESS vol.94 の特集1「実践スケーラブルAWS」を同僚の id:tkuchiki と執筆しました。本日8/24発売です。

WEB+DB PRESS Vol.94

WEB+DB PRESS Vol.94

どなたかが編集のかたに自分を推薦していただいたようで、インフラの特集で、というお話をいただいて、ここ数年はほぼAWSをメインで使っているのでAWS前提の内容でよければ…ということで寄稿することになりました。

[鍵は監視にあり!]実践スケーラブルAWS

  • 第1章:AWSにおけるスケーリングの基本戦略
    • 成長段階に合わせた適切なインフラ構成……藤原 俊一郎
  • 第2章:規模が拡大しても破綻しない監視
    • 監視対象を動的に増減,値を集約して適切に通知……藤原 俊一郎
  • 第3章:Webサーバ/アプリケーションサーバのスケール
    • ELBでロードバランシング,SQSで非同期処理……朽木 拓
  • 第4章:キャッシュサーバのスケール
    • ElastiCacheとtwemproxyを組み合わせ負荷を分散……朽木 拓
  • 第5章:データベースサーバのスケール
    • RDSでリードレプリカを利用,フェイルオーバーへの対応……朽木 拓
  • 第6章:オートスケールを無駄なく活用
    • 自律的なプロビジョニング,余裕を持った発動ポリシー……藤原 俊一郎

1,2,6章を自分が、3,4,5章を id:tkuchiki で分担しています。

内容は、1台からはじめた小規模なサービスを AWS で100台規模までスケールさせて行くにはどうすればいいのか、という想定で、それに必要な要素や構築の際に注意すべき事をまとめてあります。

最近はクラウドで「スケーラブル」というとコンテナやサーバーレスやら、というかっこいい話になりそうなものですがそうではなく(そもそもそこまで仕事で突っ込んでないので)、普通にEC2上にアプリケーションサーバを立てるような構成でどう徐々に拡張していけばいいのか、という、どちらかというと泥臭い話です。

全体を貫く軸としては「監視」をメインにしていて、どのような項目をモニタリングして判断すればいいのか、という指針で各章に記述があるのと、監視だけで独立して章を設けてZabbixとMackerel、ログ集約(分量は少ないですが…)には Fluentd と Norikra などを取り上げています。

また、AWSらしいところということでオートスケールについても章を設けました。これは先日 YAP(achimon)C::Asia Hachioji 2016 mid in Shinagawa で発表した内容がベースになっていたりします。

他の特集も Kotlin、Electron と今話題の技術が取り上げられていて大変面白いと思いますので、是非お買い求めください!

Fluent::Logger(Perl)をFluentd 0.14のSub-second timeに対応した

Fluentd 0.14 がリリースされましたね。

Fluentd v0.14.0 has been released | Fluentd

新機能が盛りだくさんですが、そのうちの一つ Sub-second time (秒未満の解像度のtimestamp) に Fluent::Logger 0.18で対応しました。

<source>
  type forward
</source>

<match **>
  @type file
  path  ./test
  time_format %Y-%m-%dT%H:%M:%S.%N
</match>

このような fluentd.conf で fluentd 0.14 で起動して、以下のように event_time オプションを真にした Fluent::Logger から送信すると、

#!/usr/bin/env perl
use 5.12.0;
use Fluent::Logger;
use Time::HiRes;
my $logger = Fluent::Logger->new( event_time => 1 );
$logger->post(
    test => { foo => "bar" },
);
$logger->post_with_time(
    test => { foo => "baz" },
    1464845619.12345, # floatで指定
);

以下のように秒以下の精度を持った時刻でログを送信できます。

2016-06-02T14:40:52.251250982    test    {"foo":"bar"}
2016-06-02T14:33:39.123450040    test    {"foo":"baz"}

Perl側のinterfaceは浮動小数点数なので、正確にはnanosecond単位の精度はありません。もし精度が必要なら、floatではない値で指定できるような方法を検討するのでお知らせください。時刻指定なしの post() では内部で Time::HiRes::time() を呼び出してその時刻を送信しています。

ちなみに送信先が fluentd 0.12 の場合に event_time => 1 で送信するとエラーが発生しますのでご注意ください。(クラッシュはしないようですが)

[error]: forward error error=#<MessagePack::MalformedFormatError: invalid byte>
error_class=MessagePack::MalformedFormatError

Enjoy!

#shibuyago #2 で Stretcher の実装について話した

Shibuya.go#2 という勉強会で、自分が開発している Pull型デプロイツール Stretcher について発表してきました。 shibuyago.connpass.com

発表資料はこちらです。 speakerdeck.com

Goの勉強会なので、Stretcherの実装で使われているTips的なコードの紹介を多めにしてみました。

ちなみに資料中で紹介している copyAndCalcHash の実装は、既にPRをいただいて io.MultiWriter によってすっきりきれいになっています。

copyAndCalcHash is simplified by io.MultiWriter by shogo82148 · Pull Request #13 · fujiwara/stretcher · GitHub

会場とピザ、ビールを提供していただいた VOYAGE GROUP 様、主催の @suzu_v 様、ありがとうございました!

nginx実践入門

「nginx実践入門」 を著者の @cubicdaiya さんからいただきました。ありがとうございます。 簡単ですが感想など。

nginx実践入門 (WEB+DB PRESS plus)

nginx実践入門 (WEB+DB PRESS plus)

感想

一通り読んだ感想としては、本書は「『実践』入門」であっていわゆる入門書ではないのですね。 手取り足取りしてくれるわけではなく、リファレンスの詳解でもなく、あくまで実践的に運用する人へ向けての、実用的な使い方の入り口を紹介してくれる本でした。

特に最近重要性の高い TLS(SSL) での安全でハイパフォーマンスな設定、大規模コンテンツ配信サーバの構築を例とした多段 proxy 構成、実用的なログ出力と Fluentd によるメトリクスモニタリングなど、本番環境でサービスを運用するために役立つ情報が多く載っています。

今時は Web サーバの運用は単体で完結するものではなく、モニタリングや周辺システムとの連動が必須になってきているという事情を踏まえての構成だと感じました。

また、ngx_lua, OpenResty についての情報は、日本語書籍ではほぼ初めての登場になるかと思います。Lua はうまく使うと nginx 単体ではトリッキーな設定になるようなものも分かりやすくなるので、ありがたいですね。

気になったところ

6章でアプリケーションにクライアントの IP アドレスを伝達するために、

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

アプリケーションはX-Forwarded-Forヘッダの最も初めに存在するアドレスを使用することでユーザの送信元アドレスを把握できます。 (140ページ)

という部分があるのですが、この設定では nginx はクライアントが X-Forwarded-For ヘッダを付けてリクエストした場合、クライアントの IP アドレスを「追加」してアプリケーションに渡す形になります。

$ curl http://127.0.0.1/
→ X-Forwarded-For: 127.0.0.1

$ curl -H 'X-Forwarded-For: 192.168.1.1' http://127.0.0.1/
→ X-Forwarded-For: 192.168.1.1, 127.0.0.1

そのため、アプリケーションが先頭のアドレスを見た場合、その値は信用できないため、アクセス制限を回避されてしまう可能性がありそうです。

realip_module を使用して nginx が $remote_addr を偽装できない形で識別した上でアプリケーションに渡すか、

real_ip_header X-Forwarded-For;
real_ip_from [信頼できる接続元(多段proxyの親、ELBなど)のアドレス範囲];
proxy_set_header X-Forwarded-For $remote_addr;

アプリケーション側では X-Forwarded-For ヘッダの先頭ではなく末尾 (N段構成の場合は末尾からN番目) のものを見る必要があるかと思います。(基本的には最後の値は直接通信しているnginxが付けているので安全)

最後に

出版記念のイベントで LT をさせていただくことになりました。カヤック(の Lobi というサービス) で nginx + Lua (openresty) をどう活用しているかをお話しする予定です。

eventdots.jp

Consul 0.4.x から 0.5.2 へのバージョンアップ

このエントリは HashiCorp Advent Calendar 2015 - Qiita 1日目の記事です。

Consul クラスタは一度稼働を始めたら基本的に落とせないため、いわゆるローリングアップグレードによってクラスタ全体を停止せずにバージョンを上げることが考慮されています。

consul.io

ということで基本的には上記のURLを参照して、順番にagentを新しいバイナリで起動し直すことによって新しいバージョンに切り替えられるわけですが、Consul 0.5.0, 0.5.1 についてはいくつか留意点がありますので記録しておきます。

consul.io

0.5.0 未満から 0.5.0 以上にする場合

  • acl 機能を使っている場合、あらかじめ acl_policy を設定してからアップグレードする必要があります
    • が、自分は使用していなかったのでスルー
  • Leader が Consul 0.5 の場合、followerもすべて 0.5 である必要があります
    • Followerをすべて 0.5 にして、最後に Leader を 0.5 に上げる
    • 任意の順番で上げてもよいが、その場合は15分以内にすべてを 0.5 にする

なぜ15分なのかよく分かっていませんが、厳しい時間制限があると心臓によろしくないので、Leaderを最後にする方法でやるのがよいでしょう。

バージョンアップの作業の順番を間違えなければ問題はありませんが、サーバが最小構成の3台しかない状態では、1台作業中に他のサーバに障害が発生すると危険なので、可能であれば一時的に5台構成にするのをおすすめします。

また、新しく起動したサーバがちゃんと 0.5 で、クラスタに正常に組み込まれているかはよくよくログなどで確認しましょう。もし新しいサーバが join できず、サーバが足りない状態で別のを作業開始してしまうとクラスタ崩壊コースです。

0.5.1 未満から 0.5.1 以上にする場合

Consul 内部で使用している DB が、LMDB から BoltDB に変更になっています。

0.5.x では起動時に自動で migration が行われますので、特に事前準備する必要はなくバイナリを入れ替えて起動し直すだけです。上記ページには以下のようなログがでたら完了だよ、と書いてあるので、

==> Successfully migrated raft data in 5.839642ms

つい「ふんふん数msでおわるのね」と思ってしまいますが……環境によってはもっと時間がかかるようです。 手元のEC2 (t2.medium, gp2 disk) のインスタンスで migrate すると、data_dir 内に100MBある状態で約45秒掛かりました。

migration が終わるまで consul agentは起動しないため、その間は名前解決などの機能も当然使用できません。consul serverのみで他の機能を提供していないホストであればともかく、そうでない場合はちょっとつらい。

ではどうすればいいのか。まず、自分の環境で migration にどれぐらいの時間が掛かるかを計測することができます。

hashicorp/consul-migrate · GitHub が手動での migration tool なので、これを使って、

  • consul agent を一旦止める
  • data_dir を rsync で別の場所に copy する
  • consul agent を起動する

として、copy された data_dir に対して consul-migrate コマンドを実行すれば Migration completed in x.xxxs と表示されて完了までの時間が分かります。

ちなみに consul-migrate 実行時の iostat -x は以下のようになっていました。大量の disk write が発生していますね。

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
xvda              0.00   455.30    0.00 1159.70     0.00 33680.80    29.04     1.24    1.07   0.81  93.60

これで計測した migration に要する時間が運用上耐えられない場合の対応ですが、tmpfs に置いて migration することで劇的に高速化しました。同環境で 2.3 秒程度です。

  • consul (0.4.1) agent 停止
  • rsync で tmpfs に data_dir をコピー
  • 旧 data_dir から symlink を張る
  • consul (0.5.2) agent 起動

この手順で、合計ダウンタイムは数秒に抑えることができました。普通の disk に戻したい場合は、もう一度 consul agent を停止して、symlink を削除して書き戻してから起動することになります。

ただ、自分の場合は Consul server のホストが落ちたらまっさらな状態から同期し直してもたいしたコストではない(なんなら別のインスタンスを立てる) と判断したのと、Server が 5台あるので耐障害性もそれなりにある、ということで tmpfs のまま運用しています。

皆さんはどうしてるんでしょうか。教えてください。