Я только что спроектировал свой первый масштабируемый бэкэнд для приложения django, однако я поместил службу очереди сообщений (RabbitMQ) на машину балансировки нагрузки. Я смог осаждать некоторые из моих маршрутов API до 500 одновременных пользователей без серьезного дефицита времени, но мне интересно, смогу ли я улучшить производительность, разместив службу MQ где-то еще.
Моя установка прямо сейчас:
запросы приложений> балансировщик нагрузки (nginx, rabbitmq)> рабочие, 2 в использовании (gunicorn / celery)> db (postgres)
Итак, в настоящее время у меня есть 4 экземпляра AWS EC2 (все m3.medium), подключенные к VPC, которые делают все это за меня. Нет смысла делать rabbit на рабочих узлах, поэтому я просто пытаюсь понять, что делают люди.
Мне также любопытно, как лучше всего настроить Gunicorn, но, судя по моим поискам, не похоже, что есть много чего возиться, кроме количества / типа реальных рабочих. Что для моего экземпляра AWS EC2 (m3.medium) только 3 / синхронно (хуже производительность при использовании async worker).
В идеале ваш MQ должен быть расположен в отдельном экземпляре (ах), чтобы его можно было масштабировать независимо от серверов приложений или балансировщика нагрузки. Это также упрощает обслуживание (вы можете поменять свой экземпляр балансировщика нагрузки, например, без необходимости переносить существующую очередь), и для безопасности лучше изолировать их (вашему LB нужен открытый доступ, а вашему MQ - нет).
Также стоит отметить, что AWS очень ориентирован на разделение того, чем можно эффективно управлять с большой экономией на масштабе, от того, что является уникальным для вашего приложения, и делегирование того, что они любят называть «недифференцированной тяжелой работой», управляемым сервисам AWS. Например, в AWS принято использовать MQ на основе SQS или Redis на ElastiCache, которые поддерживают архитектуру высокой доступности из коробки (EC через Multi-AZ). Точно так же вы можете делегировать свой LB в ELB, что позволит вам сосредоточиться на оптимизации вашего приложения и, возможно, серверов БД (если RDS не соответствует вашим потребностям, я не уверен, что такое ситуация с Postgres).