アプリケーションパフォーマンスが70%向上、mPaaSフルリンクストレステストの実装原理と実装パスを調査

事業背景

モバイル開発業界がストック時代に入るにつれて、アプリ全体のアーキテクチャの負荷容量と各リンクの最適化が徐々に開発者の注目の的になってきています。

ストレス テストは、上記の機能を実現するための主なソリューションです。一般的には、ストレス テストに基づいて判断します。

バックエンドビジネスの負荷ボトルネックをテストします。
全体的なアーキテクチャのパフォーマンスを評価します。
安定したビジネスピーク。
各ノードの弱い関係を識別します。
システムリソースを最適化します。
ショートボード効果を回避します。
アクティビティや新しいアプリケーションの起動によって発生する突然のトラフィックによるユーザー エクスペリエンスの低下を回避するために、正確なユーザー収容能力を運用の証拠として提供します。

本日は、フルリンクストレステストソリューションの実現原理と実装パスを紹介します。

フルリンクストレステストと原則

通常、推定計画には、負荷パフォーマンス = 単一マシンのパフォーマンス * マシンの合計数という式を単純に適用できます。しかし、実際のシナリオでは、DNS、ゲートウェイ、データベース、その他のリンクなど、多数のビジネス ノードが関係することが多く、これが全体的なビジネス パフォーマンスにつながるボトルネックとなる可能性があります。したがって、実際のサービス容量は予想と大きく異なる可能性があります。

通常、ユーザーは、loadrunner などのソリューションを使用して、実稼働環境でサーバー パフォーマンスのストレス テストを実装します。しかし、mPaaS アプリケーションでは、複雑なデプロイメントは MGS ゲートウェイを通過できず、これらの問題点を解決するために高コストやその他の困難が生じます。

mPaaS チームは、多くの顧客の要望に基づいて、MGS フルリンク ストレス テスト ソリューションを提供しています。

フルリンク ストレス テスト ソリューションと以前のテスト ソリューションの最大の違いは、視点の違いです。フルリンク ストレス テスト ソリューションは、クライアントの視点をエントリ ポイントとして扱い、サーバー リンク全体をブラック ボックスとして扱い、実際の要求と応答を評価の基準として使用し、実際のビジネス要求、実際のデータ トラフィック、実際のユーザー習慣をシミュレートして、可能な限り最も現実的な評価結果を実現します。

リンクの並べ替え

標準的なデータリンクでは、一般的に次のモデルが使用されます。

フルリンクストレステストでは、サーバー実装全体をブラックボックスと見なすため、前半に重点を置く必要があります。要点は次のようにまとめられます。

1. 依頼者が工事を依頼する。

2. クライアント要求が送信され、MGS ゲートウェイを通過します。

3. クライアントは、MGS ゲートウェイから返された応答を解析し、正しく処理します。

4. 高同時実行クライアント要求クラスタリングを実装します。

上記を検討した後、次のような問題点をまとめることができます。

難しさ1: クライアントリクエストの構築

mPaaS モバイル ゲートウェイ RPC 通信は、HTTP プロトコルに基づいて実装された標準化されたインターフェース方式です。 HTTP リクエスト標準を再利用することを前提として、ヘッダーと本文を実際の区別として使用して、一連のデータ交換形式が定義されています。大まかに言えば、ヘッダー内の Operation-Type を実際の API ポインターとして使用し、ルールに従ってボディ部分をカプセル化して転送するということです。

このステップでは、実装ソリューションとして JMeter を使用します。 Jmeter の柔軟なスクリプト機能により、クライアントの実際のリクエストのシミュレーションを適切に実装できます。

難易度2: データの暗号化と復号化

mPaaS モバイル ゲートウェイ RPC 要求の独自のデータ暗号化方法により、要求のより複雑な部分が構築されます。クライアント側の既存のテスト ソリューションではこの部分の機能をカバーできないため、ゲートウェイ サーバーの署名検証機能と暗号化機能をオフにしてストレス テストを実施することがよくあります。

この方法の隠れた危険性は、暗号化と復号化がゲートウェイ サーバーにもたらす計算負荷を見積もることが不可能なことです。

経験上、暗号化および復号化アルゴリズムの構成が異なると、ゲートウェイのスループットに 20% ～ 40% の影響が及びます。この段階では、JMeter プラグイン MGSJMeterExt は、ユーザーの本番環境に基づいて Financial Line SRE チームによってカスタマイズおよび開発されました。このプラグインは、リクエスト本体の暗号化と復号化のプロセスを逆に実装し、ストレス テスト スクリプトのオーケストレーションに暗号化部分を含めることができるようになりました。

難易度3 署名ビルドをリクエスト

mPaaS モバイル ゲートウェイ RPC 要求に固有の署名検証メカニズムも非常に特殊です。データの暗号化と復号化と同様に、現在クライアント側にこの機能をカバーできるソリューションは存在せず、クライアントはテストのためにインターフェイス署名検証を閉じることを選択することがよくあります。また、MGSJMeterExt の助けを借りて、メッセージの正しい署名を JMeter で実現し、サーバーで検証することができます。

難しさ4: ストレステストクラスタ環境の展開

ストレス テストでは、実際の結果を得るために、実際のトラフィックの入口と同時接続の実際の数に重点を置く必要があります。しかし、ストレステスト環境を自社で実装したり、クラスターの導入に高額なコストがかかると、無駄な出費になります。

したがって、ストレス テスト プラットフォームとして Alibaba Cloud PTS を使用することをお勧めします。他のソリューションと比較して、導入が簡単、Jmeter スクリプトのサポート、実際のトラフィックなどの利点があります。また、より詳細なストレス テスト レポートをユーザーに提供することもできます。

概要

上記のモデルは、簡単にまとめると次の構造になります。

フルリンクソリューションと実装

パート1 事前準備と調査

初期段階では、実際のストレス テストに必要な準備とデータ サポートを提供し、ストレス テストの目標と全体的な方向性を確立することが目標です。

1.1 目的とデータの準備

1. お客様は、独自のストレス テストの目標と目的を明確に定義する必要があります。ストレス テストの目標に基づき、過去の運用データを参照して、顧客は、関連する特定のビジネス カテゴリとユーザーの行動習慣、およびビジネス全体における各習慣の相対的な重みを提供する必要があります。

1.2 クライアントの準備

1. クライアントは、ログインなどの事前手順が含まれているかどうか、ホームページの更新などの必須手順が含まれているかどうかなど、対応するビジネス目標に基づいて、クライアント実装に関係する可能性のあるインターフェイスとデータフローを整理し、パケットをキャプチャしてこの手順で実際の要求と応答を収集し、期待を満たす値の条件を決定する必要があります。

2. このステップにはさまざまなビジネス構造が関係しており、準備はサーバー インターフェイスによって完了することもできます。

1.3 サーバーの準備

1. サーバー側では、1.2 でカウントした関連インターフェースに基づいて、実際のデータベースがテスト データによって汚染されることを回避するために、関連するデータ シールドを作成します。

2. mPaaS フルリンク ストレス テストではサーバーがブラック ボックスとみなされるため、サーバー上の各サービスのパフォーマンス インジケーターを監視して、その後のサーバー チューニングの基礎を提供する必要があります。

1.4 MGSJMeterExtプラグインの準備

MGSJMeterExt は実際のゲートウェイ環境に応じてカスタマイズする必要があるため、ユーザーは次のデータを提供する必要があります。

1. ワークスペース関連の環境データ

2. 暗号化アルゴリズムと公開鍵

質疑応答

Q: ストレス テスト スクリプトを実装するにはどうすればよいですか?

A: 弊社の専門チームと現地の受講生が、簡単なシナリオでストレス テスト スクリプトのトレーニングを実施します。実際のシナリオでは、ログイン トークンの取得や明確な事前手順など、ビジネスの複数のリンクが含まれる場合があります。このタイプには複雑なビジネス シナリオが含まれるため、顧客は Alibaba の専門家チームの支援を受けて自分で完了する必要があります。

Q: なぜフルリンクなのですか?

A: 当社のストレス テスト スクリプトはクライアント ロジックに基づいて実装されていますが、実際には実際のデータ要求をシミュレートし、データ リンクとノード全体を含めてサーバーの応答が期待どおりであるかどうかを確認します。

Q: リンクインジケーターを追跡するにはどうすればよいですか?

A: ストレス テスト ソリューションはブラック ボックスに基づいています。システムの pts インジケーター、リクエスト パラメータ、戻り率、期待される結果の成功率をチェックすることで、ユーザーの観点からアーキテクチャ全体のパフォーマンスを検証します。一部のバックエンド指標については、顧客によって使用されるサーバーアーキテクチャに多くの違いがあるため、そのようなバックエンド指標については、通常、対応するサービスプロバイダーが関連する監視ソリューションを提供できるため、mPaaS で処理する必要はありません。

Q: PTS を使用する理由は何ですか?

A: mPaaS チームは実際に、顧客の PTS スクリプトの作成を支援するために MGS 通信ソリューションを提供しています。 PTS の使用は必須ではありません。関連する Jmeter クラスタ展開環境のみを提供する必要があり、ユーザーは PTS 関連のリソースを自分で購入する必要があります。しかし、mPaaS チームは複数のケースを評価した結果、PTS を使用する方が比較的コスト効率が高く、より期待されるストレス テスト環境と完全なストレス テスト レポートを提供できることがわかりました。したがって、ストレス テストには PTS を使用することをお勧めします。

Q: 2c4g、4c8gの場合、どのようなパフォーマンス指標を達成すべきかなど、詳細な基準はありますか?

A: ストレステストの目的は、関連するシステムリソースで達成できるパフォーマンス指標を明らかにすることです。実際のビジネスに関係するサーバー アーキテクチャやプロセス ノードが異なるため、環境によってパフォーマンスに大きな違いが生じます。これらがストレステストの目的です。実際の指標を明確にし、各ノードの実際のリソース消費を評価するには、ストレス テストが必要です。

パート2 Jmeterの開発とスクリプトの変更

MGS通信ソリューションの特別な焦点をまとめたので、これらの変換をJmeterで完了する必要があります。

2.1 ヘッダー変換

ヘッダーでは、次の点に注意する必要があります。

1. MGS ゲートウェイ プロトコルはいくつかのヘッダー フィールドに依存するため、ゲートウェイ パラメータが完全であることを確認する必要があります。

2. 一部のパラメータは固定値であり、ハードコードすることができます。関連する構成については、コンソールからダウンロードした構成ファイルを参照してください。

3. ビジネスに Cookie などの他のヘッダー依存関係がある場合は、それらを直接追加できます。 MGS ゲートウェイはヘッダー情報をフィルタリングしません。

2.2 URL変換

URL では、次の点に注意する必要があります。

1. 実際の URL は、実際のビジネス サーバーではなく、MGS ゲートウェイを指す必要があります。関連する構成については、コンソールからダウンロードした構成ファイルを参照してください。

2. 現在、MGS ゲートウェイへのすべてのリクエストは POST です。 GETリクエストがあった場合、MGSから転送されるとGETとなり、MGSとの通信でもPOSTとなります。

3. ボディ部分に特別な要件がない場合は、図に従うことをお勧めします。

2.3 リクエスト変換

リクエストでは、次の点に注意する必要があります。

1. ここでの暗号化/署名検証は、参照する必要がある MGSJMeterExt ファイルに依存します。

2. 通常は、//config 部分のみを変更する必要があります。

3. 以下の部分は、主に暗号化と署名検証のための一般的な統一ソリューションであり、変更する必要はありません。

2.4 レスポンス変換

対応にあたっては、以下の点に注意する必要があります。

1. 圧力機器の性能を考慮すると、サーバーの評価能力には影響しません。したがって、データの二次利用や結果判定の必要がない場合は、ここに記載する必要はありません。

2. 関連するニーズがある場合は、ここでレスポンスリターンパラメータの二次処理を完了できます。

パート3 実際のストレステスト

一般的な手順は次のようにまとめられます。

3.1 PTSとスクリプトのパフォーマンスチューニング

Alibaba Cloud パフォーマンス テスト サービス (PTS) は、便利で高速なクラウドベースのストレス テスト機能を提供します。このストレス テスト サービスでは、PTS を使用してインターネット ストレス トラフィックを入力します。

興味深い点は、暗号化と復号化の計算がゲートウェイに計算上の圧力をもたらすだけでなく、圧力マシンにも一定の計算上の圧力をもたらすことです。そのため、プラグインとストレス テスト スクリプトの最初のバージョンを実装する前に、まずストレス テスト マシンで「ストレス テスト」を実施しました。

最初の基本テスト

PTSプレステストマシンの構成:

1.PTS単一IPユニット構成

2. 同時実行数 500 (単一マシンの最大同時実行数)

3. 固定圧力フローモデル

4. 2分間のストレステスト期間

回復されたストレス テスト レポートから、TPS の結果は高くありませんが、返された RT 値も高くありません。

次に、圧力機械の性能を観察します。圧力マシンの CPU 使用率が比較的高いことがわかります。したがって、暗号化計算の圧力が圧力機械の圧力解放に大きな影響を与えると疑う理由があります。

繰り返しコンテンツの暗号化結果をキャッシュすることで、計算負荷が大幅に軽減されます。同時に、キャッシュ設計によって発生するメモリの問題を回避するために、キャッシュの上限が制限されます。

2回目のテスト

テスト構成は最初のラウンドとまったく同じで、最適化された暗号化プラグインのみが置き換えられます。回収されたテストレポートによると、シーンの TPS は 75% 増加しました。

圧力マシンの CPU パフォーマンスが明らかに最適化されています。

3回目のテスト

最初の調査ラウンドと 2 番目の最適化ラウンドの結果に基づいて、3 番目のテスト ラウンドでは 2 台のストレス マシンを使用して構成の全負荷ストレス テストを実行し、ストレス テストの結果を観察しました。

結果から判断すると、ストレス テスト スクリプトとオーケストレーション プロセスは期待どおりであり、正式な PTS クラウド ストレス テストを顧客の運用環境で実行できます。

3.2 実稼働環境のストレステスト

正式なストレス テストが開始される前に、バックエンド システムの動作状態が期待どおりであるかどうかを観察するために、小規模なストレス テストが数回実施されました。調査中に以下の問題が発見されました。

問題1: 不均一なNginxトラフィック転送

MGS コンテナのログから、一部のコンテナがリクエストを取得できないことがわかります。調査の結果、問題の原因は次の 3 つであることがわかりました。

1) DMZ ゾーンの Nginx 転送構成に MGS コンテナ IP がありません。

2) DMZ ゾーンから各 MGS コンテナ IP へのネットワーク ポリシーでアクセス権を有効にする必要があります。

3) Nginx 転送ルールが iphash に設定されています。単一の IP ソースのテスト ケースでは、トラフィックは 1 つのコンテナーにのみ転送できます。

正しい IP リストを構成し、ネットワーク権限を有効にし、転送ルールを変更した後、問題は解決しました。

問題2: 特定のMGSコンテナのCPU負荷が高すぎる

予備テストでは、MGS コンテナ (mpaasgw-7) の CPU 負荷がサイレント モードで 25% となり、予想どおりではなかったことが判明しました。

コンテナにログインすると、CPU を大量に消費する JPS プロセスがあることがわかりました。デバッグの初期段階で関数が呼び出された後、正常に解放されなかったことが疑われます。 JPS プロセスを終了した後、問題は解決しました。他の問題を回避するために、コンテナも同時に再起動されました。

注: JPS (Java Virtual Machine Process Status Tool) は、現在のすべての Java プロセスの PID を表示するために Java によって提供されるコマンドです。https://docs.oracle.com/javase/7/docs/technotes/tools/share/jps.html を参照してください。

問題3: CoreWatch監視プラットフォームにアクセスできない

CoreWatch コンソールにアクセスできず、ブラウザに 502 エラーが報告されます。 CoreWatch コンテナを再起動すると、ページを読み込むことはできますが、常に読み込み状態になります。

http://corewatch.*.com/xflush/env.js は常に保留状態です。トラブルシューティングの結果、ALB インスタンスの監視設定にエラーがあることが判明しました。修正後、問題は解決しました。

3.3 実稼働環境のストレステストと概要

3.2 のすべての問題を解決した後、システムはストレス テストの準備が整います。正式なストレス テストでは、「暗号化されたシナリオ」と「暗号化されていないシナリオ」の両方でストレス テストを実施します。

生産データは公開されていないため、以下では発生した問題の例のみを示します。

「暗号化」でテストする

1. ストレステスト中に、同時接続数が約 500 のときに TPS が増加しないことが判明しました。これは、ボトルネックに達した可能性があることを意味します。

2. MGS ゲートウェイ コンテナの負荷を観察し、全体的な CPU 負荷が限界に達していることを確認します。

3. 同じ期間の MCUBE コンテナの CPU 負荷は正常であり、その他のパフォーマンス指標 (IO、ネットワークなど) も正常な状態です。

4. 上記の状況から、暗号化シナリオでは、主なパフォーマンスのボトルネックは MGS ゲートウェイにあります。経験とプロセス分析によると、パフォーマンスへの主な負荷は、メッセージの暗号化と復号化中に行われる集中的な計算によって発生します。このボトルネックを解決するには、MGS コンテナを拡張する必要があります。

暗号化なしでのテスト

1.同時実行数が約 1000 に達すると、TPS の増加は停止します。一般的に、この状況はシステム容量のボトルネックに達したことを示します。

2. MGS ゲートウェイ コンテナの負荷を確認します。暗号化の場合とは異なり、全体的な CPU 負荷は高くありません。

3. 同時に、ネットワーク チームからのフィードバックによると、ストレス テスト中、インターネットから DMZ 領域への TCP セッション数は、DMZ 領域からイントラネット領域への TCP セッション数の 3 ～ 4 倍であり、トランザクション イントラネット セグメントのファイアウォールの CPU 負荷は比較的高かった。

4. 上記の 3 つの症状を組み合わせると、ネットワークのボトルネックが発生していると考えられます。現場の状況から、DMZエリアのNginxがイントラネットに転送する際に長時間接続維持戦略が採用されていないことが判明しました。 Nginx 設定を変更し、keepalive 1000 構成を追加して、2 回目のテストを再度実行します。

Keepalive パラメータに関する注意: デフォルトでは、Nginx はバックエンドにアクセスするために短い接続 (HTTP1.0) を使用します。新しいリクエストごとに、Nginx は新しいポートを開いてバックエンドとの接続を確立し、バックエンドが実行を完了すると接続をアクティブに閉じます。 Keepalive パラメータは、バックエンド サーバーとサーバーの間でキャッシュされる長い接続の数を Nginx に伝えます。新しいリクエストが到着すると、TCP 接続を直接再利用できるため、TCP 接続を確立することによるパフォーマンスへの影響が軽減されます。参照: http://nginx.org/en/docs/http/ngx_http_upstream_module.html。

要約する

上記の問題を最適化した後、暗号化されていないシナリオでは少なくとも 70% のパフォーマンスが向上し、暗号化されたシナリオでは 10% のパフォーマンスが向上します。 MGS 拡張が完了すると、パフォーマンスが大幅に向上します。最適化の結果は期待をはるかに上回りました。