ISUCONの勝ち方 YAPC::Asia Tokyo 2015

ISUCONの勝ち方YAPC::Asia Tokyo 2015

Masahiro Nagano @kazeburo

Me

• 長野雅広(Masahiro Nagano)

• @kazeburo

• Mercari, Inc.

• Operations Engineer, Site Reliability

• ISUCON芸人

主要KPI

ダウンロード数

購入金額

出品数

2000万DL(JP+US)

月間数十億円

1日数十万品以上

JOIN!!

Agenda1. ISUCONとは

2. 私とISUCON

3. Webアプリケーションのパフォーマンス

4. ISUCONの勝ち方

1. 準備編

2. チューニングの進め方

3. チューニングのヒント

この発表の狙い• ISUCONに興味をもってもらい、参加者を増やす

• 予選突破、良い成績を残すのためのヒント• Webアプリケーションのパフォーマンスに関する知識の共有と自分を含むエンジニアと業界の技術力向上

ISUCONとは資料中の写真は isucon.net から引用

ISUCONとは• Webアプリケーションの高速化コンテスト

• 1日かけてお題となるWebアプリケーションをチューニングする

• アプリケーションのコードを弄る事ができないチューニングコンテストへのアンチテーゼ

ISUCONとは• 課題となるWebアプリケーションに対してレギュレーション範囲内であれば、どんなチューニングを行ってもよい

• 職種、言語や開発・運用しているサービスの規模を超えて如何にパフォーマンスの高いWebアプリケーションを作る事ができるか

• (開催者がそれをみて楽しむ)

• ISUCONで得られた知見が公開される事で自分を含むエンジニアと業界の技術力向上に寄与

ISUCONの順位• 出題者が用意したベンチマークツールの計測したスコアにより順位が決定

• ベンチマークツールはWebアプリケーションの動作に変更がないことをチェックしており、ベンチマークがエラーとなれば失格

これまでのISUCON

ISUCON1 2011/8出題: livedoor

Blog コメント欄

ISUCON2 2012/11出題: NHN Japan

チケット販売サイト

ISUCON32013/10 オンライン予選 2013/11 本選

出題: 面白法人カヤック

予選: nopaste

本選: 画像投稿 + TL

ISUCON42014/9 オンライン予選 2014/11本選

出題: クックパッド

予選: パスワードリスト攻撃本選: 動画広告

ISUCON52015/9/26-27 予選

2015/10/31 本選

出題: トレジャーデータ

https://twitter.com/studio3104/status/332899481286766593



http://isucon.net/archives/45166655.html



私とISUCONISUCONで生まれた技術

私とISUCON• 2011年出題、サーバセットアップ担当

• 2012年出題、サーバセットアップ担当事前に出題に挑戦し、ベンチマークの問題を洗い出す急性胃腸炎になる

• 2013年初出場優勝メンバー: tagomoris sugyan kazeburo

• 2014年 2年連続優勝メンバー: tagomoris sugyan kazeburo

ISUCONから生まれた技術• ISUCONの為に作られたWAF

• Kossy

• より高いパフォーマンスを実現• Gazelle

• Redis::Jet

• Plack::Middleware::Session::Simple

詳しくはblogで

Webアプリケーションのパフォーマンスなぜ重要か／なぜこだわるのか

パフォーマンスの重要性• UX

• Jakob Nielsen - Response Times: The 3 Important Limits“1.0 second is about the limit for the user's !ow of thought to stay uninterrupted”

• KPI

• Google: Using site speed in web search ranking

• Aberdeen Group: study showed that a one second delay in page load time equals 11% fewer page views, a 16% decrease in customer satisfaction, and 7% loss in conversions.

http://www.nngroup.com/articles/response-times-3-important-limits/http://googlewebmastercentral.blogspot.jp/2010/04/using-site-speed-in-web-search-ranking.html

http://www.aberdeen.com/research/5136/ra-performance-web-application/content.aspx

http://www.nngroup.com/articles/response-times-3-important-limits/

http://www.nngroup.com/articles/response-times-3-important-limits/

パフォーマンスの重要性• インフラコスト

• 30% 負荷を削減できると

• c4.2xlarge 30台だと$9843 => $6890

• c4.2xlarge 100台だと$32,810 => $22,967

• 管理コストや障害対応のコストも減らせる。大規模なインフラでは嬉しい

ISUCONの勝ち方

準備編

チーム編成• ISUCONは2～3人のチームで参加

• 時間が限られるので効率よく作業を分担し、お互いの作業をチェックし、ミスを減らすことが重要

• コミュニケーションコストを減らすため、普段から一緒に業務を行っているメンバーでチームを作った方が有利

コミュニケーション• チームメイトとの“会話”を重視しましょう

• 問題をいち早く相談して解決する• 本選では目の前にいる

• 決まった事はメモとして書き出す。後戻りを減らす

雑な構成メモ

時間配分• チームで認識を合わせる

• ISUCONは11:00 ~ 18:00 の7時間。意外と短い

• 最初の1時間は「まだ慌てる時間じゃない」課題の理解、プロファイリングとチューニングの方向性を決めることだけに使う

• 最後の30分は再起動テストに残す

事前準備• Private Git Repository

• Wiki

• メンバーのSSH公開鍵

• 秘伝のタレを集める

• Chat room

• 技術選択についての簡単な打ち合わせ

• 過去問を解く

• ISUCON予選突破の鍵は過去問を解くことなので無料で試せるようにした(Vagrant+Ansible) - Dマイナー志向http://d.hatena.ne.jp/tmatsuu/20150815/1439643715

チューニングの進め方

チューニングの進め方1.課題の理解

2.プロファイリング

3.サーバ構成の把握

4.チューニングの方向性を決める

5.作業！

1. 課題の理解

• レギュレーションや当日の説明を良く読む• スコアの算出方法、失格条件は特に重要

• ブラウザで課題となるサイトへアクセスする• とりあえずベンチマークを動かす

2. プロファイリング• Webアプリケーションで起きていることを知る

• アクセスログ解析• MySQLのSlowLog解析

• アプリケーションのプロファイリング• サーバの負荷の確認

• プロファイリング結果を読み解く慣れも必要

アクセスログ解析• ベンチマークツールがアクセスしている先を知る

• 頻度とレスポンス時間をバランスよく見る

• ツール

• analyze_apache_logshttps://github.com/tagomoris/Apache-Log-Parser

• kataribehttps://github.com/matsuu/kataribe/

アクセスログ解析# vim httpd.confLogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" \"%v\" \"%{cookie}n\" %D" combined

$ rm /var/log/httpd/access_log$ service httpd restart

# ベンチマーク実行

$ cat access_log | analyze_apache_logs

MySQL SlowLog解析• クエリ実行回数と頻度の両方をみる• ツール

• pt-query-digesthttps://www.percona.com/doc/percona-toolkit/2.2/pt-query-digest.html

https://www.percona.com/doc/percona-toolkit/2.2/pt-query-digest.html






MySQL SlowLog解析# mysqlのコンソールにて

> set global slow_query_log = 1;> set global long_query_time = 0;> set global slow_query_log_file = "/tmp/slow.log";

# ベンチマーク実行

$ pt-query-digest /tmp/slow.log > /tmp/digest.txt$ rm /tmp/slow.log

# 戻すときは

$ service mysqld restart

アプリケーションのプロファイリング

• 各プログラミング言語のツールを使う• strace

• システムコールレベルでアプリケーションの動作を確認

• tcpdump

• 通信内容のキャプチャ

サーバの負荷をみる• top - 全体の負荷

• iftop - ネットワーク

• iotop - disk io

• dstat

• などなど。使い慣れた物を使う

3. サーバ構成の把握

Client ReverseProxy

AppServer

RDBMS

Cache,KVS

サーバ構成

サーバ構成の把握

• それぞれ、どのようなサーバ、ミドルウェアが動作しているか

• サーバ、ミドルウェアの設定• 過去には設定のtypoや罠も

4. チューニングの方向性を決める

チューニングの方向性を考える• ISUCONではサーバのおかわりはない。与えられたサーバを効率よく使い切る

• 効率の良いCPUの使い方を知る

• CPUの気持ちになれるツール作ったhttp://yuroyoro.hatenablog.com/entry/2014/10/20/102416

• コンテキストスイッチング

Remix: Latency Numbers Every Programmer Should Know(2014)http://yuroyoro.net/latency.html

http://yuroyoro.net/latency.html

http://yuroyoro.net/latency.html

コンテキストスイッチング

CPU CPU CPU CPU

process process process process process process process



OSによりスケジュール実行


CPU CPU CPU CPU

process process

process

process process process process





CPU CPU CPU CPU


process process process process process

process

process




• process/taskの切り替え時にCPUの状態を保存・復元

• プロセス数が多過ぎると、コンテクストスイッチの回数が増え、その処理にCPUが取られてしまう

チューニングすべき対象

• 大量のデータの参照• 多サーバとの通信。特にラウンドトリップのコストが大きい新規の通信開始

• 大量のプロセス／スレッドの調節コンテキストスイッチングを減らす

目指すアプリケーション• 何もしないアプリケーションに如何に近づけていくか

• 参照を減らす／しない• 通信を減らす／しない• プロセス・スレッドを減らす／使わない

チューニングのヒントWebサーバ・アプリケーション・RDMBS

Webサーバの選択

Apache vs. Nginx

worker worker worker



リクエスト

コンテキストスイッチが大量発生

リクエスト

worker

1個のプロセスで効率よく通信を処理

Nginx vs. h2o

リクエスト

process process

process

リクエスト

thread thread

thread

h2oはプロセスではなくスレッド。スレッドの方がコンテキストスイッチのコストが低い。スレッド間の情報の共有がしやすい

複数のworkerプロセスを起動し大量のアクセスを

捌く

アプリケーションのチューニング

• 外部プロセスの起動• HTMLテンプレート処理

• テキスト／画像変換処理• RDBMS/Cacheとの接続

• N+1問題

わかりやすい重い処理

RDBMS/SQL

心にいつもB+Treeを

MySQL の B+Tree

titleuser

....

titleuser

...

titleuser

...

titleuser

...

titleuser

...

titleuser

....

titleuser

....

titleuser

....

PRIMARY KEYCLUSTERED INDEX

リーフノードにデータを含む

small largeid id id id id id id id

MySQL の B+Tree

SECONDARY KEYprimary keyじゃないkey

リーフノードにPRIMARY KEYが含まれ、データはCLUSTERED INDEX

から取得

id id id id id id id id

is_private

created_atolder newer older newer

MySQLのB+Tree

titleuser

....

titleuser

....

titleuser

....

titleuser

....

titleuser

....

titleuser

....

titleuser

....

titleuser

....

PRIMARY KEY


SECONDARY KEY


is_private

created_at

MySQLのB+Tree

titleuser

....

titleuser

....

titleuser

....

titleuser

....

titleuser

....

titleuser

....

titleuser

....

titleuser

....

PRIMARY KEY


SECONDARY KEY


is_private

created_at

MySQLのB+Tree

titleuser

....

titleuser

....

titleuser

....

titleuser

....

titleuser

....

titleuser

....

titleuser

....

titleuser

....

PRIMARY KEY


SECONDARY KEY


is_private

created_at

MySQLのB+Tree

titleuser

....

titleuser

....

titleuser

....

titleuser

....

titleuser

....

titleuser

....

titleuser

....

titleuser

....

PRIMARY KEY


SECONDARY KEY


is_private

created_at

何度も繰り返す = 重い

MOTTAINAIの心

MySQLのOFFSET処理id title user ... . id title user ... . id title user ... . id title user ... .

id title user ... . id title user ... . id title user ... . id title user ... .


id title user ... .


id title user ... .

1 2 3 4

5 6 7 8

9 10 11 12

13

10000

10001 10002 10003 10004




id title user ... .


id title user ... .

1 2 3 4

5 6 7 8

9 10 11 12

13

10000

10001 10002 10003 10004

頑張ってソート

必要な個数まで到達




id title user ... .


id title user ... .

1 2 3 4

5 6 7 8

9 10 11 12

13

10000

10001 10002 10003 10004

頑張ってソート

必要な個数まで到達

廃棄

RDBMS/SQL

• B+Treeをイメージして走査の距離を短く保つ

• 捨てるデータの読み取りを最小限に

最後に

大事なこと• 初期状態を記録し、いつでも戻せるようにしておく

• 変更を都度記録し、壊れる前の状態に戻しやすくする

• 前日はよく寝ましょう• 諦めたらそこで終了です

健闘を祈ります！

ご清聴ありがとうございました

資料中の写真は isucon.net から引用しました

ISUCON 2回優勝したけど質問ある？

Q&A

勝つのは俺たちだ！

Technology

ISUCONの勝ち方 YAPC::Asia Tokyo 2015