Blink: что под капотом приложения для мониторинга друзей

Максим Климчук

Co-Founder/CPO Blink. До этого запускал сервис для поиска работы рядом с домом Qwenty и предшественника Blink — соцсеть CheckYou.

На сайте приложения указано, что оно создано выходцами из Zenly. Получается, вы выступаете в роли «импортозаместителя»? Или Blink — самостоятельное решение, лишь вдохновленное французами?

После закрытия Zenly мы вместе с коллегами Димой Трачуком и Марией Мышь (ранее работала в Zenly), собрались и начали обдумывать создание своего приложения. К нам постепенно присоединились и другие специалисты, и мы продолжили формировать команду.

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

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

Какие основные функции и возможности предлагает Blink пользователям? Можем ли мы «бампнуться» по-старинке или отправить смайлик другу на весь экран?

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

Одна из новых возможностей Blink — функция отслеживания шагов. Теперь пользователи могут соревноваться друг с другом, сравнивая свою ежедневную активность. Эта опция стала возможной благодаря высокой точности геолокации.

Кроме того, в Blink реализована усовершенствованная система чекинов. При отметке пользователя в определенной локации, его друзьям тут же приходит push-уведомление. В Zenly данная функция работала менее эффективно, поэтому мы приняли решение о ее полной переработке.

Еще одна интересная особенность Blink — функция «трях», аналогичная «бампу» из Zenly. Теперь, чтобы сообщить друзьям о встрече, достаточно просто потрясти телефонами. Вообще, термин «бамп» в английском языке имеет сексуальный подтекст, поэтому для англоговорящей аудитории звучит так же странно, как «трях» для русскоязычной.

Какие программные платформы и языки программирования использовались для разработки Blink? Почему был выбран именно такой технологический стек?

Выбор стека связан с наличием специалистов на рынке, задачами и с высокими хайлоадом. В качестве основного языка веб-разработки мы выбрали компилируемый Golang, это современный стандарт для стартапов.

Помимо Golang, в стек входит ряд других ключевых инструментов. Для обработки потоков данных в режиме реального времени используется Apache Kafka, надежный и производительный брокер, с которым уже была знакома команда разработчиков и DevOps/SRE. Выбор Kafka обусловлен необходимостью надежной маршрутизации гигабайтов геопакетов в секунду.

В качестве основной базы данных выбран PostgreSQL, известный своей надежностью, производительностью и возможностью масштабироваться. Для кэширования данных используется Redis, а ClickHouse – для аналитики и обработки больших объемов данных, в том числе для пост-процессинга геокоординат. На данный момент объем данных в кластере приближается к 30 ТБ, и ClickHouse справляется с этой нагрузкой.

Для мобильных платформ мы используем Swift для iOS и Kotlin для Android.

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

Перейдем к конкретным фичам. Какие алгоритмы и методы используются для определения местоположения пользователей в Blink? Как вы обеспечиваете высокую точность геолокации?

В основе нашей работы лежит сбор данных с устройств пользователей и применение технологий геофенсинга. Хотя мы не изобретаем революционных решений, поскольку действуем в рамках закрытых операционных систем (iOS и Android), тщательно обрабатываем полученные данные, чтобы обеспечить их точность и надежность. Как происходит процесс?

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

Если координаты проходят наши фильтры, они отправляются на дальнейшую обработку. Но если выявляем проблемы по типу воздействия GPS-глушилок, применяем дополнительные этапы проверки.

Мы также проверяем, находится ли пользователь в знакомом окружении, например, в домашней сети Wi-Fi. Если данные указывают на аномальное перемещение, корректируем местоположение.

Стоит отметить, что в последнее время мы все чаще сталкиваемся с проблемами навигационных систем и GPS-глушилок. Поэтому разработали целый ряд фильтров и механизмов для обеспечения высокой точности геолокации. Кроме того, работаем над улучшением клиентской части, оптимизируя работу приложения для минимального потребления заряда аккумулятора. Blink в среднем потребляет всего 1% заряда в сутки, что является отличным показателем. Мы потратили много времени на это улучшение, и теперь приложение практически не тратит заряд, хотя работает в фоновом режиме.

Как реализована система хранения и обработки больших объемов геоданных в приложении? Какие технологии и подходы задействованы?

Мы внедрили два ключевых решения: Apache Kafka и ClickHouse.

Apache Kafka выступает в качестве надежного механизма передачи данных между различными сервисами. Он обеспечивает бесперебойную доставку координат пользователей, которые постоянно обрабатываются и анализируются приложением.

В свою очередь, ClickHouse — это высокопроизводительная аналитическая база данных, где мы храним всю историю передвижений наших пользователей. Это позволяет создавать уникальные решения, раскрывающие интересные закономерности и паттерны поведения людей. Например, мы можем показывать пользователям, где они чаще всего ночевали, с кем больше всего общались, какие места посещали и какие районы исследовали. Эти «цифровые следы» помогают людям лучше понимать свои привычки.

Стоит отметить, что объем накопленных нами данных уже превышает 30 терабайт. Это огромный массив информации, который требует применения современных Big Data решений, таких как Kafka и ClickHouse. Благодаря этому мы можем эффективно управлять и анализировать все эти данные, извлекая ценные инсайты и предоставляя полезный сервис нашим пользователям.

А что насчет самих пользователей? Как вы подходите к вопросам безопасности и конфиденциальности данных в Blink? Какие меры предприняты для защиты личной информации?

Мы применяем комплексный подход, сочетающий в себе передовые технологии шифрования и строгие меры контроля доступа.

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

Во-вторых, в компании регулярно проводится аудит безопасности. Мы тщательно контролируем, кто и к каким данным имеет доступ. Более того, любое обращение к конфиденциальным ресурсам, будь то подключение к базе данных из нестандартного местоположения, вызывает срабатывание системы оповещения. Таким образом, все действия с чувствительной информацией пользователей фиксируются в журнале регистрации и расцениваются как инциденты безопасности.

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

У нас есть два основных направления аналитики: клиентская и серверная.

Для клиентской аналитики мы используем как бесплатные, так и платные трекеры для отслеживания активности пользователей. Одним из ключевых инструментов является Amplitude, позволяющий собирать и анализировать данные о взаимодействии пользователей с приложением.

В части серверной аналитики:

• Все события, связанные с действиями пользователей, собираются и отправляются на наш сервер, где хранятся в базе данных ClickHouse. Это касается как клиентских, так и серверных событий.

• Собранные данные затем передаются в BI-системы, такие как Redash и Superset, для визуализации и построения дашбордов.

• Наши аналитики проверяют гипотезы и анализируют поведение пользователей. При этом данные обезличены, чтобы не нарушать конфиденциальность.

Один из последних кейсов:

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

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

С какими основными трудностями и вызовами вы сталкивались в процессе разработки и масштабирования Blink? Как вы их преодолевали?

Несмотря на стремительный рост, мы столкнулись с несколькими серьезными техническими вызовами:

1. Изначально, с нагрузкой в 10 тысяч онлайн-пользователей, наши го и легковесные горутины, а также оптимизированные веб-фреймворки справлялись с нагрузкой. Однако с ростом аудитории до 100 тысяч возникли проблемы на сетевом уровне, которые нашим инженерам удалось решить за счет переконфигурирования балансеров (nginx + sysctl). 
2. Для хранения географических данных мы выбрали PostgreSQL, но со временем объем этих данных превысил 1 ТБ, что привело к существенному падению производительности. Попытки горизонтально масштабировать PostgreSQL оказались малоэффективными, и в итоге мы перешли на Clickhouse, который гораздо лучше справился с этой задачей. Перевод на Clickhouse занял около недели, но куда больше времени потребовалось на миграцию данных из PostgreSQL. 
3. Недостаток мониторинга приводил к тому, что о проблемах мы узнавали уже тогда, когда они становились критическими и вызывали простои сервиса. Несколько бессонных ночей наглядно продемонстрировали важность использования инструментов вроде Grafana.

Несмотря на эти трудности, нам удалось преодолеть их и продолжить успешное развитие Blink. Опыт, полученный в ходе решения этих задач, стал для нас бесценным.

Каковы ваши планы на дальнейшее развитие приложения? Над какими новыми функциями и возможностями сейчас работаете?

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

Из больших сервисов, над которыми работаем сейчас — чекины. Это инструмент, который позволяет пользователям в реальном времени делиться своим местоположением, фотографиями и видео, рассказывая друзьям о том, где они находятся прямо сейчас. В ближайшем будущем планируем добавить элементы геймификации, например, возможность соревноваться за звание «мэра» в различных локациях, основываясь на частоте посещений.

Кроме того, мы разрабатываем собственную карту Blink Maps, которая будет интегрирована в приложение уже через несколько месяцев для некоторых устройств на Android. Это наша собственная 3D-карта, позволяющая решить технические ограничения, с которыми мы сталкиваемся при использовании платформенных карт, по типу Google Maps. Например, сможем более эффективно отображать больше пинов без задержек и сбоев. Карта будет регулярно обновляться, что позволит избегать проблем с устаревшей информацией. У нас свой движок, построенный на видеопроцессоре GPU, который на основе данных OpenStreetMap делает магию. Основу мы берем из OSM и поверх накручиваем все свои изменения.

Как вы считаете, какие тенденции и инновации будут определять развитие мобильных приложений для отслеживания местоположения в ближайшем будущем?

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

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

Однако, в свете этих тенденций, стоит учитывать, что Apple и Google, например, продолжают усложнять работу с геолокацией для сторонних разработчиков. Несмотря на наличие встроенных решений, таких как Find My Friends у Apple, ограничения и новые требования для работы с геоданными становятся все более жесткими. Это создает дополнительные вызовы для разработчиков, которые должны адаптироваться к меняющимся условиям и искать альтернативные пути стабильной работы своих приложений.