コスト削減のアイデア
A 社のオンライン ビジネスの安定性基準は、企業が承認した TPS に達すると、ピーク CPU 使用率が 60% を超えず、これが安定した状態です。
このような背景から、テスト部門は、ビジネス TPS 要件を満たす際のパフォーマンス テストとチューニングを通じて、テスト対象アプリケーションのピーク CPU 使用率を削減することを目的として、CPU 消費量が高い一部のシステムに対して統合ソートと特殊パフォーマンス テストを実施しました。ピーク CPU 使用率が大幅に低下した場合は、デプロイされたノードの CPU コア数を減らし、ビジネス シナリオに基づいて再テストを実施します。ピーク CPU 使用率が依然として 60% 未満であり、TPS に異常がないことが判明した場合は、運用環境デプロイメント ノードの CPU コア数が削減され、他のサービスのデプロイメントにより多くのリソースが解放されます。生産監視手法と合わせて、一定期間内に異常がなければコスト削減が成功したとみなします。
具体的な考え方を図に示します。
以下、図に示したコスト削減のステップを説明します。
1) パフォーマンス ストレス テスト: テスト対象のアプリケーションに対して高同時実行ストレス テストを実施します。
2) パフォーマンス評価: パフォーマンス テスト プロセス中にパフォーマンス指標を確認することで、考えられる最適化ポイントを評価します。パフォーマンス指標には、TPS、応答時間、CPU 使用率、メモリ使用量、コード応答時間、フルリンク トポロジなどが含まれます。
3) パフォーマンス分析: 以下の 3 つの側面を含みます。
❑ CPU 消費量が高いテスト済みアプリケーションの CPU ホットスポット分析とスレッド追跡分析を実行します。ビジュアル レポートを使用して、CPU 使用率が高いときに実行されているアプリケーションのコード セグメントとスレッド ID を表示し、コード セグメントのソース コードとスレッド コール スタックを詳細に分析して、CPU 使用率が高い根本原因を特定します。
❑ メモリ消費量が多いテスト済みアプリケーションの場合、メモリパースペクティブ分析を通じて、JVM の新世代、旧世代、GC、オフヒープ メモリ、メモリ オブジェクト、クラス オブジェクト、およびその他の指標を低コストの方法で取得できます。視覚的なレポートを通じて異常なインジケーターや曲線をリアルタイムで表示し、対応するメモリ オブジェクトを分析して、根本原因を特定します。
❑ コード応答時間が長いテスト済みアプリケーションの場合、サブメソッド呼び出し分析を通じて、リアルタイム バイトコード拡張テクノロジを使用して、コード内でトリガーされたサブメソッド呼び出しのマイクロ秒レベルの時間のかかる分析を実行します。最も時間のかかるコード セグメントを特定したら、ソース コード分析を開始して、ソース コード ロジックを確認し、根本原因を特定します。
4) パフォーマンスのチューニング: プロジェクト チームと連絡を取り、見つかった CPU、メモリ、スレッド、およびコードの問題を修正します。
5) コスト削減の検証: 同じシナリオと同時実行数を使用して、最適化されたテスト対象アプリケーションを検証し、テスト対象アプリケーションの CPU インジケーターとメモリ インジケーターが改善されていることを確認します。最適化が確認されたテスト対象アプリケーションについて、CPUおよびメモリ構成を削減し、同じシナリオおよび同時実行数で性能テストを実施し、ダウングレード後の性能指標がオンライン基準を満たしていることを確認します。
ダウングレード後に測定したアプリケーション指標がオンライン基準を満たしていない場合は、性能評価ステップからやり直して分析をやり直してください。
コスト削減事例
上記のコスト削減の考え方に基づき、A社における実際のシステムチューニングのプロセスは以下のとおりです。1) 問題の説明: 高同時実行ストレス テスト シナリオでは、システム内のアプリケーションの平均 CPU 使用率が図 10-19 に示されており、実際の CPU 使用率は 70.07% に達し、最高値は 100% です。
図 10-19 アプリケーションの CPU 使用率 2) 位置付けプロセスの説明: パフォーマンス分析プラットフォームでのホット スポット分析により、CPU のほとんどがログ スタックの登り操作で消費されていることがわかります。
CPUホットスポット分析チャート
3) パフォーマンスのリスク ポイントを特定します。同時実行性が高い状態でログが頻繁に上昇すると、過剰な CPU 消費が発生し、アプリケーション全体のエクスペリエンスに影響を与えます。
4) 最適化の提案: 開発仕様の観点から、行番号で検索することはコストが高すぎ、リソースの無駄が多すぎるため推奨されません。正確な出力ログ文字列を使用することが最善です。どの段落に問題があるのかを示す記号。コードロジックに問題があります。この場合、まず、行番号を出力するパラメータ %I および %L を削除することをお勧めします。次に、%method または %m 構成を削除します。現在、デバッグ、情報、警告、およびエラー レベルのログは同じ出力形式のセットを使用します。つまり、パターン構成は同じです。デバッグと情報は使用しないことをお勧めします。メソッド名と行番号を出力しますが、Warn と Error を直接出力しても問題ありません。
5) 実際の最適化効果: 構成を変更することにより、TPS は 260 トランザクション/秒から 320 トランザクション/秒に増加し、25% 以上増加しました。
6) コスト削減効果: アプリケーションサーバーの構成を50%削減しても、全体の指標は目標値を達成しています。