Максим Лапшин. Erlang production
0 likes•1,708 views
Документ описывает опыт использования Erlang в продакшне, подчеркивая его преимущества для создания высоконагруженных видеостриминговых серверов. Указывается на важность коммерческого применения для развития технологий и опыта команды, а также на проблемы, возникающие при поддержке старого кода. В документе также рассматриваются методы мониторинга, выявления и устранения багов, что критично для эксплуатации ПО на живых системах.
Максим Лапшин. Erlang production
- 1. Erlang в настоящем продакшне Максим Лапшин Эрливидео [email protected]
- 2. Пишем про ФП, но пишем не на ФП?
- 3. • Бизнесу нужен продукт, а не софт • Программистам интересно писать софт • Нет опыта в продакшне, значит небезопасно делать продукт на таком софте • Бизнес избегает ФП • Без коммерческого применения нет опыта • Замкнутый цикл
- 4. Опасения бизнеса в непредсказуемости технологии
- 5. Эрланг годится для коммерческой разработки!
- 6. Эрливидео • Высоконагруженный видеостриминговый сервер (10 ГБит/с без проблем) • 5 лет разработки и успешной продажи ПО • Беспроблемный найм людей • Очень мало критичных багов (и те в C) • Крайне быстрая разработка • Без эрланга мы бы не справились!
- 7. Эрланг в продакшне • Надежно • Дешево • Предсказуемо • Имеет смысл использовать для коммерческого софта
- 8. Продакшн познается через год • Софт дорастает до использования живыми пользователями • Начинается поддержка старого кода • Приходят новые программисты, перед которыми стыдно за исходники • Пользователи создают нагрузку
- 9. Проблемы эксплуатации • Работа со своим и чужим кодом • Работа с багами на недевелоперских серверах • Поведение под нагрузкой
- 10. Поддержка старого кода • Через год даже свой код уже не вспомнить • Автора кода не достать, он пошел на IPO • Статической типизации в эрланге нет
- 11. Реалии старого кода • Код 10-летней давности запускается и работает • Очень сильная обратная совместимость между версиями VM • Немутабельность сильно помогает отладке • Не-OTP код — зло, OTP код — хорошо
- 12. Старый код в Эрливидео • Есть куски кода, которым по 5 лет • Иногда проводятся массовые рефакторинги • Интеграционные тесты помогают, юнит-тесты нет
- 13. Борьба с багами • 95% падений рантайма — нехватка памяти • Нехватка памяти почти всегда — нехватка контроля за пайплайном данных • Остальное лечится чтением стектрейсов сверху вниз, потому что let it fail • Если пишем хорошо, то ошибки изолируются по процессам
- 14. Алгоритмы багфикса • По нажатию кнопки «загрузить логи», система сама пакует всё • Пользователи всегда вырезают самое интересное из логов, их логи мы не читаем • Изучаем стектрейсы и периодический дамп самых прожорливых процессов • Пытаемся восстановить ситуацию у себя. Если не можем, идем на сервер заказчика
- 15. Авральные работы на сервере • recon, htop в помощь что бы понять, какой ресурс сожран • to_erl дает больший контроль, чем другие варианты (remsh и ssh) • erlang:processes() что бы найти самого обжору • ищем причину утечки памяти и/или тормозов • непроходимость в пайплайне данных -> утечка памяти
- 16. Интроспекция • supervisor:which_children/1 для обхода структуры • sys:get_state/1 что бы добраться до нутра • lager:pr/2 для изучения состояния • lager:md/1 для тегирования логов • самодельные хелперы: ems_debug:top(binary)
- 17. Само-мониторинг • На сервера не набегаешься • Система должна сама себя мониторить • Поиск источника багов • Поиск потенциальных тормозов (для highload)
- 18. Мониторинги • Потребление памяти (раз в 10 секунд) • Мониторинг длин очередей • Мониторинг размера ets таблиц • Внутренние очереди • Контроль за тем, что данные втекают не быстрее, чем вытекают
- 19. Capacity control • Что бы не лопнуть, надо уметь отказываться • Поиск утечек памяти и багов показывает бутылочные горлышки • Узкие места должны сообщать о собственной загрузке • Без обратного контроля можно быстро, но недолго
- 20. Работа под нагрузкой • Эрланг — одна из нескольких multicore платформ • Можно получить линейное ускорение по ядрам • Интроспекция на живом продакшне под полной нагрузкой • Как всё не затормозить?
- 21. Шаги на пути к Highload • Развязывание узких мест: одно ядро не может, а 10 смогут • Ускорение линейного кода • Перенос данных в память
- 22. Развязывание узких мест • Singleton это узкое место, потому что одно ядро • gen_server:call сам по себе не спасает • Нужно разносить однопроцессные сервисы на несколько ядер • Способы: пулы, шардирование, ets • ETS — это очень быстро и эффективно
- 23. Примеры распараллеливания • У одного открытого файла пул процессов, читающих с диска • В comet сервере шардинг процессов мониторинга по hash(channel_id) % pool_size • Подписка через ets типа bag: по ключу много значений сразу
- 24. Профилирование • Возможность профилировать отдельный процесс • В эрланге оно всё так себе • Анализ стектрейсов • Тайминги в заголовках HTTP ответов • Не особо много хитростей
- 25. ETS для памяти • In-memory database • Великолепно масштабируется на 40-70 ядер • Прекрасно годится для отдачи готовых данных • Рекомендуется вместе с zerocopy протоколами • Вторичные индексы руками
- 26. Примеры в Эрливидео • Раздача live потоков: данные готовятся заранее, укладываются в ets таблицы. 20 Гбит/с без надрыва • Стриминг файлов с диска: пляски с бубном и 10-15 Гбит/с можно
- 27. Архитектура стриминга с диска • В линуксе синхронное чтение с диска, тред на запрос. • Держим 50 или 1000 одновременных запросов к диску • Процесс файла — арбитр между динамическим пулом процессов ридеров • Ридеры идут в лимитированную очередь с таймаутом: N одновременных запросов и M в ожидании • Мониторинг загрузки диска и времени чтения • Спасибо POSIX API
- 28. Продакшн • Писать код на Эрланге интересно • Возможно устранять баги в бою • Можно поддерживать старый код и жить с ним • Можно делать крайне производительный код, притом очень быстро