Привет, друзья!
Тернистый путь цифровой трансформации классического телеком-оператора большой тройки в современную IT-компанию. Как обеспечить интеграцию множества сервисов, разрабатываемых множеством команд, между собой и не допустить хаоса во взаимодействии – расскажет Алексей Коновкин (Nexign).
📋 https://clck.ru/bVYkk
Аутентификация и авторизация "всех со всеми", если у вас несколько поставщиков идентификационной информации (Identity Providers), множество сервисов, а безопасностью взаимодействия нельзя пренебречь.
"Купить или не купить — вот в чем вопрос". Вопрос выбора API Gateway, и почему они решили пойти своим путем.
🔹Ждем вас на HighLoad++ 17 и 18 марта в Москве. Подробное расписание и билеты на сайте – https://clck.ru/bVYmu
Тернистый путь цифровой трансформации классического телеком-оператора большой тройки в современную IT-компанию. Как обеспечить интеграцию множества сервисов, разрабатываемых множеством команд, между собой и не допустить хаоса во взаимодействии – расскажет Алексей Коновкин (Nexign).
📋 https://clck.ru/bVYkk
Аутентификация и авторизация "всех со всеми", если у вас несколько поставщиков идентификационной информации (Identity Providers), множество сервисов, а безопасностью взаимодействия нельзя пренебречь.
"Купить или не купить — вот в чем вопрос". Вопрос выбора API Gateway, и почему они решили пойти своим путем.
🔹Ждем вас на HighLoad++ 17 и 18 марта в Москве. Подробное расписание и билеты на сайте – https://clck.ru/bVYmu
Всем привет!
На конференции HighLoad++ выступит Юрий Печатнов из Яндекса.
📋 https://clck.ru/bVm8P
Его доклад будет о том, как они научились более эффективно передавать данные между своими сервисами.
С сохранением exactly once и отказоустойчивости они уменьшили материализацию потока промежуточных данных на дисках на 90% и примерно на столько же снизили latency.
Подробнее на простом примере:
Пусть у них есть много входных очередей (например, kafka) с событиями, каждое событие содержит идентификатор стейта StateId и относится к соответствующему стейту. И они хотят в реальном времени считать агрегаты произвольной сложности (= обновлять стейты) по входным событиям с семантикой exactly once.
Для эффективной работы такой схемы обновления стейтов в хранилище нужна какая-то локальность по ключам, поэтому входные данные нужно сначала пошардировать примерно так же, как шардированы данные в хранилище.
Тогда в этом простом случае получается, что нужно два сервиса: один читает входные события и пишет их в промежуточную очередь пошардировано (resharder), другой читает уже шардированные события и обновляет стейты в соответствии с ними (aggregator).
Что плохо в этой схеме? То, что весь поток событий необходимо писать через промежуточную очередь, а это большой поток на записи на диски и, соответственно, много железа! А ведь еще есть небольшая задержка.
То есть они решают проблему: как передать данные от resharder'а aggregator'у с наименьшей материализацией на дисках, с наименьшими задержками и при этом отказоустойчиво и с exactly once.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bVmRZ
На конференции HighLoad++ выступит Юрий Печатнов из Яндекса.
📋 https://clck.ru/bVm8P
Его доклад будет о том, как они научились более эффективно передавать данные между своими сервисами.
С сохранением exactly once и отказоустойчивости они уменьшили материализацию потока промежуточных данных на дисках на 90% и примерно на столько же снизили latency.
Подробнее на простом примере:
Пусть у них есть много входных очередей (например, kafka) с событиями, каждое событие содержит идентификатор стейта StateId и относится к соответствующему стейту. И они хотят в реальном времени считать агрегаты произвольной сложности (= обновлять стейты) по входным событиям с семантикой exactly once.
Для эффективной работы такой схемы обновления стейтов в хранилище нужна какая-то локальность по ключам, поэтому входные данные нужно сначала пошардировать примерно так же, как шардированы данные в хранилище.
Тогда в этом простом случае получается, что нужно два сервиса: один читает входные события и пишет их в промежуточную очередь пошардировано (resharder), другой читает уже шардированные события и обновляет стейты в соответствии с ними (aggregator).
Что плохо в этой схеме? То, что весь поток событий необходимо писать через промежуточную очередь, а это большой поток на записи на диски и, соответственно, много железа! А ведь еще есть небольшая задержка.
То есть они решают проблему: как передать данные от resharder'а aggregator'у с наименьшей материализацией на дисках, с наименьшими задержками и при этом отказоустойчиво и с exactly once.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bVmRZ
Всем привет!
Как наладить CI-процесс в монорепозитории и сохранить спокойствие разработчиков – расскажет Алина Власова. Она работает в “Лаборатории Касперского” c 2015 года. В данный момент является руководителем группы, занимающейся разработкой инфраструктуры для непрерывной интеграции.
📋 https://clck.ru/bd3C5
Несколько лет тому назад в Лаборатории Касперского приняли решение переехать в монорепозиторий с собственной инфраструктурой. В докладе Алина расскажет о том, как это решение повлияло на жизнь разработчиков и на скорость доставки изменений в код.
Вы узнаете о том, как у них устроен CI-процесс, какие преимущества они получили и с какими проблемами столкнулись. Какие инструменты и мониторинги используют для того, чтобы повышать работоспособность данного процесса и создавать комфортные условия для разработчиков, вносящих изменения в код.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bd3CV
Как наладить CI-процесс в монорепозитории и сохранить спокойствие разработчиков – расскажет Алина Власова. Она работает в “Лаборатории Касперского” c 2015 года. В данный момент является руководителем группы, занимающейся разработкой инфраструктуры для непрерывной интеграции.
📋 https://clck.ru/bd3C5
Несколько лет тому назад в Лаборатории Касперского приняли решение переехать в монорепозиторий с собственной инфраструктурой. В докладе Алина расскажет о том, как это решение повлияло на жизнь разработчиков и на скорость доставки изменений в код.
Вы узнаете о том, как у них устроен CI-процесс, какие преимущества они получили и с какими проблемами столкнулись. Какие инструменты и мониторинги используют для того, чтобы повышать работоспособность данного процесса и создавать комфортные условия для разработчиков, вносящих изменения в код.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bd3CV
💥 Кто получит премию HighLoad++ Award 2022? Решать вам!
Ранее мы объявляли о наборе номинантов на премию HighLoad++, в котором мог принять участие каждый, кто оказал положительное влияние в развитие экосистемы интернет-разработки.
Экспертный совет произвел первичный отбор поданных заявок. И теперь все номинанты, прошедшие фильтр – попали в закрытое голосование.
В голосовании могут принять участие абсолютно все, необходимо зайти на сайт голосования, авторизироваться через соцсеть и отдать свой голос в одной номинации или нескольких.
✅ Голосование будет проходить до 20 февраля.
Переходите по ссылке 👉 https://clck.ru/auCAr и оставляйте свой голос за лучшего!
Ранее мы объявляли о наборе номинантов на премию HighLoad++, в котором мог принять участие каждый, кто оказал положительное влияние в развитие экосистемы интернет-разработки.
Экспертный совет произвел первичный отбор поданных заявок. И теперь все номинанты, прошедшие фильтр – попали в закрытое голосование.
В голосовании могут принять участие абсолютно все, необходимо зайти на сайт голосования, авторизироваться через соцсеть и отдать свой голос в одной номинации или нескольких.
✅ Голосование будет проходить до 20 февраля.
Переходите по ссылке 👉 https://clck.ru/auCAr и оставляйте свой голос за лучшего!
Привет, друзья!
В своем докладе Андрей Аксенов (Авито, Sphinx) поделится, как они в порядке эксперимента выжимали 1 миллион запросов в секунду из 1 физического сервера и СУБД, никогда при этом НЕ рассчитанной на именно такой workload (спойлер: СУБД всё ещё Сфинкс).
📋 https://clck.ru/bfrRy
На выступлении узнаем:
- Почему выжимали именно ~1 миллион (а не ~0.1 или ~10м).
- В каких местах обнаружились тормоза (спойлер: в разных и поначалу несколько удивительных).
- Как получилось подлечить 3+ места с разумной трудоемкостью и немедленно закатить эти успехи в бой (тизеры: не обошлось без пары строчек ассемблера, причем, что удивительно, сервер Intel, а ассемблер понадобился ARM; не обошлось без легких лок-фри-фокусов; не обошлось без переписывания простеньких системных вызовов вручную и прочей легкой наркомании).
- Чего в итоге получилось.
- Где ещё есть известные диоды, которые уже так просто не залечить.
- Ну и совсем вкратце — как теоретически атаковать следующие вершины (10+ миллионов RPS).
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bfrn5
В своем докладе Андрей Аксенов (Авито, Sphinx) поделится, как они в порядке эксперимента выжимали 1 миллион запросов в секунду из 1 физического сервера и СУБД, никогда при этом НЕ рассчитанной на именно такой workload (спойлер: СУБД всё ещё Сфинкс).
📋 https://clck.ru/bfrRy
На выступлении узнаем:
- Почему выжимали именно ~1 миллион (а не ~0.1 или ~10м).
- В каких местах обнаружились тормоза (спойлер: в разных и поначалу несколько удивительных).
- Как получилось подлечить 3+ места с разумной трудоемкостью и немедленно закатить эти успехи в бой (тизеры: не обошлось без пары строчек ассемблера, причем, что удивительно, сервер Intel, а ассемблер понадобился ARM; не обошлось без легких лок-фри-фокусов; не обошлось без переписывания простеньких системных вызовов вручную и прочей легкой наркомании).
- Чего в итоге получилось.
- Где ещё есть известные диоды, которые уже так просто не залечить.
- Ну и совсем вкратце — как теоретически атаковать следующие вершины (10+ миллионов RPS).
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bfrn5
👍1
Привет, друзья!
В докладе Тимура Давыдова (Московская Биржа) рассмотрим архитектуру современной торгово-клиринговой системы (ТКС) и более подробно познакомимся с in-memory-базой данных, оптимизированной для работы с низкими и предсказуемыми задержками, предназначенными для хранения информации во время работы ТКС.
📋 https://clck.ru/bggxi
В связи с изменением поведения рынков со временем и требованием хранения большего количества информации, были сделаны оптимизации как в самом представлении данных, так и в организации базы данных. Но одна проблема все еще оставалась нерешенной — это выделение оптимального объема памяти для каждой таблицы БД с расчетом на худший случай.
Поэтому в докладе также будут рассмотрены способы увеличения объема непрерывной области данных в памяти и предложена оптимальная реализация технологии динамического увеличения непрерывной области данных в памяти за константное время. Также будет рассмотрен опыт внедрения и применения данной технологии в реальных условиях. Отдельное внимание будет уделено решению проблем, возникших в процессе реализации и тестирования.
📍Спешите запланировать своё участие в HighLoad++. Расписание и билеты - https://clck.ru/bghNU
В докладе Тимура Давыдова (Московская Биржа) рассмотрим архитектуру современной торгово-клиринговой системы (ТКС) и более подробно познакомимся с in-memory-базой данных, оптимизированной для работы с низкими и предсказуемыми задержками, предназначенными для хранения информации во время работы ТКС.
📋 https://clck.ru/bggxi
В связи с изменением поведения рынков со временем и требованием хранения большего количества информации, были сделаны оптимизации как в самом представлении данных, так и в организации базы данных. Но одна проблема все еще оставалась нерешенной — это выделение оптимального объема памяти для каждой таблицы БД с расчетом на худший случай.
Поэтому в докладе также будут рассмотрены способы увеличения объема непрерывной области данных в памяти и предложена оптимальная реализация технологии динамического увеличения непрерывной области данных в памяти за константное время. Также будет рассмотрен опыт внедрения и применения данной технологии в реальных условиях. Отдельное внимание будет уделено решению проблем, возникших в процессе реализации и тестирования.
📍Спешите запланировать своё участие в HighLoad++. Расписание и билеты - https://clck.ru/bghNU
Всем привет!
Что могут C и C++, и когда нужен ассемблер – узнаем у Александра Крижановского. Он является основателем и системным архитектором Tempesta Technologies, экспертом в области высокопроизводительных вычислений в Linux/x86-64.
📋 https://clck.ru/bkrkK
C и C++ известны скоростью сгенерированного кода. Однако, код генерируется конкретным компилятором под конкретную ОС на конкретное железо. Расширения компиляторов позволяют генерировать еще более быстрый код, чем для "чистых" C и C++. Микропроцессоры тоже предоставляют свои расширения, которые недоступны даже для расширений компилятора и для использования которых нужен ассемблер.
В этом докладе Александр посмотрит, какой код генерируют GCC и Clang для некоторых C и C++ конструкций и как сделать этот код быстрее. Также он копнет в специфичные для x86-64 оптимизации. Обсудит микробенчмарки.
А еще узнаем:
- Как x86-64 исполняет код и как работает с памятью.
- Некоторые полезные расширения и оптимизации GCC и Clang для C и C++.
- Когда ассемблер x86-64 не только быстрее, но и проще C.
- Скользкие места программирования для многоядерных архитектур.
- Защита от Spectre в компиляторах.
- Profiler guided optimization (PGO) и когда она бесполезна.
📍До встречи на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bkrkm
Что могут C и C++, и когда нужен ассемблер – узнаем у Александра Крижановского. Он является основателем и системным архитектором Tempesta Technologies, экспертом в области высокопроизводительных вычислений в Linux/x86-64.
📋 https://clck.ru/bkrkK
C и C++ известны скоростью сгенерированного кода. Однако, код генерируется конкретным компилятором под конкретную ОС на конкретное железо. Расширения компиляторов позволяют генерировать еще более быстрый код, чем для "чистых" C и C++. Микропроцессоры тоже предоставляют свои расширения, которые недоступны даже для расширений компилятора и для использования которых нужен ассемблер.
В этом докладе Александр посмотрит, какой код генерируют GCC и Clang для некоторых C и C++ конструкций и как сделать этот код быстрее. Также он копнет в специфичные для x86-64 оптимизации. Обсудит микробенчмарки.
А еще узнаем:
- Как x86-64 исполняет код и как работает с памятью.
- Некоторые полезные расширения и оптимизации GCC и Clang для C и C++.
- Когда ассемблер x86-64 не только быстрее, но и проще C.
- Скользкие места программирования для многоядерных архитектур.
- Защита от Spectre в компиляторах.
- Profiler guided optimization (PGO) и когда она бесполезна.
📍До встречи на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bkrkm
Привет, друзья!
Продолжаем знакомить вас со спикерами HighLoad++. Одним из них станет Александр Ляпунов (VK).
📋 https://clck.ru/bm63K
В своем докладе он расскажет, как они используют msgpack в асинхронном сетевом протоколе СУБД и сервера приложений Tarantool в целом и о реализации его клиентской части (коннектора) на С++, в частности.
Для коммуникации с базами данных проблемой является заранее неизвестная структура данных, а если рассматривать Tarantool в контексте сервера приложений, то задача становится фактически реализацией протокола RPC с неопределенным набором функций. Другими словами, при реализации сервера и коннектора к нему структура и набор данных не определены. Для такого динамического протокола хорошо подошел msgpack, однако это принесло сложности в разработке и затронуло быстродействие системы.
У коннектора, вдобавок к динамичности, есть еще одна проблема — встраиваемость в существующую кодовую базу приложения. По-хорошему, нужно сделать так, чтобы вне зависимости от того, что использует приложение — блокирующее I/O, epoll, другие событийные циклы, файберы — можно было бы удобно использовать коннектор.
В этом докладе Александр попробует поделиться решениями этих и других проблем, а также просто опытом создания подобных систем.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bm63a
Продолжаем знакомить вас со спикерами HighLoad++. Одним из них станет Александр Ляпунов (VK).
📋 https://clck.ru/bm63K
В своем докладе он расскажет, как они используют msgpack в асинхронном сетевом протоколе СУБД и сервера приложений Tarantool в целом и о реализации его клиентской части (коннектора) на С++, в частности.
Для коммуникации с базами данных проблемой является заранее неизвестная структура данных, а если рассматривать Tarantool в контексте сервера приложений, то задача становится фактически реализацией протокола RPC с неопределенным набором функций. Другими словами, при реализации сервера и коннектора к нему структура и набор данных не определены. Для такого динамического протокола хорошо подошел msgpack, однако это принесло сложности в разработке и затронуло быстродействие системы.
У коннектора, вдобавок к динамичности, есть еще одна проблема — встраиваемость в существующую кодовую базу приложения. По-хорошему, нужно сделать так, чтобы вне зависимости от того, что использует приложение — блокирующее I/O, epoll, другие событийные циклы, файберы — можно было бы удобно использовать коннектор.
В этом докладе Александр попробует поделиться решениями этих и других проблем, а также просто опытом создания подобных систем.
✅ Встречаемся на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bm63a
👍1
Всем привет!
Про статистический анализ кода++ поговорим с Анастасией Казаковой из JetBrains.
📋 https://clck.ru/bmEpE
Если судить по опросу C++ Foundation, то проблемы безопасности кода на C++, ошибки при работе с памятью и прочие типичные "боли" языка — все еще самые актуальные для разработчиков на C++. При этом, как известно, софт более высокого качества обходится дешевле в создании (а не только в поддержке, как можно было бы подумать).
В своем докладе Анастасия обсудит некоторые примеры типичных проблем, рассмотрит, что сейчас предлагает язык (интересно, что несмотря на очень активное развитие инструментов статического анализатора кода, многие предложения направлены именно на внесение дополнительной аналитики в сам компилятор языка), и выяснит, что же умеют современные статические анализаторы, и как далеки компиляторы от "счастливого и безопасного" будущего в C++.
📍Ждем вас на HighLoad++ 17 и 18 марта в Москве. Подробное расписание и билеты на сайте – https://clck.ru/bmEpj
Про статистический анализ кода++ поговорим с Анастасией Казаковой из JetBrains.
📋 https://clck.ru/bmEpE
Если судить по опросу C++ Foundation, то проблемы безопасности кода на C++, ошибки при работе с памятью и прочие типичные "боли" языка — все еще самые актуальные для разработчиков на C++. При этом, как известно, софт более высокого качества обходится дешевле в создании (а не только в поддержке, как можно было бы подумать).
В своем докладе Анастасия обсудит некоторые примеры типичных проблем, рассмотрит, что сейчас предлагает язык (интересно, что несмотря на очень активное развитие инструментов статического анализатора кода, многие предложения направлены именно на внесение дополнительной аналитики в сам компилятор языка), и выяснит, что же умеют современные статические анализаторы, и как далеки компиляторы от "счастливого и безопасного" будущего в C++.
📍Ждем вас на HighLoad++ 17 и 18 марта в Москве. Подробное расписание и билеты на сайте – https://clck.ru/bmEpj
Привет, друзья!
На выступлении Данилы Смирнова обсудим поиск в HeadHunter: как подружить machine learning и production.
📋 https://clck.ru/bmFba
Современные web-сервисы уже практически немыслимы без машинного обучения. Тем не менее эффективное использование в production ML-моделей может быть сопряжено с большим количеством задач на построение архитектуры приложения или оптимизации производительности, которые практически не встречаются в обычной разработке и для которых ещё не выработали стандартных решений.
Именно с такими задачами столкнулись в HeadHunter во время внедрения машинного обучения в сервис поиска, и на примере чего хочется обсудить возникшие проблемы и их решения:
- для взаимодействия между обучением моделей на python и инференсом на java;
- для оптимизации архитектурных решений на java для сложных моделей;
- поведенческие признаки в production;
- а также java и mmap, сериализация и обмен данными между python и java.
✅ До встречи на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bmFR3
На выступлении Данилы Смирнова обсудим поиск в HeadHunter: как подружить machine learning и production.
📋 https://clck.ru/bmFba
Современные web-сервисы уже практически немыслимы без машинного обучения. Тем не менее эффективное использование в production ML-моделей может быть сопряжено с большим количеством задач на построение архитектуры приложения или оптимизации производительности, которые практически не встречаются в обычной разработке и для которых ещё не выработали стандартных решений.
Именно с такими задачами столкнулись в HeadHunter во время внедрения машинного обучения в сервис поиска, и на примере чего хочется обсудить возникшие проблемы и их решения:
- для взаимодействия между обучением моделей на python и инференсом на java;
- для оптимизации архитектурных решений на java для сложных моделей;
- поведенческие признаки в production;
- а также java и mmap, сериализация и обмен данными между python и java.
✅ До встречи на HighLoad++ 17 и 18 марта в Москве. Подробная информация и билеты на сайте – https://clck.ru/bmFR3
Всем привет!
На выступлении Вадима Щемелинина из СИБУР Диджитал обсудим рабочую видеоаналитику в нефтехимии.
📋 https://clck.ru/bmm7K
Три года назад перед командой поставили цель: все видеокамеры в нефтехимическом холдинге СИБУР должны выводиться на экран операторам только тогда, когда в зоне их видимости "что-то идёт не так". За это время разработчики не раз посетили заводы, изучили производственные процессы, разработали и внедрили систему, которая покрыла 70% камер.
В своем докладе Вадим расскажет про сложности, с которыми сталкиваются Python-разработчики, внедряя машинное зрение в индустрии. Заводов в холдинге много, они большие, очень разные, и на них постоянно происходят различные изменения. Поэтому вызовов перед командой разработки стояло много.
✅ Встречаемся 17 и 18 марта в Москве, в Крокус Экспо. И, если вы еще не купили билет, то самое время это сделать 👉https://clck.ru/bmm7j
На выступлении Вадима Щемелинина из СИБУР Диджитал обсудим рабочую видеоаналитику в нефтехимии.
📋 https://clck.ru/bmm7K
Три года назад перед командой поставили цель: все видеокамеры в нефтехимическом холдинге СИБУР должны выводиться на экран операторам только тогда, когда в зоне их видимости "что-то идёт не так". За это время разработчики не раз посетили заводы, изучили производственные процессы, разработали и внедрили систему, которая покрыла 70% камер.
В своем докладе Вадим расскажет про сложности, с которыми сталкиваются Python-разработчики, внедряя машинное зрение в индустрии. Заводов в холдинге много, они большие, очень разные, и на них постоянно происходят различные изменения. Поэтому вызовов перед командой разработки стояло много.
✅ Встречаемся 17 и 18 марта в Москве, в Крокус Экспо. И, если вы еще не купили билет, то самое время это сделать 👉https://clck.ru/bmm7j
👍1
Всем привет!
Как запускали компьютерное зрение для офисов продаж МТС по всей России – расскажет Кирилл Овчинников.
📋 https://clck.ru/bmxDv
Компьютерное зрение все больше проникает в бизнес-процессы больших компаний. Большая часть проектов реализуется на серверах с GPU с хорошим интернетом и охлаждением. Но есть множество ситуаций, когда запуск модели и обработку видео надо сделать как можно ближе к камере: например, если нет стабильного интернета или если служба безопасности не санкционирует передачу видео на сервера.
В МТС более 5000 точек продаж. "Ручной" подсчет количества посетителей и сбор другой аналитический информации в режиме реального времени и в таком масштабе не представляется возможным.
В своем докладе Кирилл расскажет, как они смогли запустить AI-сервис компьютерного зрения на EDGE-устройствах в 500 точках продаж МТС, с какими подводными камнями они столкнулись и как смогли поддерживать весь флот устройств в актуальном состоянии и выполнять задачи бизнеса с нужной точностью.
⚡️Спешите запланировать своё участие в HighLoad++. С 1 марта будет повышение цен! Расписание и билеты - https://clck.ru/bmxEd
Как запускали компьютерное зрение для офисов продаж МТС по всей России – расскажет Кирилл Овчинников.
📋 https://clck.ru/bmxDv
Компьютерное зрение все больше проникает в бизнес-процессы больших компаний. Большая часть проектов реализуется на серверах с GPU с хорошим интернетом и охлаждением. Но есть множество ситуаций, когда запуск модели и обработку видео надо сделать как можно ближе к камере: например, если нет стабильного интернета или если служба безопасности не санкционирует передачу видео на сервера.
В МТС более 5000 точек продаж. "Ручной" подсчет количества посетителей и сбор другой аналитический информации в режиме реального времени и в таком масштабе не представляется возможным.
В своем докладе Кирилл расскажет, как они смогли запустить AI-сервис компьютерного зрения на EDGE-устройствах в 500 точках продаж МТС, с какими подводными камнями они столкнулись и как смогли поддерживать весь флот устройств в актуальном состоянии и выполнять задачи бизнеса с нужной точностью.
⚡️Спешите запланировать своё участие в HighLoad++. С 1 марта будет повышение цен! Расписание и билеты - https://clck.ru/bmxEd