20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения (Redis, RabbitMQ, Skytools, Node.JS, HBase)", Александр Чистяков

Демоны в большом проекте –
проблемы и их решения
Александр Чистяков
Младший системный администратор Cezurity
admin@cezurity.com
2013 dev.it-portfolio.net

Кто я?
• Топ-менеджер РАО ЕЭС
• Муж певицы Глюк’оZa
• Подрабатываю в компании Cezurity
системным администратором
dev.it-portfolio.net 2

Кто вы?
• 91.89% - Windows users
• 6.94% - OS X users
• 1.17% - Linux users
• Вы слышали про компьютерные вирусы?
• Если не слышали, вирус – это такая
программа для устаревших операционных
систем, несанкционированно
модифицирующая их работу

Отказ от ответственности
• Верите презентациям на слово?
картинка №1 (очень важная)

Чем занимается Cezurity?
• Создание облачного антивируса
• Целевая аудитория – те самые 91.89%
• Как мы уже выяснили, Windows в зале ни у
кого нет, поэтому речь пойдет не об
антивирусе, а о
• ВЫСОКИХ НАГРУЗКАХ

Что такое высокие нагрузки?
• Как установили ученые (британские), еще
викинги занимались созданием
высоконагруженных сайтов, они просто не
знали, что это – высоконагруженные сайты
• Высокие нагрузки – это когда вам
позвонили среди ночи, сообщить о том, что
все упало
• Где нагрузка выше: VK или Одоклассники?

Как викинги делали сайты?
• Методология “Фигак-фигак и в продакшн”
• У веб проекта должна быть архитектура!
• Со времен викингов проще жить не стало

А что такое архитектура?
• Веб-проект состоит из квадратиков
• Квадратики можно найти в сети и скачать!
• Если скачивать все найденные в сети
квадратики, к окончанию проекта успеете
• Многообразие квадратиков порождает
комбинаторный взрыв, следовательно
• Нужно знать, какие квадратики скачать!

Откуда мы знаем, что скачивать?
• “Берите тот дистрибутив Linux, который
стоит у вашего районного Linux-гуру”
• “Никто не был уволен за покупку Cisco”
• “Вся бытовая техника в доме должна быть
одного производителя”
• …и тому подобная чушь

Откуда мы знаем, что скачивать?
• А мы не знаем
• Некоторые квадратики попадают в проект,
потому что у команды есть предыдущий
опыт с ними (или языком/платформой)
• Некоторые квадратики попадают в проект
после сравнения свойств нескольких
кандидатов и выбора наиболее
подходящего

Архитектура типичного веб-проекта
• Сервер приложений (неинтересно)
• Reverse-proxy (тривиально)
• СУБД (товарищеский матч MySQL vs
PostgreSQL на стульях и швабрах в
перерыве)
• ORM (расшифровывается как “я не знаю
SQL”)
• Кэш

Архитектура нетипичного веб-проекта
• СУБД? (schemaless document-oriented fast
scalable fault-tolerant near-realtime web2.0-
ready modern not-only-SQL storage)
• Очереди
• Шардинг
• BigData
– Аналитика

Итого, что нам было нужно
• СУБД?! (SQL or NoSQL? SQL and NoSQL? SQL
xor NoSQL?)
• Очереди
• Шардинг
• Кэш
• BigData

Техническая археология
• Проекту больше года, ключевые сервисы
уже на своих местах
• Попытка осмыслить пути выбора
составляющих архитектуры и оценить
достоинства и недостатки

SQL and NoSQL
• Необходимость не только писать данные в
базу, но еще и гарантированно читать их
обратно => старый добрый SQL
• Необходимость не просто читать данные,
но делать это быстро => рассмотрение
современных NoSQL решений
• Необходимость хранить данных больше,
чем влезает на один сервер (и на 2, и на 3)

Очереди
• Варианты:
– ActiveMQ (мир делится на Java-программистов
и не Java-программистов, среднего нет)
– RabbitMQ (5 баллов за маркетинг)
– ZeroMQ (не сервис, а библиотека)
– Kestrel (слова “a port of Starling from Ruby to
Scala” звучат как приговор)
– Beanstalkd (кто-нибудь в зале слышал?)
• Выбор пал на RabbitMQ

Впечатления Java-программиста
• Попытка прочесть и понять спецификацию
AMQP вызывает судороги
• Ни одна клиентская библиотека толком не
реализует поддержку AMQP keepalive
• Большая часть клиентских библиотек
похожа на студенческие курсовые
• Erlang – очень простой язык
• RabbitMQ чаще работает, чем не работает

Проблемы
• Написан на Erlang – надо знать Erlang
• Можно попробовать не знать Erlang, но
тогда конфигурация и эксплуатация
RabbitMQ будет вызывать неприятие
• Не можете понять Erlang – картинка №1!
• Очереди в памяти – при падении данные
теряются
• Памяти не хватает – все встает

Кто сказал «персистирование»?
• У нас уже есть PgQ (SkyTools)
• PgQ – это очереди поверх PostgreSQL
• Они работают хорошо
• Но дисковая подсистема на машинах, где
они развернуты, начинает работать плохо
• В RabbitMQ - диск лучше? Картинка №1!
• Большая часть наших сообщений живут
миллисекунды – зачем их персистировать?

Шардинг
• PL/Proxy – проект, позволяющий
организовать шардинг с использованием
хранимых процедур на PL
• (Как вы уже, наверное, догадались, мы
используем PostgreSQL)

Впечатления Java-программиста
• Хранимые процедуры это древнее зло
– Их сложно читать и понимать
– Их сложно отлаживать
– Сложно анализировать slow query log, так как
там не запросы, а вызовы хранимок
• К счастью, шардинг с помощью PL/Proxy
(пока) работает как часы
• (Кстати, PL/Proxy используется в Skype)

Кэш
– memcached (в названии есть слово “cache”)
– Redis (в названии нет слова “cache”)
– MongoDB (“MongoDB is web scale!”)
– Membase/Couchbase (в названии все время
разные слова, И ЭТО НЕСПРОСТА, все мои
попытки внедрить Membase заканчивались
срочной эвакуацией с него)

Memcached
• Очевидный выбор
• С точки зрения топ-менеджера РАО ЕЭС
представляет собой slab allocator с lock-free
структурами данных, MVCC и evented I/O
• Просто работает, причем, у многих
• Не поддерживает объединение ключей в
множества (тегирование ключей, списки)

Redis
• Второй очевидный выбор
• Поддерживает списки
• Может работать как кэш, а может – как БД
• По умолчанию сохраняет данные на диск

MongoDB
• Судя по деталям реализации, была
написана викингами
• У нас отсутствует достаточный запас боевых
мухоморов, чтобы пытаться внедрить
продукт, технические решения в котором
долгое время противоречили здравому
смыслу (no WAL, global lock, random crashes
и другие атрибуты web2.0-ready решения)

Неочевидный вариант
• MySQL + HandlerSocket
• Не рассматривался никем, кроме меня –
все-таки, у антивирусной компании потоки
данных совсем не такие, как у типичного
веб-проекта
• Поэтому писать на диск данные из кэша
нам не надо – «горячие» данные все время
разные

Итак, Redis
• Сначала мы пытались использовать его еще
и как базу (без вытеснения)
• Два типа данных – с установленным
expiration date и персистентные
• Когда место в памяти заканчивается, Redis
перестает записывать данные
• Почему заканчивается место в памяти?
• Redis ведет slow log (у нас до 400-600 Mb)

Redis – итоговые настройки
• Вытеснять все без разбора:
– maxmemory-policy allkeys-lru
• Ничего не сохранять на диск: #save
• (Кстати, Redis долго читает состояние с
диска при рестартах, если оно есть)
• Если сохранение на диск было отключено
не сразу, надо стереть дамп
• slowlog-log-slower-than -10000

Redis – после внедрения
• Мы не используем репликацию (нет смысла
в силу особенности бизнеса)
• Мы храним данные в разных базах одного
инстанса и в нескольких разных инстансах
• Активно используем списки
• Мы не сразу нашли, куда расходуется
память, и даже хотели ее профайлить
• В целом, мы довольны

BigData
• Антивирусная компания – это очень много
данных, даже когда клиентов мало
• Данные нужно не только записать, но и
прочитать
• И не только прочитать, но и обработать
• Например, если в файле обнаружен новый
вирус, нужно сообщить всем клиентам, у
которых был такой файл

BigData
• Нельзя просто взять, и сложить все на одну
машину
– RIAK, Cassandra, MongoDB, ТЫСЯЧИ ИХ
(eventually consistent == eventually inconsistent)
– HBase (strongly consistent)
– Vertica (стоит денег)
– Greenplum (стоит денег)

HBase - развертывание
• Раньше я ничего не говорил про это, так как
развертывание Redis, RabbitMQ,
memcached, etc - тривиально
• HBase развернуть тоже несложно – сначала
нужен ZooKeeper cluster
• Стойте, как я сказал, «несложно»?
• 5 сервисов на мастер-ноде, по 3 на слейвах
• 8 кукбуков в Chef

Стоп, а что это все-таки, HBase?
• Это такое key-value хранилище
• В котором ключи сохраняют отношение
порядка
• Потому что используется LSM tree
• Позволяет извлекать данные не только по
конкретным ключам, но и делать range
scans
• На уровне отдельной строки - атомарность

HBase – эксплуатация
• Ручки у HBase везде, и крутить их можно в
разные стороны
• Мы пока начинаем, и настраивали только
region size и max KeyValue size в сторону
увеличения
• Клиенты у нас на Python, работают через
Thrift
• Thrift-сервер требует больше памяти, чем
мог бы (Java-программист во мне смеется)

Из чего состоит HBase?
• ZooKeeper – координатор
• HDFS – распределенная файловая система
• Сервисы самого HBase поверх HDFS
• Сломаться может везде:
– ZooKeeper может потерять кворум из-за
задержек ответа нод
– Файловая система может потребовать
проверки
– master node может умереть

Как обеспечивать устойчивость?
• Подстроить сетевые таймауты
• Поставить рядом второй кластер и делать
репликацию данных на него
• Либо быть готовым к проверке файловой
системы в ручном автоматическом режиме
• Дублировать master node

Так в ручном или не в ручном?
• А что может сломаться на файловой
системе, когда вышестоящие сервисы
обеспечивают strong consistency?
• Write-ahead logs
• Что-то потеряли в WALs?
– Картинка №1!
• Автоматическая проверка – хорошо, но
может быть долго

Перспективный план
• Научиться ломать HBase
• Научиться чинить HBase
• Научиться редко ломать HBase
• Научиться быстро чинить HBase
• ????????
• В октябре прочитать про это большой
доклад

В анонсе было про Node.JS
• Каково назначение Node.JS в
инфраструктуре?
• Генерировать непонятные эксепшны вида
[2013-04-19 22:21:41.987] [FATAL] daemon - !! Unhandled exception !! TypeError: Object [object Object] has no method 'destroy'
at onclose (stream.js:74:10)
at EventEmitter.emit (events.js:115:20)
at RequestStream.destroy (/opt/node-server/lib/http_server.js:220:7)
at IncomingMessage.onclose (stream.js:74:10)
at IncomingMessage.EventEmitter.emit (events.js:115:20)
at abortIncoming (http.js:1649:11)
at CleartextStream.serverSocketCloseListener (http.js:1659:5)
at CleartextStream.EventEmitter.emit (events.js:115:20)
at SecurePair.destroy (tls.js:907:22)
at process.startup.processNextTick.process._tickCallback (node.js:244:9)

Лист ненависти
• Прочь с моего облака! (с) The Rolling Stones
• Node.JS есть? А если найду?
• Крокфорда читали?
• Node.JS был выбран, «потому что он
быстрый»
• Анекдот про скорость печати в 400
символов в минуту
• Use statically typed languages, Luke!

Выводы
• Абсолютное большинство проблем – не в
софте, а в голове
• Надо только вовремя понять, в чьей (в
своей, или в голове разработчика сервиса)
• Если вы берете в проект сервис, вам
придется на нем жениться быть готовым
поддерживать его код
• Очень важно помнить про картинку №1

Пора закругляться
• Если погода хорошая – поблагодарить
• Если погода плохая – извиниться за то, что
пришлось ее испортить
• Вопросы?
• Голосуйте за меня на http://devconf.ru/offers
• http://twitter.com/noatbaksap
• http://github.com/alexclear

20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения (Redis, RabbitMQ, Skytools, Node.JS, HBase)", Александр Чистяков

More Related Content

What's hot (20)

Viewers also liked (6)

Similar to 20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения (Redis, RabbitMQ, Skytools, Node.JS, HBase)", Александр Чистяков (20)

More from IT-Portfolio (11)

20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения (Redis, RabbitMQ, Skytools, Node.JS, HBase)", Александр Чистяков