📌 はじめに
オンプレミスの単一データベースにおいて、「高頻度のリアルタイム書き込み」と「重い集計バッチ処理」が同居している環境では、リソース競合やテーブル/行ロックによる書き込みタイムアウトが深刻な課題となります。
今回は、クライアント（センサー機器側）の設定変更を一切行わず（ゼロダウンタイム＆クライアント無感知）、AWS DMS を用いた継続的レプリケーションで移行しつつ、Amazon Aurora MySQL の物理的な読取分離と RDS Proxy + Lambda による接続プール保護を組み合わせた標準移行パターンをまとめます。
1. 業務シナリオとコア課題の整理
業務背景
-
現行システム: 2つの Node.js アプリケーションが稼働。
- センサー端末からの高頻度ストリーミングデータを MySQL へロードする収集アプリ。
- 長時間実行される集計レポートバッチ処理アプリ。
コア課題
- リソース枯渇とロック競合: 集計バッチが実行されると、単一 MySQL の CPU/IOPS が飽和し、あるいはテーブル/行ロックを長時間保持するため、リアルタイムの書き込みがタイムアウトしデータ欠損が発生する。
-
移行の絶対制約:
- パフォーマンスと安定性: 集計処理による書き込み失敗を恒久的に排除すること。
- クライアント無変更・無停止（Zero Downtime）: 数千台の外部センサー機器の接続先変更やファームウェア更新を伴わず、サービス停止時間（メンテナンスウィンドウ）をゼロにしてクラウドへ切り替えること。
2. アーキテクチャトポロジー
[ センサー機器 / 外部クライアント ]
│
│ (1. DNS切替: エンドポイントをALBへ向ける)
▼
┌───────────────────────────┐
│ Application Load Balancer │
│ (ALB) │
└─────────────┬─────────────┘
│ (2. HTTP Target Group 経由でキック)
▼
┌───────────────────────────┐
│ AWS Lambda 関数 │ (データ収集層: サーバーレスイベント駆動)
└─────────────┬─────────────┘
│
▼
┌───────────────────────────┐
│ Amazon RDS Proxy │ (接続プール層: 接続急増を吸収)
└─────────────┬─────────────┘
│ (3. Writer専用書き込み)
┌─────────────────────────┐ ▼
│ オンプレミスデータセンター │ ┌──────────────────────────────────────────────┐
│ │ │ Amazon Aurora MySQL クラスター │
│ ┌─────────────────────┐ │ │ │
│ │ オンプレミス MySQL │ │ │ ┌──────────────────────────────────────┐ │
│ └──────────┬──────────┘ │ │ │ プライマリインスタンス (Writer) │ │
│ │ │ │ └──────────────────┬───────────────────┘ │
│ │ CDC継続同期 │ │ │ ミリ秒未満の共有分散ストレージ
│ ▼ │ │ ▼ │
│ ┌─────────────────────┐ │ │ ┌──────────────────────────────────────┐ │
│ │ AWS DMS レプリカ ├──┼───►│ │ リードレプリカ (Aurora Read Replica) │ │
│ └─────────────────────┘ │ │ └──────────────────▲───────────────────┘ │
│ │ │ │ 読取専用クエリを完全隔離 │
└─────────────────────────┘ └──────────────────────┼───────────────────────┘
│
┌──────────────┴──────────────┐
│ 集計バッチ処理プログラム │
│ (Node.js) │
└─────────────────────────────┘
3. なぜこの設計を選択するのか？（3大コアソリューション）
① ロック競合の物理的根絶：Aurora による読取/書込の完全分離
- 専用リードレプリカの配置: 長時間実行される集計バッチは、Aurora クラスターの リードエンドポイント（Reader Endpoint） を通じてリードレプリカへ直接接続させます。
- 物理的なコンピューティング分離: Aurora のアーキテクチャでは、Writer と Reader が底层の分散ストレージを共有（ミリ秒未満のレプリケーション遅延）しながら、CPU とメモリリソースは完全に独立しています。重い集計処理が実行されても Writer インスタンスの計算リソースやバッファプールは一切圧迫されず、行ロック・表ロックの競合が物理的に根絶されます。
② ゼロ停止・クライアント無感知の移行：AWS DMS (CDC) ＋ DNS 割接
-
AWS Database Migration Service (AWS DMS):
-
初回の全量データロード（Full Load）を実行した後、CDC（Change Data Capture / 継続的増量レプリケーション） を稼働させます。
-
移行作業中もオンプレミスの業務を停止させる必要はなく、DMS が裏側で継続的に差分ログ（バイナリログ）を追従し、両環境のデータをリアルタイムに同期（追いつき状態）させます。
-
DNS レコードのスムーズな切り替え:
-
データ同期が追いついたタイミングで、センサー機器がアクセスしている既存のドメイン（FQDN）の DNS 解決先を、オンプレミス環境から AWS 上の ALB へ切り替えます。
-
クライアント側では IP アドレスのハードコードやアプリ改修を必要とせず、メンテナンスウィンドウ（計画停止）なしでシームレスな移行が完了します。切替確認後に DMS タスクを停止します。
③ 高頻度バースト書き込み対策：ALB × Lambda × RDS Proxy
-
サーバーレス受信層（ALB + Lambda）:
-
センサー機器からの HTTP トラフィックを ALB で直接受け、バックエンドの Lambda 関数を起動します。リソースのプロビジョニングやパッチ管理が不要になり、トラフィックの急増にも自動スケールで対応可能です。
-
コネクションストームの緩和（Amazon RDS Proxy）:
-
Lambda が急激に同時実行されると、大量のデータベース接続が同時に生成され、MySQL の最大接続数（
max_connections）を超過する「コネクションスパイク」が発生します。 -
RDS Proxy を Lambda と Aurora の間に介在させることで、接続をプール化して多重化します。Aurora への物理接続数を最小限に保ち、データベースが過負荷でダウンすることを防ぎます。
4. Terraform によるインフラ構成コード例 (RDS Proxy & Aurora)
# 1. RDS Proxy の作成
resource "aws_db_proxy" "aurora_proxy" {
name = "aurora-mysql-proxy"
debug_logging = false
engine_family = "MYSQL"
idle_client_timeout = 1800
require_tls = true
role_arn = aws_iam_role.proxy_role.arn
vpc_subnet_ids = [aws_subnet.private_a.id, aws_subnet.private_b.id]
vpc_security_group_ids = [aws_security_group.proxy_sg.id]
auth {
auth_scheme = "SECRETS"
iam_auth = "DISABLED"
secret_arn = aws_secretsmanager_secret.db_secret.arn
}
}
# 2. RDS Proxy と Aurora クラスターのターゲットバインド
resource "aws_db_proxy_default_target_group" "aurora_tg" {
db_proxy_name = aws_db_proxy.aurora_proxy.name
connection_pool_config {
max_connections_percent = 90
max_idle_connections_percent = 50
}
}
resource "aws_db_proxy_target" "aurora_target" {
db_proxy_name = aws_db_proxy.aurora_proxy.name
target_group_name = aws_db_proxy_default_target_group.aurora_tg.name
db_cluster_identifier = aws_rds_cluster.aurora_cluster.id
}
5. まとめ
- ロックと負荷の完全遮断: センサー書き込みをプライマリインスタンス（Writer）へ、集計バッチをリードレプリカ（Reader）へ分離することで、データベースの可用性を最大化。
- 無停止移行: AWS DMS の CDC 機能と DNS 切り替えを組み合わせることで、センサー端末に手を加えず、サービス停止を発生させずにクラウドへカットオーバー。
- 接続負荷の吸収: 大規模な同時書き込みアクセスに対しては、ALB + Lambda + RDS Proxy の組み合わせにより、データベース接続のパンクを未然に防止。