フルマネージドDBの真髄：AWS Aurora Serverless v1/v2を比較解説

はじめに

クラウドコンピューティングの進化は、データベース管理のあり方を劇的に変えてきました。かつてオンプレミス環境で必須だった、ハードウェア選定、OSインストール、DBソフトウェア設定、パッチ適用、バックアップ計画、災害対策といった膨大な運用業務は、フルマネージドデータベースサービスによって大幅に軽減され、私たちはよりアプリケーション開発やビジネスロジックに集中できるようになりました。

AWS Auroraは、AWSが提供する代表的なフルマネージドデータベースサービスであり、MySQLおよびPostgreSQLとの高い互換性を持ちながら、商用データベースに匹敵するパフォーマンスと可用性を実現しています。その革新的なアーキテクチャ、特に分散ストレージシステムは、標準的なMySQL/PostgreSQLと比較して最大5倍/3倍のスループットを実現し、データ損失のリスクを大幅に低減します。

しかし、Auroraのプロビジョンドインスタンスは、事前にキャパシティ（インスタンスタイプ）を決定し、固定のコンピューティングリソースを確保する必要がありました。これは、ワークロードが予測可能な場合には効率的ですが、トラフィックが大きく変動したり、使用頻度が低かったりするワークロードにとっては、リソースの過剰プロビジョニングによるコスト増や、急なスパイクへの対応遅延といった課題がありました。

この課題に応える形で登場したのが、AWS Aurora Serverlessです。これは、データベースのキャパシティを自動的にスケールさせ、使用したリソースに対してのみ課金されるという画期的なサービスです。これにより、ユーザーはデータベースインスタンスのサイズ指定や管理から解放され、さらにコスト効率の高い運用が可能になりました。

Aurora Serverlessは、そのコンセプト発表以来、多くの注目を集め、サーバーレスアーキテクチャを志向する開発者や企業にとって魅力的な選択肢となりました。最初にリリースされたバージョンは「Aurora Serverless v1」として知られ、特定のユースケースでその価値を発揮しました。そして、その進化版である「Aurora Serverless v2」が登場し、Serverlessデータベースの能力をさらに高め、より幅広い、そしてよりミッションクリティカルなワークロードに対応できるようになりました。

本記事では、フルマネージドデータベースの究極形とも言えるAurora Serverlessの「真髄」に迫ります。特に、Aurora Serverless v1とv2のそれぞれについて、そのアーキテクチャ、機能、メリット・デメリット、そして適したユースケースを詳細に解説し、両者を徹底的に比較します。さらに、v1からv2への移行戦略についても触れ、読者の皆様が自身の要件に最適なAurora Serverlessのバージョンを選択し、最大限に活用するための情報を提供することを目指します。

AWS Auroraの基本

Aurora Serverlessの詳細に入る前に、まずはその基盤となるAWS Auroraについて、そしてなぜServerlessという形態が求められるのかを理解しておきましょう。

Auroraとは何か？

AWS Auroraは、Amazon Relational Database Service (RDS) のエンジンオプションの一つです。MySQLおよびPostgreSQLと高い互換性を持つリレーショナルデータベースであり、クラウドネイティブな分散型ストレージシステムを特徴としています。

Auroraの最大の特徴は、コンピューティング層とストレージ層が分離している点です。データは複数のアベイラビリティゾーン（AZ）にわたり6重に冗長化された共有ストレージボリュームに格納されます。これにより、非常に高い耐久性と可用性が実現されています。書き込み処理はコンピューティングインスタンスで行われますが、ストレージボリュームに書き込まれるのはトランザクションログのみであり、データブロック全体の書き込みはバックグラウンドで行われます。このログベースのアーキテクチャにより、書き込みパフォーマンスが向上しています。

可用性に関しても、Auroraは高いレベルを提供します。プライマリインスタンスに障害が発生した場合、数秒以内に自動的にリードレプリカが新しいプライマリに昇格します。リードレプリカがない構成でも、障害発生時には新しいインスタンスが自動的にプロビジョニングされ、共有ストレージボリュームにアタッチされます。

プロビジョンドインスタンスとの違い

従来のAurora（プロビジョンドインスタンス）では、ユーザーはEC2インスタンスと同様に、DBインスタンスのサイズ（db.r6g.large, db.r6g.xlargeなど）を指定してコンピューティングリソースをプロビジョニングします。このインスタンスサイズは、特定のvCPU、メモリ、ネットワーク帯域を持ち、固定のキャパシティを提供します。ユーザーはワークロードの最大負荷を予測し、それに合わせたインスタンスサイズを選択する必要があります。

一方、Aurora Serverlessは、このキャパシティ管理を自動化します。ユーザーは最小および最大のキャパシティ範囲を設定するだけで、Auroraが実際のワークロードに応じてコンピューティングリソースを自動的に増減させます。これにより、ユーザーはインスタンスサイズの選定や変更の手間から解放され、利用したリソースに応じた課金となります。

なぜServerlessが必要なのか？

プロビジョンドインスタンスは、安定した予測可能なワークロードや、常に高いパフォーマンスが要求されるワークロードには非常に適しています。しかし、以下のようなシナリオでは課題が生じます。

予測不可能なワークロード: トラフィックが時間帯やイベントによって大きく変動する場合、最大負荷に合わせてインスタンスをプロビジョニングすると、アイドル時間や低負荷時のコストが無駄になります。かといって、低負荷に合わせてプロビジョニングすると、急な負荷増大に対応できません。
断続的なワークロード: 開発環境、テスト環境、バッチ処理、利用頻度の低い内部ツールなど、継続的に使用されないデータベースは、アイドル状態でもコストが発生し続けます。
新規アプリケーション: まだトラフィックパターンが確立されていない新規サービスでは、適切なインスタンスサイズを予測することが困難です。
コスト最適化: 特に中小規模のアプリケーションや、コストを厳しく管理したいプロジェクトでは、固定費となるプロビジョンドインスタンスのコストが負担になる場合があります。

Aurora Serverlessは、これらの課題を解決するために設計されました。自動スケーリングにより、ワークロードの変動に柔軟に対応し、アイドル時にはキャパシティを最小限に抑えることで、コストを大幅に削減できる可能性を秘めています。これにより、ユーザーはインフラ管理の負担を減らし、データベースコストを最適化しながら、アプリケーションの可用性とパフォーマンスを維持できます。

Aurora Serverless v1の詳細解説

Aurora Serverlessの最初のバージョンであるv1は、2018年に登場しました。これは、従来のプロビジョンドインスタンスとは一線を画す新しいコンセプトのデータベースサービスとして大きな注目を集めました。

アーキテクチャ

Aurora Serverless v1のアーキテクチャは、プロビジョンドインスタンスとはいくつかの重要な点で異なります。

プロキシ層: v1は、コンピューティングインスタンスの前にプロキシ層（フリート）を持ちます。アプリケーションからの接続はまずこのプロキシを経由します。スケーリングが発生する際、プロキシは既存のコネクションを新しいキャパシティを持つコンピューティングインスタンスにスムーズに切り替える（ドレインまたは切断）役割を担います。
キャパシティユニット (ACU): コンピューティングキャパシティは、Aurora Capacity Units (ACU) という独自の単位で表現されます。1 ACUあたり約2GBのメモリとそれに相当するCPUおよびネットワークリソースを持ちます。v1では、ACUは通常2 ACU単位でスケールします（最小2 ACUから）。
スケーリングの仕組み: v1は、CPU使用率、コネクション数、ネットワーク帯域などのメトリクスに基づいて自動的にスケールします。スケールアップが必要と判断されると、Auroraは新しいキャパシティを持つコンピューティングインスタンスを準備し、プロキシ経由でトラフィックを誘導します。スケールダウンも同様に行われます。
- スケーリングクールダウン: v1のスケーリングには、スケールアップまたはスケールダウンが完了してから次のスケーリングを開始するまでに一定の時間（通常5分）待機する「クールダウン」期間があります。これにより、短時間での頻繁なスケーリングを防ぎますが、急激なワークロードの変化への追従が遅れる要因にもなりえます。
- コネクションのドレイン: スケールダウン時、v1は既存のコネクションを終了させるために、新しいコネクションを受け付けずに既存のコネクションが終了するのを待ちます（コネクションのドレイン）。ドレイン期間中にコネクションが終了しない場合、最大5分後に強制的にコネクションが切断される可能性があります。スケールアップ時も同様に、スケーリング中に短いコネクション中断が発生する可能性がありました。

特徴と機能

自動スケーリング: ワークロードに応じてACUを自動的に増減させます。ユーザーは最小ACUと最大ACUの範囲を設定します。最小は2 ACU、最大は128 ACUでした。
Pause/Resume機能: 設定された時間（例: 30分）アイドル状態（コネクションがない）が続くと、データベースを一時停止（Pause）させることができます。Pause中はストレージ料金のみが発生し、コンピューティングコストはかかりません。再度コネクションが発生すると、数秒から数十秒で自動的に再開（Resume）されます。この機能は、開発/テスト環境や利用頻度の低いデータベースで特にコスト効率を発揮します。
データAPI: HTTPエンドポイント経由でAurora Serverless v1にアクセスできる機能です。アプリケーションは従来のDBドライバーを使用する必要がなく、HTTPSリクエストでSQLを実行できます。これは特にLambda関数などのサーバーレスコンピューティングサービスとの連携を容易にしました。
リージョン内高可用性: プロビジョンドインスタンスと同様に、データはAZ間で冗長化されたストレージに保存されます。コンピューティングインスタンスに障害が発生した場合、自動的に別のインスタンスが起動し、ストレージにアタッチされます。ただし、v1は単一のコンピューティングインスタンスで稼働するため、リードレプリカを持つプロビジョンドインスタンスのようなスタンバイ構成ではありませんでした。
セキュリティ: VPC内に配置され、セキュリティグループ、IAM認証、保管時の暗号化（KMS）など、RDSの標準的なセキュリティ機能を利用できます。
対応エンジン: リリース当初はMySQL互換のみでしたが、後にPostgreSQL互換もサポートされました。ただし、サポートされるマイナーバージョンはプロビジョンドインスタンスに比べて限定的でした。

メリット

管理の容易さ: インスタンスサイズの選定や変更、キャパシティプランニングの手間が大幅に軽減されます。
アイドル時のコスト削減: Pause/Resume機能により、使用しない時間帯のコンピューティングコストをゼロにできます。
予測不可能なワークロードへの対応: トラフィックの急増や減少に対して自動的にスケールするため、リソースの過不足を抑えられます。
Data API: サーバーレスアーキテクチャとの連携を簡素化します。

デメリット

スケーリングの遅延とコネクション中断リスク: v1のスケーリングプロセスは比較的時間がかかり（数分から10分以上）、特にスケールダウン時にはコネクションが切断される可能性がありました。これにより、ミッションクリティカルなアプリケーションやリアルタイム性が求められるアプリケーションには不向きでした。
スケーリングイベント中のパフォーマンス変動: スケーリング中に、アプリケーションからのリクエストに対する応答時間が長くなるなどのパフォーマンス劣化が発生することがありました。
最小ACUが高止まりする可能性: ワークロードが非常に低い場合でも、最小2 ACUで起動するため、プロビジョンドのマイクロインスタンスなどと比較してコストが高くなる可能性がありました。また、最小ACUを2よりも小さく設定することはできませんでした。
レプリカインスタンスの非サポート: v1はリードレプリカをサポートしていませんでした。そのため、読み取りワークロードの分散や、リードレプリカをフェイルオーバーターゲットとする高可用性構成を構築できませんでした。
特定の機能制約: グローバルデータベース、Blue/Green Deployments、Performance Insightsの全機能など、プロビジョンドインスタンスで利用できる一部の高度な機能がサポートされていませんでした。
対応DBエンジンバージョン: サポートされるMySQLやPostgreSQLのバージョンが、プロビジョンドインスタンスに比べて限定的でした。

適したユースケース

Aurora Serverless v1は、その特徴と制約から、以下のようなユースケースに適していました。

開発/テスト環境: コスト効率が重要であり、スケーリング時の遅延やコネクション中断が許容される環境。
使用頻度の低いアプリケーション: 社内ツールやアーカイブデータへのアクセスなど、利用が断続的なアプリケーション。
断続的なワークロード: 定期的に実行されるバッチ処理、特定の期間だけ利用されるキャンペーンサイトやイベントサイトなど。
トラフィック量が少なく、予測不可能な新規アプリケーション: 初期段階でキャパシティを予測するのが難しいが、まだミッションクリティカルではないアプリケーション。

v1は確かに革新的なサービスでしたが、スケーリング時の課題や機能制約により、本番環境のミッションクリティカルなワークロードに適用するには限界がありました。これらの課題を克服するために開発されたのが、Aurora Serverless v2です。

Aurora Serverless v2の詳細解説

Aurora Serverless v2は、2022年にGA（一般提供）が開始された、Aurora Serverlessのメジャーアップデート版です。v1の課題を解決し、より幅広い、特にミッションクリティカルな本番ワークロードにServerlessのメリットをもたらすことを目指して設計されました。

アーキテクチャ

Aurora Serverless v2のアーキテクチャは、v1から大きく進化し、プロビジョンドインスタンスのアーキテクチャに非常に近くなっています。

共有ストレージ基盤の活用: v2は、プロビジョンドインスタンスと同じ、AZ間で共有される分散ストレージボリュームを使用します。これにより、プロビジョンドインスタンスで提供される多くの機能がv2でも利用可能になりました。
秒単位のマイクロスケール: v2の最も大きな進化は、スケーリングの仕組みです。v1のようなコネクションドレインやクールダウン期間を必要とせず、ワークロードの小さな変動（ACU単位の0.5 ACU刻み）に対して、秒単位でほぼ瞬時に、かつアプリケーションに透過的にスケールアップ・スケールダウンが可能です。これは、データベースエンジン自体がリソース管理を動的に行うようになったためです。
Aurora Endpoint: アプリケーションからの接続は、プロビジョンドインスタンスと同様に、特定のDBエンドポイント（クラスターエンドポイント、リーダーエンドポイントなど）を使用します。v1のような専用のプロキシ層の存在はユーザーから意識されなくなりました。
リードレプリカ、グローバルデータベースのサポート: v2では、プロビジョンドインスタンスと同様にリードレプリカを作成できます。また、Aurora Global Databaseの一部としてv2クラスターを配置することも可能です。これは、v2がプロビジョンドインスタンスとストレージアーキテクチャを共有していることによる大きなメリットです。

特徴と機能

Aurora Serverless v2は、v1と比較して大幅に機能が強化され、プロビジョンドインスタンスで提供される機能のほとんどをサポートしています。

連続的かつきめ細やかな自動スケーリング: CPU使用率、メモリ使用率、コネクション数などのメトリクスに基づき、0.5 ACU刻みで、秒単位でスケーリングします。最小ACUは0.5 ACU、最大は128 ACUまで設定可能です。このきめ細やかさと速度が、アプリケーションへの影響を最小限に抑えます。
スケーリング中のコネクション維持: スケーリング中も既存のデータベースコネクションは維持されます。アプリケーションはスケーリングの発生をほとんど意識する必要がありません。これにより、スケーリング中のパフォーマンス低下やコネクション切断のリスクが大幅に低減されました。
最小ACUの柔軟性: 最小キャパシティを0.5 ACUまで設定できるため、v1の最小2 ACUと比較して、低負荷時のコストをさらに抑えることが可能です。ただし、v1のようなPause/Resume機能はありません。
リードレプリカのサポート: リードレプリカを作成し、読み取りワークロードをオフロードしたり、プライマリインスタンスのフェイルオーバーターゲットとして利用したりできます。リードレプリカもServerless v2として構成できるため、読み取り負荷に応じた自動スケーリングが可能です。
Aurora Global Databaseのサポート: 異なるリージョンに跨る災害対策（DR）や、リージョン間の高速なレプリケーションを実現するAurora Global Databaseに参加できます。これにより、ミッションクリティカルなアプリケーションの可用性をさらに高められます。
Blue/Green Deploymentsのサポート: ゼロダウンタイムに近い環境でデータベースのバージョンアップやスキーマ変更を行うためのBlue/Green Deploymentsを利用できます。
スナップショットからのリストア時間の高速化: 共有ストレージアーキテクチャにより、スナップショットからのリストア時間が大幅に短縮されました。
充実した監視機能: Performance Insights、Enhanced Monitoringなど、プロビジョンドインスタンスで利用できる高度な監視ツールがサポートされています。
幅広いDBエンジンバージョンと機能サポート: プロビジョンドインスタンスと同等のMySQLおよびPostgreSQLのバージョン、そしてストアドプロシージャ、トリガー、外部キーなどのデータベース機能が完全にサポートされています。
データAPIの非サポート: v2ではv1にあったData APIは提供されません。通常のデータベース接続（JDBC, ODBCなど）を利用する必要があります。これは、v2がプロビジョンドインスタンスと同等の幅広いワークロードを想定しているため、標準的なアクセス方法に回帰したと解釈できます。
Pause/Resume機能の非サポート: v1にあった、アイドル時にコンピューティングコストをゼロにするPause/Resume機能はv2にはありません。これは、v2が常に高速な応答性を維持し、急な負荷増大にも即座に対応できるよう、スタンバイ状態を維持するためと考えられます。

メリット

ほぼ瞬時の、アプリケーションに透過的なスケーリング: スケーリングが高速かつ滑らかになり、アプリケーションへの影響が最小限に抑えられます。これにより、ミッションクリティカルなワークロードにも適用可能です。
より幅広いワークロードへの対応: プロビジョンドインスタンスに近い機能セットと高性能な自動スケーリングにより、予測困難だが継続的なトラフィックを持つアプリケーション、大規模なエンタープライズアプリケーション、SaaSバックエンドなど、より多様なユースケースに対応できます。
リードレプリカによる読み取り性能向上と可用性強化: リードレプリカを活用することで、読み取り負荷の高いアプリケーションのパフォーマンスを向上させ、高可用性構成を容易に実現できます。
グローバルデータベースによるDR/複数リージョン対応: 異なるリージョンでの冗長構成により、事業継続計画（BCP）やDR戦略を強化できます。
最小ACUの低減によるコスト効率向上: 最小0.5 ACUからの設定が可能になり、低負荷時のコストをv1よりもさらに削減できる場合があります（ただし、継続的に低負荷の場合）。
プロビジョンドと同等の機能セット: 大半のAurora機能が利用できるため、Serverlessを選択することによる機能的な制約が大幅に減少しました。

デメリット

Pause/Resume機能がない: v1のようにアイドル時にコンピューティングコストをゼロにすることはできません。継続的に非常に低い負荷（最小ACUの設定値以下）のワークロードにとっては、v1のPause/Resume機能があった方がコスト効率が良い可能性があります。v2は最小ACU分のコストは常時発生します。
v1と比較して最小コストは高くなる可能性: Pause/Resume機能がないため、開発環境やテスト環境のように全く使われない時間が多い場合、v1よりもv2の方がコストが高くなる可能性があります。ただし、これはワークロードパターンに大きく依存します。
Data APIは非サポート: Data APIを利用していたアプリケーションは、通常のDB接続に切り替える必要があります。

適したユースケース

Aurora Serverless v2は、その高性能かつ透過的な自動スケーリングと豊富な機能サポートにより、以下のような幅広いユースケースに最適です。

ミッションクリティカルな本番ワークロード: スケーリング中のダウンタイムやパフォーマンス劣化が許容されないアプリケーション。
予測困難だが継続的なトラフィックを持つアプリケーション: トラフィックが変動するが、常に一定レベル以上の負荷があるアプリケーション。
SaaSアプリケーション: 顧客ごとのトラフィックが変動したり、全体として利用率のピークが予測しにくかったりする場合。
大規模なエンタープライズアプリケーション: 複雑なワークロードや厳しい要件を持つ基幹システムなど。
読み取り負荷の高いアプリケーション: リードレプリカを活用して読み取り性能を向上させたい場合。
事業継続計画（BCP）/災害対策（DR）が必要なアプリケーション: Aurora Global Databaseを利用する場合。

Aurora Serverless v1 vs v2: 詳細比較

ここで、Aurora Serverless v1とv2の主な違いを、様々な観点から比較してみましょう。

比較項目	Aurora Serverless v1	Aurora Serverless v2	補足
自動スケーリングの挙動	段階的、スケーリングクールダウンあり	連続的、きめ細やか (0.5 ACU刻み)	v2の方が高速かつ滑らか。
スケーリング速度	遅い (数分〜10分以上)	ほぼ瞬時 (秒単位)	v2の最大の進化点。
スケーリング粒度	通常2 ACU刻み	0.5 ACU刻み	v2の方がより細かい調整が可能。
スケーリング中の影響	コネクション中断リスクあり、パフォーマンス変動あり	コネクション維持、アプリケーションに透過的	v2はミッションクリティカルなワークロードに適している。
最小ACU	2 ACU	0.5 ACU	v2はより低い最小キャパシティから開始可能。
最大ACU	128 ACU	128 ACU (特定のインスタンスタイプではそれ以上も可能に)	最大キャパシティの柔軟性は両バージョンで高い。
アイドル時コスト	Pause/Resume機能でゼロにできる (ストレージコストのみ)	最小ACU分のコストは常時発生 (Pause機能なし)	利用頻度によってはv1が有利。
アーキテクチャ	専用プロキシ層あり、ストレージとの連携が限定的	プロビジョンドインスタンスと同等、共有ストレージ活用	v2がプロビジョンドと同じアーキテクチャ基盤に乗った。
リードレプリカ	非サポート	サポート	v2は読み取り性能向上や高可用性構成が可能。
Aurora Global DB	非サポート	サポート	v2はリージョン間DR/レプリケーションが可能。
Blue/Green Deployments	非サポート	サポート	v2はダウンタイムを抑えたDB変更が可能。
Data API	サポート	非サポート	v1はHTTPアクセス可能、v2は通常のDB接続が必要。
Pause/Resume機能	サポート (アイドル時コスト削減)	非サポート	v1の大きな特徴。v2は常に利用可能な状態を維持。
対応ワークロード	断続的、予測困難、非ミッションクリティカル	継続的、予測困難、ミッションクリティカル、高負荷、読み取り集中	v2はより広範なワークロードに対応。
機能セット	プロビジョンドと比較して限定的	プロビジョンドと同等レベル (多くの機能を追加)	v2は高度なAurora機能が利用可能。
コストモデル	使用ACUとPause期間に基づく (ACU時間単位)	使用ACUに基づく (ACU秒単位)	v2はより細かい課金単位。

スケーリング

スケーリングの挙動と速度は、v1とv2の最も大きな違いです。v1は、キャパシティを変更するために内部的に新しいインスタンスを準備し、プロキシ経由でトラフィックを切り替える必要がありました。このプロセスには時間がかかり、特にスケールダウン時にはアクティブなコネクションが終了するまで待つ（またはタイムアウトで切断する）という課題がありました。これにより、アプリケーションが短時間でもデータベースに接続できない、あるいは処理が遅延するといった影響を受ける可能性がありました。

一方、v2は、Auroraの分散ストレージアーキテクチャと緊密に連携し、コンピューティングリソースを動的に割り当てることで、この課題を解決しました。データベースエンジン自体が、必要に応じてCPUやメモリを0.5 ACUという小さな粒度で増減させることが可能です。これにより、スケーリングはほぼ瞬時に完了し、既存のデータベースコネクションは維持されます。アプリケーションは、データベースのキャパシティが増減していることをほとんど意識する必要がありません。これは、特に急激な負荷変動があるミッションクリティカルなアプリケーションにとって非常に重要です。

アーキテクチャと機能サポート

v1は、Serverlessというコンセプトを先行して実現するために、プロビジョンドインスタンスとは異なるプロキシベースのアーキテクチャを採用しました。これは手軽さを提供しましたが、Auroraの共有ストレージアーキテクチャが持つ本来の能力（リードレプリカ、Global Databaseなど）を十分に引き出せていませんでした。

v2は、プロビジョンドインスタンスと同じ共有ストレージアーキテクチャ上に構築されました。これにより、v1では利用できなかった多くの重要な機能がv2でサポートされるようになりました。リードレプリカは、読み取り負荷を分散させるだけでなく、プライマリインスタンスに障害が発生した場合の高速なフェイルオーバー先としても機能するため、可用性向上に不可欠です。Aurora Global Databaseは、リージョン障害に対するDR戦略を可能にします。Blue/Green Deploymentsは、本番環境での安全なデータベース変更を実現します。これらの機能は、エンタープライズレベルのアプリケーションやミッションクリティカルなサービスにとって必須となることが多く、v2がこれらの要件を満たせるようになったことは大きな進歩です。

コストモデル

どちらのバージョンも、ACUという単位でキャパシティを表現し、使用したACUに対して課金されます。

v1は、ACU時間単位での課金が基本ですが、アイドル時にはPause機能でコンピューティングコストをゼロにできる点が大きな特徴でした。最小2 ACU、最大128 ACUの間でスケールします。

v2は、ACU秒単位での課金となります。これは、きめ細やかなスケーリングを反映したものです。最小ACUは0.5 ACUから設定でき、最大128 ACUまでスケールします。v2にはPause機能がないため、たとえ全くワークロードがない時間帯でも、設定した最小ACU（0.5 ACU以上）分のコストは常時発生します。

したがって、コスト効率の観点では、使用頻度が非常に低く、長時間のアイドル期間があるワークロードでは、v1のPause機能がコストをゼロにできるため有利な場合があります。一方、断続的または継続的に負荷があり、特に負荷変動が大きいワークロードでは、v2のきめ細やかなスケーリングと低い最小ACU（0.5 ACU）設定が、無駄なキャパシティを最小限に抑えるため、結果的にv1よりもコスト効率が良くなる可能性が高いです。また、v2はスケーリングが高速でアプリケーションへの影響が少ないため、パフォーマンス要件の高いワークロードでは、多少コストが高くなってもv2を選択する価値があります。

運用管理

v1もServerlessとして管理の手間は少ないですが、スケーリング時の挙動を考慮したアプリケーション設計や運用監視が必要でした。例えば、スケーリングイベント中に発生しうるコネクション切断に対応するためのアプリケーション側のリトライロジックなどです。

v2は、スケーリングがアプリケーションに透過的であるため、運用管理の観点ではプロビジョンドインスタンスとほぼ同じように扱えます。スケーリングイベントを特に意識した特殊な運用は不要です。プロビジョンドインスタンスと同様に、Enhanced MonitoringやPerformance Insightsといった豊富なツールを利用して、詳細なパフォーマンスやリソースの使用状況を監視できます。自動パッチ適用、バックアップ、ポイントインタイムリカバリなどの機能も標準で利用可能です。

移行戦略: v1からv2へ

現在Aurora Serverless v1を利用しているユーザーにとって、v2への移行は重要な検討事項となります。v2は多くの点でv1より優れており、特に本番ワークロードへの適用においてはv2が圧倒的に有利です。

なぜ移行すべきか？

v2の主なメリット（高速スケーリング、機能豊富さ、ミッションクリティカル対応）に加えて、v1はAWSによる継続的な機能強化の中心から外れつつあります。新しいDBエンジンバージョンや機能は基本的にv2で優先的にサポートされます。また、将来的にはv1のサポート終了（EOL: End-of-Life）が発表される可能性もゼロではありません。これらの理由から、特に本番環境でv1を利用している場合は、できるだけ早期にv2への移行を検討することが推奨されます。

移行前の考慮事項

移行を開始する前に、以下の点を考慮する必要があります。

互換性の確認: 利用しているDBエンジン（MySQLまたはPostgreSQL）のバージョンがv2でサポートされているか確認します。古いマイナーバージョンを使用している場合は、v2がサポートするバージョンへのアップグレードが必要になる可能性があります。
機能要件の確認: Data APIを利用している場合は、アプリケーションを通常のDB接続に変更する必要があります。Pause/Resume機能に依存している場合は、v2ではこの機能がないことを考慮し、最小ACUの設定や常に稼働していることによるコスト増を許容できるか検討します。
コストシミュレーション: 現在のv1の使用状況（平均ACU、ピークACU、アイドル時間）とv2の最小/最大ACU設定候補、およびv2の料金体系に基づいて、移行後のコストをシミュレーションします。v1でPause機能によりコストを大幅に削減していた場合、v2では最小ACU分のコストが常時発生するため、コストが増加する可能性があります。
アプリケーションの互換性テスト: v2に移行した後、アプリケーションが問題なく動作するか、特にスケーリング時の挙動やパフォーマンスについて十分にテストする計画を立てます。

移行方法

v1からv2への移行方法はいくつかあります。主要な方法を以下に示します。

スナップショットからのリストア: 最もシンプルで一般的な方法です。
- v1クラスターの手動スナップショットを作成します。
- 作成したスナップショットから、Aurora Serverless v2クラスターとしてリストアします。
- リストアされたv2クラスターの最小/最大ACUを設定し、必要に応じてパラメータグループを設定します。
- アプリケーションからの接続先をv2クラスターのエンドポイントに切り替えます。
- 注意点: スナップショット作成時点からのデータ変更は含まれません。短いダウンタイムが発生します。
論理レプリケーション（MySQLの場合）: MySQLのネイティブなレプリケーション機能（バイナリログレプリケーション）を利用します。
- v1クラスターをプライマリ（マスター）、新しく作成したv2クラスターをレプリカ（スレーブ）として設定します。
- v1からv2へのデータ同期が完了するのを待ちます。
- 同期が完了したら、アプリケーションからの書き込みを停止します。
- v2クラスター上でレプリケーションを停止し、必要に応じてリードオンリー設定を解除します。
- アプリケーションからの接続先をv2クラスターのエンドポイントに切り替えます。
- 注意点: 設定がやや複雑です。v2クラスターが論理レプリケーションのレプリカとして機能するように設定が必要です。ダウンタイムはスナップショットからのリストアより短縮できますが、書き込み停止期間が必要です。
AWS Database Migration Service (DMS) の利用: DMSを使用して、v1からv2へデータを継続的にレプリケーションします。
- v1クラスターをソースエンドポイント、v2クラスターをターゲットエンドポイントとしてDMSレプリケーションタスクを設定します。
- DMSタスクを実行し、初期ロードと継続的な変更データキャプチャ（CDC）を行います。
- v2クラスターがv1クラスターとほぼリアルタイムで同期していることを確認します。
- アプリケーションからの書き込みを停止します。
- DMSタスクが完全に同期するのを待ちます。
- アプリケーションからの接続先をv2クラスターのエンドポイントに切り替えます。
- 注意点: DMSは別途コストがかかります。設定や監視が必要ですが、ダウンタイムを最小限に抑えることが可能です。複雑なスキーマや大量のデータの場合に適しています。

どの方法を選択する場合でも、事前に十分なテストを行うことが重要です。特に、移行後のv2クラスターでアプリケーションの負荷テストを行い、設定した最小/最大ACU範囲で期待通りのパフォーマンスが得られるか、スケーリングがスムーズに行われるかなどを確認してください。

移行中の注意点

バックアップ: 移行作業を開始する前に、必ずv1クラスターの最終的なスナップショットを手動で作成しておきましょう。
ダウンタイム計画: スナップショットからのリストアや論理レプリケーション、DMSの切り替え時には、アプリケーションのダウンタイムが発生する可能性があります。計画的にメンテナンスウィンドウを設けるか、ダウンタイムを最小限にするための戦略（DMSなど）を選択してください。
アプリケーションのテスト: 移行後のv2クラスターに対して、本番環境に近いワークロードでアプリケーションの動作確認と性能テストを必ず実施してください。

移行後の検証とモニタリング

v2への移行が完了したら、以下の点を継続的に監視・検証します。

アプリケーションの動作: エラーが発生していないか、パフォーマンスが劣化していないかを確認します。
データベースのパフォーマンス: Performance InsightsやEnhanced Monitoringを使用して、CPU使用率、メモリ使用率、スループット、レイテンシなどを監視します。
スケーリング挙動: ワークロードに応じてACUが適切に増減しているか、最小/最大ACU設定が適切かを確認します。必要に応じて調整します。
コスト: 予想していたコストシミュレーションと比較して、実際のコストがどうなっているかを確認します。

v2はv1とは異なる特性を持つため、移行後しばらくは注意深く監視を行い、必要に応じて設定を調整していくことが重要です。

Aurora Serverless v2のさらなる可能性

Aurora Serverless v2は、プロビジョンドインスタンスの能力とServerlessの柔軟性を組み合わせたことで、リレーショナルデータベースの利用方法に新たな可能性をもたらしました。

将来的展望

AWSはAurora Serverless v2の開発に注力しており、今後も機能強化や対応DBエンジンの拡充が期待されます。例えば、さらに高い最大ACUのサポート、より多くのAurora機能（機械学習統合など）のサポート、さらなるパフォーマンス最適化などが考えられます。v2はプロビジョンドインスタンスと同じ基盤上に構築されているため、プロビジョンドインスタンスで利用可能になった新しい機能は、比較的早期にv2でも利用可能になる可能性が高いです。

他のAWSサービスとの連携

Aurora Serverless v2は、その自動スケーリングの特性から、他のサーバーレスまたは伸縮自在なAWSサービスと非常に相性が良いです。

AWS Lambda/Fargate/ECS/EKS: イベント駆動型やコンテナ化されたアプリケーションは、トラフィックに応じてコンピューティングリソースが自動的にスケールします。これらのサービスとAurora Serverless v2を組み合わせることで、バックエンド全体を完全にサーバーレスまたは伸縮自在な構成で構築し、インフラ管理の負担を大幅に軽減できます。
Amazon SageMaker: 機械学習のトレーニングや推論で大量のデータを扱う際に、必要に応じてスケーリングするデータベースとしてAurora Serverless v2を利用できます。
AWS Glue: サーバーレスなETLサービスであるGlueからAurora Serverless v2に接続し、データの抽出・変換・ロードを行うことができます。

これらの連携により、エンドツーエンドのサーバーレスアーキテクチャや、特定の用途に最適化された伸縮自在なデータ処理基盤を構築する際の選択肢が広がります。

データドリブンなアーキテクチャにおける役割

現代のアプリケーションは、多くの場合、データドリブンなアーキテクチャを採用しています。リアルタイムなデータ処理、分析、機械学習などが重要性を増しています。Aurora Serverless v2は、変動するデータアクセスパターンや、急増するデータ処理要請に対して、柔軟かつコスト効率良く対応できるため、このようなデータドリブンなアーキテクチャにおいて重要な役割を果たすことができます。特に、データレイクやデータウェアハウスと連携し、リアルタイム分析のバックエンドとして利用されるケースも増えていくでしょう。

まとめ

本記事では、フルマネージドデータベースの進化形であるAWS Aurora Serverless v1とv2について、そのアーキテクチャ、機能、メリット・デメリット、そしてユースケースを詳細に比較解説しました。

Aurora Serverless v1は、アイドル時のコスト削減や予測不可能な低〜中規模ワークロードへの対応という点で革新的でしたが、スケーリング時の遅延やコネクション中断、機能制約といった課題がありました。これは主に、開発/テスト環境や、利用頻度の低いアプリケーションに適していました。

一方、Aurora Serverless v2は、v1の課題を克服し、ほぼ瞬時のアプリケーション透過的なスケーリング、そしてプロビジョンドインスタンスと同等レベルの豊富な機能サポート（リードレプリカ、Global Database、Blue/Greenなど）を実現しました。これにより、ミッションクリティカルな本番ワークロード、予測困難だが継続的なトラフィックを持つアプリケーション、大規模なSaaSバックエンドなど、より幅広い、より厳しい要件を持つユースケースに対応できるようになりました。v2はPause/Resume機能がないため、完全にアイドル状態になることが頻繁にあるワークロードではv1の方がコスト効率が良い場合もありますが、それ以外の多くのシナリオではv2の柔軟性と高性能が大きなメリットとなります。

v1からv2への移行は、v2の優位性や将来性を考慮すると推奨される選択肢です。スナップショットからのリストア、論理レプリケーション、DMSなど、いくつかの移行方法があり、それぞれの特性を理解した上で最適な方法を選択し、入念な計画とテストを行うことが成功の鍵となります。

Aurora Serverless v2は、リレーショナルデータベースの「Serverless」の概念を次のレベルに引き上げました。DB管理の手間を最小限に抑えながら、ワークロードに応じて柔軟にキャパシティを調整し、高いパフォーマンスと可用性、そしてコスト効率を実現します。これにより、企業はデータベースインフラストラクチャの運用負荷から解放され、ビジネス価値を生み出すアプリケーション開発に集中できます。

フルマネージドDBの真髄は、まさに「運用からの解放」と「必要な時に必要なだけリソースを利用できる柔軟性」にあります。Aurora Serverless v2は、この真髄を高いレベルで体現しており、現代のクラウドネイティブなアプリケーション開発において、非常に強力な選択肢となるでしょう。

どちらのバージョンを選択するかは、最終的にはワークロードの特性、コスト要件、必要な機能セット、そしてスケーリングの要件によって決定されます。本記事が、皆様のAurora Serverlessの理解を深め、最適な選択を行うための一助となれば幸いです。