サーバープラットフォーム、プログラミングスタック、データベースベンダーに関する重大な意思決定を行うには、正確なベンチマーキングが不可欠です。しかし、多くの組織が「カジュアルなベンチマーキング」の罠に陥っています。これは、実際には別のものをテストしているにもかかわらず、一つの指標だけを測定してしまうことであり、長年にわたって続く不適切なアーキテクチャの選択につながる可能性があります。Brendan Greggは、収集されたデータが実際にテストの意図した対象を反映していることを保証するために、「アクティブ・ベンチマーキング」への移行を提案しています。
パッシブ・ベンチマーキングの落とし穴
パッシブ・ベンチマーキングは、ベンチマークを実行し、さらなる調査を行わずに結果を単に記録する際に発生します。この「放っておく」スタイルは、裏付けとなる技術的証拠を欠いた印象的な棒グラフを導き出すことが多く、なぜ特定の結果が生じたのかを判断することを困難にします。
リアルタイムの分析を行わなければ、テストを無効にする問題を見落としてしまうのは容易です。例えば、ベンチマークが遅い原因が、テスト対象のコンポーネントの性能ではなく、ネットワークのボトルネックやソフトウェアによるリソース制御である可能性があることもあります。
アクティブ・ベンチマーキングの手法
アクティブ・ベンチマーキングは、ベンチマークの実行中にシステムを分析することで、生のデータを情報へと変換します。このプロセスは標準的なパフォーマンス分析を反映していますが、ベンチマーク自体という、既知の制御されたワークロードの恩恵を受けることができます。
アクティブ・ベンチマーキングを実行するには、定常状態に達するまで、場合によっては数時間にわたりテストを実行する必要があります。その間、vmstat、iostat、mpstat、sar、top、またはeBPFベースのツールなどのOS提供ツールを使用して、システムの真の制限要因を特定する必要があります。
この手法の主な目標は、「なぜ結果が2XではなくXなのか？」という問いに答えることです。マルチコアサーバー上のシングルスレッドアプリケーションのような制限要因を特定することで、ユーザーはベンチマークが意図した通りにテストされていることを確認できます。
システムボトルネックの特定
アクティブ・ベンチマーキングは、結果を歪める可能性のある特定の一般的な落とし穴を特定するのに役立ちます。これには、隣接するプロセスによる影響、クライアントとサーバー間のネットワーク速度による制限、または意図したファイルシステムI/OではなくディスクI/Oをテストしている場合などが含まれます。
USE Method（Utilization、Saturation、Errors）のような構造化された手法を使用することで、エンジニアはボトルネックがハードウェアリソースによるものか、ソフトウェアの制限によるものかを特定できます。これにより、最終的な結論がシステムの制約に関する明確な理解に基づいていることが保証されます。
検証と統計的整合性
統計分析は数値結果に対する信頼を構築するための貴重なツールですが、アクティブ・ベンチマーキングの代わりになるものではありません。もし初期データが観察されなかったボトルネックのために欠陥がある場合、統計的手法はその誤った結果をより信頼できるものに見せかけてしまう可能性があります。
推奨されるワークフローは、まずアクティブ・ベンチマーキングを実行してデータが有効であることを確認し、その後に統計分析を行って知見を洗練させることです。この順序により、最終的な結論が確かな証拠の基礎に基づいていることが保証されます。