【ITニュース解説】Performance Engineering: Measure Before You Optimize

システムエンジニアとして、アプリケーションのパフォーマンス改善に取り組む際、多くの人は「キャッシュの導入」「インデックスの活用」「キューの使用」といった具体的な技術的最適化手法を思い浮かべがちだ。これらは確かに有効な手段だが、最も重要なのは、これらの最適化を適用する前に、何を改善したいのかを正確に測定し、理解することである。つまり、闇雲に最適化の手法を選ぶのではなく、システムがどのように振る舞っているのかを「測定」することが、パフォーマンスエンジニアリングの基本原則なのだ。

測定を行わずに最適化を進めると、間違った問題を解決しようとしたり、システムに不必要な複雑さを加えてしまったり、あるいは全体のパフォーマンスにはほとんど貢献しない部分を最適化してしまったりするリスクがある。特定のワークロードで効果があった手法が、別のワークロードでは全く効果がないというケースも少なくない。また、最適化の中には、メモリ消費の増加、データ整合性の問題、運用上の複雑さの増大、障害発生時の対応の難しさといったトレードオフを伴うものもある。したがって、個々のコンポーネントを単独で高速化することだけが目的ではない。重要なのは、定義されたワークロードの下でシステムがどのように動作するかを理解し、その中で最もパフォーマンスに影響を与える部分を特定し、改善することである。

この理解を得るために不可欠なのが「ベンチマーク」だ。私たちはしばしば「この実装の方が速いだろう」と仮説を立てるが、それはあくまで推測に過ぎない。ベンチマークは、その仮説を裏付ける客観的な証拠を与えてくれる。ここで言うベンチマークとは、必ずしもシステムに最大負荷をかけたり、長時間テストしたりすることだけを指すのではない。それは、測定対象、ワークロード、実行環境、現在の基準となる数値（ベースライン）、加える変更、そしてその結果が明確に定義され、いつでも同じ条件で繰り返し測定できるものである必要がある。

ベンチマークを行う際には、結果に影響を与えうる様々な要因を考慮しなければならない。例えば、システムが安定するまでのウォームアップ時間、同時に処理されるリクエストの数を示す並行性、キャッシュやデータベースの状態、ネットワークの状況、裏側で動いている他の処理などがこれに該当する。例えば、数回のリクエストを順次実行して二つのAPIの実装を比較するのと、多数の同時リクエストが持続的に発生する状況でテストするのとでは、結果が大きく異なる可能性がある。前者のテストでは両方の実装が高速に見えるかもしれないが、後者ではコネクションプールの枯渇や応答時間の増加、未処理の作業がキューに溜まるといった問題が明らかになるかもしれない。ベンチマークは、私たちが答えを出したい質問を正確に反映している必要がある。例えば、スループット（単位時間あたりの処理量）の向上を検証したいなら、同等の条件下でスループットを測定すべきだし、個々のユーザー体験の改善を知りたいなら、レイテンシ（処理にかかる時間）に注目すべきだ。信頼できるベースラインがなければベンチマークの結果を正しく解釈することは難しく、再現性のあるプロセスがなければその結果を信用することはできない。

バックエンドシステムにおけるパフォーマンスは、単に「1秒あたりのリクエスト数」だけで測れるものではない。有用な測定項目には、レイテンシ、スループット、エラー率、メモリ使用量、CPU使用率、データベース時間、キュー遅延、リソース飽和度などがある。これらはそれぞれ異なる側面からシステムの挙動を教えてくれる。例えば、システムが高いスループットを達成していても、個々のリクエストが許容できないほど遅延している可能性もある。また、平均レイテンシが低くても、ごく一部の重要なリクエストが完了までに数秒かかっているケースもある。これが「レイテンシのパーセンタイル」が重要になる理由である。p50（中央値）、p95（95%のリクエストが完了するまでの時間）、p99（99%のリクエストが完了するまでの時間）といったパーセンタイル値を見ることで、平均値では隠されてしまうような遅いリクエストの存在を明らかにできる。エラー率も同様に重要だ。より多くのリクエストを拒否したりタイムアウトさせたりすることで見かけ上のスループットが上がっても、それは真の改善とは言えない。パフォーマンス測定は、個々を切り離して見るのではなく、互いに関連付けて総合的に解釈する必要がある。

実装に変更を加える前に、システムの現在の挙動を正確に把握しておくことが不可欠だ。この現在の挙動を示す参照点が「ベースライン」である。ベースラインがあれば、最適化が実際に効果があったかどうかを客観的に評価できる基準が得られる。APIのエンドポイントであれば、p50, p95, p99でのリクエストレイテンシ、特定の並行処理レベルでのスループット、エラー率とタイムアウト率、CPUとメモリの消費量、データベースクエリの実行時間などがベースラインの項目となる。測定が行われたランタイムのバージョン、ハードウェア、データベース設定、データセットのサイズなども記録しておくべきだ。ベースラインは複雑である必要はなく、現実を代表し、再現性があり、意味のある比較をサポートできるだけの詳細さがあれば十分である。

ベンチマークは、そのワークロードが私たちが関心を持つ実際のシステムの動作に似ている場合にのみ有用だ。例えば、常に多数のユーザーから同時リクエストを受けるAPIを、一度に一つのリクエストでテストしても、実際の競合やリソースの限界は隠されてしまう。より現実的なテストでは、同時ユーザー数やリクエスト数、読み取りと書き込みの比率、一般的なペイロードサイズ、データベースのレコードサイズ、キャッシュのヒット率、外部サービスへの依存などを考慮に入れるべきである。パフォーマンステストには、予想されるワークロードを評価する「負荷テスト」、システムを限界以上に押し上げる「ストレステスト」、メモリリークなどの問題を長時間にわたる負荷で明らかにする「ソークテスト」など、様々な種類がある。これらはそれぞれ異なる疑問に答えるものであり、一つのベンチマークですべての疑問に答えられることはほとんどない。

遅いAPIの原因が、必ずしもアプリケーションコード自体にあるとは限らない。ボトルネックがデータベースクエリにあることも非常に多い。だからこそ、パフォーマンスの調査はアプリケーションのレイヤーを超えて、システム全体にわたって行う必要がある。ネットワーク、アプリケーション、データベースといった全てのレイヤーがレイテンシに寄与する可能性がある。もしアプリケーションコードだけに注目すると、時間の大部分を消費している操作を見落とすかもしれない。例えば、アプリケーションが複数の要求リストを取得し、その一つ一つの要求に対してさらに個別のアイテムを取得するためのクエリを実行している場合、これはN+1クエリ問題として知られる一般的なボトルネックである。このような場合、アプリケーションの処理能力を増やしても、過負荷なデータベースへの競合を増大させるだけで、問題解決には繋がらない可能性がある。より良い調査では、リクエストごとに実行されるクエリの数、クエリの実行計画、インデックスの有無とその有効性、コネクションプールの利用率などを詳細に調べるべきだ。データベースのパフォーマンスは、APIの応答時間から推測するだけでなく、データベースの境界で直接測定すべきである。

データベースがボトルネックでない場合、次にアプリケーションのランタイムとコードを調査する必要がある。例えばNode.jsはI/O処理に優れるが、CPU負荷の高いJavaScriptコードはイベントループをブロックし、スループットの低下や遅延を引き起こす可能性がある。大規模な同期処理や過剰なオブジェクト生成も問題となりうる。CPU使用率が高い、メモリ使用量が継続的に増加している、並行処理下でレイテンシが急上昇するといった症状から、計算コストの高い処理、リソースリーク、競合といった具体的な原因を特定し、プロファイリングツールなどを活用して詳細を調べる。目標は、観測された症状と具体的な原因を結びつけることにある。

ボトルネックが特定できたら、その問題に最も適した最適化を選択する。キャッシュ、インデックス、キュー、ストリーム、ワーカースレッドなど、様々な技術が存在するが、それぞれが異なる問題を解決するためのものであり、同時にトレードオフも伴う。例えば、キャッシュはデータの無効化や整合性に関する懸念を生み、インデックスは書き込み操作にオーバーヘッドを加える。キューはメッセージの配送や再試行の考慮が必要となる。最適化の手法を選ぶ前に、「観測されているパフォーマンス問題は何か？」「どのコンポーネントがそれを引き起こしているのか？」「提案する変更がどのように改善すると考えられるのか？」「どのようなトレードオフが考えられるか？」「効果があったことを証明するために、どの測定項目を確認すればよいか？」といった質問に答えられるようにすべきだ。これらの質問は、最適化が客観的な証拠に基づいたものであることを保証する。

ベンチマークは、システムが遅くなってから行う特別なイベントではなく、日々のエンジニアリングプロセスの一部として組み込まれるべきである。そのサイクルは、「測定 → ボトルネックの特定 → 仮説の形成 → 変更 → 再測定 → 結果の比較」となる。結果を比較する際には、同じワークロードと十分に似た環境条件下で行う必要がある。そうしないと、コードの変更ではなく、別の変数が原因で改善や劣化が起こったと誤って判断してしまう可能性がある。また、重要なパフォーマンス調査の結果は記録として残し、チームがその最適化の理由や継続的な価値を理解できるようにすべきだ。厳密さのレベルは、誤った判断を下した場合のコストに見合ったものであるべきだ。パフォーマンスエンジニアリングは、単にベンチマークを実行すること自体が目的ではない。情報に基づいた意思決定を行い、その結果を検証することなのだ。

測定を伴わない最適化は、単なる憶測に過ぎない。本番環境でのパフォーマンスエンジニアリングには、常に客観的な証拠が必要である。見た目上最も速そうな実装が、現実的な条件下で本当に最速とは限らない。最も洗練されたアーキテクチャが、最も効率的であるとは限らない。そして、成功した最適化とは、単にコードがきれいになったり、より高度に見えたりするものではない。それは、許容できないトレードオフを導入することなく、測定可能な改善をもたらしたものなのだ。だからこそ、まず測定する。ボトルネックを理解する。的を絞った変更を加える。そして、もう一度測定する。このプロセスが、真のパフォーマンス向上へと導く鍵となる。