# Хмара ## Що це таке Хмара, або хмарні обчислення (англійською cloud computing), — це оренда комп'ютерів, яких орендар ніколи не побачить: постачальник володіє будівлями, електроживленням і обладнанням, а клієнт вмикає й вимикає сервери, сховища та мережі через вебконсоль або API і платить за те, що використав. Попри назву, кожне «хмарне» навантаження працює на цілком фізичній машині в дата-центрі. Різниця лише в тому, що цю машину купив хтось інший і здає її частинами багатьом клієнтам одночасно. Точне визначення дає американський Національний інститут стандартів і технологій, NIST. Його спеціальна публікація 800-145, яку написали Пітер Мелл і Тімоті Гранс і яка вийшла у вересні 2011 року, описує хмарні обчислення як модель мережевого доступу на вимогу до спільного пулу конфігурованих обчислювальних ресурсів, які можна швидко виділити й звільнити з мінімальними зусиллями на керування. Документ називає п'ять обов'язкових ознак. Самообслуговування на вимогу: новий сервер з'являється без розмови з людиною. Широкий мережевий доступ: до сервісу звертаються через мережу зі звичайних пристроїв. Об'єднання ресурсів: клієнти ділять обладнання постачальника і зазвичай обирають країну чи дата-центр, а конкретну стійку — ні. Швидка еластичність: потужність зростає і зменшується разом із попитом. Вимірюваний сервіс: споживання обліковується, і саме це робить можливим рахунок за годину чи за гігабайт. Ці п'ять ознак добре працюють як тест. Виділений сервер, орендований на рік, який змінюють через заявку в підтримку і за який платять фіксовану суму, проходить лише кілька з них. Це хостинг, часто вдалий вибір, але інший договір з іншою економікою. Той самий документ поділяє хмарні сервіси на три моделі. В інфраструктурі як сервісі (IaaS) клієнт орендує віртуальні машини, диски й мережі та сам оновлює на них операційну систему. У платформі як сервісі (PaaS) клієнт розгортає свій код у середовищі виконання постачальника. У програмному забезпеченні як сервісі (SaaS) клієнт користується готовою програмою, наприклад вебпоштою. До них додано чотири моделі розгортання: публічна хмара, яку може орендувати будь-хто; приватна, створена для однієї організації і, можливо, розміщена в її власних приміщеннях; спільнотна, яку ділять організації зі спільними потребами; і гібридна, де дві чи більше хмар пов'язані так, що дані й застосунки можуть переходити між ними. Найвідоміші публічні хмари — великі платформи на кшталт AWS, Azure і Google Cloud, а поруч із ними менші постачальники продають звичайні віртуальні машини за простішими цінами. ## Чому це важливо Хмара перетворює купівлю на поточні витрати, і в цьому вже більша частина рішення. Купити сервери означає заплатити наперед за потужність, розраховану на здогадку про найзавантаженіший день наступного року. Орендувати означає щомісяця платити за те, що ввімкнено, з правом змінити відповідь наступного тижня. Для нового продукту чи сезонного бізнесу така гнучкість варта надбавки. Для системи, яка три роки працює в тому самому розмірі, надбавку й далі стягують, хоча гнучкістю давно ніхто не користується. Друге рішення — наскільки високо в стеку орендувати. Віртуальна машина схожа на сервер, який команда вже розуміє, і її можна перенести до іншого постачальника, маючи трохи більше, ніж копію диска. Керована база даних, безсерверна функція чи пропрієтарне сховище даних знімають з команди роботу, але кожна з них водночас стає частиною застосунку, написаною під інтерфейс однієї компанії. Корисна звичка — знати, скільки коштуватиме відмова від кожного керованого сервісу, і приймати цю ціну свідомо, а не дізнаватися про неї під час підвищення цін. Третє — відповідальність. Орендуючи обладнання, клієнт передає постачальникові будівлю, живлення і гіпервізор. Хто може увійти, які порти відкриті і чи є в даних копія деінде, лишається на боці клієнта. Великі постачальники публікують модель спільної відповідальності, яка проводить цю межу, і в кожній версії облікові записи, конфігурація та дані лежать на боці клієнта. ## Як це виглядає на практиці Для одного міжнародного клієнта головним питанням був рахунок. [Його налаштування AWS було надлишковим і накопичило сервіси, якими вже ніхто не користувався](/uk/portfolio/optimized-budget-costs-10-times-with-zero-loss-56/), тож щомісячні витрати давно відірвалися від реальних потреб бізнесу. Робота почалася з аудиту того, що насправді працює, прибрала дубльовані й непотрібні сервіси і підігнала решту під реальний попит замість розрахунків на найгірший сценарій. Потім навантаження поетапно перенесли з AWS на економніший хостинг, щоб бізнес працював і під час переїзду. Витрати скоротилися приблизно у 10 разів без жодної втрати продуктивності. Власний робочий хост компанії лежить на протилежному кінці шкали. [Це одноядерний хмарний примірник із 512 МБ пам'яті та 10 ГБ диска](/uk/portfolio/ran-the-whole-company-on-one-512mb-host-109/), з яких придатні до вжитку близько 464 МБ, і він обслуговує TLS для семи доменів, git-фордж, onion-службу Tor, сервери Gemini і Gopher, зашифровані резервні копії та блокування вторгнень. Хмарна машина такого розміру не лишає місця для здогадок, тож питання, чи вмістить вона ще й onion-службу, вирішувала доба зразків: запас доступної пам'яті весь час перевищував приблизно 310 МБ із 464, своп — на рівні 2,6 відсотка, а процесор 99,7 відсотка часу простоював. Машина коштує на місяць менше за обід, а пошту свідомо тримають поза нею, бо поштовому серверу потрібен запас, який цей хост уже витратив. Оренда означає ще й довіру до копії постачальника, доки цю довіру не замінить щось перевірене. Усе, що зберігає компанія, стояло на одному хмарному примірнику, і [його провайдерський знімок був усією позицією відновлення](/uk/portfolio/built-encrypted-backups-with-a-monthly-restore-drill-114/). Цей знімок жив у межах того ж хмарного облікового запису, під яким працював і сам примірник, компанія його не шифрувала, а відновлювати з нього не пробував ніхто. Тепер копії залишають цю хмару: за таймером systemd restic шифрує знімок, прибирає з нього дублікати й через SFTP передає його в сховище іншого провайдера, потім підрізає старі знімки і перевіряє цілісність, а перемикач мертвої руки отримує сигнал лише в разі успіху. Раз на місяць навчання з відновлення витягує відомий файл і порівнює його, тож перевіряється саме відновлення. ## Де виникають проблеми Хмари ламаються рідше, ніж звички довкола них, і типові проблеми повільні, тихі й дорогі. **Рахунок росте, а продукт лишається того самого розміру.** Ресурси накопичуються: тестовий сервер, що працює після завершення тесту, диск, за який досі платять після видалення його машини, знімки, які зберігають вічно, балансувальник навантаження перед порожнім місцем. Вивантаження даних від постачальника чи між його регіонами теж тарифікується, тож журнали й резервні копії, що перетинають ці межі, оплачуються за кожну копію. Позначайте кожен ресурс тегами з власником і призначенням, налаштуйте сповіщення про бюджет і раз на місяць читайте рахунок рядок за рядком. **Потужність розраховують на день, який так і не настає.** Розмір машини обирають один раз, під час запуску, з огляду на найгірший сценарій, і ця здогадка переживає тих, хто її зробив. Виміряйте, скільки система споживає за звичайний і за напружений тиждень, оберіть розмір із запасом, і нехай автомасштабування зменшує потужність так само охоче, як збільшує. **Знімок постачальника вважають резервною копією.** Він лежить у тому самому обліковому записі, за тими самими обліковими даними і в тієї самої компанії, що й машина, яку він захищає, тож викрадений пароль чи заблокований обліковий запис забирають сервер разом із його єдиною копією. Справжня резервна копія лежить під іншими обліковими даними, бажано в іншого постачальника, зашифрована ключем, якого той постачальник ніколи не мав, і її відновлюють за розкладом. **Безпека лишається там, де її залишили налаштування за замовчуванням.** Типові проломи — правило брандмауера, що впускає SSH з усього інтернету, довготривалий ключ доступу в dotfiles розробника, обліковий запис адміністратора для щоденної роботи і бакет сховища, відкритий для однієї демонстрації. Надавайте найменший доступ, достатній для завдання, обирайте короткочасні облікові дані, вимагайте другий фактор для кожного входу людини і тримайте конфігурацію в коді, щоб кожну її зміну хтось переглядав. **Переїзд вимагає переписати застосунок.** Кожна пропрієтарна черга, платформа функцій і діалект бази даних прив'язують код до одного постачальника трохи міцніше. Тримайте ядро системи на відкритих інтерфейсах там, де це дешево, наприклад на PostgreSQL, контейнерах і звичайних віртуальних машинах, і записуйте ціну виходу для кожного пропрієтарного сервісу в момент, коли його впроваджують. ## Що почитати далі - [The NIST Definition of Cloud Computing](https://csrc.nist.gov/pubs/sp/800/145/final) — коротке визначення з п'ятьма ознаками, трьома моделями сервісу і чотирма моделями розгортання. - [Guidelines on Security and Privacy in Public Cloud Computing](https://csrc.nist.gov/pubs/sp/800/144/final) — що організації варто зважити, перш ніж переносити дані, застосунки та інфраструктуру до публічного постачальника. - [NIST Cloud Computing Reference Architecture](https://www.nist.gov/publications/nist-cloud-computing-reference-architecture) — архітектура й таксономія, які NIST збудував на своєму визначенні, з переліком сторін хмарної угоди. - [FinOps Framework](https://www.finops.org/framework/) — модель FinOps Foundation, що робить хмарні витрати спільною практикою інженерів і фінансистів.