ISUCONの勝ち方 YAPC::Asia Tokyo 2015
-
Upload
masahiro-nagano -
Category
Technology
-
view
29.701 -
download
1
Transcript of 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
パフォーマンスの重要性• インフラコスト
• 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
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
コンテキストスイッチング
CPU CPU CPU CPU
process process process process process process process
process process process process process process process
process process process process process process process
OSによりスケジュール実行
コンテキストスイッチング
CPU CPU CPU CPU
process process
process
process process process process
process process process process process process process
process process process process process process process
OSによりスケジュール実行
コンテキストスイッチング
CPU CPU CPU CPU
process process process process process process process
process process process process process
process
process
process process process process process process process
OSによりスケジュール実行
コンテキストスイッチング
• process/taskの切り替え時にCPUの状態を保存・復元
• プロセス数が多過ぎると、コンテクストスイッチの回数が増え、その処理にCPUが取られてしまう
チューニングすべき対象
• 大量のデータの参照• 多サーバとの通信。特にラウンドトリップのコストが大きい新規の通信開始
• 大量のプロセス/スレッドの調節コンテキストスイッチングを減らす
目指すアプリケーション• 何もしないアプリケーションに如何に近づけていくか
• 参照を減らす/しない• 通信を減らす/しない• プロセス・スレッドを減らす/使わない
チューニングのヒントWebサーバ・アプリケーション・RDMBS
Webサーバの選択
Apache vs. Nginx
worker worker worker
worker worker worker
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
id id id id id id id id
SECONDARY KEY
id id id id id id id id
is_private
created_at
MySQLのB+Tree
titleuser
....
titleuser
....
titleuser
....
titleuser
....
titleuser
....
titleuser
....
titleuser
....
titleuser
....
PRIMARY KEY
id id id id id id id id
SECONDARY KEY
id id id id id id id id
is_private
created_at
MySQLのB+Tree
titleuser
....
titleuser
....
titleuser
....
titleuser
....
titleuser
....
titleuser
....
titleuser
....
titleuser
....
PRIMARY KEY
id id id id id id id id
SECONDARY KEY
id id id id id id id id
is_private
created_at
MySQLのB+Tree
titleuser
....
titleuser
....
titleuser
....
titleuser
....
titleuser
....
titleuser
....
titleuser
....
titleuser
....
PRIMARY KEY
id id id id id id id id
SECONDARY KEY
id id id id id id id id
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 ... . 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
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 ... . 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
頑張ってソート
必要な個数まで到達
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 ... . 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
頑張ってソート
必要な個数まで到達
廃棄
RDBMS/SQL
• B+Treeをイメージして走査の距離を短く保つ
• 捨てるデータの読み取りを最小限に
最後に
大事なこと• 初期状態を記録し、いつでも戻せるようにしておく
• 変更を都度記録し、壊れる前の状態に戻しやすくする
• 前日はよく寝ましょう• 諦めたらそこで終了です
健闘を祈ります!
ご清聴ありがとうございました
資料中の写真は isucon.net から引用しました
ISUCON 2回優勝したけど質問ある?
Q&A
勝つのは俺たちだ!