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によりスケジュール実行

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

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. 勝つのは俺たちだ！

ISUCONの勝ち方 YAPC::Asia Tokyo 2015

ISUCONの勝ち方 YAPC::Asia Tokyo 2015

Recommended

More Related Content

What's hot

What's hot(20)

Viewers also liked

Viewers also liked(20)

Similar to ISUCONの勝ち方 YAPC::Asia Tokyo 2015

Similar to ISUCONの勝ち方 YAPC::Asia Tokyo 2015(20)

More from Masahiro Nagano

More from Masahiro Nagano(20)

Recently uploaded

Recently uploaded(8)

ISUCONの勝ち方 YAPC::Asia Tokyo 2015