互联网地图是一种根据用户行为展示网站位置的工具。相似的网站因为被相同的人群访问，所以彼此靠近；而没有共同访问者的网站则相隔较远。地图上网站的尺寸由其平均点击评分决定，颜色则根据其所属国家定义。要获取更详细的信息，可以访问地图网站的“关于”部分。
在本文中，将向介绍互联网地图网站的组织方式，哪些技术保证了其日常运作，以及为了维持大量访问者查看地图而采取的步骤。
互联网地图的可操作性得益于现代互联网巨头的技术：地图的可视化显示由Google Inc.的Google Maps引擎提供支持，网络查询处理则使用Microsoft的.NET技术，而Amazon的Amazon Web Services则负责托管和内容分发。这三个组件对于地图的正常运作至关重要。虽然可以找到替代方案，但不确定这会带来多大的益处。
Google Maps技术意味着使用瓦片——每个都是256x256像素的小图片，地图的图像就是由这些图片组成的。这些图片的主要特点是数量相当多。当在屏幕上以高清晰度查看地图时，它全部由这些小图片组成。这意味着服务器必须能够同时处理大量的小查询并提供瓦片，以便客户端不会看到马赛克。显示地图所需的瓦片总数等于sum(4^i)，其中i的值从0到N，N是缩放的总数。以互联网地图为例，缩放的总数等于14，即需要大约3.58亿个瓦片。幸运的是，通过避免生成空瓦片，这个天文数字被减少到了3000万。如果打开浏览器控制台，会看到大量的403错误，那就是——遗漏的瓦片，但由于如果没有瓦片，该方块会自动填充为黑色背景，所以在地图上是看不出来的。无论如何，3000万瓦片也是一个相当大的数字。即使在Windows中复制或删除瓦片目录也需要2天时间。
因此，在这种情况下，传统的将内容放置在专用服务器上的方式是不适用的。瓦片很多，用户也很多，所以服务器也应该很多，并且应该靠近用户，以便他们不会注意到延迟。否则，来自俄罗斯的用户会得到很好的响应，而日本用户则会回忆起拨号调制解调器的时代，看着地图。幸运的是，Amazon有解决这个问题的方案（Akamai也有，但那是另一个话题）。它被称为CloudFront，本质上是一个全球CDN（内容分发网络）。在某个地方部署内容（这被称为源），并在CloudFront中创建一个分发。每当用户请求内容时，CloudFront会自动找到其网络中离用户最近的节点，如果它还没有数据副本，它将从另一个有副本的节点请求，或者从源请求。看起来，数据经过多轮复制，并且很可能从CloudFront服务器而不是自己的昂贵、脆弱且不安全的数据库中交付。对于互联网地图来说，利用CloudFront有效地意味着将硬盘驱动器上的数据复制到新加坡的简单存储服务（S3）部分，然后通过AWS控制台在CloudFront中创建一个分发，其中S3被引用为数据源。如果查看互联网地图网页的代码，可能会看到瓦片来自以下CloudFront地址：http://d2h9tsxwphc7ip.cloudfront.net/；确定最近的节点、更新内容等都是由CloudFront自动完成的。
在图片中，可以看到原始地图如何分解成瓦片，瓦片存储到S3中，然后它们被导入到CloudFront中，并最终从其节点提供给用户。
为了在地图上搜索网站，需要一个数据库，其中存储有关网站及其坐标的信息。在这种情况下，拥有的是Amazon云中的MS SQL Express实例。它被称为关系数据库服务——RDS。这里并不真正需要关系部分，因为只有一个表，但拥有一个全功能的数据库总比重新发明轮子要好。RDS允许使用MS SQL，还可以使用Oracle、MySql等。
在图片中，可以看到原始地图如何变成RDS数据库中的一个表。
很可能，这个功能是所有“云”Amazon服务中最让惊讶的。Elastic Beanstalk让几乎可以一键在负载下发布项目，最小化离线时间或根本不离线。知道发布可能会有多困难，特别是当基础设施包含多个服务器和负载均衡器时，对Elastic Beanstalk如何轻松优雅地管理它感到非常惊讶！在第一次部署期间，它创建了应用程序所需的整个环境：负载均衡器（Elastic Load Balancer - ELB）、计算单元（Elastic Compute Cloud - EC2），它还确定了缩放参数。大致来说，如果有一个服务器，所有查询都直接指向它，达到一定限制后，服务器将无法应对负载，并且很可能会崩溃。有时它甚至无法在负载下重新启动并运行，因为它以前可以很好地处理，因为恢复正常操作模式通常需要一些时间，并且在持续查询的背景下几乎是不可能的。无论如何，那些去过那里并做过那件事的人会知道意思。
可以在所有基础设施问题上依赖Elastic Beanstalk。事实上，只需要在MS Visual Studio中安装一个插件，然后忘记细节。它将自动控制和更新版本、部署等。如果负载增加，它将创建所需数量的EC2实例。
在图表中，Elastic Beanstalk用虚线标记，里面可以看到ELB接受传入查询并将它们提供给EC2实例中的IIS。
7月24日，在俄罗斯最大的IT资源Habrahabr.ru上发表了一篇文章，互联网地图公开了。文章发表后不久，互联网地图就经历了访问者的大量涌入。从图表中可以清楚地看出，网站流量急剧上升，在前6个小时内，网站被访问了3万人，到当天结束时，访问量几乎达到了5万人，主要来自俄罗斯和前苏联国家。Elastic Beanstalk立即创建了10个EC2实例，并且它们很好地解决了问题。没有收到关于无法访问网站的投诉。地图可以自由查看。至于RDS，它立即失败了，首先搜索开始工作得非常慢，然后变得不稳定，最终完全停止工作。第一天的账单大约为200美元。大约100美元用于S3+CloudFront，EC2和RDS各花费50美元。
在了解了学到的教训之后，优化了代码并重新调整了自动缩放参数。它起作用了。在一周内，网站每天平均有3万到5万人访问，来自不同的地方，一切都没有出错。必须说，第一天突然的流量增加没有再次发生。
然后有人在reddit.com上发布了一些关于地图的信息，导致流量激增。周日，网站被大约50万人访问，只有一台小型EC2实例和一台小型RDS实例运行得很好。有一个投诉，地图没有加载，但认为对于这样的负载是可以接受的。
当看到所有这些巨大的流量时，期望从Amazon收到巨大的账单，并弹出捐赠。现在它变得正常了，捐赠几乎准备好支付账单了。