Необходимость планирования
Думаю, что не ошибусь, если скажу, что соблазн переложить все свои риски на плечи сервис-провайдера, совсем забывая о собственной архитектуре проекта, всегда очень велик. Развернуть всё на одном сервере, сэкономить на инфраструктуре, потратить сэкономленный бюджет на раскрутку проекта — всё это работает до того, как проект становится посещаемым.
Популярность к интернет проектам редко приходит планомерно, обычно, это взрывной рост трафика, который генерируется рекламными компаниями, релизами новых интересных возможностей продукта. Если в момент роста трафика архитектура вашего проекта окажется не готовой к масштабированию, то вы рискуете потратить часть бюджета впустую. Далее мы рассмотрим варианты построения архитектуры и подготовку проекта к гибкому горизонтальному масштабированию.
Планирование
Для построения отказоустойчивой системы необходимо полностью понимать процесс, который проходит запрос пользователя до получения ответа от сервера. А также, необходимо заблаговременно задуматься о дальнейшем развитии проекта, чтобы не оказалось так, что расти невозможно из-за проблем архитектуры. Давайте разобьем весь процесс на две независимые части: запрос клиента и обработка запроса клиента на стороне приложения.
Запрос клиента
При текущей архитектуре интернета, большинство запросов от клиентов к конечным системам происходят при помощи доменных имен. Таким образом, DNS запись определяет для клиента точку входа в приложение. При помощи DNS записей мы можем добавить балансировку запросов пользователей между несколькими точками входа в приложение, что, в свою очередь, добавляет и небольшое резервирование системы за счет создания нескольких A записей для одного домена.
Обработка запроса
После того, как запрос прошел точку входа, его дальнейший путь зависит только от логики вашего приложения. На данном этапе и начинается всё самое интересное. Все приложения уникальны и трудно что-либо советовать, но, рассмотрев развитие большинства проектов, все таки можно проанализировать данный процесс на общем примере, поскольку сам процесс развития, в целом, у всех одинаков, разница заключается лишь в запуске приложения с определенной ступени. Чем выше ступень, с которой приложение начинает свою жизнь, тем проще его в дальнейшем будет поддерживать и масштабировать.
Пример развития
Для начала рассмотрим самую простейшую схему сервиса: сервер генерации контента + база данных. Обычно, в самом начале, в целях экономии, всё разворачивают в рамках одного сервера. В принципе, на старте приложения, для понимания нагрузки этот вариант может подойти. Такой сервер можно хорошо оптимизировать и всё будет прекрасно работать до полной утилизации ресурсов сервера. После чего, так или иначе, потребуются дополнительные мощности, а вот добавление их станет крайне нетривиальной задачей. Кто-то на этом шаге просто вынесет базу на отдельный сервер (о кластеризации и построении отказоустойчивой базы данных мы говорить не будем), что освободит какое-то количество ресурсов, но в целом это проблему никак не решит. Следующим шагом служит создание/вынесение фронтенда (точки входа) на отдельный сервер, что уже позволяет безболезненно добавлять дополнительные серверы генерации контента. На этом этапе, мы уже получаем минимум 3 независимых сервера, ресурсы каждого из которых полностью используются под специализированные задачи, что дает нам возможность более четко определять конфигурацию сервера под каждую из задач, и именно здесь у нас появляется возможность оптимизировать затраты на инфраструктуру. При необходимости, мы уже можем безболезненно добавлять фронтенд серверы и добавлять A запись для них. Также хорошей идеей будет размещение серверов балансировки перед фронтендами, тогда мы получим полный контроль над всем процессом прохождения запросов пользователей. Всё дальнейшее построение логики будет определяться полностью вашим приложением. Такая схема будет выглядеть следующим образом:
Выводы
Планировать архитектуру необходимо с самого начала жизни проекта, что в процессе развития сэкономит вам очень много времени и усилий. При планировании архитектуры проекта необходимо уделять внимание даже самым мельчайшим деталям. А также необходимо помнить основные моменты, а именно:
1. Резервирование каждого сервиса проекта;
2. Балансировка между фронтендами;
3. Балансировка между бекендами;
4. Кластеризация и отдельное вынесение базы данных;
Успешной реализации ваших проектов и гибкого масштабирования!
Автор:
