Як запобігти обіймові смерті на екземплярі EC2?

У мене в додатку iOS в магазині додатків, і нещодавно я отримав величезний приплив трафіку на свою цільову сторінку, розміщену на EC2, і призвів до того, що сторінка не відповідає, на щастя, мені вдалося відновити її, перезавантаживши та оновивши примірник до t2.medium.

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

Моя цільова сторінка та запуск програми iOS розміщуються в одному екземплярі.

Якщо ви хочете щось швидко розібрати без особливих знань, я рекомендую еластичну паску. Це ще одне додаток AWS, яке обробляє для вас конфігурацію балансира навантаження та масштабування екземплярів.

На додаток до балансира навантаження та екземплярів немає зайвих витрат, тому ви можете продовжувати використовувати екземпляри типу t2, але дозвольте еластичній шкалі розміру стільки, скільки захочете допомогти.

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

Я б рекомендував автоматичне масштабування, як згадувалося вище, з додаванням деяких сигналів CloudWatch, щоб почати процес автоматичного масштабування, коли конкретні пороги починають збільшуватися, а не тоді, коли це вже далеко минуло.

Наприклад; налаштуйте CloudWatch для моніторингу вашого сервера, коли процесор становить 50% або вище протягом 30 секунд або більше, запускайте процес автоматичного масштабування.

Це може бути не зовсім бездоганно, але це легко зробити через деякі онлайн-путівники та все, що можна налаштувати через GUI.

Крім того, якщо ваша цільова сторінка є статичною, чому б не розмістити її на вільному рівні t2.micro та використовувати інший вільний рівень t2.micro для свого додатка?

Я хотів би допомогти з цим, якщо ви шукаєте допомоги. Залежно від вашої сторінки, вам може взагалі не знадобитися ec2. Наприклад, якщо ви обслуговуєте щось статичне або JavaScript, його можна подавати з s3 з розповсюдженням хмарного фронту. Або ми можемо використовувати групу автоматичного масштабування, якщо це абсолютно необхідно.

Існує дві загальні стратегії боротьби зі скоками руху: збільшення потужностей та зниження витрат.

Підвищення пропускної здатності означає автоматичне масштабування, від якого всі були дуже схвильовані, коли публічні хмари вперше стали доступними. У самому основному сенсі це створить для вас більше веб-серверів на основі завантаження та додасть їх до балансиру навантаження, але оскільки це може бути більшим для управління, є і більш автоматичні рішення, як, наприклад, Elastic Beanstalk.

Проблема з автоматичним розширенням ємності полягає в тому, що його автоматизоване розширення рахунків - 10-кратний звичайний трафік означає, що 10-кратний сервер означає 10-кратну суму грошей, які потрібно заплатити. Ось чому, хоча це корисна стратегія, яку потрібно пам’ятати, я думаю, що слід завжди починати з того, як бачити, як можна обдурити.

Під обманом я маю на увазі кеш, який спирається на думку, що більшу частину часу ви можете давати користувачам застарілі дані, і вони не помітять, і це може заощадити вам величезну кількість часу. Уявіть, що у вас є сторінка, для якої ви вирішите, що це нормально, якщо вона застаріла п'ять секунд, і вона отримує 20 рек / с. Не кешуючи, ви обчислюєте цей розрахунок 1200 разів на хвилину, тоді як при кешуванні - лише 12. Ви можете бачити, як це може призвести до величезної зміни.

Звичайно, існує багато типів кешування, і успішний веб-сайт використовуватиме декілька з них. Але для вашого випадку використання є два досить хороших та простих варіанти.

Перший - зробити сайт повністю статичним. Це передбачає, що ви можете це зробити, але якщо зможете, то у вас просто Nginx обслуговує html безпосередньо, і він може обслуговувати тонни запитів без поту.

Якщо вам потрібен певний рівень динаміки, то хороший варіант кешування на повній сторінці. Nginx має певні можливості для цього, але мені дуже подобається Varnish через його гнучкість.

Який би варіант чи параметри ви не використовували, переконайтесь, що ви виконали тестування навантаження, щоб перевірити, чи правильно ви його встановили; іноді виправлення однієї плями відкриває нове вузьке місце.

Я хотів би поділитися нашим досвідом із AWS. Ми розгорнули наш додаток на EC2 і стикаємося з тією ж проблемою, а також високою вартістю. Ми розгорнули наш додаток Amazon EC2 Container Service, хоча наш додаток був монолітним, але ми цього досягли

• Доступність
• Економічно ефективним
• Масштабованість

Балансир завантаження додатків буде обробляти трафік і спрямовувати трафік на здоровий екземпляр, і ви можете виконувати кілька завдань одних і тих же служб, не турбуючись про масштабування та врівноваження навантаження.

Ця архітектура полегшує реалізацію ізоляції відмов. Такі методи, як перевірка стану здоров’я, кешування, перегородки або вимикачі дозволяють зменшити радіус вибуху несправного компонента та покращити загальну доступність даної програми.

Це багато що залежить від конкретної архітектури, але, наприклад:

• Фронтально завантажте веб-сайт CloudFront, щоб зменшити навантаження на хост
• Використовуйте сервіс хостингу на стороні клієнта на зразок S3 для масштабу
• Еластичний балансир навантаження з групою для автоматичного масштабування