オンプレからRDS移行の勘所――第2回 移行時のBulkInsert対応「課題と解決策」

はじめに

前回の記事（第1回）では、オンプレミスSQL ServerからAWS RDS for SQL Serverへの移行で考慮したポイントについてまとめました。
第2回となる今回は、BulkInsert処理のAWS RDS対応において実際に遭遇した課題と、その解決策についてご紹介します。

BulkInsertをAWS RDSで利用する際のポイント

システム概要と要件

• 現行環境：オンプレミスSQL Server
• 移行先　：AWS RDS for SQL Server
• 要件　　：ストアドプロシージャからファイルへのBulkInsertを引き続き実施したい

オンプレ環境では、ストアドプロシージャ内でファイルから直接BulkInsertを行う運用をしていました。移行後も、同様の運用を目指しました。

AWS RDSにおけるBulkInsertの制限と対応策

RDS版SQL Serverでは、ローカルディスク上のファイルを直接BulkInsertすることはできません。
そのため、以下の手順でデータ投入を試みました。

• ファイルをAmazon S3へアップロード
• S3統合タスク（例：rds_download_from_s3）でS3からRDSの一時領域にダウンロード
• ストアドプロシージャでBulkInsertを実行
• 使用済みファイルを削除（rds_delete_file_on_disk）

想定外だった性能問題 ―「5分以上かかる」BulkInsert

実運用環境で上記構成を検証したところ、全体で5分半以上も処理時間がかかってしまいました！

• S3→RDSダウンロード（rds_download_from_s3）：約2分半
• BulkInsert実行時間　　　　　　　　　　　　　　　：約1秒（高速！）
• S3ファイル削除 （rds_delete_file_on_disk）　　　：約3分

AWS公式ドキュメントには「S3統合タスクの起動に最大5分かかる場合がある」と明記されており、まさにその事象に直面しました。

方針転換 ― SqlBulkCopyへの切り替え

上記の結果を受けて、BulkInsertの利用を取り止めることに決定。
代わりに、アプリケーション側（VB.NETなど）からSqlBulkCopyを使って直接RDSへデータ投入する方式に変更しました。

その理由
• S3統合タスクは大容量バッチ処理や一時的な移行には最適だが、小規模ファイルや高頻度連携には不向き
• RDSの仕様やS3タスクの遅延が頻繁なデータ投入のボトルネックになった
• SqlBulkCopyを使うことでS3や統合タスクを経由せず、処理時間を大幅に短縮できた

まとめ：クラウド移行で重要なのは「柔軟な対応力」

AWS RDSや周辺サービス（S3統合タスク）には、オンプレ時と異なる制約や特徴があるため、理想的な設計と現実的な運用との間にギャップが生じるケースも多いです。

本事例のように、
• 「同じ機能が使える＝運用上も最適」とは限らないこと
• 実績値や運用テストに基づくプラン検討が重要

これらを意識しておく必要があります。
クラウド移行の設計段階から、「現実的」かつ「柔軟な」運用フローを検討することが、サービス品質の維持・向上への近道です。
記事がクラウド移行に取り組む方の一助となれば幸いです。