AuroraクラスターをServerless v2に移行してみる

AuroraクラスターをServerless v2に移行してみる

2025.12.03

ゲームソリューション部の えがわ です。

開発環境で運用しているAuroraクラスターを、ProvisionedからServerless v2に移行する機会があったので備忘録として残しておきます。

前提

  • 既存のAuroraクラスター(Provisioned)が存在する
  • 開発環境での移行を想定

Serverless v2とは

Aurora Serverless v2は、ワークロードに応じて自動的にスケールアップ・ダウンするマネージドデータベースサービスです。
Provisionedクラスターと比較して、以下のメリットがあります。

  • コスト最適化: 使用量に応じて自動スケールするため、アイドル時のコストを削減
  • パフォーマンス: 必要に応じて自動的にスケールアップし、ピーク時のパフォーマンスを維持
  • 運用の簡素化: 手動でのスケーリング設定が不要

移行手順

1. 既存クラスターの変更

既存のProvisionedクラスターを直接Serverless v2に変更します。

AWSマネジメントコンソールで、移行対象のAuroraインスタンスを選択し、「変更」を選択します。

「インスタンスの設定」セクションで「Serverless v2」を選択します。

aurora_serverless_migrate_01.png

2. ACU(Aurora Capacity Unit)の設定

Serverless v2では、ACU(Aurora Capacity Unit)で容量を設定します。

  • 最小ACU: 0(最小値)
  • 最大ACU: 1(開発環境の場合、必要に応じて調整)

ACUは、使用量に応じて最小ACUから最大ACUの間で自動的にスケールします。

設定を確認し、「変更の確認」を押下します。

変更内容を確認し、「今すぐ適用」または「メンテナンスウィンドウ中に適用」を選択します。

今回は「今すぐ適用」を選択して即座に変更を適用します。

aurora_serverless_migrate_02.png

4. 動作確認

せっかくなので、接続できなくなる時間と再開する時間を計測してみます。
以下のスクリプトは変更の適用前に実行しています。

#!/bin/bash

# データベース接続情報
DB_HOST="{host}"
DB_USER="{user}"
DB_PASS="{password}"
DB_PORT="3306"

# 接続確認間隔(秒)
INTERVAL=0.2

echo "データベース接続監視を開始します..."
echo "ホスト: $DB_HOST"
echo "間隔: ${INTERVAL}秒"
echo "-----------------------------------"

while true; do
    TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S.%3N')

    if mysqladmin ping -h "$DB_HOST" -u "$DB_USER" -p"$DB_PASS" --connect-timeout=1 2>/dev/null | grep -q "alive"; then
        echo "[$TIMESTAMP] 接続可能 ✓"
    else
        echo "[$TIMESTAMP] 接続不可 ✗"
    fi

    sleep $INTERVAL
done
[ec2-user@ip-172-31-21-142 ~]$ chmod +x db_check.sh
[ec2-user@ip-172-31-21-142 ~]$ ./db_check.sh
データベース接続監視を開始します...
ホスト: {host}
間隔: 0.2秒
-----------------------------------
[2025-12-03 03:53:57.201] 接続可能 ✓
[2025-12-03 03:53:57.417] 接続可能 ✓

...中略...

[2025-12-03 03:55:29.465] 接続可能 ✓
[2025-12-03 03:55:29.676] 接続可能 ✓  # ここで変更をリクエスト
[2025-12-03 03:55:29.889] 接続可能 ✓

...中略...

[2025-12-03 03:57:03.628] 接続可能 ✓
[2025-12-03 03:57:03.843] 接続可能 ✓
[2025-12-03 03:57:04.058] 接続不可 ✗  # 約90秒で接続不可
[2025-12-03 03:57:04.266] 接続不可 ✗

...中略...

[2025-12-03 04:02:15.557] 接続不可 ✗
[2025-12-03 04:02:15.767] 接続不可 ✗
[2025-12-03 04:02:15.977] 接続可能 ✓  # 約5分で接続可能
[2025-12-03 04:02:16.769] 接続可能 ✓

コスト比較

Provisioned(t4g.medium)の場合

  • インスタンスタイプ: db.t4g.medium
  • 時間あたりのコスト: 約$0.113
  • 月額コスト: 約$81(24時間×30日×$0.113)

Serverless v2の場合

  • 最小ACU: 0
  • 最大ACU: 1
  • ACUあたりのコスト: 約$0.15/ACU時間

1日のうち8時間のみ使用する場合(最大ACUで動作した場合)

  • アクティブ時間: 1 ACU × $0.15 × 8時間 = $1.20/日
  • アイドル時間: 0 ACU × $0.15 × 16時間 = $0/日
  • 1日あたりのコスト: $1.20
  • 月額コスト: 約$36($1.20 × 30日)

24時間フル稼働した場合でも(最大ACUで動作した場合)

  • 月額コスト: 約$108(1 ACU × $0.15 × 24時間 × 30日)

実際の使用量に応じて、0.5 ACUから1 ACUの間で自動的にスケールするため、実際のコストは使用パターンによって変動します。

さいごに

AuroraクラスターをServerless v2に移行することで、エンドポイントも変わらずに開発環境のコストを最適化することができる場合があります。
開発環境では、使用時間が限定的なため、Serverless v2の自動スケーリング機能が有効に働きます。
この記事がどなたかの参考になれば幸いです。

この記事をシェアする

FacebookHatena blogX

関連記事