Gitlab: как мы поняли, что пора уходить из облака (перевод)

В своей недавней статье про обновление инфраструктуры GitLab я описал связанные с хранилищами данных вызовы, на которые нам приходится отвечать по мере роста сервиса. Стремясь решить возникающие при использовании NFS проблемы емкости и производительности, мы построили CephFS-кластер. И в довесок заменили стандартный PostgreSQL Vacuum на расширение pg_repack. В результате мы ощутили все минусы использования высокопроизводительной распределенной файловой системы в облаке.

За последний месяц мы загрузили в CephFS большое количество проектов, пользователей и CI-артефактов. Эта распределенная файловая система была выбрана из-за надежности и масштабируемости до петабайтных значений (по нашим меркам это почти бесконечность). С CephFS мы можем использовать инфраструктуру напрямую, минуя создание сложных приложений. Но основная проблема CephFS в том, что из-за необходимости записи служебной информации с минимальными задержками ей требуется действительно быстрая базовая инфраструктура. Пока один из хостов не закончит запись в журнал, все остальные ждут завершения этой операции, что означает блокировку файловой системы целиком и по сути остановку работы сервиса.

В процессе более глубокого погружения в вопросы согласованности, доступности и устойчивости к разделению мы обнаружили, что в случае CephFS доступность всегда приносится в жертву согласованности. Мы также выяснили, что под серьезной нагрузкой в системе начинают возникать хот-споты. Например, во время повышенной нагрузки в определенных местах обслуживающего репозиторий GitLab CE кластера все операции чтения и записи начинают выполняться на одном узле. Проблема усугубляется работой в облаке, не имеющем SLA по минимальной задержке в системе ввода-вывода.

Проблемы производительности при работе в облаке

Выбирая облако, мы по умолчанию соглашаемся на использование инфраструктуры провайдера совместно со многими другими людьми. Поставщик облачных услуг обязан обеспечить честное распределение времени работы его ресурсов между всеми клиентами. Это достигается с помощью установки различных лимитов.

На нашем облачном сервере максимальный лимит составляет лишь 20 000 IOPS, а минимальный равен 0. С такими запросами мы становимся очень беспокойными соседями для машин других пользователей, разделяющих с нами один сервер. Продолжая бытовую аналогию, мы — те самые соседи, которые слушают очень громкую музыку действительно допоздна. За это нас наказывают большими задержками: в некоторых случаях до 100 мс для доступа к диску. Это все равно что 8 лет простоять в очереди на кассу в супермаркете. В итоге мы поняли, что облако просто не предназначено для размещения систем с требуемой для CephFS и, соответственно, нас пропускной способностью ввода-вывода.

Для небольших проектов возможностей облака вполне достаточно, и оно дешевле. Однако при необходимости расширения ситуация может оказаться не такой однозначной. Реклама убеждает нас в том, что при масштабировании нужно просто добавить машин, ведь облако практически бесконечно. Мы же выяснили вот что: да, ничто не мешает продолжать плодить новые инстансы, но при необходимости высоких значений IOPS это становится все более дорогим и менее эффективным занятием. Суть облака, которая заключается в разделении между пользователями времени доступа к ресурсам нижележащей инфраструктуры, никуда не исчезает, поэтому максимальную производительность все равно получить не удастся. В итоге вы переплачиваете за сервис, который не удовлетворяет ваши потребности.

Итак, что делать, когда облака уже мало?

Уход в Bare Metal

Для нас настал тот момент, когда в переходе на использование собственного железа появился смысл. С точки зрения экономической эффективности это более надежно и выгодно. Безусловно, первоначальные затраты на покупку своего оборудования велики. Также потребуется организация службы эксплуатации, так как компоненты будут выходить из строя и требовать замены. Нужно хорошо знать используемое оборудование и как следует за ним следить. Но в долгосрочной перспективе это сделает GitLab более эффективным, стабильным и надежным. Также мы получим более полный контроль над своей инфраструктурой.

Как мы заблаговременно находим проблемы

Чтобы как можно раньше выявлять проблемы в инфраструктуре и понимать, как она работает, мы строим пригодную для наблюдений (observable) систему. Машина совершает много действий, о которых мы даже не подозреваем. Чтобы иметь возможность рассмотреть происходящее в деталях, мы собираем данные и метрики в систему под названием Prometheus, где затем создаем дашборды и анализируем тренды.

Эти метрики собираются на основе работы внутренних механизмов ядра и обычным пользователям не так легко доступны. Чтобы увидеть полную картину, необходимо построить систему, позволяющую собирать, агрегировать и визуализировать данные в удобном для анализа виде. Графики могут быть очень полезны, так как позволяют отобразить большое количество информации на одном экране и мгновенно ее оценить.

Например, обзорный график нашего парка машин показывает количество функционирующих рабочих узлов и их загрузку:

Как мы использовали графики для оценки работы CephFS в облаке

Ниже показан график задержек журнала OSD за 7 дней, на котором можно увидеть значительный скачок показателей.

Значения по оси Y отображают время записи журнала на диск. В общем случае мы укладываемся в интервал от 2 до 12 секунд. Увеличение времени до 42 с показывает те моменты, когда провайдер наказывал нас большими задержками. В это время GitLab.com для многих пользователей был недоступен.

Этот график хорош тем, что способен быстро отобразить в одном месте большое количество данных, понятных даже неспециалистам. Необходимо стремиться именно к такому уровню понимания системы. C Prometheus можно настроить мониторинг под себя. Мы занимались этим в течение месяца и уже близки к завершению: осталось добавить еще несколько вещей.

Таким образом, нам удается принимать информированные решения в вопросах, касающихся нашей инфраструктуры. Мы стремимся к тому, чтобы в случае отказа или неправильной работы какого-то сервиса для понимания происходящего и влияния на систему в целом можно было быстро построить график, основанный на исходных данных. Мы стараемся получать и делать доступными для анализа все более детальные и обширные данные о работе GitLab. В противном случае мониторинг превращается лишь в угадывание того, что происходит с вашими системами.

Основная мысль такова: когда ваша инфраструктура — уже не горстка машин, выяснить, что происходит, с помощью однократного выполнения какой-либо команды невозможно. Истинное понимание может быть достигнуто только путем сбора достаточного количества данных.

Что мы в итоге узнали

1. CephFS обеспечивает масштабируемость и производительность (с множеством условий), но в облаке работает не очень хорошо, несмотря на настройку и тюнинг.
2. У облака есть порог производительности. Чтобы его перешагнуть, придется раскошелиться, но при этом все равно сохранится вероятность быть наказанным высокими задержками. Альтернатива ­ — уход из облака.
3. В нашем случае переход на выделенное серверное оборудование является экономически эффективным и более надежным решением.
4. За счет построения удобной для мониторинга системы мы получили возможность замечать неочевидные тенденции и взаимосвязи, что помогает нам быстрее реагировать на возникающие проблемы.
5. Реализация системы мониторинга может очень сильно зависеть от наблюдаемого объекта, поэтому мы делаем собственный модуль экспорта для Prometheus под названием gitlab-monitor и планируем в ближайшее время выложить его на GitLab CE.

Источник на английском: https://about.gitlab.com/2016/11/10/why-choose-bare-metal/