More Related Content
More from Masanori Hayashi
More from Masanori Hayashi (15)
ボトルネックを解消せよ
- 2. 自己紹介
• 林 正紀 (HAYASHI Masanori)
• 1974年9月12日生(39歳) 独身
• 埼玉生まれ、埼玉育ち(ふじみ野市在住)
• 埼玉大学／大学院・数学専攻
• @m_norii
• http://norii.hatenablog.com/
• https://www.facebook.com/m.norii
Editor's Notes
- 一般論ですが、ボトルネックの解消には、「どこがボトルネックなのか」を正確に認識する必要があります
ボトルネックではない場所を一生懸命改善に取り組んでも意味がありません。
ボトルネック、という概念は、別にIT業界でなくても、日常生活のなかにも
意識しているかしていないかは別として
たくさんあると思います。
以下、２つほど、実例を出します。
- １つは交通渋滞です。
車を普段よく乗られる方は実感あるかなと思います。
「ここ信号みじけーから、めちゃこむんよなぁ」とか
「うわ、こんなとこ緊急工事？ありえねー」とか。
特定の箇所で車が一定時間に通れる量が制限されることにより発生するボトルネックですね
- 2つめは業務上のボトルネックです。
（実はシステム的なボトルネックよりも往々にして問題だったりしますよね）
たとえば、この作業するのに、先行してAとBとCがそろってないといけないのにCがまだ完成してなくて
そこが全体の足を引っ張っているとか。
スライドの画像は、これは架空の稟議書ですね。係長と課長と部長と取締役。。。のハンコが必要、とか。
こういう会社の正式書類ものって、いろんな人のハンコがひつようで、よく「スタンプラリー」とか揶揄されたりしますね。
ここまでのハンコが必要な会社はさすがにないと思いますが（ねえよ）
何か仕事を進めるうえで、この件は誰それさんに話をとおしとかないといけない、が
誰それさんが出張で、出社が3日後だ～とか、そういうことってありますね。
逆に言うと、そういうボトルネックになりそうな箇所を予め予測して、どのタイミングで誰に何のネゴをとる、みたいなことが重要っすね
- で、ボトルネックと関連したワードで「クリティカルパス」ってのをここで話します。
エンジニアの方で、IPAの基本情報処理試験とか受けた方は「あ～、あったあった」って思うかもですね
で、この図の見方を説明しますと
丸印は、ある一連の仕事のある時点での「状態」を表します。
矢印、フキダシで、A~Gってふっていますが、これが、ある一連の仕事を達成するために必要な１つ１つの「タスク」です。
で、各タスクがこのくらい工数かかるよ、っていうのを記載しています。
矢印が○をはさんでつながっているのは、タスク間に前後関係があることを表しています。
たとえば、Bというタスクは、Aというタスクが終わらないと始められない、という意味です。
クリティカルパスというのは、この仕事全体を進める上で「このタスク群が遅延すると全体が遅延する」タスク群のことをいいます
で、ここで皆さんにお聞きします。上の図で、クリティカルパスは上中下、どのルートだと思いますか？
- 正解は真ん中のルートですね。
で、この図はさらにどう分析するかというと、クリティカルパスがわかると
じゃあ全体の仕事を早めたいとしたら、どこに手を入れればいいかわかる、ということです。
ここでいえば、DかEのタスクを、何らかの方法で工数削減できれば、より早く仕事を終えられます。
ただし、DEのタスクだけをずっと注意していればいいかというとそうではなく
あるところで、別のルートがクリティカルパスに変わることが有ります。
上の図では、例えば、Dのタスクが5日から3日に、2日縮められたとして、じゃあ全体が2日縮まるかというと・・・
そうじゃないですね。
FGのルートが7日かかるので、今度はこちらがクリティカルパスになります。
重要なのはクリティカルパス（ボトルネック）は、１つを解消すると、別の所が必ずクリティカルパス（ボトルネック）になります
なので、パフォーマンス改善という作業はこの作業のひたすら繰り返し、なわけですね。
- 前段長くなりましたが、では、実際のシステムにおいてのボトルネックの話に移ります。
上の図はかなり簡略化して書いています。
この図の中で、どんなところがボトルネックになるかあげてください。
（たくさんあると思います）
- はい、実はざっと考えられるだけでも、このくらいはボトルネックとなる要因が考えられます。
この中で一番足を引っ張るものが、システム全体の「ボトルネック」になるわけです。
次からはそれぞれについて、もう少し具体的なところに掘り下げていきます。
- 書いたソースコードは文法的なミスはないのですが、これ、「そもそも」おかしいところがあるんですが、わかりますか？ (エンジニア向け質問）
- で、この他にも、効率が悪いところをあぶりだすのに、プロファイラというツールを使うこともできます。
XhprofはPHPでは比較的ゆうめいどころのツールで（Facebookの人が作った）
こんな感じで、効率悪いところを、グラフィカルに表示してくれたりしています
- では、次のポイントです。今度はWebとDBなどの通信について。
- 実際の案件でも、WebとCacheサーバ間のトラフィック量が問題になったことがあり
この図にあるように、WebサーバにCacheも内包することで、解決をはかりました
- ・・・のですが、どんなケースが他にあるか、わかりますでしょうか？
ヒントとしては、今度はWebフロントエンドを担当している方に関わってくる部分です。
- Chrome, 他のブラウザでも同様のツールありますが
こういったツールで、そもそも1ページ内にどれだけ画像があって、どれだけ通信しているか
どれだけ時間がかかっているかを調べられます
- Webブラウザで確認できるものであれば、さきほどのChromeでいいですが
ネイティブ通信ものの場合はそれも確認が難しいので
たとえば、Fiddlerのようなローカルで動作するプロキシツールを間に挟んで確認するって方法もあります。
ただし、FiddlerはWindowsのツールです。
- この対策は、実際の案件でもUnityのアセットバンドルの転送量が問題なったことがあって
そちらの対策として導入しました。
