tjinjin's blog

インフラ要素多めの個人メモ

システムパフォーマンス本を読む〜第2章

About

前回に引き続き、第2章を読んでいきます。

システムパフォーマンス本を読む〜第1章 - tjinjin's blog

メソドロジ

  • 「パフォーマンス問題を起こしている場所を特定し、問題を分析するためにどこから始め、どのような手順を踏んだらよいかを示してくれるのがメソドロジ」
  • IOPS:1秒あたりのI/Oオペレーション。
    • AWSを使っているとディスクのIOのイメージがあるけど、ネットワークも含むと思われる。
  • レイテンシ:オペレーションがサービス提供を待つために使った時間。コンテキストによって、応答時間(オペレーションが完了するまでの時間)と同じ意味になる
  • 飽和:リソースがキューイングした作業のうち、サービスを提供できていないものの割合
  • IOPSでは計算が難しいため、レイテンシとして時間に落とし込む
  • チューニングは仕事が実行される場所からもっとも近いところで行ったときにもっとも効果的になる
  • 負荷とスループットが途中から比例ではなくなる点がある。そこがニーポイント
  • Known-Unknowns 知らないことがわかっていること。この本を読む中で、これを増やしていきたい。
  • Unknown-Unknown 知らないことを知らないこと。
  • 使用率について
    • 時間ベースの使用率:100%のときでも受け付けられる
    • 能力ベースの使用率:100%のときそれ以上の要求を受け付けられないということ
  • キャッシュのパフォーマンスを理解するには1秒あたりのキャッシュミス率を調べると良い。
  • キャッシュのアルゴリズム:MRU,LRU,MFU,NFUなど
  • キャッシュの暖まる時間
    • 毎秒約2k回のよみだしが可能な600GBのディスクがあるとき、I/Oサイズが8kBとするとキャッシュは毎秒16MBというペースでウォームアップする。キャッシュが空の場合、10時間以上かかる
  • リソース分析は、リソースがいつ限界に達するか明らかにするために使用率に焦点を絞る(IOPS,スループット、使用率、飽和)
  • ワークロード分析は、与えたワークロード、アプリのレイテンシ、実行中のエラーを探す
  • 様々なメソドロジがある(アンチパターンも含む)
  • 街灯のアンチメソッド:自分がわかっているツールで判断してしまうこと。耳が痛い話。
  • USEメソッド:システム的なボトルネックを見つけるために初期で利用すべき。すべてのリソースについて、使用率、飽和、エラーをチェックする。ツールベースの調査と比べて、網羅率が上がる。(Known-UnKnownになる)
  • マイクロベンチマーキング
    • 具体的にどんなツールなんだろう?よく聞く、Apache BenchとかJMeterとかはインダストリーベンチマーキングっぽい。
  • モデリング
    • システムをアナリティカルモデリングすることで、パフォーマンスがどのようにスケーリングするか役立てることができる。
  • スケーリングパラメータを変えてそれを図にプロットすることでパターンが見えてくる
    • 線形スケーラビリティ
    • 競合
    • コヒーレンス
    • ニーポイント
    • スケーラビリティシーリング
  • 数学的なモデルを適用することで、より多くのことを学べる。。。
  • Amdahlのスケーラビリティ法則
    • 計算機の並列度を上げたときにどのくらいの効果が見込めるかを表すもの
    • C(N) - N/(1 + α(N - 1))
    • C(N) が能力、N はCPU数などのスケーリングパラメータ。α はどれくらいシリアルかを示している?
    • ぐぐってみると上記式ではない式が書いてあって混乱している。
    • 要は並列化したからと言って単純に倍になるのではなく、プログラム内で逐次的に実行する部分が出てくるので、パフォーマンス向上の上限があるということ?
    • 本書のポイントとしてはデータを観測して、そのちくじ的に実行する部分を見極めてそこからどのくらいパフォーマンス向上が見込めるのかを推測しようということだと思う
    • アムダールの法則 - Wikipedia
  • スケーラビリティの普遍法則
    • アムダールの法則コヒーレンスの考慮を入れたもの
    • 例えば、DBとかで同じテーブルに複数アプリ書き込めないので先にロックを取得して一貫性を保証するような動き(排他制御)があるけど、そういった仕組みを実行することによるオーバーヘッドのことっぽい
    • 中身はちゃんと見てない How to Quantify Scalability
  • 待ち行列理論
    • コンピューティングで使われる多くのコンポーネントはキューイングシステムとしてモデリングできるので、キューを持つシステムの数学的研究である待ち行列理論は重要
    • 到着過程:キューイングシステムに要求が到着する間隔の性質
    • サービス時間分布:サービスセンターでサービスを提供するためにかかる時間
    • サービスセンター数:キューを捌くところ。
    • 待ち行列について - Qiita
    • ディスクをモデリングすると、使用率が80%を超えると平均応答時間が急激に悪化する。ディスクはCPUと違いプリエンプションができないためである。(言いすぎかも?)
  • 平均
    • 算術平均だけではなく、目的にあった平均を使うのが大切。また、各ツールでの平均は何の平均を示しているかも知っておく必要がありそう。
    • 幾何平均:すべての値を掛けた積のn乗根。掛け算、比率で変化していくような動きについて、平均の変化率をみたいときに主に使用するとのこと。ネットワークスタックの計測に適している。
    • 調和平均:値の個数を値の逆数の総和で割ったもの。速度の平均を取る際に利用される。データの転送速度とか
    • 時間平均:特定の対象のある時間帯の平均のこと。CPUの使用率やLAの利用率に使われる。ある一定期間内で平均してその使用率だったことを示すため、期間を平均すると、実は使用率が100%だったということもありえる
    • 減衰平均:履歴データが過去になればなるほど平均値に与える影響が少なるなくなる計算方法とのこと。
  • パーセンタイル:全体を100として小さい方から数えて何番目になるのかを示す数値。
  • 変動係数:ばらつきを一つの指標で表現するもの。変動係数=標準偏差÷平均値
  • ビジュアライゼーション
    • 折れ線グラフ
      • 全体の変化率を見ることができる
      • 細かいデータなどは見落とす可能性がある
    • 散布図
      • すべての値を見ることができる
      • 外れ値も観察できる
      • 重なりが多いと可読性が落ちる
    • ヒートマップ
      • 色によってデータ量を可視化できる
      • これを使っていくのがよさそう?
    • 表面プロット
      • 3次元の表現
      • あんまりイメージ湧かず
  • モニタリングツールでのグラフの利用

感想

数学知識のたりなさを感じました。抽象度を上げていくと数学に行き着くのかな?メソドロジがあると調査をどうすればいいってことがなくなるので、USEメソッドとかは意識しておきたいところです。後半の統計の部分はしっかりやっておきたい。

振り返りが難しい気がするので、次からまとめ方を少し見直します。