Quantcast
Channel: Microsoft Azure Japan Team Blog (ブログ)
Viewing all 711 articles
Browse latest View live

Windows Azure Web サイトでの IP およびドメインの制限

$
0
0

このポストは、12 月 9 日に投稿された IP and Domain Restrictions for Windows Azure Web Sitesの翻訳です。

編集メモ:今回は、Windows Azure Web サイトチームの主任プログラムマネージャーリードを務める Stefan Schackow の記事をご紹介します。

これまで、Windows Azure Web サイト (WAWS) で IP およびドメインの制限を構成できるようにしてほしいというご要望を多数いただいておりましたが、今回この機能が導入されました。IP およびドメインの制限は新しいセキュリティ オプションで、先日導入された動的 IP アドレス制限 (DIPR) 機能と併用可能です。

IP およびドメインを制限する機能では、一連の IP アドレスまたはアドレス範囲に対して、Web サイトに対するアクセスを許可/拒否することができます。Windows Azure Web サイトでは、Web サイト内の web.configファイルを使用すると、この機能の有効化と無効化、および動作のカスタマイズが可能です。

IIS で使用可能な IP およびドメインの制限機能の概要については、iis.net の Web サイト (英語)のページを参照してください。個々の構成要素および属性の詳細な説明については、TechNet のページ (英語)を参照してください。

次に示すのは、ipSecurityの構成を行うサンプル スニペットです。このコードは、ipAddress属性と subnetMask属性で指定した範囲のアドレスからのアクセスのみを許可するものです。allowUnlistedfalseに設定すると、Web サイトに送信された HTTP 要求のうち、明示的に指定された個々のアドレスまたはアドレス範囲のもののみが許可されます。add要素の子属性である allowed属性を trueに設定すると、アドレスとサブネットによって、Web サイトへのアクセスが許可されるアドレス範囲が指定されます。

許可された IP アドレス範囲以外から Web サイトへ要求が送信された場合、denyAction属性で指定されたとおり、HTTP 404 未検出エラーが返されます。

この機能と併用可能な DIPR 機能と同様に、Windows Azure Web サイトは、IP およびドメイン制限モジュールが「見る」クライアント IP アドレスが、HTTP 要求の送信元であるインターネット クライアントの実際の IP アドレスであることを保証します。


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

$
0
0

このポストは、11 月 6 日に投稿された Migrating a Java Spring Framework Application to Windows Azureの翻訳です。

マイクロソフトは、Windows Azure の Java 関連テクノロジを多数ご紹介している、実践形式の新しいチュートリアル (英語 : 日本語版準備中)とサンプル コードを公開しました。このガイドでは、チュートリアル形式で Java Spring Framework アプリケーション (PetClinic サンプル アプリケーション) を Windows Azure クラウドに移行する方法を説明しています。このガイドで使用されているコードは、GitHub (英語)でも公開されています。Java 開発者の皆様は、ぜひこの新しいサンプルとチュートリアルをダウンロードしてお試しください。

詳細

Windows Azure はオープンなクラウド プラットフォームであり、Microsoft .NET、Java、Node.js、PHP、Python、Ruby などの広範なプログラミング言語やフレームワークをサポートしています。このガイドは、一般的な Java アプリケーションを Windows Azure クラウドに移行する方法を紹介しているもので、特に Java 開発者を対象としています。一般的な Spring Framework のサンプル アプリケーション (Java PetClinic) をチュートリアル形式で取り扱い、Windows Azure Java SDK for Eclipse、Memcached を使用する Windows Azure キャッシュ、Windows Azure クラウド サービス、Windows Azure SQL データベース、その他のさまざまな Java アプリケーションで使用される各種テクノロジについて説明しています。

Windows Azure クラウド サービス (PaaS) か、Windows Azure 仮想マシン (IaaS) か?

基本的に、Web サイトなどのアプリケーション層を Windows Azure で実行する方法は、2 つあります。1 つ目は、Windows Azure クラウド サービスでプラットフォームとしてのサービス (PaaS) を利用する方法で、2 つ目は、Windows Azure 仮想マシン (VM) でインフラストラクチャとしてのサービス (IaaS) を利用する方法です。どちらの場合も、世界各地に存在するデータセンター (米国に 4 か所、ヨーロッパに 2 か所、アジアに 2 か所) のいずれかでアプリケーションをホストできます。

  • Windows Azure クラウド サービスでは、開発者がアプリケーションに専念することができます。インスタンスのプロビジョニングと保守はプラットフォームが自動的に実行し (Windows Hyper-V 仮想マシンとして扱われます)、この上でアプリケーション層が実行されます。このインスタンスはスケール アウトが可能で、1 つのインスタンスから数百のクローンを作成できます。また、負荷分散処理は自動的に行われます。インスタンスのサイズは変更可能 (仮想のコア数とメモリ容量を指定可能) ですが、OS 層の修正プログラムやセキュリティ更新プログラムの適用などの管理は、基本的に Windows Azure が担当します。このガイドでは、サンプル アプリケーションの Java Pet Clinic を Windows Azure クラウド サービスで実行する場合を取り扱います。
  • Windows Azure 仮想マシンでは、開発者が自身の仮想マシン イメージを作成します。この仮想マシンについては、インストールされるソフトウェアのすべてを含むインストールと管理を開発者が担当します。Java 開発者の場合、Windows や一部の Linux ディストリビューションといったさまざまな事前構築済みの仮想マシン イメージを使用できます。これも、Windows Azure クラウドで Java アプリケーションを実行するうえで優れた方法です。開発者が OS と仮想マシンを低レベルで管理し、mySQL などのソフトウェアを任意の数の仮想マシンに直接インストールできるため、アプリケーション層からデータ層まで完全なアプリケーションを構築することが可能です。この場合、ほとんどの Java アプリケーションを一切コードを変更することなく、または多少のコード変更で簡単に移行できます。負荷分散もセットアップ可能で、複数の仮想マシン (たいていの場合 Tomcat/JSP 層を実行) に対し、ラウンドロビン方式で負荷分散できます。ただし、Windows Azure クラウド サービスとは異なり、社内で実行されている仮想マシンと同様に、開発者がセキュリティ修正プログラムの適用などを含む仮想マシンの管理を行う必要があります。この新しいチュートリアルでは、Java アプリケーションを Windows Azure クラウド サービスで実行する場合について取り扱っていますが、開発者の皆様には、Windows または Linux のいずれかの仮想マシンを使用した Windows Azure 仮想マシンもお試しいただくことをおすすめします。

Windows Azure プラットフォーム上の Spring Framework 

この新しいガイドでは、最近更新された PetClinic をサンプルとして採用しました。これは、Spring Framework のサンプルの中でも PetClinic が Spring Data JPA、MVC、AOP、JMX、EhCache、Logback などのスケーラブルな Java EE アプリケーションの作成に使用される企業向けテクノロジのデモを行ううえで皆様に馴染みがあるためです。ここでは、PetClinic を拡張して、一時的な障害処理を追加し、さらに Memcached を AOP 経由で Azure キャッシュに追加します。

Eclipse や STS に慣れている Java 開発者の方には、Windows Azure Toolkit for Eclipse with Java (英語)を提供しています。このツールキットには、Windows Azure で Eclipse を使用して Java の開発を行う場合に使用する次の支援リソースが含まれています。

  • Windows Azure Plugin for Eclipse with Java
  • Microsoft JDBC 4.0 Driver for SQL Server、Windows Azure SQL データベース
  • Apache Qpid Client Libraries for JMS のパッケージ
  • Windows Azure Libraries for Java のパッケージ
  • Windows Azure アクセス制御サービスのフィルター
  • Windows Azure の一般的なプラグイン

このガイドでは、Windows Azure Plugin for Eclipse with Java および Microsoft JDBC 4.0 Driver for SQL Server を使用します。Eclipse 用プラグインでは、Windows Azure サービスおよび Windows Azure のエミュレーター用の Java ラッパーが提供されます。

まとめ

オープンなクラウド プラットフォームである Windows Azure では、さまざまなプログラミング言語とフレームワークをサポートしています。この新しい Windows Azure における Java 関連のチュートリアル (英語 : 日本語版準備中)では、Windows Azure の Java 関連テクノロジが実践形式で多数紹介されています。Java 開発者の皆様はこのガイドをぜひご参照いただき、サンプル コードをお試ください。 

Java v. 0.5.0 用 Windows Azure ストレージ クライアント ライブラリ

$
0
0

このポストは、12 月 19 日に Windows Azure Storage Team が投稿した Windows Azure Storage Client Library for Java v. 0.5.0の翻訳です。

マイクロソフトは、Java 用 Windows Azure ストレージ クライアントの更新版のリリースを発表しました。今回のリリースには、ログ記録のサポート、新規 API オーバーロードの追加、2013-08-15 RESTバージョンのストレージ サーバーの完全サポートなど、大きな機能変更が含まれています。詳細についてはこちらのページを参照してください。ソース コードは、これまでと同様にすべて Github (英語)から入手できます (場所が新しくなっていますのでご注意ください)。最新のバイナリ ファイルは Maven からダウンロードできます

<dependency>

<groupId>com.microsoft.windowsazure.storage</groupId>

<artifactId>microsoft-windowsazure-storage-sdk</artifactId>

<version>0.5.0</version>

</dependency>

エミュレーターについての案内

現在、2013-08-15 RESTはストレージ エミュレーターのサポート対象外となっています。今後 2 ~ 3 か月以内にリリースが予定されている Windows Azure ストレージ エミュレーターの更新版では、これらの新機能が完全にサポートされます。現行バージョンのストレージ エミュレーターで開発を行う場合、暫定的に Bad Request エラーが返されます。更新版のエミュレーターがリリースされるまでは、2013-08-15 RESTバージョンを活用するには Windows Azure ストレージ アカウントで開発、テストを行う必要があります。

サンプル

マイクロソフトは、サンプル (英語)のセットを Github に用意しました。このサンプルは、クライアントをセットアップして抽象化ストレージで実行する際に役立ちます。また、主要なシナリオをいくつかご紹介しています。このサンプルを Eclipse で実行する場合は、サンプル プロジェクトを読み込み、Utility.java の次の行を書き換えてストレージの認証情報を提供します。

public static final String storageConnectionString = "DefaultEndpointsProtocol=http;AccountName=[ACCOUNT_NAME];AccountKey=[ACCOUNT_KEY]";

サンプルの実行中に Fiddler でトラフィックを検査する場合は、Utility.java の次の 2 行のコメントを解除します。

// System.setProperty("http.proxyHost", "localhost");

// System.setProperty("http.proxyPort", "8888");

Utiltity.java を更新した後、実行するプロジェクトを右クリックして [Run As Java Application] を選択します。

パッケージ化およびバージョン管理に関する注意

今回のリリースで、ストレージのパッケージが Windows Azure SDK for Java から分離されました。現在既存の SDK を使用している開発者は、これに対応して依存関係を更新する必要があります。また、新しい構造が導入されたためパッケージ名が変更されています。

  • com.microsoft.windowsazure.storage– RetryPolicies、LocationMode、StorageException、StorageCredentials など。サービス全体に共通のすべてのパブリック クラス。
  • com.microsoft.windowsazure.storage.blob– BLOB 実装時の利便性を考慮し、Windows Azure BLOB を使用するアプリケーションではこの名前空間を import ステートメントに含むようにします。
  • com.microsoft.windowsazure.storage.queue– キュー実装時の利便性を考慮し、Windows Azure キューを使用するアプリケーションではこの名前空間を import ステートメントに含むようにします。
  • com.microsoft.windowsazure.storage.table– テーブル実装時の利便性を考慮し、Windows Azure テーブルを使用するアプリケーションではこの名前空間を import ステートメントに含むようにします。

今回のリリースで変更された点の詳細については、後述の「変更ログと大幅な変更点」のセクションを参照してください。

また、マイクロソフトが提供するストレージ クライアント SDK コンポーネントのすべてで、SemVer (英語)の仕様を採用します。これにより、SDK を使用する開発者にとって、一貫性のある予測可能なバージョン管理が実現されるようになります。

新機能

Java クライアント ライブラリ バージョン 0.5.0 では、2013-08-15 RESTバージョンのサービスが完全にサポートされました (サポート対象の機能についての詳細はこちら)。また、クライアントのその他の主要な機能強化についても以下で説明します。

地理冗長ストレージへの読み取りアクセスのサポート

今回のリリースでは、セカンダリ拠点に存在するストレージ アカウント データへの読み取りアクセスが完全にサポートされました。この機能は、特定のストレージ アカウントに対して管理ポータルから有効にする必要があります。地理冗長ストレージの読み取りアクセスについての詳細は、こちらのページを参照してください。この記事で言及されているとおり、CloudBlobClient、CloudTableClient、CloudQueueClient の各クライアントに対して getServiceStats API が用意されており、この API を使用すると、レプリケーションのステータスと各サービスの LastSyncTime を簡単に取得できます。次に示す例では、クライアント オブジェクトで LocationMode を設定し、getServiceStats を呼び出しています。LocationMode は、RequestOptions オブジェクトで設定すると、要求ごとに構成することもできます。

CloudStorageAccount httpAcc = CloudStorageAccount.parse(connectionString);

CloudTableClient tClient = httpAcc.createCloudTableClient();

// getServiceStats はセカンダリのエンドポイントでのみサポートされているため、LocationMode は SECONDARY_ONLY に設定する

tClient.setLocationMode(LocationMode.SECONDARY_ONLY);

ServiceStats stats = tClient.getServiceStats();

Date lastSyncTime = stats.getGeoReplication().getLastSyncTime();

System.out.println(String.format("Replication status = %s and LastSyncTime = %s",stats.getGeoReplication().getStatus().toString(), lastSyncTime != null ? lastSyncTime.toString(): "empty"));

テーブルのサポート対象プロトコルの拡張 (JSON)

前回のリリースでは、テーブルのトラフィック送信時にはすべて AtomPub プロトコルが使用されていました。今回のリリースでは、既定のプロトコルが JSON になり、メタデータの量が最小化されました。このプロトコルの詳細およびペイロードのサンプルは、こちらのページ (英語)を参照してください。今回の機能強化により、クライアントでは、要求のペイロード サイズが大幅に削減されると共に、要求の処理による CPU 負荷も減少します。このため、クライアント アプリケーションをより大規模にスケーリングできるようになると共に、テーブル操作全体の待機時間 (レイテンシ) が短縮されます。次の例は、クライアント オブジェクトでの tablePayloadFormat の設定例を示したものです。tablePayloadFormat は、TableRequestOptions オブジェクトで設定すると、要求ごとに構成することもできます。

CloudStorageAccount httpAcc = CloudStorageAccount.parse(connectionString);

CloudTableClient tClient = httpAcc.createCloudTableClient();

// ペイロードの書式を JsonNoMetadata に設定する

tableClient.setTablePayloadFormat(TablePayloadFormat.JsonNoMetadata);

JsonNoMetadata を使用する場合、クライアント ライブラリは、クライアントから提供される POJO エンティティの種類に関する情報を検査し、この情報を基にプロパティの種類を「推察」します。さらに、DynamicTableEntity でクエリを実行する場合や、複数の種類のエンティティを混在して返す複雑なクエリを実行する場合など、シナリオによっては、クライアントがプロパティの種類の情報を実行時に提供することがあります。このようなときは、PropertyResolver を実装して、サービスから受け取ったデータに基づいて各プロパティに対応する EdmType 返せるようにします。次のサンプル コードは、PropertyResolver の実装例です。

public static class Class1 extends TableServiceEntity implements PropertyResolver {

private String A;

private byte[] B;

public String getA() {

return this.A;

 }

public byte[] getB() {

return this.B;

}

public void setA(final String a) {

this.A = a;

}

public void setB(final byte[] b) {

this.B = b;

}

@Override

public EdmType propertyResolver(String pk, String rk, String key, String value) {

if (key.equals("A")) {

return EdmType.STRING;

}

else if (key.equals("B")) {

return EdmType.BINARY;

}

return null; 

}

}

この例では、次に示すように PropertyResolver は TableRequestOptions に設定されています。

Class1 ref = new Class1();

ref.setA("myPropVal");

ref.setB(new byte[] { 0, 1, 2 });

ref.setPartitionKey("testKey");

ref.setRowKey(UUID.randomUUID().toString());

options.setPropertyResolver(ref); 

テーブル挿入操作の最適化

前のバージョンの REST API では、挿入操作で Prefer ヘッダーがサポートされていなかったため、サービスは応答の本文でエンティティの内容を「エコー バック」するだけでした。今回のリリースでは、バッチ操作の一部として実行されるものも含めてテーブル挿入操作はすべて Prefer: return-no-content ヘッダーで送信されるため、コールバックは行われません。この最適化により、挿入操作による待機時間 (レイテンシ) が大きく短縮されます。ただし、挿入操作が正常に完了した場合に TableResult から返される HTTP ステータス コードは、201 (作成されました) ではなく 204 (コンテンツがありません) である点に注意してください。insert(TableEntity, ブール値) メソッドで true を指定すると、これまでと同様にエン���ィティの内容をエコー バックします。

テーブルのリフレクション操作の最適化

クライアントが POJO オブジェクトをテーブル サービスに保持している場合は、リフレクション呼び出しを繰り返し実行しないように、クライアントがその種類とプロパティ情報をキャッシュすることができるようになりました。この最適化により、クエリやその他のテーブル操作の実行による CPU 負荷が大きく低減されます。TableServiceEntity.setReflectedEntityCacheDisabled(true) と設定すると、クライアントはキャッシュを行いません。

新しい API とオーバーロード

お客様からのフィードバックにお応えし、下記の API サーフェイスを拡張して利便性の向上を図りました。

  • CloudBlob.downloadRange
  • CloudBlob.downloadToByteArray
  • CloudBlob.downloadRangeToByteArray
  • CloudBlob.uploadFromByteArray
  • CloudBlob.uploadFromByteArray
  • CloudBlob.downloadToFile
  • CloudBlob.uploadFromFile
  • CloudBlockBlob.uploadText
  • CloudBlockBlob.downloadText

ログ記録

バージョン 0.5.0 では、SLF4J (英語)ログ ファサードを使用してログを記録することができます。これにより、ストレージ API と組み合わせてさまざまなログ フレームワークを使用し、要求実行時のログ情報を記録することができます。ログに記録される情報については、下の表を参照してください。アプリケーションのデバッグ作業でクライアントを支援するため、次期リリースではログに記録される情報をさらに拡充する予定です。

ログ出力データ

ログの各行には、次のデータが含まれます。

  • クライアントの要求 ID: OperationContext でユーザーが指定した要求 ID
  • イベント: 自由形式のテキスト
  • ユーザーが選択した基盤ログ フレームワークによるその他の情報

たとえば、基盤となるログ フレームワークに Simple (英語)を選択した場合、ログ出力の行は次のようになります。

[main] INFO ROOT - {c88f2fe5-7150-467b-8571-7aa40a9a3e27} : {Starting operation.}

トレースのレベル

レベル

イベント

ERROR

例外を内部的に処理できない、または処理しないでユーザーにスローする場合は、エラーとしてログに記録されます。

WARN

例外をキャッチし内部的に処理する場合は、警告としてログに記録されます。この場合の主なユースケースとしては、処理の再試行が挙げられます。その際、ユーザーが再試行できるように、例外はユーザーにスロー   バックされません。また、404 エラーを内部的に処理する CreateIfNotExists 操作などもこの場合に該当します。

INFO

下記の情報がログに記録されます。

      
  • ユーザーがメソッドを呼び出して操作を開始した直後に、URI* やクライアントの要求 ID など、要求の詳細がログに記録されます。
  •   
  • Sending Request Start/End、Upload        Data Start/End、Receive Response Start/End、Download        Data Start/End などの重要なログには、タイムスタンプが記録されます。
  •   
  • ヘッダーを受け取った直後に、要求 ID や HTTP ステータス コードなど、応答の詳細がログに記録されます。
  •   
  • 操作が異常終了してストレージ クライアントが再試行する場合は、その理由と次の再施行を行うタイミングがログに記録されます。
  •   
  • クライアント側のタイムアウトはすべて、保留中の要求の実行をストレージ クライアントが破棄するときにログに記録されます。

DEBUG

現時点では、このレベルのログは記録されません。

TRACE

現時点では、このレベルのログは記録されません。

*ログ記録が有効なときに SAS を使用する場合、SAS トークン自身がログに記録されるので注意が必要です。このような場合は、アプリケーションのログ出力を保護する必要があります。

ログの記録を有効にする

ここで重要となるコンセプトは、クライアントがトレース処理に提供するオプトイン/オプトアウト モデルです。通常のアプリケーションでは、指定したクラスで一定の冗長性を持たせながらトレースすることが一般的です。ほとんどのクライアント アプリケーションではこの方法で問題ありませんが、拡張性を備えたクラウド アプリケーションの場合、この方法ではユーザーが必要とする量よりもはるかに大量のデータが生成される可能性があります。このため、マイクロソフトが提供するオプトイン モデルのログ記録では、特定の冗長性を持つようにクライアントでリスナーを構成できると共に、選択された場合にのみ特定の要求のログだけを記録することが可能です。この設計により、必然的に、特定のクラスまたは層によるすべてのトラフィックを記録する「水平的」なログ記録ではなく、特定の要求で対象とされたスタックの層にまたがって「垂直的」なログ記録を実行できるようになりました。

もう 1 つの重要なコンセプトは、ファサード ログ記録モデルです。SLF4J (英語)はファサードであり、ログ フレームワークを提供するものではありません。つまり、ユーザーは、JDK のロガーで構築されたものや、その他のオープン ソースのロガーなど、基盤となるログ記録システムを使用可能です。SLF4J (英語)のサイトに、互換性のあるロガーのリストが記載されています。使用するロガーが決定し、それに対応する jar ファイルをクライアントに追加すると、選択したフレームワークにファサードをバインドすることができます。アプリケーションは、該当するフレームワーク専用の設定を使用してログを記録します。この結果、ユーザーが既にアプリケーション用のログ フレームワークを選択している場合、ストレージ SDK は個別のものを要求せずに、そのフレームワークを使用します。このファサード モデルにより、開発プロセス全体でフレームワークを簡単に変更できるため、ログ フレームワークを選ぶ際の柔軟性が高まります。

ログフレームワークの選択

ログを記録するためには、まず、ログ フレームワークを選択します。既にログ フレームワークを使用している場合は、SLF4J をバインドする jar ファイル (英語)のうち対応するものをクラスパスに追加するか、Maven に依存関係を追加します。ログ フレームワークを使用していない場合は、1 つ選択してクラスパスに追加するか、Maven に依存関係を追加します。さらに、SLF4J をネイティブで実装していない場合は、SLF4J をバインドする jar ファイル (英語)のうち対応するものを追加する必要があります。SLF4J は Simple (英語)と呼ばれる独自のロガー実装を採用しています。下に示すのは、その使用例です。SLF4J (英語)から slf4j-simple-1.7.5.jar をダウンロードし、クラスパスに追加するか、または次のコードを Maven の依存関係に追加します。

<dependency>

<groupId>org.slf4j</groupId>

<artifactId>slf4j-simple</artifactId>

<version>1.7.5</version>

</dependency>

 

これにより、コンソールに記録されるログのレベルが既定で INFO になります。ログ記録の設定変更に関する詳細は、Simple (英語)を参照してください。

1. SDK でログ記録を有効にする

既定では、Azure ストレージの Java SDK は、ログ フレームワークが存在しそれに対応する SLF4J がバインドされていても、ログを生成しません。このため、Azure ストレージのログが不要な場合は、ログ フレームワークの設定を編集する必要はありません。ログ記録が有効化されると、既定でルート ロガーの設定が使用されますが、要求ごとに他のロガーを指定することもできます。

1: すべての要求のログを記録する

OperationContext.setLoggingEnabledByDefault(true);

2: 単一の要求のログを記録する

OperationContext ctx = new OperationContext();

ctx.setLoggingEnabled(true);

blockBlobRef.upload(srcStream, -1, null /* accessCondition */, null /* requestOptions */, ctx);

3:特定の要求に対し特定のロガーを使用する

OperationContext ctx = new OperationContext();

// OperationContext のログを記録する

ctx.setLoggingEnabled(true);

// SLF4J の LoggerFactory でロガーの名前を取得し、このロガーを使用する

// このロガー設定には、ログの場所とログを記録するレベルが記述される

ctx.setLogger(LoggerFactory.getLogger(“MyLogger”));

blockBlobRef.upload(srcStream, -1, null /* accessCondition */, null /* requestOptions */, ctx);

ストレージ サービスのログ記録機能とクライアント側のログ記録機能を併用すると、クライアント側とサーバー側の両方の視点から、アプリケーションを完全に監視することができます。

変更ログと大幅な変更点

既に述べたように、このリリースでは 2013-08-15 REST バージョンがサポートされています。このバージョンの機能および変更点の詳細については、MSDNこちら��ブログ記事をご確認ください。REST の変更の他に、今回のリリースではクライアント側でも機能の変更や追加が実施されています。主な変更点を以下にまとめました。また、変更ログ (英語)大幅な変更点 (英語)の詳細は Github でご覧いただけます。

共通

  • パッケージの構造が見直されました。
  • RetryResult が RetryInfo に変更され、機能が追加されました。
  • 要求の処理中に発生するイベント操作 (イベントの生成を含む) が同期されなくなりました (スレッドの安全性がイベント リスナーの CopyOnWriteArrayList で保証されるようになりました)。
  • 接続が確立される前に OperationContext.sendingRequest イベントが生成されるようになり、ヘッダーを変更できるようになりました。

BLOB

  • BLOB の downloadRange が Stream にダウンロードできるようになりました。これまでの downloadRange は、downloadRangeToByteArray に名前が変更されました。
  • ページ BLOB のスパース化機能が廃止されました。
  • CloudBlobContainer.createIfNotExist の名前が CloudBlobContainer.createIfNotExistsに変更されました。
  • CloudBlobClient.streamMinimumReadSizeInBytes が削除されました。この機能は、CloudBlob.streamMinimumReadSizeInBytes (クライアントごとではなく BLOB ごとに設定可能) で使用できます。
  • CloudBlobClient.pageBlobStreamWriteSizeInBytes と CloudBlobClient.writeBlockSizeInBytes が削除されました。この機能は、CloudBlob.streamWriteSizeInBytes で使用できます。

テーブル

  • Id フィールド (および getId、setId) が TableResult から削除されました。
  • CloudTable.createIfNotExist の名前が CloudTable.createIfNotExistsに変更されました。
  • テーブルの挿入操作時に、内容をエコー バックしないようになりました。insert(TableEntity, ブール値) メソッドで true を指定すると、再び内容をエコー バックするようにできます。この変更により、挿入操作が正常に完了すると、TableResult の HTTP ステータス コードが 201 (作成されました) ではなく 204 (コンテンツがありません) になります。
  • ペイロードの既定の形式が JsonMinimalMetadata になりました (AtomPub から変更)。ペイロードの形式は、CloudTableClient.setTablePayloadFormat を使用するとすべてのテーブルの要求に対して一括で指定でき、TableRequestOptions.setTablePayloadFormat を使用すると各要求に対して個別に指定できます。

キュー

  • CloudQueue.createIfNotExist の名前が CloudQueue.createIfNotExistsに変更されました。

まとめ

マイクロソフトは、今後も開発者のエクスペリエンスが向上するように Windows Azure ストレージを改良してまいります。ご意見やご要望がありましたら、お気軽にページ下部のコメント欄、フォーラム、または GitHub までお寄せください。また、何らかの問題が発生した場合は、GitHub にご報告いただけますと解決策が得られます。

Joe Giardino、Veena Udayabhanu、Emily Gerner、Adam Sorrin

関連情報

ソース (Github、英語)

Maven (英語)

大幅な変更点 (英語)

変更ログ (英語)

Windows Azure ストレージのリリース - CORS、JSON、分単位メトリックなど各種機能の導入

Windows Azure テーブル: JSON の紹介 (英語)

Windows Azure ストレージの冗長オプションと読み取りアクセス地理冗長ストレージ

SemVer の仕様 (英語)

C++ 用 Windows Azure ストレージ クライアント ライブラリのプレビュー版をリリース

$
0
0

このポストは、12 月 20 日に Windows Azure Storage Team が投稿した Windows Azure Storage Client Library for C++ Previewの翻訳です。

マイクロソフトは、C++ 用 Windows Azure ストレージ クライアント ライブラリを新たにリリースしました。現時点ではプレビュー リリースですので、このライブラリは本番環境のコードでは使用しないでください。また、一般提供版のインターフェイスの改良および変更に活用するため、皆様にお試しいただき、フィードバックをお寄せいただけますと幸いです。この記事では、ライブラリの概要について説明します。

Windows Azure ストレージについての詳細は、「SOSP 論文 - Windows Azure Storage: 強力な一貫性を持つ高可用性クラウド ストレージ サービス (英語)」を参照してください。

エミュレーターについての案内

このライブラリでは 2013-08-15 REST バージョンを使用していますが、このバージョンはまだストレージ エミュレーターではサポートされていません。Windows Azure ストレージ エミュレーターの更新版が来月中にリリースされる予定です。こちらでは、新機能が完全にサポートされます。現行バージョンのストレージ エミュレーターで開発を行うと、暫定的に Bad Request エラーが返されます。新しいエミュレーターのリリースまでは、2013-08-15 REST バージョンの新機能を使用するには Windows Azure ストレージ アカウントで開発、テストを行う必要があります。

サポート対象のプラットフォーム

今回のリリースでは、Visual Studio 2012 (v110) と Visual Studio 2013 (v120) の両方のプラットフォームのツールセットで、x64 と x86 のバージョンを提供します。このため、パッケージには次の 8 個のビルドが含まれています。

  1. リリース、x64、v120
  2. デバッグ、x64、v120
  3. リリース、Win32、v120
  4. デバッグ、Win32、v120
  5. リリース、x64、v110
  6. デバッグ、x64、v110
  7. リリース、Win32、v110
  8. デバッグ、Win32、v110

配布場所

このライブラリは NuGet (英語)からダウンロードできます。また、完全なソース コードは GitHub (英語)で入手できます。NuGet パッケージは CoApp ツール (英語)を使用して作成されており、次の 3 つのパッケージで構成されています。

  • wastorage.0.2.0-preview.nupkg: このパッケージには、アプリケーションの開発に必要な、ヘッダーと LIB ファイルが含まれています。ユーザーはこのパッケージをインストールする必要があり、これには redist パッケージとの依存関係が設定されているため、自動的に redist パッケージが NuGet から自動的にインストールされます。
  • wastorage.redist.0.2.0-preview.nupkg: このパッケージには、アプリケーションの実行と再配布に必要な DLL ファイルが含まれています。
  • wastorage.symbols.0.2.0-preview.nupkg: このパッケージには、各 DLL ファイルに対応したシンボルが含まれています。オプションのパッケージです。

パッケージは C++ REST SDK (英語)とも依存関係があり、こちらも自動的に NuGet からインストールされます。C++ REST SDK (コードネーム “Casablanca”) (英語)は、クライアントとサーバー間のクラウドベースの通信をネイティブ コードで実行するためのマイクロソフトのプロジェクトであり、非同期 C++ バインディングを HTTP、JSON、および URI に提供することで、複数のプラットフォームでネイティブ コードから REST サービスへのアクセスをサポートしています。Windows Azure ストレージ クライアント ライブラリではこれを使用して、Windows Azure ストレージ BLOB、キュー、およびテーブルの各サービスと通信しています。

使用可能な機能

ここでは、REST API と直接通信するのではなく Windows Azure ストレージ クライアント ライブラリを使用することによって実現される機能について、概要を説明します。

  • Windows Azure ストレージ REST API 2013-08-15バージョン全体を簡単に使用可能な形で実装
  • 特定の要求が失敗したときの再試行に指数または線形のバック オフ アルゴリズムを使用する再試行ポリシーを導入
  • 認証モデルを合理化し、共有鍵と共有認証署名の両方をサポート
  • 操作コンテキストと ETW のログを使用して、要求の詳細と結果を確認
  • BLOB のサイズや種類を問わず、ユーザーの構成に応じてブロックまたはページ単位で BLOB を並列アップロード
  • 特定のアップロード用またはダウンロード用 API に対応していなくても BLOB の読み取りおよび書き込みが可能な BLOB ストリーム
  • BLOB のアップロード用とダウンロード用のすべての API で MD5 を完全にサポート
  • 2013 年 11 月に新たに Windows Azure ストレージでのサポートが開始された JSON (英語)を使用したテーブル層
  • エンティティ グループ トランザクションがテーブル サービスでサポートされ、1 つのトランザクションで複数の操作が可能に

読み取りアクセス地理冗長ストレージのサポート

今回のリリースでは、セカンダリ拠点に存在するストレージ アカウント データへの読み取りアクセスが完全にサポートされました。この機能を使用するには、管理ポータルから特定のストレージ アカウントに対して有効化する必要があります。読み取りアクセス地理冗長ストレージの詳細については、こちらのページを参照してください。

使用方法

NuGet パッケージをインストールすると、使用する必要があるヘッダー ファイルはすべて “was” (Windows Azure Storage の略) という名前のフォルダーに格納されます。このフォルダー内にあるヘッダー ファイルのうち、次のものは特に重要です。

  • blob.h: BLOB サービスに関連するすべての型の宣言に使用します。
  • queue.h: キュー サービスに関連するすべての型の宣言に使用します。
  • table.h: テーブル サービスに関連するすべての型の宣言に使用します。
  • storage_account.h: cloud_storage_account 型を宣言します。この型を使用すると、アカウント名と鍵の組み合わせ、または接続文字列を使用してサービスのクライアント オブジェクトを簡単に作成できます。
  • retry_policies.h: すべての操作で使用可能な再試行ポリシーを個別に宣言します。

これらを使用する際は、まず、使用するヘッダーをインクルードします。

#include"was/storage_account.h"

#include"was/queue.h"

#include"was/table.h"

#include"was/blob.h"

ここでは、cloud_storage_account オブジェクトを作成することにします。これは、後述のコードでサービスのクライアント オブジェクトを作成する際に必要です。この例では接続の安全性を考慮して https を使用しますが、アプリケーションのデバッグを行う際には http を使用すると非常に便利です。

wa::storage::cloud_storage_account storage_account = wa::storage::cloud_storage_account::parse(U("AccountName=<account_name>;AccountKey=<account_key>;DefaultEndpointsProtocol=https"));

BLOB

ここでは、まず BLOB コンテナーを作成します。さらに、「何らかのテキスト」を追加して、それをダウンロードし、最後にコンテナー内のすべての BLOB をリスト表示します。

// BLOB コンテナーを作成

wa::storage::cloud_blob_client blob_client = storage_account.create_cloud_blob_client();

wa::storage::cloud_blob_container container = blob_client.get_container_reference(U("mycontainer"));

container.create_if_not_exists();

// BLOB をアップロード

wa::storage::cloud_block_blob blob1 = container.get_block_blob_reference(U("myblob"));

blob1.upload_text(U("some text"));

// BLOB をダウンロード

wa::storage::cloud_block_blob blob2 = container.get_block_blob_reference(U("myblob"));

utility::string_t text = blob2.download_text();

// BLOB をリスト表示

wa::storage::blob_result_segment blobs = container.list_blobs_segmented(wa::storage::blob_continuation_token());

テーブル

次に示すサンプルでは、まずテーブルを作成し、異なる型のプロパティを複数持つエンティティを挿入し、最後にそのエンティティを取得します。取得操作の最初に、ポイント クエリを実行して特定のエンティティを取得します。このクエリ操作では、PartitionKey が “partition” と等しく、RowKey が “m” 以上のすべてのエンティティに対してクエリを実行します。これにより、最終的に、サンプルで挿入した元のエンティティが取得されます。

Windows Azure テーブルについての詳細は、「テーブル サービス データ モデルについて」および「Windows Azure テーブルの活用方法 (英語)」の記事を参照してください。

// テーブルを作成

wa::storage::cloud_table_client table_client = storage_account.create_cloud_table_client();

wa::storage::cloud_table table = table_client.get_table_reference(U("mytable"));

table.create_if_not_exists();

// テーブル エンティティを挿入

wa::storage::table_entity entity(U("partition"), U("row"));

entity.properties().insert(wa::storage::table_entity::property_type(U("PropertyA"), wa::storage::table_entity_property(U("some string"))));

entity.properties().insert(wa::storage::table_entity::property_type(U("PropertyB"), wa::storage::table_entity_property(utility::datetime::utc_now())));

entity.properties().insert(wa::storage::table_entity::property_type(U("PropertyC"), wa::storage::table_entity_property(utility::new_uuid())));

wa::storage::table_operation operation1 = wa::storage::table_operation::insert_or_replace_entity(entity);

wa::storage::table_result table_result = table.execute(operation1);

// テーブル エンティティを取得

wa::storage::table_operation operation2 = wa::storage::table_operation::retrieve_entity(U("partition"), U("row"));

wa::storage::table_result result = table.execute(operation2);

// テーブル エンティティのクエリを実行

wa::storage::table_query query;

query.set_filter_string(wa::storage::table_query::combine_filter_conditions(

wa::storage::table_query::generate_filter_condition(U("PartitionKey"), wa::storage::query_comparison_operator::equal, U("partition")),

wa::storage::query_logical_operator::and,

wa::storage::table_query::generate_filter_condition(U("RowKey"), wa::storage::query_comparison_operator::greater_than_or_equal, U("m"))));

std::vector<wa::storage::table_entity> results = table.execute_query(query);

キュー

最後のサンプルでは、まずキューを作成し、メッセージを追加し、そのメッセージを取得して、最後にこれを更新します。

// キューを作成

wa::storage::cloud_queue_client queue_client = storage_account.create_cloud_queue_client();

wa::storage::cloud_queue queue = queue_client.get_queue_reference(U("myqueue"));

queue.create_if_not_exists();

// キューにメッセージを追加

wa::storage::cloud_queue_message message1(U("mymessage"));

queue.add_message(message1);

// キューのメッセージを取得

wa::storage::cloud_queue_message message2 = queue.get_message();

// キューのメッセージを更新

message2.set_content(U("changedmessage"));

queue.update_message(message2, std::chrono::seconds(30), true);

デバッグ方法

何らかの問題が発生した場合、呼び出しのいずれかから例外が発生したことが通知されます。この例外は wa::storage::storage_exception という型で、発生した問題に関する詳細な情報を含んでいます。次のコードをご覧ください。

try

{

blob1.download_attributes();

}

catch (const wa::storage::storage_exception& e)

{

std::cout << "例外: "<< e.what() << std::endl;

ucout << U("開始時刻: ") << e.result().start_time().to_string() << U("終了時刻: ") << e.result().end_time().to_string() << U(" の要求で、HTTP ステータス コード ") << e.result().http_status_code() << U(" が返されました。サーバーから報告された要求 ID : ") << e.result().service_request_id() << std::endl;

}

存在しない BLOB で実行しようとした場合、このコードでは次のような文字列が記録されます。

例外: The specified blob does not exist.

開始時刻: Fri, 13 Dec 2013 18:31:11 GMT、終了時刻: Fri, 13 Dec 2013 18:31:11 GMT の要求で、HTTP ステータス コード 404 が返されました。サーバーから報告された要求 ID: 5de65ae4-9a71-4b1d-9c99-cc4225e714c6

このライブラリでは wa::storage::operation_context という型も提供されています。これはすべての API をサポートしていて、操作中の処理内容を詳細に取得できます。これに関して、次のコードで説明します。

wa::storage::operation_context context;

context.set_sending_request([] (web::http::http_request& request, wa::storage::operation_context)

{

ucout << U("次の宛先に要求を送信中: ") << request.request_uri().to_string() << std::endl;

});

context.set_response_received([] (web::http::http_request&, const web::http::http_response& response, wa::storage::operation_context)

{ ucout << U("理由メッセージ: ") << response.reason_phrase() << std::endl;

});

try

{

blob1.download_attributes(wa::storage::access_condition(), wa::storage::blob_request_options(), context);

}

catch (const wa::storage::storage_exception& e)

{

std::cout << "例外: "<< e.what() << std::endl;

}

ucout << U("この操作で ") << context.request_results().size() << U(" 個の要求が実行されました。最後の要求のステータス コード: ") << context.request_results().back().http_status_code() << std::endl;

先ほどと同様に、存在しない BLOB で実行しようとした場合、このコードでは次のような文字列が記録されます。

次の宛先に要求を送信中: http://myaccount.blob.core.windows.net/mycontainer/myblob?timeout=90

理由メッセージ: The specified blob does not exist.

例外: The specified blob does not exist.

この操作で 1 個の要求が実行されました。最後の要求のステータス コード: 404

サンプル

マイクロソフトは、GitHub でサンプル プロジェクトを配布 (英語)しています。各抽象化ストレージのセットアップと実行の際にお役立てください。またその他に、主要なシナリオのサンプルが複数用意されています。サンプル プロジェクトはすべて “samples” という名前のフォルダーに格納されます。

Visual Studio の場合、サンプル ソリューションのファイル名は “Microsoft.WindowsAzure.Storage.Samples.sln” です。Microsoft.WindowsAzure.Storage.SamplesCommon プロジェクトの samples_common.h ファイルで、ユーザーのストレージ アカウントの認証情報を更新します。ソリューション エクスプローラーのウィンドウに移動し、実行するサンプル プロジェクト (Microsoft.WindowsAzure.Storage.BlobsGettingStarted など) を選択します。次に、[Project] メニューで [Set as StartUp Project] を選択 (またはプロジェクトを右クリックしてコンテキスト メニューから同オプションを選択) します。

まとめ

マイクロソフトは皆様からのフィードバックをお待ちしております、ページ下部のコメント欄、フォーラム、または GitHub (英語)までお気軽にお寄せください。また、不具合を発見した場合は、GitHub まで報告していただくと、後から解決策が確認できます。

Serdar Ozler、Mike Fisher、Joe Giardino

参照資料

ソース コード (GitHub、英語)

バイナリ ファイル (NuGet、英語)

Windows Azure ストレージのリリース - CORS、JSON、分単位メトリックなど各種機能の導入

Windows Azure テーブル: JSON の紹介 (英語)

Windows Azure Web サイト (WAWS) と中間証明書

$
0
0

このポストは、1 月 7 日に投稿された Windows Azure Web Sites (WAWS) and Intermediate Certificatesの翻訳です。

編集メモ:今回は、Windows Azure Web サイト チームでプログラム マネージャーを務める Erez Benari による記事をご紹介します。

Windows Azure Web サイトで SSL を使用することは一般的であり、サイトに証明書をアップロードして割り当てる作業は、通常、わかりやすくて簡単に行うことができます (最近のブログ記事 Obtaining a Certificate for use with Windows Azure Web Sites (WAWS) (英語) および HTTPS および SSL による Windows Azure Web サイト (WAWS) のセキュリティ保護の説明をご参照ください)。ただし、利用している証明書プロバイダーが中間証明書を使用している場合、この作業で問題が発生することがあります。

中間証明書 (チェーン証明書とも言います) は一部の証明書機関が使用するもので、より優れた安全性が提供される (英語)とのプロバイダーの判断もあって、幅広く利用されるようになっています。たとえば、VeriSignGoDaddyでは、この数年の間にチェーン証明書以外の証明書の発行を取りやめており、当然ながら、こうした証明書機関と関係のある ThawteGeoTrustといったプロバイダーにも影響を及ぼしています。

もちろん、Windows Azure Web サイトではこうしたシナリオを完全にサポートしており、中間証明書の取得に必要な手順にさえ注意すれば、適切に利用できるようになります。この作業で問題が発生する最も一般的な原因は、お客様が中間証明書そのものをサーバーにアップロードしようとすることです。また、お客様が中間証明書を含めずに証明書をアップロードしようとすることも、よくある原因の 1 つとなっています。いずれの場合も、それが原因となって、一部のブラウザーでこのサイトが信頼できないサイトであるとの警告が表示される可能性があります (この場合でも通常、ユーザーは次の手順に進むことができますが、このエラーによって多くのユーザーが警戒心を持つことになるため、こうした事態は避けなければなりません)。

つまり、証明書プロバイダーがチェーン証明書モデルを使用している場合は、もちろんチェーン証明書をアップロードする必要がありますが、その場合には、両方の証明書を 1 つのものとしてアップロードするのが正しい方法となります。このトピックに関する以前の記事でもご説明したように、証明書をアップロードするには、証明書を PFX ファイルにエクスポートする必要があり (証明書に秘密キーを含めるために必要となります)、その証明書が中間 CA によって発行されたものである場合、その中間証明書をエクスポートに含めなければなりません**。そのためには、[Include all certificates in the certification path if possible]オプションを必ずオンに設定してください。

これによって PFX ファイルのサイズは若干大きくなりますが、サーバーが証明書を処理するために必要なすべての情報が含まれた状態になります。誤解のないように言うならば、中間証明書そのものをエクスポートするのではなく、ご自身のサーバー証明書をエクスポートするということです。この点に気を付けて正しいオプションを設定すれば、両方の証明書が PFX ファイルにエクスポートされるので、サーバーで処理が正しく実行されます。

** ここで注意したいのは、このエクスポートが正しく行われるためには、エクスポートを実行しているコンピューター上にその中間証明書自体が存在している必要があるという点です。証明書プロバイダーが証明書を発行する際には、通常、証明書のインストールに関する情報やリンクが提供されますが、もしこうした情報が不明な場合は、メールを確認して、説明の手順に従うことをお勧めします。また、該当するプロバイダーの   Web サイトで関連情報を検索することもできます (GoDaddy のページ (英語)VeriSign のページ (英語)などをご参照ください)。

Windows Azure ネットワーク セキュリティに関する新しいホワイトペーパー

$
0
0

このポストは、1 月 8 日に投稿された New Windows Azure Network Security Whitepaperの翻訳です。

Windows Azure ネットワーク セキュリティに関する新しいホワイトペーパーをぜひダウンロードしてください。

Windows Azure のネットワーキング機能では、仮想マシンどうしを安全に接続し、クラウドとオンプレミスのデータ センターを安全につなぐために必要となるインフラストラクチャを提供します。

今回公開されたホワイトペーパーは、こうした内部の仕組みを明らかにすると共に、お客様がプラットフォームのネイティブ機能をどのように活用すれば情報資産を最大限保護できるかをご理解いただくためのものです。このホワイトペーパーの概要を以下にご紹介します。

あらゆる共有クラウド アーキテクチャの基本となるのが、お客様を個々に分離するための機能です。Windows Azure では、お客様は 1 件のサブスクリプションで複数のデプロイメントが可能であり、個々のデプロイメントには複数の VM を含めることができます。Windows Azure は、複数の観点でネットワークの分離を可能にしています。

  • デプロイメント: 個々のデプロイメントは互いに分離されます。同じデプロイメントに含まれる複数の VM は、プライベート IP アドレスを通じて相互にやり取りできます。
  • 仮想ネットワーク: 同じ仮想ネットワークに (同じサブスクリプションに含まれる) 複数のデプロイメントを割り当てることができ、同じ仮想ネットワークに割り当てられた各デプロイメントはプライベート IP アドレスを通じて相互にやり取りできます。個々の仮想ネットワークは互いに分離されます。

このトポロジの例を図 1 に示します。

1. Windows Azure でホストされ分離された多層型 IaaS アプリケーションの例

Windows Azure の Web サイト開発スタックのサポート

$
0
0

このポストは、1 月 10 日に投稿された Windows Azure Websites Development Stacks Supportの翻訳です。

編集メモ:今回は、Windows Azure Web サイト チームのプログラム マネージャーを務める Daria Grigoriuと Windows Azure Web サイト開発者エクスペリエンス パートナーによる記事をご紹介します。

Windows Azure Web サイト (WAWS) チームは、Web アプリケーションをすばやく実行し、Web アプリケーションの拡張の余地を確保するうえで役立つ、開発スタックのサポート モデルに積極的に投資しています。この記事では、開発スタックのバージョン管理と拡張性に関する基本原則を紹介すると共に、その原則を Web アプリケーションにどう適用するかについて説明します。

現在サポートされているのは、.NETPHPNode.js、および Python のスタックです。各スタックのサポート技術情報は、Windows Azure デベロッパー センター (http://www.windowsazure.com/en-us/develop、英語) でご覧いただけます。Web サイト構築後、コンテンツをアップロードして最小限の情報を入力するだけで運用を開始することができます。

WAWS 開発スタックのバージョン管理

サポートされている一部の開発スタック (PHP など) では、複数バージョンの維持が可能です。これらの開発スタックには、プラットフォームで検証済みの最新バージョンのセットが提供されます。既定のバージョンが設定されているため、互換性などの特別な理由で特定のバージョンを使用する必要がある場合を除いて、何も入力する必要はありません。

その他の開発スタック (.NET など) では、一部のバージョン (.NET 4.5 など) でインプレースアップグレードが可能です。マイクロソフトでは、これらの開発スタックに最新の方針を常に反映し、最新バージョンの機能とメリットを提供できるよう努めています。

以下のリンク先では、サポートされている開発スタックごとに WAWS で利用可能なバージョンと既定のバージョンをまとめているので、ご参照ください。https://github.com/projectkudu/kudu/wiki/Azure-Web-Sites-Development-Stacks

開発スタックの拡張性

カスタマイズが必要な場合は、各開発スタックの拡張ポイントを利用できます。

.NET

.NET フレームワークは、WAWS プラットフォームと緊密に統合されています。

構成

構成は、web.config ファイルを使用して指定します。apphost.config ファイルをよく使用している開発者の方もいらっしゃるかと思いますが、このファイルは WAWS で直接編集することができません。編集するには、XML Document Transformation (XDT) 宣言を使用する必要があります。既定のドキュメントなど apphost.config ファイル内の一部の設定は、Azure ポータルから Web サイトの [CONFIGURE] タブで編集できます。

拡張性

Web アプリケーション フォルダーには、MVC や Web ページのようなバイナリ デプロイ可能なコンポーネントを追加できます。

Node.js

構成

以下は、WAWS 上にデプロイされた Node.js アプリケーションの主要構成ファイルです。

  • package.json

Node.js 固有の構成ファイルです。クロスプラットフォームに対応しています。たとえば、Node.js モジュールの依存関係 (Express.js など) やランタイムのバージョン番号を指定することができます。

  • iisnode.yml

iisnode カスタム IIS モジュール固有の構成ファイルです。たとえば、node.exe を起動するコマンド、iisnode によって作成される node.exe プロセスの数、ログ構成を指定することができます。

  • web.config

WAWS プラットフォームで使用する IIS 構成ファイルです。必要なハンドラーの登録をキャプチャし、静的ファイルのパフォーマンス最適化を目的とした URL の書き換えを可能にします。

拡張性

WAWS に統合された Node.js 開発スタックのコア機能については、http://nodejs.org/api/ (英語) を参照してください。開発スタックのコア機能は、NPM モジュールのエコシステム (https://npmjs.org/、英語) を利用して拡張できます。package.json 構成ファイルを使用して、Web アプリケーションに追加するモジュールを指定します。WAWS プラットフォームに統合された git ベースのソース管理機能では、git push 操作で依存関係を取得、インストールしている間に npm install が実行されます。FTP などの他のデプロイメント メカニズムを使用する場合は、ローカルでの開発中にモジュールをダウンロードして構成し、Web アプリケーション全体を WAWS にアップロードします。NPM モジュールには、クロスプラットフォーム対応の Javascript モジュールと、特定のプラットフォームを対象に設計されたネイティブ モジュールの両方が含まれているため、常に両方のモジュールでアプリケーションのテストを行うことをお勧めします。

ランタイムのバージョン

WAWS プラットフォームに付属する任意のバージョンの Node.js を選択するか、カスタムの Node.js ランタイムをアップロードして構成することができます。具体的な手順については、Windows Azure デベロッパー センター (http://www.windowsazure.com/en-us/develop/nodejs/common-tasks/specifying-a-node-version、英語) を参照してください。

PHP

構成

WAWS 上にデプロイされた PHP アプリケーションの主要構成ファイルは、PHP の標準の .user.ini ファイルです。このファイルを使用すると、診断時に表示される display_errors など、変更可能な PHP ディレクティブを設定できます。

拡張性

WAWS では、既定により PECL コア拡張モジュールがサポートされます。さらに、カスタム拡張モジュールも利用できます。カスタム拡張モジュールを有効化するには、まず .dll ファイルを FTP ルート直下に移動します。次に、[CONFIGURE] タブで、PHP_EXTENSIONS というアプリケーション設定と値のセットを選択し、カスタムの PHP 拡張モジュールが置かれた場所 (アプリケーション ルートからの相対アドレス) に追加します。

ランタイムのバージョンとカスタマイズ

Azure ポータルで Web サイトの [CONFIGURE] タブを開いて、バージョンを選択できます。

WAWS では、FastCGI ベースのカスタムの PHP 開発スタックもサポートされます。そのためには、Web サイトのルートに開発スタックをアップロードします。さらに、Web サイトの [CONFIGURE] タブで、新しいスクリプト プロセッサ (通常、php-cgi.exe) と拡張子 *.php を関連付けます。「D:\home\site\wwwroot\php5.5\php-cgi.exe」のように、スクリプト プロセッサの絶対パスを指定する必要があります。「D:\home\site\wwwroot」はサイトのルートを参照します。

Python

構成

WAWS 上にデプロイされた Python アプリケーションの主要構成ファイルは、web.config です。必要なハンドラーの登録をキャプチャし、静的ファイルのパフォーマンス最適化を目的とした URL の書き換えを可能にします。web.config ファイルの使用は任意です。Azure ポータルの [CONFIGURE] タブで、ハンドラー マッピングも指定できます。詳細については、Windows Azure デベロッパー センター (http://www.windowsazure.com/en-us/develop/python/tutorials/web-sites-configuration、英語) を参照してください。

一部の構成オプションは、同じく Azure ポータルの [CONFIGURE] タブの [App Settings] から更新できます。

  • WSGI_LOG: アプリケーション エラー、構成エラーをキャプチャするログ ファイルの絶対パス
  • WSGI_HANDLER: environment 関数と start_response 関数を受け付ける、WSGI プロトコルの呼び出し可能アプリケーション オブジェクト (英語)

この値には、モジュールまたはパッケージ名に続けて、モジュール内の使用する属性を指定する必要があります (例: mypackage.mymodule.handler)。さらに、かっこを追加して属性の呼び出しを指示します。

  • WSGI_RESTART_FILE_REGEX: ファイル名を指定する正規表現

.*((\\.py)|(\\.config))$ は、既定により、すべての *.py ファイルおよび *.config ファイルを参照します。

拡張性

デプロイメントにパッケージを追加するには、パッケージをアプリケーション ルートの直下に置き、web.config または [App Settings] を使用して PYTHONPATH を設定します。現在、Virtualenv は WAWS でサポートされていません。

任意のパッケージのデプロイメントをサポートするには、まず Web サイトのルートの直下にパッケージを格納するディレクトリを作成します。Python lib フォルダー内の site-packages ディレクトリとよく似ていますが、このディレクトリは Web アプリケーション内にあり、Windows Azure Web サイトにデプロイされます。新しいディレクトリにパッケージをコピーし、web.config ファイル内の PYTHONPATH にこのディレクトリの絶対パスを追加します (例: D:\home\site\wwwroot\my-packages)。これで、Web アプリケーション内からパッケージをインポートできるようになります。

この方法で、アプリケーションに Django を追加することができます。まず、既存の Python インストール内に Django をダウンロード、またはインストールします。次に、アプリケーション内の任意のディレクトリに Django パッケージ (通常、_init_.py ファイルが含まれている、django という名前のフォルダー) をコピーします。既定では、パッケージを検索するディレクトリのリストにアプリケーション ルートが含まれています。サブディレクトリ (例: mypackages\django など) に Django パッケージをコピーしたい場合は、web.config ファイルの PYTHONPATH に親ディレクトリ (この場合、D:\home\site\wwwroot\mypackages) を追加します。

詳細については、Windows Azure デベロッパー センター (http://www.windowsazure.com/en-us/develop/python/tutorials/web-sites-with-django、英語) を参照してください。

ランタイムのバージョンとカスタマイズ

FastCGI ベースのカスタムの Python 開発スタックもサポートされます。そのためには、カスタム開発スタックを Web サイトのルートの直下にアップロードし、Web サイトのハンドラー マッピングに FastCGI ベースのスクリプト プロセッサの絶対パスを追加します。

マイクロソフトでは、皆様のご意見、ご感想をお待ちしています。開発スタックのサポートを今後どのように改善していくべきかについて、ぜひフォーラム (英語)にご意見をお寄せください。

 

Windows Azure での PCI DSS への準拠と ISO 認証の拡大、Windows Azure Hyper-V Recovery Manager の一般提供開始など、Windows Azure の更新について

$
0
0

このポストは、1 月 16 日に投稿された Announcing PCI DSS compliance and expanded ISO certification for Windows Azure, general availability of Windows Azure Hyper-V Recovery Manager and other updates to Windows Azureの翻訳です。

マイクロソフトは、お客様がセキュリティとコンプライアンスを確保したアプリケーションを構築できるよう、Windows Azure を大きく進歩させる 2 つの機能強化を行ったことを発表しました。さらに、Windows Azure Hyper-V Recovery Manager の一般提供開始により、お客様はアプリケーションの可用性を向上させることができるようになります。

Windows Azure PCI DSS 準拠の認定を取得しました。支払いに関する詐欺は、クレジット カードでの支払いを受け付けている企業が増加しつつある現状において、非常に大きな懸念となっています。今回 Windows Azure は、独立認定審査機関である Qualified Security Assessor (QSA) が定めたクレジット カード業界データ セキュリティ基準 (PCI DSS) 準拠の認証を取得しました。

PCI DSS は、企業規模の大小を問わず、カードでの支払いを受け付け、カード所有者のデータの保存、処理、転送などを行うすべての企業が必ず遵守しなければならない国際標準です。PCI DSS の認証を取得したインフラストラクチャやプラットフォームのサービスを提供することにより、Windows Azure はコンプライアンスに対応したフレームワークを配信し、お客様の所有するアプリケーションのセキュリティとコンプライアンスを向上させることができます。これにより、Windows Azure を使用するアプリケーションの PCI DSS 準拠の認定がよりいっそう簡単に取得できるようになります。

お客様の PCI DSS 準拠の認定取得をご支援するため、マイクロソフトは Windows Azure PCI 準拠証明書 (英語)および Windows Azure ユーザー向け PCI ガイド (英語)をご用意しました。ぜひ、今すぐダウンロードしてご利用ください。

対象となる機能のリスト、および Windows Azure のセキュリティとコンプライアンスについての詳細は、トラスト センターでご確認ください。

ISO 認証の対象が SQL データベースおよびその他多数の Windows Azure の機能にまで拡大されました。

Windows Azure は ISO の年次監査を無事完了しました。このたびの監査は、Windows Azure クラウド サービス、ストレージ、仮想マシン、仮想ネットワークの各機能に加えて、SQL データベース、Active Directory、トラフィック マネージャー、Web サイト、BizTalk サービス、メディア サービス、モバイル サービス、サービス バス、多要素認証、HDInsight を対象として実施されました。これには、上記の機能のインフラストラクチャ、開発、運用、およびサポートを網羅する Windows Azure 向け情報セキュリティ マネジメント システム (ISMS) が含まれています。

マイクロソフトが国際的に認められている情報セキュリティ コントロールを実装し、お客様が個々の使用事例に応じて法令や規制を遵守できるように取り組んでいることが改めて確認されたため、今回の認定拡大が実現されました。

対象となる機能のリスト、および Windows Azure のセキュリティとコンプライアンスについての詳細は、トラスト センターでご確認ください。

Windows Azure Hyper-V Recovery Manager でアプリケーションの保護、監視、回復が簡単になります。

アプリケーション可用性の保護 (特に該当地域での災害発生などの脅威に対する保護) は、複雑な計画やリモートでのサービス可用性の監視が必要となるため、コストがかさんでしまいがちです。保護することで効果が見込まれるアプリケーションも、高いコストと複雑さを理由に保護されないままとなっているものが多数あります。

このたび一般提供が開始された Windows Azure Hyper-V Recovery Manager は、セカンダリ サイトへの仮想マシンのレプリケーションを自動化することで、オンプレミスのアプリケーションの保護を支援します。

主に、次の 3 つの機能が提供されます。

  • 自動化された保護 – HRM は Windows Server および System Center の機能を活用して、セカンダリ サイトへの仮想マシンのレプリケーションを継続的に実施します。
  • 継続的な正常性監視 – Windows Azure ではサービスの可用性をリモートで監視する機能を提供しており、ユーザーがカスタマイズした回復計画の中心的なリポジトリとして動作します。
  • 調整された回復 – プライマリ データセンターでサービスが停止した場合、Windows Azure から回復計画を実行し、セカンダリ サイトでのサービス回復を調整できます。

これらの回復計画では、異なる仮想マシンおよびアプリケーション層のフェールオーバーをシーケンス処理し、スクリプトおよび手動操作によるカスタマイズ機能を提供することで、障害回復の調整が自動化されています。

Windows Azure Hyper-V Recovery Manager は、既に Aston Martin (英語)United Airlines (英語)Pošta Slovenije (英語)などのお客様の環境でご利用いただいています。今回ご紹介した機能の詳細については、Brad Anderson (英語)Scott Guthrie (英語) (翻訳 : SATO Naoki ブログ: Windows Azure: Webサイト向けのステージング発行のサポート、監視の改善、Hyper-V Recovery ManagerのGA、PCIコンプライアンスを参照ください)のブログ記事をお読みください。

Hyper-V Recovery Manager についての詳細は、こちらのページを参照してください。

また今回は、他にも以下の更新が実施されています。

  • ステージング発行や WebJobs など、Windows Azure Web サイトで主要な新機能のプレビューがリリースされました。
  • Windows Azure Web サイトや Windows Azure SQL データベースの監視機能、および警告機能が強化されました。
  • Azure モバイル サービスで Sencha Touch がサポートされ、クロスプラットフォームのモバイル アプリケーションや Web サイトの構築に使用できるようになりました。

詳細については、Scott Guthrie のブログ (英語) (翻訳 : SATO Naoki ブログ: Windows Azure: Webサイト向けのステージング発行のサポート、監視の改善、Hyper-V Recovery ManagerのGA、PCIコンプライアンスを参照ください) でご確認ください。


ガートナー社、マイクロソフトを aPaaS の分野で "リーダー" と認定

$
0
0

このポストは、1 月 22 日に投稿された Gartner Recognizes Microsoft as an Application Platform as a Service Leaderの翻訳です。

2013 年は、Windows Azure にとってすばらしい年となりました。ユーザーの使用量は毎月記録を更新し、4 月には Windows Azure インフラストラクチャ サービスの一般提供開始という大きな目標を達成して、これまでにないほどのご好評をいただきました。2014 年 1 月 7 日に公開された「Magic Quadrant for Enterprise Application Platform as a Service (エンタープライズ aPaaS のマジック クアドラント)」 (英語)では、マイクロソフトがエンタープライズ向けの aPaaS (サービスとしてのアプリケーション プラットフォーム) 市場において "リーダー" に位置付けられるとガートナー社に認定されました。この快挙を皮切りに、2014 年は一層充実した年となるでしょう。

企業ユーザーのお客様からは、既存のアプリケーションの開発、テスト、およびホスティングに使用するインフラストラクチャ サービスと同様に、新しいアプリケーションの開発が行えるクラウド サービス プラットフォームを望む声をいただいていました。Windows Azure は、aPaaS のマジック クアドラントでは "リーダー"、2013 年 8 月 19 日の クラウド IaaS マジック クアドラント (英語)では "概念先行型" と位置付けられており、そうした評価は、これらのシナリオ全体にわたるマイクロソフトのビジョンの完全さと、それよりもはるかに重要な事項である、企業ユーザーのお客様の短期的、長期的ニーズを満たす実現能力が認められたものであると考えます。この件では、Windows Azure が、新規にサインアップしたユーザー数やプラットフォームに格納されているデータ量などにおいて、次のように過去 6 か月間で急速に成長した点に注目されています。

  • 1 週間あたり 8,000 の新規ユーザーがサインアップ
  • 2000 年に全世界で使用されたサーバーコンピューティング以上のコンピューティングを Windows Azure で使用
  • 6 ~ 9 か月ごとにコンピューティングの需要が継続して倍増
  • 有史以来発行された印刷物の総計以上の情報量を Windows Azure が格納

Windows Azure の大きな目標

マイクロソフトは、クラウドファーストの戦略により、2014 年度第 1 四半期で企業向けクラウド ビジネスにおいて 103% の収益増加を達成 (英語)しました。弊社では、開発者および IT 部門のニーズを満たすためにツール、管理製品、サーバー プラットフォームを Windows Azure と統合することで、クラウド OS ビジョンの遂行に引き続き取り組んでまいります。

開発者はシームレスなクラウド開発エクスペリエンスを求め続けています。これに対応して、先月リリースした Visual Studio 2013 では、コードを作成し、Azure に直接デプロイし、Azure 管理ポータルへ移動しないでも自身の環境を管理できる機能が実現されました。

また、クラウド ネイティブなアプリケーションを使用した新たなビジネス バリューの提供を試みるお客様に向けて、昨年 1 年間にモバイル サービス、メディア サービス、Web サイトなどの 200 以上の新サービスが Windows Azure に追加されました。さらに、昨年はデータセンターの設置地域を世界中に拡大する取り組みも継続し、中国本土でのサービスが開始されたと共に、日本、オーストラリアおよびブラジルでのサービス開始を予定しています。

オープンで柔軟性の高い Windows Azure

Windows Azure は、マイクロソフトに変化をもたらす要因でもあります。マイクロソフトは、自社所有のものではないテクノロジを採用し、サポートを開始しました。これには、Node.js、Java、PHP、Python などの新しいフレームワークや言語と、SUSE、CentOS、Ubuntu などの Windows 以外のオペレーティング システムが含まれます。これにより、iOS や Android などのマイクロソフト以外のモバイル デバイス用の開発が、Windows Azure 環境でも可能になりました。また、先日提携した Oracle とのパートナーシップにより、Windows Azure は Oracle データベースおよび Oracle WebLogic Server用として最も包括的かつ完全にサポートされたクラウド プラットフォームとなりました。これらはすべて、Windows Azure を誰にでもご利用いただけるクラウド プラットフォームにするための取り組みです。

お客様の導入事例

Windows Azure を導入されたお客様の多くが成功を収めています。下記の事例をお読みいただくと、それぞれのお客様がクラウドをどのように活用したかをご理解いただけます。

マイクロソフトは、aPaaS 市場における弊社の実行能力と先見性の完全さについてガートナー社の高い評価を得たことを光栄に思います。また、2014 年はさらに Windows Azure に新しいサービスを導入し、敏捷性に優れたクラウドをお客様にご活用いただけるように努めてまいります。ガートナー社による、エンタープライズ aPaaS のマジック クアドラント レポートの全文は、こちらのページ (英語)でお読みいただけます。

*ガートナーは、ガートナー・リサーチの発行物に掲載された特定のベンダー、製品またはサービスを推奨するものではありません。また、最高の評価を得たベンダーのみを選択するようテクノロジの利用者に助言するものではありません。ガートナー・リサーチの発行物は、ガートナー・リサーチの見解を表したものであり、事実を表現したものではありません。ガートナーは、明示または黙示を問わず、本リサーチの商品性や特定目的への適合性を含め、一切の保証を行うものではありません。

ストレージの料金値下げのお知らせ

$
0
0

このポストは、1 月 25 日に投稿された Announcing Reduced Pricing on Storageの翻訳です。

昨年 4 月の発表でもお伝えしたように、マイクロソフトはコンピューティング、ストレージ、帯域幅などの商用サービスの料金について、Amazon Web Services と歩調を合わせていく方針を固めました。このことから、AWS の料金設定に対抗すべく、3 月 13 日よりブロック BLOB ストレージ、およびディスク/ページ BLOB ストレージの値下げを実施します。この新料金は世界中で適用されるため、多くの地域で Azure ストレージが AWS の料金を下回ることになります。

では詳細をご説明しましょう。マイクロソフトは AWS の S3 および EBS の最安値 (米国東部地域) に対抗するために、最大で 20% の値下げを行い、世界の全地域を対象にこれまでよりも低価格でのサービス提供を開始します。また、ローカル冗長オプションのディスクおよびページ BLOB ストレージは最大で 28%、Azure ストレージのトランザクション料金は 50% 値下げします。

こうした商用サービスでは、料金が大きな障害となることが多いことをマイクロソフトは理解していますが、同時に、ただ安ければよいというものではなく、パフォーマンス、信頼性、スケーラビリティの高さも重要視されていると認識しています。マイクロソフトは業界で最高のコスト パフォーマンスを維持すること、そしてクラス最高レベルの信頼性とスケーラビリティを提供することに多大な労力を注いでいます。

マイクロソフトは Windows Azure のストレージ機能をご利用のお客様に対し、競合他社よりも低料金であること以外にも、次のようなさまざまなメリットを提供しています。

1.冗長性とパフォーマンスの高さ。地理冗長ストレージ オプションをご利用の場合、データを複製し、640 キロ以上離れた別のリージョン に保管します。

最近発表された Nasuni のクラウド ストレージ レポートでも述べられているように、Azure BLOB ストレージは、パフォーマンス、スケーラビリティ、安定性のテストにおいて S3 の結果を上回っています。「本年当社が実施したテストにおいて、マイクロソフトの Azure BLOB ストレージは、前年首位の Amazon S3 を大きく引き離して 1 位を獲得しました。3 つの主要テスト (パフォーマンス、スケーラビリティ、安定性) では、マイクロソフトがすべてのカテゴリで最高の結果を上げました。」(Nasuni の 2013 年のクラウド ストレージ レポートより)

2. マイクロソフトの場合、仮想マシンでは高耐久性のストレージを追加料金なしでご利用いただけるため、競合他社よりも料金がお安くなります。

たとえば Azure IaaS のディスクは、地理冗長オプション付きで 1 か月あたり $0.095/GB です。AWS で高耐久性の VM ディスクを利用すると、EBS スタンダード ボリューム (1 か月あたり $0.05/GB) と S3 に対する EBS スナップショット (1 か月あたり $0.095/GB) の両方の料金を支払う必要があり、34% も高くなります。

マイクロソフトは、仮想マシンでも最高のコスト パフォーマンスを皆様にご提供するために日々取り組んでいます。先日、メモリ集中型コンピューティング インスタンスを最大で 22% 値下げすることを発表しましたが、これにより、SharePoint や SQL Server、インメモリ分析などのメモリ集中型のワークロードをクラウドに移行していただきやすくなりました。

Cloud Spectator が最近実施した大規模クラウド IaaS プロバイダー 5 社の比較分析 (英語)では、Windows Azure インフラストラクチャ サービスのパフォーマンスが最も優れており、コストパフォーマンスは平均で Amazon EC2 3 倍も高いことが示されました。

Windows Azure をご利用いただくことで、お客様はより優れたパフォーマンス、信頼性、スケーラビリティを得ることができます。今回の発表では、商用サービスの料金に対する取り組みと、それによる Windows Azure のコスト パフォーマンスの維持にいかにマイクロソフトが労力を注いでいるかをお伝えしました。

Azure Web サイトで実行中の WordPress に Memcached を使用する

$
0
0

このポストは、1 月 25 日に投稿された WordPress with Memcached on Azure websitesの翻訳です。

編集メモ:今回は、Windows Azure Web サイト チームでプログラム マネージャーを務める Sunitha Muthukrishnaと Windows Azure Web サイト開発エクスペリエンス パートナーの投稿をご紹介します。

Azure Web サイト サービスで実行している WordPress の Web サイトのパフォーマンスを向上させたいとお考えなら、キャッシュを使用して Web サイトを高速化させる方法があります。Web サイトのトラフィック量が多い場合は、分散メモリ キャッシュのメカニズムを採用してセットアップすると最適な結果が得られます。

Memcachedは汎用分散メモリ キャッシュ システムで、動的なデータベース駆動型 Web サイトでデータやオブジェクトを RAM にキャッシュして外部データ ソース (データベースや API など) の読み込み回数を減らし、高速化させる目的でよく活用されています。Memcached システムではクライアント/サーバー型アーキテクチャを使用します。ユーザーが運営している Web サイトなどのクライアントは、クライアント側のライブラリ (この場合は Memcached ライブラリである PECL) を使用して、11211 番のポートを通じてサービスを提供するサーバーに接続します。各クライアントはすべてのサーバーを認識していて、サーバーは相互の通信を行いません。

クライアントが特定のキーに対応する値を設定したり読み込んだりする場合、まずクライアントのライブラリが該当するキーのハッシュを計算し、使用するサーバーを決定してから、そのサーバーとの接続を確立します。接続先のサーバーは、該当するキーの 2 つ目のハッシュを計算して、保存先の決定や、対応する値の読み取りを行います。

Memcached のクライアントは、Memcached サーバーを一時キャッシュとして扱う必要があります。Memcached に保存されているデータが、必要なときに必ず残っているとは限りません。MemcacheDB、Couchbase Server、Varnish などのデータベース サーバーでは、Memcached プロトコルとの互換性を保ちつつ永続的なストレージを提供しています。

このチュートリアルでは、次の手順について説明します。

  • Memcached サーバーを Azure Ubuntu VM でセットアップする方法
  • ユーザーが所有する WordPress サイトで Memcached を構成する方法

Azure VM での Memcached のセットアップ

Azure 管理ポータルにログインし、Ubuntu VM を作成します。この手順の詳細については、「仮想マシン ギャラリーから Linux VM を作成する方法 (英語)」のページを参照してください。まだ Azure のアカウントを所有していない場合は、30 日間の無料評価版をお試しください (\17,000 相当分の Windows Azure のリソースをご利用いただけます)。

Ubuntu VM にアクセスするには、PuTTY (英語)などの SSH クライアントをインストールします。この手順の詳細については、「Linux VM で SSH を使用する方法 (英語)」のページを参照してください。PuTTY クライアントを開いて VM 名 (例: memcachesrv.cloudapp.net) を入力し、[Open]をクリックします。

該当する仮想マシンの管理者ユーザー (この例では azureuser) としてログインした後、次のコマンドを実行します。すると、ルート ユーザー権限を使用可能な状態で Linux のシェルが起動されます。さらに、既存のリポジトリからパッケージ リストがダウンロードされ、パッケージと VM の依存関係が最新のバージョンに更新されます (図 2 参照)。

sudo -s

apt-get update

既定では、11211 番ポートはブロックされています。このポートを開くには、Azure 管理ポータルにログインして VM のダッシュボードにアクセスする必要があります。[ENDPOINTS]をクリックし、11211 番のポートを新しいエンドポイントとして追加します。

Memcached のインストール

Memcached のインストール手順を説明します。まず、apt-getを使用して Memcached をインストールします。

sudo apt-get install memcached

 

ユーザーのサーバーにコンパイラがない場合、build-essentialをダウンロードすると Memcached をインストールできます。

sudo apt-get install build-essential

 

次のコマンドを使用して、Memcached の構成ファイル (memcached.conf) を編集します。

sudo nano /etc/memcached.conf

35 行目の行頭に # を追加し、この行をコメント アウトします。

-1 127.0.0.1

 

WordPress での Memcached の構成

  • FTP でサイトにアクセスします。
  • bin フォルダーを作成します。
  • Memcached の拡張機能である PECL をこちらからダウンロードします。この拡張機能は PHP5.4 (32 ビット) 向けのものですので、ご注意ください。異なる構成で Web サイトを運用している場合は、こちらのページ (英語)から適切な DLL を選択します。
  • 管理ポータルにログインして、WordPress の Web サイトの構成を更新します。[Configure][app settings]セクションで、次のように設定します。

  • こちらのリンク (英語)から Memcached Object Cache プラグインをダウンロードします。
  • object-cache.phpwp-contentフォルダーにコピーします。
  • wp-config.php ファイルで Memcached サーバーの詳細を指定します。

「/* that’s all, stop editing! Happy blogging.」という部分のすぐ上に、次のようなコードを追加します。

*/

$memcached_servers = array(

            'default' => array('memcachesrv.cloudapp.net:11211' )

);

  • こちらのリンク (英語)から Batcache プラグインをダウンロードします。
  • advanced-cache.phpwp-contentディレクトリにアップロードします。
  • wp-config.phpファイルの冒頭に次の行を追加します。

                            define('WP_CACHE',true);

キャッシュの動作確認

キャッシュが動作しているかどうかを確認するには、ホーム ページを 3 回以上読み込み直してから HTML のソースを表示します。最初に読み込んだときには、終了タグの </head> のすぐ上に次のようなコメントが表示されます。

WordPress のページを数回更新してコメントが変わったら、ページがキャッシュから読み込まれたということです。

Memcache によるサーバー統計情報の確認

Memcached サーバーを定期的に追跡しサーバーの状態を把握することを、強く推奨します。これには複数の方法があります。

1.netcat ユーティリティ (英語)を使用する方法。これは、"apt-get update" コマンドを実行済みであれば Ubuntu VM で既に使用可能な状態になっています。11211 番ポートをリッスンしている Memcached サーバーで "stats" コマンドを使用して netcat を実行すると、使用中の Memcached サーバーの状態が得られます。

 echo "stats" | nc memcachesrv.cloudapp.net 11211

2. watch コマンド (英語)を使用する方法。2 秒ごとに状態を確認し、リストとして出力します。

             watch "echo stats |nc memcachesrv.cloudapp.net 11211"

3. PHP の Memcached 拡張機能である Memcache::getStats () API (英語) を呼び出して、プログラム的に実行する方法。

参考情報

“2013-08-15” バージョンをサポートした Windows Azure ストレージ エミュレーター 2.2.1 のプレビューをリリース

$
0
0

このポストは、1 月 26 日に Windows Azure Storage Team が投稿した Windows Azure Storage Emulator 2.2.1 Preview Release with support for “2013-08-15” versionの翻訳です。

このたび、新しい “2013-08-15” バージョンの機能 (CORS や JSON など) をサポートする Windows Azure ストレージ エミュレーターの更新版プレビューがリリースされました。

Windows Azure ストレージ エミュレーター 2.2.1 プレビューの MSI パッケージは、こちらのページ (英語)からダウンロードできます。

インストールの手順

今回のリリースはプレビュー版です。また、Windows Azure SDK 2.2がインストール済みである必要があります。インストーラーによって Windows Azure ストレージ エミュレーター 2.2 のバイナリが自動的に置換されることはなく、バイナリは一時フォルダーに格納されます。一時フォルダーの場所は、32 ビット OS の場合は "%ProgramFiles%\Windows Azure Storage Emulator 2.2.1\devstore"、64 ビット OS の場合は "%ProgramFiles(x86)%\Windows Azure Storage Emulator 2.2.1\devstore" です。今回は、このエミュレーターが「プレビュー」であることを考慮し、上書きをしないようにしました。このため、以前のバージョンのエミュレーターに簡単に戻せるようになっており、一度アンインストールして SDK 2.2 を再インストールするといったことは必要ありません。マイクロソフトでは、Windows Azure ストレージ エミュレーター 2.2 のバイナリをバックアップしてから新しいバイナリに置き換えることを推奨しています。MSI でのインストール作業の終了後、詳細な説明が記載された readme.txt ファイルが開きます。

今回のリリースはプレビュー バージョンであることにご注意ください。また、何かお気付きの点がありましたら、ぜひこのページ下部のコメント欄か Windows Azure ストレージのフォーラム (英語)までご意見をお寄せください。

Michael Roberson、Jean Ghanem

 

参考用に、インストール後に開かれる readme.txt に記載された、MSI でのインストール終了後の作業指示をご紹介します。

[README.TXT]

Windows Azure ストレージ エミュレーター 2.2.1 プレビュー

------------------------------------

前提条件

Windows Azure SDK 2.2 をインストール済みである必要があります。次のページからダウンロードできます。
http://www.microsoft.com/ja-jp/download/details.aspx?id=40893

セットアップ

次の手順に従って 2.2.1 バージョンをセットアップします。

  1. Windows Azure SDK 2.2 がインストールされていることを確認します。Windows Azure ストレージ エミュレーター 2.2.1 は、SDK バージョン 2.2 がインストールされていない環境では動作しません。
  2. Windows Azure ストレージ エミュレーターを実行中の場合は、終了させます。
  3. 次のパスにあるファイルをすべてコピーします。
  • 32 ビット OS の場合: "%ProgramFiles%\Windows Azure Storage Emulator 2.2.1\devstore"
  • 64 ビット OS の場合: "%ProgramFiles(x86)%\Windows Azure Storage Emulator 2.2.1\devstore"

コピー先のパスは以下です。

"%ProgramFiles%\Microsoft SDKs\Windows Azure\Emulator\devstore"

確認メッセージが表示された場合、既存のファイルを新しいファイルに置き換えるように選択します。

アンインストール

Windows Azure ストレージ エミュレーター 2.2.1 はバージョン 2.2 との下位互換性があるため、ほとんどの場合、バージョン 2.2 に戻す必要はありません。以前のバージョンに戻す必要がある場合は、Windows Azure SDK 2.2 エミュレーター パッケージを次の Web サイトから再インストールしてください。

http://www.windowsazure.com/ja-jp/downloads/

Windows Azure Web サイトでロックが解除された新たな構成オプションについての詳細なお知らせ

$
0
0

このポストは、1 月 29 日に投稿された More to explore: configuration options unlocked in Windows Azure Web Sitesの翻訳です。

編集メモ:今回は、Windows Azure Web サイト チームでプログラム マネージャーを務める Erez Benari による記事をご紹介します。

Windows Azure Web サイト (WAWS) で Web サイトの管理を行うときに活用できるよう、マイクロソフトでは Azure ポータルにさまざまな構成オプションをご用意し、また、継続的な追加を実施しています。既にご存知のことと思いますが、一部の非常に強力なオプションを構成するには、サイトの web.config ファイルを直接編集する必要があります。先日、マイクロソフトは新しいオプションをいくつか公開し、web.configファイルで構成できるようにしました。

IIS で Web サイトを管理していた経験があるお客様であれば、IIS で構成を管理する場合、階層システムが複雑 (英語)であることをご存知かと思います。このシステムには最上位に machine.config、applicationHost.config、その他のサイト全体に有効なファイル、その下にフォルダーのみに有効な web.config ファイルが存在するというように、複数レベルの構成ファイルがあります。 Windows Azure Web サイトでは、web.configファイルを編集することによってのみ構成を変更できるようにして、構成階層システム内の他のファイルを処理する必要をなくし、この煩雑さを解消しました。

今回の Azure Web サイトの更新によって、web.configで新しくいくつかのオプションのロックが解除されました。以前は、これらのオプションはサイト レベルでロックされていたため、開発者の皆様は構成することができず、構成しようとするとサイトからエラーが返されていました。

たとえば、Azure Web サイト ユーザーの皆様からは、動的および静的なコンテンツ圧縮で利用する MIME タイプを設定できるようにしてほしいとのご要望が多数寄せられていました。IIS サーバーの標準的な既定のインストールの場合、マスター構成ファイルである applicationHost.configファイルでは、以下に示すように text/*message/*application/javascriptapplication/atom+xmlapplication/xaml+xmlの静的な MIME タイプのみが構成できます。

IIS サーバーではこのセクションもロックされているため、通常、サイト レベルの web.config ファイルでは他の項目の設定や設定追加は行えませんでした。

スタンドアロンの IIS サーバーでは、applicationHost.config ファイルを編集して設定を追加したり、httpCompressionセクションのロックを解除してサイト レベルで構成オプションを追加したりすることが容易に行えました。

そこで今回の Azure Web サイトの変更では、このセクションをはじめいくつかのセクションのロックを解除し、ユーザーのサイトの web.configファイルでユーザー自身のオプションを定義できるようにしました。また、Azure Web サイトの httpCompression セクションに対して小規模な変更を実施し、以下のように構文を簡略化しました。

ご覧のようにディレクトリスキーム名の指定が不要になり、静的タイプと動的タイプのそれぞれについて MIME タイプのリストを作成するだけになりました。

今回ロックが解除された他のセクションでは、通常の IIS Web サイトで使用されていたものと同様の構文を使用します。該当するセクションは以下に示すとおりです。各項目は IIS.NET の記事へのリンクになっていて、構成スキーマの一部および構成方法をご覧いただけます。

今回公開されたオプションを活用することで、これまでよりもはるかに柔軟に構成を変更できるようになります。Windows Azure Web サイトでさらに生産性の高い Web サイトを構築するうえでお役立ていただければ幸いです。

Windows Azure ストレージ: CORS の導入

$
0
0

このポストは、2 月 3 日に Windows Azure Storage Team が投稿した Windows Azure Storage: Introducing CORSの翻訳です。

マイクロソフトは、先日、Windows Azure ストレージ用 CORS (クロス オリジン リソース共有) をリリースしました。CORS (英語)は BLOB、テーブル、およびキューの各サービスでサポートされ、Windows Azure ストレージ クライアント ライブラリ 3.0 (英語)を使用すると各サービスに対して有効化できます。今回の記事では、CORS について説明すると共に、Windows Azure ストレージで CORS をサポートする方法をサンプルを交えて紹介します。完全なサンプル コードは、こちらのページ (英語)からダウンロードできます。

CORS の概要

Web ブラウザー (ユーザー エージェントとも呼ばれる) では、通常、同一呼び出し元ポリシーによる制限がネットワーク要求に対して適用されています。この制限は、セキュリティ上の理由により、特定のドメインから実行されるクライアント側の Web アプリケーションが他のドメインに要求を発行することを禁止するものです。たとえば、http://www.contoso.com/のサイト内にある JavaScript のコードが http://www.northwindtraders.com/などの他のドメインに要求を発行することは、Web ブラウザーがこのような要求の実行を禁止しているためできません。

CORS は、上記のような制限を緩和し、ドメイン間で互いにアクセス許可を付与して、互いのリソースにアクセスできるようにするメカニズムです。上記の例で言うと、ユーザー エージェントは、www.contoso.comというドメインから読み込まれた JavaScript コードが www.northwindtraders.comにあるリソースにアクセスできるように、追加のヘッダーを送信します。このとき、後者のドメインは、www.contoso.comから自身のリソースへのアクセスを許可または拒否することを示す追加のヘッダーを返すことができます。

CORS では HTTP の仕様が拡張されます。詳細については http://www.w3.org/TR/cors/を参照してください。

Windows Azure ストレージに CORS を導入した理由

CORS を使用しない場合、Windows Azure ストレージ サービスを使用する Web サイトは、ストレージを呼び出す際にプロキシとして働く必要があります。ストレージへの要求はすべてサービス経由でプロキシ転送される必要があるため、読み込み量が増加すると、サーバーのスケール アウトが必要になります。例として、http://www.contoso.comという Web サイトを所有し、その Web サイトにユーザーが BLOB をアップロードする機能があり、その BLOB を Windows Azure ストレージ アカウントである contoso.blob.core.windows.net というドメインに永続化する場合を考えます。この場合、まずブラウザーからサービスへアップロードが行われ、次にサービスがそのデータをストレージ アカウントへ PUT することになります。このため、所有する Web サイトへの上り方向のトラフィック量が増加すると、このサービスをスケール アウトする必要があるのです。

しかし、CORS を使用すると、アップロード時にサービスを経由する必要がなくなります。この例では、ストレージ アカウントの contoso.blob.core.windows.net で CORS を有効化し、contoso.com からのアクセスを許可します。そうすると、プロキシ サービスを挟まないでも、Javascript コードが共有アクセス署名を使用してストレージ アカウントに BLOB を直接アップロードできるようになります。これで、所有する Web サイトへの上り方向のトラフィックがどれだけ増加してもサービスをスケール アウトする必要はなく、Windows Azure ストレージ サービスの非常に大規模なスケールを活用することができます。

ここで、CORS は認証メカニズムではないという点に注意してください。CORS が有効な場合にストレージのリソースに対して発行される任意の要求は、認証用の適切な署名を持っているか、またはパブリックなリソースに対するものである必要があります。

Windows Azure ストレージ用の CORS の詳細については、以下のページに掲載されている MSDN のドキュメントを参照してください。 http://msdn.microsoft.com/ja-jp/library/windowsazure/dn535601.aspx

CORS のしくみ

通常、CORS の動作には 2 つの段階があります。まず、プレフライト要求 (OPTIONS 要求) が発行され、その後で実際の要求 (GET、PUT、POST など) が続きます。

ただし、GET などの単純なメソッド (英語)簡単な要求 (英語)を発行する場合などでは、ユーザー エージェントがプレフライト要求を発行しないこともあります。

プレフライト要求

プレフライト要求とは、サービスごとに設定されている CORS の制限を照会するしくみです。Javascript のコードの一部が別のドメインへの要求を送信するたびに、ユーザー エージェントはこの要求を発行します。プレフライト要求は OPTIONS 要求の一種で、実際の要求ヘッダー、目的の HTTP 要求、および発信元のドメインを伝達します。受信側のサービスは、発信元、要求ヘッダー、メソッドなどの制限を定めた、事前構成済みの一連のルールに基づいて、目的の処理を評価し、要求を受理または拒否します。Windows Azure ストレージの場合、CORS ルールはサービスごと (BLOB、テーブル、キュー) に構成され、プレフライト要求も個々のリソースごとではなくサービスごとに評価されます。

通常、プレフライト要求はブラウザーによってキャッシュされるため、キャッシュされたプレフライト要求の処理が正常に完了し、実際の要求がディスパッチされる際、後続の要求ではこの手順は省略されます。キャッシュの TTL (Time to Live) はユーザーが設定できます。

実際の要求

実際の要求とは、クライアントが目的とする要求のことです。この要求には、ユーザー エージェントが追加した “Origin” というヘッダーが存在します。

受理された CORS 要求に対しては、有効な Access-Control 応答ヘッダーが返されます。Access-Control ヘッダーが返されない場合、ブラウザーはこの応答を確認し、要求の発行者を拒否します。ここで、Origin ヘッダーが構成済みのルールを満たしているかどうかにかかわらず、サービスは要求の処理を継続する点に注意が必要です。Web ブラウザーは、Access-Control 応答ヘッダーの値に従って、応答のどの部分 (必要な場合) を JavaScript に渡すかを決定します。

また、OPTIONS 要求が必須ではない場合もあります。この場合は、Web ブラウザーがこの要求を発行せず、代わりに実際の要求が直接ディスパッチされます。このような要求は簡単な要求 (英語)と呼ばれます。

Windows Azure ストレージでの CORS の活用シナリオ

先に述べたように、BLOB で CORS を使用する一般的な例としては、Web ブラウザーから Windows Azure ストレージ アカウントへファイルを直接アップロードする場合が考えられます。このとき、CORS と SAS (共有アクセス署名) 認証メカニズムを併用すると、Web ブラウザーに対してストレージ アカウントへの書き込み権限を付与することができます。このケースでは、ユーザーがファイルをアップロードする準備が完了するたびに、JavaScript コードは、アップロードする BLOB の SAS の URL をサービスに対して要求し、次に、その BLOB を PUT する要求をストレージに対して実行します。この際、セキュリティ リスクを低減し、特定のコンテナーまたは BLOB (あるいはその両方) のみがアップロードされるように、SAS トークンのアクセス時間を必要な長さに制限することを推奨します。SAS の使用に関するベスト プラクティスについては、こちらのページ (英語)を参照してください。

他には、Windows Azure テーブルで CORS を使用して、ブラウザーでテーブルのデータを表示し、必要に応じてそのデータを操作するという場合があります。その典型的な例として、管理ページを公開し、Windows Azure テーブルで永続化されている Web サイトの構成設定をユーザーが変更できるようにするというケースが挙げられます。このような機能の実装には CORS、SAS、および JSON が使用できます。詳細については、こちらのサンプル コード (英語)を参照してください。このケースで JavaScript の JQuery の機能を利用して、Windows Azure テーブルへの要求の実行とデータの操作を行う場合、JSON を使用するのが最適です。

Windows Azure ストレージ チームが提供している JavaScript のサンプル コード (英語)では、BLOB のアップロードとリスト表示を行う方法や、JQuery を使用して Windows Azure テーブルに対して Insert Entity や Query Entities の操作を行う方法を示しています。

Windows Azure ストレージで CORS を有効化する方法

CORS を使用するには、まず、目的のサービス (BLOB、テーブル、キュー) ごとに個別に有効化し、構成する必要があります。REST API または Windows Azure ストレージ クライアント (.Net (英語)Java (英語)C++ (英語)のいずれか) を使用して CORS ルールを設定するには、ストレージの最新バージョンである “2013-08-15” バージョンを使用する必要があります。いったん有効化した後は、CORS に準拠している限り、ストレージ アカウントに対する操作および REST 要求 (Put Blob や Query Entities など) の発行には、任意のバージョンのストレージを使用できます。

こちらのページに掲載されている MSDN のドキュメントでは、REST API の Set Blob Service Properties (REST API)Set Queue Service Properties (REST API)、および Set Table Service Properties (REST API)を使用して CORS ルールを構成する方法を説明しています。

このセクションでは、CORS ルールの構成例を簡単に説明し、Windows Azure ストレージ クライアント .NET ライブラリ 3.0 (英語)を使用して CORS の有効化および構成を行う方法を紹介します。

CORS ルールは、BLOB、テーブル、キューの各ストレージ サービスでそれぞれ 5 個まで構成できます。次に示すのは、CORS ルールを 1 つだけ構成した場合の例です。

<CorsRule>

<AllowedOrigins>http://www.contoso.com, http://www.fabrikam.com</AllowedOrigins>

<AllowedMethods>PUT,GET</AllowedMethods>

<AllowedHeaders>x-ms-meta-data*,x-ms-meta-target,x-ms-meta-source</AllowedHeaders>

<ExposedHeaders>x-ms-meta-*</ExposedHeaders>

<MaxAgeInSeconds>200</MaxAgeInSeconds>

</CorsRule>

各 XML 要素の詳細な説明については、こちらの MSDN ドキュメントを参照してください。

上に示したルールでは、次の条件を満たす CORS 要求を許可します。

  • 発信元が http://www.contoso.com または http://www.fabrikam.com のいずれか (AllowedOrigins)
  • かつ、PUT または GET の HTTP 要求を含む (AllowedMethods)

AllowedOriginsAllowedMethodsは、両方とも "*" を使用して設定することもできます。これは最も一般的な使用方法で、サービスは、あらゆる発信元から呼び出されたあらゆるメソッド (PUT、POST、GET など) に対して必要な CORS ヘッダーを送信します。しかし、この場合でも、誰もがユーザーのアカウントにアクセスできるわけではなく、先に述べたように適切な認証署名が必要です。

AllowedHeadersには、クライアント (JavaScript コード) がストレージ アカウントに送信可能な要求ヘッダーを指定します。プレフライト要求または実際の要求のいずれかに対して Windows Azure ストレージ サービスから返される Access-Control-Allow-Headers 応答ヘッダーには、許可されるヘッダーのリストが含まれています。これにより、Web ブラウザーは許可されたヘッダーを把握し、AllowedHeaders の構成を強制適用します。ブラウザーから呼び出しが発行されたときにクライアントにメタデータ情報をまったく保存しないようにして、同時に、x-ms-meta-reserved キーに含まれるすべての情報の保存を許可しない場合、上記の例のように、x-ms-meta-data から始まる、あるいは x-ms-meta-target または x-ms-meta-source と完全一致するキーの名前のみにメタデータを制限します。通常は、すべての要求のヘッダーを許可するように、この構成には * を設定します。

ExposedHeadersは、クライアントの JavaScript コードに対して公開できる応答ヘッダーを指定するものです。この構成も、Web ブラウザーが強制適用します。実際の要求に対して Windows Azure ストレージ サービスから返される Access-Control-Expose-Headers 応答ヘッダーには、指定されたヘッダーのリストが含まれています。これにより、Web ブラウザーは指定されたヘッダーを把握し、ExposedHeaders の構成を強制適用します。通常は、すべての応答のヘッダーを許可するように、この構成には * を設定します。

MaxAgeInSecondsは、プレフライトの OPTIONS 要求のキャッシュをブラウザーが保持できる時間の最大の長さを指定します。上記の例では、200 秒に設定されています。ルールを頻繁に変更しない場合、MaxAgeInSecondsには多少大きめの値を設定することを推奨します。こうすることにより、ラウンドトリップが減少して Web アプリケーションの応答性が向上し、また有料であるプレフライト要求が減少してストレージの使用料金が抑えられるという効果があります。

CORS ルールの評価は、REST API の Set Service Properties の XML で出現する順に実行されます。このため、最も厳しい条件を最初に配置し、* を指定したルールはすべて最後に配置します。CORS ルールの評価の詳細については、MSDN のドキュメントの「CORS ルールの評価ロジックについて」を参照してください。

Windows Azure ストレージクライアントライブラリ 3.0 を使用して CORS を有効化するコードのサンプル

ここからは、Windows Azure ストレージ アカウントの BLOB サービスおよびテーブル サービスで CORS を有効化するコードのサンプルについて説明します。このコードは、こちらのページ (英語)で公開しているサンプル コードの一部です。

このコードは、まず現在のサービスのプロパティを GET し、すべての発信元および HTTP メソッド (PUT、GET、HEAD、POST) を許可するという 1 つのルールに従って CORS を有効化します。その後、変更が適用されたサービスのプロパティを BLOB およびテーブルの両サービスにコミットします。

private static void InitializeCors()

{

// サービスの起動後 CORS を有効化

// BlobClient を指定し、現在のサービスのプロパティをダウンロード

ServiceProperties blobServiceProperties = BlobClient.GetServiceProperties();

ServiceProperties tableServiceProperties = TableClient.GetServiceProperties();

 

// CORS を有効化し構成

ConfigureCors(blobServiceProperties);

ConfigureCors(tableServiceProperties);

 

// CORS の変更をサービスのプロパティにコミット

BlobClient.SetServiceProperties(blobServiceProperties);

TableClient.SetServiceProperties(tableServiceProperties);

}

private static void ConfigureCors(ServiceProperties serviceProperties)

{

serviceProperties.Cors = new CorsProperties();

serviceProperties.Cors.CorsRules.Add(new CorsRule()

{

AllowedHeaders = new List<string>() { "*" },

AllowedMethods = CorsHttpMethods.Put | CorsHttpMethods.Get | CorsHttpMethods.Head | CorsHttpMethods.Post,

AllowedOrigins = new List<string>() { "*" },

ExposedHeaders = new List<string>() { "*" },

MaxAgeInSeconds = 1800 // 30 分

});

}

BLOB Windows Azure ストレージにアップロードする JavaScript のサンプルコード

以下に示すサンプルは、Web ブラウザーから Windows Azure ストレージにファイルを直接アップロードする JavaScript のコードの一部です。コード全文はこちらのページ (英語)で公開しています。次のコードは UploadImage.cshtml ファイルの一部です。

// BLOB の SAS の URL を使用して BLOB を Azure ストレージにアップロードするメソッド

// Web ブラウザーが、必要な CORS ヘッダーを追加し、必要に応じてプレフライト要求を発行

// blobSasUrl: BLOB の SAS の URL。自身のサービスに対する Ajax の呼び出しにより取得済み

// fileDataAsArrayBuffer: アップロードするファイルの生データを含む ArrayBuffer (Byte 配列)

function uploadImage(blobSasUrl, fileDataAsArrayBuffer) {

var ajaxRequest = new XMLHttpRequest();

// 画像が正常にアップロードされた後、その画像を表示する renderImage を呼び出す

ajaxRequest.onreadystatechange = function() {return renderImage(ajaxRequest, blobSasUrl)};

 

try {

// ストレージに対し Put Blob (ブロック BLOB) を実行

ajaxRequest.open('PUT', blobSasUrl, true);

ajaxRequest.setRequestHeader('Content-Type', 'image/jpeg');

ajaxRequest.setRequestHeader('x-ms-blob-type', 'BlockBlob');

ajaxRequest.send(fileDataAsArrayBuffer);

}

catch (e) {

alert("サーバーに画像をアップロードできませんでした。\n" + e.toString());

}

}

次のコードでは、最初に ASP.NET サービスを呼び出して BLOB の SAS の URL を取得し、最終的には上記の uploadImage メソッドを呼び出します。まず、指定されたファイルを読み込み、次に、BLOB の SAS の URL を取得します。最後に uploadImage を呼び出し Azure ストレージに画像をアップロードします。

// このメソッドは、アップロード対象の画像をユーザーが選択した後に呼び出される

// 選択されたすべてのファイルを対象としてループ処理し、1 つずつ Azure にアップロード

function handleFileSelect(evt) {

var files = evt.target.files; // 選択されたすべてのファイル (FileList オブジェクト)

 

// FileList をループ処理し、保存してファイルのサムネイルを表示

for (var i = 0, file; file = files[i]; i++) {

// ファイルのデータ全体を ArrayBuffer として読み込むための reader を作成

var reader = new FileReader();

 

// Azure BLOB の SAS の URL を要求する際に使用される AJAX の URL

file.getSasUri = "/Home/GetBlobSasUrl" + "?blobName=" + file.name;

 

reader.onloadend = (function (theFile) {

return function (e) {

// reader がファイルの読み込みを終了した後

// サービスに対して AJAX の呼び出しを発行し、SAS の URL を取得

$.ajax({

type: 'GET',

url: theFile.getSasUri,

success: function (res, status, xhr) {

// GetBlobSasUrl を呼び出して、必要な BLOB の SAS を生成

blobSasUrl = xhr.responseText;

// これで、画像のアップロードに使用する SAS の URL の取得が完了

// この SAS の URL を渡し、ArrayBuffer をアップロード

uploadImage(blobSasUrl, e.target.result);

},

error: function (res, status, xhr) {

alert("サーバーから SAS を取得できませんでした。");

}

});

};

})(file);

// 画像ファイルを ArrayBuffer として読み込み、完了後に reader.onloadend イベントが発生

reader.readAsArrayBuffer(file);

}

}

Windows Azure テーブルにアクセスする JQuery のサンプルコード

こちらのページ (英語)で、Insert Entity および Query Entities 操作を行う JQuery のサンプル コードを公開しています。まずは InsertTableEntities.cshtml と QueryTableEntities.cshtml の両ファイルからご覧ください。

CORS のサンプル コード

CORS のサンプル コードはこちらのページ (英語)で公開されています。最新バージョンの NuGet Package Manager (英語)がインストールされていて、参照先のライブラリにアクセスできることを確認してください。

既定では、このサンプルは Windows Azure ストレージ エミュレーターを使用するように構成されています。エミュレーターはこちらのページからダウンロードできます。AzureCommon.cs ファイルの中で AzureCommon.StorageAccount を構成すると、Windows Azure ストレージ アカウントを使用できるようになります。

まとめ

簡単にまとめると、Windows Azure ストレージで CORS をサポートすると、アプリケーション開発者は、自身の Web ページでスクリプトを使用して、Web サービスからの呼び出しをプロキシ転送せずに Windows Azure ストレージの各リソース (BLOB、テーブル、キュー) と直接やり取りすることができるようになります。また、Windows Azure ストレージ クライアント ライブラリ (英語)を使用すると、CORS を簡単に構成できます。

Wael Abdelghani、Jean Ghanem

 

参考資料

MSDN で公開されている CORS のサンプル コード (英語)

Windows Azure ストレージのリリース - CORS、JSON、分単位メトリックなど各種機能の導入

2013-08-15 REST バージョンのストレージのリリース ノート

Windows Azure ストレージ サービスでのクロス オリジン リソース共有 (CORS) のサポート

Windows Azure ストレージのライブラリ

ソチ オリンピックのライブ ストリーミングで NBC とパートナーシップを締結

$
0
0

このポストは、2 月 6 日に投稿された Announcing NBC Partnership to Live Stream the Sochi Olympic Gamesの翻訳です。

NBC とマイクロソフトは、ロシアのソチで開催される 2014 年冬季オリンピックのライブ ストリーミングに、Windows Azure メディア サービスが使用されることを発表しました。前回のオリンピックではライブ ストリーミングが行われたのは一部だけでしたが、今回は非常に規模が大きくなり、全 98 競技で 1,000 時間を超えるコンテンツが、iOS や Android、Windows Phone、Windows 8、Windows RT などの各種デバイスやプラットフォームで視聴可能です。

NBC によるこの決定は、約 1 年前に一般提供が開始された Windows Azure メディア サービスの勢いを示すものであり、マイクロソフトのクラウド プラットフォームに対してお客様から信用と信頼をお寄せいただいている証でもあります。NBC は、コンピューティング能力とネットワークの利用にとどまらず、市場での需要を伸ばしている高レベルな PaaS サービスも活用する予定です。さまざまな場所で行われるさまざまな競技を、多様な移動体を利用して放送するオリンピックにおいて、安定した視聴環境を提供するというこれまでにない能力を実現させ、お客様に強力なエクスペリエンスをお届けできることを非常に嬉しく思っています。

マイクロソフトが NBC に提供する機能の詳細については、マイクロソフトの公式ブログ (英語)を参照してください。ソチ オリンピックの映像をライブまたはオンデマンドでご覧になりたいお客様は、NBCOlympics.com (英語)にアクセスしてください。


Barracuda Firewall を使用して Azure アプリケーションをセットアップ/保護する方法

$
0
0

このポストは、1 月 28 日に Ashwin Palekarが投稿した How to Setup and Protect an Azure Application with a Barracuda Firewallの翻訳です。

編集メモ: 今回は、シニア アプリケーション開発マネージャーを務める Tim Omta の投稿をご紹介します。

1 はじめに

Windows Azure でアプリケーションをホストする企業は、どこかの時点で、商業的に活用する目的でアプリケーションをインターネット上に公開する必要があります。インターネットへの公開は、顧客と攻撃者の両方の興味を引きつけることになり、アプリケーション内のデータの価値が上がるにつれ、攻撃者にとってそのアプリケーションの魅力はさらに高まっていきます。企業は、Azure で Web アプリケーションをホストすることによって得られる経済的メリットについては把握していますが、顧客に有益なエクスペリエンスを提供しつつ攻撃者からデータを保護するということに関しては、不安を抱いています。オンプレミスのデータセンターに関しては、攻撃者からアプリケーションを保護するためのインターネット エッジ デバイスが多数存在します。今日では、こうしたデバイスを製造するメーカーの何社かが、Windows Azure をはじめとするホスティング プロバイダー向けのソリューションの提供を開始しています。

Barracuda Networks はその 1 社であり、Windows Azure 向けに Web Application Firewall 仮想デバイスを開発しました。このデバイスでは、Azure IaaS Web サーバーや PaaS Web ロールを保護することが可能です。この記事では、シンプルな PaaS アプリケーションのセットアップ方法を段階的に説明しながら、Barracuda が提供する Windows Azure 向けネットワーク セキュリティ ソリューションについてご紹介していきます。ここでは主に以下の重要な項目についてご紹介します。

  • ネットワークのセットアップ
  • Azure PaaS アプリケーション
  • Barracuda Web Application Firewall (WAF) のセットアップ
  • アプリケーションの公開

このガイドでは、以下の構成図に示すようなシステムを作成します。

2 ネットワークのセットアップ

最初に行うのはネットワークのセットアップです。ネットワークは、Azure 内で PaaS アプリケーション、Web Application Firewall (WAF)、インターネットを接続するにあたっての基礎となります。後から変更することはできないため、ここでは慎重な判断が必要とされます。まず、1 つのネットワーク、その中に 2 つのサブネット、さらに 1 つのアフィニティ グループを作成していきます。ネットワークは、全リソースが参照する IP アドレスの総合プールとなります。また、2 つのサブネットには、Subnet-1 と Subnet-2 という名前を付けます。Subnet-1 は WAF サブネットとなり、WAF のみを含みます。Subnet-2 はアプリケーション サブネットとなり、アプリケーション PaaS ロールのみを含みます。このようにサブネットを区別する理由は、通信するリソースのタイプを、そのアドレスによって把握できるようにするためです。また、区別することによって、各タイプのリソースのセキュリティをサブネットごとに確保できるようになります (サブネットは基本的にリソース タイプでグループ化するため、グループを適切に扱うことができます)。サブネットは、セキュリティとアドレス割り当ての境界を規定します。

最後に、アフィニティ グループを作成することにより、すべてのマシンと新規に作成されたネットワークとをグループ化するように、Azure に通知することができます。また、アフィニティ グループは、通信の待機時間 (レイテンシ) を短縮するためにリソースを地理的に併置します。

2.1 ネットワークとアフィニティグループを作成する

まず、Azure 管理ポータル (http://manage.windowsazure.com/) にサインインします。

左側のウィンドウから [NETWORKS] をクリックします。

ページ上部中央の [VIRTUAL NETWORKS] をクリックします。

左下部にある [NEW] をクリックします。

[NETWORK SERVICES] をクリックします。

[VIRTUAL NETWORK] をクリックします。

[CUSTOM CREATE] をクリックします。

このダイアログで、慎重に名前を選択するようにします。以降、このインフラストラクチャ全体を通じてこのネットワーク名とアフィニティ グループ名を使用することになるため、後からこれらを変更することは推奨されません (変更するとすべて台無しになります)。

[NAME] テキスト ボックスにネットワーク名を入力します。

[AFFINITY GROUP] で「Create a new affinity group」が選択されていることを確認します。

ネットワークを作成し、リソースを地理的に配置するリージョンを選択します。

アフィニティ グループの名前を入力します。

[OK] をクリックします。

2.2 ネットワークアドレスとサブネットアドレスの範囲を決定する

次に、下の画像のようなページが表示されます。

ネットワークのアドレス空間を選択します。ここでは「172.16.x.x」という全体的なネットワーク アドレス範囲を選択したため、最初の 2 つのドット付き数字 (オクテット) は、このネットワーク上のすべてに共通して使用されます。「172.16.1.0/16」は、IP アドレスの割り当てを「172.16.1.0」から開始するつもりであり、最後の 16 ビット (最下位の 2 つのオクテット) をアドレスとして変化させるということを Azure に通知します。最下位の 2 つのオクテットを、それぞれサブネット番号とデバイス アドレスとして使用します。

[ADDRESS SPACE] に「172.16.1.0/16」と入力します。

「172.16.1.0/24」のアドレス空間に「Subnet-1」という名前のサブネットを追加します。

「172.16.2.0/24」のアドレス空間に「Subnet-2」という名前のサブネットを追加します。

ネットワークは、以下の画像のとおりに作成され、ポータルに表示されます。

以上で、Subnet-1 に WAF を配置し、Subnet-2 にアプリケーションを配置するための準備ができました。

次に、保護対象となるアプリケーションの作成と構成を行います。

3 Azure PaaS アプリケーション

このステップでは、アプリケーションを作成し、Paas Web ロールにそのアプリケーションをデプロイします。ここで重要なのは、アプリケーションそのものではなく、アプリケーションの構成になります。構成は、WAF で保護するすべての Web ロールに対して行う必要があります。また、この構成は、ここまでの手順で作成したネットワーク レイアウトが準備されていることを前提としています。ネットワーク名、アフィニティ グループ、サブネット名は、アプリケーションの構成に不可欠です。デプロイされたアプリケーションはインターネットからのトラフィックを直接受け取ることはできず、自身のサブネット (Subnet-2、アプリケーション サブネット) と WAF サブネット (Subnet-1、WAF サブネット) 上のロールとのみ通信できます。

3.1 デモ アプリケーションを作成する

Visual Studio で、[File] メニューを開き、[New] を選択して、[Project] をクリックします。

左側のウィンドウで [Cloud] を選択します。

中央のウィンドウで [Windows Azure Cloud Service] テンプレートをクリックします。

プロジェクトの名前を入力するか、既定の名前 (WindowsAzure1) をそのまま使用します。ここでは「DemoApp」という名前を付けたので、これ以降、この名前がアプリケーション名として表示されます。

[OK] をクリックします。

次のダイアログで、[ASP.NET Web Role] をクリックします。

[>] ボタンをクリックして、この Web ロールを追加します。

[OK] をクリックします。

Default.aspx を開いて、<h2> タグ コンテンツを以下のように変更します。

変更前: Modify this template to jump-start your ASP.NET application

から

変更後: This application is protected by the Barracuda Web Application Firewall

ここまでの手順で、標準の Azure Web ロール アプリケーションが作成されました。以降の修正は、Azure の WAF の背後に配置する必要があるすべてのアプリケーションに対して行うべき重要な修正です。

3.2 アプリケーションを構成する

まずアプリケーションの構成を変更して、それをネットワークのアプリケーション サブネット (Subnet-2) に配置します。

Visual Studio クラウド プロジェクトで、ServiceConfiguration.Cloud.cscfg ファイルを開きます。

下の図に示すように、ServiceConfiguration タグ内に次の NetworkConfigurationセクションを追加します。Role の終了タグの直後に追加できます。

<NetworkConfiguration>

<VirtualNetworkSitename="DemoVNet"/>

<AddressAssignments>

<InstanceAddressroleName="WebRole1">

<Subnets>

<Subnetname="Subnet-2"/>

</Subnets>

</InstanceAddress>

</AddressAssignments>

</NetworkConfiguration>

ネットワーク名に VirtualNetworkingSite の名前属性を割り当てます。先ほど付けたものと同じ名前を使用している場合、ネットワーク名は「DemoVNet」となります。

既にこのファイルにある Role タグの名前属性と同じ値に InstanceAddress タグの roleName 属性を割り当てます。

さきほど作成し、アプリケーション サブネットの「Subnet-2」として指定したサブネットの名前に、Subnet タグの名前属性を割り当てます。

これで ServiceConfiguration.Cloud.cscfg は、以下のようになります。

ファイルを保存します。

3.3 アプリケーションファイアウォールの構成のためにコマンドファイルを追加する

この作業の主な目的は、WAF サブネット (Subnet-1) からのトラフィックを受け入れるために、PaaS ロールのファイアウォールを開放するコードを追加することです。ここでは、netsh (英語)を呼び出すロール起動タスクを使用して、ファイアウォール ルールを追加する方法をご紹介します。これは、他の方法 (ロールの OnStart メソッドでの C# コードなど) でも実現できます。

WebRole1 プロジェクトを右クリックします。

[Add] をクリックします。

[Text File] を選択します。

ファイルに「Start.cmd」という名前を付けます。

[OK] をクリックします。

start.cmd に以下の行を追加します。

eventcreate /ID 1 /L APPLICATION /T INFORMATION /SO demoWebApp /D "Webrole start task complete" netsh firewall add portopening protocol=TCP port=80 name="demoWebApp" mode=ENABLE scope=CUSTOM addresses=172.16.1.0/255.255.255.0 profile=CURRENT

最初の行は、start.cmd が起動したことを示すイベントを Windows Server アプリケーションのイベント ログにポストします。

2 番目の行は、WAF サブネットからのトラフィックのために、Paas Web ロール上で TCP トラフィック用にポート 80 を開放します (前の段階で、172.16.1.x アドレス空間に Subnet-1 を作成しました)。

既定では、Visual Studio は start.cmd を Unicode で保存しますが、cmd コマンド プロセッサはこれを実行できません。cmd が実行されるように、ファイルは確実に ASCII エンコーディングで保存する必要があります。

この設定を行うには、Visual Studio の [File] メニューをクリックして [Advanced Save Options] を選択します。

[encoding] を「US-ASCII – Codepage 20127」に変更します。

[OK] をクリックします。

ソリューション エクスプローラーで start.cmd を選択します。

start.cmd ファイルの [Properties] で、[Build Action] を「None」に設定します。

[Copy to Output Directory] を「Copy Always」に設定します。

start.cmd ファイルを保存します ([File]、[Save] の順にクリック)。

これで、ロールが起動されたときに実行するバッチ ファイルが作成されました。次に、ロールを構成して、インターネット トラフィックを受け入れず、実際に start.cmd ファイルを実行するようにする必要があります。

3.4 アプリケーションエンドポイントと起動タスクを構成する

クラウド プロジェクトで、ServiceDefinition.csdef ファイルを開きます。

InputEndpoint タグを InternalEndpointに変更します。

Endpoints の終了タグの下に、start.cmd を実行する Startupタグを追加します。

<Startup>

<TaskcommandLine="start.cmd" executionContext="elevated" taskType="simple"></Task>

</Startup>

ServiceDefinition.csdef は、以下のようになります。

ファイルを保存します。

3.5 適切なアフィニティグループにアプリケーションのクラウドサービスを追加する

次に、アプリケーションをホストするクラウド サービスをカスタム作成する必要があります。クラウド サービスのカスタム作成によって、ここで作成したネットワークのアプリケーション サブネット (Subnet-2) 内にアプリケーションを配置できることを後で確認するアフィニティ グループを指定できるようにします。

Azure 管理ポータルで、左側のウィンドウにある [CLOUD SERVICES] をクリックします。

左下にある [NEW] をクリックします。

[COMPUTE]、[CLOUD SERVICE] を順に選択します。

[CUSTOM CREATE] をクリックします。

アプリケーション クラウド サービスに、任意の URL を指定します。ここでは、アプリケーションと同じ名前を使用します。

ネットワークの作成時に作成したアフィニティ グループを選択します。この手順は重要です。これによって、ネットワークと同じグループにアプリケーション クラウド サービスを配置できるためです。

OK チェック マークをクリックします。

3.6 アプリケーションを発行する

最後に、カスタム作成したクラウド サービスにアプリケーションを発行します。

Visual Studio で [Cloud Project] を右クリックして、[Publish…] を選択します。

サブスクリプションを選択します。

[Next] をクリックします。

直前に作成したクラウド サービスを選択します。サービスと関連付けたアフィニティ グループが表示されることを確認してください。

RDP やその他の必要な設定を構成します。

[Next] をクリックします。

最後に、以下のような概要が表示されます。

[Publish] をクリックします。

数分後、アプリケーションが Azure に発行され、実行されます。RDP を有効にすると、PaaS ロール インスタンスにログオンしてイベント ログを見ることができます。起動タスクが正しく動作していれば、ロール アプリケーション ログに「Webrole start task complete」というメッセージが表示されます。ここで作成した start.cmd ファイルの詳細を見ると、最初の行がこのイベント メッセージをポストしていることがわかります。また、このロールの Windows Firewall コンソールにリストされたファイアウォール ルールを確認することもできます。このルールは、start.cmd の netsh 行で付けられた名前で表示されます。

アプリケーションが正常に起動し、動作しているので、WAF のセットアップに移ります。

4. WAF のセットアップ

WAF VHD ファイルをお持ちでない場合は、Barracuda Networks から入手する (英語)必要があります。「Barracuda Web Application Firewall Azure Virtual Device」をリクエストしてください。

4.1 Azure ストレージアカウントに Barracuda VHD アップロードする

以下に示すような add-azurevhd (英語) Azure PowerShell コマンドレットを使用することができます。基になる変数は、Barracuda 社のサイトからダウンロードした vhd への完全なパスです。対象になる変数は、ストレージ アカウントの URL、コンテナー、および vhd のアップロード先となるファイル名です。Azure PowerShell コマンドレットのセットアップ手順については、http://msdn.microsoft.com/ja-jp/library/windowsazure/jj156055.aspxを参照してください。

4.2 VHD から仮想マシンディスクを作成する

Azure 管理ポータルで、左側にある [VIRTUAL MACHINES] を選択します。

ページ上部中央の [DISKS] をクリックします。

[CREATE] をクリックします。

次のダイアログで、ディスクに名前を付けます。

[VHD URL] に、アップロードした vhd のパスとファイル名を設定します。

[The VHD contains an operating system] チェック ボックスをオンにします。

オペレーティング システムとして「Linux」を選択します。

チェック マークをクリックします。

これでディスクが作成されます。次のステップでは、ディスクから仮想マシンを作成します。

4.3 IaaS Barracuda 仮想マシンを作成する

ディスクから仮想マシンを作成するには、管理ポータルで [VIRTUAL MACHINES] を選択します。

ページ下部の [NEW] ボタンをクリックします。

[COMPUTE]、[VIRTUAL MACHINE] を順に選択します。

[FROM GALLARY] をクリックします。

次のダイアログで、左側にある [MY DISKS] をクリックします。

右側のリストを一番下までスクロールします。

今作成したディスクをクリックします。

この仮想マシンに名前を付けます。

仮想マシンのサイズを選択します。サイズの選択は、WAF が処理しなければならないトラフィックの量により変わります。サイトのトラフィックが極端に少ないのでなければ、最低でも [Medium] を選択するとよいでしょう。

[Next] 矢印をクリックします。

[CLOUD SERVICE] リスト ボックスで、「Create a new cloud service」を選択します。

クラウド サービスの DNS 名を選択します。

仮想ネットワークを、手順 1 で作成した仮想ネットワーク「DemoVNet」に設定します。

サブネットを、手順 1 で作成した WAF サブネット「Subnet-1」に設定します。

[Next] 矢印をクリックします。

HTTPS エンドポイントを追加することにより、WAF に TCP ポート 443 を開放します。

OK チェック マークをクリックします。

Azure は仮想マシンを作成し、起動します。WAF 仮想マシンの起動までしばらく待つと (30 分程度)、安定した状態になります。仮想マシンの状態は、Azure 管理ポータルの仮想マシン ダッシュボードで確認できます。ダッシュボードで、CPU 使用率の登録が開始されます。

4.4 Barracuda 仮想デバイスをプロビジョニングする

ブラウザーを開いて、WAF 管理ページに移動します。WAF 管理ページの URL は、前のセクションで指定した仮想マシンのクラウド サービスの DNS 名です。ここでは、https://omtaDemoWAF.cloudapp.netとなっています。技術情報として、Barracuda のサイト (http://techlib.barracuda.com/display/BWAFv76/Barracuda%2BWeb%2BApplication%2BFirewall%2BVx%2BQuick%2BStart%2BGuide%2B-%2BWindows%2BAzure、英語) に、起動中は SSL 管理サイトにアクセスできない場合がある旨が掲載されています。このことが問題になる場合は、前のステップで Azure ポータルから作成したクラウド サービスに、エンドポイントとしてポート 8000 を追加し、次にポート 8000 で明白な HTTP (この例では http://omtaDemoWAF.cloudapp.net:8000) の管理サイトにアクセスしてデバイスの状態について確認します。

今回初めて WAF にアクセスしたので、以下の管理ページが表示されます。

Barracuda のライセンス トークンを入力します。

アプリケーションが配置される DNS ドメイン (contoso.net または、任意のドメイン) を入力します。

[Provision] ボタンをクリックします。

ブラウザーを閉じて、WAF のプロビジョニングが完了するまで数分待ちます。WAF は自動的に再起動して、しばらくすると元に戻ります。

これで、次の手順のアプリケーションの発行を行う準備ができました。

5. アプリケーションの公開

最後に、インターネットから WAF 経由でアプリケーションにつながるリンクを作成します。

5.1 WAF 仮想サービスを作成する

ブラウザーを開いて、手順 3 のステップと同様に、WAF 管理ページに移動します。

今回はログイン ページが表示されるため、ここに Barracuda の既定の管理ユーザー名を入力します。

管理ユーザー用の既定のパスワードを入力します。

[Login] ボタンをクリックします。

WAF 管理ポータルにログインし、[BASIC] タブをクリックします。

リボンで [Services] をクリックします。

WAF サービスと、仮想サービスを追加するセクションをリストしたページが表示されます。WAF サービスは、WAF に入ってくるトラフィックと PaaS アプリケーション間のリンクです。PaaS アプリケーションは内部エンドポイント付きで作成されているため、インターネットからファイアウォールで遮断されています。

[Service Name] テキスト ボックスに仮想サービスの名前を入力します。

[Virtual IP Address] テキスト ボックスに WAF の IP アドレスを入力します。WAF は Subnet-1 (WAF サブネット) の最初のデバイスなので、「172.16.1.4」というアドレスになります。Azure のアドレスは DHCP アドレスですが、所定のサブネット内で Azure が提供する最初のアドレスは常にネットワーク範囲の最初から 4 番目のアドレスです。

[Port] テキスト ボックスに「81」と入力します。

[Real Servers] テキスト ボックスに最初の PaaS ロール サーバーの IP アドレスを入力します。このアドレスは「172.16.2.4」になります (Subnet-2 (アプリケーション サブネット) の最初のサーバーであるため)。

[Add] ボタンをクリックします。

ここまでの手順で、WAF に仮想サービスを作成しました。仮想サービスは WAF にポート 81 でインターネットから入ってくるトラフィックを調査し、ポリシーと照合し、これが準拠していればそのトラフィックをポート 80 のバックエンド PaaS アプリケーション サーバーに渡します。ここではポート 81 を選択しましたが、これは、アプリケーションが公開されるものと同じポートを選択する必要がないことを示すためです。仮想サービス用にポート 80 を選ぶこともできますので、ご自身でお試しください。

サービス ページは、以下のようになります。

5.2 WAF 仮想サービスをインターネットに公開する

次に、インターネットから WAF へのトラフィックを許可するように、Azure に通知する必要があります。これには、ポート 81 を WAF クラウド サービスのエンドポイントに追加します。

Azure 管理ポータルで、左側のウィンドウにある [VIRTUAL MACHINES] をクリックします。

WAF 仮想マシン名をクリックします。

ページ上部中央の [ENDPOINTS] をクリックします。

ページ下部中央の [ADD] ボタンをクリックします。

[Add a Stand-Alone Endpoint] を選択します。

[Next] 矢印をクリックします。

[Name] テキスト ボックスに、エンドポイントの名前を入力します。

プロトコルとして「TCP」を選択します。

パブリック ポートを「81」に設定します。

プライベート ポートを「81」に設定します。

チェック マーク ボタンをクリックして、エンドポイントを追加します。

これで、エンドポイントのリストは以下のようになるはずです。これらは、インターネットから WAF 仮想マシンへの通信を Azure が許可するポートです。

この時点で、WAF IaaS マシンをホストするクラウド サービスに付けた DNS 名を使用して、アプリケーションにアクセスすることが可能になっているはすです。このデモでは omtaDemoWAF を使用したので、URL は http://omtaDemoWAF.cloudapp.net:81/default.aspxになります。

これで設定は完了です。

6. 負荷分散とフォールトトレランス

ここまでの手順では、操作の基本を学習しました。次に、フォールト トレラントと負荷分散を実現するシステムを作成するステップに進みます。Barracuda 仮想デバイスをクラスター化して、セクション 5.1 で作成した WAF サービスに複数の PaaS ロールを配置することができます。

この記事の執筆時点では、仮想デバイスのクラスター化に関する資料はリリースされていませんが、物理デバイスの場合に関する情報は、http://techlib.barracuda.com/display/BWAFV76/How+to+Set+Up+a+High+Availability+Environment+with+Two+Barracuda+Web+Application+Firewalls (英語)からご確認いただけます。

この情報のうち、LAN、MGMT、ブリッジ モードに関する記述は無視してください (LAN と MGMT インターフェイスは、仮想デバイス上では同一です)。

セットアップが完了したら、システム間の構成は、複数の WAF ノードのアクティブ/アクティブ クラスターで同期することができます。クラスター内の 1 つのデバイスに加えられた構成の変更は、その構成クラスター内の他の全デバイスに伝達されます。

以下の設定は、クラスター化された WAF 間では伝達されません。クラスター化の時点であらかじめ設定が済んでいない場合は、クラスター内の各 WAF でこれらを手動で構成する必要があります。

  • WAN IP アドレス/ネットマスク/ゲートウェイ
  • システム DNS サーバー
  • システムのホスト名
  • クラスターの共有シークレット
  • システムのタイム ゾーン
  • システム IP/パスワード/シリアル
  • HTTP/HTTPS ポート (全マシン上で同じ値にしなければなりません)
  • HTTPS 証明書/設定
  • アピアランス名、ロゴ、または URL
  • リンク監視設定
  • リモート サポート オプション
  • NIC 速度/二重化設定

PaaS ロールに関しては、セクション 5.1 で最初の PaaS ロールを WAF サービスに追加したのと同じ要領で、他のロールも追加することができます。WAF は REST API を有しているため、このプロセスは自動化できます。PaaS ロールの OnStart メソッドに、起動時にそのロールを WAF サービスに追加するコードを記述することができます。今回の設定では、WAF が特定のサブネットに配置され、また、Azure は常にサブネットのアドレス範囲の 4 番目の IP を最初のデバイスに割り当てるため (この説明では最初の WAF に常に 172.10.1.4 が割り当てられます)、PaaS ロールが最初の WAF を検出して、自らを既知の WAF サービスに追加するように、構成設定を PaaS ロールに追加することができます。

反対に、PaaS ロールの OnStop メソッドに、ロールの終了時に WAF サービスからそのロールを削除するコードを記述することもできます。

説明は以上で終了です。この情報が、皆様のデータ保護とビジネスの拡大に少しでも役立つことを願っています。

Windows Azure Web サイトの自動復旧

$
0
0

このポストは、2 月 6 日に投稿された Auto-Healing Windows Azure Web Sitesの翻訳です。

編集メモ:今回は、Windows Azure Web サイト チームでプログラム マネージャーを務める Apurva Joshi による記事をご紹介します。

皆さんは、Web サイトを再起動するだけで解決できるような簡単な問題に対処するために、真夜中に呼び出された経験はありませんか。このような簡単な問題を自動検出し、自動的に復旧できればとても便利です。

Windows Azure Web サイト (WAWS) に施された今回の更新では、この機能の実現に向けて、「常時アクセス」機能をいくつかの点で強化しました。この機能強化により、Web アプリケーションをホスティングしているワーカー ロールのプロセスが自動的に再起動されるようになりました。この機能は「自動復旧」と呼ばれています。ここでは、そのしくみについてご説明します。

ユーザーが行うことは、Web サイトのルートにある web.config ファイルで、トリガーとその条件が発生したときに実行されるアクションを定義するだけです。構成セクションは、大まかに次のような構造になっています。

注意:「常時アクセス」と同様に、この機能は標準インスタンスでのみ使用可能です。

次に、使用可能なオプションをシナリオごとに詳細に説明していきましょう。

(サポート対象となっているすべての要素と属性についての詳細な説明は、この記事の最後にあります。)

シナリオ 1 – 「要求数に基づく再起動」

Y 時間の間に X 回の要求が処理された場合、アプリケーションを自動的に再起動するとします。短時間に膨大な数の要求が送られた場合、スケーリング機能では十分に対応できないため、このような状況を検出してワーカー プロセスを自動的に再起動し、このイベントをログに記録するようにします。

この場合、次の構成例を参考にして、ルートにある web.config ファイルをこのアプリケーション用に編集します (既に web.config が存在する場合は、既存の <system.webServer> セクションの下の <monitoring> セクションにコピーします)。

上記の構成例では、10 分間1000回の要求を処理した場合にワーカー プロセスを再起動し、eventlog.xml にイベントのログを記録します (eventlog.xml は Webサイトのルートにある Logfiles フォルダーの中にあります)。イベントのログ記録は、Web サイトの自動復旧が発生したことを把握し、トラブルシューティングや根本原因の解析のための重要な手掛かりを得るために役立ちます。最初の要求を受け取ったときに、timeInterval が時間のカウントを開始します。ここから要求数のカウントを開始し、timeInterval の期限に達する前に、設定した最大回数に達すると、アクションが実行されます。timeInterval の期限に達した場合、時間と要求回数の両方の値がリセットされます。上記の構成例の条件では、次のように処理が実行されます。

00:00:00 – 最初の要求を受理

00:09:59 – 998 回目の要求を処理

00:10:00 – タイマーが期限に到達したため、0 にリセット

00:10:01 – 999 回目の要求を処理

この例では、1 回目と 2 回目のどちらの timeInterval でも 1000 回の要求は発生しなかったため、アクションは実行されませんでした。

注意: Web サイトで複数のインスタンスを実行している場合、トリガー条件に達したインスタンスのワーカー ロールのみが再起動され、他のインスタンスでは再起動は実行されません。

次に、eventlog.xml に記録されたイベントのログの例を示します。

シナリオ 2 – 「要求の応答速度の低下に基づく再起動」

アプリケーションのパフォーマンスが低下し始め、ページの表示に長い時間が掛かるようになってきたとします。このような状況を検出し、ワーカー プロセスを自動的に再起動するようにします。

この場合、次の構成例を参考にして、ルートにある web.config ファイルをこのアプリケーション用に編集します (既に web.config が存在する場合は、既存の <system.webServer> セクションの下の <monitoring> セクションにコピーします)。

上記の構成例では、直近の 2 分間20 回の要求の処理に 45 秒以上掛かった場合を検出します。ここで、slowRequests は各要求の実行終了時に評価されるため、timeInterval の値は必ず timeTaken よりも大きな値を設定する必要があることに注意が必要です。

注意: Web サイトで複数のインスタンスを実行している場合、トリガー条件に達したインスタンスのワーカー ロールのみが再起動され、他のインスタンスでは再起動は実行されません。

次に、eventlog.xml に記録されたイベントのログの例を示します。

シナリオ 3 – HTTP ステータスコードに基づくイベントログの記録 (または再起動)

Web サイトが特定の HTTP ステータス コードやサブステータス コード、win32 のステータス コードを返す場合に、ユーザーに通知するとします。このとき、イベントのログを eventlog.xml (Web サイトのコンテンツのルートにある Logfiles フォルダーの中にあります) に記録するだけか、または再起動するかを選択することができます。

次の構成例を参考にして、ルートにある web.config ファイルをこのアプリケーション用に編集します。

上記の構成例では、直近の 30 秒間10 個の要求に対して 500 番のHTTP ステータスコード 100番のサブステータスコードが返された場合、eventlog.xml にイベントのログを記録します。

注意: Web サイトで複数のインスタンスを実行している場合、トリガー条件に達したインスタンスでのみイベントのログが記録され、他のインスタンスでは記録されません。オプションとして、イベントのログを記録するだけでなく、再起動することもできます。既定で、再起動のログは記録されるように設定されています。

次に、eventlog.xml に記録されたイベントのログの例を示します。

シナリオ 4 – 「メモリの制限に基づくカスタムアクション (または再起動/ログの記録) の実行」

Web サイトで発生したメモリ リークのトラブルシューティングを実施し、さらに、メモリ ダンプの作成、電子メール通知の送信、メモリダンプの作成とプロセスの再起動などといったカスタムのアクションを実行するとします。

この場合、次の構成例を参考にして、ルートにある web.config ファイルをこのアプリケーション用に編集します。

上記の構成例では、ワーカー プロセスのプライベートバイトが800MB に達したと検出された場合に、カスタムのアクションとして procdump.exeを実行し、小規模なメモリダンプを作成します。要求がワーカー プロセスのパイプラインに対して作成されることはないため、自動復旧は http.sys (カーネル ドライバー) からの特定の HTTP エラー コードによってトリガーされることはありません。このようなステータス コードの例としては、304、302、400 (400 番の多くが該当しますが、例外もあります)、503 などがあります。

注意: Web サイトで複数のインスタンスを実行している場合、トリガー条件に達したインスタンスでのみメモリ ダンプが作成され、他のインスタンスでは作成されません。オプションで、電子メールを送信するなどのカスタム アクションを実行することもできます。また、Web サイトのルート (d:\home) にある procdump.exe は、既定では使用できません。これは、Web サイトに xcopy 配置が存在する場合などが該当します。

次に、アクションで再起動を実行した場合に eventlog.xml に記録されたイベントのログの例を示します。

最後になりますが、FREB モジュールを使用すると、特定のページまたは URL に対してトリガー条件を構成できます。手順の詳細については、次のブログ記事をお読みください。

http://thenextdoorgeek.com/post/Windows-Azure-Web-Sites-(WAWS)-Collecting-dumps-of-the-worker-process-(w3wpexe)-automatically-whenever-a-request-takes-a-long-time (英語)

この場合、パフォーマンスに 5 ~ 10% の影響があります。また、FREB を有効化する必要があります。

注意: 共有モードと無料モードでは 1 時間後に自動的に FREB が無効化されるため、上記の手法は標準モードでも有効です。

ベスト プラクティス: Windows Azure Web サイト (WAWS)

$
0
0

このポストは、2 月 10 日に投稿された Best Practices: Windows Azure Websites (WAWS)の翻訳です。

編集メモ: 今回は、Windows Azure Web サイト チームでプログラム マネージャーを務める Sunitha Muthukrishna による記事をご紹介します。

Windows Azure Web サイト (WAWS、英語)を使用すると、高度にスケーラブルな Web サイトを Windows Azure で構築できます。WAWS の主なメリットは、次のとおりです。

  • リソースの有効活用:基本ユーザー数の増加に従ってアプリケーションの使用量も増加しますが、Web サイトのトラフィック パターンに基づいて事前にスケーリングすることができます。
  • 従量課金:お客様のニーズを満たすクラウド サービスを選択するうえで、コストは重要な考慮事項です。Azure Web サイトでは使用量に応じた料金体系 (従量課金) か、6 か月または 12 か月の月額プランを選択できます。詳しくは、Windows Azure Web サイトの料金詳細のページをご覧ください。
  • より短期間での製品化:インフラストラクチャのことを気にせずにアプリケーション開発に集中できるため、これまでよりも開発者の創造性や生産性を高めることに時間を使うことができ、アプリケーションの製品化までの期間が短縮されます。

ベスト プラクティス

ここからは、ベスト プラクティスをご紹介します。Windows Azure Web サイトのインフラストラクチャを効果的に活用し、エンド ユーザーに向けてパフォーマンスと信頼性の高い Web サイトを配信するためにお役立てください。

  • スケーラブルなアーキテクチャを構築する

Windows Azure Web サイトでは、Azure 環境でスケーラブルなソリューションを構築することができますが、このとき、サービスが提供するスケーラブルなインフラストラクチャを Web サイトで最大限に活用することが非常に重要です。

以下に、スケーラブルなソリューションを設計するうえでのポイントを挙げます。

1. アーキテクチャのボトルネックは、待機時間 (レイテンシ) を大きくする原因となる場合があります。このため、現行のアーキテクチャの主要なボトルネックをすべて調査します。ボトルネックは、アプリケーションの設計不良や帯域幅の制限などさまざまな理由で発生します。これらを回避するために、アプリケーション アーキテクチャのリファクタリングを行います。

2. さまざまなスケール構成 (インスタンスのサイズと数の組み合わせ) で Web サイトのロード テストを実施し、通常の負荷で最適なスケール構成を把握します。ロード テストを実行するには、Visual StudioApache Jmeter (英語)など、さまざまなツールが利用できます。

3. ご利用中の Web 解析ツールを使用し、Web サイトのトラフィック パターンや 1 秒間あたりの平均要求数などを調査します。

4. 予想外の量のトラフィックが発生した場合に備えて、自動スケーリングをセットアップします。詳細については「Web サイトをスケーリングする方法 (英語)」の記事を参照してください。

5. アプリケーションでデータベース層を使用している場合、Azure キャッシュ サービスなどの分散キャッシュ ソリューションを統合してパフォーマンスを向上させます。

  • 障害に対して耐久性の高いアーキテクチャを設計する

WAWS では充実したサービス レベル アグリーメント (英語)を提供していますが、業務の継続性を考慮すると、クラウド ソリューションの使用中にサービス障害が発生するリスクを理解し、このような場合に影響を軽減する方法を知っておくことが重要です。

次に示すのは、障害軽減策として必須のものです。

  • コンテンツのバックアップおよび復元を自動的に実行するツールを Windows Azure SDK で自作するか、Cloud Cellar (英語)などのサードパーティのサービスを利用する。
  • 2 つ以上のデータセンターに Web サイトの冗長コピーをセットアップし、受信トラフィックの負荷をデータセンター間で分散する。
  • グローバル トラフィック マネージャーを利用して、データセンターでの障害発生を想定した自動フェールオーバー機能をセットアップする。
  • Web サイトと並行してコンテンツ配信ネットワーク (CDN) サービスをセットアップし、コンテンツのキャッシュによりパフォーマンスを向上させると同時に、Web サイトの可用性も向上させる。
  • WAWS で運用している Web サイトと緊密に連携しているコンポーネントやサービスとの依存性を可能なかぎり排除する。

たとえば、データベースを利用している Web サイトで、何らかの理由によりデータベース サービスが一時的に停止し、アーキテクチャ内の 1 か所で障害が発生したとします。このデータベースは緊密に連携するコンポーネントであり、アーキテクチャから除外することはできません。このような場合、次の対策が考えられます。

- 複数のデータセンターにデータベースの複製を作成し、データベース間で自動的にデータを同期して、障害の影響を軽減する。

- 障害発生時の耐久性を考慮してアプリケーションを設計する。

依存関係にあるコンポーネントを使用する必要がある場合、堅牢性を高めるためには、複製という戦略は有効です。

  • クラウドに移行する前に、予期しない障害の発生に備えたリスク軽減戦略を策定します。
  • ステージング環境で Web サイトを構築し、サイトを停止して障害をシミュレートすることにより、障害発生時にどのような挙動を示すかを評価します。

 

  • インフラストラクチャを自動化する

Web サイトを正常に維持するためには、開発やデプロイメントなど、クラウド ソリューションに関連するさまざまな操作が必要です。この操作を自動化すると、アプリケーションのリリース サイクルの管理が容易になります。WAWS の機能はすべて WAWS REST API からアクセス可能なため、簡単に自動化することができます。

Web サイトの管理における重要な操作には、次のようなものがあります。

  • Web サイトへのデプロイメント

デプロイメントを行う場合、Web Deploy (英語)Git (英語)、FTP などのさまざまな方法が使用できます。ユーザーの好みにあったツールを Windows Azure SDKで構築すると、Web サイトへのコンテンツのデプロイを簡単に自動化できます。

  • ステージング環境のサイトを使用した試験導入

WAWS ではステージング発行がサポートされています。この機能では、更新を実際に顧客に公開している Web サイトに適用する前に、ステージング バージョンの Web サイトにデプロイし、本番環境でテストを実施できます。詳細については、「Windows Azure Web サイトでのステージング発行の実施 (英語)」を参照してください。

  • 診断ログの記録の有効化

WAWS には、アプリケーションのデバッグを支援する診断機能が組み込まれています。診断機能には次の 2 種類があります。

  • サイト診断: 詳細なエラー ログの記録、失敗した要求のトレース、および Web サーバーのログの記録が可能です。
  • アプリケーション診断: Web アプリケーションにより生成された情報を取得できます。

詳細については、「Windows Azure Web サイトでの診断ログの有効化 (英語)」を参照してください。

  • 監視機能の有効化

WAWS では、[Monitor] 管理ページで監視機能を使用できます。このページで、CPU 時間、HTTP クライアントのエラー、HTTP サーバーのエラーなど、さまざまな指標に対してアラートを設定し、Web サイトを継続的に監視することができます。詳細については、「Windows Azure Web サイトを監視する方法 (英語)」を参照してください。

  • セキュリティを確保する

WAWS プラットフォームは、セキュリティおよび信頼性に関する主要な業界標準に準拠していて、お客様に安全なプラットフォームを提供しています。しかし、アプリケーションに脆弱性があった場合、アーキテクチャが攻撃を受けるおそれがあります。

WAWS で安全なソリューションを構築するために、アプリケーションを作成する際には、攻撃に対抗可能な安全なコーディング手法に従う必要があります。詳細については、「安全なコードの作成方法 (英語)」を参照してください。

参考情報

Windows Azure Web サイトのチュートリアル (英語)

Windows Azure トラフィック マネージャー (英語)

Windows Azure のドキュメント

Web Deploy API の使用方法 (英語)

Windows Azure のセキュリティとコンプライアンスに関する概要

Windows Azure HDInsight が Hadoop 2.2 クラスターのプレビュー版をサポート

$
0
0

このポストは、2 月 13 日に投稿された Windows Azure HDInsight supports preview clusters of Hadoop 2.2の翻訳です。

マイクロソフトは昨年 10 月に Windows Azure HDInsight の一般提供を開始しましたが、このたび Windows Azure HDInsight で新たに Hadoop 2.2 クラスターのプレビュー版をサポートすることを発表しました。

Windows Azure HDInsight は、マイクロソフトが100%  Apache Hadoop をベースとして構築した Windows Azure用ディストリビューションです。Hadoop は大規模なデータの分析を行う分散ストレージおよび分散処理のプラットフォームであり、リレーショナル データと非リレーショナル データの両方に対応しています。HDInsight を使用すると、Azure ユーザーは、Windows Azure BLOB ストレージのデータや計算ノードのローカルにあるネイティブ HDFS ファイル システムのデータを利用することができます。さらに、Hadoop クラスターに動的にプロビジョニングしてデータを処理し、Windows Azure の柔軟なスケーリングを活用することも可能です。CIO Magazine (英語)では、HDInsight で大規模なデータを活用し、新しい種類のデータを統合して分析を行っているユーザーの特集記事を公開しています。ぜひご参照ください。

Windows Azure HDInsight での今回のサポートによって、クエリの応答時間が大幅に短縮 (最大で 40 倍) されるほか、データ圧縮 (最大で 80%) によってストレージ要件が緩和され、さらに YARN の利点 (英語) (Hadoop の新しいデータ処理システムへのアップグレード) も活用できるようになります 。Windows Azure HDInsight は、世界中に存在する Windows Azure のデータセンター設置地域のうち、中国以外の地域 (北米、ヨーロッパ、中東、アフリカ、アジア) でご利用いただけます。

Hadoop 2.2 のプレビュー版のサポートが決定した Windows Azure HDInsight の使用開始を検討しているお客様は、こちらのページ (英語)の案内をご参照ください。また、参考として以下に関連資料をまとめましたので、ぜひこちらもご確認ください。

祝 日本国内データセンター始動

$
0
0

きょうはみなさんに大変喜ばしいニュースをお知らせします。

プレスリリースですでにご案内の通り、明日、2014年2月26日にWindows Azureの国内データセンターがついに稼働を開始します。

Windows Azureがサービスを開始したのが2010年2月ですから、ちょうど4年。これまでも日本のお客様には香港をはじめとした世界8か所のデータセンター(リージョン)をご利用いただいてきました(*)が、国内にデータを置きたい、または様々な規制上国内にデータを置かなくてはならない、というお客様から日本のデータセンターを求める声をずっといただいていました。このご要望にお応えできる日を迎えたことを大変うれしく思います。
*富士通様とのパートナーシップによるFGCP/A5によって国内でWindows Azureのサービスをご利用いただくこともできました。

明日からさまざまなイベントもあります。まずは明日のCloud Days Tokyo 2014 Spring (@ホテルニューオータニ)の KEYNOTE 講演にお越しください。展示会場ではWindows Azureを支えてくださるパートナー様のソリューション展示があるほか、ブレイクアウトセッションでは企業内でどう使っていくか、を中心としたAzure関連5セッションを二日間で予定しています。

今後のイベント予定です。

2月26日-27日 Cloud Days Tokyo 2014 Spring (東京)

3月6日-7日 Cloud Days Osaka 2014 Spring (大阪)

3月11日 ITPro Active セミナー クラウド活用、次の一手 (福岡)

3月13日 ITPro Active セミナー クラウド活用、次の一手 (名古屋)

 

Azureのユーザーコミュニティ(JAZUG)によるコミュニティイベントも各地で開催予定があります。

2月26日 Windows Azure 4周年記念 Japan GeoオープンマジカJAZUG大会 (東京:日本マイクロソフト共催)

3月1日 地理冗長の中心でAzure愛を叫ぶ (名古屋)

3月6日 日本DCの本命、大阪でWindows Azureを愛でる会 (大阪)

3月7日 第1回JAZUG 札幌スタート!&Azure Japan Geo オープンマジカ記念勉強会 (札幌)

3月8日 修羅の街からこんにちわ♪JAZUG連動企画 by ふくあず (福岡)

3月15日 杜の都でAzure4周年を祝う♪ (仙台)

初めてという方も、この機会にお近くの会場に足をお運びください。


また、日本のデータセンターオープンを記念して、本日からアドベントカレンダーを1か月間実施します。通常のアドベントカレンダーは12月25日のクリスマスに向けて毎日ブログをつづっていく、というものですが、今回は記念日から1か月という形式を取ります。テーマは Windows Azure に関連したことなら、国内データセンターに特化した話題でなくても構いません。必ずしも技術的な投稿でなくても構いません。投稿したい方はご自身が持っているブログのURLをつけて投稿日をアドベントカレンダー(明日26日から公開) から登録してください。この投稿はこのアドベントカレンダーの初日の投稿になっています。

今後もみなさまのビジネス成長を Windows Azure でお手伝いしていきます。どうぞ日本のWindows Azureもよろしくお願いいたします。

 

Viewing all 711 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>