Isucon summer class_2013
Upcoming SlideShare
Loading in...5
×
 

Isucon summer class_2013

on

  • 6,464 views

 

Statistics

Views

Total Views
6,464
Views on SlideShare
1,843
Embed Views
4,621

Actions

Likes
12
Downloads
3
Comments
0

14 Embeds 4,621

http://d.hatena.ne.jp 1878
http://isucon.net 1640
http://yosuke-furukawa.hatenablog.com 953
http://cloud.feedly.com 77
http://obtuse-angled25.rssing.com 27
http://obtuse-angled25.alamaree.com 18
http://www.feedspot.com 11
https://twitter.com 5
http://feedly.com 5
http://www.newsblur.com 2
http://digg.com 2
https://www.google.co.jp 1
http://reader.aol.com 1
http://www.google.co.jp 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Isucon summer class_2013 Isucon summer class_2013 Presentation Transcript

  • 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処理)について規定以上の率で正常な 応答を返すことを最低条件とする その上で、特定の一連の更新処理を所定回数完了するまでの時間 をスコアとし、最も短いチームを勝者とする Perl/Ruby/Python/PHP/Node.js で記述されたWebアプリケー ションを基準アプリケーションとして提供します Java による実装が追加される可能性があります 13年8月2日金曜日
  • レギュレーション(2) チーム単位(2名もしくは3名)での参加とし、チーム毎に仮想サーバと して4台程度のLinuxサーバが与えられる 今回、1名での参加は不可とします リバースプロキシ、Web/AP(2台)、DB、の構成で計画しています 与えられたWebアプリケーションにおける以下の機能を変えないこと アクセス先のURI レスポンス(HTML)のDOM構造 ブラウザで表示した際の見た目(問題ない範囲で)、および Javascript/CSSの効果 アプリケーションが提供するデータの一貫性の保持 13年8月2日金曜日
  • レギュレーション(3) 上記のレギュレーション項目が守られればいかなる変更も可とする HTMLやJS/CSSなど、コンテンツの最適化 DBスキーマの変更やインデックスの作成・削除、キャッシュ機構 の追加 jobqueue機構の追加による遅延書き込み (レギュレーションの一 貫性に関する条項を満たすこと) 他の言語による再実装 Webサーバソフトウェアやデータベースソフトウェアの変更 ただしコンテスト実施上必要ないくつかのメンテナンス機能につ いて互換性を保つこと 13年8月2日金曜日
  • user4 user3 user2 user1 ※イメージ server server server server server server server server serverserver server server bench 高負荷アクセス 動作チェック 13年8月2日金曜日
  • 13年8月2日金曜日
  • ぼくらのお仕事について Webサービス/インターネットサービスの提供 サーバサイドの環境構築・プログラミング ネットワーク、サーバ、OS httpd, RDBMS, KVS などのミドルウェア プログラムコード 要するにISUCONの作業対象ほとんど 13年8月2日金曜日
  • ISUCON参加者の人々 インターネットサービス関連の人が多い 会社の同僚でチームを組む例が多い 他には勉強会などでの知り合い同士など スキル的にはいろいろ ITインフラ専門の人ばかりのチーム ITインフラ + アプリな人のチーム 13年8月2日金曜日
  • Webサービスにおけるパフォーマンス 「パフォーマンス」とは レスポンスタイム: 1リクエスト → 1レスポンス の時間 スループット: 1秒間に返せるレスポンスの数 短いレスポンスタイム、高いスループット == 「良いパフォーマンス」 13年8月2日金曜日
  • パフォーマンス向上の重要性 ユーザ体験の向上 ユーザのアクションにすぐに反応する 入力内容が遅れず反映される 運用コストの低減 必要なサーバ台数の減少 高負荷サーバ減少→メンテナンス手間の削減 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%以上ある その他アプリケーションの動作仕様に変化があると チェッカが判断した場合 13年8月2日金曜日
  • 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 size? latency? ボトルネックは解決するたびに移っていく 13年8月2日金曜日
  • スコア スコアを向上させる スコア算出ルールを見る 何を改善すべきかを考える スコアの揺れ 実行時の状況によって多少の揺れが出る わずかな差異(誤差)にまどわされない 改善は劇的に行う 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 ※それぞれ別のサーバ 13年8月2日金曜日
  • 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: image, js, css, ... load balance cache controls RDBMS: mysql 13年8月2日金曜日
  • application server プログラムを実行して結果を返す なんでもできる 決まった処理をやらせるにはコストが高い 内容の変わらない処理 (js/css/image) 13年8月2日金曜日
  • web server reverse proxy server 設定に従って特定のコンテンツを返す 指定された場所に置いてあるファイルなど 特定のパスについては別のサーバに取りに いって、とってきた結果を返す(proxy) 「別のサーバ」を複数指定して順番に問合 せる、とかできる 13年8月2日金曜日
  • 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月2日金曜日
  • 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日金曜日
  • 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/threads database configuration 13年8月2日金曜日
  • 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日金曜日