Архітектура Twitter

Cassandra

Статистика

  • Apache + mod_proxy
  • Unicorn
  • Ruby + Ruby on Rails
  • Scala
  • Flock
  • memcached
  • Kestrel
  • MySQL
  • Cassandra
  • Scribe
  • Hadoop, HBase та Pig

Порівняйте з аналогічним розділом попередньої статті про Twitter – побачите багато нових осіб, детальніше нижче.

Устаткування

  • Сервера розташовані в NTT America
  • Жодних хмар та віртуалізації, існуючі рішення страждають надто високими затримками
  • Більше тисячі серверів
  • Планується переїзд у власний датацентр

Що таке твіт?

Архітектура

архітектура

Сервер програм для Rails:

  • Розгортання нових версій кодубез простою
  • На 30% менша витрата обчислювальних ресурсів та оперативної пам'яті, порівняно з іншими рішеннями
  • Перейшли з mod_proxy_balancer на mod_proxy_pass

Використовується в основному для створення сторінок, робота за сценою реалізована на чистому Ruby або Scala.

Зіткнулися з такими проблемами:

  • Проблеми з кешуванням, особливо щодо інвалідності
  • ActiveRecord генерує не найвдаліші SQL-запити, що сповільнювало час відгуку
  • Високі затримки у черзі та при реплікації

  • memcached не ідеальний. Twitter почав стикатися з Segmentation Fault у ньому дуже рано.
  • Більшість стратегій кешування ґрунтуються на довгих TTL (більше хвилини).
  • Витіснення даних робить його непридатним для важливих конфігураційних даних (наприклад, прапорів "темного режиму", про який йтиметься нижче).
  • Розбивається на кілька пулів для покращення продуктивності та зниження ризикувитіснення.
  • Оптимізована бібліотека для доступу до memcached з Ruby на основі libmemcached + FNV hash замість чистого Ruby і md5.
  • Twitter є одним з найбільш активних проектів, що беруть участь у розробці libmemcached.

  • Розбиття даних через Gizzard
  • Безліч серверів MySQL як нижча система зберігання
  • У Twitter містить 13 мільярдів ребер графа та забезпечує 20 тисяч операцій запису та 100 тисяч операцій читання за секунду
  • Грані зберігаються та індексуються в обох напрямках
  • Підтримує розподілений підрахунок кількості рядків
  • Open source!

Середній час виконання операцій:

  • Підрахунок кількості рядків: 1мс
  • Тимчасові запити: 2мс
  • Запис: 1мс для журналу, 16мс для надійного запису
  • Обхід дерева: 100 граней/мс

Докладніше про еволюцію систем зберігання даних на Twitter у презентації Nick Kallen.

Розподілена система зберігання даних, орієнтована на роботу у реальному часі:

  • Спочатку розроблена у Facebook
  • Дуже висока продуктивність на запис
  • Зі слабких сторін: висока затримка при випадковому доступі
  • Децентралізована, здатна переносити збої обладнання
  • Гнучка схема даних
  • Планується повний перехід на неї за таким алгоритмом:
  • Всі твіти пишуться і в Cassandra, і в MySQL
  • Динамічно частина операцій читання перекладається Cassandra
  • Аналізується реакція системи, що зламалося
  • Повністю відключаємо читання з Cassandra, робимо несправності
  • Починаємо спочатку
  • Оновлення: стратегія щодо використання Cassandra змінилася, спроби використовувати її в ролі основного сховищадля твітів припинилися, але вона продовжує використовуватися для аналітики та географічної інформації.

    • Докладніше чому Twitter прийшов до рішення використовувати Cassandra можна прочитати в окремій презентації.

    Крім іншого Cassandra планується використовувати використовується для аналітики в реальному часі.

    Користувачі Twitter генерують величезну кількість даних, близько 15-25 Гб на хвилину, більше 12 Тб на день, і ця цифра подвоюється кілька разів на рік.

    Спочатку для збору логів використовували Syslog-ng, але він дуже швидко перестав справлятися з навантаженням.

    Працює локально, надійний навіть у разі втрати мережного з'єднання, кожен вузол знає тільки на який сервер передавати логи, що дозволяє створювати масштабовану ієрархію для збирання логів.

    Підтримуються різні системи для запису даних, у тому числі звичайні файли і HDFS (про неї нижче).

    Як Ви зазвичай зберігаєте 12Тб нових даних, що надходять щодня?

    Якщо вважати, що середня швидкість запису сучасного жорсткого диска становить 80Мбайт на секунду, запис 12Тб даних зайняв би майже 48 годин.

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

    Використання кластерної файлової системи додає складності, але дозволяє менше піклуватися про деталі.

    Hadoop Distributed File System (HDFS) надає можливість автоматичної реплікації та допомагає справлятися зі збоями обладнання.

    MapReduce framework дозволяє обробляти величезні обсяги даних, аналізуючи пари ключ-значення.

    Типові обчислювальні завдання, які вирішуються за допомогою Hadoop у Twitter:

    Для того, щоб аналізувати даніза допомогою MapReduce зазвичай необхідно розробляти код на Java, що далеко не всі вміють робити, та й трудомістко це.

    Pig є високорівневою мовою, що дозволяє трансформувати величезні набори даних крок за кроком.

    Дещо нагадує SQL, але набагато простіше. Це дозволяє писати в 20 разів менше коду, ніж під час аналізу даних за допомогою звичайних MapReduce робіт. Більшість роботи з аналізу даних у Twitter здійснюється за допомогою Pig.

    • логі Apache, RoR, MySQL, A/B тестування, процесу реєстрації
    • пошукові запити

    Що вони роблять із цим усім?

    • Підрахунок математичного очікування, мінімуму, максимуму та дисперсії наступних показників:
    • Кількість запитів за добу
    • Середня затримка, 95% затримка
    • Розподіл кодів HTTP-відповідей (по годинах)
    • Кількість пошуків здійснюється щодня
    • Кількість унікальних запитів та користувачів
    • Географічний розподіл запитів та користувачів
  • Підрахунок ймовірності, підступності, впливу:
  • Як відрізняється використання мобільних пристроїв?
  • Як впливає використання клієнтів сторонніх розробників?
  • Когортний аналіз
  • Проблеми з сайтом (кити та роботи, докладніше нижче)
  • Які функціональні можливості чіпляють користувачів?
  • Які функціональні можливості найчастіше використовуються популярними користувачами?
  • Коригування та пропозиція пошукових запитів
  • A/B тестування
  • Пророцтва, аналіз графів, природні мови:
  • Аналіз користувачів за їх твітами, твітами, на які вони підписані, твітами їх фоловерів
  • Яка структура графа веде до успішних популярних мереж
  • Репутація користувача
  • Аналіз емоційного забарвлення
  • Які особливості змушують людей витвітнути твіт?
  • Що впливає на глибину дерева ретвітів?
  • Довгострокове виявлення дублікатів
  • Машинне навчання
  • Виявлення мови

    • Докладніше про обробку даних у презентації Kevin Weil.

    Twitter починають будувати справжні сервіси на основі Hadoop, наприклад пошук людей:

    • HBase використовується як змінний прошарок над HDFS
    • Дані експортуються з HBase за допомогою періодичної роботи MapReduce:
    • На етапі Map використовуються також дані з FlockDB та кількох внутрішніх сервісів
    • Власна схема розбиття даних
    • Дані підтягуються через високопродуктивний, горизонтально масштабований сервіс на Scala (докладніше про побудову розподілених сервісів на Scala)

    На основі HBase розробляються інші продукти всередині Twitter.

    Основними її перевагами є гнучкість та легка інтеграція з Hadoop та Pig.

    Порівняно з Cassandra:

    • "Їхнє походження пояснює їх сильні та слабкі сторони"
    • HBase побудований на основі системи пакетної обробки даних, високі затримки, працює далеко не в реальному часі
    • Cassandra побудована з нуля для роботи з низькими затримками
    • HBase легко використовувати при аналізі даних як джерело або місце збереження результатів, Cassandra для цього підходить менше, але вони працюють над цим
    • HBase зараз єдину точку відмови у вигляді майстер-вузла
    • У твіттері HBase використовується для аналітики, аналізу та створення наборів даних, а Cassandra – для онлайн систем

    Централізована система керування обладнанням.

    Реалізованоз використанням:

    Інтегрована з LDAP, аналізує вхідну пошту від датацентру та автоматично вносить зміни до бази.

    Система розгортання коду та ПЗ, заснована на протоколі BitTorrent.

    Завдяки своїй P2P природі дозволяє оновити понад тисячу серверів за 30-60 секунд.

    Розподілена черга, що працює за протоколом memcache:

    • set - поставити у чергу
    • get - взяти з черги

    • Відсутність суворого порядку виконання завдань
    • Відсутність загального стану між серверами
    • Розроблено на Scala

    Кожен твіт обробляється за допомогою daemon'ів.

    У unicorn обробляються тільки HTTP запити, вся робота за сценою реалізована у вигляді окремих daemon'ів.

    Раніше використовувалося багато різних демонів, по одному на кожне завдання (Rails), але перейшли до меншої кількості, здатної вирішувати кілька завдань одночасно.

    Як вони впораються з такими темпами зростання?

    Рецепт простий, але ефективний, підходить практично для будь-якого інтернет-проекту:

    • виявити найслабше місце у системі;
    • вжити заходів щодо його усунення;
    • перейти до наступного найслабшого місця.

    На словах звучить і справді примітивно, але на практиці потрібно вжити низку заходів, щоб такий підхід був би реалізований:

    • Автоматичний збір метрик (причому в агрегованому вигляді)
    • Побудова графіків (RRD, Ganglia)
    • Збір та аналіз логів
    • Всі дані повинні виходити з мінімальною затримкою, якомога ближче до реального часу
    • Аналіз:
    • З даних необхідно отримувати інформацію
    • Слідкувати за динамікою показників: стало краще чи гірше?
    • Особливо при розгортанні новихверсій коду
    • Планування використання ресурсів набагато простіше, ніж вирішення екстрених ситуацій, коли вони закінчуються

    Прикладами агрегованих метрик у Twitter є "кити" та "роботи", вірніше їх кількість в одиницю часу.

    Що таке "робот"?

    архітектура

    • Помилка всередині Rails (HTTP 500)
    • Неспійманий виняток
    • Проблема в коді або нульовий результат

    Що таке "кит"?

    архітектура

    • HTTP помилка 502 чи 503
    • У твіттер використовується фіксований тайм-аут в 5 секунд (краще комусь показати помилку, ніж захлинутися в запитах)
    • Вбитий надто довгий запит до бази даних (mkill)

    Значне перевищення нормальної кількості китів або роботів за хвилину є приводом для занепокоєння.

    Реалізовано цей механізм простим bash-скриптом, який переглядає агреговані логи за останні 60 секунд, підраховує кількість китів/роботів і розсилає повідомлення, якщо значення виявилося вищим за порогове значення. Докладніше про роботу команди оперативного реагування у презентації John Adams.

    "Темний режим"

    Є близько 60 вимикачів, у тому числі повний режим "тільки для читання".

    Усі зміни в налаштуваннях цього режиму фіксуються в логах і повідомляються посібнику, щоб ніхто не балувався.

    Підбиваємо підсумки

    • Не кидайте систему на самоплив, починайте збирати метрики та їх візуалізувати якомога раніше
    • Заздалегідь плануйте зростання необхідних ресурсів та свої дії у разі екстрених ситуацій
    • Кешуйте по максимуму все, що можливо
    • Всі інженерні рішення не вічні, жодне з рішень не ідеальне, але багато хто нормально працюватиме протягом якогось періоду часу
    • Заздалегідь починайте замислюватися про план масштабування
    • Не покладайтеся повністю на memcached і базу даних - вони можуть Вас підвести в самий невідповідний момент
    • Всі дані для запитів у реальному часі повинні бути в пам'яті, диски в основному для запису
    • Вбивайте повільні запити (mkill), перш ніж вони вб'ють всю систему
    • Деякі завдання можуть вирішуватися шляхом попереднього підрахунку та аналізу, але далеко не всі
    • Наближайте обчислення до даних якомога
    • Використовуйте не mongrel, а unicorn для RoR

    Дякую за увагу, чекаю на Вас знову! Радий, якщо Ви підпишетесь на мене в Twitter, із задоволенням поспілкуюся з усіма читачами :)