AWSのエンジニアが、Amazon Aurora Serverlessプラットフォームのリソース管理とスケーリングの進化と最新の設計について説明した論文を発表した。Aurora Serverlessは、顧客のワークロードのニーズを満たすために動的にリソースをスケーリングし調整するための全体的なアプローチを作成するために、異なるレベルのコンポーネントの組み合わせを使用する。
Amazon Aurora Serverlessは、変化する顧客のワークロードに対応するためにAmazon Auroraデータベースを自動的にスケーリングし、コストの最適化、パフォーマンスの向上、運用の簡素化を実現する。Auroraの顧客はAurora Capacity Units (ACUs)を使ってスケーリングの境界を設定し、サービスは需要に応じて動的にリソースを調整する。顧客の観点では、これらのスケーリング操作は介入を必要とせず、クライアント接続やセッション状態を中断させないが、レイテンシに影響を与える可能性がある。
現在のAurora Serverless製品は、2018年に発売されたASv1の運用とサポートから得た経験に基づく第2世代の設計である。新しい設計では、CPUとメモリのホット（アン）プラグを使用したインプレース・スケーリングに重点を置いており、ホスト間のライブマイグレーションでサポートされている。ASv1と比較して、ASv2はより高速でシームレスなスケーリングを提供し、スケーリング増分量が少ないため、費用対効果が高い。
第2世代のソリューションに取り組むチームは、多くの課題に取り組まなければならなかったが、その主なものは、スケールアップとスケールダウンのイベントをサポートするDBワークロードの効果的なメモリ管理だった。LinuxとDBエンジンは、利用可能なメモリをすべてコミットし、それを保持する傾向がある。エンジニアはDBエンジン、Linuxカーネル、AWS Nitroハイパーバイザーを変更し、さまざまなワークロードに対してより柔軟なメモリ管理を可能にした。
/filters:no_upscale()/news/2024/08/aurora-serverless-scale-resource/en/resources/1aurora-serverless-instance-1724329981067.jpeg)
インスタンス・マネージャー・サービス（出典：Aurora Serverlessにおけるリソース管理）
Amazon Auroraは、物理ホスト上のすべてのインスタンスからの需要動向に基づいてDBエンジンのリソーススケーリングを制御するために、インスタンスごとのマネージャーサービスを利用している。ホスト間のDBエンジンの配置と利用可能なリソースのヘッドルームを最適化することで、Aurora Serverlessはホスト間でリソースを移行する必要なく、動的なワークロードに対応するためにホスト上で十分なリソースを確保できる。
Aurora Serverlessサービスは、数万台のコンピュート・インスタンスからなる大規模なフリートをもっとも広いレベルで管理する。フリートマネージャーサービスは、中長期的なフリートサイジングと、望ましい利用レベルと予測される需要に基づくキャパシティ調整に重点を置いている。ホスト間のライブマイグレーションは、ホストが "ホット "になる危険性がある場合に使用され、リソースを解放する。さらに、フリート・マネージャーは、「ヒート修復」の間、インスタンスの最大ACUに一時的な制限を課すことができる。
/filters:no_upscale()/news/2024/08/aurora-serverless-scale-resource/en/resources/1aurora-serverless-fleet-1724329981067.jpeg)
フリート・マネージャー・サービス（出典：Aurora Serverlessにおけるリソース管理）
エンジニアは、米国のAWSリージョンにおけるAuroraフリーからのいくつかのデータを共有し、スケールアップイベントの大部分（99.98％）はホスト間マイグレーションを必要とせず、インプレーススケーリングメカニズムで満たすことができると指摘した。
この論文では、設計のシンプルさと、リソース管理に対するリアクティブでメトリクス駆動型のアプローチに重点を置くことを強調し、いくつかの重要なポイントを挙げている。チームは、将来的にソリューションに予測的要素を導入することを否定せず、DBワークロードをよりよくサポートするためにハイパーバイザーとOSカーネルを共進化させるさらなる機会を強調した。