SQL ServerをAWSへ移行する方法と、移行前に必ず確認すること
オンプレミスのSQL ServerをAWSへ移す方法は一つではありません。RDS for SQL Server、EC2上のSQL Serverのどちらを選ぶかで、移行できるものと移行できないものが変わります。
このページは、社内で稼働しているSQL ServerをAWSへ移したいが、何から確認すればいいか分からない方に向けたものです。GIIPはオンプレミスSQL Serverを、x12largeクラス・5レプリカ構成のAWS RDS for SQL Serverへ移行し、同等構成を12セット展開した経験があります。
RDSとEC2のどちらを選ぶべきか分からない
「マネージドの方がいい」とは聞くものの、現行の運用がRDSで成立するのかを判断できる材料がありません。
移行後に動かなくなるものが怖い
SQL Server Agentのジョブ、リンクサーバー、ファイル連携など、データベースの外側の仕組みが多数あります。
止められる時間が限られている
業務の都合で許容できる停止時間が短く、その中で移行しきれるのかが分かりません。
RDSにはOSレイヤーがない
マネージドサービスではサーバーにログインできません。OSのスケジューラ、常駐エージェント、ローカルファイルを前提にした処理は成立しません。
ログインとユーザーは別物
データベースをコピーしてもインスタンスレベルのログインは付いてきません。SIDが一致せず孤立ユーザーになる典型的な問題が起きます。
確認漏れは環境ごとに掛け算される
複数セットを移行する場合、1件の確認漏れがセットの数だけ再現します。手順を再現可能にしておかないと事故が増えます。
移行の可否を判断するために必要な材料を先に揃え、切り替えと切り戻しの手順まで用意します。
現行構成と依存関係の棚卸し
バージョン、インスタンス構成、レプリカ構成、ジョブ、リンクサーバー、外部連携を列挙し、RDSで成立するもの・置き換えが必要なものに切り分けます。
移行方式と停止時間の設計
許容できる停止時間を業務条件として確定し、それに収まる方式を選びます。無停止を前提にできるかは確認してからお答えします。
移行後の監視・運用の継続
移行して引き渡す形ではなく、移行後のAWS環境の監視・性能分析・障害対応まで同じチームが継続します。
ご自身で先に確認できること
- SQL Serverのバージョンとエディション（Standard / Enterprise）
- インスタンス数と、レプリカを含む構成
- データ容量と、1日あたりの更新量のおおよその規模
- SQL Server Agentで動いているジョブの一覧
- リンクサーバーや他システムとの連携の有無
- ファイル出力・取り込みなど、OSに依存する処理の有無
- 業務上、何時間まで停止できるか
実績で示せること
守秘義務およびセキュリティ上の理由から、顧客名とシステム固有情報は公開していません。移行に要した時間・停止時間・性能変化は測定値として確認されていないため記載していません。
よくあるご質問
RDS for SQL ServerとEC2上のSQL Serverはどちらがいいですか。
現行の運用がOSレイヤーにどれだけ依存しているかで決まります。ジョブやファイル連携をすべて置き換えられるならRDSが運用面で有利ですが、置き換えが難しい処理が残る場合はEC2が現実的な選択になることもあります。
移行にどのくらいの停止時間が必要ですか。
データ量、更新頻度、選ぶ移行方式によって変わります。実測に基づかない一般値をお伝えすることはしていません。現行構成をご提示いただければ前提を明示して見積もります。
ライセンスはどうなりますか。
RDSではライセンス込みの提供形態があり、EC2では持ち込みの可否がエディションと契約条件によって変わります。現在のライセンス条件を確認したうえでご説明します。
移行後の運用も任せられますか。
可能です。GIIPは現在も複数のAWS RDS for SQL Serverを含むクラウドデータベースを、AIエージェントと人間の専門家で継続的に監視・運用しています。
自社のSQL ServerがAWSへ移行できるか確認する
バージョン、構成、停止許容範囲をお知らせください。パスワードや接続文字列はお預かりしません。