Одноклассники – самый крупный пользователь Apache Cassandra в Рунете и один из крупнейших в мире. Мы начали использовать Cassandra в 2010 для хранения оценок фото, а сейчас под управлением Cassandra находятся петабайты данных на тысячах нод, более того, мы даже разработали свою собственную NewSQL транзакционную БД.
12 сентября в своём петербургском офисе мы проведем второй митап, посвященный Apache Cassandra. Основным спикером мероприятия станет станет главный инженер Одноклассников Олег Анастасьев. Олег – эксперт в области распределённых и отказоустойчивых систем, он работает с Cassandra уже более 10 лет и неоднократно рассказывал об особенностях эксплуатации этого продукта на конференциях.
В преддверии митапа мы поговорили с Олегом про отказоустойчивость распределённых систем с Cassandra, поинтересовались о чем он будет рассказывать на митапе и почему стоит посетить это мероприятие.
Олег начал карьеру программиста в далеком 1995 году. Разрабатывал ПО в банковской сфере, телекоме, транспорте. Работает ведущим разработчиком в Одноклассниках с 2007 года в команде платформы. В его обязанности входит разработка архитектур и решений для высоконагруженных систем, больших хранилищ данных, решение проблем производительности и надежности портала. Также занимается обучением разработчиков внутри компании.
— Олег, привет! В мае состоялся первый митап, посвященный Apache Cassandra, участники говорят, что обсуждения шли до поздней ночи, скажи, пожалуйста, какие у тебя впечатления от первого митапа?
Пришли разработчики с разным бекграундом из различных компаний со своей болью, неожиданными решениями проблем и удивительными историями. Нам удалось провести большую часть митапа в формате дискуссии, но обсуждений было так много, что мы смогли затронуть лишь треть намеченных тем. Много внимание уделили тому, как и что мы мониторим на примере наших реальных production-сервисов.
Мне было интересно и очень понравилось.
— Судя по анонсу, второй митап будет полностью посвящен отказоустойчивости, почему выбрали именно эту тему?
Cassandra это типичная нагруженная распределённая система с огромным количеством функциональности помимо непосредственного обслуживания пользовательских запросов: gossip, обнаружение сбоев, распространение изменений схемы, расширение/уменьшение кластера, anti-entropy, бекапы и восстановление и т.д. Как и в любой распределённой системе с ростом количества железа растёт вероятность сбоев, поэтому эксплуатация production кластеров Cassandra требует глубокого понимания её устройства для предсказания поведения в случае сбоев и действий оператора. В процессе многолетнего использования Cassandra мы накопили значительную экспертизу, которой готовы поделиться, а также хотим обсудить, как коллеги по цеху решают типичные проблемы.
— Когда речь заходит о Cassandra, что ты понимаешь под отказоустойчивостью?
В первую очередь, конечно, способность системы переживать типичные сбои железа: потерю машин, дисков или сетевой связности с нодами/датацентрами. Но сама тема гораздо шире и в частности включает в себя восстановление после отказов, в том числе отказов, к которым люди редки бывают готовы, например, ошибок оператора.
— Можешь привести пример самого нагруженного и самого большого кластера данных?
Один из наших самых больших кластеров — это кластер подарочков: больше 200 нод и сотни ТБ данных. Но он не является самым нагруженным, поскольку прикрыт распределённым кешем. Наши самые нагруженные кластера держат десятки тыс. RPS на запись и тысячи RPS на чтение.
— Ого! Как часто что-нибудь ломается?
Да постоянно! Суммарно у нас больше 6 тыс. серверов, и каждую неделю пара серверов и несколько десятков дисков идут под замену (без учёта параллельных процессов апгрейда и расширения парка машин). Для каждого вида отказа прописана чёткая инструкция, что и в каком порядке делать, всё по возможности автоматизировано, поэтому отказы являются рутиной и в 99% случаев происходят незаметно для пользователей.
— Какие вы боретесь с подобными отказами?
С самого начала эксплуатации Cassandra и первых инцидентов мы проработали механизмы резервных копий и восстановления из них, построили процедуры deploy, которые учитывают состояние кластеров Cassandra и, например, не дают перезапускать узлы, если возможна потеря данных. Про всё это мы планируем поговорить на митапе.
— Как ты сказал, абсолютно надёжных систем не существует. К каким видам отказов вы готовитесь и способны пережить?
Если говорить о наших инсталляциях кластеров Cassandra, пользователи ничего не заметят, если мы потеряем несколько машин в одном ДЦ или целиком один ДЦ (такое случалось). С ростом количества ДЦ, думаем о том, чтобы начать обеспечивать работоспособность в случае сбоя двух ДЦ.
— Чего на твой взгляд не хватает Cassandra в плане отказоустойчивости?
Cassandra как и многие другие ранние NoSQL хранилища требует глубокого понимания её внутреннего устройства и происходящих динамических процессов. Я бы сказал, что ей не хватает простоты, предсказуемости и наблюдаемости. Но будет интересно услышать мнение других участников митапа!
Олег, большое спасибо что нашел время ответить на вопросы!
Мы ждем всех, кто хочет пообщаться с экспертами в области эксплуатации Apache Cassandra на митап 12 сентября в свой петербургский офис.
Приходите, будет интересно!
Комментариев нет:
Отправить комментарий