Aurora Serverless v2の待機インスタンス0検証 〜本当にコスト最適化できるのか〜

はじめに

AWS Aurora Serverless v2において、待機インスタンスを0に設定できるようになりました。
これにより、完全なサーバーレス運用が可能となり、コスト最適化の新たな選択肢となりました。
本記事では、実際にどの程度の起動時間がかかるのか、実用に耐えうるのかを検証していきます。

検証環境

• Aurora Serverless v2 (MySQL 8.0互換)
• 最小ACU: 0
• 最大ACU: 1
• リージョン: ap-northeast-1（東京）
• テストデータ: MySQL公式提供の「Worldデータベース」
  • 内容: 国、都市、言語に関するデータ
  • ダウンロードURL: MySQL Sample Databases

テストデータの準備

テストデータには、MySQL公式が提供する「Worldデータベース」を使用します。このデータセットはAurora Serverlessv2で簡単にインポート可能で、国や都市、言語に関するデータが含まれています。

ダウンロードとセットアップ手順

1. データベースファイルのダウンロード
   以下のリンクから「World Sample Database」をダウンロードしてください。
   • ダウンロードURL: https://dev.mysql.com/doc/index-other.html
     ファイル名は world.sql.gz です。
2. データベースファイルのインポート
   解凍した world.sql をAuroraにインポートします。

検証項目

1. コールドスタート時の起動時間計測
2. 連続アクセス時のレスポンスタイム計測

検証コード

必要なライブラリのインストール

pip install pymysql sshtunnel

from sshtunnel import SSHTunnelForwarder
import pymysql
import time

# SSHトンネル設定
SSH_HOST = "bastion.example.com" # 踏み台サーバーのホスト名またはIPアドレス
SSH_PORT = 22                    # SSHのポート番号（通常22）
SSH_USER = "ec2-user"            # SSHユーザー名
SSH_KEY = "~/.ssh/id.pem"        # SSH秘密鍵のパス
REMOTE_BIND_NAME = "aurora-cluster-xyz.amazonaws.com" # Auroraのエンドポイント
REMOTE_BIND_PORT = 3306          # Auroraのポート番号（通常3306）

# Aurora接続情報
DB_HOST = "127.0.0.1"      # ローカルホスト
DB_PORT = 3306             # ローカルポート番号（SSHトンネル経由）
DB_USER = "admin"          # Auroraユーザー名
DB_PASSWORD = "your-password" # Auroraパスワード
DB_NAME = "world"          # データベース名

def measure_query_time(server):
    """クエリ実行時間を計測する"""
    query = "SELECT COUNT(*) FROM city;"  # 簡単なクエリ
    start_time = time.time()
    try:
        conn = pymysql.connect(
            host=DB_HOST,
            port=server.local_bind_port,
            user=DB_USER,
            password=DB_PASSWORD,
            database=DB_NAME,
        )
        with conn.cursor() as cursor:
            cursor.execute(query)
            result = cursor.fetchone()
            print(f"クエリ結果: {result}")
        conn.close()
    except Exception as e:
        print(f"クエリエラー: {e}")
        return None
    end_time = time.time()
    return end_time - start_time

if __name__ == "__main__":
    # SSHトンネルを作成
    with SSHTunnelForwarder(
        (SSH_HOST, SSH_PORT),
        ssh_host_key=None,
        ssh_username=SSH_USER,
        ssh_password=None,
        ssh_pkey=SSH_KEY,
        remote_bind_address=(REMOTE_BIND_NAME, REMOTE_BIND_PORT)
    ) as server:
        print("クエリ実行時間を計測中...")
        query_time = measure_query_time(server)
        if query_time is not None:
            print(f"クエリ実行時間: {query_time:.2f}秒")

検証結果

1.コールドスタート時のパフォーマンス

• クエリ実行までにかかった時間（5回実行の記録）:
  • 1回目: 14.58秒
  • 2回目: 13.30秒
  • 3回目: 15.65秒
  • 4回目: 14.26秒
  • 5回目: 14.97秒
• 平均時間: 14.55秒

2.連続アクセス時のパフォーマンス

• 2回目以降のクエリ実行までにかかった時間（5回実行の記録）
  • 1回目: 1.01
  • 2回目: 1.01
  • 3回目: 1.02
  • 4回目: 1.01
  • 5回目: 1.02
• 平均時間: 1.01秒

コスト比較

前提条件

• アクティブ時間: 平日8時間 × 月20日間（合計160時間）
  • アクティブ時間中は、従来構成・新構成ともに 1 ACU を利用。
• アイドル時間: アクティブ時間以外（24時間 - 8時間 × 30日間、合計480時間）
  • 従来構成: 最小0.5 ACUで稼働。
  • 新構成: アイドル時は 0 ACU にスケールダウンし、課金が発生しない。
• 1 ACUあたりのコスト: $0.15/時間（東京リージョン）
• ストレージ料金などのコストは考慮しないものとする

比較結果

従来構成（最小0.5 ACU）

• アクティブ時間: 160時間（8時間 × 20日間, 1 ACU利用）
  • コスト: $24.0
• アイドル時間: 480時間（(24 - 8)時間 × 30日間, 0.5 ACU利用）
  • コスト: $36.0
• 合計: $60.0/月

新構成（最小ACU 0）

• アクティブ時間: 160時間（8時間 × 20日間, 1 ACU利用）
  • コスト: $24.0
• アイドル時間: 480時間（(24 - 8)時間 × 30日間, 0 ACU利用）
  • コスト: $0
• 合計: $24.0/月

新構成（最小ACU 0）はアイドル時にコストを発生させないため、従来構成に比べて月間で $36.0 のコスト削減が可能です。アクティブ時間が少ない運用では、さらに大きなコスト削減が期待できます。

まとめ

検証結果のサマリー

• コールドスタート時の平均クエリ実行時間は約 14.55秒 であり、初回アクセス時の遅延に注意が必要です。
• 連続アクセス時の平均クエリ実行時間は 1.01秒 と決して速くはありませんが、安定したパフォーマンスを確認しました。
• コスト面では、最小ACU 0の構成によりアイドル時のコストを削減でき、従来構成に比べて約 $36.0 の削減が可能でした。

推奨される使用シーン

• バックエンド処理を伴うバッチ処理や非同期ジョブ:
  • リアルタイム性を必要としないデータ集計、レポート生成、夜間バッチ処理など。
• 開発・検証環境:
  • コールドスタートの影響を運用に持ち込む必要がない環境。
  • 短期間の利用や、負荷テストの検証などコストを抑えたい用途。

API接続先としての注意点

• 初回アクセスで 15秒前後の遅延 が発生するため、APIの接続先としては適していない場合があります。
• リアルタイム性が求められるサービス（例: ユーザー向けのREST APIやWebアプリケーションのバックエンド）では、最小ACUを 0.5以上 に設定するか、通常のAurora構成を検討してください。

導入検討時の判断ポイント

• コールドスタート時の遅延を許容できるかを運用シナリオに応じて評価。
• 定期的なアクセスがある場合は、スケールダウンを抑制する設定を検討。

参考情報

• Amazon Aurora Serverless v2: 最小ACU 0のスケーリングをサポート