ツールの選択と移行モデルの決定基準を分析する
移行方法のオプションとツール オプションについて説明したので、Azure Database for PostgreSQL フレキシブル サーバーへの移行を実行するために検討する必要がある決定基準を調べることができます。 選択に役立つ 3 つの主な条件は、ダウンタイム、ソース データベースの場所、カスタマイズ性です。
ダウンタイム
ダウンタイムは移行アクティビティの重要な側面であり、利害関係者が許容できる期間は、オフライン移行アクティビティとオンライン移行アクティビティのどちらを実行する必要があるかを判断するのに役立ちます。
通常、移行アクティビティは、アクティビティに対して適切な変更制御と関連するガバナンスが確実に完了するように、事前に計画されます。 この計画により、主要な利害関係者との対話で、システムをオフラインにできる期間を把握できます。 このような状況では、推定最短ダウンタイム期間と最長ダウンタイム期間を確立できるさまざまなオプションにかかる時間を把握することをお勧めします。
アプリケーションのカットオーバーを実行するために必要な最小限のダウンタイムを確立することが重要です。 最終的に、この時間は、オンライン (または最小限のダウンタイム) 移行アクティビティでも、システムをオフラインにする必要がある期間です。 アプリケーションの複雑さによって、このタイムスケールが決まります。 比較的単純なアプリケーションの場合、このプロセスはサービスを停止し、構成ファイルを更新してからオンに戻すことになる可能性があります。 より複雑な環境で、複数のサーバーとアプリケーション レイヤーが存在する場合、このプロセスにより長い時間がかかる場合があります。
オンラインまたはオフラインの移行アクティビティに必要な期間を理解することは、ダウンタイムに関連する次の重要な要素です。 オフライン移行の場合、ソースから移行先へのデータの抽出、転送、読み込み、その後の検証と検査にかかった時間がダウンタイムになります。 このダウンタイムは、アプリ/ワークロードをオフにするのに要する時間と、アプリ/ワークロードをオンに戻すのにかかる時間の間になります。
オンライン (最小限のダウンタイム) 移行の場合、ダウンタイムは、アプリケーションがオフになった後にソースから宛先に最終的な変更を同期するために必要な期間です。 アプリケーション/ワークロードを再構成して有効にする前の検証、検査アクティビティをそのダウンタイムに加えます。
この情報を取得したら、移行の技術的な要素を確認して、実行可能なオプションを確立できます。
ソース データベースの場所
移行するデータベースのソースの場所は、特定の構成に対して課される可能性が高い制約があるため、一定の役割を果たします。
オンプレミスまたは Azure 以外のソース
オンプレミスまたは Azure 以外の場所のデータベースの場合、主な制約は通常、ソースとターゲットの間のネットワーク接続です。 ここで考慮すべき 3 つのポイントは、帯域幅、待機時間、データ量です。 これらの点を理解したら、実行可能な移行の種類について、十分な情報を得たうえで決定を行うことができます。
移行するデータの量が多く、それと比較したときに相対的に帯域幅が小さい場合、単純なダンプと復元はおそらく実行できません。 大量のデータと大量の帯域幅がある場合は、それほど問題になりません。
同様に、データ同期が行われるオンライン移行の場合は、待機時間が重要な要因の 1 つになります。 待機時間が長い場合は、同期プロセスの完了に時間がかかりすぎるため、システムのパフォーマンスに悪影響を及ぼす可能性があります。
また、他のクラウド プロバイダーから移行する際の重要な要素の 1 つとして、データ エグレスに対して課金されるかどうかについても考慮します。 その場合は、転送されるデータの物理的なフットプリントを最小限に抑えられることを考慮できます。 このような状況では、同期に使用されるダンプまたはデータ ストリームでは、圧縮テクノロジが重要になる場合があります。
その他の Azure ベースのサービス
他の Azure ベースのサービスから Azure Database for PostgreSQL フレキシブル サーバーに移行するような状況になることがあります。 これらのソース データベースは、Azure VM、コンテナー、または場合によっては Azure Database for PostgreSQL 単一サーバーに存在する可能性があります。 その場合は、検討すべき考慮事項のセットは異なりますが、同時に、これらのシナリオに対する Azure サービス内の最適化の恩恵を受ける機会がいくつかあります。
カスタマイズ性
最後に考慮すべき領域は、どの程度のカスタマイズが必要か、または望ましいかについてです。 この考慮事項は、データ レプリケーションをサポートするためにソース データベース構造の変更が必要になるという形を取る場合があります。または、スクリプトを使用して自動化する方法がいかに簡単であるかを意味する可能性があります。
良い例は、pg_dump と pg_restore を介してデータベースのオフライン移行を自動化することですが、同時にダンプ ファイルの圧縮と展開も含まれます。
意思決定
この情報のすべてを収集するプロセスを経たので、利害関係者と協力して、特定のシナリオに最適なオプションを決定できます。 どの手法とテクノロジのセットを使用するかを決定するときは、ビジネスの利害関係者だけでなく、技術的な利害関係者とも連携することが重要です。 このコラボレーションは、ビジネス上の判断で最小限のダウンタイムの移行が推進される状況を回避するのに役立ちます。技術チームの側では、スタッフ、リソース、またはテクノロジの制約のためにこれを提供できません。
ここで重要なのは、期待を管理し、オープンで正直な対話の機会を持つことです。 また、データベース移行を実行する技術チームの範囲外にある検証タスクの所有権をビジネスが確実に持つことも重要です。 この検証には、データの整合性と検証チェック、およびユーザー エクスペリエンス テストが含まれる場合があります。