Как увеличить пропускную способность сети AWS EC2?

Question

Мы разместили сайт в AWS EC2 типа c4.8xlarge. Это довольно большая система с большим объемом памяти и вычислительными ресурсами. Тысячи пользователей пытались получить доступ к системе в течение 2-х часового таймфрейма в эти выходные. Хотя он не разбился, он немного замедлился и не смог выполнить ожидаемый уровень. Анализ статистики показал, что ограниченная пропускная способность сети является основной причиной замедления. Использование процессора оставалось ниже 6%, но NetworkIn и NetworkOut, похоже, достигли максимума в 60 МБ и 200 МБ соответственно в течение этого периода времени. Хотя я не ожидаю от сети, некоторые чтения в Интернете, по-видимому, указывают на то, что весь трафик, проходящий через один сетевой адаптер, может быть основной причиной ограниченной пропускной способности сети. Это правда? Хостинг сайта на другом типе экземпляра EC2 поможет увеличить пропускную способность сети? Вот как показатели networkIn и networkOut выглядели как при большой нагрузке.

Answer 1

Да Amazon имеет концепцию ENI - Эластичный сетевой интерфейс. Пока вы можете добавить дополнительный экземпляр в экземпляр; он по-прежнему является логическим интерфейсом. Предоставление и доступность сетевого канала сильно зависит от выбранного вами типа экземпляра. У Amazon есть несколько типов/семейств экземпляров, таких как R, I, C, D, G - оптимизированы в памяти, IO, Compute, Dense Storage, GPU соответственно. Вы можете увидеть, можете ли вы сжать макс. из них.

Независимо от того, что когда-либо вы выбираете как тип экземпляра, вы по существу достигли порога и не смогли бы масштабироваться за определенную точку. Масштабируемость особенно уникальна по сравнению с другими факторами масштабируемости, такими как Memory/CPU.

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

Answer 2

Если вы ограничены полосой пропускания, этот график станет плоским, когда вы достигнете предела. Кроме того, как отмечали другие, только 1 Мбайт/с и 3 МБ/с, и я могу сделать больше, чем на t2.micro для внешнего интернета.

Что делает система с каждым запросом? Вот список вещей, на которые я бы посмотрел, в порядке:

• Threading: существуют ли узкие места в вашем приложении, где только один поток может получить доступ к ресурсу? Это снизит загрузку процессора, но приведет к точному отображению шаблона.
• Плохие шаблоны параллелизма в вашем приложении или сервере. Загрузите тест и найдите его медленнее и медленнее, поскольку соединения увеличиваются, но ничего не делают.
• Индивидуальный процессор: один процессор загружен до 100%, в то время как другие в основном не работают? (с 30+ ядрами, насыщенный процессор будет давать вам только 3% использования ЦП). Один простаивающий CPU + другие в режиме ожидания обычно означает проблему параллелизма, возможно, при обработке соединения.
• Что такое использование памяти? Вы используете своп вообще? (это ОЧЕНЬ плохой знак, если это так, и вызовет проблему). Если использование памяти чрезмерно, часто происходит сбой в хранении в памяти или в пулах потоков обработчиков избыточного размера.
• Диск-входы/выходы или внешние сетевые запросы: читаете или пишете с каждым запросом? vmstat сообщит, если вы тратите много времени на ожидание обслуживания I/O. Если это так, я бы посмотрел на журнал прежде всего.
  • В примерах c4.8xlarge используется только EBS, если хранилище магнитное и вы записываете журналы доступа, вы получаете несколько сотен записей в секунду. SSD общего назначения дает вам 3 IO/s на базу GB, но может лопнуть до 3000, пока у них не закончится IO-кредитов.
  • ОС будет пытаться объединить записи, но с тысячами одновременных

Это не невозможно, но очень маловероятно, что вы могли бы быть упираются на сетевом уровне с созданием соединения или пакетов в секунду, если ваши запросы очень маленькие.

Answer 3

Ваш NetworkIn и Out на самом деле> 50 МБ/с. Если ваш процессор и память остались в разумных пределах, ваш экземпляр в порядке. Вы также должны проверить журнал соединений в своей базе данных (при условии, что вы используете RDB с вашей системой), замедление фактически может быть вызвано медленным ответом на вашу базу данных, что заставляет веб-сервер реагировать медленнее.

Кроме того, вы должны запустить вашу систему с помощью нагрузочного устройства AWS и установки и автоскалера с триггером в сети. Таким образом, вторичный экземпляр запускается, чтобы помочь в временном увеличении нагрузки в сети. Если основной причиной является увеличение соединения в вашей базе данных, тогда балансировка нагрузки не поможет в решении этой проблемы. Вместо этого вы хотите улучшить настройку кеша, поэтому на пользователя или пользователя на ваш сайт меньше нагрузки на пользователя.