ボトルネックを調査する方法

このトピックでは、ボトルネックを調査するための推奨プロセスについて説明します。

問題の原因について

問題の原因は、ハードウェアに関連している場合もあれば、ソフトウェアに関連している場合もあります。 リソースが十分に活用されていない場合は、一般に、システムのどこかにボトルネックがあると考えられます。 ボトルネックは、ハードウェアの制限、ソフトウェアの非効率的な構成、またはその両方が原因となって発生します。

ボトルネックの特定では、あるボトルネックを緩和すると次のボトルネックが見つかることもまれではなく、作業を積み重ねが必要になります。 こうしたボトルネックの特定と緩和について科学的に説明することがこのトピックの目的です。 システムは、短期間なら最大限の性能を発揮できます。 しかし、スループットを維持するには、そのシステムの最も遅いコンポーネントの速度でしか処理できなくなる場合もあります。

連続的アプローチの使用

ボトルネックは、システムのエンドポイント (入り口/出口) で発生することも、その間のどこか (オーケストレーション/データベース) で発生することもあります。 ボトルネックの場所を切り分けることができれば、原因を特定するための体系的なアプローチを開始できます。 ボトルネックを緩和できたら、再度パフォーマンスを測定して、システムのどこか別の場所で新たなボトルネックが発生していないかどうかを確認することが重要です。

ボトルネックの特定と修正のプロセスは、一度に 1 つのパラメーターのみを変更して、その 1 つの変更の影響を確認するためにパフォーマンスを測定するという、連続的な方法で行う必要があります。 一度に複数のパラメーターを変更すると、変更の効果がわからなくなってしまう可能性があります。

たとえば、パラメーター 1 を変更するとパフォーマンスが改善するのに、同時にパラメーター 2 を変更するとマイナスの効果が生じ、パラメーター 1 の変更の効果が帳消しになる場合が考えられます。この場合、最終的な効果はゼロになりますが、 その結果、パラメーター 1 を変更した効果が偽陰性、パラメーター 2 を変更した効果が偽陽性になってしまいます。

テストの一貫性

設定を変更したら、その変更の効果を検証するためにパフォーマンス特性を測定することが重要です。

• ハードウェア: ハードウェアが異なると、矛盾した動作が表示され、ラップトップを使用しないなど、誤解を招く結果が生じる可能性があるため、一貫性のあるハードウェアを使用することが重要です。

• テスト実行時間: 結果が単にピークではなく、実際に持続可能であることを確認するために、一定の最小期間のパフォーマンスを測定することも重要です。 テストを長時間実行するのにはもう 1 つの理由があります。それは、システムの最初のウォームアップ期間/準備期間が終わった状態でテストできるようにするためです。これにより、すべてのキャッシュにデータが格納され、データベース テーブルが予想の数に到達し、制限が作動してスループットが制御された状態 (あらかじめ定義されたしきい値に到達した状態) でテストを実行できます。 このアプローチは、維持可能な最大スループットを特定するのに役立ちます。

• テスト パラメーター: テストの実行からテストの実行まで、テスト パラメーターを変更しないことも不可欠です。 たとえば、マップの複雑さやドキュメントのサイズを変更すると、スループットや待機時間の結果が変わってしまう可能性があります。

• クリーン状態: テストが完了したら、次のテスト実行を実行する前にすべての状態をクリーンアップすることが重要です。 たとえば、データベースに蓄積された履歴データが実行時のスループットに影響を与える可能性があります。 サービス インスタンスを再利用すると、メモリ、データベース接続、スレッドなどのキャッシュされたリソースを解放できます。

期待値: スループットと待機時間

展開されたシステムにある程度のスループットや待機時間を予測することは正当です。 高いスループットと短い待機時間の両方を実現しようとするのは、同時に 2 つの別の方向に向かおうとするようなものですが、 現実として、最大限のスループットと妥当な待機時間を予測することはできます。 スループットが高まるとシステムのストレスが増加して (CPU 消費、ディスク入出力の競合、メモリ不足、ロックの競合が増加するなど)、待機時間にマイナスの影響が及ぶ可能性があります。 システムの最適処理能力を見極めるためには、すべてのボトルネックを特定し、それらを解消することが重要です。

ボトルネックは、データベースに存在するレガシ データ (完了したインスタンス) がクリーンアップされていないことが原因で発生する可能性があります。この場合、パフォーマンスが低下する可能性があります。 この問題は、システムがデータを削除するのに十分な時間を確保することによって解消できます。 ただし、バックログが蓄積された原因を特定して、その問題を解決することが重要です。

バックログの原因を特定するには、履歴データを分析し、パフォーマンス モニター カウンターを監視することが重要です (使用パターンを特定してバックログの原因を診断するため)。 バックログの蓄積は、大量のデータを毎晩バッチ方式で処理するような場合によく見られる状況です。 システムの性能とバックログからの回復能力を知ることは、負荷が集中した状態を処理するためのハードウェアの要件や、スループットの予想外のピークが生じた場合に対処するにはシステム内にどの程度の余地があればよいのかを見積もるうえで役に立ちます。

維持可能な最大スループットを得られるようにシステムをチューニングするには、展開するアプリケーション、システムの長所と短所、および特定のシナリオの使用パターンについての深い理解が必要です。 ボトルネックを特定し、維持可能な最大スループットを確実に予測するためには、実稼働環境で使用されるものに近いトポロジで徹底的なテストを行うしかありません。

このセクションの他のトピックでは、そのトポロジを定義するためのプロセスを紹介し、ボトルネックを緩和するにはどうすればよいか、さらには、そもそもボトルネックが発生しないようにするにはどうすればよいかを説明します。

スケーリング

ボトルネックは、展開されたトポロジのさまざまな段階で発生します。 ハードウェアをアップグレードすることによって対処できるボトルネックもあります。 ハードウェアのアップグレードには、スケール アップ (CPU、メモリ、キャッシュなどの追加) とスケール アウト (サーバーの追加) があります。 どちらを利用するかは、発生したボトルネックの種類と、構成するアプリケーションによって決まります。 以下は、発生したボトルネックに基づいてハードウェア展開トポロジを変更する方法についてのガイダンスです。 スケールアップ/スケールアウトを利用できるようにするには、アプリケーションを一から構築する必要があります。例えば：

• アプリケーションがシリアル化されていて、1 つのスレッドの実行に依存している場合は、CPU やメモリを追加してサーバーをスケール アップしても問題は解消されません。

• サーバーを追加しても拡張不可能な共通リソースの競合が増加するだけである場合は、サーバーを追加してシステムをスケール アウトしても役に立ちません。 ただし、スケール アウトにはまた別のメリットもあります。 クアッド プロセッサのサーバーを 1 つ展開する代わりにデュアル プロセッサのサーバーを 2 つ展開すると、追加のスループットを処理するための拡張と可用性の高いトポロジの実現という両方の目的に対応する冗長サーバーを実現できます。