えいのうにっき

a-knowの日記です

読書メモ・詳解システムパフォーマンス 第12章/ベンチマーキング

「詳解システムパフォーマンス」の読書メモシリーズ・第11弾。

詳解 システム・パフォーマンス

詳解 システム・パフォーマンス

  • 作者:Brendan Gregg
  • 発売日: 2017/02/22
  • メディア: 単行本(ソフトカバー)

感想

  • ベンチマーキング、そもそもこれまでにも大した回数やってきてないけれど、それでさえちゃんとしたベンチマーキングとして成立してなかったな、ということがわかった章だった
    • というか、耳が痛いことが多かった......w
  • ベンチマークは、ツールなどを使ってただ実施するだけじゃ全然だめで、以下のようなことも同時に考えなければならず、そしてもしそれができたとすれば多くの貴重な学びも同時に得られそうだな、と思った。
    • そもそもそのツールはどんなことをおこなうツールなのか
    • それによりどのようなワークロードが発生するのか・ベンチマークツール自身の動作がベンチマーク結果に影響を及ぼす可能性はないか
    • それは、今回のベンチマークの目的に合致しているのかいないのか

なるほど・知らなかった

  • ベンチマーキングには、誤りや見落としの可能性があちこちにあるため、正しく実行しようとすることはとてもむずかしい。
    • 「広く使われているベンチマークの大半には欠陥があり、多くの研究論文は、本当のパフォーマンスを明確に示していない」
  • 優れたベンチマークのエッセンス
    • 反復可能
    • 観察可能
    • ポータブル
    • 容易なプレゼンテーション
    • 現実的
    • 実行可能
  • 効果的なベンチマーキングとは、「ベンチマークをどのように活用するか」という問題でもある
    • 「分析」と、そこから引き出す「結論」
  • ベンチマークを使うには、以下のことを理解している必要がある
    • ベンチマークソフトウェアが何をおこなっているか
    • システムはどのように応答しているか
    • 結果とディスティネーション環境はどのように関係しているか
    • 何がテストされているか
    • 制限要因は何か(一つとは限らない)
    • 結果に影響を与えるような副次的な影響はないか
    • 結果からどのような結果が引き出せるか
    • これらのニーズを満たすためには、ベンチマーク実行中(パッシブベンチマーキング)にシステムのパフォーマンス分析をおこなう(アクティブベンチマーキング)ことが大切。
  • ベンチマーキングの禁じ手
    • おざなりなベンチマーキング
      • 「実際に何を計測しているのか」がチェックできておらず、「何をテストしたのか」を理解できていないようでは、ベンチマーキングをうまく実施することはできない
    • ベンチマークに対する根拠のない信頼
      • 「人気のあるものは正しいに違いない」という誤解
      • ベンチマーキングツールの方だけでなく、ベンチマーク結果の解釈にも誤りがある場合がある
    • 分析抜きの数値
      • ベンチマークの結果は調査の最初に過ぎないことが多い、分析内容の詳細を伴う必要がある
        • 『ベンチマークの結果の分析に1週間未満しかかけていない場合には、そのベンチマークはおそらく間違っている』
      • 慎重な分析をする時間が無い場合には、チェックする時間がなかった前提条件をリストアップ、結果に添付する
    • 複雑なベンチマークツール
      • ベンチマークツール自身がベンチマーク分析を邪魔しない
      • ベンチマークのベンチマーキング問題
        • 報告された結果がベンチマークソフトウェア自身によって制限を受けているような状況
    • テスト対象の誤り
      • 対象のワークロードが関係する対象を正しくベンチマーキングできているかどうか。
    • 誤りの無視
      • ベンチマークの結果おこなわれる処理に誤りがあり、それを無視してしまうようなケース。
    • ばらつきの無視
      • 現実のワークロードでは1日の時間帯や期間内の時期などによりばらつきが生じる場合があるが、それを無視した(計測値の平均に基づいた)ベンチマーキングをおこなってしまうケース。
    • 副次的影響の無視
      • 副次的影響:バックアップなどのスケジュール処理の有無・クラウドの場合、見えない別テナントからの影響に対する考慮。
      • 対策としては、ベンチマークを長時間実行すること。
    • 複数の要因の変更
      • 二種類のベンチマークテストをおこない、その結果を比較するようなときのこと。両者の間で異なるあらゆる点に注意し、異なる要因が複数とならないようにする。
      • クラウドインスタンスを用いるような場合には、システムによる外れ値を避けるために、複数のインスタンスをテストして平均を取るなどする。
    • 競合製品のベンチマーキング
      • 競合製品に打ち勝つためだけに、極端な条件でのベンチマーキングをおこなわない。
    • 同士討ち
      • ベンチマーキングをおこなうチームが、開発チームしか知りえないパフォーマンスに関わる設定を知らされておらず、そのままベンチマークしてしまうような問題。
      • その後のバージョンで解決されたパフォーマンス問題を抱える古いバージョンのソフトウェアでベンチマークしてしまうといった問題。
    • 誤解を招くベンチマーク
      • ベンチマークが実際に計測するものは何かについての情報が意図せずに不完全なものになっているか、意図的に必要な情報を省略したときに誤解を招きやすい。
    • ベンチマークスペシャル
      • ベンチマーク最適化とも。
      • 特定のベンチマーキングにおいて高得点を取ることだけを目的として製品を作ってしまうこと。
    • 詐欺
      • 最後の禁じ手。偽りの結果を公表すること。
  • ベンチマーキングのタイプ
    • マイクロベンチマーキング
      • 人工的なワークロードを使って特定のタイプのオペレーションだけテストするもの
      • マイクロベンチマーキングの結果を使うときには、ターゲットワークロードへのマッピングが必要となる
      • ターゲットシステムのパフォーマンス分析やモデリングをおこなうと、マイクロベンチマーキングから得られたどの結果がどの程度適切なものかを判断するために役に立つ。
      • 晴れの日のパフォーマンステスト:トップスピードに注目するベンチマーク
      • 曇りの日のパフォーマンステスト:競合、副次的影響、ワークロードのばらつきなどの望ましくない条件下でのテスト
    • シミュレーション
      • 顧客がアプリケーションに与えるワークロードをシミュレートするベンチマーク。マクロベンチマークとも。
      • 問題点としては、ばらつきを無視することがあること。
    • リプレイ
      • トレースログをもとに操作をリプレイして、実際にキャプチャしたクライアントのオペレーションと比較する手法。
      • サーバー上の特長やレイテンシが変わると比較できなくなるために注意が必要
  • サニティチェック
    • ベンチマークの結果に何かおかしな部分が含まれていないかどうかをチェックすること。
    • 加えられている制限を突破してしまうような結果になってしまっていないか、等。
  • ベンチマークについての問い
    • ベンダーからベンチマークの結果を入手したとき、理解を深め、自分の環境に応用するため(実際に計測されているものは何か、その結果がどれくらい現実的で反復可能なものかを明らかにするため)に、いくつかの問いに答えてみるとよい。
      • 自分でこの結果を再現することができるか?
      • その他、一般的な問いやCPU/メモリ関連・ストレージ関連・ネットワーク関連のベンチマークについての問い。
        • P.648 - 649