Отказоустойчивый стартап на AWS без devops’ов Архитектуры
Тезисы
Технически, любой веб-сервис состоит из самого продукта, который решает задачу клиента, и инфраструктуры, которая его поддерживает. Каждый стартап в условиях ограниченных ресурсов сталкивается с выбором: разработчик продукта или devops? Как правило продукт выигрывает, а инфраструктурные проблемы накапливаются на будущее. Через год развития у такого стартапа есть продукт, который можно было бы запустить в активный маркетинг, но нельзя - падает.
Однако не все так плохо. Развитие современного рынка облачных технологий привело к ситуации, что при правильном использовании профильная команда может достаточно долго не заботиться о devops-инженере и больших вложениях на поддержку инфраструктуры в проекте.
На примере конкретного стартапа readymag.com я расскажу
* как выглядела архитектура системы на момент старта (все работает на одном сервере и не масштабируется), в чем были основные проблемы:
* монолитная архитектура,
* ограничения по возможности вертикального масштабирования,
* взаимосвязанные тестовые и продуктивные окружения,
* отсутствие возможности отлаживать системные (nginx/redis/mongo) конфиги,
* зависимость от локальных файлов при обработке независимых запросов,
* наличие SPOF
* последовательность рефакторинга системы до состояния "нам всеравно сколько трафика к нам идет”:
* декомпозиция монолитной архитектуры на компоненты,
* выделение группы для горизонтального масштабирования и сопутствующие изменения: тестовый/боевой деплоймент, мониторинг, балансировка нагрузки,
* переход на S3 для работы с аплоадом файлов, изменения в архитектуре и обеспечение безопасности данных,
* использование ELB для балансировки нагрузки,
* разделение тестового/боевого окружений,
* использование AMI и клонирования машин для быстрого управления ресурсами
* общий подход к эффективному использованию сервисов AWS, который позволит получить эффективно масштабируемый сервис без участия devops и сосредоточить усилия команды на развитии продукта:
* много независимых stateless воркеров,
* ELB для балансировки нагрузки
* SQS/http-callbacks для управления очередью задач
* S3 для хранения и распространения статики