Продолжаем серию о том, как мы эффективно управляем инфраструктурой Yubo силами небольшой команды. В Части 1 мы представили нашу инфраструктуру, а в Части 2 подробно разобрали структуру команды и её философию. Сегодня мы разберём, как масштабировали практики дата-инжиниринга, чтобы обслуживать более 80 миллионов пользователей силами всего пяти человек.
Масштабировать дата-инжиниринг непросто, особенно когда речь идёт об огромной пользовательской базе и маленькой команде. Это требует стратегического планирования, продуманного инструментария и культуры, поощряющей эффективность. Вот как мы это делаем.
1. Вовлекаем дата-инженеров в проектирование фич на раннем этапе
Один из краеугольных камней нашего подхода — привлечение дата-инженеров к проектированию фич с самого начала. Подключая их к обсуждению на старте, мы гарантируем, что разрабатываемые модели данных будут масштабируемыми, эффективными и устойчивыми к будущим изменениям. Дата-инженеры больше не просто «разработчики пайплайнов» — они полноценные архитекторы решений.
Вовлечение дата-инженеров с самого начала позволяет заранее решать потенциальные проблемы масштабируемости, пока они не превратились в реальные. Ранняя совместная работа приводит к моделям данных, оптимизированным как по производительности, так и по масштабируемости. Кроме того, это обеспечивает согласованность между командами: все находятся на одной волне в отношении требований к данным, ограничений и будущего развития.
Мы выстраиваем тесное взаимодействие между дата-инженерами, продакт-менеджерами и разработчиками с самой первой установочной встречи. Это гарантирует полное понимание целей фичи и потребностей в данных. Результат — надёжный и масштабируемый дизайн данных с первого дня.
2. Не боимся дублирования данных
Вопреки традиционной мудрости, мы не боимся дублирования данных. Более того, дублирование даёт нам несколько преимуществ. Разделение данных позволяет каждой фиче работать независимо, что естественным образом приводит к дублированию части данных между сервисами. Такая независимость снижает задержки и повышает производительность за счёт локального доступа к данным. Кроме того, это упрощает масштабирование, поскольку фичи могут масштабироваться независимо друг от друга.
Выбираем правильную базу данных под каждый сценарий
Мы твёрдо убеждены, что каждую базу данных нужно подбирать под её идеальный сценарий использования, применяя для каждой конкретной задачи наиболее подходящий инструмент.
Наша экосистема баз данных состоит из MongoDB для гибкого документного хранения, KeyDB для быстрого кеширования в памяти, Elasticsearch для мощного поиска и аналитики, Couchbase для распределённого NoSQL-хранения и доступа к данным в реальном времени, PostgreSQL для традиционных реляционных данных и нашего Data Lake для крупномасштабной аналитики.
При выборе базы данных мы оцениваем три ключевых фактора: модель данных (структурированные, неструктурированные или реляционные), паттерны доступа (характер операций чтения и записи) и требования к масштабируемости (ожидаемый рост и нагрузку). Такой тщательный подход к выбору помогает нам оптимизировать производительность, сохраняя архитектуру чистой и эффективной.
3. Определяем источник истины
Хотя дублирование данных приносит множество преимуществ, оно может усложнить обеспечение согласованности данных. Чтобы решить эту проблему, мы применяем стратегию единого источника истины (single source of truth, SSOT). Для каждого типа данных мы явно определяем, какая система или сервис является авторитетным источником. Мы используем продвинутые механизмы синхронизации, чтобы изменения в первичном источнике точно отражались во всех дублированных экземплярах. Внедрение версионирования и аудита помогает нам отслеживать изменения и вести понятную историю эволюции данных.
Сочетая дублирование данных с чётко определённой стратегией SSOT, мы балансируем между оптимизацией производительности и согласованностью данных, благодаря чему система остаётся эффективной и надёжной по мере масштабирования.
Используем Kafka и Change Data Capture (CDC)
В основе нашей стратегии синхронизации данных лежат Kafka и концепция Change Data Capture (CDC).
Kafka служит нашим надёжным опорным каналом обмена сообщениями, обеспечивая передачу данных в реальном времени между распределёнными системами. Она развязывает производителей и потребителей данных, позволяя сервисам работать независимо и повышая масштабируемость за счёт своей распределённой природы. Kafka также выступает буфером, не давая базам данных перегружаться в пиковые моменты.
Kafka ставит входящие данные в очередь, сглаживая всплески трафика. Она обеспечивает отказоустойчивость, удерживая данные при выходе базы из строя до её восстановления. Несколько потребителей могут читать из Kafka в собственном темпе, что делает потребление масштабируемым. Более того, Kafka позволяет сервисам выбирать наиболее подходящую базу данных без ограничений, обеспечивая гибкость в выборе хранилища.
Change Data Capture позволяет нам эффективно захватывать и распространять изменения из первичных источников данных. Это гарантирует, что все системы остаются в актуальном состоянии с самыми свежими данными без жёсткой связанности.
4. Даём разработчикам self-service-автоматизацию баз данных
Чтобы устранить узкие места и расширить возможности разработчиков, мы создали self-service-платформу для баз данных на основе Kubernetes Custom Resource Definitions (CRD). Эта платформа позволяет разработчикам самостоятельно описывать и разворачивать нужные им ресурсы баз данных, не обращаясь к команде инфраструктуры, что развивает автономность.
Благодаря такому self-service-подходу мы обеспечиваем единообразие сред: стандартизированные описания гарантируют одинаковость в разработке, staging и продакшене. Операционные накладные расходы снижаются, высвобождая команду инфраструктуры для стратегических задач. Разработчики декларативно описывают нужные ресурсы в YAML-файлах, а операторы Kubernetes автоматизируют создание этих ресурсов баз данных и управление ими.
Наша self-service-платформа поддерживает несколько баз данных, включая MongoDB, KeyDB, Elasticsearch, Couchbase и наш Data Lake (о котором мы расскажем в одной из будущих серий блога). Абстрагируя сложность управления базами данных, мы позволяем разработчикам сосредоточиться на создании фич, а не на заботах об инфраструктуре.
5. Заключение
Масштабирование дата-инжиниринга в среде быстрого роста не обязано быть непосильной задачей — даже для небольшой команды. Вовлекая дата-инженеров в проектирование фич на раннем этапе, используя Kafka как систему развязки, подбирая правильные базы данных под каждый сценарий и предоставляя разработчикам self-service-инструменты, мы построили масштабируемую и эффективную инфраструктуру данных, которая обслуживает более 80 миллионов пользователей.