ボトルネックのイイ話 2015-06-04 ISUCON FRESH勉強会 # ボトルネックのイイ話 ---------------------- サイバーエージェント15新卒 FRESH勉強会 <!-- .slide: class="center" --> === # About Me ---------  <!-- .element: style="position:absolute;right:0;z-index:-1" --> + κeen + [@blackenedgold](https://twitter.com/blackenedgold) + Github: [KeenS](https://github.com/KeenS) + 渋谷のエンジニア + Lisp, ML, Shell Scriptあたりを書きます === # ボトルネック ------------- > ボトルネック (bottleneck) とは、システム設計上の制約の概念。英語の「瓶の首」の意。一部（主に化学分野）においては律速（りっそく、「速さ」を「律する（制御する）」要素を示すために使われる）、また『隘路（あいろ）』と言う同意語も存在する。 === # Webアプリの主な登場人物 ------------------------ * リバースプロキシ * アプリケーションサーバ * データベース ===  <!-- .slide: class="center" --> === # レスポンスタイムとスループット ------------------------------ * レスポンスタイム + リクエストを投げてレスポンスが返ってくるまでの時間 + ユーザから見たメトリクス * スループット<!-- .element: class="fragment highlight-red"--> + 一定時間内にシステムがどれだけのリクエストを捌けるか + 中の人から見たメトリクス === # スループット ------------- * スループットの最大 ≒ リソースの限界 + ネットワーク帯域 + ディスクIO + メモリ使用量 + CPU負荷 * リソースのどれか1つでも限界になったらそれ以上パフォーマンスは上がらない === # パフォマンスの目安 ------------------- * ネットワーク帯域: bpsで表わす。NICによるが 1Gbpsとか * CPU: パーセンテージで表わす。100xコア数が最大マシンに依る。 * メモリ: Bで表わす。ピンキリだが1GB ~ 128GBくらい？ * ディスクIO: Bpsで表わす。HDDなら 100Bpsとか。SSDなら10倍くらい。 テキトーに調べたので間違ってるかも === # 誰が何を --------- * リバースプロキシ: ネットワーク、メモリ、CPUなど * アプリケーションサーバl: CPU、メモリなど * データベース: CPU、ディスクIOなど === <span style="font-size: 200%">「CPUは100%に行ってないのにアプリケーションが遅いんだよ」</span> <!-- .slide: class="center" --> === # 誤り ------ * ボトルネックはCPUとは限らない * 他のメトリクスも一緒に見るべき === # 推測するな。計測せよ --------------------- * 実際に測ってみないとどこがボトルネックか分からない * 何をしてどれくらいパフォーマンスが上がったのかも分からない + コストパフォーマンスも重要 === <span style="font-size: 200%">「パフォーマンスが悪いからCPUをグレードアップしよう」</span> <!-- .slide: class="center" --> === # 誤り ------ * ボトルネックはCPUとは限らない * 例えばネットワーク帯域が詰まっているのにCPUを改善しても意味がない * 帯域が詰まってるならデータを減らす、NIC（マシン）を増やすなどをする === <span style="font-size: 200%">「多分アプリケーションを高速化したよ」</span> <!-- .slide: class="center" --> === # 誤り ------ * 計測せずに高速化しても意味がない + テストの無いリファクタリングがただの破壊なのと同じ * 高速化した気になって実際はコードが汚なくなっただけの可能性もある === # ボトルネックは変わりうる ------------------------ * 一箇所をずっと改善してても意味がない * ある程度改善したら次のリソースの限界がきてるかもしれない === <span style="font-size: 200%">「アプリケーションを10倍高速化したのにあんまり速くなってない」</span> <!-- .slide: class="center" --> === # 誤り ------ * 10倍くらい極端に高速化すると次のリソースがボトルネックになる * ディスクやネットワークの改善を考えるべき === # リソースの食い合い ------------------- * 1マシンで完結している場合、リソースの食い合いが発生しうる + リバースプロキシとアプリケーションがCPUを食い合うとか * この時、どのようにして解決するのが適切か？ === # 例題 ------ * アプリが80%くらいの負荷 * Rプロキシが20%くらいの負荷 === # 例題 ------ 1. アプリが多くCPUを喰ってるからアプリを高速化すべき 2. アプリが多くCPUを必要としてるからRプロキシはアプリにCPUを譲るべき === # 例題 ------ 1. アプリが多くCPUを喰ってるからアプリを高速化すべき 2. <span style="color: #aaa;">アプリが多くCPUを必要としてるからRプロキシはアプリにCPUを譲るべき</span> === # アムダールの法則 ----------------- * [アムダールの法則 - Wikipedia](http://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%A0%E3%83%80%E3%83%BC%E3%83%AB%E3%81%AE%E6%B3%95%E5%89%87) * ざっくり言うと比率の小さな部分を高速化しても全体の高速化は高が知れてる === <span style="font-size: 200%">「ORマッパ使うと遅そうだから生のSQL使おう」</span> <!-- .slide: class="center" --> === # 誤り ------ * ORマッピングにかかるコストは微小 * 他にもっと効率的に改善出来る部分に手をつけるべき === # リソースの配分 --------------- * 逆に、与えられたリソースからどれをどこに割り当てるかの問題もある * 理論的には負荷の高い部分に多くリソースを割り当てれば良い。 * しかしアプリケーションの構成を先に決めないといけないので事前に計測は出来ない + 知識と経験と勘 === # 例題 ------ * 画像配信アプリケーション * VPS5台 + ネット1Mbps/メモリ1G/CPU4コア/HDD * Rプロキシ、アプリ、DBにそれぞれ何台割り当てる？ + 1つのマシンに複数機能を持たせても良い。 === # チューニングは難しい --------------------- * 様々な部分の知識が必要 * システム全体を見渡した設計力も大事 * 細かなチューニングテクニックも一杯 + 今回話してないが、キャッシュ戦略とかも + Cache-Control * 知識がないと計測しても数値の意味が分からない === <span style="font-size: 200%">「やった。5%高速化した」</span> <!-- .slide: class="center" --> === # 誤り ------ * パフォーマンスは計測の度にゆらぎがある * 5%くらいなら普通に測定誤差の範囲内 * 逆に、5%くらいの改善をしても意味がない === # チューニングは楽しい --------------------- * パズルゲームみたいな部分もある * チューニング次第でスループット何十倍とかいく * 難しい分一気にパフォーマンスが上がると喜びも一入 === # ISUCON <!-- .slide: class="center" --> === # ISUCON -------- * [ISUCON公式Blog](http://isucon.net/) * Webアプリケーションチューニングコンテスト * 優勝賞金100万円 * 何でもアリ。どこをいじってもいい。 * 要はさっきの知識をフルで活用出来る === # ISUCON -------- * 何でもアリは実は珍しい。 + 他はデータベースのみ、とかアプリは触っちゃだめ、とか雁字搦め * 前回は185組（1チーム2~3人）の大きな大会 + 予選で27チームに絞られる * 界隈の有名人が揃う天下一武闘会の様相 * 楽しい === # 良質な問題 ----------- * 過去問は教育的な問題が多数。 * 過去問は全て公開。 * 腕試しに丁度良い。 === # 今年のISUCON -------------- * 予選 9/26,27 * 本戦 10/31 * 2~3人のチーム * Google Cloud Platform * 出題は[@tagomoris](https://twitter.com/tagomoris)さんと[@kamipo](https://twitter.com/kamipo)さん === <span style="font-size: 300%">Let's ISUCON</span> <!-- .slide: class="center" --> === # 参考 ------ * [ISUCONで学ぶ Webアプケーションのパフォーマンス向上のコツ 実践編 完全版](http://www.slideshare.net/kazeburo/isucon-summerclass2014action2final) * [ISUCONの話(夏期講習2014)](http://www.slideshare.net/tagomoris/isucon2014) * [kamipoさんはすごい人](https://twitter.com/search?q=kamipo%E3%81%95%E3%82%93%E3%81%AF%E3%81%99%E3%81%94%E3%81%84%E4%BA%BA&src=typd&vertical=default&f=tweets)