Основной многих проектов являются кастомные решения и инструменты — часто кажется, что так проще и быстрее. Но на практике при динамичном масштабировании проектов наличие крупных кастомных узлов начинает создавать трудности: требуется больше времени, ресурсов и дополнительных издержек. Поэтому с ростом проектов командам нередко разумнее пересматривать стек в пользу готовых решений.

Я Александр Поливанов, технический директор VK Teams. В этом материале я расскажу, с чего начинался VK Teams, какое кастомное решение мы изначально задействовали, почему были вынуждены от него отказаться, что учитывали при выборе новой технологии и какие задачи смогли закрыть с помощью внедренного Tarantool.

Материал подготовлен на основе совместного вебинара с Монсом Андерсоном «It's a match! Как Tarantool помог VK Teams построить микросервисную архитектуру».

Немного о VK Teams: что сейчас представляет собой корпоративный суперапп

VK Teams — платформа для корпоративного общения и совместной работы с коллегами. Решение доступно на всех клиентских платформах и представлено в двух версиях:

• SaaS (software as a service) — сервис в облаке;
  
• On-Premise — коробочное ПО, которое разворачивается на собственной инфраструктуре компаний и интегрируется в его ИТ-ландшафт.
  

VK Teams — суперапп. Он объединяет в едином цифровом пространстве функции разных приложений:

• корпоративный мессенджер;
  
• сервис для аудио- и видеозвонков;
  
• хранилище;
  
• таск-трекер;
  
• почту;
  
• платформу для создания мини-приложений для автоматизации процессов.
  

При разработке и развитии решения мы в первую очередь исходили из потребностей On-Premise-версии — она должна стабильно и без сбоев работать вне нашего доступа, в закрытом контуре заказчика. Поэтому требования к ней значительно выше, чем к сервису в облаке. Это сказалось на выборе стека — выбирать технологии и следить за их разнообразием в проекте приходится тщательнее.

VK Teams имеет микросервисную архитектуру, которая включает более 100 различных микросервисов, 30 из них — на Tarantool. Типичный микросервис представляет собой сервис, который хранит свои локальные данные в собственной базе, будь она встраиваемая или отдельностоящая.

С чего все начиналось

Сначала VK Teams:

• имел «комбинированную» архитектуру (лишь часть микросервисов);
  
• был написан на C и C++;
  
• использовал MySQL в качестве основной базы данных, в которой хранилось все, в том числе видео и фотографии пользователей;
  
• задействовал большой «зоопарк технологий» для оркестрации, масштабирования и резервирования.
  

Для полноценной работы VK Teams нам требовалось универсальное хранилище, которое легко поддерживать и масштабировать с учетом развития проекта. Но:

• В то время (2014 год) SSD только начали появляться в серверном оборудовании, а HDD стоили дешево и с RAID обеспечивали достаточную скорость чтения.
  
• RAM стоила дорого и была ограничена: на серверах редко было больше 40–50 ГБ.
  
• Нам не подходили типовые дисковые базы данных. К тому же нам требовалось универсальное решение, которое можно использовать для хранения любых данных: историй, аватаров, переписки и других.
  

После анализа рынка с учетом наших запросов мы решили написать на С свою embedded key-value БД с LRU-кешем. Для ее корректной работы мы также разработали средства масштабирования, резервирования, оркестрации и другие, которые нужны для баз данных.



В результате БД и ее «обвязка» стала основным, практически безальтернативным решением для VK Teams на годы вперед.

Как начали внедрять Tarantool

В процессе эксплуатации своей БД мы начали сталкиваться с некоторыми трудностями. Примерно за пять лет набралась их «критическая масса».

• Сложность поддержки. Только на поддержку собственной базы данных и своевременное устранение багов нужно много ресурсов, в том числе выделенная команда. Чтобы развивать ее, надо постоянно увеличивать затраты и количество привлеченных специалистов.
  
• Потребность во внутренней экспертизе. В нашем случае БД была продуктом одной команды. Поэтому при онбординге новых членов команды они были вынуждены заниматься разработкой не только VK Teams, но и поддержкой БД. Это повышало порог входа и создавало дополнительную нагрузку на специалистов.
  
• «Пробелы» в документации. Для внедрения самописной БД в промышленную среду заказчика нужна была объемная документация, которой иногда не хватало — при разработке решения «для себя» ее просто не делали. 
  
• Отсутствие внешнего комьюнити. Поскольку основным потребителем БД была только наша команда (сами используем свой продукт), «костяк» комьюнити сформирован из членов одной команды. В итоге находить все баги и способы устранения нужно было своими силами, а это сложно и долго. Постепенное «размытие» экспертизы, связанное с уходом специалистов, смещало фокус на разработку основного продукта — VK Teams.
  

Для нас стало очевидно, что от концепции использования своего решения нужно уходить, потому что издержки были велики и неоправданны. Начали искать универсальное решение, способное «закрыть» наши потребности с учетом уже имеющегося стека и динамично увеличивающейся нагрузки со стороны VK Teams. После небольшого исследования выбрали Tarantool — платформу in-memory-вычислений с гибкой схемой данных для создания высоконагруженных приложений, которая объединяет базу данных и сервер приложений на Lua. 

В пользу Tarantool было три фактора:

• Его возможности аналогичны традиционным СУБД (персистентность, транзакционность ACID, репликации master-slave и master-master), но скорость работы существенно выше.
  
• Tarantool перестал быть новым и нишевым решением, которое только вышло на рынок Open Source — его уже успешно использовали крупные проекты, в том числе в схожих кейсах.
  
• К 2019 году оперативная память, на которой базируется работа Tarantool, стала дешевле и доступна практически в неограниченных объемах.
  

Сценарии применения Tarantool в VK Teams

Tarantool можно использовать в разных сценариях. В случае VK Teams варианты применения можно разделить на несколько групп.

Persistent cache

Мы не стремимся к использованию классических неперсистентных кешей, поскольку они таят в себе очень сильную неопределенность. Например, холодный запуск после сбоя, который может оказаться критическим в инсталляциях с миллионом RPS.

Но мы используем персистентные кеши несколько иначе: поскольку во внешних системах, в которые интегрируется VK Teams, могут быть ограничения по пропускной способности, времени работы или другим критериям, мы кешируем все данные у себя. Благодаря этому мы:

• соблюдаем ограничения внешних систем;
  
• не теряем скорость на внешних запросах;
  
• получаем предсказуемое поведение и производительность.
  

Tarantool в качестве персистентного кеша для VK Teams мы используем, например, для:

• интеграции Keycloak и Active Directory и быстрых запросов к ним;
  
• сохранения метаданных файлов из внешних БД.
  

Key-value database

Наш классический микросервис — это сервис, который хранит только свои данные, в своей базе, сам с ней работает, и все обращения к этим данным идут только через него. Поэтому мы задействуем Tarantool также и в качестве отдельной базы данных. Это дало нам ряд преимуществ:

• У Tarantool хорошее соотношение полезного объема к служебному. Например, сервисы, которые занимаются резолвингом одного идентификатора в другой, легко помещаются в оперативную память, практически без накладных расходов. При переходе с самописной БД на Tarantool мы улучшили показатели по использованию оперативной памяти в 10 раз.
  
• Данные всегда «теплые». Они хранятся в оперативной памяти, благодаря чему нет cache miss — доступ к информации стабильный, прогнозируемый и быстрый.
  
• Данные в Tarantool можно получить через консоль. Они хранятся по определенной схеме, благодаря чему с помощью простых скриптов их легко запросить для любых задач, например, для сбора статистики. Необходимость разработки отдельного сервиса при этом отпадает.
  

Кейсов, в которых Tarantool используется в качестве Key-value database для VK Teams, много. Например:

• хранение задачи встроенного таск-трекера;
  
• преобразование одного типа ID в другой;
  
• хранение обратных индексов.
  

Важно, что Tarantool легко масштабируется. Это позволяет нам строить системы, выдерживающие более 1 млн RPS, и быстро адаптироваться к возрастающим нагрузкам.

Queue

Мы создаем синхронную систему — считаем, что не нужно отдавать пользователю результат, пока его запрос не прошел по всем сервисам, базам данных и другим узлам. Так гарантируется надежность доставки данных. Поэтому мы на уровне всей системы получаем глобальную очередь, состоящую из пользовательских запросов, сгенерированных клиентским приложением.

Но в VK Teams есть и второстепенные системы, от которых необязательно дожидаться ответа или его можно получить асинхронно. Очередь на Tarantool мы используем именно для них. Например:

• отправляем файлы на проверку антивирусом;
  
• отправляем сообщения в DLP.
  

Одним из преимуществ такого сценария для нас стало большое количество библиотечных инструментов, очереди можно создавать практически в одну строку без дополнительных затрат времени.

В нашем случае Tarantool по двум причинам был приоритетнее Rabbit и Kafka, которые де-факто являются стандартом для очередей:

• Наличие компетенций. Редкая очередь системы не обходится без кастомизации, а знакомый инструмент проще кастомизировать. Получать компетенцию по эксплуатации новой технологии нам не понадобилось.
  
• Наличие On-Premise-реализации VK Teams. Приходится делать тройную работу: сначала выбрать технологию и разработать решение; потом внедрить его в коробочное решение так, чтобы все работало надежно и полностью автоматически; и, наконец, — устранять баги и решать возникающие вопросы во внешнем контуре компании. Поэтому удобнее не создавать «зоопарк технологий», а работать с одним знакомым решением. Tarantool мы используем и в других кейсах, поэтому он был в приоритете.
  
  

Application Server

Мы изначально стремились к созданию сервисов со встраиваемой БД, ведь такая реализация:

• не требует отдельного демона;
  
• проще в разработке и деплое;
  
• позволяет получать доступ к данным без дополнительных сетевых запросов;
  
• позволяет использовать «зеленые треды», которые доступны «из коробки».
  

Большие сервисы с высокой, динамически меняющейся нагрузкой и сложной бизнес-логикой мы разрабатываем отдельно. 

Одновременно с этим иногда рационально использовать Tarantool в качестве Application Server. Например, так мы реализуем:

• очереди событий для bot API;
  
• сервис хранения, обновления, преобразования и поиска профилей.
  

Встроенные возможности и дополнительные реализации

Для VK Teams также оказался полезен ряд встроенных возможностей Tarantool, которые доступны в пакетном менеджере решения буквально по одному клику:

• нативная поддержка разных индексов, например, R-tree;
  
• встроенная репликация;
  
• встроенный SSL, ролевая модель.
  

Они позволяют нам реализовывать и гарантировать: 

• выдачу чатов в зависимости от географических координат пользователя — в Tarantool есть встроенные R-tree, которые позволяют это сделать  несколькими строчками кода;
  
• резервирование и катастрофоустойчивость благодаря доступным инфраструктурным решениям;
  
• шифрование протоколов передачи данных;
  
• ограничение прав доступа и выдачу минимально необходимых привилегий.
  

Выводы из нашего опыта: задачи для Tarantool

Сейчас в VK Teams более 100 различных микросервисов, 30 из них — на Tarantool. Мы уже запустили в production несколько десятков On-Premise-инсталляций, самые крупные из которых достигают 200 тысяч пользователей. При этом наша облачная платформа работает под нагрузкой более 1 млн RPS.

На основе своего опыта мы выделили ряд стандартных задач, для которых Tarantool подойдет лучше аналогов:

• Когда данные разумно хранить в оперативной памяти. При условии, если их объем не превышает терабайтов, иначе это будет дорого и нерентабельно.
  
• Когда необходима система с минимальным временем отклика. Платформа in-memory-вычислений позволяет получить доступ к любым данным в хранилище в разы быстрее и стабильнее, чем БД на основе HDD и SSD.
  
• Когда важно уменьшить количество холодных стартов системы. Любая система имеет тенденцию к росту пользователей. При кратном увеличении RPS холодный старт системы может стать критически важным, в том числе сказаться на предсказуемости времени запуска. Tarantool исключает этот риск, ведь данные в in-memory всегда «прогреты».
  
• Когда необходимо управлять количеством технологий. Чем меньше технологий в ИТ-ландшафте, тем проще и быстрее устранять баги, тем ниже требования к компетенции специалистов. К тому же, например, в случае с On-Premise-реализациями чем больше технологий, тем выше сложность их настройки и поддержки. Благодаря универсальности Tarantool может заменить бо̒льшую часть «зоопарка технологий» и стать основным решением в проекте.  
  
• Когда важно экономить время, то есть использовать готовые библиотеки и опыт сообщества. Для Tarantool есть много стандартных библиотек, которые поддерживают, дополняют, обновляют и своевременно «лечат» от багов. Благодаря этому для типовых задач можно использовать готовые решения, а не «изобретать велосипед».
  
• Когда нужен быстрый старт проекта и простой онбординг. Благодаря большому сообществу, обучающим роликам и подробной документации Tarantool легко освоить и внедрить в любой проект. У разработчиков команды VK Teams на базовое освоение Tarantool, как правило, уходит до недели.
  

Скачать Tarantool можно на официальном сайте, а получить помощь — в Telegram-чате.