Когда говорят о выборе архитектуры IT-системы, почти всегда упускают один ма-а-аленький нюанс: мы делаем продукты для пользователей, не для себя. А пользователям совершенно неважно, какая у сервиса архитектура. Никто в отзывах не ставит звёздочки за event-driven подход или классную реализацию service mesh — разве что в редких случаях, когда речь о продуктах для разработчиков. 

Техническое совершенство — современные инструменты, предельная оптимизация, чистота кода и лаконичная, но гибкая и масштабируемая архитектура — всё это нужно нам, технарям. А как это всё связано со счастьем пользователей, как его измерять и учитывать при проектировании сервиса, разберёмся под катом.  

Представьте идеальный мир с бесконечными ресурсами, в котором можно сколько угодно линейно масштабироваться под нагрузку: просто доставлять серверы, диски, видеокарты, как только потребуется больше мощностей. Звучит хорошо? Только оказывается, что когда серверов 5 000 и дисков 100 000, то несколько из них обязательно находятся в состоянии maintenance или repair, куда их привели обстоятельства непреодолимой силы. И главная задача здесь — обеспечить доступность сервиса в условиях постоянных сбоев. 

В статье разберём, как построить отказоустойчивую платформу, с какими неочевидными corner cases может столкнуться сервис с UGC-контентом, а ещё — как жить в реальном, а не идеальном мире и оптимизировать железо. Чтобы раздавать 4 Тбит/с можно, конечно, использовать 400 серверов по 10 Гбит/с, но гораздо интереснее грамотно всё потюнить и выжать 100 Гбит/с с Java-сервера.  

На протяжении всей жизни мне приходится экономить вычислительные и сетевые ресурсы: сначала были компьютеры с 300 кГц (кило — не гига!) и 32 Кбайт RAM, интернет по dial-up. Потом я решал олимпиадные задачки. Теперь имею дело с терабайтами трафика и 50 млрд событий в сутки. И хотя современные телефоны в 1 000 раз мощнее любого оборудования двадцатилетней давности, я до сих пор оптимизирую. Думал даже, что это со мной что-то не так. Но потом понял, что все постоянно что-нибудь оптимизируют. 

Эта статья в меньшей степени о том, почему нужно бороться за производительность, и в большей о том, на что сейчас стоит заменить устаревший стек из JPEG, JSON, gzip и TCP — и как это сделать. 

Спойлер: у нас есть решение и мы его не только показываем — ссылки на open source в конце статьи.

Сервисы для онлайн-общения и всевозможная доставка — наверное, самые востребованные и активно развивающиеся отрасли 2020–21-го. Мы ВКонтакте тоже не остались в стороне: работая удалённо с первых месяцев пандемии, запустили групповые видеозвонки. Сперва они вмещали одновременно 128 человек, а теперь мы полностью сняли лимиты на число участников.

В этой статье рассказываем, с какими трудностями сталкивается большинство сервисов звонков. И показываем, что нам понадобилось сделать и изобрести, чтобы преодолеть ограничения по числу участников. Попутно отвечаем на вопросы, которые прилетали со всех сторон на волне интереса к технологиям real-time коммуникации: как устроены Zoom и Clubhouse, что взять для своего сервиса звонков из open source, как встроить звонки в приложение. Про эффективную доставку тоже будет — но не еды, а данных, аудио и видео.

Что нужно от картинки в видеозвонке? Базово — чтобы не пикселила, не замирала и не вешала весь звонок. Это основы real-time видео, и добиться этого не так трудно. 

Всё самое интересное начинается, когда вы хотите, чтобы в одном звонке могли участвовать сколько угодно человек. И при этом все могли включать видео, а не просто смотреть; разрешение скриншеринга было бы 4К; шеринг оставался суперчётким при любом интернете и т. д. И чтобы звонки работали на любых платформах и устройствах на мобильном нестабильном интернете. 

Как мы добиваемся всего этого в звонках ВКонтакте, какие хаки в настройках используем, как экономим трафик и CPU, как боремся за latency и где нам пришлось идти в обход WebRTC, читайте под катом. 

Чтобы снять лимиты на число участников в одном звонке, мы реализовали принципиально новую схему работы с видео- и аудиопотоками: построили уникальную архитектуру, которая горизонтально масштабирует звонок на любое количество серверов и потребляет минимум ресурсов — как серверных, так и клиентских. 

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

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

Распознаванием лиц в 2018 году никого не удивишь – каждый студент, может, даже школьник, его делал. Но всё становится немного сложнее, когда у вас не датасет на 1 млн пользователей, а:

• 330 миллионов пользовательских аккаунтов;
• ежедневно заливается 20 млн пользовательских фотографий;
• максимальное время на обработку одного фото не должно превышать 0.2 сек;
• ограниченные объемы оборудования для решения задачи.

В этой статье мы поделимся опытом разработки и запуска системы распознавания лиц на пользовательских фотографиях в социальной сети Одноклассники и расскажем про все ”от А до Я”:

• математический аппарат;
• техническую реализацию;
• результаты запуска;
• и акцию StarFace, которую мы использовали для PR-а нашего решения.

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