Однокласники – найбільший користувач Apache Cassandra у Рунеті та один з найбільших у світі. Ми почали використовувати Cassandra в 2010 для зберігання оцінок фото, а зараз під управлінням Cassandra знаходяться петабайти даних на тисячах нод, більше того, ми навіть розробили свою власну .
12 вересня у своєму петербурзькому офісі ми проведемо . Основним спікером заходу стане головний інженер Однокласників Олег Анастасьєв. Олег – експерт у галузі розподілених та відмовостійких систем, він працює з 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 вересня у свій петербурзький офіс.
Приходьте, буде цікаво!
Джерело: habr.com