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

Меня зовут Алексей Подольский. Я DevOps-инженер в Cloud.ru. В этой статье я расскажу о своем опыте освоения Tarantool в условиях жестких дедлайнов, предпосылках перехода на Tarantool, допущенных ошибках, полученном результате и сделанных выводах.

Материал подготовлен по мотивам вебинара «Как освоить Tarantool с нуля за 3 месяца и остаться в живых: учимся на ошибках DevOps-инженера».

Предпосылки перехода на Tarantool 

Когда я пришел в Cloud.ru, в нашем проекте было 10 сервисов, которые разрабатывались разными командами в разное время, но формировали единый продукт. Изначально это был частично распиленный монолит: некоторая функциональность вынесена в отдельные сервисы. В итоге дисперсия технологий и реализованных подходов была значительной. 

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

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

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

• используют микросервисную архитектуру;
  
• нуждаются в Real-Time-обработке данных;
  
• имеют большой стек сервисов — от авторизации пользователей до рекомендательных систем, как в нашем случае;
  
• являются высоконагруженными;
  
• должны дать максимально быстрый отклик конечному пользователю.
  

Так в нашем проекте стало два основных решения: PostgreSQL, от которого было невозможно отказаться одномоментно, и Tarantool, который решили использовать под запуск компонентов на независимых микросервисах.

Начало освоения: поиск материалов

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

1. Изучение официальной документации. На официальном сайте проекта представлена большая библиотека материалов, с помощью которых можно разобраться с инструментом и научиться его применять в своих проектах. Документации много, она подробная и сопровождается примерами — отличный источник знаний.
   
2. Изучение GitHub. У Tarantool большое сообщество. Поэтому на GitHub легко найти варианты документации, файлы с описанием модулей, примеры конфигураций и другие данные, которые можно попробовать применить на практике.
   
3. Общение в комьюнити. Вариант не самый простой и очевидный, но вполне рабочий. Например, найти специалистов по Tarantool можно на тематических форумах и в телеграм-каналах, на митапах, конференциях и других мероприятиях. В свое время я пошел именно по этому пути: после базового изучения документации инструмента посетил конференцию HighLoad, на которой смог лично пообщаться с разработчиками Tarantool. Я глубже погрузился в особенности построения отказоустойчивых кластеров, расчета ресурсов, нагрузочных тестов и других внутренних моментов. 
   

Требования к компетенции

Отдельно стоит оговорить вопрос компетенций. Cloud.ru — мое первое место работы, поэтому большого бэкграунда в разработке у меня не было. Однако для работы с Tarantool он и не понадобился — вполне хватило знаний и базовых навыков DevOps-инженера: как ставить табы в Yaml, как их писать, как использовать Ansible и так далее. Поэтому с точки зрения компетенций требования к работе с Tarantool минимальны: любой DevOps-специалист с опытом сможет освоить инструмент.

Аналогична ситуация и с изучением Lua — скриптового языка программирования с автоматическим управлением памятью, который содержит базовые элементы для поддержки функционального и объектного стилей программирования. 

К началу активного внедрения Tarantool в архитектуру Cloud.ru в нашей команде практически не было специалистов, которые знают Lua, в основном мы использовали Go и PHP. Вместе с тем освоить Lua оказалось несложно: свою роль сыграли синтаксис и общие принципы работы, схожие с другими языками. Упрощает ситуацию и то, что для Tarantool есть модули, которые позволяют использовать для работы не только Lua, но и другие языки, например Go, Java, C и Python. Благодаря этому порог входа в новый язык низкий.

Ошибки и их решение

Освоение Tarantool я начинал фактически с нуля: в команде практически не было специалистов со схожей компетенцией. Основными обучающими материалами стали официальная документация и наработки коллег из других проектов: ответов на многие вопросы в Google банально не было. В целом имеющихся материалов достаточно. Имея даже небольшой бэкграунд и знания в DevOps, освоить инструмент можно и в одиночку. Вместе с тем на своем опыте я столкнулся с рядом проблем, решение которых казалось сложным и неочевидным. Приведу некоторые из них.

Неточность при описании топологии кластера в init.lua

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

После детального изучения схожих случаев и консультации с техподдержкой Tarantool первоисточник проблем был найден — оказалось, что в описании топологии кластера в init.lua были допущены ошибки, а именно: в init Lua были IP-адреса Docker, а в inventory были IP-адреса виртуальных машин. 

Решить проблему помогло приведение топологии к общему виду с указанием IP-адресов ВМ только в инвентори ansible.

Недопустимость использования идентичных Cluster_cookie

В моем понимании Cluster_cookie были ничем иным как паролем, который нужен для входа в консоль Tarantool. Исходя из этого, значения Cluster_cookie для разных сервисов я указывал идентичные. В dev это не создавало проблем, но лишь до определенного момента, когда мы начали делить проект на разные кластеры и виртуальные машины. Оказалось, что все сервисы были фактически развернуты в одном огромном кластере с разными реплика-сетами — пока проблем не было, в это даже никто не пытался вникать. После начала разделения проекта на кластеры количество ошибок и сбоев многократно выросло.

При анализе я выяснил, что проблемы связаны с Cluster_cookie: в Tarantool разные кластеры с одинаковым Cluster_cookie, указанным в inventory, могут попадать в виртуальные машины на произвольных кластерах, что неизбежно приводит к нарушению топологии, сбоям при запуске сервиса и другим ошибкам. Решить проблему оказалось просто: в Tarantool Cluster_cookie приравниваются к ID, поэтому каждый из них должен быть уникальным. После внесения правок сбои прекратились.

Невозможность автоматического обновления патчей

В обычных условиях обновление патчей Tarantool занимает не больше пары минут: вызывается задача в коде приложения, собирается deb-пакет, Ansible последовательно раскатывает обновление по всем кластерам. Все выполняется через CI без остановки кластера.

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

После нескольких попыток стало понятно, что проблема в том, что Tarantool не смог автоматически обновить патч. Решить ситуацию удалось не самым очевидным способом: вместо версии 2.8.4 вручную обновили Tarantool через пакет 2.10.6. Для обновления написали плейбук, который в момент обновления перекидывает роль мастера на реплику, обновляет то, что было мастером до этого, после чего возвращает роль мастера основному кластеру.

Что после преодоления ошибок

Наш опыт показал, что работа с Tarantool — реальный пример поговорки «от любви до ненависти один шаг», только наоборот, «от ненависти до любви». Почему?

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

После освоения инструмента мы смогли поставить работу с Tarantool на поток: безопасно масштабировать сервисы, автоматизировать CD-процессы, обеспечить отказоустойчивость всей системы. Одновременно с этим кратно уменьшилось количество неочевидных ошибок. Также мы выработали внутреннюю экспертизу по работе с Tarantool. Более того, он стал основной базой данных для части микросервисов и, как результат, неотъемлемой частью архитектуры нашего продукта. 

Рекомендации от DevOps

Tarantool — классный инструмент, который можно освоить в относительно сжатые сроки. Например, у меня на это ушло три месяца. Вместе с тем стоит понимать, что ошибки при освоении любого нового инструмента неизбежны — на начальных этапах работы с Tarantool они тоже будут. Но мой опыт показал, что любые, даже самые неочевидные проблемы в Tarantool можно решить, достаточно внимательно изучать настройки кластера (часть проблем в них) и обучающие материалы. В качестве последних подойдет официальная документация, разборы на форумах и даже примеры на GitHub — зачастую их хватает, чтобы разобраться в инструменте и механике работы с ним.