20 апреля, DEV {highload} - конференция о Highload веб-разработке, "Демоны в большом проекте – проблемы и их решения (Redis, RabbitMQ, Skytools, Node.JS, HBase)", Александр Чистяков (ведущий разработчик Cezurity)
Аннотация
Когда команда разработчиков собирается написать новый сервис, у нее, как правило, отсутствует свободное время, но есть необходимый энтузиазм. Из-за нехватки времени многие архитектурные решения приходится принимать, руководствуясь общими соображениями, так как провести всесторонние тесты имеющихся на рынке средств в краткие сроки невозможно. Мы, специалисты компании Cezurity, начали свой проект не вчера, и уже накопили некоторый опыт использования технологий, появившихся сравнительно недавно - таких как Skytools, Node.JS, RabbitMQ и Redis. О том, какие возникли проблемы при внедрении этих средств, и какие их ограничения пришлось преодолевать и учитывать - мой доклад. Кроме того, я расскажу о новом направлении в нашей деятельности - внедрении HBase для хранения большого объема данных.
Биография
Докладчик - узкий специалист широкого профиля, относит себя к виду, называемому в современной англоязычной литературе термином "DevOps". Любит принимать участие в создании сложных систем и постоянно это делает. Никогда не работал в Яндексе, компенсировав это работой в Mail.Ru и некоторых других местах.
Очереди и блокировки. Теория и практика / Александр Календарев (ad1.ru)
Similaire à 20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения (Redis, RabbitMQ, Skytools, Node.JS, HBase)", Александр Чистяков
Top-10 популярных вопросов администраторам баз данных или почему я против св...Ilya Kosmodemiansky
Similaire à 20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения (Redis, RabbitMQ, Skytools, Node.JS, HBase)", Александр Чистяков (20)
13 октября, DEV {web} - конференция о Highload веб-разработке. "Архитектура п...
20 апреля, DEV {highload}, "Демоны в большом проекте – проблемы и их решения (Redis, RabbitMQ, Skytools, Node.JS, HBase)", Александр Чистяков
1. Демоны в большом проекте –
проблемы и их решения
Александр Чистяков
Младший системный администратор Cezurity
admin@cezurity.com
2013 dev.it-portfolio.net
2. Кто я?
• Топ-менеджер РАО ЕЭС
• Муж певицы Глюк’оZa
• Подрабатываю в компании Cezurity
системным администратором
dev.it-portfolio.net 2
3. Кто вы?
• 91.89% - Windows users
• 6.94% - OS X users
• 1.17% - Linux users
• Вы слышали про компьютерные вирусы?
• Если не слышали, вирус – это такая
программа для устаревших операционных
систем, несанкционированно
модифицирующая их работу
dev.it-portfolio.net 3
4. Отказ от ответственности
• Верите презентациям на слово?
картинка №1 (очень важная)
dev.it-portfolio.net 4
5. Чем занимается Cezurity?
• Создание облачного антивируса
• Целевая аудитория – те самые 91.89%
• Как мы уже выяснили, Windows в зале ни у
кого нет, поэтому речь пойдет не об
антивирусе, а о
• ВЫСОКИХ НАГРУЗКАХ
dev.it-portfolio.net 5
6. Что такое высокие нагрузки?
• Как установили ученые (британские), еще
викинги занимались созданием
высоконагруженных сайтов, они просто не
знали, что это – высоконагруженные сайты
• Высокие нагрузки – это когда вам
позвонили среди ночи, сообщить о том, что
все упало
• Где нагрузка выше: VK или Одоклассники?
dev.it-portfolio.net 6
7. Как викинги делали сайты?
• Методология “Фигак-фигак и в продакшн”
• У веб проекта должна быть архитектура!
• Со времен викингов проще жить не стало
dev.it-portfolio.net 7
8. А что такое архитектура?
• Веб-проект состоит из квадратиков
• Квадратики можно найти в сети и скачать!
• Если скачивать все найденные в сети
квадратики, к окончанию проекта успеете
• Многообразие квадратиков порождает
комбинаторный взрыв, следовательно
• Нужно знать, какие квадратики скачать!
dev.it-portfolio.net 8
9. Откуда мы знаем, что скачивать?
• “Берите тот дистрибутив Linux, который
стоит у вашего районного Linux-гуру”
• “Никто не был уволен за покупку Cisco”
• “Вся бытовая техника в доме должна быть
одного производителя”
• …и тому подобная чушь
dev.it-portfolio.net 9
10. Откуда мы знаем, что скачивать?
• А мы не знаем
• Некоторые квадратики попадают в проект,
потому что у команды есть предыдущий
опыт с ними (или языком/платформой)
• Некоторые квадратики попадают в проект
после сравнения свойств нескольких
кандидатов и выбора наиболее
подходящего
dev.it-portfolio.net 10
11. Архитектура типичного веб-проекта
• Сервер приложений (неинтересно)
• Reverse-proxy (тривиально)
• СУБД (товарищеский матч MySQL vs
PostgreSQL на стульях и швабрах в
перерыве)
• ORM (расшифровывается как “я не знаю
SQL”)
• Кэш
dev.it-portfolio.net 11
13. Итого, что нам было нужно
• СУБД?! (SQL or NoSQL? SQL and NoSQL? SQL
xor NoSQL?)
• Очереди
• Шардинг
• Кэш
• BigData
dev.it-portfolio.net 13
14. Техническая археология
• Проекту больше года, ключевые сервисы
уже на своих местах
• Попытка осмыслить пути выбора
составляющих архитектуры и оценить
достоинства и недостатки
dev.it-portfolio.net 14
15. SQL and NoSQL
• Необходимость не только писать данные в
базу, но еще и гарантированно читать их
обратно => старый добрый SQL
• Необходимость не просто читать данные,
но делать это быстро => рассмотрение
современных NoSQL решений
• Необходимость хранить данных больше,
чем влезает на один сервер (и на 2, и на 3)
dev.it-portfolio.net 15
16. Очереди
• Варианты:
– ActiveMQ (мир делится на Java-программистов
и не Java-программистов, среднего нет)
– RabbitMQ (5 баллов за маркетинг)
– ZeroMQ (не сервис, а библиотека)
– Kestrel (слова “a port of Starling from Ruby to
Scala” звучат как приговор)
– Beanstalkd (кто-нибудь в зале слышал?)
• Выбор пал на RabbitMQ
dev.it-portfolio.net 16
17. Впечатления Java-программиста
• Попытка прочесть и понять спецификацию
AMQP вызывает судороги
• Ни одна клиентская библиотека толком не
реализует поддержку AMQP keepalive
• Большая часть клиентских библиотек
похожа на студенческие курсовые
• Erlang – очень простой язык
• RabbitMQ чаще работает, чем не работает
dev.it-portfolio.net 17
18. Проблемы
• Написан на Erlang – надо знать Erlang
• Можно попробовать не знать Erlang, но
тогда конфигурация и эксплуатация
RabbitMQ будет вызывать неприятие
• Не можете понять Erlang – картинка №1!
• Очереди в памяти – при падении данные
теряются
• Памяти не хватает – все встает
dev.it-portfolio.net 18
19. Кто сказал «персистирование»?
• У нас уже есть PgQ (SkyTools)
• PgQ – это очереди поверх PostgreSQL
• Они работают хорошо
• Но дисковая подсистема на машинах, где
они развернуты, начинает работать плохо
• В RabbitMQ - диск лучше? Картинка №1!
• Большая часть наших сообщений живут
миллисекунды – зачем их персистировать?
dev.it-portfolio.net 19
20. Шардинг
• PL/Proxy – проект, позволяющий
организовать шардинг с использованием
хранимых процедур на PL
• (Как вы уже, наверное, догадались, мы
используем PostgreSQL)
dev.it-portfolio.net 20
21. Впечатления Java-программиста
• Хранимые процедуры это древнее зло
– Их сложно читать и понимать
– Их сложно отлаживать
– Сложно анализировать slow query log, так как
там не запросы, а вызовы хранимок
• К счастью, шардинг с помощью PL/Proxy
(пока) работает как часы
• (Кстати, PL/Proxy используется в Skype)
dev.it-portfolio.net 21
22. Кэш
• Варианты:
– memcached (в названии есть слово “cache”)
– Redis (в названии нет слова “cache”)
– MongoDB (“MongoDB is web scale!”)
– Membase/Couchbase (в названии все время
разные слова, И ЭТО НЕСПРОСТА, все мои
попытки внедрить Membase заканчивались
срочной эвакуацией с него)
dev.it-portfolio.net 22
23. Memcached
• Очевидный выбор
• С точки зрения топ-менеджера РАО ЕЭС
представляет собой slab allocator с lock-free
структурами данных, MVCC и evented I/O
• Просто работает, причем, у многих
• Не поддерживает объединение ключей в
множества (тегирование ключей, списки)
dev.it-portfolio.net 23
24. Redis
• Второй очевидный выбор
• Поддерживает списки
• Может работать как кэш, а может – как БД
• По умолчанию сохраняет данные на диск
dev.it-portfolio.net 24
25. MongoDB
• Судя по деталям реализации, была
написана викингами
• У нас отсутствует достаточный запас боевых
мухоморов, чтобы пытаться внедрить
продукт, технические решения в котором
долгое время противоречили здравому
смыслу (no WAL, global lock, random crashes
и другие атрибуты web2.0-ready решения)
dev.it-portfolio.net 25
26. Неочевидный вариант
• MySQL + HandlerSocket
• Не рассматривался никем, кроме меня –
все-таки, у антивирусной компании потоки
данных совсем не такие, как у типичного
веб-проекта
• Поэтому писать на диск данные из кэша
нам не надо – «горячие» данные все время
разные
dev.it-portfolio.net 26
27. Итак, Redis
• Сначала мы пытались использовать его еще
и как базу (без вытеснения)
• Два типа данных – с установленным
expiration date и персистентные
• Когда место в памяти заканчивается, Redis
перестает записывать данные
• Почему заканчивается место в памяти?
• Redis ведет slow log (у нас до 400-600 Mb)
dev.it-portfolio.net 27
28. Redis – итоговые настройки
• Вытеснять все без разбора:
– maxmemory-policy allkeys-lru
• Ничего не сохранять на диск: #save
• (Кстати, Redis долго читает состояние с
диска при рестартах, если оно есть)
• Если сохранение на диск было отключено
не сразу, надо стереть дамп
• slowlog-log-slower-than -10000
dev.it-portfolio.net 28
29. Redis – после внедрения
• Мы не используем репликацию (нет смысла
в силу особенности бизнеса)
• Мы храним данные в разных базах одного
инстанса и в нескольких разных инстансах
• Активно используем списки
• Мы не сразу нашли, куда расходуется
память, и даже хотели ее профайлить
• В целом, мы довольны
dev.it-portfolio.net 29
30. BigData
• Антивирусная компания – это очень много
данных, даже когда клиентов мало
• Данные нужно не только записать, но и
прочитать
• И не только прочитать, но и обработать
• Например, если в файле обнаружен новый
вирус, нужно сообщить всем клиентам, у
которых был такой файл
dev.it-portfolio.net 30
31. BigData
• Нельзя просто взять, и сложить все на одну
машину
• Варианты:
– RIAK, Cassandra, MongoDB, ТЫСЯЧИ ИХ
(eventually consistent == eventually inconsistent)
– HBase (strongly consistent)
– Vertica (стоит денег)
– Greenplum (стоит денег)
dev.it-portfolio.net 31
32. HBase - развертывание
• Раньше я ничего не говорил про это, так как
развертывание Redis, RabbitMQ,
memcached, etc - тривиально
• HBase развернуть тоже несложно – сначала
нужен ZooKeeper cluster
• Стойте, как я сказал, «несложно»?
• 5 сервисов на мастер-ноде, по 3 на слейвах
• 8 кукбуков в Chef
dev.it-portfolio.net 32
33. Стоп, а что это все-таки, HBase?
• Это такое key-value хранилище
• В котором ключи сохраняют отношение
порядка
• Потому что используется LSM tree
• Позволяет извлекать данные не только по
конкретным ключам, но и делать range
scans
• На уровне отдельной строки - атомарность
dev.it-portfolio.net 33
34. HBase – эксплуатация
• Ручки у HBase везде, и крутить их можно в
разные стороны
• Мы пока начинаем, и настраивали только
region size и max KeyValue size в сторону
увеличения
• Клиенты у нас на Python, работают через
Thrift
• Thrift-сервер требует больше памяти, чем
мог бы (Java-программист во мне смеется)
dev.it-portfolio.net 34
35. Из чего состоит HBase?
• ZooKeeper – координатор
• HDFS – распределенная файловая система
• Сервисы самого HBase поверх HDFS
• Сломаться может везде:
– ZooKeeper может потерять кворум из-за
задержек ответа нод
– Файловая система может потребовать
проверки
– master node может умереть
dev.it-portfolio.net 35
36. Как обеспечивать устойчивость?
• Подстроить сетевые таймауты
• Поставить рядом второй кластер и делать
репликацию данных на него
• Либо быть готовым к проверке файловой
системы в ручном автоматическом режиме
• Дублировать master node
dev.it-portfolio.net 36
37. Так в ручном или не в ручном?
• А что может сломаться на файловой
системе, когда вышестоящие сервисы
обеспечивают strong consistency?
• Write-ahead logs
• Что-то потеряли в WALs?
– Картинка №1!
• Автоматическая проверка – хорошо, но
может быть долго
dev.it-portfolio.net 37
38. Перспективный план
• Научиться ломать HBase
• Научиться чинить HBase
• Научиться редко ломать HBase
• Научиться быстро чинить HBase
• ????????
• В октябре прочитать про это большой
доклад
dev.it-portfolio.net 38
39. В анонсе было про 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)
dev.it-portfolio.net 39
40. Лист ненависти
• Прочь с моего облака! (с) The Rolling Stones
• Node.JS есть? А если найду?
• Крокфорда читали?
• Node.JS был выбран, «потому что он
быстрый»
• Анекдот про скорость печати в 400
символов в минуту
• Use statically typed languages, Luke!
dev.it-portfolio.net 40
41. Выводы
• Абсолютное большинство проблем – не в
софте, а в голове
• Надо только вовремя понять, в чьей (в
своей, или в голове разработчика сервиса)
• Если вы берете в проект сервис, вам
придется на нем жениться быть готовым
поддерживать его код
• Очень важно помнить про картинку №1
dev.it-portfolio.net 41
42. Пора закругляться
• Если погода хорошая – поблагодарить
• Если погода плохая – извиниться за то, что
пришлось ее испортить
• Вопросы?
• Голосуйте за меня на http://devconf.ru/offers
• http://twitter.com/noatbaksap
• http://github.com/alexclear
dev.it-portfolio.net 42