В работе онлайн-кинотеатра «Амедиатека» произошёл сбой в ночь премьеры финального сезона «Игры престолов»
Проблемы возникли из-за десятикратного роста желающих посмотреть сериал, объяснили в компании.
В ночь на 15 апреля состоялась премьера первой серии восьмого сезона «Игры престолов». Пользователи пожаловались на сбой в работе онлайн-кинотеатра «Амедиатека», который первым показал начало сезона в 4:00 по московскому времени.
Вечером 14 апреля пользователи начали жаловаться на проблемы с платежами за подписку: сервис списывал оплату, но подписка не появлялась. Служба поддержки «Амедиатеки» объяснила, что подписка начисляется с задержкой из-за высокой нагрузки на сервер.
В час премьеры пользователи начали жаловаться на недоступность или нестабильную работу самого сервиса.
у Вас была куча времени чтобы подготовиться к премьере и не лажать так в очередной раз!!! #GameofThrones #ИграПрестолов @HBO take note of these epic fails with season premiere failing to air/stream properly every year!!!
Добавлено 15 апреля в 11:50. Представитель «Амедиатеки» объяснил vc.ru задержки в начислении оплаты за подписку аномальным количеством платежей, «проводимых ежеминутно». Сколько пользователей пострадали из-за сбоя, в компании не говорят. Деньги можно вернуть, написав в службу поддержки «Амедиатеки».
Примерно с 20:00 по Москве пользователи стали жаловаться на то, что при оплате на их аккаунты не начислялись подписки. Ситуация улучшилась на короткий период, но повторилась с новой силой после 22:00 и продолжалась приблизительно до 03:00. Утром началась вторая, ещё более сильная волна.
Всю ночь, как и в настоящий момент специалисты нашего технического подрядчика работают над её устранением. Наша служба поддержки всё это время вручную оперативно начисляет пользователям подписку.
Сбой в работе онлайн-кинотеатра в «Амедиатеке» объяснили десятикратным ростом количества пользователей, желающих посмотреть первый эпизод финального сезона «Игры престолов». Компания усилила мощности оборудования, но в час премьеры нагрузка более чем в два раза превысила пиковые показатели просмотров предыдущего сезона «Игры престолов» — это абсолютный рекорд сервиса, отметил его представитель.
Первая серия восьмого сезона появилась на сайте в 4:00 по московскому времени, как и было запланировано, но видео плохо загружалось либо вообще не запускалось примерно до 4:40. Это связано с тем, что одновременное количество пользователей на сервисе было в десять раз больше наших самых оптимистичных ожиданий.
Мы пятикратно увеличили количество оборудования в нашем сервисе, но даже оно не справилось с желанием фанатов сериала первыми начать просмотр эпизода.
В качестве извинений «Амедиатека» предложила пользователям воспользоваться промокодом WEGOTYOU на три дня подписки.
Правда - вот интересно - для кого придумали облака то? Облако - смысл же не в том, что это сервер в датацентре далеко, а в возможности получить столько мощностей - сколько нужно!
Где балансировщики нагрузки?! Где подключение новых серверов по мере надобности? Это ж типовые технологии - это просто и отработано уже.
За облачные сервера вы видимо заплатите? Стойку в амку вбухали, а теперь умники вроде вас нихера не понимая в ситуации суют повсюду экспертное мнение. Вам нравятся облака - пользуйтесь, тут же немного другой уровень.
Кагбэ сервис коммерческий, за него заплатили. И клиенты вправе ожидать, что хотя бы в части сайта и приёма оплаты все будет работать без очевидных глюков.
Теперь насчёт облаков. Вы намекаете что они сильно дороже собственных систем? Не уверен, особенно с учетом необходимости обслуживать пики трафика. К тому же речь шла не об основных серверах для трансляции (их можно и свои держать), а о сайте/биллинге. В чем проблема сделать их масштабируемыми по нагрузке то? Дропбокс как то жил с облачными серверами, и это был тот самый уровень.
Ну я вижу вы хорошо в теме разбираетесь, раз считаете что персональная платежная информация может храниться на облаках на зарубежных сереверах.
И если вы не уверены, можете посчитать сколько стоят 30 large инстансов амазона. Кроме того, что это все надо оплачивать, кто гарантирует что все сервера будут в одной стойке для уменьшения задержек?
И дропбокс ЖИЛ с облаками, когда маленький был. А вот стал по больше, отказался от них. Странно, правда? И все крупные компании так же без облаков живут на основных сервисах. Так что если ваш хомяк в облаке, не надо из себя корчить специалиста. Начните с приобретения реального опыта в нагруженных проектах, где использование облаков создают больше проблем, чем решений.
А где вы в моем комменте увидели "зарубежное" облако? Это не очень выгодно, возможно, CDN прийдётся заюзать для местной публики для приемлемых скоростей ответа. Зачем такие сложности? Хотите хранить персональные данные - велкам к рф. Тут тоже есть облака.
Теперь про большие инстансы. А зачем большие инстансы для рассматриваемого случая: работы веб-сайта и биллинга? Вот зачем? Это обычный сайт, его сервера не обрабатывают в памяти какие-то значительные объекты, не ведут сложных вычислений. Вполне справится тьма мелких инстансов - влез бы туда соответствующий микросервис, например. В теории, можно на чем то типа облачных функций сделать систему - но не уверен что в рф такие штуки есть, да и не обязательно. И зачем все сервера в стойке? Вы же не кластерные вычисления делаете. Обращение пойдет всё равно от инстанса к той или иной БД, которая живёт внутри сети этого датацентра. Существенным будет скорость работы БД и сети. И зачем требовать размещения внутри одной стойки я не знаю. Попросите какой то хитрый линк между серверами? Зачем?! В общем, ваши тезисы звучат надуманно.
И уж в любом случае стоимость доп инстансов в облаке не может сравниться со стоимостью настоящих "железных" серверов, которые нужно купить чтобы пережить нагрузку. Зачем их покупать? Когда нагрузка спадёт - они будут простаивать: выкинутые деньги! А в облаке вы просто отказываетесь от ненужных ресурсов. Кейс с резким всплеском нагрузки - это как раз тот случай, который очень хорошо подходит под облака.
Поэтому в вашем комментарии я не увидел ни одного реального аргумента "против". Более того, вы переходите на личности, пытаясь намекнуть на некомпетентность. Слабенько, слабенько.
Если мы про чужие облака, то проблемы:
1. Дорого. Даже аренда серверов значительно дешевле, а покупка своих сильно дешевле.
2. Сторонняя поддержка. У вас может что-то отвалиться и вы будете долго и упорно понимать что происходит. А облако будет упорно отрицать происходящее. Скорость реакции явно не их конёк даже на топ-клиентах.
3. Сложная история с облаками в России. Прям надежных нет. Когда-нибудь возможно им станет Яндекс, но там до устойчивой работы на объемах ещё пилить и пилить.
А подключение дополнительных инстансов и без облаков возможно. Ничто не мешает вам быстро к основной инфраструктуре доставить серверов, когда ты крупный клиент.
Да, вопросы есть, но я не совсем согласен.
1. Облако дороже, если сервер работает 24-7-365. Но мы обсуждали пик трафика, который точно пройдёт через 1.5 месяца - когда народ отсмотрит Игру престолов и закончатся купленные подписки. Для отработки пика трафика облака очень экономически эффективны - и можно сделать систему, которая совмещает облачные сервера и собственные - это самое эффективное. На период пиков увеличиваем количество облачных серверов, заменяя их своими если рост носит постоянный характер - такая схема мне представляется наиболее эффективной экономически, хотя она несколько усложняет архитектуру системы. но ничего невозможного или сильно сложного в ней нет.
2. Вопрос неспешности поддержки (скорее всего речь идет об инциденте) решается путём разнесения облака на несколько регионов. Выпадение одного региона вызывает переключение на другой регион (с возможным ростом объемов серверов в том регионе).
3. Прям надежного облака не должно существовать. Весь смысл облака - в возможности резервирования и переключения нагрузки между регионами / датацентрами и тп. Надежный датацентр нужен как раз своим серверам - которые если в нём живут - оттуда быстро не "убегут". А облачные сервера легко запускаются в другом регионе этого же облака - или у другого провайдера облака.
Насчёт подключения доп инстансов в своей инфраструктуре - это вам всё равно доп железо нужно своё. Безусловно, свою инфраструктуру тоже нужно строить по принципу облака - с контейнеризацией / виртуализацией и похожими принципами построения на облачного провайдера.
Это вы сейчас про ваш хомяк? Ну ок. Но точно не про амедиатеку. И держат, кеш например, и ведут, когда надо все необходимые условия пользования промоакциями рассчитать корректно. Опять же - не гребите всех под гребенку своего хомяка.
И зачем все сервера в стойке?Чтобы пингов по 30мс на sql или редис запрос не было, элементарно. Но для вашего хомяка, у которого по 100 посетителей в год, это совсем не важно, поэтому для вас конечно звучит надуманно
И уж в любом случае стоимость доп инстансов в облаке не может сравниться со стоимостью настоящих "железных" серверовЕсли вы мыслите в рамках месяца - то да. Но вы годовой оборот посмотрите, там уже эти цифры немного иные. И сервера простаивать будут только если у вас один проект, вроде вашего хомяка,
И я потому говорю о вашей некомпетентности, что вы лезете со своими советами уровня домашней странички к сервису у которого 3к рпс.
Что вы привязались к выдуманному вами «моему хомяку»? Вы меня не знаете, а зачем то своей фантазией что то пытаетесь аргументировать. Так делают в отсутствии реальных аргументов.
Теперь по сути: не понимаю - о каком кэше в памяти инстансов вы говорите. Вы
вместо специализированного облачного сервиса кэша/штуки для хранения статики типа s3/cdn хотите поднимать собственное решение для кэширования статики? Зачем? Это ж не выгодно. И работать будет медленнее правильного cdn с серверами в рф.
Насчёт условий промоакций - не понимаю, какие такие гигабайты данных нужно хранить в озу. Пара запросов к базе данных. Какой то код, который реализует логику. Кмк, не особенно эдакая задача, чтобы были нужны дорогие инстансы с большим количеством оперативки.
Пинги по 30мс на бд - некоторый бардак конечно. Но с sql можно решить путём создания хранимых процедур, например! Или разобраться с сетью облачного провайдера. Или сменить провайдера, который не может решить вопрос.
Теперь про простой серверов. Мы говорим про амедиатеку, которая не справляется с наплывом посетителей на свой сайт к выходу сезона Игры престолов. Конкретно. Рост посетителей мне не ясен - но, возможно, он в разы. Чтобы без проблем переживать кратный рост трафика, нужен кратный рост мощностей. Поясните подробно - как с кратным временным ростом мощностей может сойтись экономика приобретения собственного оборудования? Задействовать его потом «в других проектах»? Так себе идея - какие проекты есть у амедиатеки то?
В общем, вернитесь плиз к сути обсуждений и постарайтесь удержаться от перехода на личности - а то мне скучно становится с вами беседовать
Вы не понимаете, а я с этим каждый день работаю. И не про кеширование статики я говорил, если что. CDN как раз у амки был облачный, но стали использоать свой, потому что тот же амазоновский не все нужные нам форматы поддерживает.
А если вы считаете что с облачным провайдером можно разобраться и выбить для себя идеальные условия - считайте дальше, у реальных коиентов с этим проблемы постоянно.
И амедиатека если что через подрядчика этот проект делает.
И если вам скучно - досвидания, ваше пустословие не особо мне интересно.
Простите - н мы обсуждали, что у амедиатеки сайт под наплывом посетителей не справляется с регистрацией новых пользователей и оплаты подписки. Сам сайт еще довольно медленно работает - сам видел. Что же вы кроме статики собрались кэшировать в облачных инстансах для сайта / биллинга?
Но вот вы уже говорите, что CDN был. Значит статика кэширована. Не совсем понимаю, зачем нужно было пытаться свой CDN делать - это сложно, сделать CDN c хорошим покрытием в РФ. Но, возможно, для качественной доставки видео для такого сервиса это оправдано. Опять же - задачу можно было разделить, и хостинг сайта отдать на внешний CDN c лучшим покрытием, чем свой, а свой CDN оставить для видео. Впрочем, без должной инфы судить сложно.
Как итог - не понимаю в итоге вашего закидона насчёт кэширования. Видимо, под кэширования инстансы таки не требовались, и вообще есть CDN. То есть аргумент снялся в ходе обсуждения. Ок.
Аргумент про высоконагружденный биллинг, который должен в гигабайтах памяти инстансов анализировать применяемые промокоды - снялся тихо и без аргументов. Видимо, вам самим стыдно аргументировать такую глупость. Тоже ок.
Теперь насчет пингов к базе данных у облачных провайдеров. Не живите в мире дефицита. Не получается "выбить" нормальные условия у одного - мигрируйте к другому. Благо облачные технологии нынче коммодизированы - миграция может быть произведена через довольно быстрое поднятие системы из образов контейнеров, Базы данных реплицируются в другой ДЦ. Это просто, понятно, предсказуемо и недорого. Особенно, если на этапе проектирования системы предусмотреть такую возможность.
Насчет подрядчика у амедиатеки для "этого проекта" - да я хз кто там чего сделать не может: сама амедиатека или подрядчик. Мы не это обсуждаем. Зачем вы это и к чему написали - мне не понятно.
Итог: я так и не услышал содержательных возражений о невозможности применения облачных технологий
Какой у вас уровень мы уже поняли.
уровень "я делаю работу, а не даю тупые советы"
А ваши тупые советы мы тоже уже видели, мистер "засунь-все-в-облако"