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

Azure クラウド サービスの開発に関する注意事項

更新日: 2014年6月

作成者: Selcin Turkarslan

校閲者: Tim Wieman、Valery Mizonov、Avilay Parekh、Paolo Salvatori、Steve Howard

アプリケーションを Microsoft Azure Cloud Services に移行する前に、サービスの詳細を確認しておくことをお勧めします。記事「Azure の概要」には、以下に関する情報があります。

  • Azure のコンポーネント。

  • 実行モデル。

  • データ管理。

  • ネットワーキング。

  • サポートされているプログラミングのソフトウェア開発キット (SDK) など。

この記事の目的は、Microsoft Azure Cloud Services を使用する Microsoft Azure アプリケーションの実装に関する概要を示すことです。移行シナリオは無数に存在します。このため、アプリケーションやユーザーに最も適した方法とソリューションを選択するようにしてください。

既存のアプリケーションを Azure に移行する大まかな手順は次のとおりです。

  • アプリケーションに最適なコンピューティング実行モデルを判断する (例: Cloud Services、Web Sites、Virtual Machines (VM) など)。「Azure の概要: 実行モデル」を参照してください。

  • Azure 固有の構成とカスタム コードを追加する。

  • Azure でデータを格納および管理する。

  • 既存のアプリケーションを Azure アプリケーションとして再パッケージ化する。

  • アプリケーションを Azure にデプロイする。

Microsoft Azure Cloud Services にデプロイされたアプリケーションには、アプリケーション コード、データ管理、構成設定が含まれています。クラウド用のアプリケーションを開発する場合も、一般的なアーキテクチャのパターンが適用されます。たとえば、開発者は分散環境における可用性、スケーラビリティ、信頼性、およびセキュリティに対応した設計にする必要があります。また、次の点についても考慮する必要があります。

  • サービス レベル アグリーメント (SLA)。

  • キャパシティ プランニング。

  • 顧客への課金。

  • 監査。

  • アプリケーション監視。

  • トラフィック分析。

  • コスト管理。

  • スケーリング - クラウド アプリケーションをスケールアップ、スケールダウン、スケールアウト、スケールインするタイミングと方法。

従来のプライベートなデータ センター環境でサービスを実行する場合は、ハードウェアの購入、設定、管理を各自で行う必要があります。Azure を使用すると、仮想化されたリソースを割り当てることで要求に応じて拡張できるアプリケーションを設計および構築することができます。一部のオンプレミス アプリケーションは、ごくわずかな変更で、またはまったく変更せずに Azure で実行できます。ただし、ほとんどのアプリケーションはクラウド用の設計とアーキテクチャにすることで大きな恩恵を受けることができます。Azure を最大限に活用するには、Azure に移行する前に、複数のロールを使用するようアプリケーションを変更することをお勧めします。

たとえば、従来のデータ センターでホストされる Web サービスやアプリケーションは、複数の機能が 1 つのアプリケーションにまとめられることがよくありますが、スケーラビリティが得られない場合があります。また、多くの Web アプリケーションの永続的な状態がローカルのディスク ドライブに格納されており、Azure Cloud Services 環境では使用できません。既存の Web アプリケーションから Azure に移行する場合、クラウド コンピューティングのスケーラビリティと柔軟性を最大限に活用するには次の 2 つのオプションがあります。

Azure Cloud Services では、すべてのアプリケーションが 1 つ以上のロールとして実装されます。それぞれのロールに、アプリケーションの機能の一部を実行するために必要なコードと構成情報が格納されます。フロントエンド サービス、および Web ブラウザーなどの HTTP クライアントと直接やり取りするコードは、Web ロールです。Web ロールは、Microsoft の Web サーバーであるインターネット インフォメーション サービス (IIS) Web サーバーで動作します。ワーカー ロールでは、バックグラウンド処理とサポート タスクが実行されます。中間層のサービスは、通常、ワーカー ロールです。

各ロールには複数のインスタンスを含めることができます。各インスタンスは、そのロール用に作成された同じコードを実行します。ただし、各ロール インスタンスは Azure のデータ センター内の個別の仮想マシンに存在します。ロールのインスタンスで使用する VM のサイズは、ロールごとに指定することができます。詳細については、「クラウド サービスのサイズを構成する」を参照してください。

各ロールは、それぞれ機能が異なるだけでなく、アプリケーションのスケーリングの単位でもあります。たとえば、20 個の Web ロール インスタンスで多くのトラフィックを処理し、その後、5 つのワーカー ロール インスタンスだけで Web ロールの要求を非同期に処理することができます。単純な ASP.NET、PHP、Node.js のアプリケーションや Web サービスを作成するだけであれば、Web ロールのみでもかまいません。クラウド サービスの機能やパフォーマンスを詳しくテストすることをお勧めします。アプリケーションを実稼働環境にデプロイする前に、このようなテストを行うことで、最適なロール インスタンスの数や VM のサイズを特定できるようになります。クラウド サービスの概念の詳細については、Azure デベロッパー センターおよび Azure ドキュメント センターを参照してください。

Azure で提供されているストレージ オプションの利用を検討してください。これにより、アプリケーション ロジックが単純になり、クラウド サービスのパフォーマンスが向上します。アプリケーションの移行を計画するときは、各データ ストレージ オプションの制限について理解することが非常に重要です。また、クラウド サービスで使用するデータ ストレージ オプションを適切に選択する方法も知っておく必要があります。Azure で使用できるストレージ オプションの詳細については、「Azure のデータ管理サービスの概要」を参照してください。

また、Azure Caching Service を使用して、Azure アプリケーション向けのメモリベースの高速ストレージを提供することもできます。キャッシュを使用してバックエンド ソースからの情報を一時的に格納することで、パフォーマンスが向上します。キャッシュを使用すると、クラウドでのデータベース ストレージ アクセス トランザクションに関連するコストが削減されます。パフォーマンスを最大限に高めるには、次の 2 つの条件を満たすデータ センターにアプリケーションをデプロイします。

  • 大部分のクライアントからできるだけ近いこと。

  • ストレージ アカウントまたは Azure SQL Database インスタンスをホストしているデータ センターにできるだけ近いこと。

ただし、データやその格納場所に関して管轄の問題や法的な問題がある場合は、会社またはデータに近いデータ センターを選択することもできます。詳細については、「Azure SQL Database のパフォーマンスに関する考慮事項」を参照してください。

Azure Cloud Services の実装を開始する前に、まず Microsoft Azure サブスクリプションを購入する必要があります。詳細は、Microsoft Azure サイトをご覧ください。その後、開発環境を準備する必要があります。Microsoft では、.NET、Java、PHP、Node.js、Python、および Ruby 向けの言語固有の SDK を提供しています。サポートされるプログラミング言語とプラットフォームに関する最新情報については、Microsoft Azure ドキュメント センターを参照してください。また、Azure の SDK とツールのダウンロード センターから、Azure のすべてのクライアント ライブラリ、SDK、およびコマンド ライン ツールにアクセスできます。

Microsoft Azure では、Web サイトや Web アプリケーションをホストするための Azure Web Sites サービスを用意しています。Azure Web Sites は、Web アプリをすばやくデプロイしてスケーリングできる、完全に管理されたサービスとしてのプラットフォーム (PaaS) サービスです。詳細については、「Azure Web Sites」を参照してください。

異なるプラットフォームで動作するクライアント アプリケーションがリレーショナル データ ソースに接続できるように、Microsoft では ODBC を選択しています。これが、Azure SQL Database (SQL Database) に接続するネイティブのクライアント アプリケーション用の標準クライアント接続 API です。SQL Server Native Client OLE DB プロバイダーは、SQL Server 2012 を最後に廃止され、SQL Database ではサポートされません。

Windows または Azure でアプリケーションを作成するときは、SQL Server 用 .NET データ プロバイダーを使用します。または、SQL Server 2008 R2 以降に付属の SQL Server Native Client ODBC ドライバーを使用してください。アプリケーションの新規の開発や今後のバージョンの開発では ODBC を使用することをお勧めします。OLE DB を使用している既存のアプリケーションについては、将来的に ODBC に移行することをお勧めします。OLE DB アプリケーションを ODBC アプリケーションに変換する方法の詳細については、「OLE DB から ODBC への SQL Server アプリケーションの変換」を参照してください。OLE DB の廃止に関する ADO.NET チームからの説明については、「Microsoft SQL Server OLEDB プロバイダーの廃止予定のお知らせ」を参照してください。

他のアプリケーションと同様に、マルチテナントの分散クラウド環境における可用性、災害復旧、およびセキュリティに対応したアプリケーションを設計する必要があります。詳細については、「Azure SQL Database における高可用性と災害復旧」および「Windows Azure のセキュリティに関するガイダンス」を参照してください。セキュリティの要件については、Azure へのアプリケーションの配布準備をする前に、ソフトウェア開発ライフサイクルの初期の段階で対処することをお勧めします。

Azure でのアプリケーション開発の詳細については、「Azure アプリケーションの開発」および「フェールセーフ: 回復力のあるクラウド アーキテクチャに関するガイダンス」を参照してください。

Azure はマルチテナントに対応した動的に拡張できるクラウド上のプラットフォームです。このため、アプリケーションを設計するときは、クラウド固有の監視および診断方法について検討する必要があります。監視と診断については、ソフトウェア開発ライフサイクルの初期の段階で検討することをお勧めします。アプリケーションをクラウドにデプロイした後も既存の監視および診断方法で適切に対応できるかどうかを評価します。たとえば、アプリケーションのログ ファイルが大きい場合は、診断とログの設定の調整が必要になることがあります。調整を行うことで、詳細な分析のために、すぐに調べたりオンプレミス環境にダウンロードしたりできる小型のログ ファイルを生成できます。

Azure のトラブルシューティングに使用できるツールと方法を次にいくつか示します。

  • Azure 診断 (WAD): Azure サービスから操作データと診断データを収集します。Azure 診断では、次のようなさまざまなデータ ソースからの診断データがログに記録されます。

      • IIS ログ。

      • Windows 診断インフラストラクチャ ログ。

      • Windows イベント ログ。

      • パフォーマンス カウンター。

      • クラッシュ ダンプ。

      • カスタム エラー ログ。

      Azure 診断のログ記録間隔を設定できます。収集された情報は、分析用に Azure のテーブル ストレージと BLOB ストレージに保存されます。詳細については、「Azure 診断を使用したログ データの収集」を参照してください。

  • System Center の Azure 管理パック (MP): Azure 監視管理パックでは、Azure で実行しているアプリケーションの可用性とパフォーマンスを監視できます。詳細については、「Azure アプリケーションの監視パック ガイド」を参照してください。Azure 診断と System Center の Azure 管理パックを使用することをお勧めします。詳細については、「System Center 2012: プライベート クラウドとパブリック クラウドでのアプリケーションの管理」のビデオを参照してください。

  • Azure Storage Analytics: ログが記録され、Azure ストレージ アカウントのメトリック データを得ることができます。このデータを使用して、要求のトレース、使用傾向の分析、およびストレージ アカウントの問題の診断を行うことができます。詳細については、「Storage Analytics」を参照してください。

  • SQL Database の接続管理: アプリケーションに再試行ロジックを実装してエラー コードを処理します。詳細については、「Azure SQL Database のリソース管理」を参照してください。

  • Azure PowerShell コマンドレット: Azure クラウド サービスおよびデータ管理サービスの参照、構成、管理を PowerShell から直接行うことができます。これらのツールは、Azure サービスを使用するアプリケーションの開発やテストで役立ちます。詳細については、「Azure コマンドレット リファレンス」を参照してください。

  • "クラウド サービスの基礎" リファレンス ソリューション:このアプリケーションでは、データベースによって支援される Azure サービスの作成方法を具体的に示します。このデモは、Microsoft Azure CAT (Customer Advisory Team) がお客様との作業を通じて実地で学んだ教訓に基づいています。アプリケーションのテレメトリ データの収集と使用を含む、スケールアウト Azure アプリケーションの基本的な構成要素を説明しています。このリファレンス ソリューションは、Microsoft Azure でのクラウド サービスの基礎の Web ページに掲載されています。ガイダンスには TechNet Wiki (クラウド サービスの基礎の Wiki) が含まれ、詳細な記事があります。

他のアプリケーションと同様、Azure Cloud Services についても、実稼働環境にアップロードする前に詳細なテストが必要です。機能、エンドツーエンドの実行、パフォーマンス、スケーラビリティ、セキュリティなどをテストする必要があります。

詳しい手順については、「Azure アプリケーションの開発に関するトラブルシューティングのベスト プラクティス」を参照してください。その他の情報については、「Azure 診断を使用したログ データの収集」および「Azure アプリケーションのテスト、管理、監視、および最適化」を参照してください。

Azure には、既存のアプリケーションのクラウドへの統合やネットワーク トラフィックの管理に役立つさまざまなネットワーク機能が用意されています。Azure の主なネットワーク コンポーネントと接続コンポーネントを次に示します。

  • Azure ストレージ キュー: Azure ストレージ キューは、クライアントがアクセスする可能性のあるメッセージの格納に使用でき、ロール インスタンス間で信頼性の高いメッセージ処理を提供できます。詳細については、「.NET からキュー ストレージを使用する方法」および「ストレージ」を参照してください。

  • Azure Service Bus: Azure 内のサービス間の通信には、Azure Service Bus を使用することをお勧めします。また、オンプレミスのサーバーと Azure の統合を維持するには、Azure Service Bus を使用します。Service Bus には、アプリケーション層でのセキュリティで保護されたメッセージングやリレー機能が用意されています。Azure Service Bus が提供するクラウド ベースの通信インフラストラクチャでは、パブリック ネットワークのセキュリティで保護された一般的なメッセージング サービスがサポートされ、https://myhostname.servicebus.windows.net のような統一された簡単な名前空間が提供されます。Service Bus でサポートされるプログラミング モデルは、.NET API、REST API、および WCF です。詳細については、Service Bus ドキュメントの Web ページおよび「Azure キューと Service Bus キューの比較」を参照してください。

  • Azure Active Directory: クラウド ホスト型の Web サービスやエンド ユーザー アプリケーションに対しては、Azure Active Directory (AD) を使用して、スケールアウトした要求ベースのアクセス制御を行うことをお勧めします。Azure Active Directory は、ID 管理とアクセス管理用の包括的なクラウド ソリューションです。主要なディレクトリ サービス、高度な ID 管理機能、セキュリティ、アプリケーション アクセスの管理機能が統合されています。また、開発者は、Azure AD を ID 管理プラットフォームとして、一元化されたポリシーとルールを基に、開発したアプリケーションへのアクセス制御を行うことができます。このサービスは、Windows Identity Foundation (WIF) とも統合されます。詳細については、「Azure Active Directory アクセス制御を使用して Web ユーザーを認証する方法」および Azure Active Directory ドキュメントの Web ページを参照してください。

  • Azure Traffic Manager: Traffic Manager を使用すると、複数の Azure ホステッド サービス間で着信トラフィックを負荷分散できます。サービスが同一のデータセンターで実行されているか、世界各地のデータセンターで実行されているかに関係なくトラフィックを負荷分散できます。トラフィックを効果的に管理することで、アプリケーションのパフォーマンス、可用性、および回復性を高めることができます。詳細については、Traffic Manager ドキュメントの Web ページを参照してください。

  • Azure Content Delivery Network: Azure Content Delivery Network (CDN) は開発者向けのグローバルなコンテンツ キャッシュ ソリューションです。顧客に最も近い場所にコンテンツをキャッシュすることでアプリケーションの操作性を高めることができます。CDN では、Azure の BLOB とコンピューティング インスタンスの静的コンテンツ出力を戦略的に配置された場所にキャッシュします。これにより、ユーザーへのコンテンツ配信用に最大帯域幅を提供します。CDN による配信は、Azure Platform Management Portal を使用してコンテンツ プロバイダーに対して有効にすることができます。詳細については、Azure CDN ドキュメントの Web ページを参照してください。

  • Azure の仮想ネットワーク: Azure Virtual Network を使用すると、論理的に分離されたセクションを Azure 内に作成し、IPsec 接続を使用してオンプレミスのデータセンターまたは単一のクライアント コンピューターに安全に接続できます。Virtual Network を使用すると、Azure のスケーラブルなオンデマンドのインフラストラクチャを簡単に活用できます。それと同時に、Windows Server、メインフレーム、および UNIX で実行中のシステムを含むオンプレミスのシステムにあるデータおよびアプリケーションへの接続性を保ちます。詳細については、Virtual Network ドキュメントの Web ページを参照してください。

  • Azure ExpressRoute: Azure ExpressRoute を使用すると、Azure のデータセンターとオンプレミスまたはコロケーション環境にあるインフラストラクチャとの間にプライベート接続を作成することができます。ExpressRoute 接続は、パブリック インターネットを経由しません。インターネットを経由する一般的な接続に比べて、信頼性が高く、より高速で、待機時間が少なく、セキュリティが強固です。ExpressRoute を使用すると、ExpressRoute の場所 (Exchange プロバイダーの施設) にある Azure への接続を確立することも、既存の WAN ネットワーク (MPLS VPN など) から Azure への直接接続を確立することもできます。詳細については、「ExpressRoute の概要」および ExpressRoute ドキュメントの Web ページを参照してください。

詳細については、ネットワーク サービスの Web ページを参照してください。

クラウド サービスまたはアプリケーションの開発が完了したら、パッケージを作成し、アップロードして Azure にデプロイできます。配置シナリオは 4 種類あります。

  • 新規の配置

  • 構成の変更

  • コードの増分アップグレード

  • メジャー アップグレード

詳細については、「Cloud Services の管理方法」、「Azure でのデプロイの管理」、「サービスの管理」を参照してください。

1 つの Azure サブスクリプションで複数のデプロイメントを構成し、開発、テスト、QA、ステージングなどをサポートすることができます。1 つの Azure アカウントで複数のサブスクリプションへのアクセスを構成することもできます。このため、Azure アプリケーション用の開発環境とテスト環境をそれぞれのサブスクリプションで分けることができます。この場合は、サービスをテストのサブスクリプションにデプロイしてから実稼働のサブスクリプションにデプロイすることを検討してください。サービスの運用を開始する準備ができたら、実稼働環境に移行できます。実稼働のサブスクリプションにクラウド サービスを配置した後、継続的なテストにはステージング環境を使用できます。

Azure では、最新の需要に合わせてアプリケーションを自動的にスケールアップまたはスケールダウンし、コストを最小限に抑えるように構成できます。この機能を有効にするには、「自動スケール」のルールとスケジュールを使用します。詳細については、「アプリケーションの規模を設定する方法」を参照してください。

関連項目

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