Хмарні послуги на практиці: п'ять сценаріїв, у яких хмара працює на компанію

Блог WebDisk · категорія: Хмара · час читання: ~7 хвилин

Коротко:- Замість загальників про «ключ до сучасності» – п'ять конкретних застосувань хмари в компанії: хостинг застосунків, резервні копії, сховище даних, тестові середовища та сезонні піки.- Спільний знаменник усіх п'яти: ресурси ви запускаєте тоді, коли вони потрібні, і платите за те, що використовуєте – замість інвестувати наперед в обладнання «про запас».- Чесно: хмара не є автоматично дешевшою ані безпечною «сама собою» – ми пишемо також про те, коли вона не виправдовується.

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

Ця стаття – огляд застосувань, а не словник понять. Якщо ви хочете спершу впорядкувати терміни IaaS, PaaS і SaaS, прочитайте «Хмара як послуга» – тут ми припускаємо, що визначення вже позаду, і відповідаємо на практичне питання: для чого компанії насправді використовують хмарні послуги? На розгляд беремо п'ять сценаріїв, з яких найчастіше починається знайомство компанії з хмарою.

Для порядку одне речення визначення: хмарні послуги – це ІТ-ресурси – обчислювальна потужність, простір для даних, готові застосунки – що надаються через інтернет з інфраструктури постачальника, запускаються та вивільняються на вимогу, без купівлі власного обладнання.

Сценарій 1. Хостинг застосунків: сервер, який росте разом із трафіком

Найочевидніше застосування: корпоративний сайт, інтернет-магазин, система B2B, застосунок, яким користуються клієнти. Замість фізичного сервера – віртуальна машина в публічній хмарі, а поруч із нею елементи, які у власній серверній довелося б купувати та обслуговувати окремо: приватні мережі (VPC), файрвол, балансувальник навантаження, що розподіляє трафік між кількома екземплярами.

Практична різниця виявляється в життєвому циклі застосунку. Ви стартуєте з невеликої конфігурації, бо нова система має десять користувачів. Через півроку їх п'ятсот – збільшення машини або додавання другої це операція в панелі, а не замовлення обладнання з кількатижневим терміном постачання. Команди розробників ідуть на крок далі й розгортають на тих самих ресурсах контейнерні кластери (Docker, Kubernetes), поєднуючи їх із власними процесами CI/CD.

У WebDisk цей сценарій обслуговує публічна хмара WebDisk Cloud – віртуальні машини з оплатою за фактично використані ресурси.

Сценарій 2. Резервне копіювання: копія поза компанією без будівництва другої серверної

Класичне правило резервних копій 3-2-1 говорить: три копії даних, на двох різних носіях, у тому числі одна поза локацією компанії. Остання вимога історично була найдорожчою – вона означала другу серверну, вивезені стрічки або диски в сейфі. Хмара замикає це правило без жодної з цих речей: копія «поза локацією» – це сховище в постачальника, у фізично іншому місці, ніж ваші системи.

Природною ціллю копії є об'єктне сховище, сумісне з S3 – популярні інструменти резервного копіювання вміють писати в нього напряму, без посередників. Дедалі більшого значення набуває стійкість такої копії до ransomware: зловмисники рутинно намагаються видалити резервні копії, перш ніж зашифрувати продакшн, тому все частіше вимагають копій, які неможливо видалити до завершення заданого часу (про такі незмінні копії ми пишемо в окремій статті).

Одне застереження: резервне копіювання в хмарі не «відбувається саме собою». Розклад, обсяг і – передусім – тестове відновлення залишаються вашим завданням. Більше про побудову цього процесу ми пишемо в статті «Резервна копія в хмарі: фундамент ІТ-безпеки».

Сценарій 3. Сховище даних: Object Storage замість чергового NAS

Корпоративні дані ростуть швидше, ніж будь-що інше: документи, скани, мультимедіа, логи, артефакти застосунків. Локальний NAS відповідає на це черговими дисками, перебудовами масивів і питанням «що далі, коли корпус заповниться». Object Storage – об'єктне сховище – масштабується без цієї механіки: ви додаєте дані, не керуєте томами, а платите за реально зайняте місце.

Ключовою рисою є стандартний інтерфейс S3, яким говорить величезна екосистема інструментів – від AWS CLI та s3cmd до програмних бібліотек. Застосунок, який уміє писати в S3, як правило, працюватиме з будь-яким сумісним сховищем – відмінності між реалізаціями стосуються деталей, а не ядра API; це практична страховка на випадок зміни постачальника. В Object Storage від WebDisk, побудованому на відкритій платформі Ceph, можна ввімкнути шифрування на рівні бакета (бакет – це контейнер, у якому сховище S3 зберігає об'єкти, тобто файли – окремий, іменований простір для даних). Розподілена архітектура при цьому зберігає дані надлишково, так щоб відмова окремого диска чи сервера не означала їх втрати.

А якщо замість сирого S3 команді потрібен зручний інтерфейс для щоденної роботи з файлами, цю роль виконують надбудови на кшталт Nextcloud – відкрита платформа спільного використання файлів і групової роботи, у WebDisk доступна як керована послуга WebDisk Next; об'єктне сховище стає тоді шаром під ним. Ширший опис застосувань об'єктного сховища ви знайдете в записі «Object Storage у WebDisk».

Сценарій 4. Тестові середовища: інфраструктура на години, а не на роки

У власній серверній тестове середовище – це зазвичай найстаріший сервер у шафі, бо «шкода нового». У хмарі буває навпаки: тестове середовище може бути точною копією продакшну, яка існує лише на час тестів. Ви клонуєте машину з шаблону або знімка (снапшоту), проводите пробну міграцію, оновлення чи тести продуктивності – і видаляєте все, платячи за години, а не за роки.

Той самий механізм рухає щоденну роботу розробників: окреме середовище на проєкт чи гілку коду, машини для збірки в процесах CI/CD, що створюються на час білду. Зникає також класичний конфлікт «тести з'їдають ресурси продакшну» – середовища відокремлені одне від одного мережево та ресурсно.

Це сценарій, у якому оплата за використання дає найбільшу різницю порівняно з власним обладнанням: інфраструктура, яка більшу частину часу не існує, більшу частину часу не коштує.

Сценарій 5. Сезонність: пік без обладнання, купленого на цілий рік

Інтернет-магазин перед четвертим кварталом, бухгалтерська фірма при закритті року, рекрутинговий портал у сезон набору, кампанія з телевізійною рекламою – багато бізнесів мають піки, у яких трафік зростає в кілька разів на тижні, іноді на дні. Власне обладнання доводиться купувати під цей пік; решту року воно простоює й старіє.

У хмарі ресурси додають перед піком і згортають після нього: більші машини, додаткові екземпляри за балансувальником навантаження, більше простору для даних. Чесне зауваження: самого «докуплення екземплярів» не досить – застосунок мусить уміти працювати на багатьох машинах паралельно, а це треба спроєктувати (відсутність збереження стану, спільне сховище сесій або даних). Масштабування є властивістю архітектури, яку хмара уможливлює, а не функцією, що вмикається кнопкою.

Коли хмара не виправдовується? Чесний баланс

• Стале, високе навантаження 24/7. Якщо машини мають працювати на повну потужність без перерви роками, власне обладнання буває дешевшим у загальному розрахунку. Перевага хмари зростає разом зі змінністю навантаження – тому сценарії 4 і 5 виправдовуються найлегше, а сталу, передбачувану базу треба порахувати, а не припустити.
• Відповідальність не зникає – змінює обсяг. Постачальник відповідає за обладнання, живлення та рівень віртуалізації; конфігурація систем, права доступу, оновлення та резервні копії на ваших машинах залишаються на вашому боці. Погано сконфігурована машина в хмарі так само вразлива, як погано сконфігурована у власній серверній.
• Передавання даних. Перенесення великих обсягів – особливо вихідних – буває в постачальників хмари істотною статтею витрат. Перевірте умови свого плану, перш ніж проєктувати архітектуру, яка постійно переганяє великі обсяги даних між локаціями.
• Залежність від постачальника. Що більше унікальних послуг конкретної хмари ви поєднаєте із застосунком, то дорожчим буде переїзд. Стандартні інтерфейси (як-от S3) та відкрите програмне забезпечення зменшують цей ризик – варто про них питати при виборі постачальника.

Часті запитання

Для чого компанії насправді використовують хмарні послуги? Найчастіше для п'яти речей: хостингу застосунків і сайтів, резервних копій поза компанією, сховища даних (object storage), тестових середовищ, створюваних на час робіт, та обслуговування сезонних піків трафіку. Спільний знаменник: ресурси запускають тоді, коли вони потрібні, і платять за фактичне використання, замість інвестувати наперед в обладнання.

Чи хмара дешевша за власний сервер? Буває – але не за визначенням. Хмара замінює велику інвестиційну витрату на операційні витрати й усуває оплату за бездіяльне обладнання; при сталому, повному навантаженні ця перевага тане. Ретельне порівняння враховує на боці власного обладнання також електроенергію, охолодження, сервіс, простір і час людей – не лише ціну сервера.

З якого сценарію почати? Якщо компанія не має резервної копії поза своєю локацією – з резервного копіювання. Воно не вимагає змін у працюючих системах, дає негайну цінність і дає змогу познайомитися з постачальником за низького ризику. Другим природним кандидатом є тестові середовища: помилка коштує небагато, а економію видно одразу.

Чи треба переносити все одразу? Ні – і зазвичай не варто. Типовий шлях – це гібридна модель: частина систем залишається локально, частина (резервні копії, сховище даних, тимчасові середовища) працює в хмарі. Міграцію продакшн-застосунків планують окремо, після здобуття першого досвіду.

Де фізично зберігаються мої дані? У постачальника – тому локація центрів обробки даних – це питання, яке варто поставити перед підписанням договору, особливо з огляду на GDPR і галузеві вимоги. WebDisk – це польська хмара: дані ми зберігаємо в Польщі, що полегшує відповідність GDPR і галузевим вимогам.

Підсумок

Хмарні послуги найкраще оцінювати не за гаслами, а за сценаріями: хостинг, що масштабується разом із трафіком; резервне копіювання, яке замикає правило 3-2-1; сховище даних, що росте без заміни обладнання; тестові середовища на години; запас потужності на сезонний пік. Кожен із них можна впровадити окремо – і кожен окремо можна порахувати. Хочете перевірити, який має сенс у вашій компанії? Напишіть нам – допоможемо підібрати точку старту.