2022/9からオンプレミス環境にあるお客様のDWHサーバーをAWS（Aurora）に移行するプロジェクトを始め、2023/2すべての対応は終わりました。移行作業中にいろいろ課題が出てきましたが、２つ挙げてメモとして残しておきます。
◆移行背景
オンプレミス環境にあるDWHサーバーは、データ量は増えつつあり、ハードディスクの容量不足は顕在化しております。物理的なハードディスクは柔軟に拡張できないため、容量監視でアラートが出来たら、データを削除したり、圧縮したりしていました。このような対応は都度必要があり、対象データの判断など、多大な工数はかかってしまっていました。
AWS Auroraは性能は優れているほか、ストレージも自動的に拡張できるので、移行先として進めることにしました。Redshiftも検討視野に入れましたが、リレーショナルデータベースが必要、毎日夜間バッチでデータ反映必要、データ量はそこまで大きくなく、迅速的にデータ抽出が必要という理由で、最終的にAuroraへ移行することにしました。
◆移行後の構成図
お客様のクライアントPCに事前にインストールしているMicroStrategyという分析ツールで、Auroraから必要なデータを抽出し分析を行っていただきます。
◆移行中の課題および解決方法
【課題】
Auroraのエンドポイントは将来復旧等変わっても、アプリケーション側に影響を及ぼさないため、Route53へCNAMEレコードを作成し、登録しました。
しかし、オンプレミス環境にあるお客様のクライアントPCは、インターネット接続ができないクラウド専用線でセキュアな通信をしており、DNS名前解決ができず、ODBCを設定しても繋がらないとの課題がありました。
【解決方法】
① Route 53 Resolver(インバウンドエンドポイント)作成
Route 53 Resolver(インバウンドエンドポイント)は、AWS VPCの外部(ダイレクトコネクトやVPNで接続されているオンプレミスなど)から、VPC内のRoute 53 Resolverを使用して、VPC内の名前解決を可能にするためのエンドポイント。
② NTT.com Enterprise Cloud側のServer、On-Premise環境にあるClientPCに、DNSサーバーIPアドレスに、エンドポイントのIPアドレス設定
【課題】
SQLServerが入っているNTT.com Enterprise Cloud側のServerから、毎晩データを抽出してリンクサーバーを使い、AWS Auroraへデータを更新したり、インサートしたりするバッチ処理は動いています。
当該バッチ処理はかなり時間かかり、予定時間内で終了できず、後方処理への影響がある課題がありました。
【原因調査】
・AWS Aurora のCloudWatchメトリクス調査
・NTT.com Enterprise Cloud、オンプレミスからAWSへ通信できるよう設定している、Flexible InterConnect側調査
・ECL側のServer → Auroraと同じPrivate SubnetにあるEC2は、PINGコマンドで確認したところ、8ms程度のレイテンシ
【解決方法】
上記調査結果により、8ms程度のレイテンシが発生する環境で、数十万件のデータを UPDATE/INSERT で追加している状況にあり、やはりネットワークのレイテンシがボトルネックであるように見受けられました。
例として 30 万件のデータを INSERT する場合を考えます。この環境でネットワークのレイテンシが全体の処理に与える時間を単純に計算すると、以下のようになります。
8 (レイテンシ[ms]) * 2(往復) * 300000 (件数) / 1000 / 60 = 80 (分)
クエリの処理時間を無視しても 80 分程度の時間を要することがわかります。ネットワークのレイテンシが処理時間の支配的な要素となっていたことが疑われます。
CloudWatchメトリクスを確認したところ、CPU や Memory は十分な余裕がありました。また、ネットワークのスループットも DB インスタンスクラスの上限には達していませんでした。ただし、ネットワークのスループとは何らかの制限に抵触した際に見られる、台形のグラフが確認できました。これはネットワークのレイテンシに律速されたことによって現れたグラフと考えております。
Amazon Aurora MySQLとS3間でデータをロード&アンロードするをする機能がありますので、SQLServerリンクサーバーを使う設計を変えて、一度テキストのデータをS3にPUTし、S3からAuroraへロードする案で対応を進めました。
①Aurora が S3 にアクセスするための IAM ロールを作成
②DB クラスターパラメーターグループのパラメーターに IAM ロールの ARN を指定
③IAM ロールをアタッチ
④Aurora クラスター再起動
設定後、mysql クライアントから実行して問題なくデータはアップロードできるようになりました。
問題ないことを確認してから、NTT.com Enterprise Cloud側のServerで、S3へテキストデータを出力し、Auroraへロードする処理を追加するようプログラムのロジックを変更し、解決に至りました。