Чему учат падения Pokemon Go: геоданные в масштабе

Pokemon Go вышел в июле 2016 года и сразу стал одним из самых обсуждаемых инфраструктурных провалов года. У Niantic оказался продукт с геолокацией в реальном времени в масштабе, который мало кто пробовал раньше, и система несколько раз рухнула в первые недели. Ошибки сервера стали мемом, но суть проблемы была серьёзной: модель данных была спроектирована под определённую нагрузку, а в первый же день получила в десять раз больше.

Я пишу это не для того, чтобы критиковать инженеров Niantic. Я пишу потому, что несколько человек, с которыми я разговаривал тем летом, сказали примерно следующее: «ну это потребительское приложение, у нас такого не бывает». Мне кажется, это слишком поспешный вывод.

Что пошло не так технически

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

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

Niantic использовала инфраструктуру Google Cloud и работала с Google по масштабированию, но начальная модель не предполагала такой скорости поступления данных. Архитектуру пришлось перестраивать под огнём.

Почему это важно для не-потребительских приложений

Несколько реальных бизнес-областей имеют тот же паттерн: управление выездным обслуживанием, логистика и мониторинг автопарка, промышленный контроль датчиков, управление активами на складах или в портах. Это не игрушечные задачи.

Если у вас 200 выездных техников, которые отправляют геоданные каждые 30 секунд, а вы храните всё это в транзакционной реляционной базе, спроектированной под управление заказами, - вы в конечном счёте упрётесь в ту же стену. Просто медленнее и менее заметно, чем Niantic.

Вопросы, которые нужно задать до проектирования

Если в приложении есть компонент геолокации или датчиков, вопросы проектирования такие:

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

Ответы определяют, достаточно ли обычной реляционной базы или нужны специализированное time-series хранилище, пространственное расширение базы или потоковый конвейер перед ней.

Практическая рекомендация

Разделяйте геоданные и транзакционные данные с самого начала. Даже если оба хранятся в PostgreSQL - держите их в разных таблицах с разными стратегиями индексирования, разными политиками хранения и чётким планом на случай, когда таблица геоданных будет расти в десять раз быстрее остальной базы.

История Pokemon Go - крайний случай. Но инженерная ошибка, которую она иллюстрирует - недооценка объёма и скорости непрерывных данных - встречается часто. Урок не в том, что «не надо строить геофичи». Урок в том, что стоимость инфраструктуры нужно честно оценивать до того, как зафиксирована модель данных.