Хмари подібні до магічної скриньки — задаєш, що тобі потрібно, і ресурси просто з'являються звідки. Віртуальні машини, бази даних, мережа – все це належить лише тобі. Існують й інші хмари, але у своєму Всесвіті ти одноосібний правитель. Ти впевнений, що завжди отримаєш необхідні ресурси, ні з ким не зважаєш і самостійно визначаєш, якою буде мережа. Як улаштована ця магія, яка змушує хмару еластично виділяти ресурси та повністю ізолювати тенанти один від одного?
Хмара AWS – це мегасуперскладна система, яка еволюційно розвивається з 2006 року. Частина цього розвитку застав Василь Пантюхін - Архітектор Amazon Web Services. Як архітектор він бачить зсередини не лише кінцевий результат, а й складнощі, які долає AWS. Чим більше розуміння роботи системи, тим більша довіра. Тож Василь поділиться секретами хмарних сервісів AWS. Під катом пристрій фізичних серверів AWS, еластична масштабованість БД, кастомна база даних Amazon та методи підвищення продуктивності віртуальних машин з одночасним зменшенням їхньої ціни. Знання архітектурних підходів Amazon допоможе ефективніше використовувати сервіси AWS і, можливо, дасть нові ідеї щодо побудови власних рішень.
Про спікера: Василь Пантюхін () починав Unix-адміном в.ru-компаніях, 6 років займався великими залозками Sun Microsystem, 11 років проповідував дата-центричність світу в EMC. Природним шляхом еволюціонував у приватні хмари, а 2017 року подався до публічних. Зараз технічними порадами допомагає жити та розвиватися у хмарі AWS.
Дисклеймер: все, що нижче – це особиста думка Василя, і вона може не співпадати з позицією Amazon Web Services. доповіді, на основі якої створено статтю, доступна на нашому YouTube-каналі.
Чому я розповідаю про пристрій Amazon
Моя перша машина була з "ручкою" - на механічній КПП. Це було чудово через відчуття, що я можу керувати машиною та повністю контролювати її. Ще мені подобалося, що я бодай приблизно розумію принцип її роботи. Природно, я представляв пристрій коробки досить примітивно приблизно як коробку передач на велосипеді.
Все було чудово, окрім одного — стояння у пробках. Начебто сидиш і нічого не робиш, але постійно перемикаєш передачі, натискаєш на зчеплення, газ, гальмо — від цього реально втомлюєшся. Проблема заторів частково вирішилася, коли в сім'ї з'явилася машина на автоматі. За кермом з'явився час про щось подумати, послухати аудіокнигу.
Ще в моєму житті з'явилася загадка, бо я загалом перестав розуміти, як працює моя машина. Сучасний автомобіль – це складний пристрій. Машина адаптується одночасно до десятків різних параметрів: натискання на газ, гальмо, стиль водіння, якість дороги. Я вже не розумію, як це працює.
Коли я почав займатися хмарою Amazon, це теж було для мене таємницею. Тільки ця таємниця на порядок вища, тому що в машині один водій, а в AWS їхні мільйони. Всі користувачі одночасно керують, натискають на газ та гальмо. Дивно, що вони їдуть туди, куди хочуть — це диво для мене! Система автоматично адаптується, масштабується та еластично підлаштовується під кожного користувача так, що йому здається, що він один у цьому Всесвіті.
Магія трохи розвіялася, коли згодом я прийшов працювати архітектором в Amazon. Я побачив, з якими проблемами ми стикаємося, як вирішуємо, як розвиваємо сервіси. Зі зростанням розуміння роботи системи з'являється більше довіри до сервісу. Тому я хочу поділитися картиною того, що під капотом біля хмари AWS.
Про що поговоримо
Я вибрав диверсифікований підхід - відібрав 4 цікаві сервіси, про які варто поговорити.
Оптимізація серверів. Ефемерні хмари з фізичним втіленням: фізичні дата-центри, де стоять фізичні сервери, які гудуть, гріються та блимають лампочками.
Серверлес-функції (Lambda) - напевно, наймасштабніший сервіс у хмарі.
Масштабування бази даних. Розповім про те, як ми будуємо свої власні масштабовані БД.
Масштабування мережі. Остання частина, де відкрию пристрій нашої мережі. Це чудова річ – кожен користувач хмари вважає, що він у хмарі один і взагалі не бачить інших тенантів.
Примітка. У цій статті йдеться про оптимізацію серверів та масштабування БД. Масштабування мережі розглянемо у наступній статті. Де ж серверлес-функції? Про них вийшло окреме розшифрування «». У ній розказано про кілька різних способів масштабування, і докладно розібрано рішення Firecracker – симбіоз найкращих якостей віртуальної машини та контейнерів.
сервери
Хмара ефемерна. Але ця ефемерність все ж має фізичне втілення — сервери. Спочатку їхня архітектура була класичною. Стандартний x86 чіпсет, мережеві карти, Linux, гіпервізор Xen, на якому запускалися віртуальні машини.
У 2012 році така архітектура цілком справлялася зі своїми завданнями. Xen - чудовий гіпервізор, але з одним серйозним недоліком. У нього достатньо високі накладні витрати на емуляцію пристроїв. При появі нових швидших мережних карток або дисків SSD ці накладні витрати стають надто високими. Як же упоратися з цією проблемою? Вирішили працювати одразу на двох фронтах. оптимізувати і залізо, і гіпервізор. Завдання дуже серйозне.
Оптимізація заліза та гіпервізора
Зробити все одразу і добре не вийде. Що таке «добре» спочатку теж було незрозуміло.
Вирішили застосувати еволюційний підхід – міняємо один важливий елемент архітектури та кидаємо його у продакшн.
Наступаємо на всі граблі, вислуховуємо скарги та пропозиції. Потім змінюємо іншу компоненту. Так, невеликими інкрементами кардинально змінюємо всю архітектуру на основі зворотного зв'язку від користувачів та підтримки.
Перетворення розпочалися 2013 р. із найскладнішого — мережі. У С3 Інстанси до стандартної мережевої карти додали спеціальну карту Network Accelerator. Вона підключалася буквально коротким loopback кабелем на передній панелі. Негарно, але у хмарі не видно. Зате пряма взаємодія із залізом принципово покращила jitter та пропускну спроможність мережі.
Далі вирішили зайнятися покращенням доступу до блокового зберігання даних EBS - Elastic Block Storage. Це комбінація мережі та сховища. Складність у цьому, що й на ринку існували карти Network Accelerator, можливості просто купити залізо Storage Accelerator був. Тому ми звернулися до стартапу Лабораторії Аннапурниякий розробив для нас спеціальні чіпи ASIC. Вони дозволили підключати віддалені томи EBS як пристрої NVMe.
В інстансах C4 ми вирішили два завдання. Перша — реалізували заділ на майбутнє перспективною, але новою на той момент технологією NVMe. Друга – значно розвантажили центральний процесор перенесенням обробки запитів до EBS на нову карту. Вийшло вдало, тому зараз Annapurna Labs – частина Amazon.
До листопада 2017 р. ми зрозуміли, що настав час змінювати і сам гіпервізор.
Новий гіпервізор розробили на основі доопрацьованих модулів ядра KVM.
Він дозволив важливо скоротити накладні витрати на емуляцію пристроїв і працювати безпосередньо з новими ASIC. Інстанси С5 були першими віртуалками, під капотом яких працює новий гіпервізор. Ми назвали його Nitro.
Еволюція інстансів на часовій шкалі.
Всі нові типи віртуальних машин, які з'явилися з листопада 2017 року, працюють на цьому гіпервізорі. Залізні Bare Metal інстанси не мають гіпервізора, Але їх також називають Nitro, тому що вони використовують спеціалізовані Nitro-карти.
За наступні два роки кількість типів Nitro-інстансів перевищила кілька десятків: A1, C5, M5, T3 та інші.
Типи інстансів.
Як влаштовані сучасні Nitro-машини
У них є три основні компоненти: Nitro-гіпервізор (про нього говорили вище), чіп безпеки та Nitro-карти.
Чіп безпеки інтегрований у материнську плату. Він контролює безліч важливих функцій, наприклад, контроль завантаження хостової ОС.
Nitro-картки їх існує чотири типи. Всі вони розроблені Annapurna Labs та базуються на загальних ASIC. Частина їх прошивки також загальна.
Чотири типи Nitro-карт.
Одна з карток призначена для роботи з мережеюVPC. Саме вона видно у віртуалках як мережева карта ENA — Elastic Network Adaptor. Також вона інкапсулює трафік під час передачі його через фізичну мережу (про це поговоримо в другій частині статті), контролює файрвол Security Groups, відповідає за маршрутизацію та інші мережеві речі.
Окремі карти працюють із блочним зберіганням EBS та дисками, які вбудовані на сервер. Гостьовій віртуалці вони видаються як NVMe-адаптери. Також вони відповідають за шифрування даних та моніторинг дисків.
Система Nitro-карт, гіпервізора та чіпа безпеки об'єднана в мережу SDN або Програмно визначена мережа. За керування цією мережею (Control Plane) відповідає карта-контролер.
Звісно, ми продовжуємо розробку нових ASIC. Наприклад, наприкінці 2018 р. випустили чіп Inferentia, який дозволяє ефективніше працювати із завданнями машинного навчання.
Чіп Inferentia Machine Learning Processor.
Масштабована база даних
Традиційна база даних має шарувату структуру. Якщо сильно спростити, виділяються такі рівні.
- SQL — на ньому працюють диспетчери клієнтів та запитів.
- Забезпечення транзакцій — тут все зрозуміло, ACID і таке інше.
- Кешування, що забезпечується буферними пулами.
- Логування - Забезпечує роботу з redo-логами. У MySQL вони називаються Bin Logs, у PosgreSQL - Write Ahead Logs (WAL).
- Зберігання - Безпосередньо запис на диск.
Шарувата структура бази даних.
Існують різні способи масштабування баз даних: шардування, архітектура Shared Nothing, диски, що розділяються.
Однак, всі ці методи зберігають ту саму монолітну структуру бази даних. Це помітно обмежує масштабування. Щоб вирішити цю проблему, ми розробили свою власну базу даних. Амазонська Аврора. Вона сумісна з MySQL та PostgreSQL.
Амазонська Аврора
Основна архітектурна ідея – відщепити рівні зберігання та логування від основної БД.
Забігаючи наперед скажу, що рівень кешування ми теж зробили незалежним. Архітектура перестає бути монолітом, і ми отримуємо додаткові ступені свободи у масштабуванні окремих блоків.
Рівні логування та зберігання відокремлені від бази даних.
Традиційна СУБД записує дані на систему зберігання як блоків. В Amazon Aurora ми створили "розумне" сховище, яке може розмовляти мовою redo-логів. Усередині себе сховище перетворює логи на блоки даних, стежить за їх цілісністю та автоматично бекапіт.
Цей підхід дозволяє реалізувати такі цікаві речі як клонування. Воно працює принципово швидше та економічніше за рахунок того, що не вимагає створення повної копії всіх даних.
Рівень зберігання реалізований як розподіленої системи. Вона складається з великої кількості фізичних серверів. Кожен redo-лог обробляється та зберігається одночасно шістьма вузлами. Це забезпечує захист даних та розподіл навантаження.
Масштабування читання можна забезпечити з допомогою відповідних реплік. Розподілене сховище усуває необхідність синхронізації між головним інстансом БД, через який ми записуємо дані, та іншими репліками. Актуальні дані гарантовано доступні для всіх реплік.
Єдина проблема – кешування старих даних на репліках читання. Але це завдання вирішується передачею всіх redo-логів на репліки з внутрішньої мережі. Якщо лог в кеші, він позначається як некоректний і перезаписується. Якщо в кеші його немає, він просто відкидається.
Зі сховищем розібралися.
Як масштабувати рівні СУБД
Тут горизонтальне масштабування зробити набагато складніше. Тому підемо второваною доріжкою класичного вертикального масштабування.
Припустимо, що ми маємо додаток, який спілкується з СУБД через майстер-ноду.
При вертикальному масштабуванні виділяємо нову ноду, яка матиме більше процесорів і пам'яті.
Далі перемикаємо програму зі старої майстер-ноди на нову. Виникають проблеми.
- Це вимагатиме помітного даунтайму програми.
- Нова майстер-нода матиме холодний кеш. Продуктивність БД буде максимальною тільки після прогріву кешу.
Як покращити ситуацію? Поставити проксі між програмою та майстер-нодою.
Що це нам дасть? Тепер усі програми не потрібно вручну перенаправляти на нову ноду. Перемикання можна зробити під проксі і при цьому важливо швидше.
Здається, що проблему вирішено. Але ні, ми все ще страждаємо від необхідності прогрівання кешу. До того ж, постала нова проблема — тепер проксі це потенційна точка відмови.
Підсумкове рішення з Amazon Aurora serverless
Як ми вирішили ці проблеми?
Залишили проксі. Це не якийсь окремий інстанс, а цілий розподілений флот проксі, через який додатки підключаються до БД. Будь-яку з нід у разі виходу з ладу можна замінити практично миттєво.
Додали пул теплих нід різного розміру. Тому при необхідності виділення нової ноди більшого чи меншого розміру вона одразу доступна. Не слід чекати, коли вона завантажиться.
Весь процес масштабування контролюється спеціальною системою моніторингу. Моніторинг постійно стежить за станом поточної майстер-ноди. Якщо він виявляє, наприклад, що навантаження на процесор досягло критичної величини, то повідомляє пул теплих інстансів про необхідність виділення нової ноди.
Розподілені проксі, теплі інстанси та моніторинг.
Нода необхідної потужності доступна. На неї копіюються буферні пули, і система починає чекати на безпечний момент для перемикання.
Зазвичай момент для перемикання настає досить швидко. Тоді комунікація між проксі та старою майстер-нодою припиняється, всі сесії перемикаються на нову ноду.
Робота з базою даних поновлюється.
На графіку видно, що призупинення справді дуже коротке. На синьому графіку навантаження, а на червоних сходах моменти масштабування. Короткочасні провали в синьому графіку якраз і є коротка затримка.
До речі, Amazon Aurora дозволяє зовсім заощадити та вимкнути БД, коли вона не використовується, наприклад, у вихідні. Після зупинки навантаження БД поступово зменшує свою потужність і якийсь час відключається. Коли навантаження повернеться, воно знову плавно підніметься.
У наступній частині розповіді про пристрій Amazon поговоримо про масштабування мережі. Підписуйтесь і слідкуйте за оновленнями, щоб не пропустити цю статтю.
На Василь Пантюхін виступить із доповіддю «». Які патерни проектування розподілених систем використовують розробники Amazon, які бувають причини відмов сервісів, що таке Cell-based architecture, Constant Work, Shuffle Sharding буде цікаво. До конференції менше місяця . 24 жовтня - остаточне підвищення цін.
Джерело: habr.com