Comments
Хорошим пруфом к такой статье было бы использование собственного хранилища вместо habrastorage
А трафика столько на одну конкретную статью нагнать слабо, чтобы почувствовать разницу?:) А то пока вот например чуть больше тысячи просмотров с момента публикации. Что, в общем-то, капля в море озвученных в статье нагрузок:)

Через некоторое время после публикации статьи картинки автоматически копируются на хабрасторадж и ссылки меняются. По крайней мере с моими статьями было именно так.

Объяснили бы для начала, что такое LTM для тех кто в танке не в теме.

Расскажу про то, как у меня решена похожая задача. Картинки, в день исходящий трафик больше 14 ТБ, пиковая скорость — до 8 Гбит/с.
На AWS Route 53 создан alias для домена, указывающий на 16 адресов кэширующих серверов. По днс запросу домена отдаются multiple A-records, 8 адресов, ttl 60s, порядок меняется с каждым запросом. Для каждого адреса кэширующего сервера в Route 53 настроен health check порта 443/tcp (можно и http на liveness url, но будет чуть дороже). В случае недоступности порта на каком-то адресе, health check реагирует на это за 30-60 сек и выкидывает адрес из днс выдачи у домена. Еще до 60 сек (помним про ttl алиаса) нужно чтобы старая днс запись у клиента протухла и он сходил за новой. Таким образом время недоступности домена у 1/16 клиентов наткнувшихся на упавший адрес составит от 30 до 120 сек максимум. И то, только если ПО клиента не умеет доставать следующие адреса из днс ответа самостоятельно (браузеры например умеют, мобильные приложения насколько я знаю — тоже). Дальше, на этих 16 кэширующих серверах (8 на ДЦ) настроена в nginx балансировка по 2 стораджам из своего ДЦ + 2 стораджа из второго ДЦ указаны с опцией backup. Если ответ с ошибкой или кончился таймаут (специально поставлен небольшим) — отправляем запрос на другой сторадж. Стораджи отдают в день до 4 ТБ за счет кэширующего слоя, а клиентам уходят 14 ТБ.
В такой схеме спокойно живется как при отказе любого сервера, так и при недоступности одного ДЦ. Небольшая часть клиентов при сбоях увидит или небольшое повышение времени ответа, либо недоступность не более 1-2 мин. Ручные действия не требуются, в PagerDuty присвоен низкий приоритет на алерты. Используемое ПО — только бесплатный nginx, за Route 53 — несколько десятков $ в месяц.

Еще до 60 сек (помним про ttl алиаса) нужно чтобы старая днс запись у клиента протухла и он сходил за новой.

Зря вы в это верите, многие провайдеры не смотрят так пристально на TTL.

Решение, когда DNS прячет запись, указывающую на хост, при недоступности хоста — неплохо, но очень зависит от клиентов: кто-то кеширует и тудо долбится на один хост, кто-то каждый раз делает запросы на разные хосты из тех, на которые DNS указывает. Причем первый вариант поведения выглядит на самым глупым, как с точки зрения клиента: если у него (клиент) уже были запросы на www.site.com, то логично туда же и стучаться дальше, т.к. есть шанс сэкономить из-за keepalive.

Но, конечно, у каждого свой подход — и свой калибр решения. Кто-то под ту же задачу проксирующий CDN юзает, кто-то простой CDN — и то, и то в каких-то случаях обоснованно, но стоит денег из-за трафика, конечно.

Мне лично запомнился пост от IVI — они там небанально выкрутились, у них трафик очень большой, проксировать его не хотели, и время сходимости решения у них хорошее, как для их ситуации (тюнинг, конечно, нужен, они про него в конце пишут — в частности, что важно не забывать про настройку BFD для ускорения определения живости нод).

Кэшировать адрес для dns записи разумно только на время равное или меньшее её TTL (chrome например принудительно ограничивает кэш минутой).
А если у клиента и кэш лежит неделю, и из списка 8 адресов в ответе он только один себе возьмет — то это только нарочно так можно сделать мне кажется :)

А вы представьте: живет себе простой юзер, где-то дома, и стоит у него wifi-роутер безродный. Считаем: у юзера есть свой кеш днс, затем на роутере свой ДНС-сервер и кеш может быть, тот запрашивает ответы у ДНС провайдера, а провайдерский может спрашивать как у авторитетного сервера для зоны, так и у своего рекурсора. В худшем случае TTL на всех этих ресурсах будут складываться, так что 5 минут TTL для записи легко вырастает до 10-15 и даже 20 минут. По крайней мере, опыт подсказывает это.
Если вы говорите про кеш в Хроме (я такого не знал, но поверю: у них в как бы «браузере» чего только нет своего), то его минуту к тем 10-15 минутам можете приплюсовать.
Иные рекурсивые ДНС-серверы лимитируют минимальный TTL минутой или 5 минутами, им много постоянных запросов — тоже лишний трафик.
В общем, DNS хороший механизм, но, как говорит Черномырдин, «есть и более другие».

Спасибо за ссылку, прочитал и этот пост и предыдущий, в том числе про остаточный трафик в течении 2 недель после смены записи при ttl 15 минут — это, конечно, сильно.
Но у себя такого не наблюдал (и хорошо!), если один-два устройства и засиделись на убираемом балансировщике — то я ими готов пренебречь.
Я всё равно считаю людей которые себе сами так настраивают локальный резолвер или пользуются таким от провайдера — ССЗБ.
Но случаи конечно разные бывают, может быть ситуация когда это будет неприемлемо (как те сайты интернет банков, которые десять лет таскали с собой наследие совместимости с IE 6-8).

В день исходящий трафик больше 14 ТБ

Используемое ПО — только бесплатный nginx, за Route 53 — несколько десятков $ в месяц.
я что то упустил и Amazon вам дарит 14+ Тб трафика?

Упустили, Route 53 это dns, а указывать dns записи — совершенно не обязаны на aws хосты.

Одному мне не хватает в статье двух-трех схем? Типа "Вот так сеть была устроена" и "Вот так сеть теперь устроена".

Если честно, полностью про расшифровке восстановить такой доклад будет проблематично и пара лишних слайдов (в оригинале из 68) имхо не спасут ситуацию. Погляди лучше видео, пользы больше :-)

Интереснее было бы прочитать про ботов и схемах обмана пользователей вашего сайта. Пилите пост, ждем.
Only those users with full accounts are able to leave comments. Log in, please.