x12largeクラス・5レプリカ構成のSQL Serverを12セット、AWS RDSへ移行
オンプレミスのSQL Server環境を、AWS RDS for SQL Serverへ移行した事例です。単発の移行ではなく、同等構成を12セット展開した経験に基づいて記載しています。
SQL ServerのAWS移行では、データをコピーできるかどうかよりも、ログイン・ジョブ・リンクサーバー・レプリケーションといった「データベースの外側」をどう引き継ぐかが論点になります。GIIPはオンプレミスSQL Serverを、x12largeクラス・5レプリカ構成のAWS RDS for SQL Serverへ移行し、同等の大規模構成を12セット展開した経験があります。
事例概要
| 移行元環境 | オンプレミス SQL Server |
|---|---|
| 移行先 | AWS RDS for SQL Server |
| インスタンス規模 | x12largeクラス |
| 構成 | 5レプリカ構成 |
| 展開規模 | 12セット |
| 対応範囲 | マイグレーションおよびAWS環境への移行 |
| 公開制限 | 顧客名・業務データ非公開 |
本ページに記載した規模はGIIPの実務経験に基づきます。守秘義務およびセキュリティ上の理由から、顧客名とシステム固有情報は公開していません。
この事例で確認できる事実
- GIIPは、オンプレミスのSQL Server環境をAWS RDS for SQL Serverへ移行した経験があります。
- 移行先インスタンスはx12largeクラスで、1セットあたり5レプリカで構成されています。
- 同等の大規模構成を、合計12セット展開しました。
- 移行後のAWS環境の監視・運用もGIIPが継続して担当できます。
移行前の環境
オンプレミスで稼働していたSQL Server環境が対象でした。単一のデータベースサーバーではなく、レプリカを含む複数インスタンスで構成されたセットが並んでいる状態です。
このような環境では、1台ずつ個別に判断していくと工数も確認漏れも増えます。セット単位で移行手順を確定させ、それを反復できる形にすることが前提になります。
移行の規模
- 移行先はAWS RDS for SQL Server。
- インスタンス規模はx12largeクラス。
- 1セットは5レプリカで構成。
- 同等構成を合計12セット展開。
「5レプリカ」の内訳(リードレプリカ・マルチインスタンス・業務上の複製構成のいずれに該当するか)および具体的なAWSインスタンスファミリー名は、本ページでは推定して記載していません。
大規模環境で論点になること
セット数が増えるほど、1件あたりの確認コストがそのまま全体の工数に掛け算されます。
- 同じ手順を12セットに対して再現できるか。手作業が残るほど、セット間の差異が事故につながります。
- RDSはOSレイヤーに触れられないため、オンプレミス前提の運用(エージェント常駐、ローカルファイル連携など)をそのまま持ち込めるかを事前に切り分ける必要があります。
- レプリカを含む構成では、切り替え時にどのノードを基準にするかを決めておかないと、切り戻し手順が定義できません。
- 移行後に誰が監視するかが決まっていないと、移行完了と同時に運用の空白が生まれます。
移行後の監視と運用
GIIPは移行して終わりにせず、移行後のAWS環境の監視・運用まで同じチームで継続します。現在もAWS RDS for SQL Serverを含む複数のクラウドデータベースを、AIエージェントと人間の専門家が継続的に監視しています。
AIエージェントがメトリクス収集・異常検知・ログと性能情報の分析・定期報告・承認済みランブックに沿った定型作業・エスカレーションを担当し、スキーマ変更や復旧判断のような取り返しの難しい作業は人間の専門家が判断・承認します。
大規模SQL Server移行で確認が必要な代表項目
以下は大規模SQL Server移行時に確認が必要な代表項目です。すべてが本事例で使用されたという意味ではありません。
- 01アカウント・ログイン(SIDの不一致による孤立ユーザー)の引き継ぎ
- 02SQL Server Agentのジョブとスケジュール
- 03リンクサーバーおよび外部接続の依存関係
- 04レプリケーション構成の扱い
- 05バックアップ方式とリストア手順の再定義
- 06統計情報とインデックスの再構築方針
- 07照合順序・互換性レベル(compatibility level)の差異
- 08文字コードとデータ型の差異による影響
- 09アプリケーション側の接続文字列とタイムアウト設定
- 10切り替え手順と切り戻し(ロールバック)手順
このリストは一般的な技術説明です。実際に必要な項目は環境ごとに異なり、本事例で実施した内容の全量を示すものではありません。
よくあるご質問
オンプレミスのSQL Serverは、そのままRDSへ移せますか。
データそのものは移せても、OSレイヤーに依存する運用はRDSではそのまま使えません。ジョブ、リンクサーバー、ファイル連携、常駐エージェントなどを先に棚卸しし、RDSで実現できるもの・別方式に置き換えるもの・EC2など別の形が適するものに切り分けます。
どのくらいの規模まで対応できますか。
GIIPはx12largeクラス・5レプリカ構成のAWS RDS for SQL Server環境を12セット展開した経験があります。それ以上の規模については、現在の構成を確認したうえで可否をお答えします。
移行にかかる期間や停止時間を教えてください。
期間と停止時間はデータ量、レプリカ構成、業務の停止許容範囲によって変わります。実測に基づかない一般値をお伝えすることはしていません。現在のDB構成をご提示いただければ、前提を確認したうえで見積もります。
移行後の運用も任せられますか。
可能です。GIIPは現在も複数のAWS RDS for SQL Server、Aurora MySQL、Azure上のSQL ServerおよびPostgreSQLと約30のWebサービスを、AIエージェントと人間の専門家で継続的に監視・運用しています。
GIIP データベース・クラウド運用チーム
大規模Webサービス、SQL Server、Oracle、AWS、Azureの設計・移行・運用に従事。x12largeクラスのAWS RDS for SQL Server環境12セット、約12万テーブルのOracle環境、約3TBのTiDBからAurora MySQLへの移行を経験。現在も複数のクラウドデータベースと約30のWebサービスをAIエージェントとともに監視・運用している。
- 初回公開日
- 最終更新日
本ページでは、GIIPが実際に経験した内容と、一般的な技術説明・確認項目を明確に分けて記載しています。チェックリストなど一般的な説明として記載した項目は、本事例で必ず実施したという意味ではありません。
守秘義務およびセキュリティ上の理由から、顧客名・システム固有情報・業務データの内容は公開していません。規模を示す数値のみをGIIPの実務経験に基づいて記載しています。
運営会社: GIIP Co., Ltd.(日本オペレーション: SHINSEMA株式会社) / お問い合わせ: contact@littleworld.net
他の移行事例
データベース移行・運用の関連ページ
自社のSQL Server環境が移行できるか確認する
現在のバージョン、インスタンス構成、レプリカ構成、停止許容範囲をお知らせいただければ、移行の論点を整理してご回答します。