データ・サーバー移行と接続のシナリオ判断

移行対象、必要な変換、変わり続けるデータ、利用できる接続という条件から手段を選びます。転送時間の計算と業務の切替を別に考え、旧資料の機器名を現行の提供保証としない判断を練習します。

この単元で学ぶこと

移行対象に合うサービスと検証を判断する
帯域・データ量・更新差分の数値を評価する
現行の転送方式と接続・暗号化を比較する

本文解説

1. 売上DBを別エンジンへ業務DBを対応する別エンジンへ移す例では、DMSのデータ移行と構造変換の評価を分けます。表やビューの変換結果を調べ、SQLの意味、金額、日付、文字を確認します。最初のコピー中にも取引が増えるなら、CDC等の変更追従と最終切替を計画します。

2. 古い業務サーバーを移す OSとアプリを大きく変更せずAWSへ移したい例はMGNで比較します。起動設定とサポート条件を確認し、テストインスタンスから認証やDBへ接続できるかを試します。テストが成功した後も、切替までに元で更新されたデータを扱います。テスト起動済みの環境が常に最新へ更新されるとは考えません。

3. ファイルをまとめて運ぶ NFS共有からS3へ静的ファイルを移すならDataSync等でオンライン転送を比較します。ネットワークが細いなら回線の改善やData Transfer Terminal等も選択肢になります。新規企業へSnow Family機器を当然に注文できる案を出さず、現行の制限と利用条件を確認します。

4. 時間を単位付きで計算十進単位で900GBを実効50MB/秒で一定転送すると、900000MB÷50=18000秒、5時間です。これは準備や検証を除いた転送部分の仮定です。追加で検証1時間、切替30分を順に行えば合計6時間30分になります。公称帯域を常に実効速度とみなさず、実際の条件を計測します。

5. 変化し続けるデータ初期差分0で毎分200件の更新が発生し、毎分150件を反映する状態が6分続けば、未反映は300件増えます。帯域や移行先の処理能力、ログの条件を調べます。遅れを残したまま切り替えると必要な更新が欠ける可能性があるため、書込み制御と最終反映を確認します。

6. 専用経路と暗号化インターネット経由Site-to-Site VPNはIPsecで通信を保護します。Direct Connectは専用経路として比較しますが、既定で暗号化を保証するものではありません。必要な保護範囲に合わせてVPNや対応する暗号化を検討します。暗号化した後も、DBの利用権限やS3のアクセス許可は別に確認します。

7. 接続先を切り替える元と先のデータを確認した後、利用者やアプリの接続先を計画どおり変更します。切替後の更新がどちらに入るか、失敗した場合にどう戻すかを決めます。元のデータを残していても、移行先で新たな注文が入った後に無調整で戻すと、注文を欠落させる場合があります。

8. 合格の証拠を残す DMSのデータ検証やMGNのテスト起動、ファイル転送後のチェックは、それぞれ確認できる範囲が異なります。実施した条件と未確認を記録し、必要な業務を試します。移行後のバックアップ、監視、アクセス管理や使わなくなった資源の処理も計画に含めます。移行ツールの成功を、調べていない業務まで保証するものにはしません。

図解

数字と業務の両方で判断する — 数字は十進単位、速度一定、工程は順次という仮定の例です。実際の性能保証ではありません。

重要ポイント

対象と移行先の変更量から選ぶ。
転送時間と準備・検証・切替の総時間を分ける。
コピー後の更新と戻す手順を確認する。

間違えやすい点

専用回線なら暗号化とDB権限が自動で整うと考える。
元が残っていれば移行先の新更新も考えず戻せると考える。

用語解説

切替後の更新: 利用先を変えた後、新環境で発生した取引やファイルの変更。
総移行時間: 準備、転送、検証、切替等を含む計画上の所要時間。
未反映差分: 元に存在するが移行先へまだ反映されていない変更。

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。