daemons in web on #devrus

Демоны в большом проекте – проблемы и их решения

Александр ЧистяковМладший системный администратор Cezurity

[email protected]

2013 dev.it-portfolio.net

dev.it-portfolio.net 2

Кто я?

• Топ-менеджер РАО ЕЭС• Муж певицы Глюк’оZa• Подрабатываю в компании Cezurity

системным администратором


Кто вы?

• 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

http://devconf.ru/offers

http://twitter.com/noatbaksap

http://github.com/alexclear

daemons in web on #devrus

Technology