Тема 1/4: Введение в спринт 2 → Урок 2/2

Описание проектной работы 2

В этом уроке вы познакомитесь с проектной работой второго спринта. Это поможет вам оценить её сложность и распланировать своё время.
🔍 Обратите внимание: вам не нужно выполнять эти задания прямо сейчас. Можете пропустить этот урок и перейти к изучению теории. В конце спринта будет отдельный урок для сдачи проекта: там мы повторим задания и дадим форму, через которую нужно отправить решение.
Представьте, что вы с коллегой решили запустить небольшой онлайн-магазин. Там можно купить аксессуары для смартфонов. Вы сделали PоC для сайта. Его бэкенд состоит из нескольких микросервисов.
Затем вы решили запустить акцию «Чёрная пятница» и выпустили классную рекламу, которая привлекла много покупателей. В какой-то момент сайт перестал справляться с потоком новых пользователей и упал на несколько часов.
Чтобы узнать причины сбоя, вы провели исследование. Выяснилось, что один из микросервисов — API, который работает с базой данных, — не справился с нагрузкой и повлиял на работу всего приложения. Забились очереди обработки заказов, и таски начали отваливаться по тайм-ауту. В итоге вы потеряли много заказов и упустили прибыль.
Вот схема, которая изображает один инстанс приложения и одну ноду MongoDB:
Скоро вы хотите устроить ещё одну распродажу. Чтобы подготовиться к ней, вы планируете повысить отказоустойчивость приложения и увеличить пропускные способности инфраструктуры.
В ближайшее время вам нужно оптимизировать компонент системы, который отвечает за взаимодействие с MongoDB, и повысить отказоустойчивость ключевой базы данных.
Эту задачу вы и будете решать в проектной работе.

Подготовьтесь к работе

В репозитории GitHub лежит проект на Docker Compose. Он разворачивает текущий стенд микросервисного приложения: pymongo-api и single инстанс MongoDB.
Сделайте форк репозитория в свой личный репозиторий на GitHub и запустите проект локально для проверки:
  • Инструкция для запуска описана в README.md.
  • Приложение будет доступно на порту 8080.
  • Документацию API можно посмотреть на эндпоинте /docs.
Обратите внимание: чтобы запустить проект на Docker Compose, нужно минимум 2 CPU и 4 Гб ОЗУ.

Задание 1. Планирование

Вам предстоит реализовать шардирование, репликацию и кэширование. Чтобы это сделать, нужно распланировать изменения.
🔹 Вот шаблон схемы исходного приложения в draw.io. Скачайте его.
На основе шаблона вам нужно создать схему итогового решения. Рекомендуем работать над схемой в несколько этапов. Вот первые три шага:
  1. Подготовьте первый вариант схемы. Изобразите, как вы будете использовать шардирование в MongoDB для повышения производительности. Двух шардов будет достаточно.
  2. Подготовьте второй вариант схемы. Изобразите, как реализуете репликацию MongoDB для повышения отказоустойчивости. Чтобы это сделать, скопируйте первый вариант схемы и доработайте его таким образом, чтобы для каждого шарда была настроена репликация. Каждый шард должен иметь по три реплики.
  3. Подготовьте третий вариант схемы. Изобразите, как реализуете кэширование для ещё большего повышения производительности. Чтобы это сделать, скопируйте второй вариант схемы и добавьте инстанс Redis для кэширования запросов приложения к MongoDB.
Всего таких схем у вас получится пять, потому что в 5 и 6 заданиях тоже нужно поработать со схемой.
Ревьюер будет проверять только итоговую схему. На ней должны быть все изменения, которые вы внесёте в проект в процессе решения всех заданий.
Мы рекомендуем делать отдельные схемы для каждого этапа, потому что так проще контролировать изменения.

На что будет смотреть ревьюер

  • На схемах нужно указать инстанс приложения и все инстансы инфраструктурных сервисов, а также их типы (pymongo-api, configSrv, redis, shard1-1, shard1-2 и т. п.). Имена сервисов можно взять из примеров, которые описаны в уроках.
  • Выделите группы репликации.
  • Отобразите стрелками сетевые взаимодействия между сервисами.

Задание 2. Шардирование

  1. Скопируйте исходную директорию с приложением и compose.yaml под новым именем mongo-sharding.
  2. В файле compose.yaml измените имя проекта на name: mongo-sharding.
  3. Модифицируйте compose.yaml таким образом, чтобы реализовать первый вариант схемы. За основу можете взять пример из урока про шардирование.
  4. В директории с проектом создайте файл README.md. Опишите там шаги для инициализации шардирования в MongoDB.
💡 С помощью этого shell-скрипта можно автоматизировать выполнение команд на инстансах MongoDB:
BASH
docker compose exec -T <service-name> mongosh --port <mongo port> --quiet <<EOF
<mongosh commands here>
EOF
Например, так выглядят команды для отображения количества документов в БД somedb инстанса shard1:
BASH
docker compose exec -T shadr1 mongosh --port 27018 --quiet <<EOF
use somedb
db.helloDoc.countDocuments()
EOF
💡 Номера портов по умолчанию для различных типов инстансов MongoDB можно узнать в документации.
  1. Назовите БД somedb, а коллекцию — helloDoc.

На что будет смотреть ревьюер

  • Проект запускается.
  • Настройка по инструкции в README.md выполняется без ошибок.
  • Приложение работает и показывает общее количество документов в базе (≥ 1000), а также количество документов в каждом из шардов.

Задание 3. Репликация

  1. Скопируйте директорию с проектом mongo-sharding под новым именем mongo-sharding-repl.
  2. В файле compose.yaml измените имя проекта на name: mongo-sharding-repl.
  3. Модифицируйте compose.yaml таким образом, чтобы реализовать второй вариант схемы. За основу можете взять пример из урока про репликацию и кэширование.
  4. В директории с проектом создайте файл README.md. Опишите там шаги, которые нужно выполнить, чтобы настроить репликацию для каждого шарда в MongoDB.
💡 Не забывайте, что с помощью shell-скрипта можно автоматизировать выполнение команд.

На что будет смотреть ревьюер

  • Проект запускается.
  • Настройка по инструкции в README.md выполняется без ошибок.
  • Приложение работает и показывает общее количество документов в базе (≥ 1000), количество документов в каждом из шардов, а также количество реплик.

Задание 4. Кэширование

  1. Скопируйте директорию с проектом mongo-sharding-repl под новым именем sharding-repl-cache.
  2. В файле compose.yaml измените имя проекта на name: sharding-repl-cache.
  3. Модифицируйте compose.yaml таким образом, чтобы реализовать второй вариант схемы. В качестве ориентира можете использовать пример из урока про кэширование.
  4. Чтобы включить кэширование в приложении, добавьте переменную окружения:
    BASH
     REDIS_URL: "redis://<redis-service-name>:6379"
    Вместо <redis-service-name> напишите имя сервиса redis.
  5. В приложении кэширование доступно для эндпоинта /<collection_name>/users. Проверьте скорость выполнения повторных запросов — она должна увеличиться.

На что будет смотреть ревьюер

  • Проект запускается.
  • Настройка по инструкции в README.md выполняется без ошибок.
  • Приложение работает и показывает общее количество документов в базе (≥ 1000), количество документов в каждом из шардов, количество реплик.
  • Второй и последующие вызовы эндпоинта /<collection_name>/users выполняются <100мс.

Задание 5. Service Discovery и балансировка с API Gateway

На данный момент у вас развёрнут только один инстанс приложения. Это может вызвать простои в случае перезапуска приложения — например, при обновлении. Также один инстанс может просто не справиться с нагрузкой. Чтобы решить эту проблему, нужно реализовать горизонтальное масштабирование приложения.
Если запустить несколько инстансов приложения, то непонятно, на какой из инстансов подавать трафик. Для распределения трафика используйте API Gateway.
Ещё нужно как-то сообщать API Gateway об изменении количества инстансов. Например, что нужно добавить новые инстансы в балансировку или, напротив, убрать оттуда удалённые инстансы. Чтобы решить эту проблему, используйте Hashicorp Consul для Service Discovery.

Что нужно сделать

Составьте четвёртый вариант схемы. Изобразите, как вы реализуете горизонтальное масштабирование приложения. Для этого скопируйте третий вариант схемы и добавьте на него API Gateway для балансировки и Consul для Service Discovery.

На что будет смотреть ревьюер

На схеме нужно отобразить несколько инстансов приложения, инстансы Consul и API Gateway. Отобразите сетевое взаимодействие между ними с помощью стрелок.

Задание 6. CDN

Чтобы ускорить доставку статического контента пользователям в разных регионах, нужно использовать CDN.
Составьте пятый вариант схемы, на котором вы реализуете использование CDN. Для этого скопируйте прошлый вариант схемы и добавьте на него сервис CDN в нескольких регионах.

Как сдать работу

Когда решите все задания, создайте пул-реквест в основную ветку. Отредактируйте корневой файл README.md. Опишите там, как можно поднять стенд, чтобы ревьюер мог запустить приложение и увидеть все настройки финальной реализации MongoDB.
📎 Репозиторий должен содержать:
  1. Все созданные директории: mongo-sharding, mongo-sharding-repl, sharding-repl-cache. Для проверки будет использоваться директория sharding-repl-cache, которая должна включать в себя решение заданий 2, 3 и 4.
  2. Файл README.md, где вы описали шаги, которые нужно выполнить ревьюеру, чтобы запустить проект, содержащий приложение, Redis и MongoDB c шардированием и репликацией.
  3. Файл draw.io с итоговой схемой, которая получилась после решения заданий 1, 5 и 6.

Перед отправкой проверьте, что

  • В README.md проекта есть инструкция, как запустить проект. Обычно достаточно команды запуска проекта docker compose up -d и выполнения скрипта. Либо — команды инициализации и наполнения MongoDB.
  • Вы используете docker-образ приложения kazhem/pymongo_api:1.0.0.
  • Все сервисы запускаются. Проверить статус сервисов можно командой docker compose ps.
  • Приложение открывается в браузере и отображает JSON с информацией о MongoDB.
  • Приложение отображает информацию о MongoDB и статус использования кэша в формате JSON.
⚠️ Обратите внимание, для сдачи проекта необходимо сделать репозиторий на GitHub публичным.
Когда всё будет готово, вставьте ссылку на пул-реквест GitHub во вкладке «Ревью» в уроке «Сдача проектной работы 2».