1

この質問は、特に Amazon ではなく、Swisscom Application Cloud に関するものです。

私のアプリケーションは 50 のスレッドを使用します。合計すると、S3 に対して 1 秒あたりおそらく 25 ～ 200 のリクエストが行われます。それらを10〜30秒間実行した後、次のような例外が発生し始めます。

2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT com.amazonaws.AmazonClientException: Unable to execute HTTP request: Socket is closed
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeHelper(AmazonHttpClient.java:956)
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT at com.amazonaws.http.AmazonHttpClient$RequestExecutor.doExecute(AmazonHttpClient.java:661)
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT at com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeWithTimer(AmazonHttpClient.java:635)
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT at com.amazonaws.http.AmazonHttpClient$RequestExecutor.execute(AmazonHttpClient.java:618)
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT at com.amazonaws.http.AmazonHttpClient$RequestExecutor.access$300(AmazonHttpClient.java:586)
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT at com.amazonaws.http.AmazonHttpClient$RequestExecutionBuilderImpl.execute(AmazonHttpClient.java:573)
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT at com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:445)
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT at com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:4041)
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT at com.amazonaws.services.s3.AmazonS3Client.putObject(AmazonS3Client.java:1581)
2016-10-29 14:36:58 [APP/PROC/WEB/0] OUT at <my_code_from_here>.putFile(S3Service.java:49)

アプリを再起動するか、数分待った後、問題は解決しましたが、起動して S3 に再び負荷をかけるとすぐに、10 ～ 30 秒後にこれらの例外が再び発生しました。

リクエストレートに制限はありますか?

4

2 に答える 2

1

Cloud Foundry プロバイダーにアウトバウンド トラフィックの制限があるかどうか、自分で調べてみませんか? また、アプリケーションに何らかの欠陥や欠陥がある可能性を排除する必要があります。

したがって、アウトバウンド リクエストの制限があるかどうかを検出し、アプリケーションに何らかの問題がある可能性を排除するには、次の手順に従います。

  1. 外部サーバーに任意の Web サービス アプリケーションをデプロイします。つまり、同じ Cloud Foundry ドメインにデプロイされていない (つまり、Swisscom AppCloud にデプロイされていない)。実際には、適切な Web サービスである必要はありませんが、"nc -l PORT" は既にその仕事をしています - TCP ポートをリッスンするだけです。
  2. 次に、ステップ 1 でデプロイした外部 Web サービス アプリケーションに対して毎秒約 300 のリクエストを行う Cloud Foundry (つまり、Swisscom AppCloud) にアプリケーションをデプロイできます。このようにして、Cloud Foundry 内のアプリケーションをシミュレートします (この中でケース、Swisscom AppCloud の場合) は、シナリオで述べたのと同じ動作をします。

わかりましたが、問題は次のとおりです。そのような手順を技術的/実際的に達成するにはどうすればよいですか? 大変な作業ではないですか？

まあ、それは可能ですし、大した手間ではありません。20 分かけて、それをシミュレートするコマンド/スクリプト/Docker イメージのセットを考え出しました。

したがって、ステップ1は自分で達成できます。単純な Web サービスを別の場所にデプロイするかもしれませんが、それだけです。ステップ 2 はより複雑ですが、次の CF CLI コマンドを実行するだけで簡単に実行できます。

cf push LoadTestFromCloudFoundry --no-hostname --no-route --docker-image gsmachado/loadtest-docker --health-check-type none -c 'loadtest -t 20 -c 10 --rps 10 -k https://IP_ADDRESS_TO_YOUR_EXTERNAL_WEBSERVICE:PORT'

この例では、「LoadtestFromCloudFoundry」というアプリを、ホスト名、ルート、およびヘルス チェック タイプなしでプッシュしています。また、すでに DockerHub で公開されている Docker イメージ (gsmachado/loadtest-docker) を指定していますが、ここでソース コードを確認できます(スターを付けてください! オープン ソースです!)。オプション「-c」は、この docker コンテナーで実行するコマンドを指定します。これは、実際には、Cloud Foundry で実行されるアプリです。この docker コンテナーは、プロジェクトのloadtestを使用します特定の Web ターゲットへの要求を実行します。すべてのドキュメントを確認して、独自の「-c」コマンドを考え出すことができます。この特定の例では、10 の同時クライアントを使用して、20 秒間に 1 秒あたり 20 のリクエストを実行することを定義しました。Cloud Foundry は Docker コンテナー全体をデプロイする必要があるため、cf push コマンドの実行には時間がかかります。

「cf ログ」を確認することで、負荷テストの結果を確認できます。

cf logs LoadTestFromCloudFoundry

また、マニフェストの例がここにあり、README ドキュメントもここにあります。

このような外部アプリケーションを対象とした負荷テストを実行すると、問題がアプリケーションにある場合、または Cloud Foundry プロバイダー (この場合は Swisscom AppCloud) が実際に 1 秒あたりの要求数 (RPS) を一定量ブロックする場合に、強力な洞察が得られる可能性があります。

ただし、現在、Cloud Foundry プロバイダーがなんらかの理由でブロックしていると判断した場合は、サポートに連絡する必要があります。適切なプロバイダーは、サービスに支払う顧客に対して、いかなる種類のアウトバウンド RPS 制限も課すべきではありません。

それは、この件に関する私の 2 セントです。:-)

于 2016-10-30T23:45:45.610 に答える
1

アウトバウンド トラフィックの制限や DoS 保護はありません。

Swisscom AppCloud には、S3 (Dynstrg としてブランド化され、ベンダーは EMC Atmos) アクセスに対する DoS ポリシーがアクティブ化されており、特定のレベルの後に要求をインターセプトします。この検出基準は現在、送信元 IP ごとに 200 TPS (Transactions per Seconds、TCP セッション) によってトリガーされ、この IP は少なくとも 120 秒間ブロックされます。

Swisscom は現在、これらのトリガーを増やすことを検討しています。

于 2016-10-31T09:34:22.643 に答える