Пользователи сообщили о сбое в сервисах «Яндекс.Еда» и Delivery Club Статьи редакции
Обе компании справились со сбоями за вечер.
Вечером 14 февраля 2020 года пользователи сообщили о проблемах с загрузкой приложений «Яндекс.Еда» и Delivery Club. Об этом они написали в Twitter.
наблюдаю как одновременно упали деливери и яндекс еда, и вот вопрос: либо диверсия, либо кто-то упал и второй не справился с двойной нагрузкой
одновременно упали яндекс еда и деливери клаб, умираю от голода по-миллениальски
На сайте Delivery Club также написано о проблемах в работе сервиса. Сайт «Яндекс.Еды» открывается, но при попытке оформить заказ возникает ошибка.
В «Яндексе» подтвердили vc.ru, что у некоторых пользователей возникали кратковременные трудности с доступом к «Яндекс.Еде», но сейчас сервис работает в штатном режиме.
«Некоторые пользователи сейчас могут столкнуться со сложностями при входе в приложение на фоне аномально высокого спроса, мы занимаемся решением этой проблемы. С операционной точки зрения сервис работает в штатном режиме», — сообщили в Delivery Club.
Обновлено в 21:20. В Delivery Club сообщили vc.ru об устранении сбоя. Компания выплатит компенсацию курьерам, которым пришлось ждать новые заказы, и примет меры, чтобы всплески спроса не влияли на работу сервиса в будущем.
Яндекс и Mail.ru: "ребята, бросайте свои выделенные сервера, переходите на наши облачные платформы, они мгновенно масштабируются под любую нагрузку, резервируются и никогда не упадут!"
Яндекс и Mail.ru: *падают, когда чуть больше чем обычно влюбленных парочек решают заказать похавать.
А вообще наверное Яндекс с Mail.ru в день Святого Валентина просто решили отключиться от всего мира и побыть вдвоём...
Вы путаете тёплое с мягким. Облака созданы для более плотной утилизации ресурсов. Само облако не знает что внутри него запущено. Система оркестрации может выполнять простые сценарии по разворачиванию инстансов. Динамическое выделение ресурсов практически никто не использует, тк держать пару тысяч серверов прозапас дорого как в плане покупки, так и обслуживания. Условно говоря если сервис обычно имеет 3х запас и это окупает железо, то уже 5х на случай такого выброса может увести сервис глубоко в минус.
Комментарий недоступен
Используют, но либо мелкие стартапы, либо что-то внутреннее очень специфичное.
И на других проектах видел, и у себя используем scale up и scale out весьма активно, тк это не означает держать про запас (это же не дэдики), а за предоставление инфраструктуры отвечает PaaS-провайдер. И платится не за то, сколько может быть использовано, а за фактическое использование.Это вы платите сколько использовали, а оператор в эти услуги уже заложил стоимость простаивающего железа. Яндекс сам покупает и сам обслуживает железо. Ему некуда сходить и попросить ещё тысячу серверов.
Ну и опять же, вот вы используете и что? У вас там ещё один под аллоцируется и все ваши потребности закрыты. У вас же нет распределённого общего стораджа под данные, нет всяких балансировок хитрых на L3/L7 чтобы уводить нагрузку в другие ДЦ. Больше инстансов - больше нагрузка на мониторинг, надо ещё и мониторинг покрыть ресурсами. В общем все что может работать на мелких сервисах далеко не факт что будет работать на больших.
Комментарий недоступен
Отлично, только население всех скандинавских стран около 20 млн человек. Это всего лишь Москва и Московская область или Москва и Питер, а у Еды 31 город без Питера и Москвы, из которых 16 миллионники. Ну и документооборотом пользуется далеко не все население, Едой пользуется гораздо больше людей.
Комментарий недоступен
Я говорю, что то, что работает быть может у вас, не работает на крупных проектах. У нас только мониторинг потребляет порядка 3800 ядер. Если вдруг к нам придёт ddos или настоящие пользователи в размере больше, чем 4x, то нужно будет на каждый добавленный под добавить ещё 20 ядер в мониторинг. Дальше доставка логов, на каждый под нужно будет по два ядра только, чтобы отправлять, но ещё и с принимающей стороны тоже растить. Ещё новые поды нужно будет аллоцировать только на тех машинах, где сеть а) без переподписки б) есть полоса без уже промаркированного трафика итд итп. И это мы пока не храним стейт и не используем БД пока. А еще может случиться так, что в локацию пришёл клиент и вдруг Еда легла, кому в такой ситуации дать ресурсы?
Именно потому, что запасов по ресурсам нужного много и сам процесс масштабирования очень сложный, является ещё одной точкой отказа. Люди держат большой запас на балансерах, а дальше сэмплируют запросы и пускают только какой-то процент, который могут переварить. Ровно это и произошло, Еда была недоступна только у части пользователей.