機能パフォーマンス検出: よりシンプルで効率的なサーバーレス仕様選択スキーム

2019 年、バークレーはサーバーレスがクラウドコンピューティングの新しいパラダイムとしてサーバーフルコンピューティングに取って代わると予測しました。サーバーレスは、アプリケーション開発のための新しいシステムアーキテクチャを提供します。2023 年に OpenAI によってもたらされる AIGC トレンドを活用し、Alibaba Cloud Function Computing FC や AWS Lambda に代表されるサーバーレスは、より高い費用対効果、よりシンプルなバックエンドコードとスケーラビリティ、より優れた弾力性などの多くの機能を備えており、開発者をさまざまな作業から解放します。手作業による大量のリソース管理とパフォーマンスコストの最適化により、開発者の旺盛な想像力と創造性が再び刺激されます。中国ではますます多くの開発者や企業が、サーバーレスを実際のビジネスやシナリオに適用する方法を試し始めています。

ただし、サーバーレスをエレガントに使用する前に、事前に解決する必要がある小さな問題がまだたくさんあります。サーバーレスプラットフォームの拡張と縮小はリクエスト処理/イベント駆動型の同時実行性に基づいているため、CPU インジケーターに基づいた水平ポッドスケーリングに慣れている開発者は、同時実行パラメータ間の関係は何か、インスタンスの最小数と最大インスタンス数は? もう 1 つの例は、ビジネスニーズを満たすために単一インスタンスの最大同時実行数を設定する方法です。

01 サーバーレスパラメータ構成の考慮事項

サーバーレスは特定の一般的な機能を提供できますが、サーバーレスの価値をより適切に活用するには、さまざまなビジネスロジックに適切な構成が必要です。ただし、関数の最適な構成を評価するには、多変量の協調最適化が必要です。Function Compute FC は、アプリケーションが現在使用しているサーバーに基づいて、アプリケーションの「毎日のリクエストの総数」と「平均リクエスト応答時間」に基づいてリクエストの推定値を提供しますが、「アプリケーション」「仕様」「利用」およびパラメータ設定を支援するその他のメソッド。ただし、より適切に構成するには、次の 3 つの側面からサーバーレスサービスパラメーターを評価および構成することをお勧めします。

(1) コストとパフォーマンスのトレードオフを考える

ビジネスの好みに応じて性能優先かコスト優先をどのように選択するかは、パラメータ設定で考慮する必要がある最初の困難です。単一インスタンスの多重同時実行数が比較的固定の場合、単一インスタンスの並列処理リクエスト数を増やすことができ、インスタンス数を削減し、コストを削減することができる。同時実行数が多すぎると、リソースの競合が増加し、パフォーマンスの遅延が増加してコストが増加します。遅延に対する感度が比較的低い場合は、より低いインスタンス仕様を選択でき、単価コストも低くなります。逆にDelayを短くしたい場合は、より高いインスタンス仕様を選択できますが、単価は高くなります。

(2) 複雑なビジネスロジックとさまざまな機能を組み合わせる

コストとパフォーマンスのトレードオフに加えて、関数ロジックのタイプが異なると、構成パラメーターの影響にも大きな違いがあります。多くの機能のビジネスロジックは複雑であり、単一のロジックブランチの特定の構成だけが全体のパフォーマンスが最適であることを意味するわけではありません。構成が不適切であると、予期しない多額の運用コストと保守コストが発生する可能性があります。この点に関して、さまざまなタイプの機能のさまざまな仕様と TPS との関係をより詳しく調査するために、さまざまなタイプの CPU 集中型および IO 集中型の機能をテストします。

さまざまな仕様での CPU 負荷の高い機能の耐圧テスト

CPU 負荷の高い仕様が高くなるほど、maxTPS も大きくなり、仕様と maxTPS の間には明らかな線形関係があることがわかります。仕様が大きくなるほど、maxRT は低くなります。これは、CPU を集中的に使用する機能、リソース仕様の増加によって RT が大幅に削減される可能性があることを示しています。ただし、4G、8Gとスペックが上がった後は、RT短縮効果は限界効果が小さくなります。

さまざまな仕様での IO 集中型機能の圧力テスト

IO 集中型のパフォーマンス向上は仕様の向上によって非常に限定的であり、仕様と maxRT および maxTPS との相関は限定的であることがわかります。特に高スペックに拡張した後のmaxTPSの向上は小さいです。

上記の圧力テストの助けを借りて、CPU 集中型の機能の場合、仕様の増加により単一インスタンスのパフォーマンスが大幅に向上する可能性があるという結論がわかります。ただし、IO 集中型の機能の場合、単一インスタンスのパフォーマンス向上に対する仕様の増加による限界効果は減少します。ある仕様を超えると、仕様を上げても性能向上にはほとんど影響しません。

(3) 機能構成が計算資源構成に与える影響を考慮する

関数の同時実行性、インスタンスの最小数、インスタンスの最大数などの構成はサーバーレスプラットフォームのリソース割り当てに影響するため、単一機能リソースの厳格な配信と多機能リソースの分離を同時に確保し、合理的なプラットフォームの柔軟なスケジューリング機能の使用とリソース使用率の向上は、検討すべき最後の質問です。

x 個の同時リクエストを処理するシナリオを例に挙げると、インスタンスの同時実行数が 1 に設定されている場合、各インスタンスは一度に 1 つのリクエストしか処理できず、Function Compute は x 個のリクエストを処理するために x 個のインスタンスを作成する必要があります。インスタンスの同時実行数が X*10 に設定されている場合、各インスタンスは同時に X*10 リクエストを処理でき、Function Compute は x リクエストを処理するために 1 つのインスタンスを作成するだけで済みます。

単一インスタンスのマルチ同時実行は、関数がダウンストリームサービスからの応答の待機に多くの時間を費やすシナリオに適しています。通常、応答を待機してもリソースは消費されず、インスタンス内での同時処理によりコストを節約できます。ただし、単一インスタンスの同時実行性が低い状態で関数のトラフィックが変動した場合、事前に単一インスタンスの同時実行性の上限に達し、インスタンスの拡張と縮小およびコールドスタートがより頻繁に発生します。同時に、より多くのインスタンスを作成して維持する必要があるため、全体的なリソース使用率が低くなります。

02 パラメータ設定の合理性を評価する

上記の 3 つの側面を組み合わせると、サーバーレスのパラメーター構成を評価するのは簡単な作業ではないことがわかります。多くのユーザーがサーバーレスを使用しようとすると、ドキュメントのガイダンスに従って関連するパラメーターを設定するだけになります。機能を正式にリリースした後、以前の構成に無理があった、コストが予想を超えた、パフォーマンスが期待どおりでないことがすぐにわかり、何度も機能構成を変更して検証してみます。上級開発者は、最適な機能構成をテストするためにストレステストを実行することを選択します。ただし、ストレステストスクリプトの構成とストレステストデータレポートの解釈にはある程度の実務経験が必要であり、開発者はストレステストから得られた構成の結論がビジネスの期待を満たす最適な選択であるかどうかを確信できません。多数のユーザーの実際の構成と使用状況を数えた結果、ユーザーの実際のリソース使用量は低く、実際の構成仕様が大きすぎるため、ある程度の無駄が生じていることがわかりました。

構成パラメーターの合理性をより適切に検証するために、Function Compute FC は、パフォーマンステスト PTS 機能に基づく関数パフォーマンス検出機能を提供し、さまざまな仕様の下で関数の単一インスタンスのパフォーマンス上限を評価し、最適なパフォーマンスを推奨します。同時実行数と関数仕様の構成の検出方法は、図に示すように、リトルの法則[1]キュー理論 (同時実行数 = リクエストの平均遅延 * TPS) に基づいています。

(横軸は同時実行数、左縦軸はTPS、右縦軸は遅延)

各サーバーの処理能力には限界があるため、同時実行数が増加するとスループットは最初は増加し、その後横ばいになり、低下する、つまりパフォーマンスが低下する可能性があり、同時実行数が高すぎると遅延が大きくなります。、あるいは急激に悪化することさえあります。パフォーマンス検出により、各仕様の重要なパフォーマンスデータ、つまり各仕様の許容可能な最高のQPSを取得しますビジネストラフィックの規模を知ることを前提として、最小のインスタンス数と最適な機能を取得できますインスタンスの最大数は最良の仕様であり、その仕様に基づく最良の同時実行性です。単一インスタンスの圧力テストのみを実行できます。これは、パフォーマンスが安定しているシステムでは、複数のインスタンスのパフォーマンスが単一インスタンスのパフォーマンスの線形重ね合わせであるため、パフォーマンスを計算するには単一インスタンスのパフォーマンスを測定するだけで済みます。複数のインスタンスの。

たとえば、ユーザーは関数呼び出しのエンドツーエンド遅延が 1000 ミリ秒であることを期待しています。1000 ミリ秒の遅延制限に従って、この仕様の下で最適な仕様と最適な同時実行性、つまり、対応する同時実行性を選択します。遅延制限を満たす最高の QPS。

現在、パフォーマンス検出は HTTP 関数のプレッシャーテストのみをサポートしており、イベント関数のプレッシャーテストはサポートしていません。単一インスタンスのストレステストのみがサポートされており、複数インスタンスのストレステストはサポートされていません。そのため、検証のためにパフォーマンス検出 (単一インスタンス) とパフォーマンステスト PTS (複数インスタンス) を提供します。

パフォーマンス調査について

Function Compute FCの機能の1つとして、性能検出の利用閾値をさらに下げるため、プロセスガイダンスを採用しており、性能検出機能は完全に無料であり、ユーザーは機能にかかるリクエストトラフィックの料金のみを支払うだけで済みます。圧力測定機能に料金を支払う必要はありません。

パフォーマンステストPTSについて

アリババグループのタオバオダブル 11 のパフォーマンステストツールとして、パフォーマンステスト PTS は、圧力テストタスクのオンデマンド開始をサポートし、数百万、数千万の同時 TPS トラフィック開始機能を提供でき、JMeter と 100% 互換性があります。シーンの配置、API デバッグ、トラフィックのカスタマイズ、トラフィックの記録などの提供機能により、ビジネスストレステストスクリプトを迅速に作成し、ビジネスシステムにアクセスするさまざまなレベルのユーザーを正確にシミュレートし、企業がシステムのパフォーマンスと安定性を迅速に向上できるように支援します。現在、新規ユーザーには 5000VUM の無料トライアル割り当てが提供されています。

03 シングルインスタンスの場合、パフォーマンス検出を通じてシングルインスタンスの構成パラメータを検証する方法

次に、わずか 3 ステップで迅速にパフォーマンス検出を開始できるパフォーマンス検出の設定プロセスを簡単に紹介します。

1. Function Compute Console [2]にログインし、左側のナビゲーションバーで[サービスと関数]を選択し、サービスリストページでターゲットサービスを選択します。

2.機能管理ページで対象の機能を選択し、パフォーマンス検出タブで耐圧テストタスクを作成します。

3. [単一インスタンスのパフォーマンス圧力テストの評価]タブで、必要な圧力テスト API 情報 (以下の表を参照) を入力し、 [圧力テストの実行]をクリックします。

(圧力テストを実行する前に、[API テスト] をクリックして、API の HTTP リクエストパラメーターが正しく構成されているかどうか、および関数が正常に実行できるかどうかを確認してください。)

4. ストレステスト結果分析レポートの表示:単一インスタンスのストレステスト結果分析タブでストレステスト結果を表示します。ストレステスト中、インターフェイスにはストレステストの推定時間が表示されます。ストレステストの仕様が増えるほど、ストレステストの時間が長くなり、ストレステストのコストが高くなります。ストレステストの結果には、推奨されるインスタンスの仕様と最適な同時リクエスト数が含まれます。ストレステスト結果の下にある 2 つの分析グラフから分析プロセスを確認することもできます。

注: Function Compute の圧力テスト機能は、単一インスタンスの圧力テストのみをサポートします。マルチインスタンス圧力テストを構成する必要がある場合は、単一インスタンス圧力テスト結果分析タブの右側にあるマルチインスタンス弾性容量圧力テストをクリックして、PTS コンソール[3]構成にジャンプします。

5. 単一インスタンスのストレステストデータの詳細を表示します。 [単一インスタンスのストレステストデータの詳細を表示] をクリックして、単一インスタンスのストレステストデータの詳細ページに移動し、各仕様のストレステスト。各仕様のストレステストの詳細では、同時実行性の増加に伴うレイテンシと最大 QPS の変化を確認できます。

ただし、パフォーマンス検出によって推奨される機能構成は、まずパフォーマンス要件が満たされ、最高のリソース使用率が達成されることを保証しますが、真に最低コストの構成を実現するには、過去のトラフィックを組み合わせる必要があることに注意してください。オンラインで機能のデータ分析を行い、推奨事項を作成します。コスト最適化のための仕様を推奨する際には、コスト削減という目的を達成するだけでなく、既存サービスのQoSを損なわないこと、つまりインスタンスの削減によって性能が遅延を増やさないことも考慮する必要があります。仕様。

04 マルチインスタンスの場合、パフォーマンステスト PTS を使用してマルチインスタンスパラメータを設定する方法

次に、パフォーマンステストのための PTS の構成プロセスを簡単に紹介します。圧力テストを迅速に開始するには、API を構成するだけで済みます。

1. パフォーマンステスト PTS コンソールに移動します。左側のナビゲーションバーで、[パフォーマンステスト] > [シナリオの作成]を選択します。

2. [シナリオの作成]ページで、 [PTS 圧力テスト]をクリックします。

3. [Create PTS Scenario]ページで、シナリオ名(Function Compute Serverless Application Pressure Test など)を設定し、次に[シナリオ構成]タブで、プレッシャーテスト API 名(demo など)を入力し、 [デモ] の右側にあるアイコンをクリックします。 [圧力テストの追加] ノード。圧力テスト URL領域に、前のセクションでコピーして保存したサーバーレスアプリケーションのアクセスドメイン名を入力します。構成が完了したら、「API のデバッグ」をクリックして、API インターフェース構成が期待どおりかどうかを確認できます。デバッグ応答のステータスコードが 200 の場合は、API に正常にアクセスできていることを意味します。

4. [Create PTS Scenario]ページの[Pressure Configuration]タブをクリックして、関連する圧力測定パラメータを設定します。増分モードに[自動増分]を選択し、最大同時実行数に 500 を入力し、増分パーセントに 20 を入力し、シングルレベルに1 を入力します。5.シリアルリンク 1 の最大同時重みとして100を入力し、シリアルリンク 1 の初期パーセンテージとして20を入力します。パラメータを確認したら、「保存」をクリックして圧力テストを開始します。プロンプトダイアログボックスで、タスクの推定消費量が無料クォータを超えていないことを確認します。確認後、「OK」をクリックして圧力テストを開始します。(上記のパラメータは一例です。実際の業務に応じて調整してください)

5. 3 分ほど待つと、現在のアプリケーションのリアルタイムのストレス測定データがストレス測定ページに表示されます。

6.ストレステストページでは、成功率、RT、TPS などの概要データを確認できます。

7. 圧力テストが完了すると、自動的にシーン編集ページにジャンプし、圧力テストレポートをクリックします。[圧力テストレポート] タブで圧力テストレポートを見つけ、右側の[操作]列の下にある[表示]をクリックします。

8. ストレステストレポートでストレステストレポートの詳細な内容を確認し、このストレステストの詳細なパフォーマンスデータを表示します。圧力テストレポートの詳細については、「PTS 圧力テストレポートの表示[4]」を参照してください。この時点で、パフォーマンステスト PTS によるサーバーレスアプリケーションの圧力テストが実現されました。

05 開発者シナリオ体験

現在、Yunqi Lab では「パフォーマンステスト PTS によるサーバーレスアプリケーションのパフォーマンスストレステスト」のシナリオが開始されています。関連する無料トライアル割り当てを提供すると同時に、関連する操作手順とテンプレートも提供されるため、FC を介したアプリケーションの作成と PTS を介したストレステストの実行をすぐに体験できます。