Какая конфигурация Amazon Web Service (AWS) наиболее масштабируемая и высокопроизводительная для веб-службы RESTful?

Question

Я создаю асинхронный веб-сервис RESTful и пытаюсь выяснить, какое решение является наиболее масштабируемым и высокопроизводительным.Первоначально я планировал использовать конфигурацию FriendFeed, используя одну машину с nginx для размещения статического контента, выступать в качестве балансировщика нагрузки и выступать в качестве обратного прокси-сервера для четырех машин, на которых работает веб-сервер Tornado для динамического контента.Рекомендуется запускать nginx на четырехъядерном компьютере и каждый сервер Tornado на одноядерном компьютере.Amazon Web Services (AWS), по-видимому, является наиболее экономичным и гибким провайдером хостинга, поэтому вот мои вопросы:

1a.) В AWS я могу найти только c1.medium (двухъядерный процессор и 1,7 ГБ памяти).) типы экземпляров.Значит ли это, что у меня должен быть один экземпляр nginx, работающий на c1.medium, и два сервера Tornado на экземплярах m1.small (одноядерный ЦП и память объемом 1,7 ГБ)?

1b.) Если мне нужно увеличить масштаб,Как бы я связал эти три экземпляра с другими тремя экземплярами в той же конфигурации?

2a.) Более логично размещать статический контент в корзине S3.Будет ли nginx по-прежнему размещать эти файлы?

2b.) Если нет, то производительность будет страдать из-за того, что nginx не будет их размещать?

2c.) Если nginx не будет размещать статический контент,это действительно только действует как балансировщик нагрузки.Есть отличная статья здесь , которая сравнивает производительность различных облачных конфигураций и говорит о балансировщиках нагрузки: «Как HaProxy, так и Nginx перенаправляют трафик на уровне 7, поэтому они менее масштабируемы из-за завершения SSL и повторного согласования SSLДля сравнения: Rock перенаправляет трафик на уровень 4 без затрат на обработку SSL. "Вы бы порекомендовали заменить nginx в качестве балансировщика нагрузки на тот, который работает на уровне 4, или у Amazon Elastic Load Balancer достаточно высокая производительность?

Answer 1

1a) Nginx - это асинхронный сервер (на основе событий), с одним работником он может обрабатывать большое количество одновременных соединений (max_clients = worker_processes * worker_connections/4 ref ) и при этом работать хорошо.Я сам проверил около 20K одновременного соединения на c1.medium вид коробки (не в aws).Здесь вы устанавливаете рабочих на двоих (по одному на каждый процессор) и запускаете 4 бэкэнда (вы можете даже протестировать больше, чтобы увидеть, где он ломается).Только если это доставляет вам больше проблем, тогда выберите еще одну подобную настройку и соедините их с помощью упругого балансировщика нагрузки

1b) Как сказано в (1a), используйте упругий балансировщик нагрузки.См. , кто-то проверял ELB на 20 тыс. Запросов / сек, и это не предел, так как он сдался, когда они потеряли интерес.

2a) Хост статического контента в cloudfront ,его CDN и предназначен именно для этого (дешевле и быстрее, чем S3, и он может извлекать контент из корзины s3 или с вашего собственного сервера).Это очень масштабируемый.

2b) Очевидно, что nginx, обслуживающий статические файлы, теперь должен будет обслуживать больше запросов к тому же числу пользователей.Снятие этой нагрузки уменьшит работу по принятию соединений и пересылке файлов (меньше использование полосы пропускания).

2c).Отказ от nginx в целом выглядит хорошим решением (на одного человека меньше среднего).Elastic Load Balancer будет обрабатывать завершение SSL и уменьшать нагрузку SSL на ваши серверы (это улучшит производительность серверов).Из вышеприведенных экспериментов он показал около 20 КБ, и, поскольку его упругость, он должен растягиваться больше, чем программный LB (см. этот хороший документ о его работе)