# ワークロードの特性の把握 ## 定義 ワークロードの特性の把握(workload characterization)は、結果としてのパフォーマンスではなくシステムに対する入力(負荷)そのものに注目することで、負荷に起因する問題を明らかにする単純かつ効果的な観察型メソドロジである。システムにアーキテクチャ・実装・構成上の問題がなくても、合理的に処理できる以上の負荷がかかれば問題は起きる。特性は次の4つの問いに答えることで把握する。(1) 誰が負荷をかけているか(プロセスID・ユーザーID・リモートIPアドレス)、(2) なぜ負荷がかかっているか(コードパス・スタックトレース)、(3) 負荷の特徴は何か(IOPS・スループット・方向・タイプ、必要なら分散も含める)、(4) 負荷は時系列的にどう変化しているか(日次パターンの有無)。答えに予想があっても意外な結果が出ることがあるため、全項目をチェックする価値がある(例: 想定していたウェブサーバーではなくインターネット全体からの DoS 攻撃だったケース)。不要な仕事(誤動作したループ、構成のまずさ、攻撃)を発見できれば、それを取り除くだけでパフォーマンスが向上する。取り除けない場合は、リソースコントロールを使ってワークロードを抑制する対応も取れる。ワークロードの特性情報はシミュレーションベンチマークの入力にもなり、負荷とアーキテクチャの問題を切り分ける手がかりにもなる。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] §2.5.11) 12章はワークロードの特性の把握を、ベンチマークの妥当性を検証するメソドロジとして位置づける。ベンチマーキングの失敗パターンのひとつ「テスト対象の誤り」(§12.1.3.5)では、既存の本番環境があればワークロードの特性の把握でデバイスI/Oからアプリケーションへの要求までの実際のワークロードを計測でき、もっとも深い関連性があるベンチマークを選ぶために役立つとされる。分析できる本番環境がない場合は、シミュレーションか意図しているワークロードのモデルを作り、ベンチマークデータのステークホルダーを巻き込んでテストをチェックすべきだとされる。§12.3.5では、比較のために本番ワークロードの特性を調べることで、ベンチマークと現在の本番環境との間にどれぐらいの関係があるかがわかるとされ、メソドロジの一覧(表12-2)で「観察による分析」に分類されている。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 12 ベンチマーキング]] §12.1.3.5, §12.3.5) ## 横断的知見 - 2章はワークロードの特性の把握を本番環境で発生している問題(不要な仕事・DoS攻撃等)の発見メソドロジとして説明するが、12章はこれをベンチマーク選択・妥当性検証という異なる目的で再利用する。同じ「誰が・なぜ・何を・どう変化するか」という観察の枠組みが、障害調査(2章)とベンチマーク設計(12章)という異なる場面に転用できることを示しており、USEメソッドが12章で診断からベンチマーク限界特定へ転用されるのと同型の関係にある(いずれも観察型メソドロジが目的を超えて再利用される)。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] §2.5.11, [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 12 ベンチマーキング]] §12.1.3.5, §12.3.5) - 16章のNetflix実務調査では、2章が定式化する「誰が・なぜ・何を・どう変化するか」という4問いの正式なチェックリストは明示的に踏まれていないが、そのうち「何を(負荷の特徴)」に相当する観察――VMが「サブコンポーネントではなくワークロード全体」を実行しているのに対しコンテナは1コンポーネントのみを実行している、という違い――がLLCヒット率低下の3つの候補要因のひとつとして自然に浮上している。これは、ワークロードの特性の把握が独立した手順としてだけでなく、PMCで観測した異常(低IPC)の解釈を助ける補助的な視点としても機能しうることを示す実例であり、2章・12章が示す「メソドロジとして明示的に実行する」形とは異なる、暗黙的な適用のされ方といえる。(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] §2.5.11, [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 16 ケーススタディ]] §16.1.5, §16.1.8) ## 未解決の問い - 「誰が」「なぜ」「何を」「どう変化するか」という4問いのフレームワークは、[[HPCワークロード特性化]]のようなドメイン特化ワークロード分析とどこまで概念を共有し、どこで分岐するか。 - 想定と異なる負荷源(DoS 攻撃のような)を検出する4問いのチェックは、どの程度自動化・常時モニタリング化できるか、それとも障害発生時の手動調査に留まるべきか。 - 12章は「分析できる本番環境がない場合はシミュレーションかモデルを作る」と述べるにとどまり、2章の4問いのフレームワークを本番環境が存在しないケース(新規開発中の製品等)にどう適用するかの具体的手順は示していない。 - 16章のように4問いのチェックリストを明示的に踏まずワークロードの違いに気づく場面が実務では多いとすれば、正式なメソドロジとしての価値はどこにあるのか。他章のケーススタディで、4問いが省略されて見落としにつながった失敗例があるか確認したい。 ## 関連 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] — ワークロードの特性の把握の原典解説(§2.5.11)。 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 12 ベンチマーキング]] — ベンチマークの妥当性検証への応用(§12.1.3.5, §12.3.5)。 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 16 ケーススタディ]] — VMとコンテナのワークロードの違い(全体実行対サブコンポーネント実行)がLLCヒット率低下の一因として暗黙に観察された実例(§16.1.5, §16.1.8)。 - [[HPCワークロード特性化]] — HPC ドメインに特化したワークロード特性化の関連概念。 - [[ベンチマーキング]] — ワークロードの特性の把握を用いてベンチマークと本番環境の関連性を検証するメソドロジ全般。 ## 出典 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 2 メソドロジ]] §2.5.11 - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 12 ベンチマーキング]] §12.1.3.5, §12.3.5(ベンチマークの妥当性検証への応用) - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 16 ケーススタディ]] §16.1.5, §16.1.8(ワークロードの違いへの暗黙的な言及)