今月に入ってからずっと、オライリーの「詳解システムパフォーマンス」を読んでいる。
- 作者: Brendan Gregg,西脇靖紘,長尾高弘
- 出版社/メーカー: オライリージャパン
- 発売日: 2017/02/22
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
ただ、一人でもくもくと読んでいるのではなく、はてな社内での有志が集まって読み合わせ／議論を行う「輪読会」に参加する・その前に下読みをしておく、という形式で読み進めている。個人的な心意気としては、「社内輪読会に参加するために読んでいる」という感覚が最も近い（もちろん、「システムパフォーマンスに詳しくなりたい」という気持ちは前提として持っている）。
これもまた個人的な思いなのだけど、ある同一のテーマの下、はてなの Web オペレーションエンジニアを始めとした優秀なエンジニア同士の会話を聞ける・その場にいられるというだけで、それはもうとんでもなく価値のあることだと思っていて、なんというか、輪読会の開催日に向けて所定のページまで本を読んでくることは、この輪読会への参加チケットのようなものだと考えている（もちろん読み忘れたからといって参加させてくれない、といったことはない）。
そんなわけでこのエントリでは、本書の2章・メソドロジ についての読書メモを以下に載せる（1章はイントロダクションだったので特にこれといってメモはしなかった）。同じく輪読会に参加している他の人の読書メモとしては、 id:y_uuki さんのものがある。
ちなみに僕は、kibela に読書メモを取りつつ、読み進めるスタイルを取ってみている。読書メモという性質上、書籍からの引用が多分に含まれていることをご理解頂ければと思う。
「詳解システムパフォーマンス」は、僕のような人（もともとアプリケーションエンジニアをしていて、今はセールスエンジニアをやっている）でも普通に読むことのできている良書だと思うので、興味を持たれた方はぜひ手にとって頂けたらと思う。ページ数はとんでもないが、電子書籍もあるので。
2章／メソドロジ 読書メモ
2.3 コンセプト
2.3.1 レイテンシ
- レイテンシ：ネットワーク接続が確立されるまでの時間
- 応答時間＝レイテンシ＋オペレーションにかかった時間（データ転送時間など）
- Webサイトのロード時間＝名前解決時間＋TCP接続時間＋TCPデータ転送時間
- レイテンシは時間による指標なので、さまざまな計算ができる
- 比較できない他の指標（ディスクI/Oなど）もレイテンシに変換することで比較できるようになる
2.3.3 トレードオフ
- トレードオフ項目を探すようにする
2.3.4 チューニング
- パフォーマンスのチューニングはその仕事が実行される場所からもっとも近いところで行ったときにもっとも効果的になる
2.3.5 適切性の水準
- パフォーマンスチューニングはそのROIを意識しながらやるもの。
2.3.6 基準時の推奨値
- 受けたアドバイスや見つけたtipsがいつ・どんな状況によるものかについては意識する必要がある
2.3.7 負荷かアーキテクチャか
- リソースが余っているのにパフォーマンスが頭打ちならアーキテクチャに
- リソースを使い切っていることによってパフォーマンスが頭打ちなら負荷の大きさに
- それぞれ問題があると言える
2.3.8 スケーラビリティ
- スケーラビリティ：負荷の増加に伴うシステムパフォーマンスの変化のこと
- しばらくの間はスケーラビリティは線形で推移するが、特定の位置にまで推移するとリソースの競合がパフォーマンスに影響を与えはじめる。
- サチる：コンポーネントの使用率が100%となり、飽和すること
2.3.9 Known - Unknowns
- システムについて知れば知る程、Unknown - Unknown を Known - Unknown にできる
2.3.11 使用率
- 時間ベースでの使用率（パーセントビジー・非アイドル時間）と能力ベースでの使用率とがある
2.3.12 飽和
- 処理できるよりもリソースに対する要求がどれくらい多いか、を飽和（saturation）と呼ぶ
- 能力ベースでの使用率が100%となり、それ以上の要求を処理できなくなり、キューイングが始まったときに飽和は始まる。
2.3.14 キャッシング
- MRU : Most Recently Used。キャッシュ保持ポリシー。
- LRU : Least Recently Used。キャッシュ削除ポリシー。
2.5 メソドロジ
- 街灯のアンチメソッド：よくしらないので、とりあえず知っている方法で調べてみたり、ネットで拾ってきた方法でやってみたりするような「とりあえず今手元にある方法だからこの方法でやる」といった場当たり的な手法。
- ランダム変更アンチメソッド：どこに問題があるかを適当に推測し、その問題が消えるまで適当に変更を加える方法。時間がかかる上に、長期的には無意味なチューニングを残す危険がある
- 問題の記述：顧客に以下のような項目について尋ねることで、直接的な原因や解決方法がわかることがよくあるので、最初のアプローチとして最適。
- パフォーマンスに問題があると思ったのはなぜか
- このシステムは、良好なパフォーマンスで動いていたことがあったか
- 最近の変更はなにか。ソフトウェアかハードウェアか、もしくは両方か。
- この問題はほかの人やアプリケーションに影響を及ぼしているか。それとも質問者だけに影響しているのか。
- 環境はどうなっているのか。どのソフトウェア・ハードウェアを使っているのか。またそのバージョンや構成は。
- 科学的メソッド：問題・仮説・予測・検証・分析、といったステップで未知の事象について検討すること。
- 検証のために何かを変更した場合は、別の仮説検証を行なう際にはその変更を元に戻すこと。
- わざとパフォーマンスを低下させるようなことをすることでターゲットシステムについての理解を深めるネガティブテストという検証手法もある。
- 「診断サイクル」もこれによく似たメソドロジ。
- ツールメソッド：利用できるパフォーマンスツールで得られる指標をもとに分析を行なうもの。利用可能なツールだけに依存することとなり、街灯のアンチメソッドと似た側面もある。
- USEメソッド：Utilization / Saturation / Errors。システム的なボトルネックを見つけるために、パフォーマンス調査の初期の段階でつかうべきメソドロジ。全てのリソースに対してこれらをチェックする。
- USEメソッドの最初のステップは、リソースのリストを作ること。パフォーマンスのボトルネックになりうるすべてのタイプ（U / S / E）を検討する。
- 通常、エラーはすばやく簡単に解釈できるので、まずエラーをチェックする。
- ワークロードの特性の把握：システムにアーキテクチャ上の問題や構成の問題がなくても、合理的に処理できる以上の負荷がかかっている場合がある。以下の問に答えていくことでワークロードの特性がわかる。また、アーキテクチャの問題から負荷の問題を切り離すためにも役に立つ。
- ドリルダウン分析：広い視野で問題を検証するところからスタートする。それまでにわかったことにもとづいて焦点を絞っていき、関係のなさそうな領域を捨て、関係のありそうな領域を深く掘り下げていく。次の3つのステージがある。
- レイテンシ分析：オペレーションが完了するまでにかかる時間を解析し、それを細かいコンポーネントに分解し、もっともレイテンシの高いコンポーネントをさらに分解していくことで根本原因をつきとめ、定量化しようというもの。
- イベントトレーシング
- システムはばらばらなイベントを処理することで動作している
- パフォーマンス分析はこれらのイベントンの集計情報を検討することになる。集計では重要な細部が失われてしまう場合がある
- ひとつひとつのイベントを順番にトレースしていくメソドロジ。
- トレーシングしていくときには、以下のような情報を探す。
- 入力：イベント要求のすべての属性（タイプ、方向、サイズなど）
- 時間：開始〜終了時間、レイテンシ
- 結果：エラーステータス、イベントの結果、サイズ
- ベースライン統計：システムのさまざまなシステム可観測性ツールを実行し、出力をあとで参照できるようにロギングしておくこと。
- 現在のパフォーマンス指標と過去の値を比較すると手がかりを得られることがよくある。問題がはじまったときまでたどっていくことができる
- システムやアプリケーションの変更の前後にもベースラインを集めておくことでパフォーマンスの変化を分析できる。
- また、システム管理者が「何が"正常"なのか」を参照できる。
- 静的パフォーマンスチューニング：構成されたアーキテクチャの問題点を対象とする。負荷が全くかかっていないときに実施できる。他のメソドロジは負荷によるパフォーマンスの変化を分析するもので、それは動的パフォーマンスと言える。以下のような項目をチェックする。
- キャッシュチューニング
- スタックの出来る限り高い位置でキャッシングすることで、キャッシュヒットのオーバーヘッドを下げることを目指す。
- チューニング対象となるキャッシュを決める場合にもこの考え方は適用できる。
- キャッシュが有効であり、動作しているか。
- キャッシュヒット率とミス率はいくらか。
- 現在のキャッシュサイズはいくらか。
- ワークロードに合ったキャッシュにチューニングできているか。
- キャッシュに合わせたワークロードとなるようにチューニングできているか。
- ターゲットとなるワークロードのためにキャッシュを使えるようにする
- スタックの出来る限り高い位置でキャッシングすることで、キャッシュヒットのオーバーヘッドを下げることを目指す。
- マイクロベンチマーキング：単純で人工的なワークロードのパフォーマンスを検査するもの。
- 現実的かつ自然なワークロードの検査を目的とするものは「インダストリーベンチマーキング」。
2.6 モデリング
- 「モデリング」？
- パフォーマンスなどの分析を行なうことを目的とした基盤？検証用環境？
- コヒーレンス：スケーリングすることによるオーバーヘッドが、スケーリングによりもたらされる効果を上回ってしまうような状況。
- アムダールの法則：
ある計算機システムとその対象とする計算についてのモデルにおいて、その計算機の並列度を上げた場合に、全体として期待できる全体の性能向上の程度を数式として表現したもの例えば、1プロセッサでは20時間かかるプログラムがあり、その中の1時間かかる部分が並列化できないとする。したがって、19時間ぶん（95%）は並列化できるが、どれだけプロセッサを追加して並列化したとしても、そのプログラムの最小実行時間は1時間より短くならない。
- スケーラビリティの普遍法則：上記コヒーレンスについての法則？
2.7 キャパシティプランニング
- システムが負荷をどの程度うまく処理しているか・負荷が増えたときにシステムがどれくらいスケーリングするかを調査するもの。
リソースの限界
負荷のもとでボトルネックになるリソースを探るアプローチ。
要素分析
望むパフォーマンスを実現するために変更できる要素が多いときに用いるアプローチ。
- すべての要素を最高値に設定してパフォーマンスを試す
- 要素をひとつずつ変更・取り除いていってパフォーマンスをテストする
- 計測にもとづき、要素ごとにパフォーマンスが落ちた割合とそれにより節約できるコストを記録する
- 計算によって得られた構成が必要なパフォーマンスを維持していることを確認するため、改めてテストする
2.8 統計
統計の使い方とその限界をよく理解することが重要。
2.8.1 パフォーマンスの定量化
- パフォーマンス問題やそれをフィックスすることによるパフォーマンス工場の度合いを定量化すると、各問題を比較したり優先順位をつけたりすることができるようになる
- 観察と実験を通じて定量化を行なうことができる
2.8.2 平均
- 算術平均：普通の平均
- 幾何平均：全ての値を掛けた値の n 乗根
- 調和平均：値の個数を値の逆数の総和で割ったもの。
- 時間平均：時系列に取った同じ指標の平均
- 減衰平均：遠い過去の指標よりも最近の指標にウェイトをかけるもの
2.8.3 標準偏差・パーセンタイル・中央値
- パーセンタイル：全体を100として小さい方から数えて何番目になるのかを示す数値。50パーセンタイルが中央値。
2.8.5 多峰分布
たとえば読み書き・ランダム I/O とシーケンシャル I/O が混在しているワークロードでのディスクの I/O のレイテンシの分布をとると、山が2つ存在することになる。 パフォーマンス指標としての平均が使われれているのを見たとき、特にレイテンシの平均なら、分布はどうなっているのかを考える必要がある。
2.9 モニタリング
- システムパフォーマンスモニタリングによって時系列的なパフォーマンス統計を記録すると、
- 過去と現在を比較したり
- 時間帯による使用パターンを明らかにしたりすることができるようになる
- キャパシティプランニング、成長の定量化、使用のピークの確認などに役に立つ。
- 履歴データは、過去の「正常な」範囲と平均がどのようなものだったかを示し、現在のパフォーマンス指標を理解するためのコンテキストも提供してくれる。さまざまなふるまいのサイクルを見て取ることもできるようになる
2.10 ビジュアライゼーション
- 視覚化により、テキストの表示よりも多くのデータを解析できるようになる。
- パターン認識やパターンマッチングもできるようになる。
- 異なるソースからの指標の相関関係を見つけるための効果的な方法にもなりうる。
- 散布図便利そう
2.11 練習問題
- IOPS とはなにか
- 秒あたりの I/O オペレーションの数
- 使用率と飽和とは何か
- 使用率
- 時間ベースでの使用率（パーセントビジー・非アイドル時間）と能力ベースでの使用率とがある
- それぞれ、全体を1としたうちの割合でしめされる
- 飽和
- 処理できるよりもリソースに対する要求がどれくらい多いか、を飽和（saturation）と呼ぶ
- 能力ベースでの使用率が100%となり、それ以上の要求を処理できなくなり、キューイングが始まったときに飽和は始まる
- 使用率
- レイテンシとは何か
- 本来目的とするオペレーションを実行するまでに要した待ち時間、および時間による指標。
- マイクロベンチマーキングとは何か
- 単純で人工的なワークロードのパフォーマンスを検査するもの。
- メソドロジ5つ
- 問題の記述
- 本当にフォーカスすべき問題はなにかをまず明らかにするため。
- 科学的メソッド・診断サイクル
- 未知の事象に立ち向かうのに有用な手段
- USEメソッド
- これも、費用対効果の高い原因の切り分け方法として。
- ドリルダウン分析
- 着実に原因にアプローチできる
- 静的パフォーマンスチューニング
- 動的な解析はできなくとも、静的な解析であれば行なうことができることが多いため
- 問題の記述
- 唯一のパフォーマンス指標として平均レイテンシを用いたときの問題点と、その対策として99パーセンタイルを採用できるかどうか。
- 平均レイテンシのみだと、外れ値の検出・考慮を行なうことができない。多峰分布のような場合にも対応できない
- 99パーセンタイルだけでは上記の考慮を完全に行えるとはかぎらない（単峰分布を対象としている）。散布図やヒートマップなどでのビジュアライゼーションが効果的。
