The AWS Well-Architected Framework in Plain English (англійською)
Ясне, практичне пояснення всіх п'яти стовпів AWS Well-Architected Framework - словник, ключові поняття і фрази для перегляду архітектури і обговорення дизайну.
AWS Well-Architected Framework є стандартним посиланням для оцінки і поліпшення хмарних архітектур на AWS. Вона також широко вживається в інтерв’ю, оглядах архітектури і презентаціях клієнтів. Незалежно від того, чи ви проводите офіційний перегляд добре спроектованих проектів (WAR) або просто обговорюєте компроміси у проектуванні, цей словник і посібник з фраз допоможуть вам чітко і професійно передати концепції структури.
Що таке добре організована структура?
Well-Architected Framework (WAF) є набором найкращих архітектурних практик, організованих у п’ять стовпів - структурований спосіб оцінки хмарних архітектур проти перевірених принципів.
Спочатку розроблений AWS, рамка широко посилається в індустрії. Кожен з п’ яти стовпів має:
- ** Принципи проектування ** — керівні філософії
- Найкращі практики — конкретні рекомендації
- ** Питання для перегляду** — запит на самооцінку
«Перед тим, як ми подали архітектуру для схвалення виробництва, команда провела перегляд добре спроектованого. Ми знайшли три результати середнього ризику і один результат високого ризику в стовпі безпеки»
П’ять стовпів
Стовбур 1: Оперативна досконалість
** Операційна досконалість ** зосереджена на запуску і моніторингу систем для забезпечення бізнес-цінності, а також на постійному поліпшенні процесів і процедур.
** Ключові терміни: **
Operations as Code — визначення та керування інфраструктурою та операційними процедурами за допомогою коду (IaC, runbooks в автоматизації). “Ми кодифікували наші runbooks — розгортання і відновлення є скриптовими, а не ручними.”
** Runbook ** — документ (або автоматизований скрипт), який описує кроки для виконання певної операційної процедури. * « Будь- який інцидент повинен мати відповідний Runbook — без ручного сортування з пам’ яті. » *
** Playbook ** — комбінація підручників виконання вищого рівня для реагування на певний сценарій або тип події.
** Спостережливість ** — здатність розуміти внутрішній стан системи з її виходів. Включає журнали, метрики і сліди. “Без спостережливості, ми летимо на сліпо — ми не можемо сказати, чи система здорова.”
** Вносити часті, невеликі, оборотні зміни ** — основний принцип. Малі розгортання зменшують радіус вибуху і дозволяють швидше відновлювати. * “Ми доставляємо кожен день на основі API - кожен випуск є однією невеликою зміною, а не великим вибуховим розгортанням.” *
** Аналіз режиму відмови ** — активне виявлення того, що може піти не так, і планування на випадок цього. * “Ми провели аналіз режиму відмови перед сезоном піку — ми визначили три окремі точки відмови і розглянули дві з них.” *
Стовп 2: Безпека
** Безпека ** охоплює можливість захисту даних, систем і активів — а також виявлення, розслідування і відновлення після подій безпеки.
** Ключові терміни: **
Least Privilege — надання мінімальних прав, необхідних для роботи функції. “Наші функції Lambda мають ролі IAM, обмежені саме тим контейнером S3 і таблицею DynamoDB, які їм потрібні — нічого більше.”
** Глибокий захист ** — використовує декілька шарів контролю безпеки. Якщо один шар не спрацює, інші все ще захищають систему. * “Ми не покладаємося тільки на безпеку периметра мережі - ми також шифруємо дані в спокійному стані, застосовуємо MFA і перевіряємо введення на кожному кордоні послуги.” *
** Модель спільної відповідальності ** - AWS відповідає за безпеку * хмари (апаратне забезпечення, мережа, фізичне); клієнт відповідає за безпеку * в * хмарі (дані, ідентичність, застосування). * “Модель спільної відповідальності означає, що AWS забезпечує гіпервізор не звільняє нас від забезпечення наших S3-кубів.” *
** Шифрування у стані спокою / під час передачі ** — * « Всі конфіденційні дані слід зашифрувати у стані спокою за допомогою KMS — без винятків. » *
** Traceability ** — можливість відстежувати кожен виклик API і зміну налаштувань до ідентифікатора. CloudTrail, AWS Config і VPC Flow Logs дозволяють це. * “Ми маємо повний відстежуваність через CloudTrail - кожна дія IAM записується і попереджає про пожежу на підозрілих шаблонах.” *
Automated Security Testing — інтеграція перевірок безпеки в CI/CD. “Наша мережа включає SAST, сканування залежностей, і Checkov для безпеки IaC — ворота безпеки перед кожним розгортанням.”
Стовп 3: Надійність
** Надійність ** — це здатність робочого навантаження виконувати свою призначену функцію коректно і послідовно, а також швидко відновлюватися у разі невдачі.
** Ключові терміни: **
** Рекомендований час відновлення (RTO) ** — максимально допустимий час простою після аварії. * « Наш RTO — 4 години — нам потрібно повернутися до мережі протягом 4 годин після аварії. » *
Ціль точки відновлення (RPO) — максимально допустима втрата даних, виміряна за часом. “Наша RPO — 1 година — ми не можемо дозволити собі втратити більше однієї години даних транзакцій.”
High Availability (HA) — розробка систем для мінімізації часу простою, зазвичай через резервування. “База даних працює в режимі Multi-AZ HA — якщо первинна не працює, вторинна автоматично підвищується впродовж 60 секунд.”
** Ізоляція помилок ** — містить помилки, щоб запобігти їх каскадуванню. VPC, зони доступності, і мережі обслуговування з автоматичними виключачами всі реалізують ізоляцію помилок. * “Кожна AZ є межею ізоляції помилок - несправність в AZ-1 не повинна впливати на AZ-2.” *
Circuit Breaker — шаблон, який припиняє надсилання запитів до служби, що не працює, надаючи час для відновлення. “Ми реалізували автоматичні вимкнення на платіжній службі — якщо рівень помилок перевищує 50%, виклики короткого замикання на 30 секунд.”
** Chaos Engineering ** — навмисне введення помилок в контрольовані способи для тестування стійкості. * “Наша практика хаосної інженерії включає щомісячні ігрові дні, де ми імітуємо помилки AZ і відключення баз даних.” *
Multi-Region Architecture — розгортання в декількох регіонах AWS для найвищого рівня стійкості. *“Ядро платіжної служби є мульти-регіональною активною активною - повний регіональний відключення не вдарить нас вниз.” *
4-й етап: підвищення ефективності
** Ефективність продуктивності ** ефективно використовує ресурси хмари і підтримує ефективність при зміні попиту.
** Ключові терміни: **
** Правильний вибір ресурсів ** — вибір найкращого типу екземпляра, типу зберігання або служби для завантаження. * “Це пакетне завдання не потребує екземпляра загального призначення — воно вимагає багато процесорного часу і повинно виконуватися на типі, оптимізованому для обчислень.” *
Еластичність — можливість масштабування ресурсів вгору/вниз на основі попиту. “Ми використовуємо групи автоматичного масштабування — під час невикористаних годин флот масштабується вниз до 20% пікової кількості, що зменшує наш рахунок за обчислення.”
Затримка — час між запитом і відповіддю. “Затримка P99 є нашим KPI для цієї служби — ми прагнемо до менш ніж 200 мс на P99.”
** Пропускна здатність ** — швидкість обробки — запитів за секунду, повідомлень за секунду, байтів за секунду. * « Пропускна здатність конвеєра повинна обробляти 50 000 подій за секунду під час пікового навантаження ». *
Кешування — зберігання результатів дорогих операцій для повторного використання. “Ми додали рівень кешування Redis — частота влучень у кеш становить 85%, а завантаження бази даних зменшилося на 70%.”
CDN (Content Delivery Network) — кешування статичного контенту в краєвих місцях, близьких до користувачів. “Ми обслуговуємо статичні активи через CloudFront — глобальна затримка P50 зменшилася з 280 мс до 35 мс після переходу на CDN.”
Аналіз компромісів — балансування продуктивності проти вартості, послідовності або складності. “Існує компроміс між сильною послідовністю і швидкістю читання — ми обирали можливу послідовність для цього кешу.”
Підтримка 5: Оптимізація витрат
** Оптимізація витрат ** - це забезпечення бізнес-цінності за найнижчою можливою ціною.
** Ключові терміни: **
Див. повний словник: Список мов світу: Українська мова: опис мов
** Ключові додаткові терміни у контексті WAF: **
** Прийняти модель споживання ** - платити тільки за те, що ви використовуєте. Віддавайте перевагу безсерверним та керованим послугам, де це можливо. “Ми мігрували пакетні завдання до Lambda і Step Functions — вартість впала на 80%, тому що ми більше не платимо за неактивні обчислення.”
** Виміряти загальну ефективність ** - зрозуміти бізнес-цінність, що надається за витрачений долар. * “Ми відстежуємо вартість за транзакцією як наш економічний KPI - він повинен зменшуватися, коли ми масштабуємо.” *
Припиніть витрачати на недиференційоване важке навантаження — використовуйте управляні послуги замість будівництва інфраструктури з нуля. “Ми не запускаємо власну Kafka — MSK робить недиференційовану роботу, ми зосереджуємось на бізнес-логіці.”
The Well-Architected Review (англійською)
** Добре спроектований перегляд ** це структурована оцінка навантаження на роботу за запитаннями WAF. Він виробляє:
- ** Звіт про ризик ** — результати оцінені як високий, середній або низький ризик
- ** Елементи поліпшення ** — конкретні рекомендації з пріоритетом
- ** План ліквідації ** - графік для вирішення висновків високого ризику
** Корисні фрази для ВІЙНИ: **
«Це виявлення високого ризику — у нас немає автоматичного відключення, налаштованого для бази даних. Який план вирішити це до кінця Q2?»
“У нас три результати середнього ризику в опорі безпеки. Я приоритизую виявлення виконання MFA - все інше може бути частиною дорожньої карти наступного кварталу»
«The Well-Architected Review показав, що ми маємо сильну надійність, але значні можливості оптимізації витрат — приблизно 35% економії за рахунок правильного розміру і зарезервованих екземплярів»
Practice
Поглибте свій словниковий запас з хмарної архітектури за допомогою ** Набор упражнений Cloud FinOps ** і досліджуйте всі ресурси хмарної архітектури за допомогою ** Архітектурний стиль — класицизм **.