Представляем гостевой пост от компании Surf Studio (Certified Google Developer Agency).

Привет, Хабр. Меня зовут Александр Ольферук (@olferuk), я занимаюсь машинным обучением в Surf. С 2011 года мы разрабатываем мобильные приложения для крупного бизнеса, а теперь готовим к релизу B2B-продукт с TensorFlow. Спасибо коллегам из Google за возможность рассказать немного о нашем опыте.

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

Миллионы пользователей ежемесячно отправляют миллиарды сообщений в Discord. Поиск в этих сообщениях стал одной из самых востребованных функций, какие мы сделали. Да будет поиск!

Требования

• Экономически эффективный: Основное взаимодействие пользователя с Discord — это наш текстовый и голосовой чат. Поиск — вспомогательная функция, и стоимость инфраструктуры должна отражать это. В идеале это значит, что поиск не должен стоить дороже, чем фактическое хранение сообщений.
• Быстрый и интуитивно понятный: Все создаваемые нами функции должны быть быстрыми и интуитивными, в том числе поиск. Он должен выглядеть и ощущаться по высшему стандарту.
• Самовосстановление: У нас нет отдела DevOps (пока), так что поиск должен выдерживать сбои с минимальным человеческим вмешательством или вообще без него.
• Линейно масштабируемый: Как и с хранением сообщений, увеличение ёмкости поисковой инфраструктуры должно предусматривать добавление нодов.
• Ленивая индексация: Не все пользуются поиском — мы не должны индексировать сообщения, пока кто-то не попытается хотя бы раз их найти. Вдобавок, после сбоя индекса должна быть возможность переиндексации серверов на лету.

Всем привет! Я хочу рассказать о том, как съездил на конференцию Google Next. На конференции я был первый раз, забегая вперед скажу, что остался доволен и почти все самые интересные технические анонсы были во второй день, но, давайте обо всем по порядку.

Урок: «Система, работающая с двумя миллионами пользователей, не обязательно сможет справиться с десятью миллионами».

После выпуска Pokémon Go в США в июле 2016 года она стала самой популярной на тот момент игрой в дополненной реальности. Этот продукт многолетнего сотрудничества игрового разработчика Niantic и Google (пока Niantic не встала на ноги, она была внутренним стартапом Google). Поэтому инфраструктура Pokémon Go сильно зависела от облачной платформы и служб приложений Google. (Компании Nintendo и Pokémon тоже приняли участие в создании захватывающего игрового процесса выращивания маленьких монстриков для мобильных платформ.)

Это была не первая игра Niantic в дополненной реальности. Ранее компания создала Ingress, игру о вторжении инопланетян, выпущенную в 2013 году для устройств Android. Но Pokémon Go стала игрой совершенно другого уровня — покемоны уже давно были культурным феноменом. Игра заинтересовала аудиторию, долгие годы ожидавшую мобильную игру. Поэтому количество установок росло стремительно. За полдня игра заняла первую позицию по доходам на iPhone. В какой-то степени это был самый масштабный в мире выпуск мобильной игры.

В первой статье этой серии мы говорили о том, как работает старая система доставки сообщений и некоторых выводах, которые мы сделали по итогам ее работы. Во второй мы рассмотрели конструкцию новой системы и то, почему мы выбрали Cloud Pub/Sub в качестве транспортного механизма для всех событий. В этой третьей и последней статье мы объясним, как мы намереваемся работать со всеми опубликованными событиями при помощи Dataflow, и что мы узнали о таком подходе.

Измерение пропускной способности узких мест по времени двойного прохода пакета

По всем параметрам, сегодняшний интернет не может перемещать данные так быстро, как должен. Большинство пользователей сотовой связи в мире испытывают задержки от нескольких секунд до нескольких минут: публичные точки WiFi в аэропортах и на конференциях ещё хуже. Физикам и климатологам нужно обмениваться петабайтами данных с коллегами по всему миру, но они сталкиваются с тем, что их тщательно продуманная многогигабитная инфраструктура часто выдаёт всего несколько мегабит в секунду на трансконтинентальных линиях. [6]

Эти проблемы возникли из-за выбора архитектуры, который был сделан при создании системы регулирования заторов TCP в 80-е годы — тогда потерю пакетов решили интерпретировать как «затор». [13] Эквивалентность этих понятий была справедливой для того времени, но только из-за ограничений технологии, а не по определению. Когда NIC (контроллеры сетевых интерфейсов) модернизировали с мегабитных до гигабитных скоростей, а микросхемы памяти — с килобайт до гигабайт, до связь между потерей пакетов и заторами стала менее очевидной.

В современном TCP регулирование заторов по потере пакетов — даже в наиболее совершенной технологии такого рода CUBIC [11] — основная причина этих проблем. Если буферы узких мест слишком большие, то система регулирования заторов по потере пакетов держит их полными, вызывая излишнюю сетевую буферизацию. Если буферы слишком маленькие, то система регулирования заторов по потере пакетов неверно интерпретирует потерю пакета как сигнал затора, что ведёт к снижению пропускной способности. Решение этих проблем требует альтернативы регулированию заторов по потере пакетов. Для нахождения этой альтернативы следует разобраться, где и как возникают заторы.

Друзья, совсем скоро, в 20:30 по Москве начнётся трансляция TensorFlow Developer Summit.

Кейноут будут вести такие люди такие люди как Jeff Dean, Rajat Monga и Megan Kacholia.
Очень рекомендую посмотреть данную трансляцию сегодня вечером всем кому интересна тема машинного обучения. Будет рассказано как про сам TensorFlow так и про интересные примеры его использования.

И вновь мы публикуем расшифровки выступлений с конференции HighLoad++, которая прошла в подмосковном Сколково 7—8 ноября 2016 года. Сегодня Евгений Пивень знакомит нас с решениями балансировки в облаках.



Меня зовут Женя, я работаю в компании IPONWEB. Сегодня мы поговорим про развитие наших решений в балансировке высоконагруженных систем.

Сначала я пробегусь по понятиям, которыми буду оперировать. Начнём с того чем мы занимается: RTB, Real Time Bidding — показ рекламы с аукционом в реальном времени. Очень упрощенная схема того, что происходит, когда вы заходите на сайт:

В первой статье мы говорили о том, как работала старая система доставки сообщений и тех уроках, которые мы вынесли из ее работы. Во этой (второй) статье мы расскажем об архитектуре новой системы и том, почему мы выбрали Google Cloud Pub/Sub в качестве транспортного механизма для всех событий.

Всякий раз, когда пользователь выполняет действие в клиенте Spotify – такое как, например, прослушивание песни или поиск исполнителя – небольшое количество информации, событие, отправляется на наши сервера. Доставка событий, процесс безопасной и надежной транспортировки информации от клиентов по всему миру к нашей центральной системе обработки, — интересная задача. В серии этих статей мы рассмотрим некоторые решения, которые реализовали в этой области. Если быть более точными, то мы рассмотрим архитектуру нашей новой системы доставки событий и расскажем, почему решили развернуть ее в Google Cloud.

В этой первой статье мы объясним то, как работает наша текущая система доставки событий и расскажем о некоторых уроках, которые извлекли в ходе работы с ней. В следующей – рассмотрим создание новой системы и то, почему мы выбрали Cloud Pub/Sub в качестве транспортного механизма для всех событий. В третьей, и последней, статье мы объясним, как работаем со всеми событиями с помощью DataFlow, и насколько быстро все это происходит.

Не ну Гугл — эт ну полная фигня:

1. При поиске «купить виагру», я не могу уже найти ни одного приличного спам-сайта!
2. GMail отправил письмо сына известного Нигерийского шейха в «Спам», а он мне предлагал 3% от 512 млн.евро!
3. Мне сказали, что Гугл Планета Земля — бесплатна, но отказываются рассказать как ее распродать!
4. Google Docs заявил, что я могу работать над документом вместе с любым человеком на земле. Я написал договор о передаче мне 50% акций и пригласил Сергея Брина поставить на нем подпись, оказывается Google Docs этого не может!
5. Google Maps не могут даже проложить ни одного наркомаршрута из России в Колумбию, не переплывая океан — 21 век, а живем как при Царе Горохе!
6. Когда я потерял своего Питона и пошел на гугл искать его — я выяснил все про замыкания и итераторы, но змейку так и не нашел. С горя я попросил Продуктовый Гугл найти мне яблочко, но дойдя до 32ой страницы, я понял, что, похоже, Американы жрут ноутбуки.