2020 年美国大选技术平台架构( 二 )


竞选活动一开始就承若 , 我们将以高标准来要求自己 , 并确保不接受来自伤害地球的组织或别有用心的个人的捐赠 。 为了信守承诺 , 我们建立了一个自动化框架 , 几乎可以实时地审查我们的捐助者是否遵守联邦选举委员会的规定和竞选承诺 。
我们赢得了初选 , 并希望在大选的网站上打造一个新的品牌 。 所以我们为joebiden.com带来了一种全新的体验 。
竞选活动的一个重要方面是直接接触选民 , 让他们知道他们所在地区发生了什么 , 或者是什么时候可以投票 。 为此 , 我们建立了一个全国范围内的短信推广平台 。 在这一过程中 , 我们节省了数百万美元的运营费用 。 除此之外 , 竞选总部和州总部也开始IT化运作 , 最终在疫情隔离开始时成为一个可以完全远程运作的组织 。
我们通过这些确保了我们拥有世界级的网络安全 , 这是我们所做一切的核心 。
但不管怎样 , 竞选活动中的任何一项工作都不只是个体的责任 , 每个人都需要在任何时候、任何地点提供帮助 , 无论是打电话让选民去投票、发送短信还是收集签名让他们参加投票 。 这些我们都做了 。
基础设施和平台
我们所做的一切都依赖于云基础设施 。 最重要的是 , 我们没有花太多宝贵的时间在重新创造轮子上 。 我们使用Pantheon来托管主网站joebiden.com 。 对于非网站的工作负载、API和服务 , 我们把它们部署在AWS上 。 此外 , 我们在AWS部署了一个小型Kubernetes , 帮助我们更快地交付简单的工作负载(主要用于CRON作业) 。
我们仍然需要快速交付大规模服务 。 作为一个小团队 , 我们的构建和部署管道的可重复性就变得非常重要 。 对于持续集成 , 我们使用了TravisCI 。 对于持续交付 , 我们使用了Spinnaker 。
服务在云端部署并开始运行了之后 , 它们都需要一组核心功能 , 比如如何找到其他服务并安全地访问配置和秘钥 。 为此 , 我们使用了HashiCorp的Consul和Vault , 这帮助我们构建了完全不可变和差异化的开发环境和生产环境 , 很少需要手动操作服务器——不是完全不需要 , 但真的非常少 。
很大一部分技术工作是由分析团队完成的 。 为了确保他们能够获得最好的工具和服务 , 我们将分析数据保存在AWSRedshift中 。 它提供了一个高度可伸缩的环境 , 可以对资源利用做到细粒度控制 。
我们将PostgreSQL作为服务的后端数据存储 。
从运维的角度来看 , 我们希望应用程序的日志记录活动有一个中心视图 , 以便我们能够快速地排除和诊断问题 , 实现最快的故障恢复 。 为此 , 我们部署了一个ELK栈 , 并使用AWSElasticsearch来存储日志 。 日志对于应用程序来说非常重要 。 指标提供了服务运行状态的洞见 , 在与我们的轮岗待命机制集成时 , 它们是非常关键的信息来源 。 在服务水平指标方面 , 我们部署了Influx和Grafana , 并将它们连接到PagerDuty , 确保不会遇到未知的中断 。 很多自动化工作负载和任务并不适合使用传统的部署模型 , 对于这些 , 我们会尽可能使用AWSLambda 。 我们还将Lambda用于需要与AWS生态系统其他部分集成的工作负载 , 以及基于数据呈现的扇出作业 。
我们构建了一个真正的多语言环境 。 我们用各种语言和框架构建了服务和自动化机制 , 我们能够以无与伦比的弹性和速度做到这些 。
我们在竞选期间涉及了很多领域 。 要把我们所做的每一件事都彻底细化需要花费一生的时间 , 所以我将挑选一些有趣的架构 , 这些架构是由负责软件工程的技术团队做起来的 。 当我深入讨论架构时 , 请注意 , 对于我所讨论的每个细节 , 至少还可以做十几次分享 , 它们涵盖了我们整个技术团队所完成的工作的广度 。