Як компанія Spotify перенесла все з локального на Google Cloud Platform

1. Навіщо мігрувати?
2. Міграція послуг
3. Міграція даних
4. Уроки
5. Результати

Компанія Spotify оголосила про те, що вона розпочала свою діяльність у Google Cloud Platform (GCP) ще в 2016 році, сплачуючи 450 мільйонів доларів США протягом трьох років. У Spotify, Google отримав себе якоря клієнта, не тільки з-за своєї марки і масштабу, але і його репутацію як дані, інженерно-орієнтованої компанії.

З тих пір Spotify закрила обидва центри обробки даних США і до кінця року після комплексної міграції не матиме вільної інфраструктури.

Під час конференції Google Cloud Next в Сан-Франциско ми чули від членів команд Spotify і Google Cloud, які були залучені до міграції, про те, як вони йшли, і деякі ключові уроки.

Навіщо мігрувати?

Директор з інженерних розробок у Spotify Ramon van Alteren почав пояснювати, чому Spotify вирішила в першу чергу зайнятися обласною інфраструктурою.

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

"Якщо я дійсно чесний, те, що ми дійсно хочемо зробити в Spotify, буде найкращим музичним сервісом у світі, жодна з цих робіт на дата-центрах фактично не сприяє цьому", - додав він.

Як і звільнення розробників від турботи про надання та підтримку інфраструктури, Ван Альтерен сказав, що компанія також хоче почати користуватися деякими інноваціями, які виходять з Google Cloud, зокрема BigQuery Cloud Storage, Pub / Sub для обміну повідомленнями та DataFlow. для пакетної та потокової обробки.

Ван Альтерен також сказав, що рушійною силою переходу до хмари стало дещо несподівано, від інженерів, які мали намір підтримувати ці центри обробки даних. "Велика частина цього запитувала, як виглядає їхня робота, коли ми перейдемо до хмари", - сказав він. "Остаточний результат полягав у тому, що група інженерів, деякі з найбільш глибоко шанованих у Spotify, виявилися прибічниками для нашої хмарної стратегії".

Міграція послуг

Фактичний план міграції був сформульований ще в 2015 році і був розділений на дві частини: послуги та дані.

Міграція послуг зосереджена на перенесенні майже 1200 мікросервісів з локальних центрів обробки даних до Google Cloud Platform.

Три головні цілі міграції, на думку Ван Альтерена, полягали у мінімізації перебоїв у розробці продукту, завершенні якомога швидше, щоб уникнути витрат і складності роботи в гібридному середовищі, а також очищення, щоб у Spotify не було жодних затяжних послуг працює в його дата-центрах.

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

Ця візуалізація виглядає як набір червоних (центр обробки даних) і зелених (Google Cloud) бульбашок, при цьому кожен бульбашка являє собою систему, а розмір міхура, що представляє кількість задіяних машин.

"Це мало ряд цікавих побічних ефектів, які врятували мені багато часу як менеджера програми для збереження оновлень статусу", - сказав Ван Альтерен. "Далі це створило справжнє почуття досконалості для команд, які мігрували, і вони могли бачити вплив, який вони робили".

Міграція послуг розпочалася з відображенням залежностей, оскільки архітектура в Spotify означає, що кожна мікросервіс покладається на 10-15 інших, щоб обслуговувати запит клієнта. Це означає, що міграція «великого вибуху», де все зупиняється, не є можливим, оскільки клієнти очікують постійної безперебійної роботи служби.

Натомість інженерним командам Spotify було доручено перенести свої послуги на хмару у фокусному двотижневому спринті, де вони ефективно призупинили будь-які розробки продуктів. Це також дозволило тим командам розпочати оцінку своєї архітектури та вивести з експлуатації щось непотрібне.

Однією з рішень, які Google Cloud принесла до таблиці спеціально для Spotify під час міграції, є її віртуальна приватна хмара (VPC).

"Це дозволяє будувати подібно до внутрішньої мережі, яка з'єднує декілька проектів, і вони можуть переговорити", сказав Ван Альтерен.

"Це дає командам хороший контроль над своєю долею, вони роблять те, що їм потрібно для своєї служби, і якщо вони стріляють у ногу, вони стріляють у ногу, а не в цілу компанію".

Другим блокатором була затримка, викликана віртуальною приватною мережею (VPN). Починаючи міграцію, Spotify виявила, що перенесення 1200 або більше мікросервісів зайняло багато пропускної спроможності VPN.

"Чесно кажучи, VPN-служба на той час була більш-менш масштабною для офісу 25 розробників", - сказав він. "Коли ми з'явилися з чотирма інформаційними центрами, які не працювали так добре, тому ми співпрацювали з Google і примусили це працювати досить швидко. Таким чином, ми побудували кілька гігабайт мережевих труб між нашими центрами обробки даних і Google Cloud, щоб отримати цю залежність Проблема зникне ".

Як тільки ці блокатори були видалені, Spotify зміг приступити до переміщення користувача до хмари. "Іншою ключовою реалізацією в міграції послуг було те, що ми могли б від'єднати міграцію послуг від переміщення нашого трафіку користувачів", - сказав Ван Альтерен.

Таким чином, ми свідомо розділили ці дорожні карти, щоб зосередитися на тому, щоб ці програми були готові до запуску в Google Cloud, і окрему дорожню карту, яка дозволила нам поступово з'єднувати все більше користувачів з GCP, що дозволило нам контролювати надійність, досвід користувачів і швидкість міграції , а також скільки трафіку надходить через ці посилання VPN. "

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

Пітер Марк Фервурд, архітектор рішень у Google, сказав: "Хоча це було цікаво розбивати речі і бачити команди, щоб допомогти забезпечити належне поширення систем моніторингу на нове розгортання хмари, якщо команда не помітила, що це буде Великий червоний прапор. Нарешті, ми мали цю книжку, яку вони могли б почати ходити за відмови в хмарі, яку вони не мали в минулому. "

До травня 2017 року кожний міграційний спринт був завершений, а трафік спрямовувався до Google Cloud. Потім у грудні 2017 року Spotify потрапив до 100% користувачів і вже закрив перший з чотирьох центрів обробки даних. Відтоді другий центр обробки даних був закритий, а останні два, як в Європі, будуть закриті до кінця цього року.

Ця дорожня карта є "досить сильним сигналом для людей з довгостроковими додатками, які все ще працюють у центрах обробки даних, що їм необхідно перейти", - сказав Ван Альтерен.

Міграція даних

Далі ми розповімо про міграцію даних Джош Баер, старший менеджер з виробництва інфраструктури машинного навчання в Spotify, який описав досвід переміщення однієї з найбільших кластерів Hadoop в Європі до хмари.

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

Детальніше: Google додає функції AI до G Suite, включаючи "розумний відповідь" для чату Hangouts

Spotify почалася з оцінки можливості міграції «великого вибуху». "Закрийте кластер Hadoop, скопіюйте всі дані в GCP і почніть все знову", сказав Баер.

На жаль, навіть з мережевим посиланням на 160 гігабіт на секунду було потрібно два місяці для копіювання даних з кластера Hadoop до інфраструктури Google. "Ми б не були великим бізнесом, якби ми були на два місяці", - додав він.

Стратегія, на яку вони потрапили, - це скопіювати багато даних.

"Коли ви перенесли свою роботу на GCP, ви б скопіювали ваші залежності, то ви могли б портувати свою роботу", - пояснив він. "Тоді, якщо у вас з'являться споживачі, ви можете скопіювати вивід вашої роботи на наш кластер, щоб вони не були порушені. Оскільки основна частина міграції даних тривала від шести до дванадцяти місяців, ми працювали багато робочих місць для заповнення прогалин на нашому дереві залежностей. "

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

Кожен міграційний спринт розпочався з двох варіантів участі команди: вони могли підняти і перенести - те, що вони називали «навантажувачем» - там, де це було доречно, або бідними за часом; але в ідеалі вони переписали б.

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

«Найбільш важливим з переписуванням було вимагати набагато більших витрат часу від команд і як інженерів, що зазвичай відбувалося, так як вони почали писати його, і вони хочуть теж реархітувати.

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

Spotify тепер використовує свій стек даних повністю на BigQuery, виконуючи 10 мільйонів запитів і запланованих завдань на місяць, все-в-усіх обробляючи 500 петабайт даних.

Уроки

Max Charas, стратегічний інженер хмари в Google попереджав: "Ця стратегія міграції дуже пристосована до Spotify як технічно, так і організаційно, так що якщо ви хочете зробити щось подібне, це може виглядати зовсім іншим".

Якщо говорити про це, то було отримано кілька ключових уроків з міграції.

Перший - підготувати. Charas сказав: "Ми підготувались, мабуть, за два роки до міграції, і кожна міграція тривала близько року. Ми намагалися побудувати мінімальний випадок використання, щоб показати переваги переходу на GCP, але це не могло бути маленькою річчю, щоб показати правду значення. "

Другий - зосередитися. Ван Альтерен сказав: "Це дійсно дивно, що ви можете зробити з командою інженерів, орієнтованих на одну річ, ми мали спринту на тиждень переїзд 50-70 послуг. Це також допоможе вашим зацікавленим сторонам бізнесу, які будуть щасливішими з коротким Період часу без розвитку продукту замість того, щоб тривалий час. Якщо ви намагаєтеся робити інші речі в той же час, ви будете сповільнювати міграцію до сканування.

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

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

Результати

Результати для Spotify були більше свободи для розробників і більшого масштабу, не жертвуючи його якістю обслуговування.

"Якість обслуговування - це те, що ми ретельно оцінювали і там не було ніякої деградації", - сказав Ван Альтерен. "Переваги, які ми отримали, включають наш конвеєр доставки подій, який несе наші виплати роялті для власників прав, але також є основною частиною нашого розробки продукту. Коли ми перейшли до хмари, що трубопровід був у піку 800000 подій в секунду, дивіться зараз, і ми переносять 3 000 000 в секунду, маючи набагато більше інформації, доступної для розробки продукту, божевільним.

І економія коштів? "Це ключова річ, щоб стежити за тим, як ми переходимо від централізованої позиції купівлі до розподіленої позиції купівлі, де кожен здатний витрачати гроші на вашу компанію", - визнав ван Альтерен. "Так це залежить. В даний час ми виросли в розмірах, так що це дуже важко порівняти, і я не можу дати вам цифри".