Зачем? Это странно...

Нет, не странно! Google Maps — это, наверно, самый потрясающий сервис, который мы получаем бесплатно [в обмен на свои персональные данные].

Я пользуюсь им почти каждый день, он невероятно полезен для ориентирования на местности.

Но что, если бы нам вообще не нужен был Google?

OpenStreetMap бесплатно предоставляет всему миру данные карт, собранные при помощи краудсорсинга. Но я не имею в виду, что можно просто воспользоваться OSM. Эта организация предоставляет данные, однако политика использования стимулирует пользователей не полагаться на её серверы при личном пользовании, а брать на себя ответственность за хостинг. И глядя на этот проект, я понимаю, почему. Его аппаратные требования не для слабонервных.

Оборудование

У меня есть игровой PC, который чаще всего простаивает без дела. В последнее время мы с подругой предпочитаем играть на диване в кооперативные игры на Switch, а не на PC в разных комнатах. Я подумал, что можно воспользоваться этим довольно мощным десктопом и превратить его в сервер карт.

Внутри этого десктопа находится следующая начинка:

• Процессор Intel i7 gen 10700kf
• 32 ГБ ОЗУ
• NVMe SSD на 1 ТБ
• GPU GTX 2070
• Блок питания на 750 Вт

Примерно два года назад я купил его за $1270.

Чтобы отвечать высоким требованиям к серверу карт для всего мира, я дополнительно купил 128 ГБ ОЗУ и поставил их вместо 32 ГБ. Так общая стоимость оборудования увеличилась до $1670.

Это довольно высокая цена для самостоятельного хостинга, однако стоит отметить, что требования приблизительно пропорциональны географическим границам данных. Если вы захотите самостоятельно хостить сервис карт для меньшего региона (европейской страны или нескольких штатов США), то это возможно сделать на гораздо более скромном компьютере.

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

Требования

Что нужно, чтобы конкурировать с Google Maps? По-моему, есть три основных требования:

• «Скользящая» карта, которую можно интерактивно перетаскивать и менять её масштаб
• Возможность прокладывания маршрутов от точки к точке
• Возможность поиска мест

Эти задачи можно решить примерно тремя сервисами:

• сервер тайлов (строго говоря, здесь задействуется несколько сервисов)
• сервис прокладывания маршрутов valhalla
• сервис геокодирования nominatim

Реализация

Для реализации я создал репозиторий github, чтобы сгруппировать эти базовые сервисы и запускать их при помощи docker-compose.

Репозиторий находится здесь.

Соединить вместе эти докеризованные сервисы в одном docker-compose оказалось на удивление просто.

В README этих сервисов рекомендуется перед запуском контейнеров создать отдельный том docker. Это полезно, потому что импортирование может занять очень много времени (для данных всей планеты — несколько дней).

Изначально я попытался импортировать весь файл planet.osm.pbf, который сейчас весит 66 ГБ. Однако импортирование постоянно завершалось сбоями, поэтому я ограничил масштаб своего проекта только данными Северной Америки.

Если в ближайшее время мне понадобится поехать за границу, я просто буду пользоваться Google Maps.

Данные Северной Америки занимают в сжатом формате protobuf всего 12 ГБ, поэтому я смог запустить для них все три сервиса.

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

Чтобы понять, сколько в итоге занято места на диске, я выполнил следующую команду:

docker system df -v

По её выводу стало понятно, почему я не могу импортировать всю планету.

VOLUME NAME      LINKS     SIZE
nominatim-data   1         291.9GB
osm-data         2         337.8GB
osm-tiles        1         203.3MB
valhalla-data    2         37.6GB

Даже при меньшем объёме извлечённых данных эти сервисы уже заняли большую часть моего SSD на 1 ТБ (суммарно 667 ГБ). Если считать, что занимаемое пространство увеличивается пропорционально, то на всю планету мне бы понадобилось примерно 3,7 ТБ на накопителе. Не говоря уже о том, что требования к ОЗУ тоже увеличиваются.

Webapp

Также я внёс некоторые изменения в веб-приложение Valhalla, чтобы дополнить layout для мобильных устройств более отзывчивым UI. Эти изменения даже добавили в основной репозиторий! Open source — замечательная вещь.

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

Это демо можно найти здесь: https://map-demo.wcedmisten.dev.

Скриншоты демо

Прокладывание маршрутов:


Изохроны:

Конфигурирование сервера

Чтобы передавать трафик за пределы моей локальной сети, нужно настроить дополнительные конфигурации.

Включаем DDNS

Поскольку Интернет-провайдер не предоставляет мне статический IP-адрес, пришлось воспользоваться клиентом Dynamic Domain Name Service, обновляющим мои записи DNS так, чтобы они указывали на текущий IP-адрес моего роутера. Так как адрес не статический, провайдер время от времени сбрасывает выделенный мне IP-адрес. Я воспользовался ddclient. Он обеспечивает меньшую надёжность по сравнению со статическим IP, однако для моего сервера, используемого для хобби-разработок, её вполне достаточно.

Nginx

Чтобы обслуживать трафик в различных поддоменах наподобие maps.wcedmisten.dev, я настроил Nginx, передающий трафик каждому поддомену в нужный порт, сконфигурированный в docker-compose.yml. Также я использовал команду certbot для автоматической генерации сертификата из LetsEncrypt для каждого поддомена и обновления конфигурации Nginx. Эта часть тоже оказалась довольно беспроблемной.

Вот как эта часть /etc/nginx/sites-available/default выглядела до выполнения certbot, добавившего дополнительную конфигурацию для обработки https.

server {
    server_name maps.wcedmisten.dev;
    location / {
        proxy_set_header Host $host;
        proxy_pass http://127.0.0.1:8080;
        proxy_redirect off;
    }
}

server {
    server_name valhalla.wcedmisten.dev;
    location / {
        proxy_set_header Host $host;
        proxy_pass http://127.0.0.1:8002;
        proxy_redirect off;
    }
}

Переадресация портов

Наконец, чтобы получать внешний трафик из подключенного к моему компьютеру (и конкретно к Nginx) Интернета, мне нужно было настроить в роутере переадресацию портов. Интерфейс администратора Netgear отображает каждое подключенное к сети устройство, поэтому мне достаточно было перенаправить на компьютер порты 80 (HTTP) и (443). Эта операция оказалась намного проще, чем я ожидал.

Сравнение затрат

Для создания приблизительной альтернативы Google Maps требуется много памяти, однако, строго говоря, это вполне возможно на оборудовании потребительского уровня и с приличным доходом пользователя.

Затраты на Google Maps API

На момент написания статьи Google Maps каждый месяц позволяет бесплатно пользоваться Maps API на первые $200. Также сервис позволяет неограниченно пользоваться встроенным Google Maps API, отображающим на сайте интерактивную карту. Однако эти условия исключительно для использования в вебе. Стоимость для iOS/Android составляет $7/1000 запросов.

API прокладывания маршрутов (не включая данные трафика) стоит $5/1000 запросов.

API геокодирования тоже стоит $5/1000 запросов.

По грубым прикидкам мы можем предположить, что каждый посетитель, пользующийся веб-приложением, в среднем ищет два места (геокодирование),
загружает встроенную карту и выполняет запрос на построение маршрута. Это значит, что на каждые 1000 посетителей тратится $15 от кредитов API.

Иными словами, бесплатный тариф может поддерживать примерно 13 тысяч посетителей в месяц, если предположить, что каждый посетитель пользуется приложением минимально. После завершения бесплатных кредитов каждый посетитель будет стоить нам $0,015.

Затраты на самостоятельный хостинг

• Доменное имя: $1,43/месяц
• Счёт Интернет-провайдера: $69,99/месяц
• PC: $1670 (единовременно)
• Итого: $1670 единовременно + $71,42/месяц

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

• Итого: ($1670/24) + $71,42 = $141,00/месяц

«Самостоятельный хостинг» в облаке

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

Дроплет DigitalOcean (оптимизация по памяти):

• 128 ГБ ОЗУ, 16 vCPU, SSD на 1170 ГБ — $832,00/месяц
• Итого — $832,00/месяц

Инстанс AWS r6a.4xlarge EC2:

• 128 ГБ ОЗУ, 16 vCPU — $653,18/месяц
• SSD на 1 ТБ — $82,24/месяц
• Итого — $735,42/месяц

Инстанс Azure D32as v5 VM:

• 128 ГБ ОЗУ, 32 vCPU — $1004,48/месяц
• SSD на 1 ТБ — $122,88/месяц
• Итого — $1127,36/месяц

Сравнение самостоятельного хостинга и Google Maps API

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

Но как насчёт Google Maps API? Бесплатных кредитов Google достаточно, чтобы обслужить 13 тысяч посетителей в месяц! Это большой объём трафика. Когда же имеет смысл организовывать собственный хостинг на моём «железе»?

13 тысяч.

Выше мы говорили, что после превышения бесплатного тарифа каждый посетитель будет стоить $0,015 за Google API. А если считать, что самостоятельный хостинг стоит $141,00/месяц, то чтобы быть равными по показателям, нам нужно 141,00/0,015 = 9400 дополнительных посетителей.

Суммарно 9400 + 13000 = 22400 посетителей в месяц.

22400 в месяц — это примерно 747 в день, или по одному пользователю раз в две минуты.

Я вполне уверен, что моя машина сможет справиться с таким объёмом трафика.

Проблема сравнения этих чисел такая же, как и при сравнении затрат на самостоятельный хостинг с затратами на облако. Нюанс заключается в той ценности, которую даёт сервис Google Maps: экспертиза, масштабируемость и проприетарные данные карт.

Но мне кажется, для подобных хобби-проектов самостоятельный хостинг вполне имеет смысл.

Даже при профессиональном использовании стоит всё подсчитать. Благодаря docker установка этих сервисов существенно упрощается, пусть и занимает какое-то время. Здесь мы также предполагаем очень несущественную API-нагрузку на карту. Если предположить, что пользование сервисами карт будет более активным, выигрыш может возникнуть даже ещё раньше. Особенно в случае приложения, требующего пакетной обработки больших массивов данных.