#aws

Подъехал пост-мортем от Амазона.

С одной стороны, хочется поржать над DNS Enactor, DropletWorkflow Manager (DWFM), Network Manager и прочими — это Galactic от Krazam, только в реальном мире и на очень серьезных щщах.

Если без шуток, то цепочка такая:

1. сначала сломался доступ к dynamodb из-за рейс-кондишена системы управления DNS — два таска начали писать в DNS одновременно, первый старую версию записей, второй — более новую новую, в результате часть записей в DNS оказалась новая, часть старая, второй процесс запустил cleanup, который удалил все старые записи и из такого разломанного состояния система сама восстановиться не могла. Сломалось в полночью, за 50 минут поняли в чем дело и ещё за 40 минут починили руками.

2. из-за сломанного dynamodb, система управления железом не могла обновить статус физических серверов и начала отмечать их как «недоступные», поэтому не могла запустить новые виртуальные машины; после восстановления dynamodb, по-идее всё должно было встать само, но из-за большого объема железа, стоящего в очереди, обновление статуса занимало дольше, чем таймаут — и очередь не разгребалась, а только росла. Коллапс. Стандартной процедуры восстановления для такого случая прописано не было, через 2 часа попыток что-то разрулить, инженеры ограничили число входящих запросов и начали перезапускать тачки с системой управления; это помогло, теперь можно было создать новые виртуальные машины;

3. но ещё какое-то время эти новые виртуалки не делали никакой полезной работы, потому что из-за взрывной нагрузки не справлялась система управления разлива конфигурации сети и сеть на новые тачки приходила с задержкой;

4. из-за этой задержки появления сети на машинах, моргали статусы серверов в лоад-балансерах, отмечая живые инстансы как мертвые и триггерились дополнительные переключения нагрузки (привет, DNS!) и перегрузилась система проверки здоровья серверов,
пришлось её на время выключить.

Ну а когда у вас не доступны базы данных и виртуальные машины, то все остальное уже валится по цепочке (и список десятков облачных сервисов, которые пострадали).

Раздел «что мы поменяем» удивительно короткий и очень технический: починят рейс кодишен в DNS, ограничат объем серверов, который может выключить лоад-балансер и т. д. Ну и заканчивают «извините, в будущем будем более лучше стараться».

Интересно, что они не делают никаких философских выводов из ситуации. Видимо, считают, что идейно всё верно. Я сам такими огромными системами (и командами) не управлял и поэтому осторожно предположу, что, наверное, технически, можно сделать систему проще, но учитывая, что над ней работают десятки независимых команд — это, наверное, минимальный доступный объем сложности и допустимый объем ошибок. Было бы интересно услышать мнение «настоящих сварщиков».

—

Коллеги советуют замечательную статью на тему безопасности сложных систем. Она не дает ответов, но предостерегает от попытки найти «root cause», «причину аварии» и предлагает посмотреть на безопасность систем по-новому, через другие линзы, чем я привык. Очень рекомендую.

Большая часть облачных сервисов AWS лежала почти 3 часа. Если у вас глючили Слек, Зум, Сигнал и прочие — это всё от этого. Уже поднимаются. Официальный статус тут.

Как обычно, система поддержки AWS тоже легла. Говорят, что из-за проблем с DNS отвалилась база данных DynamoDB на восточном побережье США, ну а дальше эффект домино. Ждем официального post mortem.

Время шутки, что один сервак в hetzner может дать больший аптайм, чем вся современная облачная инфраструктура.

В облаке Amazon AWS опять проблемы и это задело Slack — популярный рабочий мессенджер, так что если он у вас глючит — «дело не в офисном интернете».

У всех крупных онлайн платформ есть так называемый Status page, в котором инженеры отражают «здоровье сервиса». Ходят слухи, что в Amazon инженеров наказывают за то, что их сервис отметился на этой странице. К чему это приводит — довольно очевидно. Вот ребята сделали юмористический и чуть более удобный «правдивый статус Амазона».

Клаудфлер обвиняет амазон в том, что тот завышает цены на исходящий трафик на 8000%. Вторая претензия (более существенная): залить данные в облако амазона бесплатно, а выкачать обратно стоит денег.

Я люблю хвастаться, что весь хостинг Медузы стоил меньше тысячи долларов в месяц. Секрет был в том, что мы арендовали серверы у французского хостера Online.net, который не брал деньги за трафик. Тот же сайт, размещенный на обычных облачных провайдерах типа Амазона или Яндекс.Облака, стоил бы нам десятки тысяч долларов.

Для того, чтобы сайт работал в интернете, нужно арендовать серверные мощности — это сами железки, электрически, охлаждение и подключение к интернету. Если сайт не требует особых вычислений, а просто раздает популярные тексты, фото или видео, как медиа — то железок нужно не много. Основная нагрузка — на каналы связи.

Прикол в том, что облачные провайдеры платят за канал связи фиксированную плату в месяц, а с клиентов берут деньги за объем переданной информации. Большинство сервисов (стартапов) не передают большой объем информации и поэтому эта цена остается в рамках разумного. Стоит начать раздавать популярные страницы или тем более фото и видео — и ценник в облачных хостингах становится совсем негуманным.

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

P.S. Облачные хостинги — отличный инструмент ❤️

Супер история о том, как Амазон чуть не умер и переехал с серверов Sun на Linux. Это — история зарождения Amazon Web Services — облака, на котором сегодня работает добрая половина интернета.

Рассказывает один из непосредственных участников.

Самые впечатляющие моменты:

❧ в 2000 лопнул пузырь доткомов — технические компании обесценились в сотни раз, на фондовом рынке кончились деньги и Amazon начал жечь собственные средства — 1 миллиард долларов в год; самой крупной статьей расходов были серверы — их делал Sun, они стоили дорого;

❧ можно было перекупить серверы Sun у компаний, обанкротившихся на пузыре доткомов, но техдир Амазона пошел ва-банк — решил переехать с Sun на обычное железо Hewlett Packard на Линуксе; ядру лунукса тогда было всего 6 лет;

❧ на время переезда они остановили ВСЮ продуктовую разработку! ВСЕ занимались только переездом. В бэклоге лежали сотни функций для увеличения продаж, но все ждали, пока закончится переезд;

❧ заморозка развития сервиса привела к падению продаж → пришлось повышать цены на товары → продажи упали ещё сильнее, запустилась «спираль смерти»;

❧ у Амазона оставалось буквально несколько кварталов до смерти, когда деньги на счету кончатся, но они успели и запустили всё нормально, стоимость масштабирования инфраструктуры упала на 80%;

❧ продажи — сезонный бизнес и Безос придумал, почему бы не сдавать простаивающие серверы в низкий сезон другим компаниям? На презентации он привел аналогию с электрической сетью — в 1900 годы каждый завод строил свою собственную электростанцию, почему бы не сделать «электрическую сеть» для IT? Плюс это круто сочеталось с его идеей разделить команды внутри компании, чтобы команды могли развиваться самостоятельно — каждая команда стала независимым API.

Ну а дальше вы знаете. Сегодня Амазон — это не только интернет-магазин, но и одна из крупнейших IT компаний планеты.

https://twitter.com/DanRose999/status/1347677573900242944

Амазон анонсировал сервис для «chaos engineering» в своем облаке AWS. Система выключает случайные части инфраструктуры для того, чтобы проверить, как ваш сервис умеет противостоять реальным авариям.

В яндексе эта штука называется «учения», когда могут, например, выключить целиком какой-то датацентр и проверить, как разные сервисы продолжают работать в такой ситуации. Или выключить какой-то кабель, который соединяет два разных ДЦ, чтобы симулировать обрыв кабеля.

Этот подход сильно популизировал Нетфликс. В 2011 году они переехали в облако и тогда же анонсировали «chaos monkey» — «обезьяну хаоса», которая выключала (убивала) случайные продакшен серверы компании. Идея в том, что на определенном объеме серверов подобные проблемы неизбежны. Это не вопрос «сломается ли», а вопрос «когда сломается» и «сколько сломается». И лучше подготовиться и протестировать свои подходы и инструменты заранее.

Амазон предлагает и вариант с «днями учений» и автоматическую проверку системы при деплоях. Тот случай, когда придуманные гигантами технологии потихоньку просачиваются в повседневность.

Напомню, для небольших компаний гораздо важнее настроить и проверить бэкапы.

Подробная и полезная статья, как один стартап боролся с мощной DDoS атакой.

История очень хорошо написана. Например, число одновременных соединений они измеряют в подписчиках твиттера Джастина Бибера. Почитайте, оно того стоит.

Практическое: они жили на AWS и подключили услугу AWS Shield Advanced — это когда anti-DDoS специалисты амазона помогают разобраться с вашей конкретной атакой. Стоит 3k$ в месяц, договор на год. Чувакам очень понравилось, и я возьму на заметку.

Вовремя мы взяли iGooods в клиенты. У чуваков столько новых пользователей, что серверы не выдерживают и внешние сервисы бьют лимиты.

Утром придумали хитрый внутренний прокси для облегчения нагрузки, зарегали аккаунт в AWS и вот только что задеплоили первую в компании лямбду в продакшен. Сегодня вечером придумали, а завтра, я надеюсь, уже запустим внутреннего телеграм-бота для радикального ускорения сборки заказов, тоже первого в компании.

Кстати, про лямбды: для того, чтобы не попасть под блокировки РКН, пришлось завернуть все запросы через наш собственный nginx, расположенный в России. Не забывайте про это, если работаете в России.

Интереснее сейчас, наверное, только у эпидемиологов, в медиа и в школах, которые пытаются перейти на удаленку. 🚀

Amazon две недели разбирался и ответил, что простит половину счета за трафик, который мы случайно нагенерили в конце года. Cloudflare простил весь счет за трафик в указанном периоде. УРА!

Не стесняйтесь просить помощи. Люди и компании вполне могут пойти вам навстречу.

P.S. Хорошая история в тему от хмельного девопса.

Вот эпичное видео эксплуатации схожей уязвимости.

Ролик очень плохого кавера на Hello Адель (зато слова по теме!) передаётся между двумя виртуальными серверами в Amazon AWS через кеш процессора (!) и проигрывается в реальном времени.

https://www.youtube.com/watch?v=yPZmiRi_c-o

Важно, что в этом докладе речь идёт не о взломе или краже данных через процессор - на обоих серверах запущена программа, которая общается с «коллегой» с соседнего сервера через кеш процессора. Если на вашем виртуальном сервере в AWS запускают программы злоумышленники - то факт того, что ваши секретные данные были переданы наружу не через сетевое соединение, а через кеш процессора - не самая большая проблема. Это просто очень мощный пример of things to come.

Полный доклад: https://youtu.be/6bCdFmehMSY