Некоторое время назад мы столкнулись с производственной проблемой: одно из наших приложений Elixir внезапно начало периодически реагировать. После быстрого анализа того, что могло быть причиной этого, мы выявили резкое и чрезмерное потребление оперативной памяти, связанное со слабым потреблением ресурсов ЦП, что приводило к тому, что приложение переставало отвечать на запросы в течение нескольких секунд.
Помимо самого инцидента, эта история интересна тем, что является прекрасным примером устойчивости приложения, написанного на Эликсире. В случае возникновения проблемы приложение Elixir может перезапустить некоторые из своих собственных функций и снова запуститься в течение нескольких секунд. Это особенно важная функция для продуктов, которые имеют много пользователей и/или готовых функций, как в случае с «Добро пожаловать в джунгли» (WTTJ).
В WTTJ мы используем Эликсир в производстве уже пять лет, и в этой статье мы собираемся поделиться своими отзывами о том, как все получилось.
История WTTJ началась не с Эликсира. Наши первые два минимально жизнеспособных продукта (MVP) были написаны с использованием фреймворка Ruby on Rails. В то время это позволяло нам работать быстрее благодаря простому в использовании дизайну и каркасам фреймворка.. В течение первых двух лет этот стек работал очень хорошо: у нас было два функциональных продукта, которые мы могли быстро развивать.
Но поскольку Ruby on Rails основан на Ruby — интерпретируемом одноядерном языке — наше приложение представляло собой монолит, который было трудно масштабировать по горизонтали. И по мере того, как количество пользователей ежегодно увеличивается, мы сталкиваемся со все большим количеством проблем со временем отклика и сбоями обработки. После нескольких попыток оптимизации кода и библиотек мы быстро достигли пределов возможностей языка.
К середине 2000-х многоядерные процессоры захватили рынок, и пришло время найти более подходящий язык программирования, который мог бы быть как многопоточным, так и многопроцессорным, чтобы решить наши проблемы роста.
Поэтому мы протестировали несколько языков, в основном скомпилированные языки с поддержкой многоядерности: Crystal, Go и Elixir. Несмотря на свои обещания, Crystal был новым и нестабильным языком, и мы просто не хотели рисковать, управляя нашим основным продуктом с помощью технологии, которая сама по себе еще нуждалась в доработке. Что касается Go, то его также быстро исключили, поскольку наши команды не были фанатами языковых парадигм. Кроме того, время разработки функций было бы значительно увеличено без веб-фреймворка, соответствующего стандартам Ruby on Rails. Поэтому мы выбрали Elixir, который WTTJ использует в производстве с сентября 2018 года.
Теперь давайте сразу перейдем к нашим отзывам об экосистеме языка, элементам, относящимся к самой разработке, и всему, что касается развертывания.
Веб-фреймворк Phoenix, поставляемый с Elixir, несомненно, является одним из основных активов экосистемы, благодаря чему язык был одобрен нашими командами. Несмотря на то, что Elixir был еще новым, когда мы начали его использовать, мы могли легко создавать веб-приложения с использованием этого фреймворка, благодаря тому, что его парадигмы были похожи на Ruby on Rails, и возможности изначально использовать WebSockets, популярную технологию на WTTJ. Следует отметить, что мы используем эту структуру в основном из-за ее возможностей API, а системы Views и LiveView мы используем довольно редко.
Также стоит упомянуть, что, хотя этот стек элегантен и эффективен, Elixir по-прежнему остается нишевой технологией. Согласно исследованию StackOverflow, опубликованному весной 2022 года, только 2,46% профессиональных разработчиков говорят, что использовали его или хотели бы использовать в ближайшее время, несмотря на то, что это второй по популярности язык (какой парадокс!). Это приводит к сильным ограничениям для компаний, использующих этот язык.
Во-первых, это нишевое позиционирование приводит к проблемам с набором персонала: сложно найти разработчиков с опытом работы с Elixir. Поэтому часто необходимо рассмотреть возможность найма разработчиков, заинтересованных в языке, но не имеющих значительного опыта, а затем посвятить время их обучению. Это влечет за собой дополнительные затраты компании, так как эти застройщики явно не смогут выполнить свои задачи в течение нескольких месяцев.
Другим недостатком является то, что сообщество, конечно, маленькое. Это означает, что язык редко интегрируется, поставщики услуг не всегда предлагают SDK для этого языка, и существует меньше библиотек, поэтому конкуренция за некоторые функции меньше.
Тем не менее, это не делает сообщество Эликсира менее приветливым — как раз наоборот! Поскольку вклады случаются реже, предложение новых проектов или перенос существующих функций высоко ценится, и сообществу легче их продвигать. В 2022 году мы были рады получить приглашение от Эликсир мышления подкаст, чтобы рассказать о нашем проекте ecto_anon, и наши статьи также регулярно публикуются в информационном бюллетене ElixirStatus.
Основное преимущество Elixir для разработки заключается в том, что язык функционален, что означает, что он в основном декларативен, а его переменные неизменяемы. Более того, создатель языка Хосе Валим, бывший основной разработчик проекта Ruby on Rails, придал Elixir «рубиноподобный» синтаксис. Он позволил реализовать несколько примечательных функций, таких как сопоставление с образцом — синтаксис, позволяющий писать несколько функций с одним и тем же именем, но с разными аргументами, — и слабую типизацию (более слабую, чем Go или Crystal), упрощающую работу с внешние API, например.
Влияние Ruby on Rails также дало Elixir логику Active Record, системы объектно-реляционного отображения (ORM). Насколько мы понимаем, Elixir обратился к Active Record при создании SQL-оболочки Ecto, которая фокусируется на явных запросах, даже если код многословен. Но в то время как Active Record позволяет вам писать запросы только на объектно-ориентированном языке, то есть вы теряете потенциальную оптимизацию SQL, Ecto позволяет вам писать SQL так, как если бы он был объектно-ориентированным.
Язык Elixir также упрощает использование разработки через тестирование (TDD) благодаря способу компиляции кода. Если в Эликсире есть более ранняя компиляция, компилятор просто перекомпилирует то, что изменилось, и это преимущество пропорционально размеру приложения. В некоторых других языках, если вы компилируете серьезное приложение с нуля, вам придется запускать несколько компиляций для каждого крошечного изменения кода. Если ваш код хорошо структурирован, последовательные прогоны тестов могут выполняться с невероятной скоростью.
Еще одним активом экосистемы Elixir является плагин, который вы, скорее всего, будете использовать, если будете работать над веб-приложениями. Эта замечательная библиотека позволяет вам легко использовать инструменты или библиотеки в вашем проекте, например, интегрировать веб-сервер Cowboy в две строки кода. Но это также позволяет вам связать все ваши адаптеры, такие как ваш собственный маршрутизатор приложений или систему управления веб-сеансами.
Тем не менее, Эликсир также имеет свою долю проблем. Одна из проблем, с которой мы впервые столкнулись, связана с управлением переменными конфигурации. Многие вещи задаются в релизе во время компиляции, тогда как ранее на WTTJ у нас были динамические среды по запросу. Поэтому нам пришлось запускать один и тот же выпуск с разными переменными конфигурации. Однако следует отметить, что инструменты для управления переменными времени компиляции и времени выполнения с тех пор развились, и теперь это различие стало проще.
На процедуру запуска рейк-задач также повлиял переход на Эликсир и Феникс. Язык предлагает возможность запуска смешанных задач с помощью Mix, но эти задачи доступны только в среде разработки, поскольку Mix не является инструментом, предназначенным для производства. Поэтому было необходимо настроить уловки, чтобы иметь возможность выполнять определенные задачи миграции в производственной среде.
При создании релиза необходимо соблюдать некоторые правила. Одним из наиболее неизменных правил является то, что среды компиляции и выполнения должны быть ситуативными: код должен быть скомпилирован с использованием одного и того же семейства процессоров, одного и того же дистрибутива (недостаточно использовать одно и то же семейство дистрибутивов, например, Ubuntu и Debian). и такая же версия. Это имеет много последствий в процессе настройки процесса доставки. Когда вы обновляете производственную среду, вам сначала нужно обновить и, конечно же, протестировать процесс интеграции. Однако у Elixir есть неоспоримое преимущество: он позволяет встроить в него свою экосистему — нет необходимости устанавливать Erlang или Elixir на целевую машину! Хотя эта языковая функция создает более тяжелые выпуски размером в несколько мегабайт, она также существенно снижает трения в процессе доставки.
Более того, поскольку Elixir основан на виртуальной машине Erlang, языке, изначально предназначенном для телекоммуникаций, одним из преимуществ является то, что приложения, написанные на Elixir, очень хорошо работают в кластерах. Протоколы существуют для того, чтобы они могли легко общаться и, таким образом, повышать общую устойчивость.
Для этого Elixir использует GenServers (для общих серверных процессов), которые являются внутренними процессами приложения, позволяющими изолировать состояния и поведение. Основная сила этих серверов GenServer заключается в том, что они обеспечивают высокую степень гибкости приложения, особенно благодаря использованию дерева контроля, которое позволяет быть отказоустойчивым за счет изоляции ошибочных процессов без остановки всего приложения. Помните наше приложение, упомянутое в начале этой статьи, которое перестало отвечать на несколько секунд? Это произошло из-за перезапуска GenServer.
В структуре OTP (Open Telecom Platform) также есть несколько распределенных систем хранения, таких как ETS, DETS и Mnesia. Мы использовали Mnesia, распределенную систему управления базами данных в реальном времени (СУБД), в некоторых проектах WTTJ для ускорения и облегчения доступа к быстрой информации в кластере.
Однако система развертывания приложений Elixir может быть сложной для начинающих. Когда мы впервые начали использовать этот язык, мы столкнулись с трудностями с Distillery (который сейчас устарел), усугубляемыми нехваткой ресурсов, доступных в то время. Помимо сложностей сред компиляции и запуска, в то время Distillery была ранней версией системы выпуска, вероятно, не адаптированной для Интернета. Но стоит отметить, что язык и его экосистема с тех пор добились значительного прогресса в этом, и теперь мы развертываем наши приложения, используя встроенный смешанный выпуск.
Итак, сожалеем ли мы о том, что выбрали Elixir в качестве основного языка бэкенда? Точно нет! Язык оказался очень стабильным, несмотря на то, что он относительно новый, и в целом кривая обучения была довольно схожей с любым другим функциональным языком. Вселенная Elixir плотнее, чем вы ожидаете на первый взгляд, поэтому стоит потратить время на то, чтобы полностью понять экосистему Erlang/OTP, когда вы начинаете. Но, как вы можете сказать из нашего опыта, это определенно стоит того! Мы убедили вас? Если вы хотите сделать еще один шаг вперед, посетите веб-сайт Exercism, который предлагает бесплатный высококачественный учебный курс по программированию с помощью Elixir.
Написано Чарльз Смоллруководитель SRE @ WTTJ
Спасибо Кевину Лаконте и Стефану Робино за ценный вклад в эту статью.
Отредактировано Анн-Лора Сивейрак
Иллюстрация Мириам Уорс
Присоединиться к нашей команде!
