Компанія «УРУС» спробувала Kubernetes у різних видах: самостійний деплоймент на bare metal, у Google Cloud, а потім перенесла свою платформу у хмару Mail.ru Cloud Solutions (MCS). Як обирали нового хмарного провайдера і як вдалося мігрувати до нього за рекордні дві години, розповідає Ігор Шишкін.), старший системний адміністратор «УРУС».
Чим займається «УРУС»
Є багато способів покращити якість міського середовища, і один із них — зробити його екологічно безпечним. Саме над цим працюють у компанії «УРУС — Розумні цифрові сервіси». Тут впроваджують рішення, які допомагають підприємствам контролювати важливі екологічні показники та зменшувати негативний вплив на довкілля. Датчики збирають дані про склад повітря, рівень шуму та інші параметри, а потім надсилають їх у єдину платформу «УРУС — Екомон» для аналізу та складання рекомендацій.
Як влаштовано роботу «УРУС» зсередини
Типовий клієнт «УРУСа» - компанія, яка знаходиться в житловій зоні або поряд з нею. Це може бути завод, порт, залізничне депо чи будь-який інший об'єкт. Якщо наш клієнт вже отримував попередження, був оштрафований за забруднення навколишнього середовища або сам хоче видавати менше шумів, знизити кількість шкідливих викидів, він приходить до нас, і ми вже пропонуємо йому готове рішення щодо екологічного моніторингу.
На графіку моніторингу концентрації H2S видно регулярні нічні викиди розташованого поруч підприємства
Пристрої, які ми використовуємо в «УРУС», містять кілька сенсорів, які збирають інформацію про вміст певних газів, рівень шуму та інші дані для оцінки екологічної обстановки. Точна кількість сенсорів завжди визначається конкретним завданням.
Залежно від специфіки вимірювань пристрої з датчиками можуть розташовуватися на стінах будівель, стовпах та в інших довільних місцях. Кожен такий пристрій збирає інформацію, агрегує її та відправляє на шлюз прийому даних. Там ми зберігаємо дані на тривале зберігання та обертуємо для подальшого аналізу. Найпростіший приклад того, що ми отримуємо на виході після аналізу, - це індекс якості повітря, він же AQI.
Паралельно на нашій платформі працює багато інших сервісів, але переважно вони мають обслуговуючий характер. Наприклад, сервіс нотифікації надсилає клієнтам повідомлення, якщо якийсь із параметрів, що відстежуються (припустимо, вміст СО2) перевищив допустиме значення.
Як ми зберігаємо дані? Історія з Kubernetes на bare metal
У проекті екомоніторингу УРУС є кілька сховищ даних. В одному ми тримаємо «сирі» дані — те, що отримали безпосередньо від самих пристроїв. Це сховище є «магнітною» стрічкою, як на старих касетах, з історією всіх показників. Другий тип сховища використовується для передопрацьованих даних - даних з пристроїв, збагачених метаданими про зв'язки сенсорів і показання самих пристроїв, приналежності до організацій, місць розташування тощо. Ця інформація дозволяє в динаміці оцінити, як змінювався за певний проміжок часу той чи інший показник . Сховище «сирих» даних ми використовуємо у тому числі як бекап і для відновлення передоброблених даних, якщо така потреба виникне.
Коли ми кілька років тому шукали, як вирішити проблему із зберіганням, у нас було два варіанти для вибору платформи: Kubernetes та OpenStack. Але оскільки останній виглядає досить монструозно (просто подивіться на його архітектуру, щоб переконатися в цьому), ми зупинилися саме на Kubernetes'і. Ще одним аргументом на його користь стало відносно просте програмне управління, можливість гнучкіше нарізати навіть залізні ноди за ресурсами.
Паралельно з освоєнням самого Kubernetes ми вивчали і способи зберігання даних, доки ми всі наші сховища тримали в Kubernetes на своєму залізі, ми отримали чудову експертизу. Все, що у нас тоді було, жило саме на Kubernetes'і: statefull-сховище, система моніторингу, СІ/CD. Kubernetes став для нас all-in-one платформою.
Але нам хотілося працювати з Kubernetes'ом як із сервісом, а не займатися його підтримкою та розробкою. Плюс нам не подобалося те, скільки нам обходиться його зміст на bare metal, а технологія була потрібна нам постійно! Наприклад, одним із перших завдань стало вписати Ingress-контролери Kubernetes у мережеву інфраструктуру нашої організації. Це громіздке завдання, особливо якщо уявити, що на той момент нічого не було готове для програмного управління ресурсами на кшталт DNS-записів або виділення IP-адрес. Пізніше ми почали експериментувати із зовнішнім сховищем даних. До імплементації PVC-контролера так і не дісталися, але вже тоді стало зрозуміло, що це великий фронт робіт, під який слід виділяти окремих фахівців.
Перехід на Google Cloud Platform – тимчасове рішення
Ми зрозуміли, що так далі не може продовжуватися, і перенесли наші дані з bare metal на Google Cloud Platform. Насправді тоді для російської компанії було не так багато цікавих варіантів: крім Google Cloud Platform аналогічний сервіс пропонував тільки Amazon, але ми все-таки зупинилися на рішенні від Google. Тоді воно здалося нам економічно вигіднішим, ближчим до Upstream, не кажучи вже про те, що Google сам по собі це своєрідний PoC Kubernetes в Production.
Перша серйозна проблема постала на горизонті паралельно з тим, як росла наша клієнтська база. Коли у нас виникла потреба зберігати персональні дані, ми опинилися перед вибором: або працюємо з Google і порушуємо російські закони, або шукаємо альтернативу в РФ. Вибір, загалом, був передбачуваним. 🙂
Яким ми бачили ідеальний хмарний сервіс
На початок пошуків ми вже знали, що хочемо отримати від майбутнього хмарного провайдера. Який сервіс ми шукали:
- Швидкий та гнучкий. Такий, щоб ми будь-якої миті оперативно могли додати нову ноду або щось розгорнути.
- Недорогий. Нас дуже хвилювало фінансове питання, оскільки ми були обмежені у ресурсах. Ми вже знали, що хочемо працювати з Kubernetes, і тепер стояло завдання мінімізувати його вартість, щоб збільшити чи хоча б зберегти ефективність використання цього рішення.
- Автоматизований. Ми планували працювати з сервісом через API, без менеджерів та телефонних дзвінків чи ситуацій, коли потрібно вручну піднімати кілька десятків нод в авральному режимі. Так як більшість процесів у нас автоматизовані, на те ж ми чекали від хмарного сервісу.
- Із серверами в РФ. Звичайно, ми планували дотримуватися російського законодавства і того самого 152-ФЗ.
У той час провайдерів Kubernetes за моделлю aaS в Росії було мало, при цьому, вибираючи провайдера, нам було важливо не поступитися нашими пріоритетами. Команда Mail.ru Cloud Solutions, з якою ми почали працювати та співпрацюємо досі, надала нам повністю автоматизований сервіс, з підтримкою API та зручною панеллю управління, в якій є Horizon – з ним ми могли швидко підняти довільну кількість нод.
Як нам вдалося мігрувати до MCS за дві години
У подібних переїздах багато компаній стикаються з труднощами та невдачами, але в нашому випадку їх не було. Нам пощастило: оскільки ми до початку міграції вже працювали на Kubernetes, ми просто поправили три файли і запустили свої сервіси на новій хмарній платформі, в MCS. Нагадаю, що на той час ми остаточно пішли з bare metal і жили на Google Cloud Platform. Тому сам переїзд зайняв не більше двох годин плюс ще трохи часу (близько години) пішло на копіювання даних з наших пристроїв. Тоді ми вже використовували Spinnaker (мультихмарний CD-сервіс для забезпечення Continous Delivery). Його ми теж оперативно додали до нового кластера і продовжили працювати у звичайному режимі.
Завдяки автоматизації процесів розробки та CI/CD Kubernetes'ом в УРУС займається один спеціаліст (і це я). На якомусь етапі зі мною працював ще один системний адміністратор, але потім виявилося, що всю основну рутину ми вже автоматизували, а з боку нашого основного продукту завдань все більше і має сенс направити ресурси на це.
Ми отримали від хмарного провайдера те, що очікували, оскільки розпочали співпрацю без ілюзій. Якщо й були якісь інциденти, то переважно технічні й такі, які легко пояснити відносною свіжістю сервісу. Головне, що команда MCS оперативно усуває недоліки та швидко реагує на питання у месенджерах.
Якщо порівнювати досвід роботи з Google Cloud Platform, то я навіть не знав, де знаходиться кнопка зворотного зв'язку, оскільки в ній просто не було необхідності. А якщо якісь проблеми траплялися, Google сам розсилав повідомлення в односторонньому порядку. Але у випадку з MCS великим плюсом я вважаю, що вони знаходяться максимально близько до російських клієнтів — і територіально, і ментально.
Як ми бачимо роботу з хмарами у майбутньому
Зараз наша робота тісно зав'язана на Kubernetes'і, і він повністю влаштовує нас із погляду інфраструктурних завдань. Тому ми не плануємо кудись з нього мігрувати, хоча постійно вводимо нові практики та сервіси для спрощення рутинних завдань та автоматизації нових, підвищення стабільності та надійності сервісів… Зараз запускаємо сервіс Chaos Monkey (а конкретно ми використовуємо chaoskube, але концепції це не змінює ), який спочатку був створений у Netflix. Chaos Monkey робить одну просту річ: у довільний час видаляє довільний під Kubernetes'е. Це потрібно, щоб наш сервіс нормально жив із кількістю інстансів n–1, тож ми привчаємо себе бути готовими до будь-яких неполадок.
Зараз я бачу використання сторонніх рішень — тих самих хмарних платформ — як правильне для молодих компаній. Зазвичай на початку шляху вони обмежені в ресурсах, як кадрових, так і фінансових, а будувати та утримувати власну хмару чи дата-центр надто дорого та трудомістко. Cloud-провайдери дозволяють мінімізувати ці витрати, у них можна швидко отримати ресурси, необхідні для роботи сервісів тут і зараз, причому оплачувати ці ресурси за фактом. Що стосується компанії «УРУС», то ми поки що залишимося вірними Kubernetes'у у хмарі. Але хто знає, можливо, нам доведеться розширюватись географічно, чи впроваджувати рішення на базі якогось специфічного обладнання. Або, може, кількість споживаних ресурсів виправдає власний Kubernetes на bare-metal, як у старі добрі часи. 🙂
Що ми винесли з досвіду роботи з хмарними сервісами
Ми почали використовувати Kubernetes на bare metal, і навіть там він був по-своєму гарний. Але сильні його сторони вдалося розкрити саме як aaS-компонент у хмарі. Якщо поставити ціль і все максимально автоматизувати, то вдасться уникнути vendor lock-in і переїзд між хмарними провайдерами займе кілька годин, а нервові клітини залишаться з нами. Іншим компаніям ми можемо порадити: хочете запустити свій (хмарний) сервіс, маючи обмежені ресурси та максимальний velocity для розробки - починайте прямо зараз з оренди хмарних ресурсів, а свій дата-центр будуйте після того, як про вас напише Forbes.
Джерело: habr.com