Windows Azure

[アーティクル]
12/20/2016

アプリケーションを Windows Azure に移行する

ライフスタイルの専門家は、新居への引っ越しは人生の中で最もストレスの多い出来事の 1 つだと言うかもしれませんが、アプリケーションを新しいプラットフォームに移行する仕事とどちらかを選択しなければならないとしたら、ほとんどの人はためらうことなく中国に引っ越す準備に取り掛かるでしょう。ただし、ありがたいことに、アプリケーションを Windows Azure に移行するのは楽な仕事です。

何年もの間、マイクロソフトは世界中のデータセンターでスケーラビリティの高いアプリケーションを構築してきました。これらのアプリケーションは、世界中に行き届き、可用性が高く、ユーザーに高度な機能を提供しています。Windows Azure は、データセンターと同じインフラストラクチャで独自のアプリケーションを展開できるようにし、対応する機能で管理に必要な労力を削減し、パフォーマンスを最大限に引き出してコストを最小限に抑えます。

もちろん、長年アプリケーションをサードパーティのホスティング企業にアウトソーシングしているユーザーもいます。アウトソーシングには、自社のアプリケーションをインストールして実行するために、リモートデータセンターのラックスペースやサーバーを借りたり、単に Web サーバーのスペースや、ホスティング企業のデータベースを借りたりすることも含まれます。いずれにせよ、多くの場合、利用できる機能の範囲が制限されます。通常、Windows Azure では標準として含まれる認証メカニズム、メッセージキューイング、トラフィック管理、データ同期などの周辺サービスは、アウトソーシングには含まれません。

このような機能はすべて Windows Azure へのアプリケーション移行を非常に複雑にするように思えますが、時間をかけて何が必要なのかを考え、利用できる機能を調べれば、Windows Azure への移行は迅速かつ比較的簡単に行えます。オプションを理解して適切に判断できるようにするため、マイクロソフトの patterns & practices グループは最近 Windows Azure 移行ガイドの更新版として『Microsoft Windows Azure プラットフォームでのクラウドへのアプリケーションの移行』(msdn.microsoft.com/library/ff728592) を公開しています。

このガイドでは、アプリケーションを Windows Azure に移行するための幅広いシナリオを取り上げています。ここからは、これらのシナリオを調べて、判断が必要な箇所を確認し、適切な選択を行うためにガイドで示されている実用的で役立つアドバイスを紹介します。ガイドではいくぶん不自然な複数手順の移行プロセスに従っており、ほとんどの場合、そのすべてに従うことはありませんが、このアプローチでは大半のオプションを例を挙げて紹介し、独自のアプリケーションで役立つと思われる Windows Azure の機能を示しています。図 1 はガイドからの引用で、オンプレミスのデータセンターから Windows Azure にアプリケーションを移行する際に従う移行経路の概念図です。

A Conceptual Map of Some of the Possible Migration Paths in Windows Azure
図 1 Windows Azure の可能性のある移行経路の概念図

インフラストラクチャか、プラットフォームホスティングか

図から確認できるように、Windows Azure に移行する際には、まず、サービスとしてのインフラストラクチャ (IaaS: Infrastructure as a Service) とサービスとしてのプラットフォーム (PaaS: Platform as a Service) のどちらの経路をたどるかを決めます。

その名が示すように、IaaS のアプローチでは、選択した OS、サービス、およびアプリケーションをインストールするためのランタイムインフラストラクチャ (仮想サーバーとネットワーク接続など) が提供されます。実際には、サーバーを選択してマイクロソフトデータセンターで運用するだけです。Windows Azure では、(Windows Server、Linux などから) 選択できる幅広い事前インストール済み OS が提供され、Windows Azure Active Directory による認証、Windows Azure ストレージキューやサービスバスを使ったメッセージング、トラフィックマネージャーによるアプリケーションのグローバルルーティングなどの周辺サービスをそのまま利用できます。

PaaS のアプローチを採用すると、マイクロソフトが OS とランタイムプラットフォームを代行して管理できるようになります。Windows Azure Web サイトは、シンプルな管理と展開の機能を備えた、Web アプリケーションや Web サイト向けの使いやすいホスティングプラットフォームを提供し、多くのソース管理システムと直接統合でき、幅広いプログラミング言語をサポートします。さまざまな種類のロールを混在させて実行する機能やキャッシュを直接統合する機能など、プラットフォームを細かく制御する場合は、クラウドサービスのアプローチを選択できます。これにより、Web ロールと Worker ロールを個別に展開でき、幅広い構成オプションが提供され、展開環境のバージョンを管理して段階的に適合させていくことができます。

後半で説明するように、IaaS と PaaS のどちらを選択してもアプリケーションコードが制限を受けることはありません。IaaS の経路をたどる場合、SQL Server や MySQL などのデータベースを事前にインストールした Windows Azure バーチャルマシン (VM) の展開を選択できます。一方、PaaS の経路をたどる場合、Windows Azure では Windows Azure SQL データベースというホスト型のデータベースメカニズムが提供されます。このデータベースは、実際にはオンプレミスの SQL Server とほとんど同じ方法で使用できるホスト型の SQL Server インスタンスです。

IaaS でクラウドを利用する

アプリケーションをホストするために IaaS のアプローチを使用すると、いくつか注目すべきメリットがあります。たとえば、アプリケーションコードに変更を加えなくてもクラウド内の VM に移行でき、仮想ネットワークを通じて内部ネットワークとドメインに接続して、テスト、展開、管理、および監視のシステムはすべてそれまでと同様に動作し続けます。

実際には、データセンターのイーサネットケーブルを Windows Azure へのインターネット接続に置き換えるだけです。Windows Azure 仮想ネットワークは、標準の仮想プライベートネットワーク (VPN) ルーターを使って、クラウドで構成するネットワークにオンプレミスのネットワークを接続し、オンプレミスの場合と同様に内部ネットワーク IP アドレスを使用できるようにします。もちろん、接続には追加の待ち時間が生じるため、不定期におきる一時的な接続の失敗にどのように対処するかを考える必要がありますが、ハードウェア、インフラストラクチャ、および OS を管理して更新する必要はありません (多種多様な操作で一時的な接続の失敗に対処するには、Microsoft Transient Fault Handling Application Block の使用を検討します。詳細については (msdn.microsoft.com/library/hh680934(PandP.50)、英語) を参照してください)。

Windows Azure VM を使用する IaaS のアプローチは、ソースコードが見つからなかったり、(サードパーティ製アプリケーションを利用する場合など) アプリケーションを変更できない場合にソフトウェアやサービスを実行する必要があるときに最適です。OS や通常のサービスを標準構成以外にする必要がある場合や、ファイルとリソースに一連の特定のアクセス許可を設定する場合でも適切に機能します。

テストと展開の点では、開発チームが既存のプロセスとの違いに気付くことはないでしょう。オンプレミスの開発コンピューターとビルドサーバーは、Windows Azure のテスト環境と運用環境に展開でき、テストサーバーとビルドサーバーをクラウド内に配置することもできます。図 2 は、ガイドに含まれている図に基づいており、テスト用とライブアプリケーション用の 2 つの個別の Windows Azure サブスクリプションを使って、オンプレミスとクラウドでホストされるテスト環境の両方を含むテストと展開の構成例を示しています。

Overview of a Possible Development, Test and Deployment Mechanism
図 2 可能性のある開発、テスト、および展開のメカニズムの概要

そのため、Windows Azure IaaS アプローチを選択しているときに唯一実際に異なる点は、経費がかかる空調を備えた自社のサーバールームでアプリケーションを運用することも、リソースを消費したりインターネット接続の帯域幅を必要とすることもありません。代わりに、アプリケーションはマイクロソフトデータセンターで運用されるため、VM への変更は元のイメージのバックアップストレージに保存され、信頼性の高い常時接続が提供され、アプリケーションが常に使用可能であることがランタイムプラットフォームによって保証されます。

また、VM を幅広いサイズから選択できます。必要に応じて実行中のインスタンスを更新できます。アプリケーション固有のニーズに合わせて OS とそのサービスを構成できます。負荷の変化に対応してインスタンスを追加で展開できます。別のデータセンターの展開への自動ルーティングを設定して世界中のユーザーの可用性を最大に高め、応答時間を最小限に抑えることもできます。

PaaS を使って管理を簡単にする

OS を自分で管理するのを望まない場合は、PaaS のアプローチを選択できます。このアプローチによって、ランタイムプラットフォームを構成するチャンスをいくつか放棄することになりますが、マイクロソフトがサーバーの管理、OS の更新、および修正プログラムの適用を行うため、管理作業と管理コストが削減されます。ユーザーは、アプリケーションコードと周辺サービスとの相互作用に専念できます。

Web サイトや Web アプリケーションを Windows Azure に移行する場合は、Windows Azure Web サイトに展開するのが最も簡単です。この場合、アプリケーションに必要な変更は、あったとしてもごくわずかです。Microsoft Team Foundation Server (TFS) や GitHub などの他のソースコードリポジトリシステムから展開できます。ニーズとホスティング予算に応じて共有 Web サーバーまたは予約インスタンスでホストして、パフォーマンスを確保し、需要を満たすインスタンスの数を管理できます。

また、展開のバージョン管理とアプリケーションのステージングを行う組み込みのメカニズムと、アプリケーションのパーツを別々にスケール変換する自由が必要な場合は、Windows Azure クラウドサービスの Web ロールと Worker ロールを使用してアプリケーションをホストできます。バックグラウンドタスクを Worker ロールに移行し、UI を Web ロールに配置することで、アプリケーションの負荷のバランスを取り、非同期バックグラウンド処理を実行し、それぞれの適切な数のインスタンスを実行することでロールの種類ごとに別々にスケール変換できます。

(事前に定義されたスケジュールでクラウドサービス展開のロールに自動スケール変換を実装するか、サーバー負荷の変化などのランタイムイベントに応答するには、マイクロソフトの Autoscaling Application Block の使用を検討します。詳細については、(msdn.microsoft.com/library/hh680892(PandP.50)、英語) を参照してください)。

Web ロールと Worker ロールを接続するには、通常、Windows Azure ストレージクエリまたは Windows Azure サービスバスキューを使用して、データをメッセージとして受け渡します (サービスバスキューの方が大きなサイズのメッセージをサポートし、認証とアクセス制御の機能が組み込まれています)。また、メッセージングを使うと、要求/応答、"開始したら後は忘れてよい" (Fire and Forget)、遅延書き込みなどの標準のメッセージングとストレージのパターンを使用できるようになります。アプリケーションがサービス指向アーキテクチャ (SOA) の設計に従うコンポーネントとして構築されている場合、Windows Azure クラウドサービスへの移行は比較的簡単です。

当然、Web ロールと Worker ロールを使用する場合は、アプリケーションのリファクタリングが必要になることがあります。ただし、多くの場合、それほど面倒ではなく、中核となるビジネスロジックやプレゼンテーションコードには影響しません。たとえば、ASP.NET MVC アプリケーションは Windows Azure に移行しても適切に機能し、オンプレミスで実行する場合や IaaS のアプローチを使って VM に展開する場合とまったく同じ方法で SQL Server などのデータストアにアクセスできます。

Windows Azure クラウドサービスへの移行は、特にコードのリファクタリングを実行する必要がある場合は、認証と承認のメカニズムを更新するチャンスでもあります。最近のアプリケーションは、フェデレーション ID やシングルサインオン (SSO) などのクレームベースの認証メカニズムをますます使用するようになっています。

この種のメカニズムによって、ユーザーは特定のアプリケーション固有の資格情報を必要としないで、幅広い既存の資格情報を使用してサインオンでき、複数のアプリケーションや Web サイトにアクセスする際のサインオンが 1 回で済むようになります。Windows Azure Active Directory のアクセス制御機能は、Windows Identity Framework (WIF) と連携して、クレームベースの認証とフェデレーション ID を簡単に実装できるようにします。図 3 は、ガイドに含まれる図に基づいており、Adatum という架空企業の a-Expense アプリケーションの例を示しています。ここでは、独自の Active Directory でユーザーを認証し、アクセスを許可するためにアプリケーションに提示するトークンが発行されます。

Adopting a Claims-Based Authentication System
図 3 クレームベースの認証システムを採用する

クレームベースの認証の詳細については、patterns & practices の関連記事、「クレームベースの ID とアクセス制御のガイド」(msdn.microsoft.com/library/ff423674、英語) を参照してください。

データの格納場所

ほとんどすべてのビジネスアプリケーションがデータを使用し、多くの場合、このデータは SQL Server や別のサプライヤーのリレーショナルデータベース管理システム (RDBMS) などのデータベースに格納されます。リレーショナルデータベースを使用するアプリケーションを移行する場合の代表的なシナリオは、データベースサーバーをホストする Windows Azure VM を展開する方法です (Windows Azure は SQL Server または MySQL を含む事前構成済みの VM を提供します)。また、Windows または Linux で実行するほぼすべての種類のデータストアを、Windows Azure で実行する VM にインストールできます。

データベースとアプリケーションがデータセンターに配置されている場合とまったく同様に、クラウドでホストされたアプリケーションからクラウドでホストされたデータベースに接続します。ただし、これは Windows Azure で利用できるオプションの 1 つにすぎません。多くの場合、アプリケーションのデータをクラウドに展開するか、オンプレミスに保持して、仮想ネットワークまたはメッセージング経由でデータベースサーバーと通信するかを決める必要があります。クラウドを選択する場合、IaaS または PaaS (SQL データベース) のどちらの経路をたどるかも決める必要があります。

Command Query Responsibility Segregation (CQRS) パターンは、通常メッセージングを使って、データの更新とクエリの結果をアプリケーションのコンポーネント間で通信するため、Windows Azure はこのために使用できる 2 つのキューイングメカニズムをアプリケーションに提供します。ただし、標準データアクセスの場合、アプリケーションとデータベース間にインターネットなどのネットワークが介在すると、遅延やその後のパフォーマンスの低下を引き起こすことがあります。状況や法的要件によりオンプレミスデータベースが必要な場合は、このような遅延を軽減するのに Windows Azure キャッシュが役に立ちます (CQRS パターンの詳細については、関連する patterns & practices のガイド、「CQRS の旅」(msdn.microsoft.com/library/jj554200、英語) を参照してください)。

Windows Azure SQL データベースは、SQL Server を使用する既存のアプリケーションを移行する際の汎用データストレージに最適なソリューションです。コードが SQL Server の高度な機能 (フリーテキスト検索、XML 処理機能、CLR のプログラミング能力を必要とするプロシージャ、SQL Server Service Broker を利用する分散クエリなど) を必要としない限り、既存のアプリケーションは変更しなくても動作します。

Windows Azure SQL データベースは、通常量のデータのみを格納する必要がある場合は、経費の大幅な削減になります。ただし、きわめて大量のデータや多数のデータベースに展開する必要がある場合は、VM でホストされるデータベースサーバーを使用することが適切なソリューションになります。適切なサイズの VM を選択でき、複数の VM を使ってデータベースのフェールオーバーや共有データストアを実装することもできます。

データストレージとクエリには、リレーショナルデータベースシステムの機能では不十分な場合があります。たとえば、企業は多くの場合、Web サーバーログ、金融取引ファイル、ソーシャルメディア情報、医療データ、または通常は処理されないけれども、時折または将来のクエリで使用する可能性があるデータの種類を数ペタバイト所持しています。Windows Azure は、このようなシナリオのためだけに (オープンソースの Hadoop テクノロジに基づく) HDInsight サービスを提供します。詳細については、次の Web サイトを参照してください (hadooponazure.com、英語)。

テーブル、ブロブ、キュー、およびドライブ

Windows Azure は、リレーショナル SQL パラダイムに基づかないさまざまな種類のストレージも提供します。Windows Azure ストレージのテーブルとブロブを使ってアプリケーションデータを格納し、ストレージキューを使ってアプリケーションのコンポーネントと従来型のディスクベースのファイルシステムのように動作するストレージドライブの間でメッセージを受け渡すことができます。

Windows Azure ストレージのテーブルにはスキーマがなく、各行は値のプロパティバッグを含む 1 つのエンティティであるため、テーブルは各行に異なる種類のエンティティを持つことができます。これは、構造化された (列と行を持つ) データと半構造化されたデータに最適です。これに対して、Windows Azure ストレージブロブはドキュメント、バイナリデータ、XML ファイル、画像など、構造化されていないデータを格納するのに適しています。

Windows Azure ストレージも、VM でホストされるデータベースサーバーや SQL データベースを使用するよりも経費を大幅に削減できますが、既存のデータアクセスコードを書き直す必要が生じます。多くの場合、Windows Azure のテーブルとブロブは、Windows Azure で実行するためにアプリケーションをゼロから設計するときに有効です。ただし、アプリケーションに明確に区別されたデータアクセス層があり、これを Windows Azure のテーブルとブロブを使用するように設計された層と置き換えることができれば、リレーショナルデータベースの代わりに Windows Azure ストレージを使用するのはそれほど難しくありません。

すべてのクラウドベースのサービスと同様、ネットワークの一時的な問題や断続的で一時的なリソースの絞込みによって、初期接続要求が失敗することがあります。Transient Fault Handling Application Block (前述) を使用して、エラーを自動検出し、リレーショナルデータベース、Windows Azure ストレージなどのすべてのストレージ操作を再試行できます。これは、すべてのクラウドベースのアプリケーションに適したプラクティスで、Transient Fault Handling Application Block により実装が容易になります。

Worker ロールとバックグラウンドタスク

Windows Azure クラウドサービスが優れている点の 1 つは、バックグラウンド処理を実行するために設計された特殊な種類のロールのプロビジョニングです。Worker ロールは、アプリケーションの補助的な部分として使用するだけではなく、実際には Web サーバー (IIS) をインストールしない Web ロールです。ただし、代表的なのは Worker ロールの継続タスクを実行するシナリオで、Worker ロールにバックグラウンドでなんらかの操作を行うように指示するメッセージを Windows Azure キュー (またはサービスバスキュー) でリッスンします (図 4 参照)。

Passing Messages from a Web Role to a Worker Role
図 4 Web ロールから Worker ロールへのメッセージの受け渡し

この方法で非同期タスクとバックグラウンドタスクを分離することで、懸案事項の分離、単一責任などの多くのアプリケーション設計基本原則を実装できます。ロール間で情報やコマンドをメッセージとして渡すことで、SOA 原則を適用するのとほぼ同じ方法で、各ロールのカプセル化を支援し、依存関係を減らします。

たとえば、ガイドでは Adatum が Worker ロールを使用してユーザーがアップロードした領収書の画像を圧縮格納してストレージ領域を節約し、経費データを Adatum の支払い関連のアプリケーションにエクスポートする方法が説明されています。どちらのタスクも、キューに配置されたメッセージによって開始されます。メッセージには、個別のタスクに関連するデータが含まれています。

Windows Azure クラウドサービスのロールに展開するようにアプリケーションをリファクタリングする際、どのタスクを Worker ロールで実行するのが適しているかは多くの場合明らかです。バックグラウンドタスクをスケジュールに従って開始することもできるため、失敗または停止したタスクを再開するコードを含めている場合は、Worker ロールで複数のタスクを実行することでホスティングコストを最小限に抑えられます。Windows Azure は、ロールが失敗したときに検出して再開を試みますが、ロール内の個別のタスクが失敗したときは検出できません。

バックグラウンドタスクからのフィードバックや出力を処理する方法も検討が必要です。たとえば、UI が Worker ロールのタスクに送信する各メッセージをパッケージにすることで、ユーザーが送信する注文の詳細を格納するため、遅延書き込みパターンの使用が必要になる場合があります。Worker ロールは、キューからメッセージを読み取り、データベースに詳細を保存します。ただし、発注番号がストレージの時点でのみ生成される場合、Worker ロールがこの発注番号を Web ロールに返し、UI に表示されるようにするのは複雑になります。

Windows Azure のコスト

ここまでで見てきたように、今の時点ですべてを正確に把握していなくても、Windows Azure にはアプリケーションの要件を満たす幅広い機能とサービスが含まれています。世界中にあるどこかのデータセンターに展開し、幅広いストレージとスケーラビリティが高い機能を利用できます。しかし、Windows Azure でアプリケーションをライブにするコストは賄えるでしょうか。

ガイドの第 6 章「コストの計算方法」では、Adatum 社がいくつかコスト計算を行い、Windows Azure で a-Expense アプリケーションを運用した場合の概算経費を示しています。アプリケーションは、1 つの Web ロールと 1 つの Worker ロールを使用して、リレーショナルデータベースに約 20 GB のデータを格納し、Windows Azure ストレージに 120 GB の画像を格納する必要があるとします。現時点の価格では、Adatum 社はこれに年間約 3,000 ドルかかると想定しています。使用するリソースの多くを他のオンプレミスのアプリケーションと共有するため、Adatum 社は自社のデータセンターでアプリケーションを運用するコストを正確に見積もることはできませんが、Windows Azure の想定コストはかなり安価です。

さらにすばらしいことに、Enterprise Library Autoscaling Application Block などの自動スケール変換が行われるソリューションを導入することで、Adatum 社は就業時間内のみアプリケーションを運用できると計算していますが、ほとんどの経費が申請される各月末のみロールインスタンスを追加することで容量を倍増し、コストの総額を年間約 2,000 ドルに抑えています。そのうえ、SQL データベースや SQL Server の代わりに Windows Azure のテーブルとブロブを使用するようにアプリケーションを変更することで、さらに年間 750 ドル節約できると計算しています。

当然、アプリケーションに必要な容量や運用のスケジュールはそれぞれ異なり、アプリケーションで処理すべき負荷と、必要なストレージに応じて変化します。ただし、Windows Azure の利用コストが賄えることはわかります。Windows Azure への移行は、家族で新居に引っ越すよりもずっと簡単です。

詳細情報

patterns & practices のガイド、『Microsoft Windows Azure プラットフォームでのクラウドへのアプリケーションの移行』はこちら (msdn.microsoft.com/library/ff728592、英語) から参照できます。ガイドの PDF 版 (英語) は、こちら (microsoft.com/download/details.aspx?id=29252) からダウンロードできます。

patterns & practices の関連するガイドとフレームワークは以下のとおりです。

クラウド対応マルチテナントアプリケーションの開発: msdn.microsoft.com/library/ff966499
Windows Azure のクラウドにおけるハイブリッドアプリケーションの構築: msdn.microsoft.com/library/hh871440
クレームベースの ID およびアクセスコントロールガイド: msdn.microsoft.com/library/ff423674
Transient Fault Handling Application Block: msdn.microsoft.com/library/hh680934(PandP.50)
Autoscaling Application Block: msdn.microsoft.com/library/hh680892(PandP.50)

Windows Azure のホームページ (windowsazure.com) と Windows Azure デベロッパーセンター (https://msdn.microsoft.com/en-us/windowsazure/default) も併せてご覧ください。

Alex Homer は、ワシントン州レドモンドの Microsoft patterns & practices 部門に所属するテクニカルライターです。決して快適であるとは言えないシアトルの天候を避け、英国ダービシャーデールの美しい田園に囲まれた自宅で働いています。彼はブログ (blogs.msdn.com/alexhomer、英語) で、IT 業界に関するあれこれや、生活全般について書いています。

この記事のレビューに協力してくれた技術スタッフの Masashi Narumoto に心より感謝いたします。
Masashi Narumoto は、Patterns & Practices のシニアプログラムマネージャーです。彼は、Windows Azure ガイドのシリーズに取り組んでいて、現在はビッグデータに注目しています。これまで 20 年以上にわたって、特に小売、製造業界のさまざまなソリューションの開発とコンサルタントを行ってきました。彼のブログは https://blogs.msdn.com/masashi_narumoto (英語) で、Twitter での連絡先は @dragon119 (英語) です。