セールス: 1-800-867-1380

Azure SQL データベース移行プロジェクトの計画

更新日: 2014年4月

このトピックでは、Microsoft Azure SQL データベース 移行プロジェクトの一環としてオンプレミスの SQL Server データベースを に移行するための計画および移行のベスト プラクティスについて説明します。このトピックの内容は次のとおりです。

  1. データベースの移行のパースペクティブ

  2. 分析 (この中で、データベース移行プロジェクトの目標を設定する)

  3. データ移行サブプロジェクトの管理 (計画と設計開発テスト安定化デプロイの各フェーズ)

執筆者: Shaun Tinline-Jones
寄稿者:Steve Howard
校閲者:Shawn Hernan

データベースの移行は、より大きなソリューション移行プロジェクトの下位プロジェクトになります。一般に、アプリケーション移行プロジェクトとデータベース移行プロジェクトの間には、統合ポイントと依存関係があります。しかし、通常は、データベースの移行をほとんど問題なく並行して進めることができます。

Azure SQL データベース移行プロジェクトでは、次の 3 つのパースペクティブに留意する必要があります。

  • プロジェクトのライフサイクルは、本質的にアジャイルかつ反復的である必要があります。初期調査に基づいて最初の計画を作成し、新たな反復の計画を立てる際に、前の反復で行われた調査に基づいて計画を調整します。

  • 移行プロジェクトの多くの要素は、データベースおよび関連付けられているアプリケーションのサイズと複雑さに左右されます。

    • 複雑なデータベースでは、データベースの移行に必要なエンジニアリング作業が増加します。

    • データベースのサイズが大きいと (含まれているデータの量が多いと)、新しいデータベースにデータを読み込んでオンプレミス データベースから Azure SQL データベースでホストされるデータベースにカットオーバーするのにかかる時間が長くなります。

  • データベースを新しいプラットフォームに移行する際には、多くの場合、そのデータベースを使用する他のソリューション層に影響を与えるような変更が必要になります。移行プロジェクトでは、影響を受けるすべての層の間で開発作業を調整して、変更されたすべてのコンポーネントの配置を統合する必要があります。

移行する各データベースは、サイズと複雑さによって定義される四分区間のいずれかに分類できます。データベースがどの四分区間に分類されるかを特定すると、そのデータベースを Azure SQL データベースに移行するために必要なプロジェクトのスコープを把握し、移行に適したメカニズムを選択するのに役立ちます。この四分区間は次のようになります。

大きなデータベースは、データをインターネット経由で転送するのに時間がかかるため、Azure SQL データベースへのカットオーバーに必要な時間が長くなります。複雑なデータベースは、変更が必要になる可能性が高いため、必要なエンジニアリング作業が増加します。

ソース データベースのサイズと複雑さを把握することは、移行プロジェクトの目標を設定するうえで重要です。

分析フェーズでは、プロジェクトの目標と構想を設定します。移行するデータベースの目標をプロジェクト全体の目標に含める必要があります。

すべてのデータベースは、可用性、復旧、応答時間、セキュリティとプライバシーの規則への準拠などのビジネス要件を満たしている必要があります。データベースを Azure SQL データベースに移行するときには、これらのビジネス要件を満たすようにデータベース サービスを構成するか、Azure SQL データベースで満たすことのできる新たな要件を取り決めます。管理プロセスの変更が必要になる場合もあります。たとえば、現在データベースを夜間にバックアップしている場合は、Azure SQL データベースによってサポートされているデータベースのコピー機能やデータ層アプリケーションのエクスポート機能への変更が必要になる場合があります。

ビジネス要件は、データベースやアプリケーションの既存のコードを分析しても特定できません。関係者や管理者の話を聞いたり、サービス レベル契約などのプロセス ドキュメントを確認したりして、要件を収集する必要があります。

データベースの移行に関連する 移行プロジェクトの目標では、データベースのビジネス要件が満たされていて、データベースのサイズと複雑さが反映されている必要があります。複雑なデータベースの移行では、単純なデータベースより多くのエンジニアリング作業が必要になります。複雑なデータベースを移行するプロジェクトのリスクを減らすには、最初のプロジェクトの目標を、オンプレミス データベースで使用されている機能の移行に限定します。Azure SQL データベースに固有の機能は、後続のプロジェクトで組み込むことができます。

分析フェーズは、計画と設計フェーズのための高レベルのガイダンスを提供します。このフェーズでは、移行に影響する可能性があるすべての問題を確認することが重要ですが、詳細に深入りしないようにしてください。その後、計画と設計フェーズの最初の反復で、問題を詳しく調査して、詳細な設計と計画を作成する必要があります。計画と設計の初期作業の結果で構想とスコープのドキュメントを調整するためのフィードバック プロセスを導入します。

Azure SQL データベース移行プロジェクトの複雑さを評価するには、移行を完了するのにどのくらいの変更が必要かを特定します。移行によって必要になる変更作業のスコープの評価は、Azure SQL データベース移行プロジェクトの段階が進むにつれてより正確なものにする必要があります。最初の一般的な評価は、プロジェクトの目標の定義およびプロジェクトの開始の決定の際に考慮する必要があるほか、プロジェクトの計画と設計の初期作業の基礎にもなります。プロジェクトの後の段階で行われるより詳細な調査の結果は、しだいに詳細になっていくプロジェクトの計画と設計に反映する必要があります。プロジェクトの目標の修正が必要になる場合もあります。

移行プロジェクトの一環として、Azure SQL データベースではサポートされていない機能に対するすべての依存関係に対処します。最初にこれらの依存関係を特定する際には、実稼働システムにアクセスする必要はありません。Azure SQL データベースでサポートされている機能に関する既存のドキュメントを、データベース設計文書やアプリケーションの仕様書と比較することによって特定できます。データベースとアプリケーションの設計に詳しい人に確認してもらうこともできます。その後、Azure SQL データベース移行ウィザードなどのツールを使用して一部の依存関係を確認できます。

多くのオンプレミス データベースは外部のサービスに依存しています。たとえば、レプリケーション トポロジ、SQL Server Integration Services の抽出プロセス、SQL Server エージェントによって管理されている定期的なメンテナンス タスクなどに含まれている場合があります。そうしたサービスに対する依存関係を変更するために必要なコストと開発時間を移行プロジェクトに含める必要があります。Azure SQL データベースをサポートしていないサービスに対する依存関係はすべて解消します。Azure SQL データベースをサポートしているシステムでも、SQL Server と Azure SQL データベースのアーキテクチャ上の違いから変更が必要になる場合があります。

また、Transact-SQLではサポートされていない Azure SQL データベース オブジェクトがオンプレミス データベースに含まれている場合もあります。データベースにアクセスするアプリケーションや、ストアド プロシージャやトリガーなどのデータベース オブジェクト内のコードで、Azure SQL データベースではサポートされていない構文要素が使用されている場合もあります。

データベースの複雑さについての最初の評価に使用できるドキュメントを以下に示します。これらのドキュメントで説明されている問題について、データベースとアプリケーションの設計やコードを確認します。

データベースを Azure SQL データベースに移行すると、多くの場合、そのデータベースを使用するアプリケーションやシステムの変更が必要になります。

まず、アプリケーションが Azure SQL データベース環境で効果的に動作するために必要な変更を加える必要があります。Azure SQL データベースは、データ センターの外部でホストされる Web サービスです。そのため、データベース サーバーがアプリケーション サーバーと同じラックにあるときにはほとんど影響しないようなデータベースのベスト プラクティスが、データベースを Azure SQL データベースに移行すると重要になります。Azure SQL データベースでホストされる各データベースは、全体的な可用性を高めるために複数のサーバーでクラスター化されますが、特定の操作や現在のサーバーの障害によって一時的なフェールオーバー イベントが発生し、開いているすべての接続が閉じられて、アクティブなトランザクションがロールバックされることがあります。そのため、切断エラーを受け取った場合にトランザクションを再開する堅牢な再試行ロジックをアプリケーションに実装することが重要になります。

高いパフォーマンスをサポートするために必要なアプリケーションの変更の詳細については、「Windows Azure SQL データベースのパフォーマンスに関する考慮事項」を参照してください。

Azure SQL データベースで効果的に動作するために必要なその他のアプリケーションの変更については、次のドキュメントを参照してください。

データベースに加えた変更に合わせてアプリケーションを変更する必要もあります。たとえば、データベースからユーザー定義集計を削除した場合は、その集計を参照する Transact-SQL ステートメントを実行するアプリケーションを変更する必要があります。

計画と設計の作業は、複雑さの評価が行われている間に開始する必要があります。このフェーズでは、次の 2 つのセクションで取り上げた問題についての調査をしだいに詳細化することが重要になります。

変更する必要がある機能が特定されたら、プロジェクトの初期の反復で、それらの変更に必要な作業の当初見積もりを作成します。反復を重ねるたびにより包括的なデータベースのレビューを実施して、すべての変更を特定し、必要な変更のスコープのより詳細な定義を作成します。また、計画と設計の反復の間に行われたより詳細な調査の結果を反映してプロジェクトの目標とスコープを調整するためのフィードバック プロセスを導入します。最初の反復では、運用環境にアクセスする必要はありませんが、運用環境の要素をある程度正確に反映する必要があります。

この最初の計画は、Azure SQL データベース移行ウィザードを使用して、オンプレミスの SQL Server と Azure SQL データベースの違いについて調査することによって行うことができます。これらについては、それぞれのトピックで詳しく説明します。この段階では、SQL Server Data Tools (SSDT) が役に立つ可能性があります (データ層のアプリケーション ライフサイクル管理 (ALM) でこのツールまたはデータベース オブジェクトのスクリプトが使用されている場合など)。このツールで必要な作業は少なく、Azure SQL データベース移行ウィザードよりは少し多くなりますが、それほど面倒ではありません。警告をダブルクリックすると問題の行に直接移動できるなど、Visual Studio の一般的な生産性機能を使用できます。

Transact-SQL のサポートなどの問題の評価を確認するために使用できるツールは数多くあります。

  • Azure SQL データベース移行ウィザードをオンプレミス データベースのテスト コピーまたは実稼働コピーに接続して、Azure SQL データベースで実行するために変更する必要があるオブジェクトのレポートを生成できます。詳細については、「SQL Azure 移行ウィザードを使用する方法」を参照してください。

  • オンプレミス データベースのすべてのオブジェクトがデータ層アプリケーション (DAC) によってサポートされている場合は、DAC パッケージを抽出して次のいずれかの操作を行うことができます。

    • DAC パッケージで Azure SQL データベース Compatibility Assessment Service を実行して、必要な変更についてのレポートを取得します (現在提供されているのはベータ版です)。

    • SQL Server Data Tools で DAC パッケージをインポートしてデータベース プロジェクトを作成し、プロジェクトのターゲットを Azure SQL データベースに設定します。

    • 詳細については、「DAC パッケージを使用して Windows Azure SQL データベースにデータベースを移行する方法」を参照してください。

評価ツールでは、Azure SQL データベースでサポートされていない機能を特定することはできても、同じ機能を実現するために使用できる代替機能を特定できるとは限りません。プロジェクトの計画者は、その機能がビジネスでどのように使われているかや、その使い方をサポートするにはほかにどのような設計が考えられるかを、理解している必要があります。続行するかどうかの決定は、代替機能を開発および配置するためのコストの評価に基づいて行う必要があります。必要な機能がサポートされていなくても、Azure SQL データベースを使用できないとは限りません。

移行以外の目的は (複雑な移行では特に) 含めないようにします。複雑さの増加は、移行プロジェクトが失敗する一般的な理由の 1 つです。スケールアウト データベース モデルの活用に対する要望がスコープに含まれることがよくありますが、これは、次のように、必要な場合のみに限定します。

  • 移行するデータベースが Azure SQL データベースでサポートされている最大サイズより大きい場合。

  • ビジネス ケースを実現するには最初からマルチテナント機能が実装されている必要がある場合。

  • 1 つの Azure SQL データベースではデータベースのコンピューティング要件に対応できない場合。

計画と設計では、コストの問題も考慮に入れる必要があります。コスト要因は、各フェーズで反復のたびに評価する必要があります。これらは、続行するかどうかの決定において常に重要になります。コストの要素は、このリスクが問題になる可能性は低いために計画と設計から除外される場合がありますが、コストを過小評価すると重大な結果を招く可能性があります。

成功の鍵は、リスクを特定して、その確率と重大度を評価することです。些細なことに思われるものも含め、すべてのリスクを列挙します。可能性の高いリスクについては、すべての関係者がその評価に同意していること、問題になった場合のための十分なレベルの軽減計画が用意されていることを確認します。また、移行のすべてのフェーズで見つかった新しいリスクについての計画を追加するためのプロセスを確立します。最後の配置フェーズで検出および解決された問題は、将来のプロジェクトのリスクとして記録する必要があります。使い慣れたオンプレミス環境ではなくクラウド環境に当てはめてリスクを評価することも重要です。

データベースで使用されているすべての機能を Azure SQL データベースでサポートされている機能に対して確認する包括的なレビューをプロジェクトに含めることが重要です。変換のコストとデータベースを Azure SQL データベースで実行するためのコストの見積もりを含める必要もあります。このレビューは、コストが利点を上回る場合にプロジェクトを中止できるように、早期の反復で行う必要があります。ある Azure SQL データベース移行プロジェクトは、オンプレミス データベースで使用されているデータ圧縮が Azure SQL データベースではサポートされていないことをプロジェクトの計画者が見逃したために、比較的遅い段階で困難に陥りました。このプロジェクトでは、データベースを Azure SQL データベースで実行するためのコストの見積もりが大幅に変更されることになりました。この種の問題は、プロジェクトの比較的早い段階で特定する必要があります。

計画と設計フェーズでは、データ層で必要な変更の評価を反復のたびに深めていく必要があります。たとえば、2 回目の反復で機能テスト環境のプロファイラー トレースを作成して SQLAzureMW を実行し、3 回目の反復でパフォーマンス テスト環境に進む場合などが考えられます (パフォーマンス テスト環境では、パフォーマンス監視ツールを使用して、移行準備が必要な領域を特定できます)。

Azure SQL データベースでは、SQL Server 2008 以降のバージョンで削除された SQL Server 2000 および SQL Server 2005 の機能はサポートされていません。たとえば、Azure SQL データベースでは、結合を指定するための構文 *= および =* はサポートされていません。そのため、それらのデータベースを Azure SQL データベースに移行するときには、SQL Server 2000 や SQL Server 2005 からのアップグレードと同じ問題の多くにも対処する必要があります。これらの依存関係は、パフォーマンス モニターのカウンター、XEvents、SQL Server アップグレード アドバイザーなどのツールを使用して検出できます。これらの問題に関する調査の詳細については、「データベース エンジンのアップグレード」を参照してください。

開発は、計画と設計のフェーズから生成されたタスクを実行する、独立した作業です。開発タスクに割り当てる人には、移行プロジェクトの他のフェーズのタスクは割り当てないようにする必要があります。

Azure SQL データベースに移行するほとんどのデータベースで、アプリケーション層に影響する変更が必要になります。データ型、返される列の数、動的な Transact-SQL、入力パラメーターなどが変更されるとすぐに、アプリケーションのデータ層のコードの変更が必要になります。移行によって変更されるデータベース オブジェクトがない場合でも、Azure SQL データベースのアーキテクチャによって、堅牢な再試行ロジックやエラー処理などの変更がアプリケーションで必要になります。つまり、データベース開発はアプリケーション層の開発と統合する必要があります。

データベース開発作業には、SQL Server データベースをサポートしている任意のデータベース開発ツールを使用できます。SSDT など、Azure SQL データベース用のロジックが含まれているツールを使用すると、データベース プロジェクトのビルド ターゲットを Azure SQL データベースに設定できます。そうすると、コードの入力中に互換性のない構文が検出されます。詳細については、「Microsoft SQL Server Data Tools」を参照してください。SSDT がリリースされる前は、開発者は Azure Emulation Kit を使用して SQL Server Express に接続していました。これにより、利便性が向上し、オフライン感覚の開発が実現されますが、オンプレミスの機能であることに変わりはないため、Azure SQL データベースで可能なことについて誤解を招く可能性があります。より生産的かつ効率的なエクスペリエンスを実現するには、できるだけ計画フェーズに近い段階で問題を特定して、コーディングを始めるときには通常どおりにコードを記述できるようにする必要があります。Azure SQL データベース用のロジックが含まれているツールを開発に使用していない場合は、Azure SQL データベースに対する開発をできるだけ早く開始します。SSDT などのオフライン開発ツールには、同じプロジェクトで複数の開発者が同時に作業できるという独自の価値があります。SSDT は、Team Foundation Server に見られるようなソース管理機能やビルド機能とも統合されています。移行がアプリケーションとデータベースの両方のコードに影響する場合は、データベース プロジェクトを同じビルド環境に統合できます。移行がアプリケーションとデータベースの両方に影響する場合は、SSDT プロジェクトをアプリケーション プロジェクトのビルド プロセスと同じソリューションに統合できます。もちろん、直接 Azure SQL データベースに対して開発を行う場合のように接続の問題に煩わされることもありません。

移行で必要なデータ モデルの変更が比較的少ない場合は、そのデータ モデルを SSDT にインポートしてから変更を適用します。そうすると、個々の開発者がそれぞれ個別の領域で作業して、それらをビルド フェーズで統合できます。

開発チームは、プロジェクトの反復のたびに計画チームに定期的なフィードバックを提供して、開発サイクルにプロアクティブに対応する必要があります。定期的にコードを検証すると、失敗してもすぐに復旧できるため、検証せずに長期間コーディングを続けるよりリスクが小さくなります。これは新しいパラダイムではありませんが、クラウド ベースのソリューションを開発するときには、これらのパラダイムに従わない場合のコストが非常に高くなります。

移行プロジェクトのアプリケーション ライフサイクルの他のアクティビティと同様に、Azure SQL データベースへの移行以外の場合と変わらないアクティビティと目標があります。Azure SQL データベースにとって重要だがよく見落とされるテストの領域を以下に示します。

  • エラー処理

  • 再試行ロジック

  • 調整への対応

  • 変更の配置

  • スケールアウト パラダイム

  • ネットワークの待機時間の影響

  • セキュリティ

  • ログ記録

これらは、機能テストとパフォーマンス テストのユース ケースの基礎になるため、注意する必要があります。テスト ツールは数多く出回っていますが、重要なのは、データベース操作を分離できることです。機能テストを使用すると、SQL Serverにはない Azure SQL データベース の機能を正確に検出できない開発ツールの未熟さを補って、生産性を向上させることができます。使用する開発ツールとビルド メカニズムによっては、機能テストで問題が生成されない場合もあります。その場合、機能テストは、より多くの時間とコストを必要とするパフォーマンス テスト ハーネスの前の単なる追加の保険のようなものになります。

移行したソリューションのテストでは、オンプレミスの実装にはほとんど影響しなかった新しいユース ケースに取り組む必要があります。トランザクションの再試行が必要になるようなエラーを強制的に発生させるテストを作成して、負荷がピークに達したときの影響をテストします。クラウド ソリューションでは、トラブルシューティング時間の短縮を目指す必要があります。そのためには、利用状況をログに記録してシステムの現在の状態を定期的に分析するアプリケーション ロジックを開発します。データベースでのログ操作はコストが高く、別のテーブルへの書き込みに制限されるため、データベースを呼び出すアプリケーション コードでエラー、警告、および経過時間をログに記録する必要があります。たとえば、あるお客様は、パフォーマンスが低下したサーバーのトラブルシューティングに数時間を費やしました。多くのツールを使用して、問題の原因を事後対応的に特定して解決方法を見つけようとしましたが、数時間後、サーバーが突然正常に動作し始めました。アプリケーションに問題があったわけではなく、プラットフォームのアップグレードが行われていただけだったのです。この問題の解決に費やされた労力は、アプリケーションがログにデータ ポイントを記録するように作られていて、管理者がソリューションの状態を定期的に分析していれば、大幅に削減できたと考えられます。問題の根本的な原因の特定に役立つデータをヘルプ デスク エンジニアに提供しておく必要もあります。もちろん、将来そのようなデータが使用されるときには、ユーザーを別のデータ センターにリダイレクトすることもできます。

テストで忘れられがちなのが配置エクスペリエンスです。配置エクスペリエンスをテストに含めて、将来既存の環境に変更を適用する方法を検討および確認できるようにする必要があります。新しいデータベースを配置し、シードして、運用環境で使用できるように準備する作業は、既存の運用環境に変更を配置する作業とは大きく異なります。これはオンプレミスの考慮事項と変わりませんが、ここで触れたのには次の 2 つの理由があります。

  • オンプレミスで機能した配置操作がクラウド ベースのソリューションでも機能するとは限りません。

  • これをテスト計画に含めるにはかなりの追加作業が必要になりますが、すぐに得られる成果はほとんどありません。

テストを反復モデルに含めて、問題を開発チームと計画チームにフィードバックする必要もあります。オンプレミスのテスト ハーネスによく似たごく基本的なテストから始めて、反復のたびに、クラウドに対応したテスト ケースを増やしていきます。テスト ケースでは、上の「プロジェクトの複雑さの評価」で紹介したドキュメントに示されている問題がカバーされている必要があります。

ダウンタイムの制約のために移行が複雑になる場合もあります。その場合は、提案された配置計画のテストの優先度がさらに高くなります。

この段階の目的は、通常のソフトウェア開発ライフサイクルの場合と変わりません。移行プロジェクトでは、開発者が、移行されたデータベースの最初のバージョンのコーディングではなく、テストによって提起された問題の作業のみを行うようになります。

クラウドへの移行の配置フェーズも、安定化と同様に、オンプレミスの移行プロジェクトと変わりません。テストが適切に行われていると、このフェーズが成功する確率が高くなります。

移行の成功の鍵はコミュニケーションです。状態を使用する側に、適切なレベルの詳細を含む定期的な状態の更新を提供することは、優れたエクスペリエンスのために (少なくとも、クラウドへの移行のより大きなビジネス目標を見失わないようにするために) 欠かせません。

配置フェーズの成功は、それ以前のフェーズで行われた作業の品質にかかっています。調査、計画、開発、およびテストが適切に行われていないと、配置の段階で問題が発生するリスクが大幅に増加します。深刻な配置の問題のためにプロジェクトが中止されて、オンプレミス システムに戻されることもあります。場合によっては、クラウド ベースのシステムを利用する組織の能力が疑問視されることもあります。調査、計画、開発、およびテストが適切に行われていれば、通常は、計画どおりに配置を実行できます。問題が発生したとしても、計画が適切に行われていれば、問題の影響を軽減する代替計画が用意されています。

この情報は役に立ちましたか。
(残り 1500 文字)
フィードバックをいただき、ありがとうございました
表示:
© 2014 Microsoft