Embed Size (px)
Citation preview
Опыт перехода на
service oriented architecture
Контролируемая деградация • Лучше не показать часть информации на странице, чем 500ка • Лучше показать пользователю самое важное за 100ms, чем всё за 10s
Зачем?
Разные требования к компонентам
• Не все сервисы нужно писать под под большую нагрузку • Некоторые сервисы могут и “полежать” какое-то время • Усложняем и оптимизируем только там, где это требуется
Зачем?
Разработка на разных языках программирования
• Выбираем N языков программирования – упрощаем поиск разработчиков • Под какие то задачи подходит один ЯП, под другие другой • На разных ЯП разная скорость разработки
Зачем?
Как?
Виртуализация • Чтобы приложения не мешали друг другу, используем виртуализацию (kvm) • Легко деплоить – на одной машине только одно приложение • Из-за виртуализации получили сетевые задержки между виртуальными машиными, вылечили использованием SR-IOV
Как?
• Много разных конфигов • Усложнение деплоя • Усложнение мониторинга • Усложнение разработки • Усложнение поиска проблем: был лог приложения, стало много логов разных сервисов
• Усложнение поддержки тестовых стендов и рабочих станций разработчиков
Реальность!
request_id – уникальный идентификатор запроса.
• Генерируется на фронтендах: nginx + ngx_http_requestid_module • Пробрасывается на все сервисы http заголовком • Все записи в логах содержат request_id
Про логи
started GET /page/index/ got 200 http://192.168.1.172:8009/hh-session?args in 6.49ms got 200 http://192.168.1.172:8021/xml/article/?args in 4.81ms finish group: 10 requests pending got from memcache: KEYS, blocking time: 1.07 ms applied XSL ambient/index.xsl in 24.78ms applied postprocessor '<Fuchakubutsu>' in 12.94ms Stages for /page/index/ : session:9.47ms page:81.23ms xsl:24.78ms postprocess:13.27ms 200 GET /page/index/ (192.168.1.188) 174.31ms
Уже можно понять, как обрабатывался запрос, но логи размазаны по разным серверам.
Про логи
Сливаем логи через syslog на один сервер • искать по request_id долго
• проблемы с большими сообщениями
Про логи
Пробуем logstash, graylog2
• не справляются с нашей нагрузкой (20k messages/second), по крайней мере за вменяемое время не удалось победить
• сложно доделать под наши задачи
• у graylog2 есть отличный протокол: GELF
Про логи
GELF • UDP • JSON + GZIP • Поддержка больших сообщений (chunks) • Есть готовые библиотеки для java, python, php, perl, ruby итд • Очень простой – ничего лишнего
Про логи
Написали сервер • 2 дня разработки на python • Держит нашу нагрузку • Сообщения пробовали хранить в cassandra и mongodb: выбрали mongodb • Хранилище фиксированного размера (перезапись по кругу) • Шардинг по request_id • Быстрый поиск по request_id, можно добавить индексируемых полей • Интерфейс поиска от консольных скриптов до web • Легко расширять
Про логи
Научились собирать и искать по логам, учимся писать логи
• В логи надо писать всё, что может пригодиться • Если идём куда-то по сети: пишем зачем, куда, что ответили (статус), сколько ждали ответа
• Если делаем вычислительную задачу: пишем что делали, сколько заняло времени, ошибки
• Если ошибка: пишем во время какого запроса произошло, что в итоге (отдали 500 итд).
Про логи
Идеальное приложение с точки зрения эксплуатации
• По логу можно понять, чем сейчас занято приложение и чем оно было занято в момент времени X
• Если приложение тормозит или “плюется” ошибками: можно понять – это внешние проблемы или проблемы самого приложения разработчик по логу может понять причину такого поведения
Про логи
• Мониторить параметры серверов нужно, но это не главное
• Ключевые метрики – про сервис, а не железо
• CPU Usage = 100% проблема? Нет! Зачастую это просто вспомогательная информация
Про мониторинг
Самый информативный мониторинг – мониторинг на основе логов
• Мониторим каждый экземпляр сервиса отдельно
• Сервис в целом на основе логов балансировщика
• Отдельные страницы сайта на основе логов фронтендов (ключевые метрики)
Про мониторинг
• Нужно определить, что значит “сайт работает”, ”сайт не работает”
• Реальные проблемы: 95 персентиль времени ответа > N ms процент ошибок > M количество запросов резко упало / выросло • Алерты должны быть только по делу
• Отчеты о доступности должны быть на основе метрик сервиса
Про мониторинг
Что должна уметь система выкладки • Выложить сервис N, а только после этого сервис М • При выкладке сервиса N применить изменения в конфигах • Сервис N выкладывать параллельно по 2 экземпляра, идти дальше если оба ответят по /status 200м статусом
• Помнить предыдущие версии каждого сервиса • Откатиться на предыдущую версию • Знать конфигурацию всего кластера: где живую экземпляры сервиса N, сколько их итд
Про деплой
Как сейчас
• Скрипты на shell • Простой шаблонизатор конфигов • Деплой через ssh + scp + apt-get • Описание конфигурации кластера в текстовых файлах • Все достаточно громоздко
Про деплой
Куда идём
• Puppet для конфигов в роли репозитория (отключен autosync) • Скрипты на python + fabric (не пишем логику параллельного исполнения, не пишем обвязку для ssh, более умная проверка статусов сервисов)
• Выкладка только установкой deb пакетов • Описание конфигурации кластера берем из мониторинга (базы) – она там уже есть в самом актуальном виде
Про деплой
• Разделение монолитного приложения на сервисы может принести пользу • Отдельные подсистемы можно сохранить простыми • Система в целом усложняется, особенно в эксплуатации • Придется совершенствовать инфраструктурные инструменты для сохранения контроля над системой:
- деплой - логи - мониторинг
Итоги
Некоторые наши наработки на http://github.com/hhru
• Frontik • Logserver – очень грязный прототип (as is), лучше так чем никак =) • nginx_requestid – модуль nginx для генерации request_id
