Microsoft Azure の概要

Microsoft Azure は、パブリック クラウド向けの Microsoft のアプリケーション プラットフォームです。 この記事を読めば、クラウド コンピューティングに関する知識がまったくなくても、Azure の基礎を理解することができます。

この記事を読む方法

Azure のサービスは常に増え続けているため、そのすべてを理解するのは容易ではありません。 まずはこの記事で説明されている各種基本サービスを確認し、その後で追加サービスについて確認してください。 ユーザー自身では追加サービスを使用できないという意味ではありませんが、Azure 内で実行されているアプリケーションの中核を構成しているのは、基本サービスです。

フィードバックのご提供

お客様のフィードバックは重要です。 この記事によって Azure の概要を効率的にご理解いただけます。 ご理解いただけなかった場合は、ページ下部のコメント セクションでその旨をお知らせください。 期待されていた内容や記事の改善方法について詳しくお聞かせください。

Azure のコンポーネント

Azure では、管理ポータル内や、 Microsoft Azure のインフォグラフィック などのさまざまな視覚的な説明の中で、サービスをいくつかのカテゴリに分類しています。 管理ポータルは、Azure 内の大半のサービス (すべてではない) を管理するために使用するものです。

この記事では、 とある組織 を取り上げて、類似の機能に基づくサービスについて説明し、より大規模なサービスの一部である重要なサブサービスを取り上げます。

Azure コンポーネント
図: Azure には、Azure データセンターで実行される、インターネット経由でアクセスできるアプリケーション サービスが用意されている。

管理ポータル

Azure には、管理者が Azure の機能の大半にアクセスして管理できる、 管理ポータル と呼ばれる Web インターフェイスがあります。 マイクロソフトは通常、以前のポータルを廃止する前に、より新しい UI ポータルをベータ版としてリリースします。 より新しい UI ポータルは " Azure プレビュー ポータル" と呼ばれます。

両方のポータルが使用されている間は、重なり合う部分が多く、主要なサービスは両方のポータルに表示されます。 ただし、片方でしか利用できない機能も存在する可能性があります。 新しいサービスは新しいポータルに先に実装され、古いサービスと機能は古いポータルにしか存在しないという状況も考えられます。 一方のポータルで見つからない機能があったら、もう一方のポータルで探してみてください。

計算

クラウド プラットフォームで行われる最も基本的な項目に、アプリケーションの実行があります。 4 つの Azure コンピューティング モデルには、それぞれの役割があります。

必要に応じてこれらのテクノロジを単独で使用したり、組み合わせて使用したりすることで、アプリケーションに適した基盤を構築できます。 どのアプローチを選ぶかは、解決しようとしている問題によって異なります。

Azure Virtual Machines

Azure Virtual Machines ROBBCSIART_TEST
図: Azure Virtual Machines によってクラウド内の仮想マシン インスタンスをきめ細かく制御できる。

標準イメージと独自のイメージのどちらからでも、必要に応じて仮想マシンを作成できる機能は非常に便利です。 一般的にサービスとしてのインフラストラクチャ (IaaS) と呼ばれるこのアプローチは、Azure の Virtual Machines が提供する機能です。 図 2 は、仮想マシン (VM) の稼働方法と、VHD から仮想マシンを作成する方法を示しています。

VM を作成するには、使用する VHD と VM のサイズを指定します。 そして、VM を実行する料金を時間に応じてお支払いいただきます。 VHD を使用可能な状態に保持するための最小限のストレージ料金はかかりますが、分単位で実行した時間に対してだけ支払います。 Azure には、起動可能なオペレーティング システムを含むストック VHD ("イメージ" と呼ばれる) のギャラリーが用意されています。 これには、Windows Server と Linux、SQL Server、Oracle などマイクロソフトとパートナーが提供する多数のオプションが含まれます。 自由に VHD やイメージを作成した後、自分でそれらをアップロードできます。 データのみを含む VHD をアップロードすることも可能で、その後、実行中の VM からそれらにアクセスできます。

どこから提供された VHD でも、VM の実行中に加えたあらゆる変更内容を永続的に格納することができます。 次にその VHD から VM を作成するときには、保存した内容が取り込まれます。 仮想マシンを支える VHD は Azure Storage BLOB に格納されます。これについては後述します。 つまり、ハードウェアやディスクの障害によって VM が消失しないように保証するための冗長性が確保されます。 さらに、変更した VHD を Azure の外部にコピーしてローカルで実行することもできます。

アプリケーションは、以前にどのように作成されたか、またはゼロから作成することに決めたかに応じて、1 つ以上の仮想マシンで実行されます。

クラウド コンピューティングに対するこの一般的なアプローチを使用することで、さまざまな問題に対応できます。

Virtual Machines のシナリオ

  1. 開発/テスト - Microsoft Azure VM を使用して開発とテスト用に低価格のプラットフォームを作成し、必要がなくなった時点で停止できます。 さらに、どのような言語とライブラリを使用するアプリケーションでも作成して実行できます。 これらのアプリケーションでは、Azure が提供するあらゆるデータ管理オプションを使用できるだけでなく、使用する SQL Server や他の DBMS を選択して、1 つ以上の仮想マシン上で実行することもできます。
  2. アプリケーションの Azure への移行 (リフト アンド シフト) - "リフト アンド シフト" は、フォークリフトを使用して大きな物を移動するようにアプリケーションを移行することを指しています。 VHD をローカルのデータセンターから "リフト" (持ち上げ)、それを Azure に "シフト" (移動) して、そこで実行します。 通常は、他のシステムとの依存関係をなくすためにある程度の作業を行う必要があります。 作業が多すぎる場合は、代わりにオプション 3 を選択できます。
  3. データセンターの拡張 - Azure VM をオンプレミスのデータセンターの延長として使用して、SharePoint などのアプリケーションを実行することもできます。 これをサポートするため、Azure VM で Active Directory を実行して、クラウド内に Windows ドメインを作成することができます。 Azure Virtual Network (後述) を使用して、ローカル ネットワークと Azure 内のネットワークを相互接続することができます。

Web Apps

Azure Web Apps ROBBCSIART_TEST
図: Azure Web Apps では、基になる Web サーバーを管理しなくても、クラウド内で Web サイト アプリケーションを実行できる。

クラウドで行われる最も一般的なことの 1 つに、Web サイトと Web アプリケーションの実行があります。 Azure Virtual Machines でこれを実現できますが、この場合には 1 つ以上の VM と基になるオペレーティング システムをお客様が管理する必要があります。 Cloud Services Web ロールがこれを実行できますが、それらのデプロイと維持には引き続き管理作業が伴います。 Web サイトのみが必要で、その管理作業はだれかに任せたい場合はどうでしょうか。

これこそ、Web Apps が提供する機能です。 このコンピューティング モデルには、Microsoft Azure 管理ポータルおよび API を使用した、管理された Web 環境が用意されています。 既存の Web サイト アプリケーションを変更せずに Web Apps に移行することもできれば、クラウドに直接新しいサイトを作成することもできます。 Web サイトが稼働したら、インスタンスを動的に追加または削除し、Azure Web Apps で要求の負荷分散を行うことができます。 Azure Apps には、仮想マシン内で他の Web サイトと共に稼働する Shared オプションと、専用の VM でサイトを実行する Standard オプションが用意されています。 標準オプションは、必要に応じてインスタンスのサイズ (コンピューティング能力) を増強することもできます。

開発用には、.NET、PHP、Node.js、Java、Python に加え、リレーショナル ストレージのための SQL Database と MySQL (マイクロソフト パートナーである ClearDB 製) をサポートしています。 さらに、WordPress、Joomla、Drupal など、一般的なアプリケーションのサポートも多数組み込まれています。 パブリック クラウド内で Web サイトと Web アプリケーションを作成するための低価格でスケーラブル、広範な利便性を備えたプラットフォームを提供することが、その目的です。

Web Apps のシナリオ

Web Apps は、企業、開発者、および Web デザイン代理店のいずれにも役立つように設計されています。 企業にとっては、Web サイトのプレゼンスを実行するための、管理が簡単で、スケーラブルな、優れたセキュリティと可用性を備えたソリューションとして利用できます。 Web サイトを設定する必要がある場合には、まず、Azure Web Apps で開始し、使用できない機能が必要となったときに Cloud Services に進むやり方が最適です。 オプションの選択に役立つ、より多くの関連事項については、「コンピューティング」セクションの末尾を参照してください。

Cloud Services

Azure クラウド サービス
図: Azure Cloud Services では、サービスとしてのプラットフォーム (PaaS) 環境で、拡張性の高いカスタム コードを実行できる。

多数の同時ユーザーをサポートしながら、管理作業が少なく、停止することがないクラウド アプリケーションを作成したいとします。 たとえば、既存のソフトウェア ベンダーが、クラウドに自社製アプリケーションのうちの 1 つのバージョンを作成して、サービスとしてのソフトウェア (SaaS) を導入する場合や、 新興ベンダーとして、成長が期待されるコンシューマー アプリケーションを作成する場合が考えられます。 Azure 上に作成する場合は、どの実行モデルを使用しますか。

Azure Web Apps でもこのような Web アプリケーションを作成できますが、一部の制約があります。 たとえば、管理アクセス権がなければ、任意のソフトウェアをインストールできません。 Azure の Virtual Machines を使用すると、管理アクセス権を含む高い柔軟性が得られ、これを使用してスケーラブルなアプリケーションを作成できますが、信頼性と管理に関する多くの事項をお客様自身が処理する必要があります。 この場合に必要なのは、必要な制御性を提供する一方で、信頼性と管理に必要なほとんどの作業を処理するオプションです。

これはまさに Azure Cloud Services が提供する機能です。 このテクノロジは、信頼性が高くスケーラブルで管理作業の少ないアプリケーションをサポートするためのもので、一般的にサービスとしてのプラットフォーム (PaaS) と呼ばれるテクノロジです。 これを使用するには、C#、Java、PHP、Python、Node.js など、目的に合ったテクノロジを使用してアプリケーションを作成します。 次に、Windows Server のバージョンを実行する仮想マシン (インスタンスと呼ばれます) でコードを実行します。

しかし、これらの VM は Azure の Virtual Machines で作成する VM とは異なります。 まず、Azure が VM を管理し、オペレーティング システム パッチのインストールやパッチを適用した新しいイメージの自動ロールアウトなどの作業を行います これは、お客様のアプリケーションは Web ロールまたは worker ロール インスタンスで状態を維持せず、次のセクションで説明する Azure データ管理オプションの 1 つで維持する必要があることを意味します。 また、Azure は VM を監視し、障害が発生した VM を再起動します。 Cloud Services は、必要に応じて複数のインスタンスを自動的に作成するように設定できます。 これによって、使用量の増加に対処し、使用量が減少した場合は、余剰分を支払わずに済むように規模を縮小できます。

インスタンスの作成時に、Windows Server をベースとする 2 つのロールのいずれかを選択します。 この 2 つのロールの主な違いは、Web ロール インスタンスは IIS を実行しますが、Worker ロール インスタンスは IIS を実行しないことです。 しかし、どちらも同様に管理され、アプリケーションでは両方を使用することが一般的です。 たとえば、Web ロール インスタンスがユーザーからの要求を受信し、処理のために Worker ロール インスタンスに渡すことが考えられます。 アプリケーションの規模を拡大または縮小するために、Azure でいずれかのロールのインスタンスをさらに作成したり、既存のインスタンスを停止したりすることもできます。 また、Azure の Virtual Machines の場合と同様に、Web ロールまたは Worker ロールの各インスタンスも使用時間に応じて課金されます。

Cloud Services のシナリオ

Cloud Services は、Azure Web Apps が提供する以上にプラットフォームを厳密に制御する必要があるが、基になるオペレーティング システムを制御する必要はない場合に、大規模なスケールアウトをサポートするために適しています。

計算モデルの選択

Azure Web Apps、Cloud Services、および Virtual Machines の比較 に関するページに、コンピューティング モデルの選択方法について詳細が記載されています。

データ管理

アプリケーションにはデータが必要です。そして、アプリケーションが異なれば必要なデータも異なります。 このため、Azure にはデータの格納および管理を行うさまざまな方法が用意されています。 Azure には多数のストレージ オプションがありますが、すべて非常に耐久性の高いストレージを実現する目的で設計されています。 これらのオプションのいずれでも、常にデータの 3 つのコピーが Azure データセンターで同期した状態で保持されます。Azure で geo 冗長性を使用して 300 マイル以上離れた別のデータセンターにバックアップしている場合は、6 つのコピーが保持されます。

Virtual Machines 内

Azure Virtual Machines で作成した VM 内で SQL Server や他の DBMS を実行する機能については、既に説明しました。 このオプションはリレーショナル システムに限定されません。MongoDB や Cassandra などの NoSQL テクノロジも実行できることに注意してください。 自社のデータベース システムの実行は簡単で、その機能はマイクロソフトのデータセンターで行う場合と同じですが、その DBMS の管理作業を処理しなければなりません。 その他のオプションでは、Azure はより多くの、またはすべての管理作業を処理します。

作成またはアップロードした仮想マシンと追加のデータ ディスクの状態は、BLOB ストレージ (後述) によって支えられています。

Azure SQL Database

Azure Storage SQL Database

図: Azure SQL Database は、クラウド内で管理されたリレーショナル データベース サービスを提供する。

Azure には、リレーショナル ストレージのために SQL Database が用意されています。 名前に騙されないでください。 これは、Windows Server 上で稼働する SQL Server が提供する通常の SQL Database とは異なります。

以前は SQL Azure と呼ばれていた Azure SQL Database は、アトミック トランザクション、データの整合性が確保された複数ユーザーによる同時データ アクセス、ANSI SQL クエリ、使い慣れたプログラミング モデルを含む、リレーショナル データベース管理システムのすべての主要機能を備えています。 SQL Server と同様、SQL Database には、Entity Framework、ADO.NET、JDBC、およびその他の使い慣れたデータ アクセス テクノロジを使用してアクセスできます。 さらに、SQL Database はほとんどの T-SQL 言語と、SQL Server Management Studio などの SQL Server ツールをサポートしています。 SQL Server (または他のリレーショナル データベース) を使い慣れていれば、SQL Database も簡単に使用できます。

しかし、SQL Database は、クラウド内の単なる DBMS ではなく、PaaS サービスです。 データとそれにアクセスするユーザーはお客様が管理しますが、ハードウェア インフラストラクチャの管理、データベースとオペレーティング システム ソフトウェアの自動更新などの単純な管理作業は SQL Database が行います。 また、SQL Database は、高可用性、自動バックアップ、特定の時点に復元する機能も備え、複数の地理的なリージョンにコピーを複製できます。

SQL Database のシナリオ

リレーショナル ストレージを必要とする Azure アプリケーションを (コンピューティング モデルのいずれかを使用して) 作成する場合には、SQL Database が適しています。 しかし、クラウドの外部で実行されるアプリケーションもこのサービスを使用できるため、他にも多くのシナリオが存在します。 たとえば、SQL Database に格納されたデータは、デスクトップ、ノート PC、タブレット、携帯電話などのさまざまなクライアント システムからアクセスできます。 さらに、レプリケーションによる高可用性が組み込まれているため、SQL Database を使用することでダウンタイムを低減することができます。

テーブル

Azure Storage Tables

図: Azure テーブルは、データを格納するためのフラットな NoSQL の手法を提供する。

この機能は、「Azure Storage」と呼ばれる、より大規模な機能の一部として、別の用語で呼ばれることもあります。 「テーブル」、「Azure テーブル」、または「ストレージ テーブル」はすべて同じものです。

その名前が誤解を招く可能性がありますが、このテクノロジはリレーショナル ストレージを提供しません。 実際には、キー/値ストアと呼ばれる NoSQL アプローチの一例です。 Azure Tables では、アプリケーションが文字列、整数、日付などさまざまな型のプロパティを格納することができます。 その後、アプリケーションはプロパティ グループの一意のキーを指定することで、そのグループを取得できます。 結合などの複雑な操作はサポートされていませんが、テーブルを使用することで型指定されたデータに高速でアクセスすることができます。 さらに、1 つのテーブルに 1 TB (テラバイト) のデータを格納できるため、非常にスケーラブルです。 また、テーブルはその簡素性に合わせて、通常は SQL Database のリレーショナル ストレージを使用する場合よりも低価格です。

テーブルのシナリオ

大量に発生する可能性がある型指定データに高速アクセスする必要があるが、このデータに対して複雑な SQL クエリを実行する必要はない Azure アプリケーションを作成するとします。 たとえば、各ユーザーの顧客プロファイル情報を格納する必要があるコンシューマー アプリケーションを作成する場合を考えてみましょう。 このアプリケーションは広く利用されるため、大量のデータに対応する必要がありますが、データを格納して単純な方法で取得する以外は、特にデータを処理する必要がありません。 このようなシナリオには、Azure テーブルが最適です。

BLOB

Azure Storage Blobs
図: Azure BLOB は非構造化バイナリ データを提供する。

Azure BLOB (ここでも「BLOB ストレージ」と「ストレージ BLOB」は同じもの) は、非構造化バイナリ データを格納するために設計されています。 Tables と同様に、BLOB は低価格のストレージを提供し、1 つの BLOB に 1 TB (1 テラバイト) のデータを格納できます。 Azure アプリケーションでは、Azure Drive も使用できるので、BLOB は Azure インスタンスにマウントされた Windows ファイル システムの永続的なストレージを提供できます。 アプリケーションからは、通常の Windows ファイルのように見えますが、実際にはコンテンツは BLOB に格納されています。

BLOB ストレージは、ユーザーのワークロードを確実に処理できるように、他の多数の Azure 機能 (Virtual Machines を含む) によって使用されます。

BLOB のシナリオ

ビデオ、大量のファイル、その他のバイナリ情報を格納するアプリケーションで、簡単な低価格のストレージを確保するために BLOB を使用することができます。 また、BLOB は一般に、Content Delivery Network (後述) などの他のサービスと組み合わせて使用されます。

Import / Export

Azure Import Export Service

図: Azure Import/Export では、データの一括インポートまたはエクスポートをより速く安価にするために、Azure との間に物理ハード ドライブを接続する機能を提供する。

大量のデータを Azure に移行する必要がある場合があります。 おそらく数日にわたる長い時間がかかり、大量の帯域幅が使用されます。 このような場合に、Azure Import/Export を使用すると、Bitlocker で暗号化された 3.5" SATA ハード ドライブを直接 Azure データ センターに接続でき、データはマイクロソフトによって専用の BLOB ストレージに転送されます。 アップロードが完了すると、マイクロソフトはドライブをユーザーに返却します。 また、ハード ドライブにエクスポートされた BLOB ストレージからの大量のデータを要求し、メールを介して受信することもできます。

Import/Export のシナリオ

  • 大量のデータの移行 – Azure にアップロードするデータが大量にある場合は (テラバイト規模)、インターネット経由で転送するより、Import/Export サービスを使用した方がはるかに迅速で、コストも抑えることができます。 データが BLOB に格納されたら、それを処理して、テーブル ストレージや SQL Database などの他の形式に変換できます。
  • アーカイブされたデータの回復 – Import/Export では、Azure Blob Storage に格納された大量のデータを、送付していただいたストレージ デバイスに転送し、そのデバイスを希望した場所にお返しすることができます。 これには多少時間がかかるため、障害復旧には適したオプションではありません。 すぐにアクセスする必要のないアーカイブされたデータに適しています。

ファイル サービス

Azure File Service
図: Azure ファイル サービスは、SMB にクラウド内でアプリケーションを実行するための \\server\share パスを提供する。

オンプレミスでは、\\Server\share 形式を使用し、サーバー メッセージ ブロック (SMB) プロトコルを介してアクセス可能な大量のファイル ストレージがあるのが一般的です。 現在、Azure には、クラウド内でこのプロトコルを使用可能にするサービスが用意されています。 Azure 内で稼働するアプリケーションは、このプロトコルを使用して、ReadFile や WriteFile などの使い慣れたファイル システム API を使用している VM 間でファイルを共有できます。 さらに、REST インターフェイスを介して同時にファイルにアクセスできるため、仮想ネットワークも設定されている場合は、オンプレミス サーバーから共有部分へアクセスできます。 Azure ファイルは、BLOB サービスを基にして構築されているため、Azure Storage と同じ可用性、耐久性、スケーラビリティ、geo 冗長性を継承しています。

Azure Files のシナリオ

  • 既存アプリケーションのクラウドへの移行 - オンプレミスのアプリケーションをファイル共有を使用しているクラウドへ移行し、アプリケーションの部分間でデータを共有する方が簡単です。 各 VM はファイル共有に接続し、その後、オンプレミスのファイル共有の場合と同様にファイルを読み書きできます。
  • 共有アプリケーション設定 - 分散アプリケーションに共通のパターンとして、多数の異なる仮想マシンからアクセス可能な集中管理された場所に構成ファイルが配置されます。 これらの構成ファイルを Azure ファイル共有に格納し、すべてのアプリケーション インスタンスを読み取り可能にすることができます。 また、REST インターフェイスを介して設定を管理できるため、世界中から構成ファイルにアクセスできます。
  • 診断の共有 - ログ、メトリック、クラッシュ ダンプなどの診断ファイルを保存し共有することができます。 SMB と REST インターフェイスの両方を介してこれらのファイルを使用可能にすることで、アプリケーションは各種分析ツールを使用して、診断データを処理および分析できます。
  • 開発/テスト/デバッグ - 開発者または管理者がクラウド内の仮想マシンで作業している場合、通常は、一連のツールやユーティリティが必要です。 各仮想マシンにこれらのユーティリティをインストールおよび配信するのは、時間がかかります。 Azure ファイルを使用すれば、開発者または管理者は好みのツールをファイル共有に格納し、任意の仮想マシンからそれらに接続できます。

ネットワーク

Azure は、現在、世界中で広く展開され多数のデータセンターで稼働しています。 アプリケーションを実行したり、データを格納したりするときは、これらの中から使用するデータセンターを 1 つ以上選択できます。 さらに、以下のサービスを使用して、さまざまな方法でこれらのデータセンターに接続できます。

仮想ネットワーク

VirtualNetwork

図: Virtual Networks は、さまざまなサービスが相互通信したり、クロスプレミス接続に VPN を設定している場合はオンプレミスのリソースへアクセスしたりできるように、クラウド内でプライベート ネットワークを提供する。

パブリック クラウドの便利な使用方法として、自社のデータセンターの延長として扱う方法があります。

VM は必要に応じて作成し、不要になった時点で削除 (および料金のお支払いを停止) できるため、必要なときにのみコンピューティング能力を確保することができます。 また、Azure Virtual Machines により、SharePoint、Active Directory、その他の使い慣れたオンプレミスのソフトウェアを実行する VM を作成できるため、既にあるアプリケーションでこのアプローチを利用することができます。

この有用性を高めるためには、これらのアプリケーションがまるで自社のデータセンターで実行されているかのようにユーザーがアプリケーションを扱うことができる必要があります。 これを Azure の Virtual Network で実現できます。 管理者は、VPN ゲートウェイ デバイスを使用して、自社のローカル ネットワークと Azure 内の仮想ネットワークにデプロイされた VM の間に仮想プライベート ネットワーク (VPN) を設定できます。 クラウド VM には独自の IP v4 アドレスを割り当てるため、VM は自社のネットワーク上にあるように見えます。 組織内のユーザーは、ローカルで実行されているかのように、VM に含まれるアプリケーションにアクセスできます。

専用の仮想ネットワークの計画および作成の詳細については、「 Virtual Network」を参照してください。

ExpressRoute

ExpressRoute

図: ExpressRoute は Azure Virtual Network を使用しますが、パブリック インターネットの代わりにより高速の専用回線を経由して接続をルーティングする。

Azure Virtual Network 接続が提供可能なレベルより広い帯域幅や強力なセキュリティが必要な場合は、ExpressRoute を検討できます。 場合によっては、ExpressRoute の方が費用を節減できます。 引き続き Azure 内に仮想ネットワークは必要ですが、Azure とユーザー サイト間のリンクは、パブリック インターネットを経由しない専用接続を使用します。 このサービスを使用するためには、ネットワーク サービス プロバイダーまたは接続プロバイダーと契約する必要があります。

ExpressRoute 接続を設定するには多くの時間と計画が必要なため、サイト間 VPN から着手して、ExpressRoute 接続へ移行することもできます。

ExpressRoute の詳細については、「 ExpressRoute の技術概要」を参照してください。

Traffic Manager

TrafficManager

図: Azure Traffic Manager では、インテリジェントなルールに基づいて、グローバルなトラフィックを自身のサービスにルーティングできる。

Azure アプリケーションが複数のデータセンターで実行されている場合は、Azure Traffic Manager を使用して、アプリケーションのインスタンスにユーザーからの要求をインテリジェントにルーティングできます。 また、サービスがインターネットからアクセス可能な限り、Azure 内で実行されていないサービスへトラフィックをルーティングすることもできます。

ユーザーが世界の一地域に限定されている Azure アプリケーションは、1 つの Azure データセンターのみで実行されることがあります。 しかし、世界中にユーザーがいるアプリケーションは、複数のデータセンターか、場合によってはすべてのデータセンターで実行される可能性が高くなります。 この 2 番目の状況では、どのようにしてユーザーをアプリケーション インスタンスにインテリジェントに転送するかという問題に直面します。 ほとんどの場合は、最適な応答時間を確保するために、ユーザーがそれぞれ最も近いデータセンターにアクセスすることが求められます。 しかし、そのアプリケーションのインスタンスがオーバーロード状態になったり、使用できない場合には、 別のデータセンターにこのユーザーの要求を自動的に転送することが求められます。 これを Azure Traffic Manager が実現します。

アプリケーションの所有者は、ユーザーからの要求をデータセンターに転送する方法を指定するルールを定義し、Traffic Manager を使用してこれらのルールを実施します。 たとえば、通常は最も近い Azure データセンターにユーザーを転送しますが、既定のデータセンターからの応答時間が他のデータセンターからの応答時間を超過した場合には、別のデータセンターに送信します。 多くのユーザーが世界各地に分散しているアプリケーションでは、組み込みのサービスでこのような問題に対処すると効果的です。

Traffic Manager は Directory Name Service (DNS) を使用してユーザーをサービス エンドポイントにルーティングしますが、その接続が行われた後は、それ以外のトラフィックが Traffic Manager を経由することはありません。 これにより、Traffic Manager がサービスの通信の速度低下を招くボトルネックとなるのを防いでいます。

開発者サービス

Azure には、開発者と IT プロフェッショナルがクラウド内でアプリケーションを作成および維持するうえで役立つ多数のツールが用意されています。

Azure SDK

2008 年、最初に発表されたプレリリース版の Azure では .NET 開発のみがサポートされていました。 しかし、現在ではかなり多くの言語で Azure アプリケーションを作成できます。 マイクロソフトでは現在、.NET、Java、PHP、Node.js、Ruby、Python 向けの言語固有の SDK を提供しています。 C++ など、任意の言語の基本的なサポートを提供する汎用 Azure SDK も用意されています。

これらの SDK では、Azure アプリケーションを構築、デプロイ、および管理できます。 www.microsoftazure.com または GitHub から入手でき、Visual Studio や Eclipse と共に使用できます。 Azure には、Linux システムおよび Macintosh システムから Azure にアプリケーションをデプロイするためのツールなど、開発者がエディターや開発環境で使用できるコマンド ライン ツールも用意されています。

これらの SDK は、Azure アプリケーションの構築に役立つだけではありません。Azure サービスを使用するソフトウェアの作成に役立つクライアント ライブラリも用意されています。 たとえば、Azure BLOB の読み取りと書き込みを行うアプリケーションを構築したり、Azure 管理インターフェイスを通じて Azure アプリケーションをデプロイするツールを作成したりすることができます。

Visual Studio Team Services

Visual Studio Team Services は、Azure 内でアプリケーションを開発するために役立つ多数のサービスを総称したマーケティング名です。

混乱を避けるため、Visual Studio のホステッド版や Web ベース版は提供されていません。 引き続き、Visual Studio のローカルで実行されるコピーが必要です。 ただし、非常に役立つ多数の他のツールが用意されています。

それには、バージョン管理と作業項目トラッキングを提供する Team Foundation Service と呼ばれるホストされたソース管理システムが含まれます。 必要に応じて、バージョン管理に Git を使用することもできます。 さらに、プロジェクトごとに使用するソース管理システムを変えることもできます。 数に制限なくプライベート チーム プロジェクトを作成し、世界中のどこからでもアクセスできます。

Visual Studio Team Services はロード テスト サービスを提供しています。 Visual Studio で作成したロード テストをクラウド内の VM 上で実行できます。 ロード テストを実施するユーザーの合計数を指定すると、Visual Studio Team Services が自動的に必要なエージェント数を決定し、必要な仮想マシンを起動して、ロード テストを実行します。 MSDN のサブスクライバーである場合は、毎月、ロード テスト用に数千のユーザー分数を無料で取得できます。

また、Visual Studio Team Services では、継続的な統合ビルド、かんばんボード、仮想チーム ルームなどの機能により、アジャイル開発もサポートされています。

Visual Studio Team Services のシナリオ

Visual Studio Team Services は、世界規模でのコラボレーションを必要としながら、まだそれを実現するためのインフラストラクチャがないような会社に適したオプションです。 数分で設定して、ソース管理システムを選択し、その日のうちにコードの記述と構築を開始できます。 チーム ツールが調整およびコラボレーションの場を提供し、追加のツールがアプリケーションを迅速にテストおよび調整するために必要な分析を提供します。

既にオンプレミスのシステムを配備している組織は、Visual Studio Team Services で新しいプロジェクトをテストし、それがより効率的であるかどうかを判別できます。

アプリケーション インサイト

アプリケーション インサイト

図: Application Insights による、実行中の Web アプリまたはデバイス アプリのパフォーマンスと使用状況の監視

アプリを発行すると、アプリがモバイル デバイス、デスクトップ、Web ブラウザのいずれで実行されるとしても、Application Insights によりアプリの実行状況と利用ユーザーを知ることができます。 クラッシュと応答速度低下の発生回数が記録され、回数が許容できないしきい値を超えた場合には警告されるので、問題が起きた場合の原因究明に役立ちます。

新機能を開発する場合は、ユーザーの満足度を測定することを計画してください。 使用パターンを分析すると、顧客に最も適した機能がわかり、開発サイクルのたびにアプリを強化することができます。

Application Insights は Azure でホストされていますが、Azure の内外両方のさまざまなアプリに対応しており、その対応範囲は拡大を続けています。 iOS、Android、OS X、Windows のアプリケーションだけでなく、J2EE と ASP.NET の両方の Web アプリにも対応しています。 アプリでビルドされた SDK から製品利用統計情報が送信され、Azure の Application Insights サービスで分析されて表示されます。

より専門的な分析が必要な場合には、製品利用統計情報ストリームをデータベース、Power BI などのツールにエクスポートしてください。

Application Insights のシナリオ

あなたはアプリを開発しています。 Web アプリやデバイス アプリ、あるいは Web バック エンドを備えたデバイス アプリの場合もあります。

  • 発行後またはロード テスト中にアプリのパフォーマンスを調整する。 Application Insights では、インストール済みのすべてのインスタンスから製品利用統計情報が収集され、応答時間、要求と例外の件数、依存関係の応答時間などのパフォーマンス指標に関するグラフが表示されます。 これらの指標は、アプリのパフォーマンス調整に役立ちます。 必要に応じて、より具体的なデータを報告するコードを挿入できます。
  • 実行中のアプリにおける問題を検出して診断する。 許容可能なしきい値をパフォーマンス指標が超えた場合、電子メールで警告を受け取ることができます。 たとえば、特定のユーザー セッションを調査することで、例外の原因となった要求を確認できます。
  • 使用状況を追跡してそれぞれの新機能の満足度を評価する。 新しいユーザー ストーリーを描く場合は、どれだけ使用されているかや、望んでいた目標をユーザーが達成しているかどうかを測定することを計画してください。 Application Insights によって Web ページの閲覧数などの基本的な使用状況データが得られ、ユーザー エクスペリエンスをさらに詳しく追跡するコードを挿入できます。

Automation

同じ手動プロセスを繰り返し実行して時間を無駄にするのが好きな人はいません。 Azure Automation は、Azure 環境内でリソースを作成、監視、管理、およびデプロイする手法を提供します。

Automation では、内部で Windows PowerShell ワークフロー (正規の PowerShell ではなく) を使用する "Runbook" が採用されています。 Runbook は、ユーザーが介在することなく実行されるようになっています。 PowerShell ワークフローによって、途中のチェックポイントでのスクリプトの状態を保存できます。 その後、障害が発生した場合は、スクリプトを最初から起動し直す必要はありません。 最後のチェックポイントから再起動できます。 これによって、スクリプトで考えられるすべての問題を処理するために費やす時間を大幅に節減できます。

Automation のシナリオ

Azure Automation は、手動で、時間がかかり、エラーを招きやすく、頻繁に繰り返されるようなタスクを Azure 内で自動化するために適した選択肢です。

API Management

アプリケーション プログラマー インターフェイス (API) を作成し、インターネットで公開するのが、アプリケーションにサービスを提供する一般的な方法です。 それらのサービスが再販可能な場合 (たとえば、気象データ)、組織は、他のサード パーティに同じサービスへの有料でのアクセスを許可します。 パートナー数が増えるほど、通常はアクセスを最適化し管理する必要が生じます。 パートナーによっては、異なる形式でデータが必要な場合もあります。

Azure API Management は、組織がより簡単に、規模に応じて安全に API をパートナー、従業員、サード パーティ開発者に発行できるようにします。 異なる API エンドポイントを設け、キャッシュ、変換、スロットル、アクセス制御、分析集計などのサービスを提供しながら、実際のエンドポイントを呼び出すプロキシとして動作します。

API Management のシナリオ

たとえば、路上の各トラックにデバイスがある輸送会社のように、会社にデバイスのセットがあり、すべてのデバイスが中央のサービスにコールバックしてデータを取得する必要があるとします。 特に、会社は、配送時間を確実に予測し更新できるように、自社のトラックを追跡するシステムを設定することを望んでいます。 そのようなシステムがあれば、使用可能なトラック数を把握し、適切に計画できます。 各トラックには、中央サイトにコールバックし、位値データや速度データなどのさまざまなデータを送信するためのデバイスが必要です。

おそらく、輸送会社の顧客にも、この位置データの取得からメリットがもたらされます。 顧客はそのデータを使用して、製品の運搬に必要な距離、停滞している場所、特定の経路に沿って支払う金額を把握できます (輸送に支払いが伴う場合)。 輸送会社がこのデータをあらかじめ集計してあれば、多くの顧客がそれにお金を払うかもしれません。 しかし、輸送会社は、顧客にデータを提供する手段を用意する必要があります。 顧客にアクセス権を提供すると、データの問い合わせ頻度を制御できなくなる場合があります。 だれがどのデータにアクセス可能であるかルールを指定する必要があります。 これらのルールをすべて、外部 API に組み込む必要があります。 ここで、API Management が役立ちます。

ID とアクセス

ほとんどのアプリケーションには、ID の処理が含まれます。 アプリケーションはユーザーがだれかを認識することで、そのユーザーとの対話方法を決定します。 Azure は、ID の追跡に加え、既存の ID ストアへの ID の統合にも役立つサービスを提供しています。

Active Directory

ほとんどのディレクトリ サービスと同様、Azure Active Directory は、ユーザーとユーザーが所属する組織に関する情報を格納しています。 これにより、ユーザーはログインでき、ID を証明するためにアプリケーションに提示するトークンが提供されます。 さらに、ローカル ネットワークでオンプレミスとして実行される Windows Server Active Directory とのユーザー情報の同期も可能です。 Azure Active Directory により使用されるメカニズムとデータ形式は、Windows Server Active Directory とは異なりますが、実行する機能はきわめて似ています。

ここで重要な点は、Azure Active Directory は主にクラウド アプリケーションで使用するために設計されているということです。 Azure Active Directory は、Azure やその他のクラウド プラットフォームで実行するアプリケーションのほか、 Office 365 など、マイクロソフトのクラウド アプリケーションでも使用されます。 しかし、Azure Virtual Machines や Azure Virtual Network を使用してデータセンターをクラウドに拡張する場合には、Azure Active Directory は適していません。 代わりに、Virtual Machines 内で Windows Server Active Directory を実行する方が適しています。

アプリケーションが中に含まれる情報にアクセスできるようにするため、Azure Active Directory には、Azure Active Directory Graph と呼ばれる REST ベースの API が用意されています。 この API を使用すると、任意のプラットフォームで実行されるアプリケーションからディレクトリ オブジェクトとこれらオブジェクトのリレーションシップにアクセスすることができます。 たとえば、承認されたアプリケーションは、ユーザー、ユーザーが属するグループ、およびその他の情報を得るために、この API を使用することが考えられます。 アプリケーションは、ユーザー間のリレーションシップ (ソーシャル グラフ) を確認し、ユーザー間の接続をよりインテリジェントに処理することができます。

このサービスのもう 1 つの機能である Azure Active Directory Access Control は、アプリケーションが Facebook、Google、Windows Live ID やその他の一般的な ID プロバイダーから ID 情報を簡単に取得できるようにします。 アプリケーションがこれらの各プロバイダーで使用されるさまざまなデータ形式とプロトコルを認識するのではなく、Access Control がこれらのすべてを 1 つの共通形式に変換します。 さらに、アプリケーションは 1 つ以上の Active Directory ドメインからのログインを受け入れることができるようになります。 たとえば、SaaS アプリケーションを提供するベンダーは、Azure Active Directory Access Control を使用して、各顧客のユーザーにアプリケーションへのシングル サインオンを提供できます。

ディレクトリ サービスは、オンプレミス コンピューティングの中核的な土台を構成し、 当然のことながら、クラウドでも重要な役割を担います。

Multi-Factor Authentication

Azure Multi-Factor Authentication

図: Multi-Factor Authentication は、アプリケーションで複数の形式の ID を検証する機能を提供する。

セキュリティは常に重要です。 Multi-Factor Authentication (MFA) は、ユーザー自身のみが自分のアカウントにアクセスするように保証するために役立ちます。 MFA (2 要素認証、"2FA" としても知られる) では、ユーザーのサインインとトランザクションのために、ユーザーが次の 3 つの ID 検証方法のうち 2 つを提供する必要があります。

  • ユーザーが知っているもの (通常はパスワード)
  • ユーザーが持っているもの (携帯電話など、簡単には複製できない信頼できるデバイス)
  • ユーザー自身 (生体認証)

そのため、ユーザーのサインイン時に、モバイル アプリ、電話のコール、またはテキスト メッセージとパスワードを組み合わせて ID を検証するように要求することができます。 既定では、Azure Active Directory は、ユーザーのサインインの唯一の認証方式としてパスワードの使用をサポートしています。MFA と Azure AD を併用することもできれば、MFA SDK を使用することで MFA とカスタム アプリケーションおよびディレクトリを併用することもできます。 また、Multi-Factor Authentication Server を使用することで、オンプレミスのアプリケーションと併用することもできます。

MFA のシナリオ

銀行へのログインやソース コードへのアクセスなど、機密アカウントでのログインの保護。不正なアクセスにより、財政や知的財産関連のコストが増加しかねない場合に有益です。

モバイル

モバイル デバイスのアプリケーションを作成している場合は、大量のカスタム コードを記述する必要なしに、クラウドへのデータの格納、ユーザーの認証、プッシュ通知の送信を行うために Azure が役立つことがあります。

Virtual Machines、Cloud Services、または Web Apps を使用して確実にモバイル アプリケーションのバックエンドをビルドすることもできますが、Azure のサービスを使用すると、このような基盤となるサービス コンポーネントの記述に要する時間を大幅に削減できます。

Mobile Apps

Mobile Apps

図: Mobile Apps は、モバイル デバイスと連動するアプリケーションによって一般に必要とされる機能を提供する。

Azure Mobile Apps は、モバイル アプリケーションのバックエンドの構築時に時間を節減できる多数の役立つ機能を提供します。 ユーザーは、SQL Database に格納されるデータをプロビジョニングして管理するだけです。 サーバー側のコードでは、BLOB ストレージや MongoDB などの追加のデータ ストレージ オプションを簡単に使用できます。 Mobile Apps は通知をサポートしていますが、特定の場合には、次に説明するように、代わりに Notification Hubs を使用できます。 また、サービスは、モバイル アプリケーションが処理を完了するために呼び出すことができる REST API も備えています。 さらに、Mobile Apps は、Microsoft と Active Directory、および Facebook、Twitter、Google などの他の有名な ID プロバイダーを介して、ユーザーを認証する機能も提供しています。

Service Bus や worker ロールなどのその他の Azure サービスを使用して、オンプレミスのシステムに接続することもできます。 Azure ストアからサード パーティのアドオン (電子メール用の SendGrid など) を購入して、追加機能を提供することもできます。

Android、iOS、HTML/JavaScript、Windows Phone、および Windows ストアのネイティブ クライアント ライブラリは、主要なモバイル プラットフォームすべてで使用できるアプリケーションの開発を容易なものにします。 REST API では、異なるプラットフォーム上のアプリケーションと共に、Mobile Services データと認証機能を使用できます。 1 つのモバイル サービスは、複数のクライアント アプリケーションをサポートできるため、デバイス全体に一貫したユーザー エクスペリエンスを提供できます。

Azure は既にたいへんな規模をサポートしているため、アプリケーションの人気が高まり利用者が増えてもトラフィックを処理できます。 問題のトラブルシューティングとパフォーマンス管理を促進するために監視とログがサポートされています。

Notification Hubs

NotificationHubs

図: Notification Hubs は、モバイル デバイスと連動するアプリケーションによって一般に必要とされる機能を提供する。

Azure Mobile Apps では通知を実行するコードを記述できますが、Notification Hubs はかなりパーソナライズされた数百万のプッシュ通知を数分でブロードキャストするのに最適です。 携帯電話会社やデバイスの製造元などの詳細を気にする必要はありません。 単一の API コールで個々のユーザーまたは数百万のユーザーを対象にすることができます。

Notification Hubs は、いずれのバックエンドでも動作するように設計されています。 Azure Mobile Apps、プロバイダー上で稼働するクラウド内のカスタム バックエンド、またはオンプレミスのバックエンドを使用できます。

Notification Hubs のシナリオ プレイヤーが交代するモバイル ゲームを記述しているとしたら、プレイヤー 1 が自身の順番を終了したことをプレイヤー 2 に通知することが必要になる場合があります。 それだけが必要な場合は、Mobile Apps を使用できます。 ゲームをプレイするのが 100,000 ユーザーで、時間的制約のある無料プランをすべてのユーザーに送信する場合は、Notification Hubs がより良い選択肢となります。

ニュース速報、スポーツ イベント、製品発表の通知をわずかな遅延で数百万のユーザーに送信できます。 企業は、セールス リードなどの一刻を争う新たなコミュニケーションについて従業員に通知でき、従業員は電子メールやその他のアプリケーションを何度も確認する必要なく、常に情報を入手できます。 また、Multi-Factor Authentication に必要なワンタイム パスワードを送信することもできます。

バックアップ

どの企業もデータをバックアップし復元する必要があります。 クラウド内かオンプレミスかに関係なく、Azure を使用してアプリケーションをバックアップおよび復元することができます。 Azure には、バックアップの種類に応じて役立つさまざまなオプションが用意されています。

Site Recovery

Azure Site Recovery (以前の Hyper-V Recovery Manager) は、サイト間でのレプリケーションと回復を調整することで、重要なアプリケーションの保護を支援します。 Site Recovery は、Hyper-v、VMWare、または SAN に基づいてアプリケーションを保護する機能を、セカンダリ サイト、ホスト側のサイト、または Azure に提供することで、独自のセカンダリの場所を構築したり管理したりするための費用と複雑さを回避できるようにします。 Azure はデータと通信を暗号化するため、保存データの暗号化を有効にするオプションもあります。

サービスの正常性を継続的に監視し、プライマリ データセンターでのサイトが機能停止したときに秩序立てて自動的にサービスを回復できるよう支援します。 また、調整された形式で Virtual Machines を導入することで、複雑な多層のワークロードの場合でも、サービスの迅速な復元を可能にします。

Site Recovery は、Hyper-V Replica、System Center、SQL Server AlwaysOn などの既存のテクノロジと連携動作します。 詳細については、「 Azure Site Recovery の概要 」を参照してください。

Azure Backup

Azure Backup

図: Azure Backup は、オンプレミスの Windows Server からクラウドにデータをバックアップする。

Azure Backup は、Windows Server が実行されているオンプレミスのサーバーからクラウドにデータをバックアップします。 Windows Server 2012、Windows Server 2012 Essentials、または System Center 2012 - Data Protection Manager 内のバックアップ ツールから直接バックアップを管理できます。 代替として、特化したバックアップ エージェントを使用することもできます。

バックアップは伝送される前に暗号化され、暗号化されたデータが Azure に格納され、アップロードした証明書によって保護されるため、データはより安全です。 サービスは、Azure Storage と同じ冗長で可用性の高いデータ保護を使用します。 ファイルとフォルダーは、フルアックアップまたは増分バックアップを実行して、スケジュールにより定期的にバックアップすることも、即座にバックアップすることもできます。 データがクラウドにバックアップされたのち、許可されているユーザーは簡単にバックアップをサーバーに回復できます。 また、データの格納と転送にかかるコストを管理するために、設定可能なデータの保有ポリシー、データ圧縮、およびデータ転送調整も提供しています。

Azure Backup のシナリオ

既に Windows Server または System Center を使用している場合、Azure Backup は、サーバー ファイル システム、仮想マシン、SQL Server データベースをバックアップするための最適なソリューションです。 暗号化ファイル、スパース ファイル、および圧縮ファイルを処理します。 いくつかの制限があるため、最初に Azure Backup の前提条件を確認 してください。

メッセージングと統合

どのような処理を行う場合でも、コードは頻繁に他のコードと対話する必要があります。 状況によって、基本的なキュー メッセージングのみが必要な場合と、 より複雑な対話が必要になる場合があります。 Azure には、これらの問題を解決するいくつかの手段が用意されています。 図 5 に、これらのオプションを示します。

キュー

Azure Service Bus Relay

図: キューは、アプリケーションの各パーツの疎結合を実現し、スケーリングを容易にする。

キューは単純な概念で、あるアプリケーションがキューにメッセージを配置すると、そのメッセージがいずれ別のアプリケーションによって読み取られるというものです。 アプリケーションにこのように単純なサービスが必要な場合は、Azure キューが最も適しているでしょう。

Azure は時間の経過と共に拡大するため、Azure Storage キューおよび Service Bus キューは類似のキュー サービスを提供しています。 一方を他方より優先して使用する理由は、かなり技術的な資料である「 Azure キューと Service Bus キューの比較」で説明されています。 多くのシナリオでは、どちらも機能します。

キューのシナリオ

今日のキューの一般的な使用方法として、同じ Cloud Services アプリケーション内での web ロール インスタンスと worker ロール インスタンスとの相互通信があります。

たとえば、ビデオを共有するために Azure アプリケーションを作成するとします。 アプリケーションは、ユーザーがビデオのアップロードと視聴を行うために Web ロール内で実行される PHP コードと、アップロードされたビデオをさまざまな形式に変換する、C# で実装される Worker ロールで構成されています。

Web ロール インスタンスがユーザーから新しいビデオを取得すると、ビデオを BLOB に格納し、キューを介して Worker ロールにメッセージを送信してこの新しいビデオの格納場所を通知します。 Worker ロール インスタンス (どのインスタンスでもかまいません) は、その後、キューからメッセージを読み取り、バックグラウンドで必要なビデオ変換を実行します。

アプリケーションをこのように構成することで、非同期処理が可能になるだけでなく、Web ロールと Worker ロール インスタンス数を別々に変更できるため、アプリケーションの規模を簡単に変更できるようになります。 また、キュー サイズをトリガーとして使用して、worker ロールの数を増減することもできます。 キュー サイズが大きすぎる場合は、より多くのロールを追加します。 サイズが小さくなった場合は、実行中のロールの数を減らし、費用を節減できます。

Web ロールと worker ロールが使用されていなくても、アプリケーションの多くのパーツで同じパターンを使用できます。 需要や処理時間のニーズに応じて、キューのどちらかの側でパーツのスケールを調整できます。

Service Bus

クラウド、データセンター、モバイル デバイスなど、アプリケーションをどこで実行する場合でも、対話が必要です。 Azure Service Bus の目的は、データを交換するほとんどすべての場所でアプリケーションを実行できるようにすることです。

前のキュー (1 対 1) に加え、Service Bus はその他の通信方法も提供しています。

Service Bus Relay

Azure Service Bus Relay

図: Service Bus Relay を使用すると、ファイアウォールの異なる側にあるアプリケーション間で通信できる。

Service Bus はリレー サービスを介した直接的な通信を実現するため、ファイアウォールを介して安全に対話する手段を確保できます。 Service Bus リレーは、ローカルではなくクラウドでホストされるエンドポイントを介してメッセージを交換することによって、アプリケーションの通信ができます。

Service Bus Relay のシナリオ

Service Bus を介して通信するアプリケーションは、他のクラウド プラットフォーム上で実行される Azure アプリケーションやソフトウェアである場合も、 クラウドの外部で実行されるアプリケーションである場合もあります。 たとえば、自社のデータセンター内のコンピューターで予約サービスを実施する航空会社があるとします。 この航空会社は、空港のチェックイン キオスク、予約代理店の端末、さらに顧客の携帯電話など、多くのクライアントにこのサービスを公開する必要があります。 このために Service Bus を使用して、さまざまなアプリケーション間で疎結合方式の対話を作成します。

Service Bus トピックとサブスクリプション

Azure Service Bus トピック
図: Service Bus トピックを使用すると、複数のアプリケーションがメッセージを投稿でき、他のアプリケーションはサブスクライブして特定の条件を満たすメッセージを受信できる。

Service Bus は、トピックおよびサブスクリプションと呼ばれる発行/サブスクライブ メカニズムを提供しています。 発行/サブスクライブでは、アプリケーションはトピックにメッセージを送信でき、他のアプリケーションはこのトピックへのサブスクリプションを作成できます。 これにより、アプリケーション セット内で 1 対多コミュニケーションが可能になり、複数の受信者が同じメッセージを読むことができます。

Service Bus トピックとサブスクリプションのシナリオ

すべてが重要な多数のメッセージが存在する場所を設定しているが、各ダウンストリーム システムはそれらの通信のうちそれぞれ異なるサブセットしかリッスンする必要がないような場合は、Service Bus トピックとサブスクリプションが適したオプションです。

BizTalk Services

BizTalk Services
図: BizTalk Services は、クラウド内で XML メッセージ形式を変換する機能を提供する。

場合によっては、異なるメッセージング形式を使用して通信するシステムを接続する必要があります。 共通の基準が使用可能な場合でも、一般に、企業によってデータベース スキーマや XML メッセージング形式は異なっています。 多数のカスタム コードを記述するのではなく、オンプレミスの BizTalk Server を使用してさまざまなシステムを統合できます。 Azure BizTalk Services は、同じタイプのサービスをクラウド内で提供します。 使用量に応じて支払うことができ、オンプレミスのように規模について心配する必要はありません。

BizTalk Services のシナリオ

Business-to-Business (B2B) のやり取りには、一般にこの種類の変換が必要です。 たとえば、航空機を製造している会社は、さまざまな部品サプライヤーに部品を注文する必要があります。 多数の部品サプライヤーが存在します。 それらの注文は、航空機製造システムからサプライヤーのシステムに直接送信されるように自動化する必要があります。 どちらの会社も自社のコア システムとメッセージ形式を変更することは望んでおらず、それらの形式が同一である場合はほとんどありません。 BizTalk Services は、双方向で、メッセージを取得し、相手に応じた新しい形式に変換します。 どちらがより厳密な制御を望むか、さらに必要な変換の量に応じて、航空機の製造会社が変換作業を実行できる場合もあれば、さまざまなサプライヤーが実行できる場合もあります。

計算支援

Azure は、常時実行する必要のないサービスに対する支援を提供しています。

Scheduler

Azure Scheduler
図: Azure Scheduler を利用すれば、特定の期間の特定の時間にジョブをスケジュールできる。

一定の時間に実行する必要しかないアプリケーションもあります。 Azure では、データを処理するためにアプリケーションを常時実行しておく代わりに、このタイプのアプリケーションに要する費用を節減できます。 Azure Scheduler では、時間間隔またはカレンダーに基づいてアプリケーションをいつ実行するかをスケジュールできます。 信頼性が高く、ネットワーク、マシン、およびデータセンターで障害が発生した場合でも、プロセスは確実に実行されます。 これらのアクションは、Scheduler REST API を使用して管理できます。

スケジュールされたアラームが発行されると、Scheduler は HTTP または HTTPS メッセージを特定のエンドポイントに送信するか、またはメッセージをストレージ キューに入れることができます。 アプリケーションがアクセス可能なエンドポイントを保持するか、またはストレージ キューを監視するように設定する必要があります。 その後、メッセージを取得すると、プログラムされているアクションを実行できます。

Scheduler のシナリオ

  • 定期的なアプリケーション アクション: たとえば、サービスは定期的に Twitter からデータを取得し、それらのデータを定期的なフィードへとまとめます。
  • 日々のメンテナンス: ログの処理または排除、バックアップの実行、およびその他の間欠的にスケジュールされたタスク。
  • 夜間に実行されるタスク。
  • 日々のログの排除、バックアップの実行、その他のメンテナンス タスクなどの Web アプリケーション タスク。 たとえば、管理者は、今後 9 か月間、毎日午前 1 時にデータベースをバックアップするように選択できます。

Scheduler API を使用すると、ジョブ コレクションとスケジュールされたジョブをプログラムによって作成、更新、削除、表示、管理できます。

パフォーマンス

パフォーマンスはアプリケーションにとって常に重要です。 アプリケーションは、同じデータに繰り返しアクセスする傾向があります。 パフォーマンスを向上する 1 つの手段として、アプリケーションの近くにそのデータのコピーを保持して、データの取得に必要な時間を短縮する方法があります。 Azure では、この目的のためにさまざまなサービスを提供しています。

Azure Cache

Azure Caching
図: Azure アプリケーションは、データをメモリにキャッシュし、それを多数の worker ロールに分割することもできる。

SQL Database、テーブル、BLOB という Azure のデータ管理サービスのいずれかに格納されたデータには高速アクセスできますが、 メモリに格納されたデータへのアクセスはさらに高速です。 このため、頻繁にアクセスするデータのコピーをメモリ内に維持することで、アプリケーション パフォーマンスを向上できます。 これには、Azure のメモリ内 Caching を使用できます。

Cloud Services アプリケーションは、このキャッシュにデータを格納し、その後は永続的なストレージにアクセスしなくても、直接データを取得できます。 アプリケーションの VM 内にキャッシュを維持することも、キャッシュ専用の VM が提供するキャッシュを使用することもできます。 いずれの場合も、キャッシュを分散して、中に含まれるデータを Azure データセンターの複数の VM に分散することができます。

Azure には、時間の経過と共に変化してきた多種多様なキャッシュ テクノロジがあります。 それらは、共有キャッシュ、インロール キャッシュ、Managed Cache、Redis Cache の順に導入されました。 Shared Caching は、旧式のテクノロジのため、それを使用して新しい実装を作成するのは避けてください。 Managed Cache は、In-Role Cache と同じ機能を備えていますが、Microsoft Azure 管理ポータル外部のマネージ サービスとして保持します。 Redis Cache はプレビュー段階です。 Redis 実装は最大数の機能を備え、新規キャッシュ コードを記述するときに推奨されます。

Azure Cache のシナリオ

たとえば、製品カタログを繰り返し読み取るアプリケーションでは、必要なデータをすばやく取得できるため、このようなキャッシュの使用が有効です。 このテクノロジは、ロックもサポートしているため、読み取り/書き込みデータにも読み取り専用データにも使用できます。 さらに、ASP.NET アプリケーションでは、構成を変更するだけで、サービスを使用してセッション データを格納できます。

Content Delivery Network

Azure CDN
図: BLOB のコピーを世界中のサイトでキャッシュできる。

世界各地のユーザーがアクセスする BLOB データを格納する必要があるとします。 例としては、ワールド カップの最新の試合のビデオ、ドライバーの更新プログラム、一般的な電子ブックなどがあります。 このために、複数の Azure データセンターにデータのコピーを格納することができますが、ユーザーが多い場合は、十分でない可能性があります。 より優れたパフォーマンスを得るには、Azure CDN を使用します。

世界中に数十の CDN サイトがあり、それぞれが Azure BLOB のコピーを格納できます。 世界のある地域のユーザーが初めて特定の BLOB にアクセスすると、中に含まれている情報が Azure データセンターからその Geo のローカル CDN ストレージにコピーされます。 それ以降のその地域からのアクセスには、CDN にキャッシュされた BLOB コピーが使用されるため、近くの Azure データセンターまでアクセスする必要がありません。 この結果、ユーザーは世界中のどこからでも、頻繁にアクセスするデータに高速アクセスできるようになります。

CDN のシナリオ

CDN は、世界中にビデオを配信するために、Media Services と併用するのが一般的です。 ビデオは通常サイズが大きく、大量の帯域幅が必要です。 Media Services については、このページの別の場所で説明します。

ビッグ データおよび大規模なコンピューティング

HDInsight (Hadoop)

HDInsight
図: HDInsight は、大量のデータを一括処理するときに役立つ。

長年にわたって、データ分析のほとんどは、リレーショナル DBMS で構築されたデータ ウェアハウスに格納されたリレーショナル データに対して行われてきました。 このようなビジネス分析は現在も重要であり、それは今後も変わらないでしょう。 しかし、リレーショナル データベースで対応できないような大量のデータを分析する場合や、 データがリレーショナルでない場合はどうでしょうか。 たとえば、データセンターのサーバー ログや、センサーからの履歴イベント データなどです。 このような場合には、ビッグ データ問題と呼ばれる問題に直面するため、 別のアプローチが必要です。

現在、ビッグ データの分析に最もよく使用されているテクノロジは Hadoop です。 Apache オープン ソース プロジェクトであるこのテクノロジは、Hadoop 分散ファイル システム (HDFS) を使用してデータを格納し、開発者はデータを分析するための MapReduce ジョブを作成します。 HDFS は複数のサーバーにデータを分散し、各サーバーで MapReduce ジョブのチャンクを実行して、ビッグ データを並列処理します。

HDInsight は、Azure の Apache Hadoop ベース サービスの名前です。 HDInsight では HDFS がクラスターにデータを格納してそれを複数の VM に分配することができます。 また、これらの VM 全体 MapReduce ジョブのロジックを配布します。 オンプレミスの Hadoop と同様に、データはローカルで (ロジックとそのロジックが処理するデータは同じ VM 内に存在) 並列処理されるため、パフォーマンスが向上します。 HDInsight は、BLOB を使用する Azure の Storage Vault (ASV) にデータを格納できます。 ASV を使用すると、クラウドにデータを保持したまま使用していない HDInsight クラスターを削除できるため、コスト削減ができます。

HDinsight は Hive および Pig を含めた Hadoop エコシステムのその他のコンポーネントも同様にサポートしています。 Microsoft が作成したコンポーネントは、Excel を使用する HiveODBC アダプターや Data Explorer など、従来の BI ツールを使用して HDInsight によって生成されたデータに対する作業を容易にします。

ハイパフォーマンス コンピューティング (大規模なコンピューティング)

クラウドのプラットフォームはさまざまな面で有効活用できますが、その 1 つが、ハイパフォーマンス コンピューティング (HPC) とその他の "大規模なコンピューティング" アプリケーションの実行です。 例として、業界標準の Message Passing Interface (MPI) を使用するために構築された専用エンジニアリング アプリケーションや、財務リスク モデルなどのいわゆる厄介な並列アプリケーションがあります。

大規模なコンピューティングの利点は、多くのマシン上でコードを同時に実行することです。 Azure では、これは、多くの仮想マシンを同時に実行し、すべてを並列で処理して問題を解決することを意味します。 このためには、リソースを割り当ててアプリケーションをスケジュールする、つまり、これらのインスタンス間に処理を分散するための手段が必要になります。 マイクロソフトの無料の HPC パックとその他のコンピューティング クラスター ソリューションは、Azure 内で良好に稼働し、Azure コンピューティングおよびインフラストラクチャ サービスを活用して、オンプレミスのコンピューティング クラスターにオンデマンドでキャパシティを追加したり、大規模なコンピューティング アプリケーション全体をクラウド内で実行したりできます。

Azure は、CPU コア、メモリ、ディスク容量、および異なるアプリケーションの要件を満たすためのその他の特性から成るさまざまな構成における広範な VM インスタンス サイズに対応しています。 最近導入された A8 および A9 インスタンスは、高速なマルチコア CPU と大量のメモリを搭載しているため、多数のコンピューター集中型のワークロード、特に、並列 MPI アプリケーションに適しています。 特定の構成のインスタンスでは、並列 MPI アプリケーションの効率を最大化するためにリモート ダイレクト メモリ アクセス (RDMA) が組み込まれたクラウド内で、低遅延でスループットの高いアプリケーション ネットワークを利用します。

また、Azure は、大規模なコンピューティング アプリケーションの開発者とパートナーに、コンピューティングの機能、サービス、アーキテクチャの選択肢、開発ツールを含むフル セットを提供しています。 Azure は、専用のデータ ワークフローとジョブ、および数千のコンピューティング コアまで拡張可能なタスク スケジューリング パターンを含め、カスタマイズされた大規模なコンピューティングのワークフローをサポートします。

メディア

Azure Media Services
図: Media Services は、世界中のクライアントにビデオや他のメディアを提供するアプリケーションのプラットフォームです。

ビデオは、現在のインターネット トラフィックの大きな部分を占めており、その割合はさらに大きくなっていきます。 しかし、Web でビデオを提供するのは簡単ではありません。 エンコーディング アルゴリズム、ユーザー画面のディスプレイ解像度など、一定しない要素がたくさんあります。 さらに、多くの人がオンライン ムービーを観ようとする土曜の夜など、ビデオの需要は急増することがよくあります。

その人気を考えると、今後はビデオを使用した新しいアプリケーションが数多く作成されることになるでしょう。 しかし、どのアプリケーションでも同じ問題を解決する必要があり、アプリケーションごとにそれらの問題を解決するのは合理的ではありません。 多くのアプリケーションにより使用される共通の解決策を提供するプラットフォームを作成するアプローチの方が優れています。 そして、このプラットフォームをクラウドにビルドすることにはいくつかの明らかな利点があります。 従量課金制で広範囲に利用してもらうことができ、ビデオ アプリケーションがよく直面する変動に対処することもできます。

Azure Media Services はこの問題に対処します。 ビデオや他のメディアを使用するアプリケーションを作成および実行する担当者の業務をシンプルにする一連のクラウド コンポーネントが用意されています。

図が示すように、Media Services にはビデオや他のメディアと連動する一連のアプリケーション コンポーネントが用意されています。 たとえば、ビデオを Media Services (Azure BLOB における格納場所) にアップロードするためのメディア取り込みコンポーネント、さまざまなビデオ形式やオーディオ形式をサポートするエンコーディング コンポーネント、デジタル権利管理を行うコンテンツ保護コンポーネント、ビデオ ストリームに広告を挿入するコンポーネント、ストリーミングを行うコンポーネントなどが用意されています。 マイクロソフト パートナーがプラットフォーム向けのコンポーネントを提供し、マイクロソフトがそれらのコンポーネントを代理で配布して請求することもあります。

このプラットフォームを使用するアプリケーションは、Azure などで実行できます。 たとえば、ビデオ制作会社向けのデスクトップ アプリケーションでは、ユーザーが Media Services にメディアをアップロードし、さまざまな方法で処理できることがあります。 または、Azure で実行されるクラウド ベースのコンテンツ管理サービスが、ビデオを処理および配信する点で Media Services に依存していることがあります。 実行する場所や内容にかかわらず、各アプリケーションは使用する必要があるコンポーネントを選択し、RESTful インターフェイスを通してアクセスします。

アプリケーションは、生成データを配信するために、Azure CDN や他の CDN を使用したり、ユーザーに直接データを送信することができます。 配信方法が何であれ、Media Services を使用して作成されたビデオは、Windows、Macintosh、HTML 5、iOS、Android、Windows Phone、Flash、Silverlight など、さまざまなクライアント システムにより使用される可能性があります。 その目的は、最新のメディア アプリケーションの作成を容易にすることにあります。

参照

Media Services の詳細に関するビジュアルな表示については、Azure Media Services ポスターをダウンロードしてください。

コマース

サービスとしてのソフトウェアの登場により、アプリケーションの作成方法が変わろうとしています。 さらに、アプリケーションの販売方法も変わろうとしています。 SaaS アプリケーションはクラウドに存在するため、当然ながら潜在的な顧客はソリューションをオンラインで探します。 この変化は、アプリケーションだけでなくデータにも当てはまります。 ユーザーは、商用データセットもクラウドで探すはずです。 Microsoft は、 Azure Marketplaceでどちらの懸念事項にも対応しています。

Azure Commerce
図: Azure Marketplace と Azure ストアでは、Azure アプリケーションおよび商用データセットを検索して購入し、それらを Azure アプリケーションの一部として使用できる。

これら 2 つの違いは、Marketplace が Microsoft Azure 管理ポータルの外にあり、ストアはポータルからアクセスできることです。 顧客は、それぞれのニーズを満たす Azure アプリケーションを検索して見つけることができます。 また、人口統計データ、財務データ、地図データなどの商用データセットも検索することができます。 目的のデータが見つかった場合、そのベンダーから、または Marketplace やストアの Web サイト、場合によっては管理ポータルから直接そのデータにアクセスできます。 アプリケーションで Marketplace 経由で Bing Search API を使用すると、顧客が Web 検索の結果にアクセスできるようにすることもできます。

コマースのシナリオ

SendGrid は、電子メールを送信できる Azure ストア内のアプリケーションです。 信頼できる配信や統計などの追加機能を提供しています。 このようなインフラストラクチャを自身で構築する代わりに、このアプリケーションと関連サービスを購入できます。

Getting Started (概要)

これで全体像を把握できたため、次のステップは最初の Azure アプリケーションを記述することです。 言語を選択して適切な SDK を入手し、作成してみましょう。 クラウド コンピューティングはこれからの基本です。今すぐ始めましょう。