Анотація

Я відновлюю свій веб-сайт, і на цей раз я вирішив перейти зі статичним генератором веб-сайтів (jekyll, sculpin.io тощо). Частково як вправу, я хочу, щоб цей веб-сайт розміщувався на глобально збалансованому хостингу для швидкості. (Тож американські глядачі повинні отримати сайт із американського сервера.)

Отже, моя мета - створити найшвидший людський сайт. Бо я сподіваюся, що зможу.

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

Питання в тому, як це зробити? Ось що я спробував:

Використання CDN

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

Статичний хостинг веб-сайтів Amazon AWS

Використовуючи відра Amazon S3, можна створити статичний хостинг. Проблема полягає в тому, що ім'я відра повинно бути ТОЧНО таким самим, як ім'я веб-сайту, а назви відра - глобальні, тому я не можу створювати декілька примірників відра та безпосередньо обслуговувати сайт.

Амазонський маршрут53 / EC2

Хоча запуск власної операційної системи є менш оптимальним (занадто багато роботи, великі витрати), це варіант. Тим більше, що Лялька робить автоматизацію легкою.

Для цієї установки потрібен екземпляр EC2 у кожному регіоні, один еластичний балансир навантаження, сконфігурований перед ним, та Route53 для маршрутизації трафіку до географічно місцевих ELB.

Побудуйте самі

Поповнюючи VPS або root-сервери у кожному регіоні, я можу запустити власну ОС та встановити nginx. У будь-якому іншому відношенні це буде дуже схоже на налаштування AWS.

Підсумок

Жодне з них не відповідає моїм потребам статичного хостингу веб-сайтів. Як би підходити до цієї проблеми? Які приховані проблеми з цього приводу? Будь-які послуги, які мені потрібно подивитися?

Я схильний почати з того, щоб сказати: "Виберіть будь-яке двоє".

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

Я схильний не погоджуватися з припущенням, що підхід CDN не буде достатньо швидким, оскільки об'єкт не повинен бути шалено популярним, щоб бути достатньо популярним, і час від часу коротке очікування меншості об'єктів на колодязі -проектована сторінка може залишитися непоміченою. Такий CDN, як CloudFront, має додаткову перевагу в тому, що ваші запити на вихідний сервер значною мірою переходять у власну мережу Amazon, а не у загальнодоступний Інтернет, видаляючи деякі змінні глобального транспорту даних.

Але є гібридний підхід, який поєднує в основному всі згадані вами елементи:

Передня лінія - CDN. Ми скажемо CloudFront, який використовує DNS для автоматичного маршрутизації запитів із браузерів до найбільш оптимального місця розташування.

Сервер-джерело, до якого підключається CDN на зворотному боці, насправді є декількома серверами, гео / затримки маршрутизовані за допомогою маршруту 53, тому край CDN підключається до найближчого сервера-джерела в сусідній області AWS.

Ці цілі, орієнтовані на гео / затримки - джерела, коли CDN оновлює будь-які не кешовані об'єкти - є випадками EC2, але замість повнорозмірних веб-серверів вони працюють із проксі-серверами, одним або декількома в кожному регіоні, з S3 як їхні накопичувачі замість жорстких дисків. Оскільки проксі-сервери можуть переписати початкові заголовки хоста на шляху до S3, імена вашого відра більше не повинні відповідати, тому ви можете розміщувати їх у кожному регіоні. Ви можете досягти значної пропускної спроможності в дуже малих випадках за допомогою проксі-сервера типу HAProxy (у мене є машини2.2icro, що обслуговують 2 мільйони запитів на день, підтримуючи стабільну витрату процесора близько 3%). Оскільки проксі-сервери знаходяться в тому ж регіоні, що і кошики, плата за передачу даних не стягується. ELB вам не потрібен, оскільки перевірки стану маршруту 53 можуть видалити непрацюючий проксі-сервер із пулу, з якого вибере CDN.

Якби ви хотіли отримати абсолютно меншісекундні гайки, ви можете використовувати Varnish як проксі-сервер на машинах EC2 і кешувати вміст від S3 всередині EC2, щоб ви могли вже мати його, якщо CDN потрібна нова копія.

Таким чином, браузер вибирає найближчий край CDN, CDN вибирає найближчий бек-енд, який є проксі-сервером (один з потенційно декількох у регіоні), який має шлях із низькою затримкою до будь-якого вмісту, який ще не містив CDN, зберігається в відро в тому ж регіоні.

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