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

  • 发表于:
  • 原文链接:http://www.infoq.com/cn/news/2018/08/auth0-architecture-aws

扫码关注云+社区

领取腾讯云代金券