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

Azure への移行の計画

更新日: 2014年4月

移行の計画を始めるときは、コスト、ビジネス要件と技術的な要件、タイムライン、移行プロセスで必要になるテストなど、いくつかの重要な要因について最初に検討する必要があります。ここでは、Azure への移行を計画するときに検討する必要があるいくつかの問題および手順について説明します。

作成者: Steve Howard
校閲者:James Podgorski、Paolo Salvatori、Selcin Turkarslan、Stuart Ozer

コストは、最も重要な検討事項の 1 つです。オンプレミスのアプリケーションを Azure に移行することを検討している場合は、意思決定および計画の早い段階でコストについて検討することをお勧めします。Azure のアプリケーションの料金は、ネットワーク トラフィックの負荷、アプリケーションの入出力の特性、アプリケーションで処理するデータの量など、いくつかの基準に基づいて設定されます。このトピックでは、料金の計算については説明しません。移行の計画を始める前に Azure 料金計算ツールを使用してコストを見積もることをお勧めします。Azure 料金計算ツールを使用するには、ここをクリックしてください。

組織のコストを計算するときは、開発およびテストの段階で必要になる Azure のコストも忘れずに含めるようにしてください。オンプレミスの開発プロジェクトでは、開発サーバーとテスト サーバーの使用料がかかります。同様に、Azure 環境でも、開発およびテストの段階で使用するリソースの使用料が必要になります。また、トレーニングや習得のためのコスト、Azure へのアプリケーションの移植に関連するコストも考慮する必要があります。あらかじめ、パフォーマンス テストとキャパシティ プランニングを行って、アプリケーションに必要な容量を評価しておくことをお勧めします。

Azure を使用すると、いくつかのビジネス要件と技術的な要件に適切に対処することができます。ここではすべて紹介することはできませんが、アプリケーションを Azure に移行することをお勧めする状況を次にいくつか示します。

  • ユーザー ベースが分散している: Azure のデータ センターは、世界各地に分散しています。必要に応じて、データ センターを相互に接続することで、データ配信のパフォーマンスを高めることができます。Azure のコンテンツ配信ネットワーク (CDN) やデータ同期サービスなどの機能を使用すると、使用頻度が高い関連データをエンド ユーザーの近くのデータ センターに分散して配置できます。地理的に近い場所にあるデータ センターにユーザーを接続することによって、データをやり取りする距離が最小限になり、ユーザー環境が最適化されます。

  • 負荷が一定でない: オンプレミスのアプリケーションでピーク時の負荷を処理するにはハードウェアの購入が必要になります。たとえば、小売店では、ホリデー ショッピング シーズンの負荷に対応できるサーバーを購入するのが一般的です。同様に、経理部門では、月末や年末の決算の時期の負荷に対応するために、インフラストラクチャの追加を検討することがあります。そのようなピーク時の負荷に対応することを目的としたサーバーは、残りの期間はあまり活用されません。一方、規模に柔軟に対応できるように設計したアプリケーションの場合は、Azure を利用して、ピーク時にはアプリケーションの新しいインスタンスをオンラインにし、必要がない時期には処理能力と容量を低い水準に戻すことができます。このように、Azure でアプリケーションを適切に設計および管理すれば、コストを必要な分だけに抑えることができます。

  • マルチテナント: サービス プロバイダーが Azure を使用すると、ユーザー数にかかわらず、アプリケーション サービスを同じインフラストラクチャ上でさまざまな方法で提供できるので、運用コストを最小限に抑えることができます。

  • アプリケーションの作業に専念する必要がある: サービス プロバイダーの場合は特に、インフラストラクチャの保守よりも、アプリケーションや機能の開発に集中的にリソースを投入することが求められます。Azure を使用すると、オンプレミスや従来のサーバー ホスト型のアプリケーションをホストするインフラストラクチャで必要となる管理オーバーヘッドの多くが不要になり、アプリケーションや機能の開発にリソースを集中的に投入することができます。

  • インフラストラクチャのリソース所要量を最小限にする: Azure の特長である弾力的なスケーリングを活用するようにアプリケーションを設計すると、ロールやリソースのインスタンスも、必要な分だけ割り当てることが可能になります。ハードウェアへの事前の投資も、ピーク時の負荷に対応できるサーバーを使用率が低いときに保持しておくことも必要ありません。

従来の PaaS (Platform as a Service) の利点に加え、Azure では仮想マシンをホストすることもできます。これらの仮想マシンでは、Azure でサポートされる任意のオペレーティング システムを実行することができ、オンプレミスの場合と同じ方法でアプリケーションを実行できます。サポートされるオペレーティング システムの一覧については、「Azure の仮想マシンの概要」を参照してください。これらの仮想マシンは、Web ロールやワーカー ロールのインスタンス、およびその他の Azure コンポーネントと共に、大規模なアプリケーションのアーキテクチャの一部として構成することもできます。仮想マシンを使用すると、他の方法では簡単には移植できないサービスやアプリケーションも Azure に移植することができます。詳細については、「Migration with Azure Virtual Machines」を参照してください。

分析と設計のフェーズでは、Azure への移動によって高い効果が得られるアプリケーションを特定します。その後、Azure の実装の設計と実装の計画を開始します。このフェーズでは、アーキテクチャの大まかな設計とタイムラインを計画します。

計画時に考慮する主な要素の一部を次に示します。

  • 現在の課題の特定: 計画段階で特定する必要がある、アーキテクチャの見直しが必要な課題の例を次に示します。

    • アプリケーション コンポーネントのパフォーマンスが現在の負荷と現在のアーキテクチャにおいて標準に達していない: たとえば、SQL クエリのパフォーマンスが満足のいくものでない場合は、移行や設計の見直しを行う前にチューニングを行う必要があります。また、アプリケーション層のコンポーネントの再設計やスケールアウトを検討してください。

    • 弾力的スケーリングの要件の特定: アプリケーションを機能単位に分解してこれらの単位が個別に拡張可能で互いに独立して実行可能となるようにするにはどうすればよいかを特定します。

    • 不均一な負荷のパターン: 不均一な負荷のパターンを特定し、ピーク時にはスケールアウトで対応できるようにアプリケーションを設計します。ピーク時から要求が少ない時期までの段階的なスケールアウトの管理方法について計画する必要があります。

    • 成長予測: 多くの場合、成長予測は、IT 部門がパラダイム変更を検討する最初のきっかけとなります。成長予測に対応するソリューションとしてスケールアウトを使用できる状況を特定しておきます。成長予測は、特定のデータ ウェアハウスを中心とするアプリケーションのパラダイムを大規模なデータ分析に切り替えるなど、パラダイムの変更を検討する必要があることを示す指標にもなります。計画の段階でそれらの選択肢を検討しておく必要があります。設計と実装の段階に進むまではソリューションを確定できないことに注意してください。初回移行時またはそれ以降の適切な時点で評価できるように、それらの代替計画や決定要因をまとめておく必要があります。

  • 技術的な要件の特定: アプリケーションのコンポーネントごとに、ピーク時とオフピーク時の両方の要件を確認します。その後、各コンポーネントの規模について検討します。スケーリングを実行できるかどうかやそのメカニズムはコンポーネントごとに異なる可能性があります。技術的な要件はパフォーマンスだけとは限りません。移行を計画するときは、たとえば、高可用性と災害復旧の要件やネットワークの最大待機時間の要件を確認して、Azure を使用した場合と比較する必要があります。技術的な要件の例を次にいくつか示します。

    • リレーショナル ストレージの使用: リレーショナル データベースに格納されているデータを調べます。実質的なトランザクション データとリレーショナル データ、または実際にトランザクション処理が必要なデータは、リレーショナル ストレージに格納する必要があります。Azure SQL データベース (SQL データベース) または仮想マシンで実行されている SQL Server を使用して、この種のデータを格納することができます。それ以外の種類のデータは、Azure テーブル、Azure BLOB ストレージ、または Azure ドライブに効率的に格納できます。データの各部について、必要なストレージの種類をそれぞれ特定することをお勧めします。

    • リレーショナル データ ストレージの選択: SQL データベースを使用するか、Azure 仮想マシンで実行される SQL Server を使用するかを決める要因はさまざまです。高可用性、負荷分散、および透過的なフェールオーバーの管理オーバーヘッドを回避するには、SQL データベースが適しています。ただし、アプリケーションの移行中の中間の状態や、SQL データベースでまだ機能を利用できない特殊な状況など、Azure の仮想マシンで実行されている SQL Server の方が適している場合もあります。どちらを使用するかは、状況とソリューションに応じて判断します。この判断を行う際のいくつかの注意点を次に示します。

      • データベース サイズ: Azure SQL データベースの現在のサイズの上限は、5 GB (Web Edition データベースの場合) または 150 GB (Business Edition データベースの場合) です。データベースの容量を拡張するには、スケールアウト方法の 1 つを使用します。Azure のスケールアウト方法については、「Windows Azure SQL データベースのスケール アウト」を参照してください。使用できるデータベースのエディションとサイズに関する最新情報については、「Azure SQL データベースのアカウントと課金」を参照してください。

      • データベースの数: 既定では、SQL データベースはサブスクリプションごとに最大で 6 つのサーバー、SQL データベース サーバーごとに最大で 150 のデータベース (master データベースを含む) をサポートします。この制限に対する拡張も可能です。詳細については、Microsoft Online Services カスタマー ポータルでカスタマー サポート担当者にお問い合わせください。

      • 複数のデータベースにまたがるクエリ: 現在、SQL データベースでは、複数のデータベースにまたがる結合などの、複数のデータベースにまたがるクエリはサポートされていません。複数のデータベースのデータを必要とする結合を SQL データベースで使用する場合は、ロジックをアプリケーションのアプリケーション層で実行する必要があります。

      • 共通言語ランタイム (CLR) のオブジェクト: 現在、SQL データベースでは、CLR のストアド プロシージャ、集計、トリガー、関数はサポートされていません。ストアド プロシージャ、トリガー、または関数を SQL データベースで実行するには、Transact-SQL に移植する必要があります。データベース層の Transact-SQL で実行できない複雑なロジックや操作 (集計など) は、アプリケーション層に移動する必要があります。このような作業はワーカー ロールで実行できます。

      • データ型: SQL データベースでは、SQL Server の一部のシステム データ型がサポートされません。最新情報については、MSDN ライブラリの「Data Types (SQL Database)」を参照してください。

      • レプリケーション: トランザクション レプリケーションやマージ レプリケーションなどのタイプのレプリケーションは、SQL データベースでは使用できません。それらの種類のレプリケーションは、Azure の仮想マシンで実行されている SQL Server で設定して実行できます。SQL データベース インスタンス間のデータの同期には SQL データ同期を使用できます。ただし、SQL データ同期サービスは、トランザクションの一貫性や複雑な競合解決が求められる場合には適さないことがあります。警告: SQL データ同期は現在プレビュー版としてのみ公開されており、その目的は今後のリリースのための製品フィードバックのみであるため、実稼働環境では使用しないでください。

      • フルテキスト検索: 現在、Azure SQL データベースでは、フルテキスト検索はサポートされていません。アプリケーションで SQL Server テーブルの文字データに対するフルテキスト クエリを実行する場合は、データベースを Azure 仮想マシン内の SQL Server に移行することを検討してください。Azure VM 内の SQL Server の詳細については、「Azure の仮想マシン内の SQL Server への移行」を参照してください。

      • ライセンス: SQL データベースの料金は月額制で、選択したデータベースのサイズに応じて課金されます。Azure の仮想マシンで SQL Server を実行する場合はライセンスが必要です。

      • ログインとセキュリティ: Windows 認証 (統合セキュリティ) は、SQL データベースではサポートされませんが、Azure の仮想マシンで実行されている SQL Server では使用できます。SQL データベースのセキュリティのガイドラインと制限事項の詳細については、「Azure SQL データベースのセキュリティのガイドラインと制限事項」を参照してください。

  • ログインおよびユーザーのセキュリティ: Azure のネットワーク機能が強化され、オンプレミスのネットワークの Active Directory ドメインを Azure まで拡張できるようになりました。詳細については、「Migration with Azure Virtual Machines」を参照してください。SQL データベースのセキュリティ管理の詳細については、「Azure SQL データベースにおけるデータベースとログインの管理」を参照してください。

  • アプリケーションの機能的分解: アプリケーションをどのように機能単位に分割してそれぞれを別の Azure ロールまたは仮想マシンで実行できるかを特定します。このようにすることで、規模に柔軟に対応できるようになり、クラウド コンピューティングに適さないアプリケーションをハイブリッド アプリケーションにできる場合があります。

  • Payment Card Industry (PCI) などの規制上の要件: アプリケーションまたはコンポーネントを Azure に移動する前に、必要となる認定や要件の最新情報を確認してください。PCI 準拠などの要件がある場合は、Azure に移行する対象からアプリケーションやデータベースの一部を除外し、ハイブリッド アプリケーションを実行することができます。これにより、ほとんどのコンポーネントで Azure とクラウド コンピューティングを活用すると同時に、データやアプリケーションの各部に求められる厳格に制度化された制御と準拠も可能になります。

  • Azure Platform でホストできない主なコンポーネント: コンポーネントやデータ タイプの中には、懸念が理由でパブリック クラウドではホストできないものがあります。それらのコンポーネントを特定し、ハイブリッド アプリケーションの使用を検討します。ハイブリッド アーキテクチャを使用すると、一部のコンポーネントを Azure でホストして Azure とクラウド コンピューティングを最大限に活用できます。また、データやアプリケーションの各部に求められる厳格に制度化された制御と準拠も可能になります。

移行の範囲を定義すると、移行計画の各手順で実行する作業量も明確になります。アプリケーションとデータの各コンポーネントについて、開発、テスト、および移行に必要な時間とリソースを見積もります。アプリケーションの機能を分解する場合は、それらの分解されたコンポーネントを並行して開発することで、規模に柔軟に対応できるコンポーネントを作成します。

機能やパフォーマンスのテストなどのプロジェクトのマイルストーンを決めて、移行計画のリリース日を設定します。Azure に移行する各種のコンポーネントの準備や、コンポーネントを Azure の Web ロールやワーカー ロールに移動する準備など、一連の手順と繰り返しによって移行を進めることができます。

開発と移行のタイムラインを設定するときは、その期間の成長を考慮し、既存のアプリケーションやインフラストラクチャに対する必要な処理を判断します。このような計画を行うことで、移行が完了するまでの既存のシステムの運用が可能になります。この中間計画をまとめるときは、現在の問題点を特定し、継続的な運用のために必要な処理や、暫定のインフラストラクチャで運用を継続できる範囲を特定します。また、継続的な運用のために必要な可能性がある手順を特定します。これらの手順は、特定のアプリケーションの特性に応じて SQL クエリのチューニングや Web サーバーの追加を行うなど、簡単な処理の場合がほとんどです。さらに、想定を超える急速な成長や予期しない急増に備えて代替計画を用意しておきます。代替計画をまとめるときは、Azure の仮想マシンにスケールアウトすることで急激な増加や成長に対応できないかどうかを検討します。これにより、追加のハードウェア投資なしでそれらの状況に対応できる場合があります。

移行計画には、包括的な機能テストとロード テストの計画を必ず含めるようにしてください。ここでは、テスト方法については説明しません。テストを実行する際の重要な注意点の一部を次に示します。

  • テスト スクリプトを自動化する

  • アプリケーションのすべての層とコンポーネントをテストする

  • 操作の割合をシステムでの実際の割合と同じにしてテストする

  • 想定される最大使用率またはそれ以上の水準までテストする

テストの構築と実行にかかる時間だけでなく、テストで見つかった問題を解決するのにかかる時間も考慮することをお勧めします。

ビジネス要件と技術的な要件を定義する際、移行を正常に実行するために必要なリソースを特定します。移行には次のようなリソースが必要になる可能性があります。リソースを特定するときは、主にこれらの 3 つについて確認します。

  • 人材: アプリケーションを正常に移行するために、追加のスキルを備えた従業員の増員が必要になる場合があります。また、移行後に技術スタッフの役割が変わり、新しいスキルが必要になることがあります。たとえば、ログイン、アクセス レベル、サービス レベル、およびスケール レベルを管理するアカウント管理者やサービス管理者の役割を検討してください。

  • ツール: Azure アプリケーションの開発、テスト、およびデプロイに必要なツールを特定します。詳細については、「Azure Tools for Microsoft Visual Studio」および「Azure SQL データベースのツールとユーティリティのサポート」を参照してください。

  • コンサルティング: アプリケーションを移行するために特定分野の専門家が必要になることがあります。移行の専門家に相談すると、よくある落とし穴を回避して時間やコストを大幅に削減できることがあります。

小規模なアプリケーションであれば、Azure Management Portal で Azure の配置を十分に管理できます。Azure Management Portal にログインして、インスタンス ロール数の変更や SQL データベース インスタンスの管理など、配置やアプリケーションの管理を行うことができます。ただし、複雑なアプリケーションや顧客にサービスを提供するアプリケーションの場合は、Azure Management Portal だけでは管理できないことがあります。

Azure では、Azure でホストされるアプリケーションや VM をプログラムで管理できるように REST API を公開しています。これらを使用すると、Azure ストレージのプロビジョニングや使用も可能です。管理インターフェイスを記述することで、Azure 環境のスケーリングや監視に対応できます。移行計画には、カスタムのインターフェイスやオートメーションも管理する必要がある場合は特に、移行後のアプリケーションの管理に関する計画を含める必要があります。

Azure の配置の管理に使用できる REST API の詳細については、「Azure の API リファレンス」を参照してください。

関連項目

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