「Resource Management in Aurora Serverless」を読んでみた

インフラ担当の柴田です。お盆休みに「Resource Management in Aurora Serverless」という論文を読んだのでブログを書いてみました。

この論文では、顧客体験を維持しながら物理的な機器のリソースを効率よく利用するためのさまざまな工夫が紹介されています。そういった工夫も勉強になるのですが、「2.1 Challenges and a Key Design Principle」で述べられている次の設計原則にAmazonらしさがあるなと思いました。

Therefore, a general design principle throughout Aurora Serverless’s evolution has been to start off with minimal assumptions about our workloads and incorporate specificity only once we have seen enough evidence for it in our datasets.

この原則は、Aurora Serverlessのv1からv2へのアーキテクチャ移行の背景にあり、v2で取り入れられたさまざまなメカニズムに繋がっています。小さく始めて徐々に改善していくというアプローチは理想的ですが、実際にそれを実現するのは非常に難しいことです。それを実践しているAurora Serverlessの開発が改めて凄いなと思いました。

詳細は実際に論文を読んでいただくとして、今回はv1からv2へのアーキテクチャ移行について少しだけ紹介します。

Amazon Aurora Serverlessとは？

Amazon Aurora Serverlessは、MySQLやPostgreSQLと完全な互換性を持つリレーショナルデータベースサービスです。従来のAmazon Auroraでは、インスタンスの容量は固定されており、事前に需要を予測して容量を決定する必要がありました。一方で、Aurora Serverlessでは、必要に応じて自動的に容量をスケールアップまたはスケールダウンできます。これにより、リソース管理の負担が軽減され、効率的に容量を利用することが可能になります。

v1からv2への進化

Aurora Serverlessは2018年に最初のバージョンであるv1がリリースされ、その後2022年に最新のバージョンであるv2がリリースされました。 Aurora Serverless v2では、Amazon Auroraの多くの機能を使えるほか、Aurora Serverless v1よりも高速で中断の少ないスケーリングが可能です。

docs.aws.amazon.com

v1のアーキテクチャ

論文によると*1、Aurora Serverless v1ではリソース管理にシンプルな「セッション転送」を使用していました。セッション転送は、インスタンスをスケールアップする際に、セッションを別のバックエンドに転送し、新しいインスタンスに接続を切り替える仕組みです。しかし、このアプローチにはいくつかの制約がありました。たとえば、セッションを転送する際に顧客のパフォーマンスを妨げない適切なタイミングを見つける難しさや、一部のセッション状態（例えば一時テーブル）の転送が困難であることが挙げられます。また、スケーリングは大きな単位（約2倍）でしか行えず、コスト効率も十分ではありませんでした。

v2のアーキテクチャ

そこで、v1の利用者を観察して得た洞察から、Aurora Serverless v2ではv1の問題を克服するためにアーキテクチャが刷新されました。 v2では、初めからインプレース（その場）でスケーリングができるように設計され、0.5 Aurora Capacity Unit (ACU)という小さな単位で容量を変更することが可能になりました。さらに、スケーリングは通常処理を停止することなく行われます。

このv2のスケーリングは、メモリとCPUのホットプラグ、そしてホスト間でのインスタンスのライブマイグレーションという2つのメカニズムを利用しています。需要にあわせて仮想マシンのCPUやメモリの割り当てを動的に調整し、同一ホスト内で処理が難しくなった場合には、他のホストにライブマイグレーションすることで無停止でのスケーリングを実現しています。