ISUCONの勝ち方 YAPC::Asia Tokyo 2015
•
50 likes•55,492 views
ISUCONの勝ち方 YAPC::Asia Tokyo 2015
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芸人
- 6. JOIN!!
- 7. Agenda 1. ISUCONとは 2. 私とISUCON 3. Webアプリケーションのパフォーマンス 4. ISUCONの勝ち方 1. 準備編 2. チューニングの進め方 3. チューニングのヒント
- 8. この発表の狙い • ISUCONに興味をもってもらい、参加者を 増やす • 予選突破、良い成績を残すのためのヒント • Webアプリケーションのパフォーマンスに 関する知識の共有と自分を含むエンジニア と業界の技術力向上
- 10. ISUCONとは • Webアプリケーションの高速化コンテスト • 1日かけてお題となるWebアプリケーショ ンをチューニングする • アプリケーションのコードを弄る事ができ ないチューニングコンテストへのアンチテ ーゼ
- 11. ISUCONとは • 課題となるWebアプリケーションに対してレギュレーシ ョン範囲内であれば、どんなチューニングを行ってもよ い • 職種、言語や開発・運用しているサービスの規模を超え て如何にパフォーマンスの高いWebアプリケーションを 作る事ができるか • (開催者がそれをみて楽しむ) • ISUCONで得られた知見が公開される事で自分を含むエンジニアと 業界の技術力向上に寄与
- 15. これまでのISUCON
- 17. Blog コメント欄
- 18. ISUCON2 2012/11 出題: NHN Japan
- 19. チケット販売サイト
- 20. ISUCON3 2013/10 オンライン予選 2013/11 本選 出題: 面白法人カヤック
- 21. 予選: nopaste 本選: 画像投稿 + TL
- 22. ISUCON4 2014/9 オンライン予選 2014/11本選 出題: クックパッド
- 25. 出題: トレジャーデータ
- 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で
- 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. サーバ構成の把握
- 55. サーバ構成の把握 • それぞれ、どのようなサーバ、ミドル ウェアが動作しているか • サーバ、ミドルウェアの設定 • 過去には設定のtypoや罠も
- 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. 目指すアプリケーション • 何もしないアプリケーションに如何に近 づけていくか • 参照を減らす／しない • 通信を減らす／しない • プロセス・スレッドを減らす／使わな い
- 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 頑張ってソート 必要な個数まで到達 廃棄
- 84. 最後に
- 85. 大事なこと • 初期状態を記録し、いつでも戻せるよう にしておく • 変更を都度記録し、壊れる前の状態に戻 しやすくする • 前日はよく寝ましょう • 諦めたらそこで終了です
- 86. 健闘を祈ります！
- 89. 勝つのは俺たちだ！