📚 AWS SCT・DMS オンラインマイグレーション

図書館の営業を続けながらの移転プロジェクトで理解する無停止データベース移行

📖 図書館の営業を続けながらの移転プロジェクト！

AWS SCT・DMSによるオンラインマイグレーションを、来館者にサービスを提供し続けながら図書館を移転するプロジェクトに例えると分かりやすくなります

📚

旧図書館

既存データベース
（移行元システム）

🏛️

新図書館

移行先データベース
（AWS RDS、Aurora等）

🔄

分類システム変換

AWS SCT
（スキーマ変換ツール）

🚚

引っ越し業者

AWS DMS
（データ移行サービス）

👥

来館者

アプリケーションユーザー
（サービス利用者）

⏱️

本を見つける時間

レイテンシ性能
（応答時間）

📖 営業継続中の図書館移転プロジェクト

📚
旧図書館（営業中）

来館者にサービス提供を続けながら移転作業進行中

文学
歴史
科学
技術
芸術
語学
📖 営業継続：来館者は引き続き本を借りられる
📦 同時移転：新刊は新図書館にも配置
🔄
変換センター

「分類システムを新方式に変換中」

📋 SCT：スキーマ変換
🚚 DMS：データ転送
⚡ リアルタイム同期
🏛️
新図書館（準備中）

新しい分類システムで整理された高機能図書館

Literature
History
Science
Technology
Arts
Languages
🏛️ 高性能：検索・貸出システム向上
🔄 自動同期：旧館の変更を即座に反映
💡 オンラインマイグレーションの価値： 図書館が一日も休館することなく、 来館者は本を借り続けられ、新刊も引き続き入荷される。移転完了後は、より高機能な新図書館でサービス向上！

🔧 移転プロジェクトの専門チーム

🔄
AWS SCT
Schema Conversion Tool - 分類システム変換専門家

📚 図書館例： 旧図書館の「デューイ十進分類法」を新図書館の「最新デジタル分類システム」に変換する専門チーム。 本の内容は変えずに、分類方法だけを新システムに適合させる

🎯 主な変換機能

15+
対応DB エンジン
90%+
自動変換率
0円
ツール利用料
SCT変換例（Oracle → PostgreSQL）
-- Oracle (変換前)
CREATE TABLE books (
id NUMBER ,
title VARCHAR2 (200),
publish_date DATE
);
-- PostgreSQL (変換後)
CREATE TABLE books (
id SERIAL ,
title VARCHAR (200),
publish_date TIMESTAMP
);
✅ SCTのメリット： 手動変換では数ヶ月かかるスキーマ変換を数時間で完了。 互換性のない部分は詳細なレポートで明示され、修正指針も提供されます。
🚚
AWS DMS
Database Migration Service - プロ引っ越し業者

📚 図書館例： 図書館を営業しながら本を一冊ずつ慎重に移転する専門業者。 来館者が本を借りている間も、新刊が入荷している間も、中断することなく移転作業を続行

🚚 移行パフォーマンス

TB/時
転送速度
1-10秒
レイテンシ
99.9%
可用性

📋 対応移行パターン

同種DB移行
MySQL → Aurora MySQL
異種DB移行
Oracle → PostgreSQL
データウェアハウス
Oracle → Redshift
レプリケーション
継続的データ同期
🚚 DMSの特徴： ソースデータベースを停止することなく、リアルタイムでデータ変更を捉えて移行先に反映。 フルロード+CDCにより、ゼロダウンタイム移行を実現します。

📊 図書館移転の3つの方式比較

🎯 移転戦略の選択肢

🏢
オフライン移行

図書館例： 完全休館して一気に移転

📋 特徴

  • サービス完全停止
  • 最短移行時間
  • シンプルな手順
  • データ整合性確保
⚠️ 制約： ダウンタイム数時間〜数日
🔄
オンライン移行

図書館例： 営業を続けながら段階的移転

📋 特徴
  • サービス継続可能
  • リアルタイム同期
  • 段階的切り替え
  • リスク分散
✅ メリット： ダウンタイムほぼゼロ
⚡
ハイブリッド移行

図書館例： 大部分をオンライン、一部をオフライン

📋 特徴
  • 最適化された手法
  • 最小ダウンタイム
  • 複雑なスキーマ対応
  • 柔軟なスケジュール
🎯 適用： 企業の実情に合わせた最適解

⏱️ レイテンシ性能：本を見つけるまでの時間

📊 オンライン移行中のレスポンス時間分析

⚡
読み取りレイテンシ
1-5ms
来館者が本を見つけるまでの時間（SELECT クエリ）
✍️
書き込みレイテンシ
5-20ms
新刊登録や貸出記録の時間（INSERT/UPDATE）
🔄
同期レイテンシ
1-10秒
旧館の変更が新館に反映される時間（CDC）
🎯
切り替えレイテンシ
< 30秒
新館への完全移行時間（フェイルオーバー）

📡 リアルタイム性能モニタリング

2.3ms
平均読み取り時間
12.7ms
平均書き込み時間
4.2秒
同期遅延時間
99.9%
可用性
1,247
秒間処理数
Active
CDC状態

📈 移行方式別パフォーマンス比較

⚖️ 各移行方式の性能評価

ダウンタイム
オンライン: ほぼ0秒
★★★★★
オフライン: 数時間〜数日
★☆☆☆☆
実装複雑度
オンライン: 中程度
★★★☆☆
オフライン: シンプル
★★★★☆
データ整合性
オンライン: 高い
★★★★☆
オフライン: 最高
★★★★★
移行リスク
オンライン: 低い
★★★★☆
オフライン: 中程度
★★★☆☆

🔄 オンライン移行の詳細ワークフロー

📋 図書館営業継続移転の8段階プロセス

1
🔍
事前調査
現在の蔵書・システム分析
SCTでスキーマ評価
2
🏗️
新館準備
AWS環境構築
ネットワーク・セキュリティ設定
3
🔄
スキーマ変換
SCTでスキーマ変換実行
新分類システム適用
4
🚚
初期データ移行
DMSでフルロード実行
全蔵書の一括転送
5
🔄
CDC開始
リアルタイム同期開始
新刊・貸出情報の即時反映
6
🧪
動作検証
新館システムのテスト
パフォーマンス・機能確認
7
🔄
段階的切り替え
読み取り処理を新館に移行
書き込みは旧館のまま維持
8
✅
完全移行
全処理を新館に移行
旧館システム停止
🎯 成功のポイント： 各段階で十分な検証を行い、問題があれば前段階に戻れる仕組みを構築。 来館者（ユーザー）への影響を最小限に抑えながら、確実に移行を進めます。

🏢 業界別オンライン移行事例

🏦
メガバンク

要件： 24/7稼働必須、1秒の停止も許されない

実装： Oracle → Aurora PostgreSQL へのオンライン移行

規模： 50TB、数千テーブル、10億レコード

成果：
• ダウンタイム：0秒
• 移行期間：3ヶ月
• 同期遅延：平均2秒
• 年間コスト：60%削減
🛒
大手ECサイト

要件： ピーク時も継続稼働、在庫整合性維持

実装： MySQL → Aurora MySQL クラスター移行

規模： 20TB、商品1000万点、注文履歴5億件

成果：
• ダウンタイム：0秒
• 移行期間：6週間
• レスポンス：30%向上
• ブラックフライデー対応成功
🎮
オンラインゲーム

要件： リアルタイムランキング、プレイヤー体験維持

実装： SQL Server → Aurora MySQL + ElastiCache

規模： 5TB、プレイヤー2000万人、リアルタイムイベント

成果：
• ダウンタイム：0秒
• 移行期間：8週間
• ゲーム遅延：50%改善
• 同時接続数：2倍対応可能
🏥
医療システム

要件： 患者安全、HIPAA準拠、データ完全性

実装： Oracle → RDS PostgreSQL + 暗号化強化

規模： 15TB、患者記録500万件、医療画像データ

成果：
• ダウンタイム：0秒
• 移行期間：4ヶ月
• セキュリティ：強化達成
• 運用コスト：40%削減

📊 移行方式・性能・コスト総合比較

比較項目 オフライン移行 オンライン移行 ハイブリッド移行
ダウンタイム 数時間〜数日 ほぼ0秒 数分〜数時間
読み取りレイテンシ 移行後: 1-3ms 移行中: 1-5ms 移行中: 2-8ms
書き込みレイテンシ 移行後: 3-10ms 移行中: 5-20ms 移行中: 8-30ms
同期遅延 N/A 1-10秒 1-15秒
実装複雑度 低い 中程度 高い
移行期間 1-7日 2-12週間 3-8週間
ビジネス影響 大（サービス停止） 最小（継続稼働） 小（短時間停止）
推奨用途 開発・テスト環境 ミッションクリティカル 複雑なシステム

🎮 インタラクティブデモ：図書館移転プロジェクト体験

ボタンを押して、AWS SCT・DMSによるオンライン移行がどのように動作するかを体験してみましょう

ボタンをクリックして図書館移転プロジェクトを体験してください

Created by SSuzuki1063

AWS SAP Learning Resources