Auth0转向基于AWS的单云架构

Auth0是一家认证、授权和SSO服务提供商。近期，Auth0完成将自身架构从三家云提供商（即AWS、Azure和Google Cloud）转向AWS一家，这是因为它的服务越来越依赖于AWS服务。现在，Auth0的系统分布在4个AWS域（Region）中，其中服务是跨区（Zone）复制的。

Auth0在设计上支持 运行 在本地部署和云上。在过去的四年中，其系统扩展到每月服务超过15亿次登录操作，所提供的服务也从10种增加到30种。同时，服务器数量从单个AWS域中的数十台，增长到跨四个AWS域中的一万多台。其架构中包括了一个以提供各种服务 自动扩展组 为后端的路由层，以及一个使用 MongoDB 、Elasticsearch、 Redis 和PostgreSQL的存储层，该存储层支持Kinesis流处理系统和RabbitMQ、SNS、SQS等消息队列。

最初，Auth0架构是跨Azure和AWS的，还有一小部分部署在Google Cloud上。 Azure在一开始是作为主域 ，而AWS则用于故障转移。之后，二者的角色发生了互换。由于云间的故障转移是 基于DNS 的，这意味着TTL必须非常低，以使得客户在故障转移发生时可以快速切换。据Auth0产品经理 Dirceu Tiegs 在企业技术博客上 撰文 介绍，“当我们开始使用更多的AWS资源时，例如Kinesis和SQS等，为保持两个云服务提供商提供对等的特性，我们遇到了一些麻烦”。Azure确实曾提供类似于SQS的服务，称为Azure Service Bus。虽然博客中并未提及哪些AWS服务在Azure中缺失对等服务，但是存在一些情况使得特定AWS域中缺少服务。为此， Auth0技术团队曾撰文介绍他们是如何使用替代服务的 。

Auth0在2016年曾发生了 一次掉线故障 ，它们部署在AWS上的VPN终端开始丢弃来自于Azure和GCE的网络包。当时，Auth0的数据库集群使用了所有三家云服务提供商。由于存在上述问题，导致AWS的主数据库节点不能接收到来自于Azure的心跳网络包。随后团队恢复尝试服务，所有集群节点将自身标记为后备节点，服务因而受到了影响。DNS配置错误是导致问题的一个原因。由此，团队最终决定将AWS作为首要的云服务提供商，最小化部署在Azure的认证服务支持，只是在AWS宕机时使用。

图片来源： https://auth0.com/blog/auth0-architecture-running-in-multiple-cloud-providers-and-regions/

在Auth0的AWS架构中，包括数据库在内的所有服务运行在同一个域（Region）的三个 可用区（AZ，Availability Zone） 中。如果一个AZ发生故障，那么其它两个AZ将会继续提供服务。如果整个域发生故障，那么AWS的DNS服务Route53就会更新网络域名去指向另一个可用的域。一些服务相比于其它服务需要有更高的可用性保证。例如，尽管基于Elasticsearch的用户搜索服务可能会使用到一些过期的数据，但是所有核心功能并不会受此影响。数据库层在组成上包括了跨域的MongoDB集群、 用于PostgreSQL的RDS复制 以及部署在每个域中的Elasticsearch集群。

Auth0在2017年之前运行着自己的CDN，之后转移到使用CloudFront。企业自开发的CDN以Amazon S3为支持，使用Varnish和nginx构建。转移到CloudFront使得企业降低了维护工作，并且更易于配置。

Auth0的监控最初使用Pingdom实现，此后企业 开发了自己的 健康检查系统，该系统运行node.js脚本，并通过Slack发布通知。企业当前的技术栈包括了Datadog、CloudWatch、Pingdom和Sentinel。时序度量由Datadog采集并发送给Slack，其中一小部分发送给PagerDuty。Slack还用于实现符合ChatOps协作模型的 任务自动化 。 日志处理流水线 使用Amazon Kinesis、Elasticsearch和Kibana收集应用日志。Sumologic用于记录审计跟踪数据和AWS生成的日志。

查看英文原文： Auth0's Move to a Single-Cloud Architecture on AWS