AWS Aurora Serverlessを最新機能(v2)を含めて解説
目次
Amazon AuroraとAurora Serverless
AWS（Amazon Web Services）で提供されているマネージドデータベースの種類の1つに、Aurora Serverlessというものがあります。Aurora Serverlessは2022年4月にバージョンアップされ（出典：https://aws.amazon.com/jp/blogs/news/amazon-aurora-serverless-v2-is-generally-available-instant-scaling-for-demanding-workloads/）、Aurora Serverless v2として提供が始まっています。本記事では、Aurora Serverlessがどのようなサービスなのか、また、V2へのバージョンアップによりどのような機能が追加になったのかを、記載していきます。
まず、Amazon Auroraとは？
AWSが開発した、MySQLとPostgreSQLと互換性のあるクラウド向けのリレーショナルデータベースのことです。MySQLやPostgreSQLといったオープンソースのデータベースエンジンを、大企業における高性能・高可用性が求められる際の利用にも耐えられるように、改良が加えられています。
開発したAWSによると、MySQLと互換性のあるバージョンと、PostgreSQLと互換性のあるバージョンでは、それぞれMySQLの最大5倍、PostgreSQLの最大3倍高速であるとされています。世界最大のECサイトであるAmazonや動画配信サービスのNetflixでも利用されている事実からわかるように、非常に高性能なデータベースサービスとなっています。
Auroraの特徴的なアーキテクチャとしては、Auroraはクラスタという単位で構成されており、1つ以上のDBサーバーで構成されるインスタンス層とデータを管理するストレージ層の2層で成り立っていることです。つまり、SQLなどの処理を行うインスタンスとデータを保存するストレージが分離しています。
また、データを保管するストレージは、1AZあたり2箇所、3AZに渡りコピーされています。このような構成にすることで、仮にネットワーク障害、ディスク破損などの問題が起こっていたとしても、データベースの稼働に影響がないようにし、可用性の向上に貢献しています。Amazon Auroraについては別コラムで詳しく取り上げていますのでそちらをご覧ください。
Amazon AuroraとAurora Serverlessの違いとは？
性能面と運用面で大きな違いがあります。性能面では、Amazon AuroraはEC2やコンテナなどのサービスと通信する際にクラスターエンドポイントと呼ばれるエンドポイント経由である一方、Aurora ServerlessはVPCエンドポイント経由で通信が行われます。
簡単に言えば、Aurora Serverlessのほうが少々回り道をする通信経路となっており、Amazon Auroraのほうが、若干性能が高いです。運用面の違いは、「インスタンスの管理が必要かどうか」という点になります。Amazon Auroraはユーザー側でインスタンス管理が必要になりますが、Aurora Serverlessは完全にAWS側でインスタンスが管理されるため、運用コストが若干低くなります。
また、サービスの利用料も、Amazon Auroraはインスタンスタイプによる課金であるのに対し、Aurora Serverlessでは秒単位の利用数や、DBへのリクエスト数がメインとなり、Aurora Serverlessのほうが（使い方にもよりますが）大抵の場合コスト効率がよく、低い料金で利用できます。
（v2になる前の）Aurora Serverlessの特徴
Aurora Serverlessの大きな特徴は下記の通りです。
- アーキテクチャ
- API接続
- 自動スケーリング
- 課金体系
それぞれについて、詳細に見ていきます。
アーキテクチャ
Aurora ServerlessはS3などと同様にAWSによりサーバーが管理されているため、VPCエンドポイント経由で通信が行われます。そうすることにより、Aurora側でインスタンスの増減が行われていても、AWS側で通信の制御を行い、通信が安定して行えるようになっています。
API接続
Aurora ServerlessはAPIを使って他のサーバレスサービスとの連携ができます。APIを使うメリットとしては、APIの通信はHTTPSで行われ、DBとの直接通信を行わなくて済む、という点です。従来のRDBMSであれば、利用者が多いときに設定したコネクション数の上限に達すると通信ができなくなってしまう、というケースに遭遇することがあります。HTTPSであればセッション管理の必要性はあるにせよ、コネクション数の上限といったボトルネックはなく、アプリケーションの拡張性に一層柔軟に対応可能です。
自動スケーリング
Auroraはストレージが10GB～128TBまで自動的に拡張されます。したがって、大抵の場合なストレージ管理を気にすることなく利用を継続することが可能になっています。
課金体系
Aurora Serverlessではスケーリングした性能を表す単位をACU(Aurora capacity unit)＋DBに対するリクエスト数＋データ量となっています。1ACUは約2GBのRAMとそれに相応するCPU、ネットワークで構成されています。ACUについては、0から256ACUまでスケール変換ができますし、最大～最小を事前に設定しておき、スケールする範囲を調整することも可能です。DBの使用がなく、ACUが0の場合には課金が発生しないため、DBインスタンスを完全中止しなければ課金され続けるAmazon Auroraとは違いコスト効率に優れています。
マネージドデータベースを活用して運用コストを引き下げるスタイルズのAWS導入・移行サービスはこちら→
（v2になる前の）Aurora Serverless導入時の問題点やデメリット
Aurora Serverlessはほかのサーバーレスサービスと同様、様々な制限や制約があり、導入前には考慮に入れる必要性があります。具体的な問題点やデメリットについて記載します。
- バックアップの制約
バックアップ期間を変更することはできず、特殊な要件で長期のバックアップを擁するシステムには利用できません。 - スケールが遅い
Aurora Serverlessはクエリが処理されている間はスケーリングできません。つまり継続的にクエリが実行されるようなアプリケーションではスケーリングが実行できず、想定以上の処理性能が出ない可能性があります。 - シングルAZのみ対応、別AZへのフェールオーバーが遅い
処理は基本的にシングルAZで行われます。障害が発生した際には別のAZに自動的にフェールオーバーするのですが、プロビジョニングされたAuroraよりも時間がかかります。したがって、Amazon Auroraと比較して、RTOが遅いというデメリットがあります。 - Data APIの制限
1秒間あたり最大1000コールまでとなっており、十分な処理性能を持っていますがそれ以上の性能を求められる場合は考慮が必要です。また、レスポンスのサイズも最大1MBとなっています。
Aurora Serverlessはv2で何が変わったのか？
Aurora Serverless v2は先述のデメリット・問題点のうち、『2. スケールが遅い』『3. フェールオーバーが遅い』が改善されています。まず、クエリが実行中でも瞬時にスケールすることが可能になっており、性能上のボトルネックが改善されています。また、従来はシングルAZだったのですがマルチAZ対応も可能になっています。
それにより、グローバルデータベース、リードレプリカなどのAmazon Auroraの既存機能をAurora Serverlessでも利用可能になっており、可用性やRTOの大幅な改善が行われます。コストの効率性はそのまま継続して特徴として残っているので、性能を大幅に向上しつつ、コスト効率が良いAuroraとして利用することができます。
結局、Aurora Serverlessはどんなところで使えるのか？
Aurora Serverlessの使用ケースは下記が考えられます。
- 非常に変化の大きいワークロードの場合
非常にアクセスを多い時と少ない時の落差が大きかったりの予測できないワークロードにに対して、データベースは負荷のニーズに合わせて容量を自動的にスケーリングできます。 - システム開発時のAmazon Auroraの代替
オンプレミス上のシステムをリファクタリングして改修したりする際に、Amazon Auroraを利用するとコスト効率が悪い場合があります。そのような場合には開発中の段階では、コスト効率に優れているAurora Serverlessを利用すると開発コスト削減につながることが考えられます。
マネージドデータベースを活用して運用コストを引き下げるスタイルズのAWS導入・移行サービスはこちら→
いずれにしても、Aurora Serverlessか、通常のAmazon Auroraか、判断に迷うケースも多々あるかと思います。そのような際にはベンダーに相談してみるといいでしょう。