Створення системи безперервного розгортання: досвід Instagram



В нашому блозі на Хабре ми не тільки розповідаємо про розвиток свого продукту — білінгу для операторів зв'язку «Гідра», але і публікуємо матеріали про роботу з інфраструктурою і використанні технологій з досвіду інших компаній.

В Instagram розгортання backend-коду (основна програмно-апаратна частина, з якою працюють клієнти) походить від 30 до 50 разів на день, кожного разу, коли інженери підтверджують зміну оригіналу. І, здебільшого, без участі людини — складно в це повірити, особливо враховуючи масштаби соцмережі, але факт залишається фактом.

Інженери Instagram у своєму технічному блозі рассказали про те, як створювали цю систему і налагоджували її безвідмовну роботу. Ми представляємо вашій увазі головні думки цієї замітки.

Навіщо все це потрібно

У безперервного розгортання є кілька переваг:

  1. Безперервне розгортання дозволяє швидше працювати інженерам. Вони не обмежені декількома развертываниями за день у фіксований час — вносити зміни по мірі необхідності що економить час.
  2. Безперервне розгортання легше виявляти помилки, які вкралися в той чи інший комміт. Інженерам не доводиться разом аналізувати сотні змін, щоб знайти причину нової помилки, достатньо проаналізувати два-три останніх коміта. Метрики або дані, які вказують на проблему, можна використовувати для точного визначення моменту виникнення помилки, а значить, відразу зрозуміло, які коміти потрібно перевірити.
  3. Коміти, містять помилки можна швидко виявити і виправити, а значить-код не перетворюється в кишить «багами» масу, розгорнути яку фізично неможливо. Система завжди знаходиться в такому стані, коли знайти і виправити помилку можна дуже швидко.

Реалізація

Успіх підсумкової реалізації проекту багато в чому можна пов'язати з ітеративним підходом побудови архітектури. Система не створювалася окремо з наступним переключенням на неї, замість цього інженери Instagram розвивали існуючий процес створення софта і роботи з інфраструктурою до тих пір, поки не було реалізовано безперервне розгортання.

Що було раніше

До безперервного розгортання, інженери вносили зміни по мірі їх виникнення — якщо була реалізована певна функція, яку хочеться скоріше запровадити, то запускався процес розгортання. При цьому спочатку розгортання відбувалося на тестових серверах — на них «накочувалися» оновлення, потім вивчалися логи, і якщо все було добре, потім-оновлення розгорталося вже на всю інфраструктур.

Все це було реалізовано у вигляді скрипта Fabric (бібліотека і набір інструментів командного рядка для розгортання та адміністрування програм на python), крім того використовувалася найпростіша база даних і графічний інтерфейс «Sauron», який зберігав логи розгортання.

Тест з використанням «канарок»

Першим кроком було додавання тесту з використанням «канарок» (груп кінцевих користувачів, які можуть не знати про участь в тесті), що спочатку передбачало створення скриптів для автоматизації инжереных завдань. Замість запуску роздільного розгортання на одній машині, скрипт розгортається на машинах «канереек», записує пользователськіе логи, а потім запитує дозвіл на подальше розгортання. На наступному етапі здійснюється обробка зібраних даних: скрипт аналізує HTTP-коди всіх запитів і впорядковує їх згідно заданому бар'єру (наприклад, менше 0,5% або як мінімум 90%).

У інженерів Instagram був набір готових тестів, однак, він запускався тільки співробітниками ІТ-департаменту на їх робочих машинах. А значить, рецензентам (тим, хто виконує code review) при визначення успішності чи неуспішності тесту колегам доводилося вірити на слово. Крім того були невідомі результати тесту при розгортанні коміта на бойовій системі.

Тому було вирішено встановити систему інтеграції Jenkins для запуску тестів нових змін і створення звітів для графічного інтерфейсу Sauron. Цей інструмент був потрібен для відстеження останніх успішно пройшли тести комітів — при необхідності, саме їх система повинна була пропонувати замість самого останнього коміта.

Для рефакторінгу інженери Facebook використовують інструмент Phabricator і добре інтегрується з ним систему Sandcastle. Їх колеги з Instagram також. скористалися Sandcastle для запуску тесту і отримання звітів.

Автоматизація

Перед початком проекту по автоматизації розгортання інженерам Instagram довелося виконати деяку підготовчу роботу. Зокрема, для кожного нового розгортання був доданий статус (запущено, готове, помилка) і реалізовані оповіщення, які з'являлися у випадку, якщо попереднє розгортання не мало статусу «готово». В графічний інтерфейс була додана кнопка для переривання розгортання. Крім того, було реалізовано відстеження всіх змін. У результаті, якщо раніше Sauron знав лише про останній вдало минулому тесті, то тепер всі зміни бойової системи записувалися, і був відомий статус кожного з них.

image

Потім була виконана робота по автоматизації рішень, які повинен був приймати осіб. Першим з них був вибір коміта, який повинен бути розгорнутий. Початковий алгоритм завжди вибирав коміти, які вдало пройшли тест, і вибирав як можна менша їх кількість — це число ніколи не перевищувало трьох. Якщо все коміти пройшли тест успішно, то кожен раз обирали нове зміну, крім того могло бути не більше двох послідовних змін, які не пройшли тестування. Другим було рішення про успіх або провал проходження розгортання. Якщо воно не пройшло більш ніж на одному відсотку хостів, то таке розгортання вважалося не виконаним.

У такій конфігурації в процесі розгортання людині доводилося кілька разів відповідати «так» у системному діалозі (прийом коміта, запуск канаркового тіста, старт повного розгортання) — це дію можна було автоматизувати. Після цього Jenkins навчилася запускати скрипт повного розгортання — звичайно, на першому етапі ця його можливість використовувалася тільки під наглядом інженерів.

Проблеми

При реалізації безперервного розгортання в Instagram до його поточного стану не все йшло гладко. Було кілька проблем, над якими інженерам довелося попрацювати.

Помилки тестування
Насамперед, часто бувало так, що в коммитах містилися помилки, що приводили до збоїв тестів — а значить вони не працювали і для всіх наступних комітів. А це, в свою чергу, означало, що в такому випадку нічого не могло бути розгорнуто. Щоб виправити помилку, потрібно було спочатку помітити неполадки, відкотити проблемний комміт, почекати проходження тестів для останнього успішного коміта, а потім вручну розгорнути входять в комміт зміни, перш ніж процес зможе продовжитися в автоматичному режимі.

Все це зводило нанівець головну перевагу безперервного розгортання — розгортання малого кількості комітів за раз. Проблема полягала в ненадійності і малої швидкості відпрацювання тестів. Щоб скоротити час їх виконання за 12-15 хвилин до 5 інженерам Instagram довелося зайнятися оптимізацією продуктивності та виправленням помилок у тестовій інфраструктури, які призводили до її ненадійності.

Накопичення черги змін
Незважаючи на запроваджені поліпшення, все ще регулярно утворювалася черга змін, що чекають розгортання після помилки. Основною причиною були помилки, виявлені в ході канареечных тестів (як позитивні, так і позитивні), але виникали і інші несправності. Після виправлення проблеми, система автоматизації вибирала по одному коммиту для розгортання — щоб розгорнути їх все, потрібно було час, за яке чергу могли потрапити і нові зміни.

Зазвичай у такій ситуації черговий інженер міг втрутитися і розгорнути всю чергу відразу — але це, знову ж таки, нивелировло одне з головних достоїнств безперервного розгортання.

Для виправлення цього недоліку був реалізований алгоритм обробки черги в логіці вибору змін, що дозволило автоматично розгортати безліч змін при наявності черги. Алгоритм заснований на встановлення тимчасового інтервалу, через який буде розгортатися кожна зміна (30 хвилин). Для кожної зміни в черзі розраховується залишився інтервал часу, число розгортання, які можна провести в цей інтервал, і число змін, які повинні бути розгорнуті за раз. Вибирається максимальне відношення змін до розгортання, але воно обмежується трьома. Це дозволило інженерам Instagram проводити стільки розгортання, скільки можливо при забезпеченні розгортання кожного коміта за прийнятний час.

Однією зі специфічних причин виникнення черги було уповільнення розгортання із-за збільшеного розміру інфраструктури сервісу. Приміром, одного разу інженери виявили, що ядро було повністю завантажено SSH-агентом, що здійснює SSH-аутентифікацію сполук, і скриптом Fabric. Для вирішення цієї проблеми агент був замінений на розподілену SSH-систему від Facebook.

Пам'ятка по розгортанню від інженерів Instagram

Що потрібно знати, щоб здійснити подібний проект? Інженери Instagram виділили кілька основних принципів, які слід використовувати для створення настільки ж ефективно працюючих систем автоматичного розгортання.

  1. Тести. Набір тестів повинен бути швидким. Охоплення тестів також повинен бути великим, проте тут не обов'язково намагатися осягнути неосяжне. Тести повинні часто запускатися: при оцінці коду, перед застосуванням змін (в ідеалі блокуючи реалізацію при помилці), після реалізації змін.
  2. Тести з використанням «канарок». Необхідний автоматизований тест з використанням «канарок» для запобігання розгортання дійсно поганих комітів на всій інфраструктурі. Знову ж таки, перфекціонізм тут не обов'язковий, навіть простого набору статистичних показників і порогових значень буде достатньо.
  3. Автоматизація звичайного сценарію. Не треба автоматизувати все, достатньо лише стандартних і простих ситуацій. Якщо відбувається щось незвичайне, слід зупинити автоматичне виконання, щоб у ситуацію могли втрутитися люди.
  4. Людям повинно бути зручно. Одним з найбільших перешкод, що виникають у ході подібних проектів по автоматизації, є той факт, що люди перестають розуміти, що відбувається в поточний момент часу, і втрачають можливості контролю. Для вирішення цієї проблеми, система має забезпечувати хороше розуміння того, що зроблено, що робиться, і (в ідеалі) буде зроблено на наступному кроці. Так само необхідний добре працюючий механізм екстреної зупинки автоматичного розгортання.
  5. Варто чекати поганих розгортання. Не варто сподіватися на те, що всі розгортання будуть проходити без проблем. Помилок не уникнути, але це нормально. Головне вміти швидко знаходити проблеми і «відкотити» зміни до працюючої версії.
На думку інженерів Instagram, реалізувати такий проект під силу ІТ-департаментам багатьох компаній. Система постійного розгортання не обов'язково повинна бути складною. Варто почати з чогось простого, сфокусувавшись на викладених засадах, покращуючи систему крок за кроком.

Що інженери Instagram планують робити далі

Зараз система автоматичного розгортання в Instagram працює без особливих нарікань, але ще залишаються деякі моменти, які потрібно буде поліпшити.

  1. Підтримання швидкості роботи. Instagram швидко розвивається, і частота внесення змін також збільшується. Інженерам необхідно підтримувати високу швидкість розгортання для збереження малої кількості реалізованих за раз змін.
  2. Додати більше «канарок». Із зростанням обсягу внесених змін, зростає і кількість помилок на хостах канарок, а з чергою очікують змін взаємодіють все більше розробників. Інженерам потрібно на ранньому етапі «відловлювати» більше поганих комітів і блокувати їх розгортання — для цього здійснюється постійна модифікація процесу канаркового тестування, зокрема, його результати перевіряються з допомогою «бойового» трафіку.
  3. Підвищення якості виявлення помилок. Крім того, інженерна команда Instagram планує знизити вплив поганих комітів, які не були виявлені за допомогою канаркового тестування. Замість тестування на одній машині і розгортання на всьому парку машин, планується додати проміжні етапи (кластери і регіони), на кожному з яких все метриеи будуть перевірятися перед подальшим розгортанням.

Інші технічні статті від «Латеры»:



Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.