ISUCONの勝ち方 YAPC::Asia Tokyo 2015

27,314 views

Published on

ISUCONの勝ち方 YAPC::Asia Tokyo 2015

Published in: Technology
0 Comments
47 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
27,314
On SlideShare
0
From Embeds
0
Number of Embeds
18,085
Actions
Shares
0
Downloads
23
Comments
0
Likes
47
Embeds 0
No embeds

No notes for slide

ISUCONの勝ち方 YAPC::Asia Tokyo 2015

  1. 1. ISUCONの勝ち方 YAPC::Asia Tokyo 2015 Masahiro Nagano @kazeburo
  2. 2. Me • 長野雅広(Masahiro Nagano) • @kazeburo • Mercari, Inc. • Operations Engineer, Site Reliability • ISUCON芸人
  3. 3. 主要KPI ダウンロード数 購入金額 出品数 2000万DL(JP+US) 月間数十億円 1日数十万品以上
  4. 4. JOIN!!
  5. 5. Agenda 1. ISUCONとは 2. 私とISUCON 3. Webアプリケーションのパフォーマンス 4. ISUCONの勝ち方 1. 準備編 2. チューニングの進め方 3. チューニングのヒント
  6. 6. この発表の狙い • ISUCONに興味をもってもらい、参加者を 増やす • 予選突破、良い成績を残すのためのヒント • Webアプリケーションのパフォーマンスに 関する知識の共有と自分を含むエンジニア と業界の技術力向上
  7. 7. ISUCONとは 資料中の写真は isucon.net から引用
  8. 8. ISUCONとは • Webアプリケーションの高速化コンテスト • 1日かけてお題となるWebアプリケーショ ンをチューニングする • アプリケーションのコードを弄る事ができ ないチューニングコンテストへのアンチテ ーゼ
  9. 9. ISUCONとは • 課題となるWebアプリケーションに対してレギュレーシ ョン範囲内であれば、どんなチューニングを行ってもよ い • 職種、言語や開発・運用しているサービスの規模を超え て如何にパフォーマンスの高いWebアプリケーションを 作る事ができるか • (開催者がそれをみて楽しむ) • ISUCONで得られた知見が公開される事で自分を含むエンジニアと 業界の技術力向上に寄与
  10. 10. ISUCONの順位 • 出題者が用意したベンチマークツール の計測したスコアにより順位が決定 • ベンチマークツールはWebアプリケー ションの動作に変更がないことをチェ ックしており、ベンチマークがエラー となれば失格
  11. 11. これまでのISUCON
  12. 12. ISUCON1 2011/8 出題: livedoor
  13. 13. Blog コメント欄
  14. 14. ISUCON2 2012/11 出題: NHN Japan
  15. 15. チケット販売サイト
  16. 16. ISUCON3 2013/10 オンライン予選 2013/11 本選 出題: 面白法人カヤック
  17. 17. 予選: nopaste 本選: 画像投稿 + TL
  18. 18. ISUCON4 2014/9 オンライン予選 2014/11本選 出題: クックパッド
  19. 19. 予選: パスワードリスト攻撃 本選: 動画広告
  20. 20. ISUCON5 2015/9/26-27 予選 2015/10/31 本選
  21. 21. 出題: トレジャーデータ
  22. 22. https://twitter.com/studio3104/status/332899481286766593
  23. 23. http://isucon.net/archives/45166655.html
  24. 24. 私とISUCON ISUCONで生まれた技術
  25. 25. 私とISUCON • 2011年 出題、サーバセットアップ担当 • 2012年 出題、サーバセットアップ担当 事前に出題に挑戦し、ベンチマークの問題を洗い出す 急性胃腸炎になる • 2013年 初出場 優勝 メンバー: tagomoris sugyan kazeburo • 2014年 2年連続優勝 メンバー: tagomoris sugyan kazeburo
  26. 26. ISUCONから生まれた技術 • ISUCONの為に作られたWAF • Kossy • より高いパフォーマンスを実現 • Gazelle • Redis::Jet • Plack::Middleware::Session::Simple 詳しくはblogで
  27. 27. Webアプリケーションの パフォーマンス なぜ重要か/なぜこだわるのか
  28. 28. パフォーマンスの重要性 • 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
  29. 29. パフォーマンスの重要性 • インフラコスト • 30% 負荷を削減できると • c4.2xlarge 30台だと $9843 => $6890 • c4.2xlarge 100台だと $32,810 => $22,967 • 管理コストや障害対応のコストも減らせる。 大規模なインフラでは嬉しい
  30. 30. ISUCONの勝ち方
  31. 31. 準備編
  32. 32. チーム編成 • ISUCONは2∼3人のチームで参加 • 時間が限られるので効率よく作業を分担し、 お互いの作業をチェックし、ミスを減らすこ とが重要 • コミュニケーションコストを減らすため、普 段から一緒に業務を行っているメンバーでチ ームを作った方が有利
  33. 33. コミュニケーション • チームメイトとの“会話”を重視しましょ う • 問題をいち早く相談して解決する • 本選では目の前にいる • 決まった事はメモとして書き出す。後戻 りを減らす
  34. 34. 雑な構成メモ
  35. 35. 時間配分 • チームで認識を合わせる • ISUCONは11:00 ~ 18:00 の7時間。意外と短い • 最初の1時間は「まだ慌てる時間じゃない」 課題の理解、プロファイリングとチューニン グの方向性を決めることだけに使う • 最後の30分は再起動テストに残す
  36. 36. 事前準備 • Private Git Repository • Wiki • メンバーのSSH公開 • 秘伝のタレを集める • Chat room • 技術選択についての簡単な打ち合わせ • 過去問を解く • ISUCON予選突破の は過去問を解くことなので無料で試 せるようにした(Vagrant+Ansible) - Dマイナー志向 http://d.hatena.ne.jp/tmatsuu/20150815/1439643715
  37. 37. チューニングの進め方
  38. 38. チューニングの進め方 1. 課題の理解 2. プロファイリング 3. サーバ構成の把握 4. チューニングの方向性を決める 5. 作業!
  39. 39. 1. 課題の理解 • レギュレーションや当日の説明を良く読む • スコアの算出方法、失格条件は特に重要 • ブラウザで課題となるサイトへアクセスする • とりあえずベンチマークを動かす
  40. 40. 2. プロファイリング • Webアプリケーションで起きていることを知る • アクセスログ解析 • MySQLのSlowLog解析 • アプリケーションのプロファイリング • サーバの負荷の確認 • プロファイリング結果を読み解く慣れも必要
  41. 41. アクセスログ解析 • ベンチマークツールがアクセスしている先を知る • 頻度とレスポンス時間をバランスよく見る • ツール • analyze_apache_logs https://github.com/tagomoris/Apache-Log- Parser • kataribe https://github.com/matsuu/kataribe/
  42. 42. アクセスログ解析 # 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
  43. 43. MySQL SlowLog解析 • クエリ実行回数と頻度の両方をみる • ツール • pt-query-digest https://www.percona.com/doc/ percona-toolkit/2.2/pt-query- digest.html
  44. 44. 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
  45. 45. アプリケーションの プロファイリング • 各プログラミング言語のツールを使う • strace • システムコールレベルでアプリケーシ ョンの動作を確認 • tcpdump • 通信内容のキャプチャ
  46. 46. サーバの負荷をみる • top - 全体の負荷 • iftop - ネットワーク • iotop - disk io • dstat • などなど。使い慣れた物を使う
  47. 47. 3. サーバ構成の把握
  48. 48. Client Reverse Proxy App Server RDBMS Cache,KVS サーバ構成
  49. 49. サーバ構成の把握 • それぞれ、どのようなサーバ、ミドル ウェアが動作しているか • サーバ、ミドルウェアの設定 • 過去には設定のtypoや罠も
  50. 50. 4. チューニングの 方向性を決める
  51. 51. チューニングの方向性を考える • ISUCONではサーバのおかわりはない。 与えられたサーバを効率よく使い切る • 効率の良いCPUの使い方を知る • CPUの気持ちになれるツール作った http://yuroyoro.hatenablog.com/entry/ 2014/10/20/102416 • コンテキストスイッチング
  52. 52. Remix: Latency Numbers Every Programmer Should Know(2014) http://yuroyoro.net/latency.html
  53. 53. コンテキストスイッチング 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によりスケジュール実行
  54. 54. コンテキストスイッチング 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によりスケジュール実行
  55. 55. コンテキストスイッチング 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によりスケジュール実行
  56. 56. コンテキストスイッチング • process/taskの切り替え時にCPUの状態 を保存・復元 • プロセス数が多過ぎると、コンテクス トスイッチの回数が増え、その処理に CPUが取られてしまう
  57. 57. チューニングすべき対象 • 大量のデータの参照 • 多サーバとの通信。特にラウンドトリ ップのコストが大きい新規の通信開始 • 大量のプロセス/スレッドの調節 コンテキストスイッチングを減らす
  58. 58. 目指すアプリケーション • 何もしないアプリケーションに如何に近 づけていくか • 参照を減らす/しない • 通信を減らす/しない • プロセス・スレッドを減らす/使わな い
  59. 59. チューニングのヒント Webサーバ・アプリケーション・RDMBS
  60. 60. Webサーバの選択
  61. 61. Apache vs. Nginx worker worker worker worker worker worker worker worker worker リクエスト コンテキストスイッチが 大量発生 リクエスト worker 1個のプロセスで 効率よく通信を処理
  62. 62. Nginx vs. h2o リクエスト process process process リクエスト thread thread thread h2oはプロセスではなくスレッド。スレッドの方がコンテキスト スイッチのコストが低い。スレッド間の情報の共有がしやすい 複数のworkerプロセスを 起動し大量のアクセスを 捌く
  63. 63. アプリケーションの チューニング
  64. 64. • 外部プロセスの起動 • HTMLテンプレート処理 • テキスト/画像変換処理 • RDBMS/Cacheとの接続 • N+1問題 わかりやすい重い処理
  65. 65. RDBMS/SQL
  66. 66. 心にいつもB+Treeを
  67. 67. 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
  68. 68. 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
  69. 69. 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
  70. 70. 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
  71. 71. 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
  72. 72. 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 何度も繰り返す=重い
  73. 73. MOTTAINAIの心
  74. 74. 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
  75. 75. 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 頑張ってソート 必要な個数まで到達
  76. 76. 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 頑張ってソート 必要な個数まで到達 廃棄
  77. 77. RDBMS/SQL • B+Treeをイメージして走査の距離を短 く保つ • 捨てるデータの読み取りを最小限に
  78. 78. 最後に
  79. 79. 大事なこと • 初期状態を記録し、いつでも戻せるよう にしておく • 変更を都度記録し、壊れる前の状態に戻 しやすくする • 前日はよく寝ましょう • 諦めたらそこで終了です
  80. 80. 健闘を祈ります!
  81. 81. ご清聴 ありがとうございました 資料中の写真は isucon.net から引用しました
  82. 82. ISUCON 2回優勝したけど 質問ある? Q&A
  83. 83. 勝つのは俺たちだ!

×