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

Кто-нибудь имеет опыт работы с веб-картами (сервер плиток + JS-сценарии клиента) в Amazon Web Services (S3, EC2 и т. Д.)? Какая конфигурация AWS необходима для запуска приложения веб-карты с низкой и средней пропускной способностью, охватывающего небольшую (-ish) область (от города до размера маленькой страны)?

Все плитки будут предварительно обработаны и загружены на S3. В идеале на веб-сервере мне понадобилось бы приложение для подачи листов, которое могло бы обслуживать MBTiles (вместо загрузки сотен тысяч растровых изображений по отдельности). Так что нужен был бы какой-нибудь экземпляр EC2, но какой?

Спасибо за любые подсказки.

ОБНОВЛЕНИЕ: просто, чтобы уточнить мой вопрос. В основном мне нужны отзывы о том, насколько жизнеспособен AWS для размещения ваших собственных веб-карт как отдельного лица (что означает, что он не должен стоить слишком дорого, скажем, до 30 долларов в месяц). Некоторое время я размещал свои веб-карты через «обычных» хостинг-провайдеров, но у них есть свои ограничения (пропускная способность загрузки - одна, скорость - другая). Я также ищу любые хорошие альтернативы AWS и все, на что следует обратить внимание при использовании облачных сервисов для веб-карт.

При выборе архитектуры для службы, которая в значительной степени опирается на «классическую» архитектуру, такую ​​как веб-карты, никогда не стоит недооценивать эффективность более традиционных хостинговых решений, таких как RackSpace Cloud Servers или Linode .

У вас будет гораздо меньше вариантов выбора (например, использовать S3 или нет, балансировщики нагрузки или нет, резервные копии и т. Д. Или нет, и сколько это будет стоить?), Чей результат трудно предсказать И, что более важно, вы сможете используйте инструменты, с которыми вы уже знакомы.

Пройдя через то же самое, я могу сказать вам, что решающими факторами в моем решении разместить сервис веб-карт в Rackspace, а не в AWS, были:

1. Облачный сервер (более) устойчив, чем экземпляры EC2. Экземпляры EC2 фактически ожидается на провал , и они будут терпеть неудачу
2. Тома EBS тоже терпят неудачу (в новостях много печальных историй) и вообще имеют плохой ввод / вывод
3. если вы не выберете более крупные экземпляры, конфликт ввода-вывода может стать проблемой (особенно, если вы планируете заполнять плитки на EC2, а не копировать их). Это также может быть проблемой с базами данных MTBtiles.
4. Каждый раз, когда вы перезагружаете свой сервер, публичный ip будет меняться: это не происходит в Linode или Rackspace
5. Вам придется самостоятельно придумать стратегию резервного копирования и восстановления, в то время как и Linode, и Rackspace предоставляют автоматические моментальные и ежедневные моментальные снимки и восстановления, которые можно нажимать и щелкать.
6. Если на хосте, на котором работает ваш VPS, происходит сбой, Rackspace позаботится о перемещении вашего экземпляра и перезапуске его на другом сервере, и они сделают это за 4 часа (это в их SLA). Это случилось со мной, когда я был в отпуске: это было очень профессионально. Линод должен сделать то же самое
7. Linode имеет SLA высокой доступности: 99,9%, и они заявляют о высокой производительности, потому что они не обеспечивают слишком много
8. Rackspace недавно разработал стратегию томов, такую ​​как EBS, поэтому дисковое пространство больше не должно быть проблемой. Раньше, если вам нужно было много места на диске, вы ДОЛЖНЫ получить большой экземпляр, тогда как в EC2 вы можете выделить память, процессор и память с более точным управлением.

При этом я не говорю, что Amazon AWS уступает другим, я просто говорю, что иногда традиционные решения для хостинга могут масштабироваться так же, как и облачные. Ярким примером является сама сеть StackExchange .

Итак, в вашем случае я бы запустил большой экземпляр в Rackspace, а затем загрузил все данные в локальный экземпляр Postgis. Затем после настройки движка рендеринга я бы заполнил кеш. Большой экземпляр завершит процесс посева достаточно быстро, чтобы он не стал слишком дорогим для запуска. Вы можете хранить плитки в fs, MTBtiles, даже на S3 (кстати, вы можете передавать данные S3 на CDN с CloudFront ).

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

Это довольно длинный ответ, поэтому я остановлюсь здесь. Если вы хотите, чтобы я уточнил некоторые аспекты, просто оставьте комментарий.

Отказ от ответственности: я не связан с Rackspace, Linode или любым другим провайдером, на которого я ссылался.

Я использую WebFaction для размещения ГИС-данных в базе данных Postgresql / PostGIS с MapServer, и я думаю, что сервис не имеет себе равных по стоимости <$10в месяц. Если вы хотите использовать PostGIS 2.0, вам нужно установить его самостоятельно, что немного сложно, но по умолчанию они предоставляют PostGIS 1.5 (вам нужно открыть заявку в службу поддержки). Это сервис общего хостинга на CentOS, где вы можете гибко устанавливать все что угодно в своей части сервера.

Я не использовал Webfaction для обслуживания плиток, но они предоставляют 100 ГБ пространства; Я не уверен, будет ли ОЗУ слишком дорогой, так как по умолчанию используется 256 МБ (и каждый 256 блок стоит дополнительно 7 долларов в месяц)

Еще одна возможность, которая использует AWS:

Возможно, вы захотите использовать метод AWS Lambda Tiler, который разработал Сет Фитцсиммонс. Он использовал его для проекта Open Aerial Map, а я использовал его для проекта частного клиента, работая в Stamen Design.

На блоге Medium.com есть подробное сообщение в блоге, в котором я описываю настройку лямбда-тайлера AWS . Обратите внимание, что сообщение в блоге охватывает только растровые данные, но мы также использовали этот процесс в Stamen для управления нашей глобальной плитками карты Terrain Classic, которые генерируются из комбинации данных OSM и Natural Earth через PostgreSQL, PostGIS, Mapnik и CartoCSS.

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

Чтобы получить подробные расценки на услуги AWS, вы можете воспользоваться онлайн-калькулятором, расположенным здесь: http://calculator.s3.amazonaws.com/calc5.html

Для небольшого экземпляра EC2 под управлением Linux, если вы готовы выделить один год, вы можете купить зарезервированный экземпляр, который будет стоить около 25 долларов в месяц. Это по сравнению с примерно 44 в месяц для ценообразования по требованию или без контракта.

Я думаю, что краткий ответ на ваш вопрос заключается в том, что если вы ищете поставщика инфраструктуры, который позаботится о ваших личных приложениях для веб-картографирования, AWS может оказаться излишним. Если вы ищете ИТ-провайдера для производственных приложений, особенно если они требуют высокой доступности и масштабируемости, то AWS - ваш ответ. Это становится еще более актуальным, если вы создаете приложения, использующие множество склеенных сервисов, которые предоставляет AWS, таких как SQS, SNS, SWF и т. Д.

Что касается того, какой EC2 вам нужен? Это функция вашего приложения. Весь смысл облачных ИТ-технологий в том, что вы можете попробовать, прежде чем купить. Протестируйте свое приложение без каких-либо обязательств и только тогда, когда вы знаете, примите обоснованное решение о переходе на тип EC2 в течение определенного периода времени (покупка RI).

Я не эксперт, обладающий большими или какими-либо знаниями об этом, за исключением того, что я уже некоторое время управляю веб-сервером на Amazon EC2, так что это не ответ.

Я не уверен, что вы используете эти инструменты наилучшим образом, предварительно выполняя рендеринг и загрузку.

• Большая часть моих расходов на AWS связана с передачей данных (то, что вы говорите о загрузке).
• Что еще нужно сделать вашему серверу (если только вы не используете лицензии для рендеринга тайлов и не имеете лицензии на AWS).

Если это не удерживает или не вызывает переосмысления, сначала выберите ваш любимый картографический сервер, затем выберите поддерживаемую ОС для этого картографического сервера, затем перейдите к AWS EC2 и найдите экземпляр, который лучше всего соответствует вашим потребностям (размер, память, пространство, регион).
Может быть или не быть AMI, содержащий весь стек, который вам нужен, поэтому в следующий раз настройте его, а затем установите свой стек.
Существует большая вероятность того, что вы сделаете все это «бесплатно» или дешево.

Это правда, что вы можете использовать AWS, если используете разные сервисы, так как AWS довольно дорогой. Если вы хотите пойти по более низким ценам с теми же преимуществами, я бы порекомендовал для https://fxdata.cloud или https://digitalocean.com, так как оба они имеют заметные услуги и самые дешевые цены. Вы получите все опции ОС и СУБД с высокой надежностью.