なぜ移行時にカスタムドメイン名を維持したいのか

IBM Db2 のワークロードをオンプレミスや EC2 上の自己管理環境から Amazon RDS for Db2 へ移行するとき、多くの現場でつまずくのが接続先の書き換えです。移行前は proddb.company.com:1443 のような社内向けホスト名でアプリケーションが Db2 につないでいたのに、RDS へ移すと接続先は mydb.abc123.us-east-1.rds.amazonaws.com:50000 のようなマネージドエンドポイントに変わります。ホスト名もポートも変わるため、そのままでは既存アプリケーションがつながりません。

問題は、こうした接続文字列が一箇所にまとまっていないことです。数百のアプリケーションやバッチ、設定ファイルに散らばった接続先をすべて洗い出して書き換える作業は、工数がかかるうえにミスを誘発し、本来は素早く終わらせたいリフト＆シフト移行の足かせになります。AWS 公式ブログでは、この課題に対して「アプリケーションの接続文字列を一切変更せずに」既存のカスタムドメイン名のまま RDS for Db2 へ接続を通すソリューションが紹介されています。本記事はその構成を、実装目線でかみ砕いて解説します。

SNI パススループロキシによる解決アーキテクチャ

解決の中心にあるのは、Amazon EC2 上で動く軽量なプロキシです。公式ブログの実装では nginx をベースにした OpenResty が使われています。このプロキシは TLS ハンドシェイクの最初のメッセージである ClientHello に含まれる SNI（Server Name Indication）フィールドを読み取り、クライアントが接続しようとしているホスト名を判別します。判別したホスト名を対応表と突き合わせ、暗号化されたストリームをそのまま該当する RDS for Db2 エンドポイントへ転送します。プロキシは通信を復号せず、バイト列をそのまま流すパススルー方式で動くため、クライアントと RDS の間の TLS はエンドツーエンドで維持されます。

クライアントからプロキシまでの経路は DNS とロードバランサーで組み立てます。Amazon Route 53 のプライベートホストゾーンにワイルドカードの DNS レコードを作成し、*.db.mycompany.com のようなカスタムドメインをまとめて Network Load Balancer（NLB）へ向けます。NLB はレイヤー 4 でトラフィックを受け、背後の EC2 プロキシへ渡します。プロキシが SNI を見て宛先の RDS を決めるため、一台のプロキシで複数のカスタムドメインと複数の RDS インスタンスを同時にさばけるのが特長です。

RDS for Db2 側の SSL 設定とクライアント接続

このプロキシは SNI を頼りに振り分けるため、クライアントと RDS の通信が TLS であることが前提になります。RDS for Db2 側では、通信方式を制御する db2comm を SSL もしくは SSL,TCP に設定し、DB パラメータグループの ssl_svcename で SSL 用の待ち受けポートを定義しておきます。これにより、暗号化された接続を受け付ける準備が整います。

クライアント側は、Db2 ドライバーの設定で従来のカスタムドメイン名をそのまま指定し続けます。たとえば DSN 定義では接続先ホストに移行前と同じ proddb.company.com を書き、SSL 通信と証明書、TLS バージョンを指定します。アプリケーションから見れば接続文字列は一文字も変わっていないため、コードや設定に手を入れる必要がありません。

<dsn alias="PRODDB" host="proddb.company.com" name="BLUDB" port="1443">
  <parameter name="SecurityTransportMode" value="SSL"/>
  <parameter name="SSLServerCertificate" value="/home/db2user/certs/us-east-1-bundle.pem"/>
  <parameter name="TLSVersion" value="TLSV12"/>
</dsn>

db2 connect to PRODDB user <username> using <password>

接続要求はカスタムドメイン宛てに飛び、Route 53 が NLB を返し、プロキシが SNI を読んで正しい RDS へ橋渡しします。クライアントは移行が起きたことを意識しません。

Terraform モジュールとドメイン対応表の運用

AWS 公式ブログのソリューションは、一連のインフラを Terraform で構築します。全体は役割ごとに分かれた複数のモジュールで構成され、状態ファイルは Amazon S3 に保存し、Amazon DynamoDB のテーブルで排他ロックを取りながら安全に運用します。おおまかには、バックエンド用の S3 と DynamoDB を用意するモジュール、開発検証向けに自己署名の証明書を発行して AWS Secrets Manager と AWS Certificate Manager（ACM）へ格納するモジュール、EC2 プロキシと NLB と Route 53 を組み上げるモジュール、ドメイン対応表を投入するモジュール、そしてデプロイ後の疎通を確認するモジュールに分かれています。

運用の肝になるのがドメインと RDS エンドポイントの対応表です。どのカスタムドメインをどの RDS へ向けるかを、次のようなマッピングとして宣言します。

rds_mappings = {
  "proddb.company.com:1443" = "mydb-prod.abc123.us-east-1.rds.amazonaws.com:50000"
  "testdb.company.com:1443" = "mydb-test.def456.us-east-1.rds.amazonaws.com:50000"
  "devdb.company.com:50443" = "mydb-dev.ghi789.us-east-1.rds.amazonaws.com:50000"
}

この対応表は AWS Systems Manager のパラメータストアに保管され、EC2 上のプロキシは cron ジョブでパラメータストアを定期的に読み取ります。公式ブログによると、新しいエントリはおおむね 5 分以内にプロキシへ反映され、必要なら即時反映のための手動更新も実行できます。マッピングを書き換えて適用するだけで振り分け先を変えられるため、移行の進み具合に合わせて柔軟に経路を差し替えられます。

段階的な移行とプロキシの廃止

この構成の利点は、一斉切り替えのリスクを避けて段階的に移行できる点にあります。まずはすべてのアプリケーションを、従来のカスタムドメイン名のままプロキシ経由で RDS for Db2 につなぎます。この時点で移行そのものは完了していますが、アプリケーション側の接続文字列は旧来のホスト名のままです。

その後、アプリケーションを少しずつ改修し、接続先を RDS のネイティブなエンドポイントへ直接向けるように更新していきます。あるアプリケーションの切り替えが済んだら、そのエントリを対応表から外して Terraform を適用します。こうしてプロキシを経由するトラフィックを徐々に減らし、すべてのアプリケーションがネイティブエンドポイントへ移り終えたら、用意されているクリーンアップ手順でプロキシや関連リソースをまとめて撤去します。プロキシはあくまで移行期間中の橋渡し役であり、恒久的に抱え込む必要はありません。

本番運用で押さえる注意点とコスト感

本番で使う前に、いくつか押さえておきたい前提があります。まず、SNI ベースで振り分ける仕組みのため、SSL 接続時に SNI を送信しないレガシーな Db2 クライアントはこの方式で自動的に振り分けられません。そうしたクライアント向けには、単一の RDS エンドポイントへ固定的にマッピングした専用ポートを用意して対応します。次に証明書です。開発やテストでは自己署名のワイルドカード証明書で手早く検証できますが、本番環境では企業の認証局が発行した正式な証明書へ置き換えることが前提になります。秘密鍵は Secrets Manager、証明書は ACM に保管して管理します。

可用性の観点では、EC2 プロキシが単一障害点にならないよう、本番では複数のアベイラビリティーゾーンにまたがって複数台を Auto Scaling グループで動かす構成が推奨されています。DNS の到達範囲はプライベートホストゾーンに関連付けた VPC に限られるため、プロキシの VPC やピアリング先、Route 53 Resolver のルール経由で名前解決できるように設計します。コスト面については、AWS 公式ブログが記事執筆時点の us-east-1 を前提とした概算を示しており、単一インスタンスの参考デプロイでおおむね月額 50〜100 ドル、複数 AZ でオートスケーリングする本番構成でおおむね月額 140〜200 ドル程度（データ転送料を除く）とされています。実際の費用は構成やトラフィックで変わるため、最新の料金は必ず公式の料金ページで確認してください。接続文字列を守りながら移行を加速する選択肢として、まずは検証環境で試してみてはいかがでしょうか。