ISUCONの話
2013/08/01
LINE株式会社
田籠 聡 (@tagomoris)
13年8月2日金曜日
LINE株式会社
開発3センター 開発支援室 開発支援チーム
@tagomoris
13年8月2日金曜日
LINE株式会社
開発3センター 開発支援室 開発支援チーム
@kazeburo
13年8月2日金曜日
ISUCONとは
「いい感じに」(Iikanjini)
「スピードアップ」(Speed Up)
「コンテスト」(CONtest)
本当です
13年8月2日金曜日
ISUCONとは
Webアプリケーションを高速化するイベント
1はblog, 2はチケット販売サイト
最も良いスコアを叩き出したチームが優勝
「良スコア」==「良パフォーマンス」
イベント中はベンチマークツールは非公開
13年8月2日金曜日
レギュレーション(1)
主催者が準備したWebアプリケーションに対して規定の負荷をかけ、
所定の数の処理が全て完了するまでの時間を競う
バックグラウンド負荷(GET処理)について規定以上の率で正常な
応答を返すことを最低条件とする
その上で、特...
レギュレーション(2)
チーム単位(2名もしくは3名)での参加とし、チーム毎に仮想サーバと
して4台程度のLinuxサーバが与えられる
今回、1名での参加は不可とします
リバースプロキシ、Web/AP(2台)、DB、の構成で計画しています
与え...
レギュレーション(3)
上記のレギュレーション項目が守られればいかなる変更も可とする
HTMLやJS/CSSなど、コンテンツの最適化
DBスキーマの変更やインデックスの作成・削除、キャッシュ機構
の追加
jobqueue機構の追加による遅延書き...
user4
user3
user2
user1
※イメージ
server
server
server
server
server
server
server
server
serverserver
server
server
bench
高負荷...
13年8月2日金曜日
ぼくらのお仕事について
Webサービス/インターネットサービスの提供
サーバサイドの環境構築・プログラミング
ネットワーク、サーバ、OS
httpd, RDBMS, KVS などのミドルウェア
プログラムコード
要するにISUCONの作業対象ほ...
ISUCON参加者の人々
インターネットサービス関連の人が多い
会社の同僚でチームを組む例が多い
他には勉強会などでの知り合い同士など
スキル的にはいろいろ
ITインフラ専門の人ばかりのチーム
ITインフラ + アプリな人のチーム
13年8月2...
Webサービスにおけるパフォーマンス
「パフォーマンス」とは
レスポンスタイム:
1リクエスト → 1レスポンス の時間
スループット:
1秒間に返せるレスポンスの数
短いレスポンスタイム、高いスループット
== 「良いパフォーマンス」
13年...
パフォーマンス向上の重要性
ユーザ体験の向上
ユーザのアクションにすぐに反応する
入力内容が遅れず反映される
運用コストの低減
必要なサーバ台数の減少
高負荷サーバ減少→メンテナンス手間の削減
13年8月2日金曜日
ISUCONにおける
パフォーマンス
is
スコア
13年8月2日金曜日
競技概要※isucon2レギュレーション資料より
ベンチマークは3分間 + 前後チェック
作業中は1分で実施
チケット完売までの速度を競う
(ただし判定にはスコアを用いる)
13年8月2日金曜日
採点 (18:00 - 18:30) ※isucon2レギュレーション資料より
18:00 で全参加者の作業を停止
準備が必要なら事前に行うこと
全サーバのrebootを実行
順番に各チームのベンチマークを実施
13年8月2日金曜日
スコア算出※isucon2レギュレーション資料より
X: 完売までの所要時間(ms)
Y: 完売後の購入リクエスト処理数
Z: 全体でのGETリクエスト処理数
X - (Y*0.01 + Z*0.001)
13年8月2日金曜日
参考スコア※isucon2レギュレーション資料より
ベンチ走行時間内に
完売しない場合
時間と販売数から
完売予定時間を逆
算して X に使用
1分走行でも3分走行で
も同じ得点基準
13年8月2日金曜日
表彰※isucon2レギュレーション資料より
優勝
採点フェイズのベンチ走行で最高スコアを出した
チーム
特別賞
作業時間内のベンチ走行において スコア
180,000 未満に最も早く到達したチーム
13年8月2日金曜日
失格事項※isucon2レギュレーション資料より
チケット販売実績が保存されていない
購入処理の結果が1秒以内にGETへのレスポンス内容
に反映されていない
エラー/タイムアウトのレスポンスが1%以上ある
その他アプリケーションの動作仕様に変化...
Actions
in
ISUCON
13年8月2日金曜日
普段どおりにやる
13年8月2日金曜日
普段やれないことをやる
13年8月2日金曜日
ただし安全のために
最初の状態を保存しておく
ソースコード、初期データ、初期設定
初期スコアと初期状態
何をやったか記録しておく
ソースコードや設定のバージョン管理
相談内容の記録
13年8月2日金曜日
ボトルネックを見付けて
解決する
HTTPD? connections? cpu? memory?
Application? connections? cpu? memory?
RDBMS? read? write?
Network? data...
スコア
スコアを向上させる
スコア算出ルールを見る
何を改善すべきかを考える
スコアの揺れ
実行時の状況によって多少の揺れが出る
わずかな差異(誤差)にまどわされない
改善は劇的に行う
13年8月2日金曜日
制限時間
時間があります
7時間で何もかもやるのは不可能
最初に落ち着いて内容を把握する
時間と相談してやれそうなことを考える
大きな改造にいつ手をつけるか
早目がよい、ほぼワンチャンス
終了時間に動いてなければならない
13年8月2日金曜日
Web applicationのキソ
13年8月2日金曜日
おひとりさま環境
manager.js agent.js
http_load bench.js
application
server
mysql
:5000
:5001
13年8月2日金曜日
isucon本番環境
manager.js agent.js
http_load bench.js
application
server
mysql
:5001
application
server
apache
httpd
※それぞれ別のサー...
at first
use this application by yourself!
13年8月2日金曜日
web application
middlewares
application server:
runs program code
httpd, nginx: web server, reverse proxy
static contents:...
application server
プログラムを実行して結果を返す
なんでもできる
決まった処理をやらせるにはコストが高い
内容の変わらない処理 (js/css/image)
13年8月2日金曜日
web server
reverse proxy server
設定に従って特定のコンテンツを返す
指定された場所に置いてあるファイルなど
特定のパスについては別のサーバに取りに
いって、とってきた結果を返す(proxy)
「別のサーバ」を複数...
RDBMS (mysql)
SQLでの問合せに対して結果を返す
SQLが効率的に書かれているかは非常に重要
インデックスをきちんと使えているか
適切なインデックスが作成されているか
同時接続数が多/少なすぎる、なども注意
13年8月2日金曜日
how to get high scores
serve static files by web server
enhance sql
tune parameters
inject caches
change architecture
13年8月...
serve static files
on web server
execute httpd, and serve static files on it
write configurations
change bench setting to acc...
enhance sql
create index
rewrite sql queries
use JOIN / remove JOIN ...
13年8月2日金曜日
tune parameters
connections
connections, maxclients, keepalives
processes
application server processes
httpd process/threa...
inject caches
cache application server response
on reverse proxy
for GETs
13年8月2日金曜日
change architecture
ex: change datastore from mysql to redis
ex: rewrite overall application
13年8月2日金曜日
Enjoy ISUCON!
13年8月2日金曜日
Upcoming SlideShare
Loading in …5
×

Isucon summer class_2013

7,370 views

Published on

Isucon summer class_2013

  1. 1. ISUCONの話 2013/08/01 LINE株式会社 田籠 聡 (@tagomoris) 13年8月2日金曜日
  2. 2. LINE株式会社 開発3センター 開発支援室 開発支援チーム @tagomoris 13年8月2日金曜日
  3. 3. LINE株式会社 開発3センター 開発支援室 開発支援チーム @kazeburo 13年8月2日金曜日
  4. 4. ISUCONとは 「いい感じに」(Iikanjini) 「スピードアップ」(Speed Up) 「コンテスト」(CONtest) 本当です 13年8月2日金曜日
  5. 5. ISUCONとは Webアプリケーションを高速化するイベント 1はblog, 2はチケット販売サイト 最も良いスコアを叩き出したチームが優勝 「良スコア」==「良パフォーマンス」 イベント中はベンチマークツールは非公開 13年8月2日金曜日
  6. 6. レギュレーション(1) 主催者が準備したWebアプリケーションに対して規定の負荷をかけ、 所定の数の処理が全て完了するまでの時間を競う バックグラウンド負荷(GET処理)について規定以上の率で正常な 応答を返すことを最低条件とする その上で、特定の一連の更新処理を所定回数完了するまでの時間 をスコアとし、最も短いチームを勝者とする Perl/Ruby/Python/PHP/Node.js で記述されたWebアプリケー ションを基準アプリケーションとして提供します Java による実装が追加される可能性があります 13年8月2日金曜日
  7. 7. レギュレーション(2) チーム単位(2名もしくは3名)での参加とし、チーム毎に仮想サーバと して4台程度のLinuxサーバが与えられる 今回、1名での参加は不可とします リバースプロキシ、Web/AP(2台)、DB、の構成で計画しています 与えられたWebアプリケーションにおける以下の機能を変えないこと アクセス先のURI レスポンス(HTML)のDOM構造 ブラウザで表示した際の見た目(問題ない範囲で)、および Javascript/CSSの効果 アプリケーションが提供するデータの一貫性の保持 13年8月2日金曜日
  8. 8. レギュレーション(3) 上記のレギュレーション項目が守られればいかなる変更も可とする HTMLやJS/CSSなど、コンテンツの最適化 DBスキーマの変更やインデックスの作成・削除、キャッシュ機構 の追加 jobqueue機構の追加による遅延書き込み (レギュレーションの一 貫性に関する条項を満たすこと) 他の言語による再実装 Webサーバソフトウェアやデータベースソフトウェアの変更 ただしコンテスト実施上必要ないくつかのメンテナンス機能につ いて互換性を保つこと 13年8月2日金曜日
  9. 9. user4 user3 user2 user1 ※イメージ server server server server server server server server serverserver server server bench 高負荷アクセス 動作チェック 13年8月2日金曜日
  10. 10. 13年8月2日金曜日
  11. 11. ぼくらのお仕事について Webサービス/インターネットサービスの提供 サーバサイドの環境構築・プログラミング ネットワーク、サーバ、OS httpd, RDBMS, KVS などのミドルウェア プログラムコード 要するにISUCONの作業対象ほとんど 13年8月2日金曜日
  12. 12. ISUCON参加者の人々 インターネットサービス関連の人が多い 会社の同僚でチームを組む例が多い 他には勉強会などでの知り合い同士など スキル的にはいろいろ ITインフラ専門の人ばかりのチーム ITインフラ + アプリな人のチーム 13年8月2日金曜日
  13. 13. Webサービスにおけるパフォーマンス 「パフォーマンス」とは レスポンスタイム: 1リクエスト → 1レスポンス の時間 スループット: 1秒間に返せるレスポンスの数 短いレスポンスタイム、高いスループット == 「良いパフォーマンス」 13年8月2日金曜日
  14. 14. パフォーマンス向上の重要性 ユーザ体験の向上 ユーザのアクションにすぐに反応する 入力内容が遅れず反映される 運用コストの低減 必要なサーバ台数の減少 高負荷サーバ減少→メンテナンス手間の削減 13年8月2日金曜日
  15. 15. ISUCONにおける パフォーマンス is スコア 13年8月2日金曜日
  16. 16. 競技概要※isucon2レギュレーション資料より ベンチマークは3分間 + 前後チェック 作業中は1分で実施 チケット完売までの速度を競う (ただし判定にはスコアを用いる) 13年8月2日金曜日
  17. 17. 採点 (18:00 - 18:30) ※isucon2レギュレーション資料より 18:00 で全参加者の作業を停止 準備が必要なら事前に行うこと 全サーバのrebootを実行 順番に各チームのベンチマークを実施 13年8月2日金曜日
  18. 18. スコア算出※isucon2レギュレーション資料より X: 完売までの所要時間(ms) Y: 完売後の購入リクエスト処理数 Z: 全体でのGETリクエスト処理数 X - (Y*0.01 + Z*0.001) 13年8月2日金曜日
  19. 19. 参考スコア※isucon2レギュレーション資料より ベンチ走行時間内に 完売しない場合 時間と販売数から 完売予定時間を逆 算して X に使用 1分走行でも3分走行で も同じ得点基準 13年8月2日金曜日
  20. 20. 表彰※isucon2レギュレーション資料より 優勝 採点フェイズのベンチ走行で最高スコアを出した チーム 特別賞 作業時間内のベンチ走行において スコア 180,000 未満に最も早く到達したチーム 13年8月2日金曜日
  21. 21. 失格事項※isucon2レギュレーション資料より チケット販売実績が保存されていない 購入処理の結果が1秒以内にGETへのレスポンス内容 に反映されていない エラー/タイムアウトのレスポンスが1%以上ある その他アプリケーションの動作仕様に変化があると チェッカが判断した場合 13年8月2日金曜日
  22. 22. Actions in ISUCON 13年8月2日金曜日
  23. 23. 普段どおりにやる 13年8月2日金曜日
  24. 24. 普段やれないことをやる 13年8月2日金曜日
  25. 25. ただし安全のために 最初の状態を保存しておく ソースコード、初期データ、初期設定 初期スコアと初期状態 何をやったか記録しておく ソースコードや設定のバージョン管理 相談内容の記録 13年8月2日金曜日
  26. 26. ボトルネックを見付けて 解決する HTTPD? connections? cpu? memory? Application? connections? cpu? memory? RDBMS? read? write? Network? data size? latency? ボトルネックは解決するたびに移っていく 13年8月2日金曜日
  27. 27. スコア スコアを向上させる スコア算出ルールを見る 何を改善すべきかを考える スコアの揺れ 実行時の状況によって多少の揺れが出る わずかな差異(誤差)にまどわされない 改善は劇的に行う 13年8月2日金曜日
  28. 28. 制限時間 時間があります 7時間で何もかもやるのは不可能 最初に落ち着いて内容を把握する 時間と相談してやれそうなことを考える 大きな改造にいつ手をつけるか 早目がよい、ほぼワンチャンス 終了時間に動いてなければならない 13年8月2日金曜日
  29. 29. Web applicationのキソ 13年8月2日金曜日
  30. 30. おひとりさま環境 manager.js agent.js http_load bench.js application server mysql :5000 :5001 13年8月2日金曜日
  31. 31. isucon本番環境 manager.js agent.js http_load bench.js application server mysql :5001 application server apache httpd ※それぞれ別のサーバ 13年8月2日金曜日
  32. 32. at first use this application by yourself! 13年8月2日金曜日
  33. 33. web application middlewares application server: runs program code httpd, nginx: web server, reverse proxy static contents: image, js, css, ... load balance cache controls RDBMS: mysql 13年8月2日金曜日
  34. 34. application server プログラムを実行して結果を返す なんでもできる 決まった処理をやらせるにはコストが高い 内容の変わらない処理 (js/css/image) 13年8月2日金曜日
  35. 35. web server reverse proxy server 設定に従って特定のコンテンツを返す 指定された場所に置いてあるファイルなど 特定のパスについては別のサーバに取りに いって、とってきた結果を返す(proxy) 「別のサーバ」を複数指定して順番に問合 せる、とかできる 13年8月2日金曜日
  36. 36. RDBMS (mysql) SQLでの問合せに対して結果を返す SQLが効率的に書かれているかは非常に重要 インデックスをきちんと使えているか 適切なインデックスが作成されているか 同時接続数が多/少なすぎる、なども注意 13年8月2日金曜日
  37. 37. how to get high scores serve static files by web server enhance sql tune parameters inject caches change architecture 13年8月2日金曜日
  38. 38. serve static files on web server execute httpd, and serve static files on it write configurations change bench setting to access :80 13年8月2日金曜日
  39. 39. enhance sql create index rewrite sql queries use JOIN / remove JOIN ... 13年8月2日金曜日
  40. 40. tune parameters connections connections, maxclients, keepalives processes application server processes httpd process/threads database configuration 13年8月2日金曜日
  41. 41. inject caches cache application server response on reverse proxy for GETs 13年8月2日金曜日
  42. 42. change architecture ex: change datastore from mysql to redis ex: rewrite overall application 13年8月2日金曜日
  43. 43. Enjoy ISUCON! 13年8月2日金曜日

×