エクスポート (0) 印刷
すべて展開

Azure の移行ライフ サイクルの概要

更新日: 2014年4月

移行ライフ サイクルは、アプリケーションやデータを に移行する手順を示した標準的な方法です。次の図に示すように、主な移行手順のフェーズには、分析、アプリケーションの移行、データの移行、テストと最適化、および運用と管理があります。

このトピックでは、各フェーズについて詳しく説明し、さらに詳細な情報へのリンクも示します。

は、 仮想マシン上の Oracle もサポートしています。詳細については、「Azure 用の Oracle 仮想マシン イメージ」を参照してください。

作成者: Kun Cheng、Selcin Turkarslan、Norberto Garcia
校閲者:Paolo Salvatori、Steve Howard、Stuart Ozer

このフェーズの目的は、 ソリューションを必要とするビジネス ニーズを理解することです。ビジネス目標を特定したら、既存のアプリケーションのアーキテクチャを確認して とオンプレミス ソリューションの主な違いを特定し、 ソリューションのビジネス ニーズに合わせて既存のオンプレミス アプリケーションを再設計する必要があるかどうかを決定します。次に、移行計画の作成に役立つタスクと質問を示します。

  • ビジネス要件の定義: アプリケーションを で実行するときは、ビジネスのシナリオに応じて、次のような質問が多数発生する可能性があります。

    • 配置ソリューションの対象は新規の顧客やユーザーか。

    • 複数の顧客をサポートするマルチテナント機能が必要か。

    • 顧客のサイトではなく Microsoft のデータ センターでデータがホストされる場合、アプリケーションは法令遵守規定に準拠しているか。

    • アーキテクチャ的および戦略的に、よりクラウドに適しているのはどのアプリケーションか。

    • アプリケーションに最も適した移行のタイプはどれか: アプリケーション全体とすべての依存関係を に移行するか、アプリケーションの一部分をクラウドに移行して一部のリソースをオンプレミスに残すか、アプリケーションを Web またはワーカー ロールに移行し、依存関係のうち 仮想マシン上でよりよく機能するものを移行するか。

    これらの質問に対する答えは、 プラットフォームにおけるアプリケーション動作の設計方法に影響を与えます。

  • 機能の相違点の特定: 既存のアプリケーションを、変更を加えずに で実行できるか。たとえば、 SQL データベース (SQL データベース) では、オンプレミスの SQL Server でサポートされている機能の一部がサポートされていません。CLR (共通言語ランタイム) を使用するオンプレミス アプリケーションを SQL データベースに移動する場合は、SQL Server からアプリケーション層に CLR ロジックを移動するか、SQL データベースでサポートされている Transact-SQL ステートメントを使用して CLR ロジックを書き直すことによって、アプリケーションを再設計する必要があります。現在、SQL データベースでは SQL CLR がサポートされていません。

    2012 リリース以降の には、新しい仮想マシンの機能が追加されています。 仮想マシンを使用すると、Windows Server プラットフォームで構築された既存の SQL Server アプリケーションを、最小限のコード変更または変更なしで Platform に移行することができます。管理者や開発者は、 仮想マシン内の SQL Server の作業にも、オンプレミスの場合と同じ開発ツールや管理ツールを使用できます。仮想マシンのリレーショナル データベースのパフォーマンスには、仮想マシンのサイズ、ディスクの数と構成、ネットワーク、データベース ソフトウェアの構成、アプリケーションのワークロードなど、さまざまな要因が関係します。さまざまな仮想マシン サイズやストレージ構成でアプリケーションのベンチマークを行って、最適な構成を選択するようにしてください。詳細については、「Azure の仮想マシン内の SQL Server への移行」を参照してください。

  • パフォーマンスとスケーラビリティのための計画作成: 多くのレガシ アプリケーションは、アプリケーション ロジックとデータ アクセス コンポーネントとを緊密に統合するように設計されています。レガシ アプリケーションの場合は、 でのパフォーマンスとスケーラビリティが向上するように、アプリケーションのコンポーネントを分離する方が効果的です。アプリケーションが "おしゃべりな" (つまり、データ クエリが多すぎる) 場合は、Azure キャッシュ サービスの使用を検討するか、独自のキャッシュ メカニズムを実装して、データ アクセス クエリをバッチ処理し、アプリケーションとデータの間のやり取りを削減します。移行するアプリケーションで大規模なデータベースまたは大量のトランザクションを処理する場合は、SQL データベースへの移行時にデータベース モデルの再設計が必要になる可能性があります。これは、1 つの SQL データベース インスタンスで 1 秒あたりに処理できるトランザクション数が限られており、データベースのサイズも限られているためです。大規模なデータベースまたは大量のトランザクションを扱う場合は、SQL データベース内の複数データベースを使用するスケールアウト アーキテクチャの実装を検討するか、オンプレミスの高価なスケールアップ システムの代わりにスケールアウト方法を使用してください。パフォーマンスを向上するための手段として、大量のトランザクションが必要なテーブルにインメモリ OLTP や遅延持続性を実装することも検討してください。インメモリ OLTP の詳細については、「インメモリ OLTP (メモリ最適化)」を参照してください。遅延持続性の詳細については、「トランザクションの持続性を制御する方法」を参照してください。

    仮想マシンで SQL Server を使用する際のパフォーマンスに関する注意点の詳細については、「Azure の仮想マシンにおける SQL Server のパフォーマンスに関する考慮事項」とホワイト ペーパー「Azure の仮想マシンにおける SQL Server のパフォーマンス ガイダンス」を参照してください。

    SQL データベースの Premium Edition が制限付きのプレビュー版としてリリースされました。Premium サービスでは SQL データベースおよびそのセカンダリ レプリカ用に一定の容量を予約することで、従来の SQL データベース Web Edition および Business Edition と比較して、クラウド アプリケーションで予測可能性の高いパフォーマンスを得られるようになります。SQL データベースの Premium アカウントの詳細については、「Premium データベースの管理」および「SQL データベースの Premium プレビューに関するガイダンス」を参照してください。

  • アプリケーション ライフ サイクル管理の計画作成: でのアプリケーションのバージョン管理とアップグレードのシナリオを検討することが重要です。サービス レベル契約によっては、さまざまな階層の顧客をサポートするために、アプリケーションの複数のバージョンを管理する必要があります。 上でアプリケーションをアップグレードするときのダウンタイムを最小限に抑えたい場合もあります。 のステージング環境と運用環境は、注意深く管理することをお勧めします。互換性の問題が生じた場合はアップグレードをロールバックできるようにしてください。アップグレードのロールバック計画では、まずアプリケーションに対応し、次にデータベースに対応します。

このフェーズの後に、 Platform サービスおよびツールをよく理解するため、パイロット プロジェクトを構築することをお勧めします。

にアプリケーションを移行すると決めたら、概念実証のために、最小限のデータを含むパイロット バージョンのアプリケーションから始めます。まず、ビジネス要件と技術的な要件の観点から、 の配置目的に合わせて、必要なコード変更をアプリケーションに実装します。次に、 の適切なロールに対し、アプリケーション コードをコンパイルして配置します。

通常、既存のオンプレミス アプリケーションのほとんどは、最小限の変更または変更なしで クラウド サービスで実行できます。しかし、それでは、パフォーマンス、スケーラビリティ、およびセキュリティの問題が生じる可能性があります。パフォーマンスを最適化し、今後のスケーラビリティを実現するには、 クラウド サービスへの移行前に、複数のロールを使用してアプリケーションの再設計を検討することをお勧めします。詳細については、「Azure クラウド サービスの開発に関する注意事項」を参照してください。最初にアプリケーション全体を クラウド サービスに移動してから、データを移動することをお勧めします。セキュリティやパフォーマンスなどの理由で、アプリケーションの一部をオンプレミスに残さなければならない場合もあります。この場合、ハイブリッド ソリューションが必要になります。詳細については、「Azure のハイブリッド ソリューションの構築」を参照してください。

仮想マシン (VM) で SQL Server を使用する場合は、既存の SQL Server アプリケーションを変更して、 VM 内の SQL Server データベースに接続します。さらに、次の移行方法のいずれかを実行します。

  • 既存の仮想マシンで機能しているアプリケーションがある場合があります。この仮想マシンを に移行できます。この場合、アプリケーションと、アプリケーションの構成設定およびデータが、既にこの仮想マシン上にあります。しかし、そのために大規模な .vhd ファイルを にアップロードする必要が生じる場合があります。さらに、この既存の仮想マシンに依存するドライバーやハードウェアが存在し、それらを で使用できない場合もあります。

  • で仮想マシンを作成できます。そのためには、既に SQL Server を含むイメージ ギャラリーから仮想マシンを開始します。次に、この仮想マシンにアプリケーションをインストールします。これにより、アップロード時間が短縮され、ドライバーとハードウェアの依存関係が削除されますが、アプリケーションのインストールおよびデータのアップロードが必要です。

VM の SQL Server に既存の SQL Server データベースを移行する方法の詳細については、「Azure の仮想マシン内の SQL Server への移行」を参照してください。

クラウド サービスを使用する場合は、オンプレミスの SQL Server から SQL データベースにリレーショナル データを移動し、BLOB、テーブル、 Drive などの ストレージに非構造化データを移動します。詳細については、「Windows Azure のテーブルおよび BLOB へのデータの移行」および「Azure SQL データベースへの SQL Server データベースの移行」を参照してください。

仮想マシンで SQL Server を使用する場合は、次の 2 種類の移行方法のどちらかに従います。

  • 既存の仮想マシンにデータが含まれている場合があります。この既存の仮想マシンは、.vhd ファイルとして にアップロードできます。

  • で仮想マシンを作成できます。次に、データを .vhd ファイルとして にアップロードできます。その後、アップロードされたこの .vhd ファイルまたは空のディスクを、データ ディスクとして仮想マシンにアタッチできます。データ ディスクは、SQL Server のログ ファイルとデータ ファイルの格納に使用できます。また、「Azure の仮想マシン内の SQL Server への移行」で説明するツールや技法を使用して、既存の SQL Server データベースを 仮想マシンの SQL Server に移行することもできます。

アプリケーションとデータを に移行した後、機能とパフォーマンスのテストを実行します。このフェーズでは、クラウド内のアプリケーションをテストし、正しく機能することを確認します。次に、オンプレミスと のパフォーマンスを比較します。その後で、クラウド内のアプリケーションについて、機能、パフォーマンス、スケーラビリティの問題を解決します。詳細については、「Azure の移行計画の実行」を参照してください。

テストと最適化フェーズの後、 診断によるアプリケーションの監視とトレースをセットアップおよび実装します。 診断を使用すると、 で実行されるアプリケーションから診断データを収集できます。診断データは、デバッグ、トラブルシューティング、パフォーマンスの測定、リソース利用状況の監視、トラフィック分析、キャパシティ プランニング、監査などに使用できます。詳細については、MSDN ライブラリの「Azure での診断およびデバッグ」を参照してください。

オンプレミスと SQL データベースの間、または異なる SQL データベース サーバー間でデータを同期する必要がある場合は、SQL データ同期プレビュー サービスをセットアップおよび構成します。また、ユーザー エラーや自然災害に備えて、データ復旧プランをセットアップおよび構成することをお勧めします。詳細については、「Azure SQL データベースにおける高可用性と災害復旧」を参照してください。

関連項目

表示:
© 2015 Microsoft