じゃあ、おうちで学べる

本能を呼び覚ますこのコードに、君は抗えるか

Systems Performance: Enterprise and the Cloud 輪読会 1章 and 2章

輪読会の資料

あとで整形します。

Systems Performance: Enterprise and the Cloud

    • この会の目的

  • Systems Performance:Enterprise and the Cloud という本はオペレーティングシステムおよびオペレーティングシステムのコンテキストにおけるアプリケーションのパフォーマンス分析と向上について解説してある本です。

  • この本を通してシステムの問題点や改善点を洗い出せる 真のシステムエンジニア/管理者を目指しましょう

  • 1.5　パフォーマンスエンジニアリングの難しさと面白さ

  • システムパフォーマンスとはあくまで主観的であるということ

  • システムの複雑性による最適化の難易度と最適化と汎用性

  • 2章 データーを手に入れる前に理論化するのは大きな間違えだ。 そうすると、無意識のうちに事実に理論を合わせていくのではなく、 自然と理論に事実を合わせていこうとし始める。 —-アーサー・コナン・ドイル

  • 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 スケーラビリティ
  • スケーラビリティ：負荷の増加に伴うシステムパフォーマンスの変化のこと
  • しばらくの間はスケーラビリティは線形で推移するが、特定の位置にまで推移するとリソースの競合がパフォーマンスに影響を与えはじめる。
  • 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 メソドロジ

  • 街灯のアンチメソッド： よくしらないので、とりあえず知っている方法で調べてみたり、ネットで拾ってきた方法でやってみたりするような「とりあえず今手元にある方法だからこの方法でやる」といった場当たり的な手法

  • ランダム変更アンチメソッド： どこに問題があるかを適当に推測し、その問題が消えるまで適当に変更を加える方法。時間がかかる上に、長期的には無意味なチューニングを残す危険がある

  • 2.5 メソドロジ
  • 問題の記述： 顧客に以下のような項目について尋ねることで、直接的な原因や解決方法がわかることがよくあるので、最初のアプローチとして最適
  • パフォーマンスに問題があると思ったのはなぜか
  • このシステムは、良好なパフォーマンスで動いていたことがあったか
  • 最近の変更はなにか。ソフトウェアかハードウェアか、もしくは両方か
  • この問題はほかの人やアプリケーションに影響を及ぼしているか。それとも質問者だけに影響しているのか
  • 環境はどうなっているのか。どのソフトウェア・ハードウェアを使っているのか。またそのバージョンや構成は
  • 2.5 メソドロジ
  • 科学的メソッド：問題・仮説・予測・検証・分析、といったステップで未知の事象について検討すること
  • 検証のために何かを変更した場合は、別の仮説検証を行なう際にはその変更を元に戻すこと
  • わざとパフォーマンスを低下させるようなことをすることでターゲットシステムについての理解を深めるネガティブテストという検証手法もある

  • 「診断サイクル」もこれによく似たメソドロジ

  • 2.5 メソドロジ

  • ツールメソッド：利用できるパフォーマンスツールで得られる指標をもとに分析を行なうもの、利用可能なツールだけに依存することとなり、街灯のアンチメソッドと似た側面もある

  • USEメソッド：Utilization / Saturation / Errors。システム的なボトルネックを見つけるために、パフォーマンス調査の初期の段階でつかうべきメソドロジとなり全てのリソースに対してこれらをチェックする

  • USEメソッドの最初のステップは、リソースのリストを作ること。パフォーマンスのボトルネックになりうるすべてのタイプ（U / S / E）を検討する
  • 通常、エラーはすばやく簡単に解釈できるので、まずエラーをチェックする
  • 2.5 メソドロジ
  • ワークロードの特性の把握： システムにアーキテクチャ上の問題や構成の問題がなくても、 合理的に処理できる以上の負荷がかかっている場合がある 以下の問に答えていくことでワークロードの特性がわかる また、アーキテクチャの問題から負荷の問題を切り離すためにも役に立つ
  • 誰が負荷をかけているのか。
  • なぜ負荷がかかっているのか。
  • 負荷の特徴は何か。IOPS / スループット / ReadWrite / ばらつき（標準偏差）
  • 負荷は時系列的にどのように変化しているか。毎日のパターンはあるか。
  • パフォーマンスにおいて最高の勝利が得られるのは、不要な要求を排除していった結果。
  • 2.5 メソドロジ
  • ドリルダウン分析： 広い視野で問題を検証するところからスタートする。それまでにわかったことにもとづいて焦点を絞っていき、関係のなさそうな領域を捨て、関係のありそうな領域を深く掘り下げていく。次の3つのステージがある。
  • モニタリング：時系列的に高水準の統計情報を記録し、問題が置きているかもしれないときにそれを検出してアラートを発する。 短期間にコマンドラインツールを実行しただけでは見落としてしまうような長期的なパターンが明らかになることがある。
  • 特定：問題が疑われるときに、ボトルネックになっている可能性のあるものを特定し、調査対象を関連性のありそうな特定のリソースや領域に絞り込む。
  • 分析：特定のシステム領域をさらに解析し、根本原因を明らかにして問題を定量化しようとする。 「5つのなぜ」
  • 2.5 メソドロジ
  • レイテンシ分析： オペレーションが完了するまでにかかる時間を解析し、それを細かいコンポーネントに分解し、もっともレイテンシの高いコンポーネントをさらに分解していくことで根本原因をつきとめ、定量化しようというもの。
  • 2.5 メソドロジ
  • イベントトレーシング
  • システムはばらばらなイベントを処理することで動作している
  • パフォーマンス分析はこれらのイベントンの集計情報を検討することになる。集計では重要な細部が失われてしまう場合がある
  • ひとつひとつのイベントを順番にトレースしていくメソドロジ。
  • トレーシングしていくときには、以下のような情報を探す。
  • 入力：イベント要求のすべての属性（タイプ、方向、サイズなど）
  • 時間：開始〜終了時間、レイテンシ
  • 結果：エラーステータス、イベントの結果、サイズ
  • 2.5 メソドロジ
  • ベースライン統計：システムのさまざまなシステム可観測性ツールを実行し、出力をあとで参照できるようにロギングしておくこと。
  • 現在のパフォーマンス指標と過去の値を比較すると手がかりを得られることがよくある。問題がはじまったときまでたどっていくことができる
  • システムやアプリケーションの変更の前後にもベースラインを集めておくことでパフォーマンスの変化を分析できる。
  • また、システム管理者が「何が"正常"なのか」を参照できる。
  • 2.5 メソドロジ
  • 静的パフォーマンスチューニング：構成されたアーキテクチャの問題点を対象とする。負荷が全くかかっていないときに実施できる。他のメソドロジは負荷によるパフォーマンスの変化を分析するもので、それは動的パフォーマンスと言える。以下のような項目をチェックする。
  • このコンポーネントには意味があるか
  • 構成は、想定されるワークロードにとって意味のあるものになっているか
  • コンポーネントは、想定されるワークロードにもっとも合う状態に自動的に構成されるか
  • コンポーネントがエラーを起こし、最適ではない状態で動作していないか。
  • 2.5 メソドロジ
  • キャッシュチューニング:
  • スタックの出来る限り高い位置でキャッシングすることで、キャッシュヒットのオーバーヘッドを下げることを目指す
  • チューニング対象となるキャッシュを決める場合にもこの考え方は適用できる。
  • キャッシュが有効であり、動作しているか
  • キャッシュヒット率とミス率はいくらか
  • 現在のキャッシュサイズはいくらか
  • ワークロードに合ったキャッシュにチューニングできているか
  • キャッシュに合わせたワークロードとなるようにチューニングできているか
  • ターゲットとなるワークロードのためにキャッシュを使えるようにする
  • 2.5 メソドロジ
  • マイクロベンチマーキング：
  • 単純で人工的なワークロードのパフォーマンスを検査するもの
  • 現実的かつ自然なワークロードの検査を目的とするものは 「インダストリーベンチマーキング」
  • 2.6 モデリング
  • モデリング: パフォーマンスなどの分析を行なうことを目的とした 基盤や検証用環境
  • コヒーレンス： スケーリングすることによるオーバーヘッドが、スケーリングによりもたらされる効果を上回ってしまうような状況
  • 2.6 モデリング
  • モデリング: パフォーマンスなどの分析を行なうことを目的とした 基盤や検証用環境
  • コヒーレンス： スケーリングすることによるオーバーヘッドが、スケーリングによりもたらされる効果を上回ってしまうような状況
  • 2.6 モデリング
  • アムダールの法則：
  • ある計算機システムとその対象とする計算についてのモデルにおいて、その計算機の並列度を上げた場合に、全体として期待できる全体の性能向上の程度を数式として表現したもの
  • 例えば、1プロセッサでは20時間かかるプログラムがあり、その中の1時間かかる部分が並列化できないとする。したがって、19時間ぶん（95%）は並列化できるが、どれだけプロセッサを追加して並列化したとしても、そのプログラムの最小実行時間は1時間より短くならない
  • スケーラビリティの普遍法則： 上記コヒーレンスについての法則
  • 2.7キャパシティプランニング
  • キャパシティプランニング
  • システムが負荷をどの程度うまく処理しているか・負荷が増えたときにシステムがどれくらいスケーリングするかを調査するもの。
  • 2.7キャパシティプランニング
  • リソースの限界
  • 負荷のもとでボトルネックになるリソースを探るアプローチ。
  • 要素分析
  • 望むパフォーマンスを実現するために変更できる要素が多いときに用いるアプローチ。
  • すべての要素を最高値に設定してパフォーマンスを試す
  • 要素をひとつずつ変更・取り除いていってパフォーマンスをテストする
  • 計測にもとづき、要素ごとにパフォーマンスが落ちた割合とそれにより節約できるコストを記録する
  • 計算によって得られた構成が必要なパフォーマンスを維持していることを確認するため、改めてテストする
  • 2.8 統計

  • 統計の使い方とその限界をよく理解することが重要だよね～ という話

  • パフォーマンスの定量化

  • パフォーマンス問題やそれをフィックスすることによるパフォーマンス工場の度合いを定量化すると、各問題を比較したり優先順位をつけたりすることができるようになる
  • 観察と実験を通じて定量化を行なうことができる
  • 2.8 統計
  • 平均
  • 算術平均：普通の平均
  • 幾何平均：全ての値を掛けた値の n 乗根
  • 調和平均：値の個数を値の逆数の総和で割ったもの。
  • 時間平均：時系列に取った同じ指標の平均
  • 減衰平均：遠い過去の指標よりも最近の指標にウェイトをかけるもの
  • 2.8 統計
  • 標準偏差・パーセンタイル・中央値
  • パーセンタイル：全体を100として小さい方から数えて何番目になるのかを示す数値。50パーセンタイルが中央値 多峰分布　たとえば読み書き・ランダム I/O とシーケンシャル I/O が混在しているワークロードでのディスクの I/O のレイテンシの分布をとると、山が2つ存在することになる。 パフォーマンス指標としての平均が使われれているのを見たとき、特にレイテンシの平均なら、分布はどうなっているのかを考える必要がある
  • 2.9 モニタリング
  • システムパフォーマンスモニタリングによって時系列的なパフォーマンス統計を記録すると、
  • 過去と現在を比較したり
  • 時間帯による使用パターンを明らかにしたりすることができるようになる
  • キャパシティプランニング、成長の定量化、使用のピークの確認などに役に立つ。
  • 履歴データは、過去の「正常な」範囲と平均がどのようなものだったかを示し、現在のパフォーマンス指標を理解するためのコンテキストも提供してくれる。さまざまなふるまいのサイクルを見て取ることもできるようになる
  • 2.10 ビジュアライゼーション
  • 視覚化により、テキストの表示よりも多くのデータを解析できるようになる。
  • パター認識やパターンマッチングもできるようになる。

  • 異なるソースからの指標の相関関係を見つけるための効果的な方法にもなりうる。

  • 2.11 練習問題 割愛

最後に

社会はつらいし給料の予定が狂って経済的に厳しいけど上司は優しいので社会に参加し続けたいと思います…