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

Azure の移行計画の実行

更新日: 2014年4月

Azure は、マイクロソフトのデータ センターでホストされるインターネット規模のコンピューティングおよびサービス プラットフォームです。Azure では、基盤となるオペレーティング システム、ハードウェア、ネットワーク、ストレージ リソース、およびプラットフォームの更新がすべてマイクロソフトによって自動的に行われるため、基盤となるソフトウェアやハードウェアのインフラストラクチャを開発者や管理者が実装する必要はありません。

アプリケーションをクラウドに移行した後は、アプリケーションを新規に配置した場合と同様に、アプリケーションの機能とパフォーマンスをテストすることを強くお勧めします。Azure はオンプレミスのプラットフォームとは異なるため、移行を実行するときは次の重要な点について検討する必要があります。

ここでは、主に Azure クラウド サービスについて説明しています。Azure の仮想マシン内の SQL Server を使用した基本的な移行方法については、「Windows Azure 仮想マシンを使用した移行」を参照してください。

作成者: Kun Cheng、Steve Howard
寄稿者:Selcin Turkarslan

アプリケーションをクラウドに移行するときは、クラウドで想定どおりに機能するように、アプリケーションのテストとデバッグの方法を理解しておく必要があります。アプリケーションのテストに使用できる方法を次に示します。

  • Azure Tools for Microsoft Visual Studio: アプリケーションをビルドしてから、Azure Tools に含まれるコンピューティング エミュレーターとストレージ エミュレーターを使用して、このアプリケーションをローカルで実行およびデバッグすることができます。これにより、アプリケーションをローカルで開発してから Azure に発行できます。Azure Tools for Microsoft Visual Studio は Visual Studio 2010 の拡張ツールであり、Azure のほとんどの機能に対応するコンピューティング エミュレーターとストレージ エミュレーターを使用してアプリケーションをテストできます。機能テストの初期の段階でこのようなテストを行うことをお勧めします。詳細については、「Azure Tools for Microsoft Visual Studio」を参照してください。

  • SQL Server Data Tools: SQL Server Data Tools (SSDT) により Visual Studio 2010 内の統合環境が提供され、サポートされるすべての SQL プラットフォーム (オフプレミスの Azure SQL データベースやオンプレミスの Microsoft SQL Server 2012 など) について、データベースの設計、データベース オブジェクトやデータの作成と編集、クエリの実行などに使用できます。このツールでは、アプリケーションのリレーショナル データ アクセスの部分を調べることで、ローカルの既定のデータベースまたは Azure SQL データベースを使用してデータベース プロジェクトのソリューションをテストできます。詳細については、「SQL Server Data Tools」を参照してください。注: Azure Tools for Microsoft Visual Studio と SSDT はどちらも、オフラインとオンラインのデータ ソースを使用してアプリケーションの基本機能と互換性をテストするためのツールです。機能、パフォーマンス、スケーラビリティなど、実際のクラウド アプリケーションのあらゆる点をテストするには、アプリケーションが配置されて実行されている Azure でシミュレーション テストを行う必要があります。

  • 自動テストフレームワーク: 既存のアプリケーションの多くは既に自動テスト フレームワークを備えており、アプリケーションのすべてのコンポーネントと機能が想定どおりに動作することを確認できるようになっています。アプリケーションを Azure で実行するときは、どのように設計されているかによって、自動テスト フレームワークが機能する場合と機能しない場合があります。自動テスト フレームワークをオンプレミスから実行する必要がある場合でも、定義されているエンド ポイントを使用して Azure のアプリケーションに接続できれば機能することがあります。それ以外の場合は、接続の切断や待機時間の問題を軽減するために、自動テスト フレームワークとアプリケーションの両方を Azure でホストすることをお勧めします。

  • Visual Studio Load Testing: アプリケーションに既存の自動テスト フレームワークがない場合は、新しい自動テスト フレームワークを作成し、Visual Studio Load Testing を使用して複数の同時実行ユーザーについてのシミュレーション テストを行うことをお勧めします。

テスト、ステージング、実稼働の間の切り替えで、実際のカットオーバー時間をできるだけ最小限に抑えるようにしてください。オンプレミスから Azure に大規模なデータベースをコピーするには、数時間から数日間かかることがあります。また、既存のデータを完全に移行するまでの間、アプリケーションを停止しておけることはまずありません。そのため、カットオーバーによるダウンタイムを最小限に抑えるように計画する必要があります。カットオーバーとは、Azure に最終的に移行するまでにかかる時間のことです。カットオーバー前の時点で、静的なデータが格納されているテーブルと、カットオーバー中にデータが変更される可能性があるテーブルを区別します。静的なデータについては、カットオーバー時に移動する必要はありません。ただし、特定のテーブルのデータがカットオーバー中に変更されるかどうかが不明な場合は、変更されたすべてのデータを後で移行するためのロジックをシステムに含めるようにしてください。また、Azure でアプリケーションの運用を開始する前にオンプレミスのシステムのすべてのデータをクラウドに移行する必要があるかどうかについて検討することをお勧めします。データの移行はアプリケーションの運用を開始してからでもかまわない場合は、ダウンタイムをなくすことができます。

ただし、Azure での運用を開始する前に Azure のデータとオンプレミスのデータを一致した状態にする必要がある場合は、カットオーバー時に移行するデータの量を必要最小限に抑えることを検討してください。これにより、実際のカットオーバー時のダウンタイムを最小限に抑えることができます。場合によっては、カットオーバー前に一部のデータを移動し、実際のカットオーバー後に残りのデータを移動する方法が適していることもあります。そのような場合は、移行計画で、先に移行する必要があるデータとカットオーバー後に移行してもかまわない残りのデータを明確にする必要があります。これにより、残りのデータはアプリケーションを稼働した状態で移行できるため、Azure でアプリケーションの運用を開始する際のダウンタイムを短くすることができます。カットオーバー前のデータ移行に使用できるデータ同期方法を次に示します。

SQL データ同期プレビュー サービスでは、SQL データベース、つまり SQL Server および SQL データベース のデータ同期機能が提供されています。現在、このサービスには 2 つの主要な機能があります。

  • オンプレミスの SQL Server データベースと SQL データベース のインスタンスの間でのデータの同期。オンプレミスのアプリケーションとクラウドベースのアプリケーションでまったく同じデータを利用できます。

  • 2 つ以上の SQL データベース インスタンス間のデータの同期。インスタンスを同じデータ センター、別々のデータ センターまたは異なる地域に配置できます。

SQL データ同期プレビュー データ同期は、次のような状況で、オンプレミスのデータベースと SQL データベース のインスタンスを同期するのに適しています。

  • アプリケーションを並行してテストする必要がある。

  • オンプレミスのすべてのデータ操作を に最終的に移行する前に、アプリケーションを並行して実行する必要がある。

  • に移行するときに、ダウンタイムを最小限に抑えて、オンプレミスでアプリケーションを実行する必要がある。

  • オンプレミス アプリケーションと アプリケーションのハイブリッド ソリューションの一環として、継続的にデータ同期を行う必要がある。

データの増分変更を追跡するために、同期グループの構成時、SQL データ同期プレビュー によって同期するテーブルごとに変更追跡テーブルが追加されます。SQL データ同期プレビュー の使用時には、容量計画で変更追跡テーブルのことを考慮してください。また、同期の設定後は、同期グループを再初期化する場合を除き、同期するテーブルのテーブル構造や主キーを変更しないようにしてください。SQL データ同期プレビュー は、途中のデータや実行中のデータを同期する必要がある状況では最適とは言えません。

警告: SQL データ同期プレビュー は現在プレビューとして提供されており、今後のリリースのための製品フィードバックを得ることを唯一の目的としているため、運用環境で利用することはできません。

SQL データ同期プレビュー の詳細については、「SQL データ同期」を参照してください。

レプリケーション、ミラーリング、またはログ配布を使用して、オンプレミスの SQL Server から別のオンプレミスの SQL Server または Azure 仮想マシンで実行されている SQL Server のインスタンスにデータを移動することができます。ただし、これらの機能は、Azure SQL データベースとの間のデータの移動には使用できません。詳細については、「レプリケーションとログ配布」および「データベース ミラーリングとログ配布」を参照してください。

カットオーバー時のデータ転送にかかる時間を最小限に抑えるために、実際のカットオーバーの前に、できるだけ多くのデータを Azure Platform に移動しておく必要があります。変更されたデータをオンプレミスのシステムから Azure 環境に移動するカスタムの ETL ジョブを作成することができます。SQL Server 2008 以降のオンプレミスの SQL Server から移行するときは、変更データ キャプチャまたは変更データの追跡を使用して、変更されたすべてのデータ (変更されたデータのみ) がオンプレミスのデータベースから Azure SQL データベース インスタンスに実際に移動されることを確認することをお勧めします。これらの 2 つの機能の詳細については、SQL Server オンライン ブックの「データ変更の追跡」を参照してください。変更データ キャプチャや変更データの追跡を使用しないデータベースについては、変更内容と移行されたデータに対する追跡システムを作成する必要があります。いずれの場合も、実際のカットオーバーに必要なダウンタイムを最小限に抑えるには、実際のカットオーバー時に移動するデータを最小限に抑えることが重要です。

DAC を使用すると、SQL Server インスタンスからデータをエクスポートして Azure BLOB ストレージに格納し、Azure SQL データベースにインポートすることができます。DAC では、インポートまたはエクスポートするテーブルを抽出するフィルターを設定できますが、行レベル フィルターは設定できません。そのため、DAC はテーブル全体が 1 つのデータベースに収まる場合に適しており、スケールアウトされたデータベースでは適切に機能しません。また、実行中のデータを同期する必要があるアプリケーションのデータの移行には最適とは言えません。詳細については、SQL Server オンライン ブックの「データ層アプリケーションのエクスポート」を参照してください。

データベース バックアップを作成する目的は、管理者によるエラー、アプリケーション エラー、またはデータ センター全体の機能の喪失に起因するデータの損失から復旧できるようにすることです。Azure SQL データベースでのデータのバックアップと復元は、オンプレミスの SQL Server とは異なり、利用可能なリソースやツールと連動させる必要があります。したがって、信頼性が確保された状態でバックアップと復元を使用して復旧するには、Azure SQL データベースのバックアップと復元の戦略が必要です。Azure SQL データベース インスタンスで復旧が必要な問題は、主に次の 3 種類に分類されます。

  • インフラストラクチャまたはハードウェアの障害: データ センター内でハードウェア障害が発生することがあります。たとえば、Azure SQL データベース インスタンスを実行している物理ノードがクラッシュする場合があります。

  • アプリケーションやユーザーによって引き起こされる問題または障害: ユーザーまたはアプリケーションによって、意図しない変更がデータに加えられる場合があります。これにより元に戻す操作が必要になる場合があります。たとえば、ユーザーが間違った顧客に属するデータを変更する可能性もあります。

  • データ センター機能の喪失: Azure SQL データベースの現在のサービス レベル契約には、災害など、マイクロソフトの合理的な支配の及ばない事柄についての例外が明記されています。災害時にデータ センターが損壊した場合、データベースをレプリカやオンサイトのバックアップから復旧できなくなる可能性があります。

最終的には、Azure SQL データベースのデータ センターに格納されたデータに関して、リスクをどの程度まで受け入れるかを決める必要があります。バックアップと復元に使用できるツール、および災害復旧戦略を構築する方法の詳細については、MSDN ライブラリの「Azure SQL データベースの継続性」を参照してください。

Azure にアプリケーションを実際に移行するときは、次の方法で行います。

  • 並行して実行する: この方法では、オンプレミスと Azure の両方で並行してアプリケーションを実行できます。これにより、アプリケーションがクラウドに完全に依存する前に、Azure でアプリケーションのライブ テストを実行することができます。このテストには、たとえば、機能テスト、パフォーマンス テスト、スケーラビリティ テストが含まれます。Azure で新しいシステムを十分にテストしたら、最終的なデータ移行を実行し、オンプレミスのシステムを停止します。

  • 中断してカットオーバーする: この方法は、Azure での運用に完全に切り替える前にすべてのデータを同期する必要がある場合に適しています。この方法では、機能とパフォーマンスのすべてのテストを Azure で先に完了しておきます。その後、前述のいずれかのデータ同期方法を使用して Azure 環境にデータをレプリケートするようにシステムを設定します。最終的なカットオーバーの前に、最後の同期または ETL 操作に必要な時間を最小限に抑えることで、データをできるだけ同期された状態にすることをお勧めします。Azure にカットオーバーする準備ができたら、オンプレミスのシステムを停止し、最後のデータ同期を実行してから、Azure でアプリケーションを起動します。

関連項目

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