Amazon Web Services ブログ
AWS DMS 実装ガイド:テスト、モニタリング、SOP による耐障害性のあるデータベース移行の構築
本投稿は、Sushant Deshmukh と Alex Anto Kizhakeyyepunnil Joyと Sanyam Jain による記事 「AWS DMS implementation guide: Building resilient database migrations through testing, monitoring, and SOPs」を翻訳したものです。
AWS Database Migration Service (AWS DMS) は、データベースの移行とレプリケーションを簡素化し、お客様にマネージドソリューションを提供します。多数のエンタープライズ導入事例から、事前にデータベース移行計画に時間を費やすことで大きな見返りがあることがわかっています。網羅的なセットアップ戦略を採用する組織は、一貫して障害が少なく、より良い移行結果を達成しています。
この投稿では、初期セットアップ段階から AWS DMS の実装を最適化するための事前対策を紹介します。戦略的な計画とアーキテクチャに対する深い洞察力を活用することで、組織はレプリケーションの信頼性を向上させ、パフォーマンスを改善し、一般的な落とし穴を回避することができます。
以下の主要な分野における戦略とベストプラクティスを探ります：
- 概念実証 (PoC) の計画と実施
- 体系的な障害テストの実装
- 標準作業手順書 (SOP) の作成
- モニタリングとアラート
- AWS Well-Architected フレームワークの原則の適用
PoC の計画と実施
PoC を実施することで、環境の問題を早期に発見し、修正することができます。また、全体的な移行時間とリソースの必要性を見積もるために使用できる情報を作成するのにも役立ちます。
PoCを成功させるための大まかな手順は次のとおりです:
- 適切な AWS DMS レプリケーションインスタンス、タスク、エンドポイントを使用してテスト環境を計画し、デプロイします。リソースの計画とプロビジョニングの詳細については、AWS Database Migration Service のベストプラクティスを参照してください。
- 本番環境に近いワークロードを使用します。様々な問題を発見できる可能性を高めるために、本番環境にできるだけ近い環境をシミュレートすることが不可欠です。
- 次のセクションの表で説明されているシナリオに基づいて、障害テストを実行します。
- PoC 中に発生するリソース使用率とボトルネックを追跡し、それに応じてリソースの計画とデプロイメントを見直します。
- 観察結果を文書化し、ビジネス成果と比較して移行評価を実施します。これには、移行活動と継続的なビジネス運用の両方について、移行復旧時間とアプリケーションのサービスレベルアグリーメント（ SLA ）の評価が含まれます。これらの移行および運用要件が満たされない場合は、ビジネスニーズに合わせて計画フェーズを見直してください。
体系的な障害テストの実装
すべてのシステムは、その堅牢性に関係なく、障害やダウンタイムが発生する可能性があります。重要なワークロードを実行する組織にとって、事業継続性を維持し、SLA を満たすためには、積極的な計画が不可欠です。このセクションでは、明確な復旧プロトコルを確立し、システム障害時のオペレーションへの影響を最小限に抑える SOP を開発するための戦略的枠組みを提供します。
AWS DMS を実装する場合、耐障害性のあるシステムを構築するには、潜在的な障害点を理解することが重要になります。次の表は、AWS DMS レプリケーションシステムで発生する一般的な障害シナリオの概要を示しており、テスト戦略の基礎となります。包括的ですが、特定のアーキテクチャ、コンプライアンス要件、ビジネス目標に基づいてこれらのシナリオを拡張して、環境内の潜在的な障害モードを完全にカバーすることをお勧めします。
| 障害ポイント | ダウンタイムの可能性があるシナリオ | テスト | 潜在的な緩和戦略 |
| ソースおよびターゲットデータベース | 高 CPU、メモリ制約などのデータベースサーバーのパフォーマンスボトルネック | sysbench などのベンチマークツールを使用して、データベースサーバーに高負荷をシミュレートします。 | AWS DMS がサポートするエンジンに対して、ソースとしてリードレプリカを使用して読み取り専用データベースノードをプロビジョニングできます。詳細については、データ移行のソースを参照してください。また、データベースリソースをスケールアップし、データベースパラメータを最適化することもできます。 |
| 権限不足によるデータアクセスの問題 | 権限が少ない AWS DMS 用のデータベースユーザーを使用します。 | 最小権限の原則に従ってデータベースユーザーを作成します。それぞれのデータベースエンジンに対する DMS が必要とする権限については、AWS DMS ソースエンドポイントのドキュメントを参照してください。 | |
| データベースのフェイルオーバー（プライマリまたはスタンバイ設定を使用している場合） | プライマリノードからセカンダリノードへのデータベースフェイルオーバーを実行します。 | フェイルオーバー後に AWS DMS が古いプライマリに接続しようとする状況では、動作は Time to Live (TTL) に依存します。TTL が更新された後にタスクを再起動する必要があります。Amazon Aurora ライターエンドポイントに接続しようとすると、接続がリーダーインスタンスにリダイレクトされるのはなぜですか？を参照してください。 | |
| データベースのシャットダウンまたは障害 | 進行中の DMS レプリケーションでデータベースを停止します。 | SOP 作成のために DMS タスクの動作を記録し、データベースの問題を修正した後にタスクを再開します。 | |
| トランザクションログの利用不可 | タスクがオフラインまたは遅延している場合に、保持期間の短いログをパージします。 | SOP 作成のために DMS タスクの観察結果を記録し、トランザクションログを利用可能にした後にタスクを再開するか、ログが利用できない場合は新しいフルロードを実行します。 | |
| スキーマ、テーブル、インデックス、パーティション、データ型などの構造的変更の実行 | 関連するテーブル変更に対して異なるデータ定義言語 (DDL) ステートメントを実行します。 | サポートされている DDL ステートメントのリストとタスク設定を参照してください。 | |
| ネットワーク障害（ソースとターゲットに適用） | ネットワーク、DNS、SSL 障害を含む接続の問題 | AWS DMS セキュリティグループからソース IP を削除するか、iptables を変更します。DMS エンドポイントから証明書を削除します。MTU （最大伝送単位）の値を変更します。 | AWS DMS エンドポイント接続障害のトラブルシューティングとAmazon RDS への接続の問題を参照してください。 |
| パケットロス | Linux システムでトラフィック制御 (tc) コマンドを使用するか、AWS Fault Injection Simulator (FIS) を使用します。 | AWS DMS 診断サポート AMI を使用したデータベース移行中のネットワーク問題のトラブルシューティングとAWS DMS 診断サポート AMI の使用を参照してください。 | |
| AWS DMS の障害 | シングル AZ レプリケーションインスタンスの再起動 | AWS DMS レプリケーションインスタンスを再起動します。 | DMS は、レプリケーションインスタンスの再起動後に自動的にタスクを再開します。 |
| 進行中のレプリケーション中のフェイルオーバーを伴うマルチ AZ レプリケーションインスタンスの再起動 | 「計画的フェイルオーバーで再起動しますか？」オプションを選択して、AWS DMS レプリケーションインスタンスを再起動します。 | DMS は、レプリケーションインスタンスのマルチ AZ フェイルオーバー後に自動的にタスクを再開します。 | |
| EBS のストレージフル | AWS DMS ログによるストレージ不足につながる複数のログコンポーネントの詳細デバッグログを有効にします。 | ストレージ容量が 80 ％ に達したときにアラートを設定し、DMS レプリケーションインスタンスに関連付けられたストレージボリュームをスケールアップします。詳細については、AWS DMS レプリケーション DB インスタンスがストレージ不足の状態になるのはなぜですか？を参照してください。 | |
| メンテナンスウィンドウ中の変更の適用 | ダウンタイムを伴う DMS レプリケーションインスタンスの構成を変更し、「次の予定されたメンテナンスウィンドウ中に適用」オプションを選択します。 | DMS は、メンテナンス実施後に自動的にタスクを再開します。 | |
| レプリケーションインスタンスのリソース競合（高 CPU、メモリ競合、ベースラインより高い IOPS ） | 小規模な DMS レプリケーションインスタンスで MaxFullLoadSubTasks の値を高く設定した複数の DMS タスクを作成します。 | モニタリングとアラートのセクションで説明されているように、重要な CloudWatch メトリクスに対するモニタリングとアラートを設定します。インスタンスクラスをスケールアップするか、タスクを新しいレプリケーションインスタンスに移動できます。 | |
| DMS レプリケーションインスタンスのバージョンアップグレード | DMS レプリケーションインスタンスのバージョンをアップグレードします。DMS は古い DMS バージョンを廃止するため、ユーザーはレプリケーションインスタンスのバージョンをアップグレードする必要があります。詳細については、AWS DMS リリースノートを参照してください。 | この活動に関連するダウンタイムを最小限に抑えるために、徹底的な PoC を実施することをお勧めします。PoC テストの後、最新の DMS バージョンで実行される新しいレプリケーションインスタンスを作成し、変更データキャプチャ (CDC) の遅延が 0 または最小の低ピーク時間帯にすべてのタスクを移動することができます。詳細については、タスクの移動を参照してください。また、ビジネスへの影響を最小限に抑えるためにタスクを移動して AWS DMS でサイドバイサイドアップグレードを実行するも参照できます。 | |
| データの問題 | データの重複 | フルロードのみのタスクを 2 回実行します。1 回目はタスクを途中で停止し、2 回目は「何もしない」構成でターゲットテーブル準備モードでタスクを実行します。 | サポートされているデータベースエンジンに対して DMS 検証を使用します。検証で不一致が報告された場合は、正確なエラーに基づいて調査する必要があります。問題を緩和するために、フルロードタスクを作成するか、特定のテーブルに対してテーブルのリロード（利用可能な場合）を実行し、その後、進行中のレプリケーションタスクを作成してバックフィルを実行できます。 |
| データ損失 | ターゲットにトリガーを作成して、ランダムなレコードを削除または切り捨てます。 | このような種類の問題を避けるために、DMS 検証の使用をお勧めします。テーブルまたはタスクのリロードを実行するか、影響を受けたテーブルの新しいデータロードを実行するために新しいフルロードと変更データキャプチャタスクを作成できます。 | |
| テーブルエラー | DMS タスクが開始される前に、テーブルに対する排他的アクセスロックを取得するか、サポートされていないデータ型を使用します。 | これは、DMS でサポートされていない機能または構成が原因で発生する可能性があります。正確なエラーに基づいて調査が必要です。詳細については、AWS DMS タスクがエラー状態になるのはなぜですか？を参照してください。 | |
| 遅延の問題 | レプリケーションインスタンスでのスワップファイルの蓄積 | 変更の多い長時間実行トランザクションを開始し、CloudWatch メトリクス |
これらのシナリオを体系的にテストし、結果を文書化することで、組織は一般的な障害モードと固有の障害モードの両方に対応する堅牢な復旧手順を開発できます。このプロアクティブなアプローチは、システムの信頼性を維持するだけでなく、問題が発生した際に運用チームが対処するための明確なプロトコルを提供します。
標準作業手順書 (SOP) の作成
障害テストのシナリオでは、各問題がレプリケーションシステムに与える影響を注意深く文書化してください。この文書化は、チームが AWS DMS の実装を管理する際に信頼できる、カスタマイズされた SOPを 作成するための基礎となります。当社の障害テストフレームワークで概説されている緩和戦略は、これらの手順を開発するための優れた出発点として役立ちます。
最初の SOP は、PoC テストの初期段階で明らかになります。これらの手順は、運用経験を積み、新しいシナリオに遭遇するにつれて、定期的な更新と改善が必要な生きたドキュメントとして考える必要があります。データベース移行は動的な性質を持っているため、システムの動作や新たな課題に対する理解とともに、SOP も進化することを意味します。
複雑な移行シナリオの対処に関する追加のガイダンスについては、AWS DMS 移行のデバッグに関する包括的な 3 部構成のブログシリーズをご覧いただくことをお勧めします。これらのリソースは、既存の SOP でカバーされていない状況でも、体系的なトラブルシューティングのアプローチを開発するのに役立つ貴重な洞察を提供します。これらの詳細なガイドは以下で見つけることができます：
- AWS DMS 移行のデバッグ：問題が発生した場合の対処方法 (パート 1)
- AWS DMS 移行のデバッグ：問題が発生した場合の対処方法 (パート 2)
- AWS DMS 移行のデバッグ：問題が発生した場合の対処方法 (パート 3)
これらの手順を文書化し、テストすることで、組織は特に重大な障害イベント時に、レプリケーションシステムが SLA を満たす能力を正確に測定し、検証することができます。このプロアクティブなアプローチは、災害復旧戦略における潜在的なボトルネックや改善点を特定するのに役立ち、最終的にデータレプリケーションアーキテクチャの耐障害性と信頼性を強化します。
AWS DMS を使用してデータレプリケーション戦略を設計する際は、サービスの利用不可や、データの不一致を含むシナリオに対する包括的な緊急時対応計画を確立することが極めて重要です。ビジネスの RTO と RPO を徹底的に評価し、それに基づいて SOP を策定する必要があります。この戦略的な計画は、ビジネス継続性を促進するだけでなく、障害シナリオ時のレプリケーションシステムの実際のパフォーマンス指標に関する貴重なインサイトを提供します。
モニタリングとアラート
AWS DMS の効果を最大化するには、モニタリングとレポート機能に対する戦略的なアプローチが必要です。堅牢なモニタリングフレームワークは、シームレスなレプリケーション操作を維持し、移行プロセス全体でデータの整合性を促進するために不可欠です。
初期設定時に適切なアラートを構成することで、レプリケーションタスクのリアルタイムな可視性が得られ、異常に対して迅速に対応できるようになります。これらのモニタリング機能は早期警告システムとして機能し、データベース移行インフラストラクチャの健全性と効率性の維持に役立ちます。
プロアクティブな監視とアラートの実装により、運用の信頼性が向上し、リソースの使用状況とパフォーマンスパターンに関するインサイトが得られます。この体系的なアプローチにより、データに基づいた意思決定が可能になり、移行ライフサイクル全体を通じて最適なレプリケーションパフォーマンスを維持できます。
AWS DMS は、以下のモニタリング機能を提供します：
- Amazon CloudWatch メトリクス – これらのメトリクスは AWS DMS によって自動的に収集され、ユーザーは個々のタスクやレプリケーションインスタンスレベルでのリソース使用状況や関連メトリクスのインサイトを得ることができます。AWS DMS で利用可能なすべてのメトリクスのリストについては、AWS Database Migration Service メトリクスを参照してください。
- AWS DMS CloudWatch ログと Time Travel ログ – AWS DMS はエラーログを生成し、ユーザーが各コンポーネントに設定したログレベルに基づいてそれらを収集します。詳細については、AWS DMS タスクログの表示と管理を参照してください。CloudWatch ログが有効な場合、AWS DMS はデフォルトでコンテキストログも有効にします。さらに、DMS にはレプリケーションタスクのデバッグを支援する Time Travel ログ機能があります。Time Travel ログの詳細については、Time Travel タスク設定を参照してください。Time Travel ログの使用に関するベストプラクティスについては、Time Travel を使用したレプリケーションタスクのトラブルシューティングを参照してください。
- タスクとテーブルのステータス – AWS DMS は、タスクとテーブルの状態を報告するためのニアリアルタイムのダッシュボードを提供します。タスクステータスの詳細なリストについては、タスクステータスを参照してください。テーブルの状態については、タスク中のテーブル状態を参照してください。
- AWS CloudTrail ログ – AWS DMS は AWS CloudTrail と統合されています。CloudTrail は、ユーザー、ロール、または AWS サービスが AWS DMS で実行したアクションの記録を提供するサービスです。CloudTrail は、AWS DMS コンソールからの呼び出しや AWS DMS API オペレーションへのコード呼び出しを含む、AWS DMS のすべての API 呼び出しをイベントとしてキャプチャします。CloudTrail の設定に関する詳細については、AWS CloudTrail ユーザーガイドを参照してください。
- モニタリングダッシュボード – 拡張モニタリングダッシュボードは、モニタリングタスクとレプリケーションインスタンスに関連する重要なメトリクスの包括的な可視性を提供します。追跡したい特定のリソースのメトリクスをフィルタリング、集計、視覚化できます。このダッシュボードは、データポイントのサンプリング時間を変更することなく、既存の CloudWatch メトリクスを直接公開してリソースのパフォーマンスを監視します。詳細については、拡張モニタリングダッシュボードの概要を参照してください。
重要なメトリクスとログイベントに CloudWatch アラームを設定し、システム全体の障害に発展する前に潜在的な問題を事前に特定することをお勧めします。この基本的なモニタリングアプローチは出発点として機能しますが、特定のユースケース要件とビジネス目標に基づいてモニタリング戦略を拡張することが不可欠です。
| メトリクスタイプ | メトリクス名 | 改善策 |
| ホストメトリクス | CPU 使用率 | リソースの競合が DMS タスクのパフォーマンスに影響を与えるため、これらのメトリクスにアラームを設定してオペレーターに警告することをお勧めします。ホストのリソース制限に基づいて、CPU とメモリの競合がある場合は DMS インスタンスクラスをアップグレードするか、ストレージが少ない場合やベースライン IOPS がスロットリングされている場合はストレージを増やす必要があります。適切なレプリケーションインスタンスの選択方法の詳細については、レプリケーションインスタンスの最適なサイズの選択を参照してください。 |
| 空きメモリ | ||
| スワップ使用量 | ||
| 空きストレージ容量 | ||
| 書き込み IOPS | ||
| 読み取り IOPS | ||
| レプリケーションタスクメトリクス | CDC ソースレイテンシー | SLA 要件に基づいて、レイテンシーメトリクスのアラームしきい値を設定できます。DMS では、レイテンシーは複数の理由で発生する可能性があります。トラブルシューティングと SOP の作成については、AWS Database Migration Service のレイテンシー問題のトラブルシューティングを参照してください。 |
| CDC ターゲットレイテンシー | ||
| レプリケーションインスタンスの DMS イベント | 設定変更 | これらはそれぞれ、関連する異なるイベントを持つカテゴリです。要件に基づいて特定のイベントに通知を設定できます。これらのイベントの詳細なリストと説明については、SNS 通知用の AWS DMS イベントカテゴリとイベントメッセージを参照してください。 |
| 作成 | ||
| 削除 | ||
| メンテナンス | ||
| ストレージ不足 | ||
| フェイルオーバー | ||
| 障害 | ||
| レプリケーションタスクの DMS イベント | 障害 | |
| 状態変更 | ||
| 作成 | ||
| 削除 |
利用可能なメトリクスの完全なリストについては、AWS DMS ユーザーガイドの AWS Database Migration Service メトリクス を参照してください。
Amazon EventBridge を使用して AWS DMS イベントが発生した際に通知を提供したり、Amazon Simple Notification Service（ Amazon SNS ）を使用して重要なイベントのアラートを作成したりすることができます。DMS における EventBridge イベントの詳細については、EventBridge イベントユーザーガイドを参照してください。AWS DMS での Amazon SNS の使用に関する詳細については、Amazon SNS イベントユーザーガイドを参照してください。
CloudWatch アラームの設定に加えて、メトリクスフィルターを使用して AWS DMS CloudWatch エラーログに基づくカスタムアラートを作成できます。これらのカスタムアラートの実装に関する詳細な段階的ガイドについては、Amazon CloudWatch Logs からカスタム AWS DMS エラーに関するアラートを送信する というタイトルのブログ記事を参照してください。このリソースは、カスタムエラー監視機能を強化するための包括的な手順を提供しています。
AWS Well-Architected Framework の原則の適用
AWS Well-Architected Framework は、クラウド上でシステムを構築する際の意思決定の長所と短所を理解するのに役立ちます。フレームワークの 6 つの柱は、信頼性、セキュリティ、優れた運用効率、コストの最適化、持続可能なシステムを設計・運用するためのアーキテクチャのベストプラクティスを教えてくれます。
AWS Well-Architected Tool を使用すると、AWS マネジメントコンソールで無料で利用可能で、各柱に対する一連の質問に答えることで、これらのベストプラクティスに照らしてワークロードをレビューできます。
クラウドアーキテクチャに関するより専門的なガイダンスとベストプラクティス (リファレンスアーキテクチャのデプロイメント、図解、ホワイトペーパーなど) については、AWS アーキテクチャセンターを参照してください。
まとめ
この投稿では、耐障害性のある AWS DMS 実装を構築するための包括的なフレームワークを紹介しました。このガイドの有効性は、その実装の深さと特定の環境への適応の深さに直接相関しています。組織では、このガイドの各セクションを徹底的に見直して、独自のユースケースに合わせてカスタマイズされた移行戦略を開発するための基礎として活用することを強くお勧めします。
これらの推奨事項を慎重に評価し、移行計画プロセスに組み込むことで、AWS DMS を使用するための包括的で信頼性の高いアプローチを策定できます。これにより、長期的なデータ移動戦略の成功を促進することができます。
追加のサポートとリソースについては、AWS DMS ドキュメントをご覧いただくか、AWS サポートにお問い合わせください。
著者について
Sanyam Jain は、AWS Database Migration Service チームのデータベースエンジニアです。お客様と緊密に連携し、オンプレミスのワークロードを AWS クラウドに移行するための技術的なガイダンスを提供しています。さらに、AWS データ移行製品の品質と機能の向上において重要な役割を果たしています。
Sushant Deshmukh は、グローバルシステムインテグレーターを担当するシニアパートナーソリューションアーキテクトです。AWS 上で高可用性、スケーラブル、レジリエント、そして安全なアーキテクチャを設計することに情熱を注いでいます。AWS の顧客やパートナーが、アプリケーションを AWS クラウドに成功裏に移行し、モダナイズするのを支援しています。仕事以外では、新しい場所や料理を探索する旅行、バレーボール、そして家族や友人との質の高い時間を過ごすことを楽しんでいます。
Alex Anto は、Amazon Web Services の Amazon Database Migration Accelerator チームに所属するデータ移行スペシャリストソリューションアーキテクトです。
Amazon DMA アドバイザーとして、AWS のお客様がオンプレミスのデータを AWS クラウドデータベースソリューションに移行するのを支援しています。