Всё продолжилось на следующий день.
Когда мы изначально планировали платформу - у нас было в 6 раз меньше пользователей, а максимальный их рост планировался в три раза. Т.е. план по росту пользователей перевыполнен на 100%. Цифры не точные, тут интересен порядок.
Мы наивно полагали, что подавляющее большинство учеников(70-75% по нашим прикидкам) будут смотреть прямые трансляции.
Чтобы прямые трансляции работали без сбоев и на полную катушку мы написали свой демон для раздачи видео сегментов. Демон этот хитрый - он закодированное видео клал напрямую в оперативку и периодически от туда уже сбрасывал на диск.
Почему именно так - потому что готовый nginx-rtmp-module не выдержал нашей нагрузки, ибо полагался он на дисковый кеш, который в linux кстати не очень то и эффективно работает, как я уже сейчас понимаю(во FreeBSD более глубокая настройка, но на фряхе не работает докер).
В итоге, наш демон работает как часы и прекрасно выполняет свою функцию. Задержка отдачи видео сегментов прямого эфира просто минимальна.
Где же закрался подвох?
А суровая реальность оказалась полностью противоположной нашим ожиданиям. Вместо 70% просмотров прямого эфира - 80-90% смотрели записи.
И тут есть тоже свои интересные особенности.
Если бы на сервере у нас было бы очень много оперативки(скажем так под терабайт) - всё было бы неплохо, поскольку сработал бы дисковый кеш. Но всё равно было бы туго на входящем пике, когда разом куча людей пришли смотреть видосики.
Но у нас оперативки мало, да и ещё в добавок всего лишь 4 обычных HDD. И это тоже работало нормально, когда у нас был марафон. Даже в записи дети смотрели примерно одни и те же записи, поэтому они отдавались преимущественно из кеша. Синхронизированные дети - хорошо работающий кеш.
И тут у нас приходит 2 тысячи человек смотреть различные записи.
Это приводит к так называемому "длинному хвосту". Это когда у нас есть несколько сотен видео, каждое из которых смотрит только 1 зритель.
На физическом уровне это означает, что жестким дискам надо постоянно быстро туда-сюда считывающей головкой по блинам - куча людей запрашивают разные вещи ведь. В результате вместо больше похожей на последовательное считывание нагрузки на винты - мы получаем полный random read, который ещё и не кешируется(потому что нельзя в 64 Гб RAM впихать _столько_ терабайт видео).
И вот и получается - прямые эфиры мы могли спокойно отдавать на 2.5 гигабита/сек, а вот записи уже не можем даже на 1 гигабит отдать, потому что упираемся в винты.
Когда мы изначально планировали платформу - у нас было в 6 раз меньше пользователей, а максимальный их рост планировался в три раза. Т.е. план по росту пользователей перевыполнен на 100%. Цифры не точные, тут интересен порядок.
Мы наивно полагали, что подавляющее большинство учеников(70-75% по нашим прикидкам) будут смотреть прямые трансляции.
Чтобы прямые трансляции работали без сбоев и на полную катушку мы написали свой демон для раздачи видео сегментов. Демон этот хитрый - он закодированное видео клал напрямую в оперативку и периодически от туда уже сбрасывал на диск.
Почему именно так - потому что готовый nginx-rtmp-module не выдержал нашей нагрузки, ибо полагался он на дисковый кеш, который в linux кстати не очень то и эффективно работает, как я уже сейчас понимаю(во FreeBSD более глубокая настройка, но на фряхе не работает докер).
В итоге, наш демон работает как часы и прекрасно выполняет свою функцию. Задержка отдачи видео сегментов прямого эфира просто минимальна.
Где же закрался подвох?
А суровая реальность оказалась полностью противоположной нашим ожиданиям. Вместо 70% просмотров прямого эфира - 80-90% смотрели записи.
И тут есть тоже свои интересные особенности.
Если бы на сервере у нас было бы очень много оперативки(скажем так под терабайт) - всё было бы неплохо, поскольку сработал бы дисковый кеш. Но всё равно было бы туго на входящем пике, когда разом куча людей пришли смотреть видосики.
Но у нас оперативки мало, да и ещё в добавок всего лишь 4 обычных HDD. И это тоже работало нормально, когда у нас был марафон. Даже в записи дети смотрели примерно одни и те же записи, поэтому они отдавались преимущественно из кеша. Синхронизированные дети - хорошо работающий кеш.
И тут у нас приходит 2 тысячи человек смотреть различные записи.
Это приводит к так называемому "длинному хвосту". Это когда у нас есть несколько сотен видео, каждое из которых смотрит только 1 зритель.
На физическом уровне это означает, что жестким дискам надо постоянно быстро туда-сюда считывающей головкой по блинам - куча людей запрашивают разные вещи ведь. В результате вместо больше похожей на последовательное считывание нагрузки на винты - мы получаем полный random read, который ещё и не кешируется(потому что нельзя в 64 Гб RAM впихать _столько_ терабайт видео).
И вот и получается - прямые эфиры мы могли спокойно отдавать на 2.5 гигабита/сек, а вот записи уже не можем даже на 1 гигабит отдать, потому что упираемся в винты.
Под такой нагрузкой у нас ядро отключило один из винтов в RAID-е. Я так и не понял почему, но судя по всему винт решил через SMART сообщить о своей кончине, чему ОС и поверила.
По факту же, у нас просто был 100% iowait. Сайт был жив исключительно потому, что всё кроме видео живёт на SSD.
Единственным быстрым и эффективным экстренным решением было отключить одно из разрешений - Full HD. На самом деле, разницу между Full HD и HD на многих мониторах не видно в наших вебах, если не всматриваться в чатик.
Отключение Full HD снизило почти на треть нагрузку на винты, но этого всё равно было не сказать, что достаточно.
Ну и надо понимать, что для отключения fullhd я просто подправил код нашего демона раздачи видео, чтобы тот не отдавал в master-плейлисте информацию о том, что у вебинара в принципе есть fullhd версия.
Фактически же, все вебы у нас транслировались на сервер и записывались в fullhd. Так что, в скорем времени мы всё вернём обратно.
По факту же, у нас просто был 100% iowait. Сайт был жив исключительно потому, что всё кроме видео живёт на SSD.
Единственным быстрым и эффективным экстренным решением было отключить одно из разрешений - Full HD. На самом деле, разницу между Full HD и HD на многих мониторах не видно в наших вебах, если не всматриваться в чатик.
Отключение Full HD снизило почти на треть нагрузку на винты, но этого всё равно было не сказать, что достаточно.
Ну и надо понимать, что для отключения fullhd я просто подправил код нашего демона раздачи видео, чтобы тот не отдавал в master-плейлисте информацию о том, что у вебинара в принципе есть fullhd версия.
Фактически же, все вебы у нас транслировались на сервер и записывались в fullhd. Так что, в скорем времени мы всё вернём обратно.
Для того, чтобы полностью перестраховаться и выдержать очередной резкий рост длинного хвоста, надо было увеличивать пропускную способность I/O, т.е. тех самых винтов.
Самый простой и быстрый способ тут - поставить ещё серверов.
В тот момент я был готов бросить всё, кинуть сервера в машину и вместе с Виктором отправиться в Москву прямо в дата-центр. 6.5 часов в один конец были бы не так страшны, если бы я перед этим нормально спал, а у Виктора были бы водительские права.
Хорошо, что мы в итоге не согласились на эту авантюру, а решили взять в аренду готовые сервера. Хоть и за бешенные деньги, не очень подходящие - но они нас очень даже выручили. Если бы мы поехали со своими серверами в Москву - мы бы потратили больше сил, а результат был бы тем же по сути.
В итоге, взяли мы 4 сервера с гигабитными каналами. Туда было решено закинуть математику, как самую востребованную. У нас поулчилось некоторое шардирование - берём ID урока, делим на количество серверов(шардов) - по остатку определяем, на какой сервер это видео закинуть.
За ночь - все вебчики закинулись, балансировка нагрузки написалась и всё завелось. Хорошо, что сразу делали на микросервисах - достаточно было добавить новые сервера в кластер Docker Swarm и допилить deploy-скрипт микросервиса отдачи видео. Сам этап доработки тут занял буквально 40 минут, что крайне быстро.
Всё это выкатилось бы без простоя вообще, если бы я не опечатался в конфиге балансировщика. Ну а так простой был по факту в минут 5.
В результате, мы очень неслабо разгрузили основные винты, протестировали экстренное шардирование и балансировку.
Ну и опыт да, опыт бесценный просто!
Самый простой и быстрый способ тут - поставить ещё серверов.
В тот момент я был готов бросить всё, кинуть сервера в машину и вместе с Виктором отправиться в Москву прямо в дата-центр. 6.5 часов в один конец были бы не так страшны, если бы я перед этим нормально спал, а у Виктора были бы водительские права.
Хорошо, что мы в итоге не согласились на эту авантюру, а решили взять в аренду готовые сервера. Хоть и за бешенные деньги, не очень подходящие - но они нас очень даже выручили. Если бы мы поехали со своими серверами в Москву - мы бы потратили больше сил, а результат был бы тем же по сути.
В итоге, взяли мы 4 сервера с гигабитными каналами. Туда было решено закинуть математику, как самую востребованную. У нас поулчилось некоторое шардирование - берём ID урока, делим на количество серверов(шардов) - по остатку определяем, на какой сервер это видео закинуть.
За ночь - все вебчики закинулись, балансировка нагрузки написалась и всё завелось. Хорошо, что сразу делали на микросервисах - достаточно было добавить новые сервера в кластер Docker Swarm и допилить deploy-скрипт микросервиса отдачи видео. Сам этап доработки тут занял буквально 40 минут, что крайне быстро.
Всё это выкатилось бы без простоя вообще, если бы я не опечатался в конфиге балансировщика. Ну а так простой был по факту в минут 5.
В результате, мы очень неслабо разгрузили основные винты, протестировали экстренное шардирование и балансировку.
Ну и опыт да, опыт бесценный просто!
Рандомный факт: в фильме "Пушки Акимбо" можно увидеть вполне рабочий код на Go.
Код запускает /usr/local/bin/skizm с параметрами от ffmpeg для приёма rtmp потока трансляции и конвертирования его в формат стриминга HLS.
Через пару секунд как раз мы видим надпись "Loading Live Stream".
Это тот самый редкий случай, когда в фильме код более-менее не фейковый и создатели привлекли настоящего программиста к созданию киноленты по сути ради нескольких секунд.
Код запускает /usr/local/bin/skizm с параметрами от ffmpeg для приёма rtmp потока трансляции и конвертирования его в формат стриминга HLS.
Через пару секунд как раз мы видим надпись "Loading Live Stream".
Это тот самый редкий случай, когда в фильме код более-менее не фейковый и создатели привлекли настоящего программиста к созданию киноленты по сути ради нескольких секунд.
Вопросов никто не задаёт, ну и ладно. Вот посмотрите, как ИИ GPT-3 уже умеет - вы ему на нативном языке, он вам SQL. Умеет даже подзапросы.
https://twitter.com/i/status/1285934622891667457
https://twitter.com/i/status/1285934622891667457
У меня тут недавно спрашивали, насколько перспективное как будущая специальность направление Big Data Analysys. Я ответил, что безумно перспективное и нужно оно очень многим современным компаниям.
Некоторые компании делают все ставки на большие данные и по сути строят весь свой бизнес вокруг них, хотя для конечного пользователя это будет выглядеть как просто обычный продукт.
Вот и ещё один такой пример. Страховыми компаниями никого не удивишь - их тысячи по всему миру. Есть старые и неповоротливые, есть молодые и прогрессивные. Но все страховые по сути операются на анкетные и обычные статистические данные при расчете всей своей модели существования. Tesla Insurance пошли дальше и решили непрерывно собирать самые актуальные данные о стиле вождении автомобиля и каждый месяц пересчитывать условия по страховке.
Интересно только одно - если этот продукт потом будет для всех автомобилей, а не только для Tesla, то как они будут определять какой именно водитель за рулём, если машиной в семье пользуется несколько человек?
Откуда дровишки: https://www.businessinsider.com/elon-musk-tesla-launching-insurance-company-nationwide-hiring-2020-7
Некоторые компании делают все ставки на большие данные и по сути строят весь свой бизнес вокруг них, хотя для конечного пользователя это будет выглядеть как просто обычный продукт.
Вот и ещё один такой пример. Страховыми компаниями никого не удивишь - их тысячи по всему миру. Есть старые и неповоротливые, есть молодые и прогрессивные. Но все страховые по сути операются на анкетные и обычные статистические данные при расчете всей своей модели существования. Tesla Insurance пошли дальше и решили непрерывно собирать самые актуальные данные о стиле вождении автомобиля и каждый месяц пересчитывать условия по страховке.
Интересно только одно - если этот продукт потом будет для всех автомобилей, а не только для Tesla, то как они будут определять какой именно водитель за рулём, если машиной в семье пользуется несколько человек?
Откуда дровишки: https://www.businessinsider.com/elon-musk-tesla-launching-insurance-company-nationwide-hiring-2020-7
Business Insider
Elon Musk says Tesla is creating a 'major insurance company' after its botched rollout in California last year
Musk said he had great respect for actuaries and was looking for the best of the profession to join Tesla's workforce.
👍1
Не успел я приехать в лагерь Школково, как у нас отвалился сайт с платформой.
Причем не по нашей вине.
У хостера Selectel отвалился биллинг. В итоге, они думали, что у нас нулевой баланс. Из-за этого они отключили облачное хранилище, куда мы при сборке выгружаем всю статику фронта.
Я им позвонил, а они меня разве что только нахер не послали. Ни извинений, ни сроков устранения неполадок.
Но прикол ситуации в том, что несколько часов назад от них пришёл тикет с опросом "Помогите нам улучшить работу с балансом"(см. скриншот).
В итоге, пришлось все js ассеты упихать в докер-контейнеры и всё завелось.
Слався непрерывная интеграция, Docker славься!
Причем не по нашей вине.
У хостера Selectel отвалился биллинг. В итоге, они думали, что у нас нулевой баланс. Из-за этого они отключили облачное хранилище, куда мы при сборке выгружаем всю статику фронта.
Я им позвонил, а они меня разве что только нахер не послали. Ни извинений, ни сроков устранения неполадок.
Но прикол ситуации в том, что несколько часов назад от них пришёл тикет с опросом "Помогите нам улучшить работу с балансом"(см. скриншот).
В итоге, пришлось все js ассеты упихать в докер-контейнеры и всё завелось.
Слався непрерывная интеграция, Docker славься!
Между прочим, у этого канала есть чат https://t.me/DevHype_Chat
В нём можно:
- Задавать любые вопросы по IT, особенно по разработке
- Обсудить какую-нибудь наболевшую тему и спросить мнение знатоков и краеведов
- Поделиться своим прогрессом в освоении каких-нибудь технологий, достижением или просто похвастаться какой-нибудь поделкой
- Поделиться актуальным интересным видео/статьёй/крутой библиотекой или фреймворком, которые перевернули(или нет) ваш мир
- Просто пообщаться с хорошими людьми
Ну а пока вот вам картинка для привлечения внимания и маленький спойлер по новому сайту Школково.
PS: Найди кота🐱
В нём можно:
- Задавать любые вопросы по IT, особенно по разработке
- Обсудить какую-нибудь наболевшую тему и спросить мнение знатоков и краеведов
- Поделиться своим прогрессом в освоении каких-нибудь технологий, достижением или просто похвастаться какой-нибудь поделкой
- Поделиться актуальным интересным видео/статьёй/крутой библиотекой или фреймворком, которые перевернули(или нет) ваш мир
- Просто пообщаться с хорошими людьми
Ну а пока вот вам картинка для привлечения внимания и маленький спойлер по новому сайту Школково.
PS: Найди кота🐱
Очень жизненная ситуация порой...
Бекапы надо делать, проверять и пытаться с них восстановить. Иначе у тебя нет бекапов.
Бекапы надо делать, проверять и пытаться с них восстановить. Иначе у тебя нет бекапов.
Media is too big
VIEW IN TELEGRAM
Тут у Александра Романовича @gdialex из Школково день рождения сегодня. Мы все конечно же присоединяемся к поздравлениям!
Кому интересна офигительная история, как мы записывали музыку для этого видео? Пишите плюсик в чат канала 😜
Кому интересна офигительная история, как мы записывали музыку для этого видео? Пишите плюсик в чат канала 😜
Давайте я повторю ещё раз _свою_ позицию по поводу языков программирования.
Pascal - мёртвый, я не согласен, что он хорош для обучения - питон тут лучше.
Что надо изучать, когда не знаешь, что хочешь, но хочешь быть крутым:
1. C++ - надо изучать для понимания низкоуровневых и базовых вещей: структуры данных, выделение и работа с памятью, потоки, класический ООП, типозависимость и указатели, неймспейсы. Ни один другой язык этого лучше не покажет, чем C++
2. Java - самый распространенный язык с виртуальной машиной. Идеально подходит для понимания принципа пакетов, байткода, паттернов. Но самое главное лично для меня - понимание принципа Garbage Collection.
3. Go - идеально для понимания функциональных языков и языков, где нет исключений.
4. php, perl - для понимания интерпретируемых языков, динамической типизации
5. javascript - для понимания, как не надо делать языки, и как эту ошибку можно частично исправить с помощью стандартов
Собственно вот этот стек поможет понять самые главные аспекты в языках, ну и поможет определиться с тем, на чём хотите программировать.
PS: На самом деле, после изучения этого списка - уже без разницы на чём писать.
Pascal - мёртвый, я не согласен, что он хорош для обучения - питон тут лучше.
Что надо изучать, когда не знаешь, что хочешь, но хочешь быть крутым:
1. C++ - надо изучать для понимания низкоуровневых и базовых вещей: структуры данных, выделение и работа с памятью, потоки, класический ООП, типозависимость и указатели, неймспейсы. Ни один другой язык этого лучше не покажет, чем C++
2. Java - самый распространенный язык с виртуальной машиной. Идеально подходит для понимания принципа пакетов, байткода, паттернов. Но самое главное лично для меня - понимание принципа Garbage Collection.
3. Go - идеально для понимания функциональных языков и языков, где нет исключений.
4. php, perl - для понимания интерпретируемых языков, динамической типизации
5. javascript - для понимания, как не надо делать языки, и как эту ошибку можно частично исправить с помощью стандартов
Собственно вот этот стек поможет понять самые главные аспекты в языках, ну и поможет определиться с тем, на чём хотите программировать.
PS: На самом деле, после изучения этого списка - уже без разницы на чём писать.