ISUCONの勝ち方 YAPC::Asia Tokyo 2015

1. ISUCONの勝ち方
YAPC::Asia Tokyo 2015
Masahiro Nagano @kazeburo

2. Me
• 長野雅広(Masahiro Nagano)
• @kazeburo
• Mercari, Inc.
• Operations Engineer, Site Reliability
• ISUCON芸人

5. 主要KPI
ダウンロード数
購入金額
出品数
2000万DL(JP+US)
月間数十億円
1日数十万品以上

6. JOIN!!

7. Agenda
1. ISUCONとは
2. 私とISUCON
3. Webアプリケーションのパフォーマンス
4. ISUCONの勝ち方
1. 準備編
2. チューニングの進め方
3. チューニングのヒント

8. この発表の狙い
• ISUCONに興味をもってもらい、参加者を
増やす
• 予選突破、良い成績を残すのためのヒント
• Webアプリケーションのパフォーマンスに
関する知識の共有と自分を含むエンジニア
と業界の技術力向上

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

10. ISUCONとは
• Webアプリケーションの高速化コンテスト
• 1日かけてお題となるWebアプリケーショ
ンをチューニングする
• アプリケーションのコードを弄る事ができ
ないチューニングコンテストへのアンチテ
ーゼ

11. ISUCONとは
• 課題となるWebアプリケーションに対してレギュレーシ
ョン範囲内であれば、どんなチューニングを行ってもよ
い
• 職種、言語や開発・運用しているサービスの規模を超え
て如何にパフォーマンスの高いWebアプリケーションを
作る事ができるか
• (開催者がそれをみて楽しむ)
• ISUCONで得られた知見が公開される事で自分を含むエンジニアと
業界の技術力向上に寄与

13. ISUCONの順位
• 出題者が用意したベンチマークツール
の計測したスコアにより順位が決定
• ベンチマークツールはWebアプリケー
ションの動作に変更がないことをチェ
ックしており、ベンチマークがエラー
となれば失格

15. これまでのISUCON

16. ISUCON1 2011/8
出題: livedoor

17. Blog コメント欄

18. ISUCON2 2012/11
出題: NHN Japan

19. チケット販売サイト

20. ISUCON3
2013/10 オンライン予選 2013/11 本選
出題: 面白法人カヤック

21. 予選: nopaste
本選: 画像投稿 + TL

22. ISUCON4
2014/9 オンライン予選 2014/11本選
出題: クックパッド

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

24. ISUCON5
2015/9/26-27 予選
2015/10/31 本選

25. 出題: トレジャーデータ

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

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

28. 私とISUCON
ISUCONで生まれた技術

29. 私とISUCON
• 2011年 出題、サーバセットアップ担当
• 2012年 出題、サーバセットアップ担当
事前に出題に挑戦し、ベンチマークの問題を洗い出す
急性胃腸炎になる
• 2013年 初出場 優勝
メンバー: tagomoris sugyan kazeburo
• 2014年 2年連続優勝
メンバー: tagomoris sugyan kazeburo

30. ISUCONから生まれた技術
• ISUCONの為に作られたWAF
• Kossy
• より高いパフォーマンスを実現
• Gazelle
• Redis::Jet
• Plack::Middleware::Session::Simple
詳しくはblogで

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

32. パフォーマンスの重要性
• UX
• Jakob Nielsen - Response Times: The 3 Important Limits
“1.0 second is about the limit for the user's flow 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

33. パフォーマンスの重要性
• インフラコスト
• 30% 負荷を削減できると
• c4.2xlarge 30台だと
$9843 => $6890
• c4.2xlarge 100台だと
$32,810 => $22,967
• 管理コストや障害対応のコストも減らせる。
大規模なインフラでは嬉しい

34. ISUCONの勝ち方

35. 準備編

36. チーム編成
• ISUCONは2∼3人のチームで参加
• 時間が限られるので効率よく作業を分担し、
お互いの作業をチェックし、ミスを減らすこ
とが重要
• コミュニケーションコストを減らすため、普
段から一緒に業務を行っているメンバーでチ
ームを作った方が有利

37. コミュニケーション
• チームメイトとの“会話”を重視しましょ
う
• 問題をいち早く相談して解決する
• 本選では目の前にいる
• 決まった事はメモとして書き出す。後戻
りを減らす

38. 雑な構成メモ

39. 時間配分
• チームで認識を合わせる
• ISUCONは11:00 ~ 18:00 の7時間。意外と短い
• 最初の1時間は「まだ慌てる時間じゃない」
課題の理解、プロファイリングとチューニン
グの方向性を決めることだけに使う
• 最後の30分は再起動テストに残す

40. 事前準備
• Private Git Repository
• Wiki
• メンバーのSSH公開
• 秘伝のタレを集める
• Chat room
• 技術選択についての簡単な打ち合わせ
• 過去問を解く
• ISUCON予選突破の は過去問を解くことなので無料で試
せるようにした(Vagrant+Ansible) - Dマイナー志向
http://d.hatena.ne.jp/tmatsuu/20150815/1439643715

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

43. チューニングの進め方
1. 課題の理解
2. プロファイリング
3. サーバ構成の把握
4. チューニングの方向性を決める
5. 作業！

44. 1. 課題の理解
• レギュレーションや当日の説明を良く読む
• スコアの算出方法、失格条件は特に重要
• ブラウザで課題となるサイトへアクセスする
• とりあえずベンチマークを動かす

45. 2. プロファイリング
• Webアプリケーションで起きていることを知る
• アクセスログ解析
• MySQLのSlowLog解析
• アプリケーションのプロファイリング
• サーバの負荷の確認
• プロファイリング結果を読み解く慣れも必要

46. アクセスログ解析
• ベンチマークツールがアクセスしている先を知る
• 頻度とレスポンス時間をバランスよく見る
• ツール
• analyze_apache_logs
https://github.com/tagomoris/Apache-Log-
Parser
• kataribe
https://github.com/matsuu/kataribe/

47. アクセスログ解析
# vim httpd.conf
LogFormat "%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

49. MySQL SlowLog解析
• クエリ実行回数と頻度の両方をみる
• ツール
• pt-query-digest
https://www.percona.com/doc/
percona-toolkit/2.2/pt-query-
digest.html

50. 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

51. アプリケーションの
プロファイリング
• 各プログラミング言語のツールを使う
• strace
• システムコールレベルでアプリケーシ
ョンの動作を確認
• tcpdump
• 通信内容のキャプチャ

52. サーバの負荷をみる
• top - 全体の負荷
• iftop - ネットワーク
• iotop - disk io
• dstat
• などなど。使い慣れた物を使う

53. 3. サーバ構成の把握

54. Client Reverse
Proxy
App
Server
RDBMS
Cache,KVS
サーバ構成

55. サーバ構成の把握
• それぞれ、どのようなサーバ、ミドル
ウェアが動作しているか
• サーバ、ミドルウェアの設定
• 過去には設定のtypoや罠も

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

57. チューニングの方向性を考える
• ISUCONではサーバのおかわりはない。
与えられたサーバを効率よく使い切る
• 効率の良いCPUの使い方を知る
• CPUの気持ちになれるツール作った
http://yuroyoro.hatenablog.com/entry/
2014/10/20/102416
• コンテキストスイッチング

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

59. コンテキストスイッチング
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によりスケジュール実行

60. コンテキストスイッチング
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によりスケジュール実行

61. コンテキストスイッチング
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によりスケジュール実行

62. コンテキストスイッチング
• process/taskの切り替え時にCPUの状態
を保存・復元
• プロセス数が多過ぎると、コンテクス
トスイッチの回数が増え、その処理に
CPUが取られてしまう

63. チューニングすべき対象
• 大量のデータの参照
• 多サーバとの通信。特にラウンドトリ
ップのコストが大きい新規の通信開始
• 大量のプロセス／スレッドの調節
コンテキストスイッチングを減らす

64. 目指すアプリケーション
• 何もしないアプリケーションに如何に近
づけていくか
• 参照を減らす／しない
• 通信を減らす／しない
• プロセス・スレッドを減らす／使わな
い

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

66. Webサーバの選択

67. Apache vs. Nginx
worker worker worker
worker worker worker
worker worker worker
リクエスト
コンテキストスイッチが
大量発生
リクエスト
worker
1個のプロセスで
効率よく通信を処理

68. Nginx vs. h2o
リクエスト
process process
process
リクエスト
thread thread
thread
h2oはプロセスではなくスレッド。スレッドの方がコンテキスト
スイッチのコストが低い。スレッド間の情報の共有がしやすい
複数のworkerプロセスを
起動し大量のアクセスを
捌く

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

70. • 外部プロセスの起動
• HTMLテンプレート処理
• テキスト／画像変換処理
• RDBMS/Cacheとの接続
• N+1問題
わかりやすい重い処理

71. RDBMS/SQL

72. 心にいつもB+Treeを

73. MySQL の B+Tree
titleuser...
titleuser...
titleuser...
titleuser...
titleuser...
titleuser...
titleuser...
titleuser...
PRIMARY KEY
CLUSTERED INDEX
リーフノードに
データを含む
small large
id
id
id
id
id
id
id
id

74. MySQL の B+Tree
SECONDARY KEY
primary keyじゃないkey
リーフノードに
PRIMARYKEYが含まれ、
データはCLUSTEREDINDEX
から取得
id id id id id id id id
is_private
created_at
older newer older newer

75. 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

76. 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

77. 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

78. 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
何度も繰り返す=重い

79. MOTTAINAIの心

80. 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

81. 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
頑張ってソート
必要な個数まで到達

82. 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
頑張ってソート
必要な個数まで到達
廃棄

83. RDBMS/SQL
• B+Treeをイメージして走査の距離を短
く保つ
• 捨てるデータの読み取りを最小限に

84. 最後に

85. 大事なこと
• 初期状態を記録し、いつでも戻せるよう
にしておく
• 変更を都度記録し、壊れる前の状態に戻
しやすくする
• 前日はよく寝ましょう
• 諦めたらそこで終了です

86. 健闘を祈ります！

87. ご清聴
ありがとうございました
資料中の写真は isucon.net から引用しました

88. ISUCON 2回優勝したけど
質問ある？
Q&A

89. 勝つのは俺たちだ！