Azure Fundamentals · レッスン

データベース移行のベストプラクティス

Q: 「データベース移行のベスト プラクティス」レッスンは無料ですか？

はい。「データベース移行のベスト プラクティス」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Azure Fundamentalsコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Azure Fundamentalsコースには全4レッスンが含まれています。

Azure Database Migration Service を使用して SQL Server データベースを最小限のダウンタイムで Azure SQL に移行し、一般的なスキーマと互換性の問題を解決します。

「データベース移行のベストプラクティス」はCoddyKit上の無料Azure Fundamentalsレッスンです。これはレッスン4/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはAzure Fundamentals学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Azure Fundamentalsコースには全4レッスンが含まれています。

データベース移行が異なる理由

データベースはステートフルであり、多くの場合24 時間 365 日アクティブな接続があるため、データベースの移行は VM をそのまま移行するよりも複雑です。単純なコピーと復元の方法では数時間のダウンタイムが必要になり、本番システムでは許容されません。ベストプラクティスに基づくデータベース移行では、継続的なデータレプリケーションを使用して、ターゲットの検証中もソースとターゲットを同期させ、新しい Azure データベースにトラフィックをリダイレクトする際に、短時間で計画的なカットオーバーを実行します。

Azure Database Migration Service

Azure Database Migration Service (DMS) は、一般的なオンプレミスのデータベースエンジンから Azure のマネージドデータベースサービスへのオンライン移行（ほぼゼロダウンタイム）およびオフライン移行（ダウンタイムあり）を調整するフルマネージドサービスです。DMS は、SQL Server、MySQL、PostgreSQL、MongoDB、Oracleなどのソースと、Azure SQL Database、Azure SQL Managed Instance、Azure Database for MySQL、Azure Cosmos DB などのターゲットをサポートしています。このサービスは、移行前の互換性チェックのためにData Migration Assistant (DMA)と統合されています。

# Create a DMS instance
az dms create \
  --service-name myDMS \
  --resource-group myRG \
  --location eastus \
  --sku-name Premium_4vCores \
  --vnet myVnet \
  --subnet mySubnet

DMA を使用した移行前評価

SQL Server を移行する前に、ソースデータベースに対してData Migration Assistant (DMA)を実行します。DMA は、互換性の問題（データベースで使用されているが、対象の Azure SQL ではサポートされていない機能）、破壊的変更、非推奨機能、パフォーマンスに関する推奨事項を特定します。詳細な HTML レポートが生成され、問題が重大度順に優先付けされるため、移行時間帯が始まる前にチームで修正できます。

# Run DMA assessment from CLI (Windows only)
# DmaCmd.exe /AssessmentName='SQL2022toAzureSQL' \
#   /AssessmentSourcePlatform='SqlOnPrem' \
#   /AssessmentTargetPlatform='AzureSqlDatabase' \
#   /AssessmentDatabases='Server=myServer;Initial Catalog=AdventureWorks;Integrated Security=true'

オンライン移行とオフライン移行

オフライン移行では、移行の間、ソースデータベースをオフラインにします。これは、小規模なデータベースや、メンテナンス時間帯を確保できる重要度の低いシステムでは許容されます。オンライン移行では、変更データキャプチャ（CDC）またはトランザクションログ配布を使用して、新しいデータベースの読み込み中も変更を継続的にレプリケートし、ダウンタイムを最終カットオーバーステップだけに最小化します。オンライン移行は、1 GB を超えるデータベース、またはダウンタイムが 1 時間未満であることを求める SLA を持つデータベースに推奨されます。

DMS 移行プロジェクトの構成

DMS 移行プロジェクトでは、ソース接続（サーバー名、認証、データベース名）、ターゲット接続（Azure SQL 接続文字列）、および移行モード（オンラインまたはオフライン）を指定します。移行するデータベースとテーブルも選択します。DMS は開始前に接続性を検証します。移行プロジェクトは Azure ポータルに保持されるため、進行状況の監視、失敗したテーブルの再試行、詳細なアクティビティログの確認ができます。

# Create a DMS project for SQL Server to Azure SQL Database
az dms project create \
  --service-name myDMS \
  --resource-group myRG \
  --name SQL2AzureSQL \
  --source-platform SQL \
  --target-platform SQLDB \
  --location eastus

最初にスキーマを移行する

必ずデータより先にスキーマを移行してください。DMA またはSQL Server Management Studio (SSMS)を使用して、テーブル、ビュー、ストアドプロシージャ、関数、インデックスをスクリプト化し、対象の Azure SQL Database にデプロイします。DMS によるデータ転送を開始する前に、すべてのスキーマオブジェクトが存在し、エラーなくコンパイルされることを確認してください。移行途中で検出されたスキーマエラーは、移行実行を破損させ、最初からやり直す原因となる可能性があります。

# Generate schema scripts using sqlpackage
sqlpackage /Action:Script \
  /SourceServerName:myOnPremServer \
  /SourceDatabaseName:AdventureWorks \
  /TargetServerName:mysqlserver.database.windows.net \
  /TargetDatabaseName:AdventureWorksAzure \
  /OutputPath:/tmp/schema.sql

初期データロード

DMSは、ソースデータベースをテーブル単位で読み取り、バルクインサートを使用してAzure SQLのターゲットに行を書き込むことで、フルデータロードを実行します。フルロード中、サービスは大規模なテーブルをバッチに分割して処理します。スループットを最大化するため、ロード中はターゲット上のインデックスを無効にし、完了後に再構築します。非常に大規模なデータベース（TB規模）の場合は、Azure Data Factoryまたはbacpac exportsを使用してデータを事前にロードし、DMSの実行時間を短縮することを検討してください。

オンライン同期のための変更データキャプチャ

オンライン移行では、DMSはソースでSQL Server Change Data Capture (CDC)を有効にし、フルロードの進行中に発生するINSERT、UPDATE、DELETE操作をキャプチャします。フルロードが完了すると、DMSはキャプチャした変更をターゲットに再適用し、差分を徐々に縮めます。レイテンシがほぼゼロに低下したら、データベースをカットオーバーできる状態です。CDCを使用するには、SQL Server Agentが実行中で、ソースデータベースがfull recoveryモードになっている必要があります。

-- Enable CDC on source database
EXEC sys.sp_cdc_enable_db;

-- Enable CDC on specific table
EXEC sys.sp_cdc_enable_table
  @source_schema = N'dbo',
  @source_name = N'Orders',
  @role_name = NULL;

カットオーバーと検証

CDCの遅延が最小になったら、DMSポータルでカットオーバーを開始します。DMSは新しいCDCイベントの受け付けを停止し、残りの変更を適用して、移行を完了としてマークします。この時点で、アプリケーションの接続文字列をAzure SQLエンドポイントにリダイレクトします。重要なテーブルについて、ソースとターゲットの行数およびチェックサム集計を比較するデータ検証クエリを実行してください。ロールバックが必要になった場合に備え、カットオーバー後24～48時間はソースデータベースを読み取り専用モードにしておきます。

-- Validate row counts post-cutover
SELECT TABLE_NAME, TABLE_ROWS
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'dbo'
ORDER BY TABLE_NAME;

移行後のパフォーマンスチューニング

移行後のAzure SQL Databaseは、クエリプランキャッシュ、統計情報、ハードウェアが異なるため、オンプレミスのSQL Serverとは異なる動作をする場合があります。Database Experimentation Assistant (DEA)を実行して、Azure上のターゲットでワークロードのトレースを再生し、実行プランを比較します。Azure SQLでAutomatic Tuningを有効にすると、サービスがインデックスの作成や削除を自動的に行い、性能が低下しないクエリプランを強制できるため、手動で介入しなくても時間の経過とともにパフォーマンスを向上させられます。

-- Enable Automatic Tuning on Azure SQL Database
ALTER DATABASE CURRENT SET AUTOMATIC_TUNING (
  FORCE_LAST_GOOD_PLAN = ON,
  CREATE_INDEX = ON,
  DROP_INDEX = OFF
);

その他のデータベースエンジンの移行

DMSはオープンソースエンジンの移行にも対応しています。MySQLからAzure Database for MySQLへは、mysqldump + binlog replicationパターンを使用し、PostgreSQLからAzure Database for PostgreSQLへは、論理レプリケーションスロットを使用します。MongoDBからCosmos DBへの移行では、Cosmos DB for MongoDB APIとネイティブのmongodump / mongorestoreパイプライン、または増分CDC用のAzure Data FactoryのMongoDBコネクタを使用してください。ライブデータに対して実行する前に、必ず非本番環境のコピーで移行をテストしてください。

# Offline MySQL migration using mysqldump
mysqldump -h source-server -u admin -p \
  --single-transaction --routines --triggers \
  myDatabase > /tmp/myDatabase.sql

# Restore to Azure Database for MySQL
mysql -h myserver.mysql.database.azure.com \
  -u adminUser@myserver -p myDatabase < /tmp/myDatabase.sql

クイックチェック

このレッスンで扱ったMicrosoft Azure Fundamentals (AZ-900)の概念について、理解度を確認します。

レッスンのまとめ

このレッスンでは、Azure Database Migration Serviceがオンラインおよびオフラインのデータベース移行をオーケストレーションすること、DMAを使用した移行前評価によって移行時間帯の前に互換性の問題を検出できること、そして変更データキャプチャによって本番データベースをほぼダウンタイムなしでカットオーバーできることを学びました。次はAzureのコスト最適化に焦点を移します。

よくある質問