Чрезмерное использование S3 заканчивается с разъемом close?

Question

Этот вопрос касается облака приложений Swisscom, а не об Amazon.

Мое приложение использует 50 потоков. В сумме они делают 25-200 запросов в секунду на S3. После запуска их в течение 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 секунд.

Есть ли ограничения по ставке?

Answer 1

Нет ограничений на исходящий трафик или защита DoS.

Swisscom AppCloud имеет политику DoS для активации S3 (заклейменный как Dynstrg, поставщик EMC Atmos), который перехватывает запросы после определенного уровня. Эти критерии обнаружения в настоящее время запускаются на 200 TPS (транзакции в секунду, сеансы TCP) на один IP-адрес источника, тогда этот IP-адрес блокируется не менее 120 секунд.

В настоящее время Swisscom обсуждает увеличение этих триггеров.

Answer 2

Почему бы вам самим не обнаружить, если поставщик облачного литейного производства имеет какое-либо ограничение на исходящее трафик? Кроме того, вам нужно исключить возможность того, что ваше приложение имеет какой-то недостаток или дефект.

Итак, для того, чтобы обнаружить, есть ли исходящий ограничение запрос и исключить возможность того, что ваше приложение имеет какие-то проблемы, мы можем выполнить следующие действия:

1. Развертывание любого приложения веб-службу в внешний сервер. Другими словами, который не развернут в том же домене Cloud Foundry (т. Е. Не развернут в SwissClock AppCloud). На самом деле, он не должен быть надлежащим веб-сервисом, но «nc -l PORT» уже выполнит эту работу - просто для прослушивания TCP-порта.
2. Затем мы можем развернуть приложение в Cloud Foundry (т.е. Swisscom AppCloud), которое составляет около 300 запросов в секунду для приложения внешней веб-службы, которое мы развернули на шаге 1. Таким образом, мы имитируем приложение WITHIN Cloud Foundry (в данном случае в Swisscom AppCloud), который имеет такое же поведение, как вы упомянули в своем сценарии.

Хорошо, теперь вопрос заключается в следующем: как технически/практически достичь таких шагов? Разве это не так много работы?

Ну, это возможно и, нет, это не много работы. Я потратил 20 минут и придумал набор команд/сценариев/изображение докеров, чтобы имитировать это.

Итак, шаг 1 вы можете достичь своими силами. Возможно, развертывание простой веб-службы в другом месте, и все. Шаг 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», без какого-либо имени хоста, без какого-либо маршрута, и без какого-либо типа проверки работоспособности. Кроме того, мы указываем изображение докеров (gsmachado/loadtest-docker), которое уже опубликовано на DockerHub, но вы можете проверить исходный код here (дайте ему звезду! Это с открытым исходным кодом!). Параметры «-c» задают команду для запуска в этом контейнере докеров, который, фактически, является приложением, работающим в Cloud Foundry. Этот контейнер-докер использует проект loadtest для выполнения запросов к определенной веб-цели. Вы можете проверить всю документацию и придумать свою собственную команду -c. В этом конкретном примере мы определили, что в течение 20 секунд мы хотим выполнить 20 запросов в секунду, используя 10 одновременных клиентов. Команда cf push требует времени, которое нужно выполнить, поскольку Cloud Foundry должен развернуть весь контейнер докеров.

Вы можете проверить результаты нагрузочного теста, проверяя «журналы Cf»:

cf logs LoadTestFromCloudFoundry 

Кроме того, существует явный пример here, а также с README документации here.

Выполнение таких нагрузочных тестов, ориентированных на внешнее приложение, может дать вам большую информацию, если проблема в вашем приложении, или если поставщик Cloud Foundry (в данном случае Swisscom AppCloud) действительно блокирует определенное количество запросов в секунду (RPS).

Однако, если вы сделаете вывод о том, что поставщик Cloud Foundry каким-то образом блокирует, вы должны связаться со своей поддержкой. Приличный провайдер не должен вводить какие-либо ограничения исходящих RPS для клиентов, оплачивающих их услуги.

Это мои 2 цента на эту тему. :-)