Мини-интервью Олега Анастасьева: отказоустойчивость в Apache Cassandra

Одноклассники – самый крупный пользователь Apache Cassandra в Рунете и один из крупнейших в мире. Мы начали использовать Cassandra в 2010 для хранения оценок фото, а сейчас под управлением Cassandra находятся петабайты данных на тысячах нод, более того, мы даже разработали свою собственную NewSQL транзакционную БД ^[1].
12 сентября в своём петербургском офисе мы проведем второй митап, посвященный Apache Cassandra ^[2]. Основным спикером мероприятия станет станет главный инженер Одноклассников Олег Анастасьев. Олег – эксперт в области распределённых и отказоустойчивых систем, он работает с Cassandra уже более 10 лет и неоднократно рассказывал об особенностях эксплуатации этого продукта на конференциях ^[3].

В преддверии митапа мы поговорили с Олегом про отказоустойчивость распределённых систем с Cassandra, поинтересовались о чем он будет рассказывать на митапе и почему стоит посетить это мероприятие.

Олег начал карьеру программиста в далеком 1995 году. Разрабатывал ПО в банковской сфере, телекоме, транспорте. Работает ведущим разработчиком в Одноклассниках с 2007 года в команде платформы. В его обязанности входит разработка архитектур и решений для высоконагруженных систем, больших хранилищ данных, решение проблем производительности и надежности портала. Также занимается обучением разработчиков внутри компании.

— Олег, привет! В мае состоялся первый митап ^[4], посвященный Apache Cassandra, участники говорят, что обсуждения шли до поздней ночи, скажи, пожалуйста, какие у тебя впечатления от первого митапа?

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

Мне было интересно и очень понравилось.

— Судя по анонсу, второй митап ^[2] будет полностью посвящен отказоустойчивости, почему выбрали именно эту тему?

Cassandra это типичная нагруженная распределённая система с огромным количеством функциональности помимо непосредственного обслуживания пользовательских запросов: gossip, обнаружение сбоев, распространение изменений схемы, расширение/уменьшение кластера, anti-entropy, бекапы и восстановление и т.д. Как и в любой распределённой системе с ростом количества железа растёт вероятность сбоев, поэтому эксплуатация production кластеров Cassandra требует глубокого понимания её устройства для предсказания поведения в случае сбоев и действий оператора. В процессе многолетнего использования Cassandra мы накопили значительную экспертизу ^[5], которой готовы поделиться, а также хотим обсудить, как коллеги по цеху решают типичные проблемы.

— Когда речь заходит о Cassandra, что ты понимаешь под отказоустойчивостью?

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

— Можешь привести пример самого нагруженного и самого большого кластера данных?

Один из наших самых больших кластеров — это кластер подарочков: больше 200 нод и сотни ТБ данных. Но он не является самым нагруженным, поскольку прикрыт распределённым кешем. Наши самые нагруженные кластера держат десятки тыс. RPS на запись и тысячи RPS на чтение.

— Ого! Как часто что-нибудь ломается?

Да постоянно ^[6]! Суммарно у нас больше 6 тыс. серверов, и каждую неделю пара серверов и несколько десятков дисков идут под замену (без учёта параллельных процессов апгрейда и расширения парка машин). Для каждого вида отказа прописана чёткая инструкция, что и в каком порядке делать, всё по возможности автоматизировано, поэтому отказы являются рутиной и в 99% случаев происходят незаметно для пользователей.

— Какие вы боретесь с подобными отказами?

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

— Как ты сказал, абсолютно надёжных систем не существует. К каким видам отказов вы готовитесь и способны пережить?

Если говорить о наших инсталляциях кластеров Cassandra, пользователи ничего не заметят, если мы потеряем несколько машин в одном ДЦ или целиком один ДЦ (такое случалось). С ростом количества ДЦ, думаем о том, чтобы начать обеспечивать работоспособность в случае сбоя двух ДЦ.

— Чего на твой взгляд не хватает Cassandra в плане отказоустойчивости?

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

Олег, большое спасибо что нашел время ответить на вопросы!

Мы ждем всех, кто хочет пообщаться с экспертами в области эксплуатации Apache Cassandra на митап 12 сентября в свой петербургский офис.

Приходите, будет интересно!

Зарегистрироваться на мероприятие. ^[2]

Автор: Александр Анисимов

Источник ^[7]