Вікіпедія

Автомасштабування

Метод оптимізації навантаження, який використовується в хмарних обчисленнях

Автомасштабування або автоматичне масштабування - це метод, який використовується в хмарних обчисленнях, при якому кількість обчислювальних ресурсів у межах серверної ферми, яка зазвичай вимірюється за кількістю активних серверів, автоматично масштабується в залежності від навантаження на ферму. Він тісно пов'язаний з ідеєю балансування навантаження і ґрунтується на ній.[1][2]

Переваги ред.

Автомасштабування має наступні переваги:

  • Для компаній, що працюють на власній інфраструктурі вебсервера, автомасштабування, як правило, означає, що деякі сервери можуть засинати під час низького завантаження, заощаджуючи витрати на електроенергію (а також витрати на воду, якщо вода використовується для охолодження машин).[3]
  • Для компаній, що використовують інфраструктуру, розміщену у хмарі, автомасштабування може означати нижчі рахунки, оскільки більшість постачальників хмарних послуг нараховують рахунок на основі загального використання, а не максимальної потужності.[4]
  • Навіть для компаній, які не можуть зменшити загальну обчислювальну потужність, яку вони використовують або оплачують, автомасштабування може допомогти, дозволяючи компанії працювати з меншими часовими навантаженнями на машинах, які звільняються автомасштабуванням під час низького трафіку.[5]
  • Рішення автомасштабування, наприклад, пропоновані Amazon Web Services, також можуть піклуватися про зміну хворих екземплярів і, отже, частково захищати від збоїв обладнання, мережі і застосунків.[6]
  • Автомасштабування може запропонувати більший час роботи і доступність в тих випадках, коли виробничі навантаження змінні і непередбачувані.

Автомасштабування відрізняється від постійного щоденного, щотижневого або річного циклу використання сервера тим, що воно реагує на фактичні шаблони використання і, таким чином, зменшує потенційний недолік наявності надто великої кількості серверів або надто великої кількості трафіку для завантаження. Наприклад, якщо трафік звичайно нижче в північ, то рішення статичного масштабування може запланувати занурити в сон деякі сервера, але це може призвести до простою вночі, коли люди більше використовують Інтернет (наприклад, через вірусні новини). З іншого боку, автомасштабування може обробляти неочікувані скачки трафіку краще.[3][7]

Термінологія ред.

У наведеному нижче списку ми використовуємо термінологію, що використовується у Amazon Web Services (AWS).[8] Проте, вказуються також альтернативні назви і термінологія, тому що специфічні службам Amazon назви не використовується для позначень.

Назва (використовується в AWS, якщо не зазначено інше) Значення Альтернативні назви (використовуються в Google Cloud Platform, Microsoft Azure, or other platforms)
Екземпляр Єдиний сервер або машина, що входить до складу групи машин, які підлягають автомасштабуванню
Група автомасштабування Набір екземплярів, що підлягають автомасштабуванню, з усіма відповідними політиками та інформацією про стан Група керованих екземплярів (Google Cloud Platform)
Розмір Кількість екземплярів, що в даний час входять до групи автомасштабування
Бажана потужність (або бажаний розмір) Кількість екземплярів, які група автомасштабування повинна мати в будь-який момент часу. Якщо наявний розмір менше, ніж потрібний розмір, група автомасштабування намагатиметься запустити (забезпечити та приєднати) нові екземпляри. Якщо розмір більше, ніж потрібний розмір, група автомасштабування буде намагатися видалити (від'єднати та припинити) екземпляри
Мінімальний розмір  Ряд екземплярів, нижче яких бажана потужність не допускається


Максимальний розмір Ряд екземплярів, вище яких бажана потужність не може підвищуватися 
Метрика Вимір (наприклад, використання ЦП, використання пам'яті, використання мережі), пов'язаний з групою автомасштабування, для якої періодично створюється тимчасової ряд точок даних. Пороги для показників можуть використовуватися для установки політик автомасштабування. Метрики можуть бути засновані на агрегатах показників для екземплярів групи автомасштабування або на основі балансувальників навантаження, пов'язаних з групою автомасштабування
Політика масштабування (або політика автомасштабування) Політика, яка показує зміну бажаної ємності групи автомасштабування (або іноді її мінімальний і максимальний розмір) у відповідь на метрики, що перетинають певні порогові значення. Політики масштабування можуть мати пов'язані періоди перезарядки, які запобігають появі додаткових дій масштабування відразу після певної дії. Зміни в бажаної ємності можуть бути інкрементальними (збільшення або зменшення на певне значення) або можуть вказувати нове значення необхідної ємності. Політики, які збільшують бажану пропускну здатність, називаються «scaling out» або «scaling up», а політики, які зменшують бажану ємність, називаються «scaling in» або «scaling down»
Перевірка здоров'я Спосіб групи автомасштабування для визначення, чи правильно працюють екземпляри, прикріплені до неї. Перевірка працездатності може бути заснована на тому, чи існує екземпляр і доступний він, або на тому, що екземпляр все ще зареєстрований і перебуває на службі з відповідним балансувальником навантаження
Стартова компоновка  Опис параметрів і сценаріїв, які використовуються при запуску нового екземпляра. Сюди входять тип екземпляра, варіанти покупки (наприклад, спот за запитом у разі AWS), можливі зони доступності для запуску, машинне зображення і сценарії для запуску при старті Шаблон екземпляра

(Google Cloud Platform)

Ручне масштабування Масштабна дія виконана вручну 
Заплановане масштабування  Політика масштабування, яка виконується в певний час, наприклад, час дня чи тижня, місяць або рік.

Розвиток ред.

Amazon Web Services (AWS) ред.

 
Auto-scaling

Amazon Web Services запустила сервіс Amazon Elastic Compute Cloud (EC2) у серпні 2006 року, який дозволив розробникам програмно створювати та припиняти дії екземплярів (машин).[9][10] Під час першого запуску AWS не пропонував автомасштабування, але здатність програмно створювати та припиняти екземпляри дали розробникам можливість писати власний код для автомасштабування.

Незалежне програмне забезпечення автомасштабування для AWS почало з'являтися приблизно в квітні 2008 року. До них входили інструменти від  Scalr[11] та RightScale. RightScale був використаний Animoto, який зміг обробити трафік Facebook шляхом прийняття автомасштабування.[12][13]

18 травня 2009 року Amazon запустив власну функцію автомасштабування у парі з Elastic Load Balancing, як частину Amazon Elastic Compute Cloud.[14] Автомасштабування тепер є невід'ємним компонентом пропозиції Amazon EC2.[15][16]. Автомасштабування на Amazon Web Services здійснюється через веббраузер або інструментом командної строки.[17]

Постачальник відео-замовлень Netflix документально підтвердив, що використовує автомасштабування вебслужб Amazon, щоб задовольнити свої дуже різноманітні споживчі потреби. Вони виявили, що агресивне масштабування і затримка з обережним зменшенням масштабів служили своїм цілям безвідмовної роботи та швидкості реагування..[7]

У статті для TechCrunch, Зев Ладерман, співзасновник і головний виконавчий директор Newvem, служба, яка допомагає оптимізувати інфраструктуру хмарних технологій AWS, рекомендував початковим компаніям використовувати автомасштабування, щоб забезпечити низьку вартість своїх вебсервісів Amazon.[4] 

Різні керівництва з найкращої практики використання AWS дозволяють використовувати функцію автомасштабування, навіть якщо навантаження не є змінним. Це пояснюється тим, що автомасштабування пропонує ще дві переваги: автоматичну заміну будь-яких екземплярів, які з будь-якої причини стають нездоровими (такі як апаратні збої, збій мережі чи помилки програми) та автоматичне заміщення штучних екземплярів, які перериваються через ціну або потужність; приводячи до того, що томубільш доцільно використовувати випадкові екземпляри для виробничих цілей.[6][18][19] Внутрішня найкраща практика Netflix вимагає, щоб кожен екземпляр знаходився в групі автомасштабування, а її мавпа відповідності припиняє будь-який екземпляр не в групі автомасштабування, щоб забезпечити виконання цієї найкращої практики.[20]

Microsoft's Windows Azure ред.

27 червня 2013 року Microsoft оголосила про те, що додала підтримку автомасштабування для своєї платформи хмарних обчислень Windows Azure.[21][22][23] Документація для цієї функції доступна на Microsoft Developer Network.[24][25]

Платформа Google Cloud ред.

17 листопада 2014 року Google Compute Engine оголосила публічну бета-версію своєї функції автомасштабування для використання в застосунках Google Cloud Platform.[26][27][28][29] Станом на березень 2015 року інструмент автомасштабування все ще знаходиться в бета-версії.[30]

Facebook ред.

У себе в блозі, в серпні 2014 року, інженер Facebook повідомив, що компанія почала використовувати автомасштабування, щоб зменшити витрати на енергію. У повідомленні блогу говорилося про зниження енергоспоживання на 27% за часів низького трафіку (близько півночі) та зниження споживання енергії на 10-15% за звичайний цілодобовий цикл.[3]

Альтернативи для автомасштабування ред.

Автомасштабування - це реактивний спосіб боротьби з масштабуванням трафіку: масштабування відбувається лише у відповідь на зміни в показниках в режимі реального часу. У деяких випадках, особливо коли зміни відбуваються дуже швидко, цей реактивний підхід до масштабування є недостатнім. Два інших види масштабування описані нижче. Рішення автомасштабування, такі як AWS, дозволяють використовувати ці типи масштабування з існуючими групами автомасштабування, навіть якщо вони концептуально дещо відрізняються від автомасштабування. 

Заплановане масштабування ред.

Це підхід до масштабування, коли зміни вносяться до мінімального розміру, максимального розміру або бажаної потужності групи автомасштабування у певні години дня. Масштабування за розкладом корисно, наприклад, якщо в певний час доби спостерігається певне збільшення чи зменшення навантаження на дорожній рух, але зміна занадто раптова для реакції автомасштабування. Групи автомасштабування AWS підтримують планове масштабування.[31]

Прогнозне масштабування ред.

Цей підхід до масштабування використовує інтелектуальну прогнозову аналітику. Ідея полягає в поєднанні останніх тенденцій з історичними даними, а також іншими видами даних для прогнозування використання в майбутньому та масштабу на основі цих прогнозів. Що стосується частин своєї інфраструктури та специфічних робочих навантажень, Netflix виявив, що Scryer, їх двигун аналітичного прогнозування, дав кращі результати, ніж автомасштабування Amazon. Зокрема, він був кращий для:[32][33]

  • Ідентифікації величезних сплесків попиту в найближчому майбутньому і отриманню потужності трохи наперед
  • Робота з великомасштабними відключеннями, такими як відмова усіх зон доступності та регіонів 
  • Робота зі змінними шаблонами трафіку, що забезпечує більшу гнучкість в швидкості масштабування або в залежності від типового рівня і швидкості зміни попиту в різний час доби

Дивись також ред.

Примітки ред.

  1. ↑ Above the Clouds: A Berkeley View of Cloud Computing (PDF). Berkeley EECS. 10 лютого 2009. Архів оригіналу (PDF) за 4 серпня 2019. Процитовано 21 березня 2015.
  2. ↑ Auto Scaling. Amazon Web Services. Архів оригіналу за 17 березня 2015. Процитовано 21 березня 2015.
  3. ↑ а б в Wu, Qiang (8 серпня 2014). Making Facebook’s software infrastructure more energy efficient with Autoscale. Facebook Code Blog. Архів оригіналу за 25 лютого 2017. Процитовано 21 березня 2015.
  4. ↑ а б Laderman, Zev (22 квітня 2012). The 10 Biggest Mistakes Made With Amazon Web Services. TechCrunch. Архів оригіналу за 25 вересня 2019. Процитовано 21 березня 2015.
  5. ↑ Park, Andrew; Denlinger, Darrell; Watson, Coburn (18 вересня 2015). Creating Your Own EC2 Spot Market. Netflix. Архів оригіналу за 1 травня 2017. Процитовано 16 грудня 2016.
  6. ↑ а б Wittig, Michael (26 грудня 2015). 5 AWS mistakes you should avoid. cloudonaut. Архів оригіналу за 25 вересня 2019. Процитовано 16 грудня 2016.
  7. ↑ а б Orzell, Greg; Becker, Justin (18 січня 2012). Auto Scaling in the Amazon Cloud. Netflix Tech Blog. Архів оригіналу за 9 березня 2017. Процитовано 21 березня 2012.
  8. ↑ What Is Auto Scaling?. Amazon Web Services. Архів оригіналу за 27 грудня 2017. Процитовано 16 грудня 2016.
  9. ↑ Cubrilovic, Nik (24 серпня 2006). Almost Exclusive: Amazon Readies Utility Computing Service. TechCrunch. Архів оригіналу за 25 вересня 2019. Процитовано 4 грудня 2016.
  10. ↑ Barr, Jeff (25 серпня 2006). Amazon EC2 Beta. Amazon Web Services Blog. Архів оригіналу за 25 грудня 2018. Процитовано 31 травня 2013.
  11. ↑ Work, Henry (3 квітня 2008). Scalr: The Auto-Scaling Open-Source Amazon EC2 Effort. TechCrunch. Архів оригіналу за 22 березня 2015. Процитовано 21 березня 2015.
  12. ↑ Howlett, Dennis (25 червня 2008). RightScale cloud management extends to MySQL. RightScale, which specializes in cloud computing management for the Amazon Web Services platform today announced support for MySQL Enterprise. The service, which goes live July 1, provides automated deployment, management and scaling, coupled with MySQL Enterprise premium-level support for large database applications. ZDNet. Архів оригіналу за 20 грудня 2016. Процитовано 16 грудня 2016.
  13. ↑ von Eicken, Thorsten (23 квітня 2008). Animoto's Facebook Scale-Up. Архів оригіналу за грудня 20, 2016. Процитовано 16 грудня 2016.
  14. ↑ Barr, Jeff (18 травня 2009). New Features for Amazon EC2: Elastic Load Balancing, Auto Scaling, and Amazon CloudWatch. Amazon Web Services. Архів оригіналу за 25 вересня 2019. Процитовано 15 червня 2016.
  15. ↑ What is autoscaling?. TechTarget. Архів оригіналу за 29 квітня 2019. Процитовано 21 березня 2015.
  16. ↑ Barr, Jeff (30 липня 2014). Auto Scaling Update – Lifecycle Management, Standby State, and DetachInstances. Amazon Web Services (official blog). Архів оригіналу за 25 вересня 2019. Процитовано 21 березня 2015.
  17. ↑ Auto Scaling Command Line Tool. Amazon Web Services (community-edited page). Архів оригіналу за 5 жовтня 2016. Процитовано 21 березня 2015.
  18. ↑ Adams, Rich (3 лютого 2014). AWS Tips I Wish I'd Known Before I Started. A collection of random tips for Amazon Web Services (AWS) that I wish I'd been told a few years ago, based on what I've learned by building and deploying various applications on AWS. Архів оригіналу за 25 травня 2019. Процитовано 16 грудня 2016.
  19. ↑ How to Use Amazon EC2 Spot Instances. wikiHow. Архів оригіналу за 25 вересня 2019. Процитовано 16 грудня 2016.
  20. ↑ The Netflix Simian Army. Netflix. 19 липня 2011. Архів оригіналу за 20 березня 2017. Процитовано 5 грудня 2016.
  21. ↑ Lardinois, Frederic (27 червня 2013). Microsoft Adds Auto Scaling To Windows Azure. TechCrunch. Архів оригіналу за 25 вересня 2019. Процитовано 21 березня 2015.
  22. ↑ Microsoft to add autoscaling, alerts to Windows Azure. ZDNet. 27 червня 2013. Архів оригіналу за 20 грудня 2016. Процитовано 21 березня 2015.
  23. ↑ Butler, Brandon (7 серпня 2013). Google, Microsoft play catch up to Amazon, add load balancing, auto-scaling to their clouds. Network World. Архів оригіналу за 18 травня 2018. Процитовано 21 березня 2015.
  24. ↑ Autoscaling Guidance. Microsoft Developer Network. Архів оригіналу за 11 лютого 2017. Процитовано 6 грудня 2017.
  25. ↑ The Autoscaling Application Block. Microsoft Developer Network. Архів оригіналу за 14 грудня 2017. Процитовано 21 березня 2015.
  26. ↑ Balejko, Filip (17 листопада 2014). Autoscaling, welcome to Google Compute Engine. Google Cloud Platform blog. Архів оригіналу за 5 березня 2016. Процитовано 21 березня 2015.
  27. ↑ Protalinski, Emil (17 листопада 2014). Google Compute Engine gets Autoscaler to adjust app resources based on varying traffic and workloads. VentureBeat. Архів оригіналу за 25 вересня 2019. Процитовано 21 березня 2015.
  28. ↑ Lardinois, Frederic (17 листопада 2014). Google Brings Autoscaling To Compute Engine. TechCrunch. Архів оригіналу за 25 вересня 2019. Процитовано 21 березня 2015.
  29. ↑ Verge, Jason (17 листопада 2014). Google Launches Autoscaling Beta on Compute Engine. Data Center Knowledge. Архів оригіналу за 25 вересня 2019. Процитовано 21 березня 2015.
  30. ↑ Autoscaler. Google Cloud Platform. Архів оригіналу за 12 вересня 2019. Процитовано 21 березня 2015.
  31. ↑ Scheduled Scaling. Amazon Web Services. Архів оригіналу за 24 грудня 2017. Процитовано 16 грудня 2016.
  32. ↑ Jacobson, Daniel; Yuan, Danny; Joshi, Neeraj. Scryer: Netflix’s Predictive Auto Scaling Engine. The Netflix Tech Blog. Netflix. Архів оригіналу за 29 квітня 2017. Процитовано 28 травня 2015.
  33. ↑ Autoscaling: How the Cloud Provides a Tremendous Boost. Morpheus. 2 листопада 2016. Архів оригіналу за 25 вересня 2019. Процитовано 16 грудня 2016.
Отримано з https://uk.wikipedia.org/w/index.php?title=Автомасштабування&oldid=39807822