Шарды и реплики в геораспределённой среде

В прошлой теме вы рассмотрели полный цикл масштабирования базы данных. Но все изменения проводились внутри компании: новые серверы и мощности добавлялись к текущей инфраструктуре.
К сожалению, такой подход не гарантирует надёжности работы приложения. Например, в момент большой распродажи даже увеличенных «железных» мощностей может просто не хватить. Кроме того, обслуживать собственную инфраструктуру дорого — такое могут себе позволить только крупные компании.
Все эти проблемы решает использование публичного облачного хранилища. В этой теме вы узнаете, в чём суть облаков, какие у них есть преимущества и как на практике масштабировать инфраструктуру с помощью Yandex Cloud.

Облако и гибридная архитектура

Компании, которые хотят гибко управлять ресурсами и оптимизировать затраты на поддержку «железа», рано или поздно приходят к облаку. После этого наступает сложный и интересный этап переезда, который не обходится без распила легаси-монолитов и роста технической культуры компании в целом. В итоге архитектура начинает выглядеть так:
Такая архитектура называется гибридной: часть лежит в публичном облаке, а часть внутри компании — либо тоже в облаке, но частном, либо просто на «железе». Полного переезда в публичное облако обычно не происходит по ряду причин:
  • Не всякое легаси и сложившуюся внутреннюю архитектуру можно перенести в облако: нужна настоящая революция, а это долго и дорого.
  • «Публичность» и «конфиденциальность» — понятия плохо совместимые. Поэтому секретную информацию и инфраструктуру часто оставляют во внутренней инфраструктуре, а более безопасную, но нагруженную — выносят в облако.
  • Не во всяком облаке можно хранить и обрабатывать персональные данные: нужно соответствие 152-ФЗ, да ещё и подходящему уровню защищённости. У одних облаков оно есть, у других — нет.
☝ Если строить инфраструктуру с нуля, можно сразу организовать её исключительно в облаке, без гибрида. Этот метод особенно хорош, если планируется большая нагрузка, а «железо» придётся закупать с нуля и некому будет его обслуживать.

Преимущества гибридной архитектуры

  • Гибкость в поддержке Доступ к данным возможен в любое время из любой точки мира. Можно быстро заказать нужные ресурсы и тем самым оптимизировать работу IT-отдела.
  • Сокращение расходов Происходит благодаря экономии на капитальных вложениях в расширение инфраструктуры.
  • Улучшение масштабируемости Достигается путём быстрого использования ресурсов облачного провайдера. **Позволяет компаниям адаптироваться к взлётам и падениям нагрузки.
  • Быстрый выход на рынок Увеличивается за счёт повышения производительности IT и гибкости.
  • Непрерывность бизнеса Гарантируется созданием резервных копий критически важных данных и масштабированием в случае увеличения спроса.
  • Сохраняется безопасность Достигается благодаря контролю над данными и ограничению доступа.
  • Оптимизация скорости и увеличение отказоустойчивости за счёт увеличения географии
    Облачная инфраструктура, как правило, находится в разных ЦОДах и в разных регионах, что облегчает доступ к данным пользователям из определённых близких к этим ЦОДам регионам — получается что-то вроде геошардирования. В случае аварии в каком-то регионе остальные продолжают работать.
В облаке ресурсы поставляют в частично готовом виде: по моделям IaaS, PaaS или SaaS. В каждой модели частью ресурсов управляет облако, а частью — вы сами.

Недостатки гибридной архитектуры

  • Сложность интеграции  Интеграция внутренней инфраструктуры и публичного облака требует сложной настройки мониторинга и инструментов управления инфраструктурой.
  • Недостаточная безопасность В некоторых компаниях требования к безопасности настолько строгие, что они вообще не допускают хранения многих данных в публичном облаке. Например, такое бывает с банками или государственными учреждениями.
☝ Yandex Cloud сертифицирован на соответствие Федеральному закону 152 «О персональных данных». При этом безопасность у него всё же ниже, чем у частного облака. Многие государственные предприятия не могут использовать публичное облако в силу повышенных требований к безопасности и требований к обработке персональных данных.

Шарды и реплики в геораспределённой среде

Давайте вспомним, что мы узнали про шардирование и репликацию баз данных. Для этого посмотрите на схему — а при необходимости вернитесь к прошлой теме, если что-то забыли.
Теперь рассмотрим пример реализации шардирования в Yandex Cloud.

Создание шардированного кластера MongoDB

В этом и двух предстоящих уроках мы покажем, как настроить шардирование, распределённое кэширование и CDN в Yandex Cloud.
🔍 Вам не придётся самостоятельно оплачивать облачные ресурсы. Наши партнёры из Yandex Cloud выдали вам грант — его хватит, чтобы выполнить практические задания в этой теме.
Проверьте свою почту: вам должно было прийти письмо с промокодом. Если вы не можете найти письмо, проверьте папки спама и рассылки. Если его там нет — обратитесь к куратору.
Это не стартовый грант, который Yandex Cloud выдаёт всем новым пользователям, а дополнительный. Подробнее о разных видах грантов можете почитать в документации.
Обратите внимание: чтобы гранта точно хватило, вам нужно контролировать расход грантовых средств.
Чтобы избежать ненужных трат:
  • Контролируйте расходы с помощью бюджета и уведомлений, которые можно настроить в разделе Биллинг. Как это сделать, читайте в документации.
  • Удаляйте ресурсы в перерывах между выполнением практических работ.

Практика

Прежде чем приступить к практике убедитесь, что вы активировали промокод. Если вы ещё не сделали это, воспользуйтесь инструкцией.
  1. Основной точкой входа служит консоль Yandex Cloud. Перейдите в неё.
  2. Вам станет доступен такой личный кабинет. В разделе Все сервисы выберите Managed Service for MongoDB.
  1. В появившемся окне нажмите Создать кластер.
  1. Затем задайте параметры CPU/RAM:
  1. Задайте несколько зон доступности, чтобы реплики были в разных дата-центрах. Это и есть геораспределение, которое повысит надёжность системы:
  1. Добавьте хост:
  1. Посмотрите на блок расширенных настроек СУБД — в нём можно будет задавать более сложные параметры, когда они понадобятся вам в работе:
  1. Нажмите Создать кластер и немного подождите. Он создастся и будет готов к работе.
  2. Теперь кластер готов и пора переходить к репликации и шардированию. Для этого откройте документацию Yandex Cloud про MongoDB.
В разделе про шардирование кластер можно сразу создать шардированным и позже добавлять и настраивать шарды.
☝ Для повышения доступности шарды должны состоять как минимум из трёх хостов. Небольшие коллекции нет смысла шардировать: скорость обработки запросов будет выше в обычном кластере реплик.
Ещё шардирование можно включить позже либо сделать кластер шардированным можно через консоль или Terraform.
  1. Сначала понадобится создать реплики. Перейдите в раздел Хосты и выберите Создать хост:
Немного подождите:
В разделе Топология вы увидите, как появился secondary-хост:
  1. Теперь зайдите в Шарды и включите шардирование:
Вот что произойдёт:
Обратите внимание, что создаётся три машины со стандартным шардированием.
💡 Стандартное шардирование — экономичный тип шардирования для кластеров, в которых нет особых требований к хостам. Например, высокая доступность и мощность процессора.
В кластер будут добавлены хосты MONGOINFRA, сочетающие в себе роли MONGOS и MONGOCFG:
Напомним схему шардирования из предыдущей темы:
После проделанных выше действий схема будет выглядеть следующим образом:
  1. По пути Хосты → Создать хост можно добавить Шард-2 и Шард-3:
Постепенно вы соберёте схему для обеспечения высокой доступности:
Собирая инстанс, вы могли заметить, что стоимость MongoDB с каждым хостом существенно растёт. Поэтому внедрение и управление базами данных с распределением по регионам может быть слишком дорогим для некоторых организаций.
💡 Как только выполните последний пункт задания, удалите кластер. Это нужно, чтобы ресурсы не расходовались впустую и не было лишних расходов.
Это можно сделать на странице списка кластеров:.
В результате всех этих настроек инфраструктура «Мегашопа» стала выглядеть вот так:

Задание 1

Какие преимущества даёт облачная инфраструктура в сравнении с On premise?

Задание 2

Определите, для каких компаний будет эффективнее использовать частное облако, для каких гибридное, а для каких полностью существовать в облаке?
Стартап с ограниченным бюджетом
Облачная инфраструктура
Крупный государственный банк, который планирует переход с монолитной архитектуры на микросервисную
Частное облако
Сеть частных поликлиник, которая тестирует новый функционал для B2C-клиентов
Гибридное облако
Популярный онлайн-кинотеатр, который испытывает проблемы со скоростью
Гибридное облако
Ретейлер бытовой техники
Гибридное облако
Экологическая компания с крупными государственными заказчиками
Частное облако

Итоги

  • Масштабироваться только на собственном железе может быть неудобно и невыгодно. В таком случае компании обычно прибегают к услугам облачных провайдеров.
  • Часто инфраструктура компаний становится гибридной: часть данных и сервисов они хранят у себя, а часть — в публичном облаке. Это позволяет не переезжать сразу целиком, сохранить в защищённой среде чувствительные данные и при этом пользоваться преимуществами облаков.
  • Гибридная архитектура удобная, масштабируемая и экономная, однако нуждается в более сложном управлении и мониторинге.
  • В геораспределённой облачной среде можно создавать шарды и реплики — вы отработали это на практике, создав кластер MongoDB с шардированием в Yandex Cloud.
В следующем уроке вы узнаете о том, как настроить кэширование в такой облачной геораспределённой среде.