AWSによる単一クラウドアーキテクチャに移行したAuth0

認証、承認、シングルサインオンのサービスを提供するAuth0は、自社のインフラストラクチャを、これまでの複数クラウドプロバイダ(AWS、Azure、Google Cloud)からAWS単独に移行した。AWSサービスへの依存度が必然的に高まるため、現在の同社のシステムは4つのAWSリージョンに分散されると同時に、サービスはゾーン間でレプリケーションされている。

Auth0の設計目標は、オンプレミスでもクラウド上でも実行することだ。過去4年間で同社のシステムは、1ヶ月あたり15億ログイン以上を処理するまでにスケールアップしている。サービス数は10から30に、サーバ数は単一AWSリージョン内の数十から4リージョンにまたがった1,000以上に、それぞれ増加した。同社のアーキテクチャは、さまざまなサービスで構成される自動スケールグループを支援するルーティング層と、MongoDB、ElasticSearch、Redis、PostgreSQLからなるデータストレージ層で構成され、Kinesisストリームと、RabbitMQ, SNS、SQSなどのメッセージキューをサポートする。

Auth0の初期のアーキテクチャはAzureとAWSに分散し、一部でGoogle Cloudを使用する構成だった。当初のSaaSデプロイメントではAzureが主要リージョンでAWSがフェールオーバ用であったが、後になって役割を逆転させている。クラウド間のフェールオーバはDNSベースで行われていたため、フェールオーバ発生時にクライアントを迅速に切り換えるには、TTLが極めて低くなければならなかった。

同社プロダクションエンジニアのDirceu Tiegs氏は、“KinesisやSQSといったAWSリソースの使用量が増加し始めるにつれ、２つのプロバイダで同じ機能を維持することが困難になってきました”、と記している。当時のAzureにはSQSと同様のAzure Service Busというサービスがあったのだが、他のどのAWSサービスに相当するものがAzureに不足していたのかは、具体的に述べられていない。AWSリージョン特有のサービスで不足するものがあったために、別の手段を使って記述することになったケースの数は、それほど多くないはずだ。

Auth0がこれまで経験したシステムダウンのひとつは、2016年、 AWSにある同社のVPNエンドポイントが、AzureとGCEからのネットワーキングパケットをドロップし始めた時に発生した。当時のデータベースクラスタアーキテクチャは3つのプロバイダすべてを使用していたが、この問題によって、AWSの主要データベースノードがAzureのハートビートパケットを受け取れなくなったのだ。それによって発生した回復処理の過程で、すべてのクラスタノードがセカンダリとしてマークされたため、サービスが影響を受けることになった。この問題にはDNSの誤設定が関係していた。最終的にチームは、Azureへの依存度を低減し、AWSが利用不可になった場合には認証サービスを最小限バージョンのみとすることを決定した。その結果、AWSが同社の主要クラウドプロバイダになったのだ。

イメージ提供 - https://auth0.com/blog/auth0-architecture-running-in-multiple-cloud-providers-and-regions/

Auth0のAWSアーキテクチャには、リージョン内の3つのアベイラビリティゾーン(AZ)で運用されるデータベースを始めとする、すべてのサービスが含まれている。ひとつのAZがフェールしても、残る2つが引き続き利用できる。リージョン全体がフェールした場合は、AWSのDNSサービスであるRoute53を更新して、同社のドメインが他のアクティブなリージョンを指すようにすることが可能だ。一部のサービスには、他よりも高い可用性保証が行われている。例えば、Elasticsearchをベースとするユーザ検索サービスでは、多少データが古くても、すべての重要機能が引き続き動作するようになっている。データベース層はリージョンを越えたMongoDBクラスタ、PostgreSQL用のRDSレプリケーション、リージョン単位のElasticsearchクラスタから構成されている。

Auth0では、CloudFrontに移行した2017年まで、独自のContent Delivery Network(CDN)を運用していた。自社で立ち上げたCDNは、Amazon S3を動作基盤に、Varnishとnqinxを使って構築したものだったが、CloudFrontに移行したことによってメンテナンス作業が削減され、設定も容易になった。

監視機能には当初Pingdomを使用していたが、その後、node.jsスクリプトを実行してSlack経由で通知を行うヘルスチェックシステムを独自に開発した。現在のスタックにはDatadog、CloudWatch、Pingdom、Sentinelがある。時系列のメトリクスはDatadogによって収集し、Slackに送信されると同時に、一部はPagerDutyに送信される。SlackはChatOpsコラボレーションモデルの考え方に基づいて、タスクの自動化にも使用されている。ログ処理パイプラインではAmazon Kinesis、Elasticsearch、Kibanaを使用してアプリケーションログを収集するとともに、Sumologicで監査証跡とAWSが生成するログを記録している。