データ移行を計画する
データ プラットフォーム最新化プロジェクトには、通常、順番に完了する 5 つのステージがあります。
このグローバル小売業者のシナリオでは、取締役会が最新化プロジェクトを承認し、あなたはスタッフやその他のリソースの編成を始めています。 タスクを最適に設定して割り当てるには、プロジェクトのフェーズを詳しく理解しておく必要があります。
このユニットでは、5 つの各ステージについてさらに詳しく調べます。
開始と検出
通常、データ プラットフォームの最新化プロジェクトは、ビジネス要件または法的要件を満たすために開始されます。 したがって、これらのニーズを考慮し、上級管理職からのサポートを得ることが重要です。 最初のステップは、次の考慮事項を含む検出作業を完了することです。
現在の環境を評価する
多くの IT インフラストラクチャは、通常、何年もかけて (場合によっては何十年にもわたって) 進化します。 その間に、企業やスタッフは、組織が所有するシステムに関する専門家がいなくなるくらい大きく変化する可能性があります。 まれには、一部のシステムがまだ存在していることを組織が忘れてしまうことさえあるかもしれません。
既存のアプリケーションとデータベースの間の依存関係を調べる
時間を取って、アプリケーションがネットワーク内に存在するデータベースとどのように対話するかを理解する必要があります。 さらに、データベースを論理的にグループ化してまとめられるように、データベース間に存在する可能性がある依存関係も理解しておく必要があります。 この作業を行うことで、データベースの論理グループを、1 つの単位として Azure に移行するための基礎に使用します。
システムのワークロードの種類の一覧を作成する
識別されたデータベース サーバーに対してワークロードの種類を一覧表示すると、その使用状況に関する分析情報が得られます。 ワークロードは、読み取りまたは書き込みが集中しているかどうかに基づいて、分析 (OLAP) またはトランザクション (OLTP) として分類できます。 これは、どのデータ プラットフォーム テクノロジを移行先とするかを決定するのに役立ちます。 分類には、さらにバッチまたは意思決定サポートのワークロードが含まれる場合があります。
評価
評価ステージでは、検出フェーズ中に収集された情報を使用して、識別されたワークロードの包括的な評価を行い、以下のことを判別します。
- 移行を阻害する可能性があるすべてのもの
- 移行後に修正する必要がある破壊的変更
- ワークロードで使用できる Azure の機能
現在のワークロードの評価と、ワークロードの条件の評価を行うことにより、これを確認します。
現在のワークロードの評価
識別したデータベース サーバーとアプリケーションを分類し、データ量と予想される増加率、平均リソース使用率、ビジネスに対する重要度を判別するために確認します。 また、このステージは、移行するデータベースの数を減らし、総保有コストを削減するために、オンプレミス データベースの組み合わせまたは使用停止を検討する機会にもなります。
ワークロードの条件の評価
ワークロードの条件の評価では、現在のワークロードの評価の結果を使用して、識別されたワークロードを移行後に実行するための条件を定義します。
たとえば、ピーク時に頻繁に使用されるトランザクション データベース サーバーを識別したが、ピーク時以外の時間の使用率は低かったとします。 ワークロード条件の評価では、移行後の条件を定義します。たとえば、ピーク時の負荷を処理するために、自動スケーリングを備えた Azure SQL データベースに移行します。
計画
データ プラットフォーム最新化プロジェクトの計画ステージでは、ターゲット プラットフォーム、移行アプローチ、計画的または計画外の停止の軽減計画を決定する必要があります。
データ プラットフォーム最新化プロセスの計画フェーズには、既存のオンプレミス環境から新しいクラウドベースの環境 (パブリックまたはプライベート) にアプリケーションとデータを移行する方法を説明する 7 つの用語があります。
| # | 段階 | アクション | 説明 |
|---|---|---|---|
| 1. | 維持 | 何もしない | オンプレミスに残っているサービスについては長期的なオプションを検討しながら、最新化を続けます。 |
| 2. | リホスト | IaaS への移行 | このアプローチを使用すると、データセンターの管理は不要になり、総保有コスト (TCO) が下がるため、投資収益率 (ROI) が高くなります。 |
| 3. | リファクター | 最小限のアプリケーションの変更で、IaaS または PaaS に移行します | このアプローチを使用すると、データセンターの管理は不要になり、総保有コスト (TCO) が下がるため、投資収益率 (ROI) が高くなります。 また、データベースの統合によって、管理オーバーヘッドを削減することもできます。 |
| 4. | リアーキテクト | クラウド テクノロジを使用するようにアプリケーションの主要な側面を書き換える | これにより、最新のコンポーネントの使用が可能になり、コードのデプロイが削減され、インフラストラクチャとサービスの DevOps デプロイが容易になります。 |
| 5. | リビルド | PaaS またはサーバーレス テクノロジを使用するようにアプリケーションを再構築する | 新しいテクノロジを使用してデータ プラットフォームとアプリケーションを再構築することで、Azure に組み込まれている高可用性を使用できるようになり、アプリケーションの移植性とスケーラビリティが向上します。また、使用されるテクノロジと、アプリケーションをサポートまたは開発するスタッフとの間のスキル ギャップの可能性も最小限に抑えられます。 |
| 6. | Replace | アプリケーションを新しいアプリケーションまたは SaaS ソリューションに置き換える | アプリケーションでサーバーに接続された物理デバイスが必要な場合、またはアプリケーションがオンプレミスのインフラストラクチャと緊密に統合されている場合は、置換アプローチを検討します。 |
| 7. | 削除 | 不要になったアプリケーションの使用を停止します | ビジネス的または法的に維持しておく必要がないため、レガシ アプリケーションとデータベースが使用されなくなったときは、廃止アプローチを検討する必要があります。 |
次に示すグラフは、各フェーズで必要な作業の量と、移行によって企業が得られる価値を比較したものです。
プラットフォーム ターゲットのオプション
ターゲット プラットフォームを選択するときは、2 つの高レベルの選択肢があります。
サービスとしてのインフラストラクチャ (IaaS) - このアプローチでは、SQL Server がインストールされている仮想マシンにデータを移行します。
サービスとしてのプラットフォーム (PaaS) - このアプローチでは、ワークロードに適したデータ プラットフォーム サービスにデータを移行します。 トランザクション ワークロードの場合、これには Azure SQL Database や Azure SQL Managed Instance が含まれます。 オンライン分析処理 (OLAP) の種類のワークロードの場合、これには Azure Synapse Analytics が含まれます。
機能によるターゲット プラットフォームの選択
Azure SQL Database - アプリケーションの外部からのアクセスがデータベース スコープの場合に使用します。 SQL Database は、特定のワークロードに最適なオプションになる可能性のある、低メンテナンス ソリューションを提供します。
Azure SQL Database エラスティック プール - エラスティック プールを使用すると、データベースごとにリソースを個別に管理するのではなく、データベース グループにストレージとコンピューティングのリソースを割り当てることができます。 さらに、エラスティック プールは、エラスティック プールに加えた変更によって個々のデータベースのスケーリングが不要になるので、単一データベースよりもスケーリングが容易です。
Azure SQL Database サーバーレス - これは、開発およびテスト環境のコストを削減するのに効果的です。 自動一時停止遅延機能を使用すると、データベースが自動的に一時停止するまでの非アクティブ期間を設定できます。 1 時間から 7 日間までの間で選択するか、無効にすることができます。 データベースは再度アクセスすると再開され、一時停止中はストレージの料金のみが発生します。
Azure SQL Managed Instance - アプリケーションの外部からのアクセスがインスタンス スコープであり、Azure SQL Database では使用できない次のような機能が必要な場合は、これを使用するのが適しています。
- SQL エージェント
- MSDTC
- DQS
- MDS
- データベース メール
- PolyBase
- リンク サーバーのサポート
- 脅威検出などの新しい Azure クラウド サービスのサポート
Azure 仮想マシンでの SQL Server - アプリケーションの外部からのアクセスがインスタンス スコープであり、Azure SQL Managed Instance で使用できない SQL Server Reporting Services (SSRS)、SQL Server Analysis Services (SSAS)、SQL Server Integration Services (SSIS) などの機能が必要な場合に使用します。
Azure Synapse Analytics - 超並列処理 (MPP) を利用してクエリの処理時間を減らすことができる複雑なクエリを大量のデータに対して実行するアプリケーションがある場合に使用します。
SQL 用の各 PaaS オファリングでサポートされている機能の一覧については、「機能の比較: Azure SQL Database と Azure SQL Managed Instance」を参照してください。
コストによるターゲット プラットフォームの選択
Azure SQL Database - Azure SQL Database が備えるサービスとしてのプラットフォームの性質により、必要な作業のほとんどが Microsoft によってバックグラウンドで自動的に行われるため、Azure IaaS トポロジの従来の SQL Server よりも、管理のコストが大幅に削減されます。 時間と労力の大幅な削減を大規模に実現できます。
Azure SQL Database エラスティック プール - Azure SQL Database エラスティック プールを使用すると、使用量の需要が予測できない複数のデータベースの場合に、大幅な削減ができます。 コンピューティング リソースは共有されるため、過剰プロビジョニングが回避され、サーバーの維持と管理のコストを削減できます。
Azure SQL Managed Instance - SQL Managed Instance は、最小限の構成変更でオンプレミスの環境を簡単にリフト アンド シフトできるフル マネージドのサービスを必要とするお客様に提供されます。 この環境では、最低 8 個のコアと最大 8 TB のストレージが提供され、分離された仮想ネットワーク内に配置されます。 このオファリングは、短期間でクラウドに移行し、仮想マシンを維持するオーバーヘッドを回避することを望まれるお客様に適しています。
Azure 仮想マシンでの SQL Server - PaaS オファリングと比較して、Azure 仮想マシンで実行される SQL Server に伴うコンピューティング、ストレージ、管理のコストは高くなりますが、SQL Server とインフラストラクチャをより細かく制御できます。
Azure Synapse Analytics - Azure Synapse Analytics を使うと、MPP アーキテクチャを利用して複雑なクエリを数時間ではなく数分で処理することにより、コストを削減できます。
オフラインとオンラインの移行
計画ステージでは、オフラインとオンラインのどちらの移行を行うかを検討する必要があります。 "オフライン" 移行では、移行開始と同時にアプリケーションのダウンタイムが始まります。 ダウンタイムを、移行が完了して新しい環境に切り替えるために必要な時間に抑えるには、"オンライン" 移行を使用します。 オフライン移行をテストして、ダウンタイムが許容可能かどうかを判断することをお勧めします。できない場合は、オンライン移行を行います。 さらに、選択した Azure プラットフォームによっては、オンラインとオフラインの選択ができない場合があります。
変換と最適化
評価と計画では、移行を成功させるために移行後に機能の変換または最適化が必要になるアプリケーションとデータベースの側面を識別しました。 通常、変換には、データベースの一部を修正または変更する必要がある作業が含まれます。
通常、最適化では、機能を利用するために移行されたデータベースを変更したり、Azure 内での使用を最適化したりします。
たとえば、変換には、ターゲット データベースでサポートされていない構文を含むストアド プロシージャまたは SQL クエリの変更が含まれる場合があります。 その場合、構文を調整して新しいデータベース プラットフォームとの互換性を確保し、ストアド プロシージャまたはクエリがターゲット環境で問題なくスムーズに実行されるようにする必要があります。
変換
移行後のエクスペリエンスを確実に成功させるには、次の 1 つ以上の変更をデータベースに対して行うことが必要な場合があります。
移行前のバージョンのアップグレードをインストールする
移行評価ツールによって識別されたエラーを修正する
データベース スキーマの変更を実装する
既存の統合データベース サービスを Azure に移行する
クラウドでの SSIS ワークロードの処理
最適化
組織による Azure への投資を最大限に活用できるよう、次のような最適化ガイドラインに移行中に従うことが必要な場合があります。
ターゲット プラットフォームで使用できる新機能を評価する
コストやパフォーマンスの効率が優れたセットにワークロードを再構成する
移行時に最上位のサービス レベルとパフォーマンス レベルを選択し、移行完了後にスケールダウンする
ワークロードが適切なサイズであることを確認する
BACPAC ファイルと対象のデータ センターの間の距離を最短にする
移行中の自動統計を無効にする。
パーティション テーブルとパーティション インデックス
インデックス付きビューを削除し、完了したら作成し直す
移行、検証、修復
このフェーズには、移行自体が含まれるだけでなく、重要なこととして、移行の成功を確認するために必要な検証手順と修復手順も含まれます。 これまでの計画、評価、変換の各ステージにより、すべてが移行できる状態であり、Azure への移行後に正常に機能することが保証されています。 残っているのは、必要な移行ツールを準備し、移行を完了し、移行後の機能とパフォーマンスの検証を実行して、ソース データベースとのデータの整合性を確認することだけです。
移行、検証、修復に関する考慮事項
選択したターゲット プラットフォームへの移行を実行するには、さまざまなツールを使用できます。 これらのツールについては、他のモジュールで説明します。 それまでの間、移行を完了するときに以下の点を考慮することが重要です。
- 最初にワークロードの要件を理解します
- 最初に移行するものとして、重要でないワークロードまたは低優先度のデータベースを選択します
- テスト移行を実行する
- データベースで問題をテストします
- ダウンタイムと互換性の問題に伴うリスクを軽減するための計画をテストします
- データベースのダウンタイムのリスクの軽減に役立つよう、中断に基づいて移行ツールを評価します
- 移行プロセスの繰り返しを続けます
- 移行対象のアプリケーションとデータベースで使用できるメンテナンス期間を検討します
- 古いデータベースとアプリケーションをオフラインにします
- サードパーティのアプリケーションをテストします
- 新しいディザスター リカバリー プランとメンテナンス プランを作成します