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

Windows Azure での多要素認証サービスのプレビュー版を公開

$
0
0

このポストは、6 月 13 日に投稿された Introducing Multi-Factor Authentication on Windows Azureの翻訳です。

編集メモ:今回は、Windows Azure 担当ディレクターを務める Sarah Fender の投稿をご紹介します。

ここ数か月にわたり、当ブログでは Windows Azure がもたらす企業にとってのメリットについてご説明しています。今回は、新サービス「Active Authentication (開発コード名)」をご紹介します。このサービスは多要素認証機能が提供するものであり、企業はこれを利用して、従業員、パートナー、そして顧客がクラウド アプリケーションにアクセスする際のセキュリティを確保できます。

このたび、Windows Azure Active Directory (AD) をお使いの企業で、Office 365、Windows Azure、Windows Intune、Dynamics CRM Online など Windows Azure AD に統合されている多数のアプリケーションへのログインに、多要素認証をご利用いただけるようになりました。開発者は、Active Authentication SDK を使用して、カスタム アプリケーションやディレクトリに多要素認証を組み込むことも可能です。

Active Authentication を使用すると、サインイン プロセスに手順が 1 つ追加されます。ユーザー名とパスワードを入力した後、さらにモバイル デバイス上の Active Authentication アプリケーション、または自動発信のテキスト メッセージや通話を利用した認証を要求されるようになるのです。これにより、クラウド上のデータやアプリケーションへの不正アクセスを防止し、データ漏えいのリスク緩和や法規制への準拠を実現できます。

Active Authentication は、昨秋、買収によってマイクロソフトに加わった、業界をリードする「PhoneFactor」のサービス (英語)をベースに構築されました。非常に簡単にセットアップ、管理、利用でき、企業のニーズを満たす強力なセキュリティを提供するほか、次のようなメリットが挙げられます。

  • 迅速なセットアップ: Windows Azure AD テナントに Active Authentication を追加するだけで、ユーザーが使用できるようにセットアップされます。また、たった数行のコードで、カスタム アプリケーションにも Active Authentication を追加できます。
  • 自動登録機能: Windows Azure AD ユーザーは、自身の電話番号を登録し、サインイン時の認証方式を設定できます。トークンを準備したり配布したりする必要がないため、世界中のユーザーに対してすばやく有効化することができます。
  • 拡張性:信頼性と拡張性に優れており、大容量のミッション クリティカル アプリケーションや、従業員やパートナー、顧客への大規模な展開をサポートします。

また、Active Authentication には、次の柔軟な支払いオプションが用意されています。想定される使用方法に応じて、最適なオプションを選択できます。

  • ユーザーごと: 多要素認証を使用しているユーザーの人数に応じて毎月請求されます。
  • 認証ごと: 実行した多要素認証の回数に応じて毎月請求されます。

Active Authentication は現在プレビュー版で公開されているため、製品版料金に 50% の割引が適用され、ユーザー 1 名ごとに 1 ドル (概算円 ¥83.04 )、または認証 10 回ごとに 1 ドル (概算円 ¥83.04 )の料金となっています。料金の詳細については、こちらのページを参照してください。

技術情報については、Windows Azure Active Directory ブログ (英語) (翻訳: SATO NAOKI ブログ Windows Azure Active Authentication: セキュリティとコンプライアンスのための多要素認証を参照ください) でさらに詳しくご紹介しています。多要素認証機能をお使いになる準備は整いましたか。まずは、ぜひ無料評価版をお試しください。


モバイル サービスの更新と通知ハブでの Android サポート

$
0
0

このポストは、6 月 14 日に投稿された Mobile Services updates and Android support for Notification Hubsの翻訳です。

先日、マイクロソフトでは、モバイル アプリケーションの強力かつ柔軟なバックエンドとしてモバイル サービスをこれまで以上に活用できるようにするための更新が発表されました。加えて、モバイル サービスまたは Web サイトで使用する 20 MB の SQL データベースが無料で提供されること、さらに、通知ハブで GCM を使用して Android デバイスにプッシュ通知を送信できるようになったことについても発表されました。

モバイル サービス

モバイル サービスでは、動的で魅力的な拡張性の高いモバイル アプリケーションを簡単、迅速に作成できます。今回、カスタム API とローカル Git によるソース管理を新たにサポートすることで、さらなる機能強化が行われています。

カスタム API

モバイル サービスでは、初期プレビュー リリース以降、サーバー スクリプト (英語)を使用して SQL データベース テーブルに挿入、読み取り、更新、削除の操作を行うカスタム ロジックを追加できるようになっています。Uservoice ページ (英語)に寄せられた中で最も要望の高かった機能の 1 つが、SQL データベース テーブルと関連付けずにサーバー側のスクリプトを作成できるカスタム API エンドポイントでした。

このたび発表されたリリースでは、この要望に応えるだけでなく、HTTP の要求および応答を介したさらなる制御が可能になりました。これにより、JSON 以外の形式を受信したり、独自の HTTP ヘッダーを検出、添付したりできるようになります。

Windows Azure 管理ポータルには、新たに [API] タブが含まれています。

[API]、[Create a Custom API] の順にクリックすると、モバイル サービスの SQL データベース テーブルでアクセス許可を設定する場合と同様の方法で、アクセス許可を設定できます。

ここでは、Express.js API (英語)を活用するスクリプトを作成できます。カスタム API を使用すると、(Windows の定期的な通知を有効化する) XML の送信、同一のスクリプトからのさまざまな HTTP メソッド (GET、POST など) の処理、高度なルーティングの実行、カスタム API スクリプト間でのコードの共有などが可能になります。

ローカル Git によるソース管理

お客様から強い要望が寄せられた機能としてさらに挙げられるのが、継続的な統合を可能にするソース管理です。今回発表されたローカル Git のサポートでは、継続的な統合が可能になるだけでなく、独自のノード モジュールをインストールすることもできるようになりました。

ローカル Git リポジトリをメイン ダッシュボードのモバイル サービスに接続して、[Set up source control] をクリックします。

[Set up source control] をクリックすると、リポジトリの資格情報を入力するよう求められます。

資格情報を入力すると、[Configure] タブに Git URL が表示されます。これを使用してリポジトリをローカルに複製します。

このリポジトリにはモバイル サービス用のフォルダーと、カスタム API スクリプト、テーブル スクリプト、およびスケジュールされたスクリプトのためのサブフォルダーが含まれます。ローカル リポジトリに新しいスクリプトを追加して、コマンド ラインから git push を実行すると、このスクリプトがポータルに表示されます。

ここで重要なのは、ソース管理を利用すると、モバイル サービスに更新プログラムを配信できるだけでなく、独自のノード モジュールをインストールすることもできる点です。ローカル Git リポジトリを設定すると、npm によって独自のノード モジュールがリポジトリにインストールされます。その後、git push を実行するだけで、標準の node.js 要求によってカスタム API スクリプトからこれらのモジュールを使用できるようになります。

安定した NuGet パッケージ

ポータブル クラス ライブラリ (PCL) をベースにしたモバイル サービス C# クライアント ライブラリの新しいバージョンを採用したことで、数多くの新たなシナリオが可能になりました。

  • ポータブル ライブラリによって、Windows ストアと Windows Phone 8 のライブラリを単一のコードベースに集約。この集約によって、さまざまな C# クライアントでモバイル サービスを使用したり、ASP.NET または.NET サーバー バックエンドからモバイル サービスを呼び出したりすることができるようになります。
  • Windows Phone 7.x 向けのターンキー型モバイル サービス機能
  • クライアントによって自動的に文字列にシリアル化される列挙型、Null 許容型、リストによる Contains クエリ、新しい MobileServicesCollection、HttpMessageHandlers、および単体テストの強化のサポート

先日リリースされた最新の更新プログラムでは、このパッケージ (英語)はプレリリース状態から移行されています。このパッケージは、パッケージ マネージャー コンソール (英語)で次のコマンドを実行するだけでインストールできます。

20 MB SQL データベースを無料提供

お客様がモバイル アプリケーションや Web アプリケーションの開発を行う場合、クラウドにリレーショナル データを格納する必要があります。また、開発やテスト期間中に無料のデータ オプションが利用できると便利です。こうした理由からマイクロソフトでは、Windows Azure のすべてのお客様に対して、Windows Azure のモバイル サービスまたは Web サイトで使用できる 20 MB の Windows Azure SQL データベース 1 つを 12 か月間無料でご提供します。

ご利用いただくには

新しいモバイル サービスあるいは Web サイトの作成時に、データベースのドロップダウン メニューで、この無料の Windows Azure SQL データベースを作成するためのオプションが表示されます (新しいモバイル サービスを作成する場合は、このオプションは自動的に表示されます。新しい Web サイトを作成する場合で、このオプションを表示するには、[Custom Create] を選択する必要があります)。

このオプションを選択すると、データ要件が 20 MB を超えない限り、20 MB の SQL データベースを無料でご利用いただけます。

Windows Azure のサブスクリプション 1 件につき、モバイル サービスまたは Web サイトで使用できる 20 MB の SQL データベース 1 つを無料で提供します。この SQL データベースは、複数のモバイル サービスや Web サイトに使用することもできます。データ要件が 20 MB を超える場合は、[SCALE] タブで上限を引き上げると、20MB 以上のデータベースを通常料金でご利用いただけるようになります。この SQL データベースは新規のデータベースとして提供されるものであり、既存のデータベースは対象ではありません。

通知ハブ

通知ハブを使用すると、Windows Azure でホストされるほぼすべてのバックエンドから、プラットフォーム上の数百万ものデバイスにプッシュ通知をブロードキャストできます。通知ハブは、プッシュ通知でユーザーの関心を引きつけることにより、仮想マシン、クラウド サービス、または Web サイトでホストされる既存のアプリケーションを進化させる有効な手段として利用できるほか、トピックに応じて異なるユーザー グループを登録することで、モバイル サービスを通じて充実したプッシュ通知機能を提供するための優れた手段としても活用できます。

今回、マイクロソフトは Microsoft Open Technologies (英語)と協力して、サポートされる一連のプラットフォームを対象に、Google Cloud Messaging (GCM) を利用した Android へのプッシュ通知機能を新たにサポートします。このリリースにより、Windows ストア、iOS、および Android のデバイスに対して、それぞれ WNS、APNS、GCM を通じてプッシュ通知をブロードキャストできるようになりました。

ご利用いただくには

Android デバイスにプッシュ通知をブロードキャストするには、Service Bus .NET Preview SDK (英語)Android SDK (英語)、および Android Notification Hubs SDK (英語)が必要です。

1.Google APIs Console ページ (英語)で Google API プロジェクトを作成し、API キーを生成します。プロジェクト URL の「#project」の後ろに続く数字を記録しておきます。これが GCM の送信者 ID となります。

2.GCM 送信者 ID を取得したら、Google APIs Console のメイン ページに戻って、[Service] を選択します。[Google Cloud Messaging] を [On] に設定して、サービス条項に同意したら、[API Access] を選択します。ここで、新しいサーバー キーを作成するよう求められます。

3.GCM に登録したら、Windows Azure 管理ポータルにログインして、[App Services]、[Service Bus]、[Notification Hub]、[Quick Create] の順にクリックします。

4.通知ハブの名前、地域 (待ち時間を短縮するためにアプリケーションと同じ地域を選択)、名前空間を選択します。

5.左側のナビゲーション バーにある [Service Bus] タブに、通知ハブ用の名前空間が表示されます。この名前空間をクリックしてから、[Configure] タブをクリックして、GCM API キーを入力します。[Save] を忘れずにクリックしてください。

6.ポータルを終了する前に、[Access Connection Information] のメイン ダッシュボードで、listen アクセスの接続文字列を記録しておきます。

7.次に、Android アプリケーションを通知ハブに接続します。これを行うには、MainActivity クラスで次のプライベート メンバーを追加します (送信者 ID を、上の手順で取得したものに置き換えます)。

8.その後、OnCreate メソッドと MainActivity.java ファイルを資格情報で更新して、プッシュ通知を表示するレシーバーを起動します。詳細については、こちら (英語)を参照してください。

まとめ

モバイル サービス機能を利用したアプリケーション作成の際に、カスタム API やローカル Git によるソース管理を活用できるようになりました。さらに、Windows Azure で作成したあらゆるアプリケーションに対して、通知ハブを使用して Android デバイスにプッシュ通知をブロードキャストできる機能を搭載することが可能です。

モバイル サービスと通知ハブの詳細については、Mobile デベロッパー センター (英語)MSDNをそれぞれ参照してください。今回のリリースの詳細については、Scott Guthrie のブログ記事 (英語) (翻訳: SATO NAOKI ブログ Windows Azure: モバイル バックエンド開発に対する大幅なアップデートを参照ください) を参照してください。

今後期待する機能や取り上げてほしいトピックなどがあれば、@MLunes90までぜひご連絡ください。皆様のご意見を心よりお待ちしております。

Miranda

クロスポスト: Windows Azure インフラストラクチャ サービスで Microsoft Dynamics NAV と Microsoft Dynamics GP ���利用可能に

$
0
0

このポストは、6 月 18 日に投稿された Cross-Post: Microsoft Dynamics NAV and Microsoft Dynamics GP on Windows Azure Infrastructure Services!の翻訳です。

仮想マシンと仮想ネットワークから成る Windows Azure インフラストラクチャ サービスは、ビジネス ニーズの変化に合わせて自由に拡張できるオンデマンド インフラストラクチャを提供します。仮想マシンで新しいアプリケーションを作成するか、既存のアプリケーションを実行するかにかかわらず、分単位かつ最低使用要件のない課金体系により、お客様は最も経済的な形でクラウド サービスをご利用になれます。Dynamics は、クラウドの拡張性と経済性によって大きな恩恵を受ける既存のワークロードの好例です。先日、Microsoft Dynamics チームは、Dynamics GP 2013 および Dynamics NAV 2013 の新しい利用方法を発表しました。Dynamics パートナー エコシステムを通じて販売、サービス提供される Dynamics GP 2013 および Dynamics NAV 2013 を、Windows Azure インフラストラクチャ サービスでホストすることが可能になります。

詳しくは Dynamics チームのブログ (英語)を参照してください。先行導入企業とそのパートナーの事例が紹介されています。

クロスポスト: エンタープライズ クラウドにおけるパートナーについて

$
0
0

このポストは、6 月 25 日に投稿された Cross-Post: Partners in the enterprise cloudの翻訳です。

編集メモ: この投稿は、Microsoft's Server & Tools Business プレジデント Satya Nadella の投稿記事となります。

Microsoft と Oracle は、長年において、競合、パートナー、業界のリーダーとして 20 年間以上もの間、エンタープライズのお客様と協力してきました。多くのお客様は、ミッション クリティカルな Oracle ソフトウェアを実行するために Microsoft のインフラストラクチャに依存しており、この関係は10年以上に経過しています。本日、Microsoft と Oracle との間の新しい戦略パートナーシップを介して、プライベートクラウドとパブリッククラウドを支援できるよう、私たちの活動をともに拡大していきます。このパートナーシップは、柔軟性や選択を提供することでお客様のクラウド コンピューティング採用を促進し、これらのワークロードが求める第一級のサポートを維持します。

この新しく発表されたパートナーシップの詳細については、The Official Microsoft Blog (翻訳 SATO NAOKI ブログ MicrosoftとOracleが、エンタープライズ パートナーシップを発表を参照ください) をお読みください。

Satya

Windows Azure モバイル サービスおよび Windows Azure Web サイトの正式リリースと、既存サービスに対する技術革新の継続についてのお知らせ

$
0
0

Windows Azure モバイル サービスおよびWindows Azure Web サイトの正式リリースと、既存サービスに対する技術革新の継続についてのお知らせ

このポストは、6 月 28 日に投稿された Announcing the General Availability of Windows Azure Mobile Services, Web Sites and continued Service innovation の翻訳です。

マイクロソフトでは、開発者の皆様が最高のクラウド アプリケーションを構築するための基盤となるプラットフォームを提供できるよう、日々尽力しています。これにより、世界中のお客様が優れたクラウド アプリケーションをすばやく手に入れられるようになります。マイクロソフトでは、さまざまなモバイルデバイスからアクセス可能な完全 Web ベースのアプリケーションのことを「モダン アプリケーション」と呼んでいます。最近では、それに該当するタイプの新しいアプリケーションが続々と登場しています。そしてこの度、Windows Azure モバイル サービスと Windows Azure Web サイトの正式リリース (GA: General Availability) が発表されました。これにより、モダン アプリケーションの迅速な提供という目標が、より現実的なものとなりました。

Windows Azure モバイルサービス

Windows Azure モバイル サービスは、さまざまなデバイスのモバイル バックエンドを簡単かつ迅速に作成することを目的としたもので、ユーザー認証、プッシュ通知、サーバー側データおよびビジネス ロジックを簡略化し、モバイル アプリケーションの市場投入までの期間を短縮することができます。このサービスでは、Windows ストア、Windows Phone、Android、iOS、HTML5 のそれぞれに向けたネイティブ SDK および REST API を提供しています。

今回の正式リリース版では、無料、スタンダード、プレミアムの 3 つのプランを提供します。スタンダードとプレミアムは API 呼び出し数に応じた従量課金制のプランで、月間稼働率 99.9% の標準的な SLA の保証が適用されます。新しい料金プランの詳細については、こちらのページをご確認ください。2013 年 8 月 1 日までの期間中、Windows Azure モバイル サービスの全プランを無料でご利用いただけます。お客様のアプリケーションに合わせて、適切なプランをお選びください。この期間は、SQLデータベースおよびストレージの料金については別払いとなります。

さらに、Visual Studio 2013 プレビューでは Windows Azure モバイル サービスに最高クラスのサポートが実現されます。Windows 8.1 と接続するアプリの構築が従来よりも簡単になるほか、お客様がサービスとクライアントの間で Gzip 圧縮を実行できるようになります。

Yatterbox (英語)、Sly Fox (英語)、Verdens Gang (英語)、Redbit (英語)、TalkTalk Business (英語) などの企業においては、既にコンテンツ配信用のアプリを構築し、さまざまなデバイスに最新情報を提供しています。

開発者の皆様は、Windows Azure モバイル サービスと、New Relic、SendGrid、Twilio、Xamarin などのお好みのサードパーティ製サービスとを組み合わせて使用することが可能です。

Windows Azure Web サイト

Windows Azure Web サイトでは、ビジネス レベルの Web アプリケーションの構築、スケーリング、管理をすばやく実行できます。オープンで柔軟性が高く、ASP.NET、PHP、Node.JS、Python などの複数の言語やフレームワーク、WordPress、Drupal などの複数のオープンソース アプリケーション、さらに複数のデータベースをサポートしています。ASP.NET を使用している場合、Web サイトの新規作成や既存の Web サイトの Windows Azure への移行を、Visual Studio の内部で実行できます。

今回の正式リリース版 (GA) では、スタンダード (旧称「Reserved」) と無料の 2 種類のプランが発表されました。スタンダード プランでは、SLA で月間稼働率 99.9% が保証されます。また、2013 年 8 月 1 日までの期間中に限り、スタンダード プランに対して 33% のプレビュー版割引が適用されます。Web サイトを共有プランで実行している場合は引き続きプレビュー版となりますので、変更はありません。料金変更に関する詳細については、料金早見表のページでご確認ください。

Windows Azure Web サイトのスタンダード プランのサービスの変更点は、次のとおりです。

  • SSL のサポート: SNI または IP ベースの SSL がサポートされます。 
  • 個別での Web サイトスケーリング: 各 Web サイトを個別でスケール アップ (スケール ダウン) できます。
  • デバッグ用メモリダンプ: REST API を使用してメモリ ダンプにアクセスし、サイトのデバッグや診断に活用できます。
  • 64 ビット処理のサポート: 64 ビット Web サイトを実行できるため、大容量メモリの活用や高速な演算処理が可能です。

既存サービスに対する技術革新の継続

自動スケーリング、警告の通知、監視の各機能をプレビュー版で提供

アプリケーションの正常性をより詳しく把握するためのさまざまな機能が、Windows Azure に新たに追加されました。これらの機能はプレビュー版として提供され、アプリケーションの正常性と可用性の監視、サービスの可用性に関する変更通知の受信、アクションに基づくイベントの実行、要求に応じたスケーリングの自動実行が可能です。

可用性、監視、自動スケーリング、警告の通知は、Windows Azure Web サイト、クラウド サービス、仮想マシンのプレビュー機能 (英語)として利用できます。警告の通知と監視は、WindowsAzure モバイル サービスのプレビュー機能として利用可能です。プレビュー期間中、これらの機能は無料で提供されます。 

Windows Azure 仮想マシンの新しいイメージを提供

SQL Server 2014 および Windows Server 2012 R2 プレビューのイメージが、仮想マシンのイメージ ギャラリーからご利用いただけるようになりました。マイクロソフトのクラウド OS の展望の中核として、WindowsServer 2012 R2 では、ストレージ、ネットワーク、アクセス保護、情報保護の面で数多くの新機能が提供されるほか、さまざまな機能強化が施されています。WindowsServer 2012 R2 および SQL Server 2014 は、事前構築済みのイメージをイメージ ギャラリーからプロビジョニングするだけで、簡単に利用を開始できます。現在のプレビュー期間中、これらのイメージには 33% の割引が適用されます。料金は、分単位の従量課金制となっています。

Windows Azure Active Directory の最新情報

Build カンファレンスの基調講演 (英語) において、Scott Guthrie が Windows Azure Active Directory の今後の機能強化について一足先にご紹介しました。マイクロソフトでは現在、Box などのサードパーティと協力して、ユーザーのシングル サインオン (SSO) に Windows Azure Active Directory を活用する手法の開発を進めています。高レベルのセキュリティが必要とされる場合には、Active Authenticationを利用して多要素認証を実現できます。SSO に関してWindows Azure Active Directory との統合を検討中の ISV のお客様は、簡単なアンケート (英語) にお答えいただき、マイクロソフトまでご連絡ください。

MSDN サブスクライバのWindows Azure利用がクレジットカードが不要に

Windows Azure は、オンプレミスでは得ることが難しい演算能力を提供する、開発やテストに適した重要なプラットフォームです。先日の TechEd 2013では、課金単位、料金の値下げ、Windows Server での MSDN ソフトウェア使用の無料化という Windows Azure MSDN の新たな特典を発表しました。現在では、MSDN のほとんどのお客様がクレジット カード番号を入力することなく Windows Azure の特典を企業のアカウントで有効化できるようになっており、これらの特典を簡単にご利用いただくことができます。

今回の発表は、マイクロソフトのプラットフォームとインフラストラクチャ サービスへの技術革新を継続することによって、「モダン アプリケーション」の構築に携わる開発者への取り組みを強化するというものです。今後も、魅力的な新機能や強化機能に関する発表を随時行っていく予定です。ユーザーの皆様もまた、モバイル アプリ (英語) や Web アプリのデベロッパー センターや、Build カンファレンスのセッションのライブ ストリーミング (英語)をご覧いただくなどして、マイクロソフトの取り組みにご協力いただければ幸いです。また、WindowsAzure のフォーラム (英語) や Stack Overflow (英語) へのご質問の投稿もお待ちしています。

Steven Martin(Windows Azure ゼネラル マネージャー)

 

 

優れたクラウド アプリケーションの構成要素

$
0
0

このポストは、6 月 21 日に投稿された Building Blocks of Great Cloud Applicationsの翻訳です。

編集メモ: 今回は、Windows Azure 顧客アドバイス チームの主任プログラム マネージャーを務める Michael Thomassy の投稿をご紹介します。

Azure 顧客アドバイス チームは、先日「優れたクラウド アプリケーションの設計」という記事を公開した後、MSDN コード ギャラリーに投稿された「Windows Azure でのクラウド サービスの基礎」(英語)コード プロジェクトのコンポーネントについて、さらに詳細な情報と技術的な説明を追加しようと検討してきました。その一環として、これらの基本構成要素 (コンポーネント) の使用方法を説明するブログや技術記事のシリーズを開始することになりました。クラウド サービスの各基本コンポーネントに関する詳細な技術情報を記載したブログを、今後数か月にわたって公開していく予定です。

私たちはマイクロソフト内外の Windows Azure ユーザーの皆様との間で、「Windows Azure のサービスには何が必要であるか」ということについて、幾度となく議論してきました。その中で、クラウド サービスの実装に関する簡単な質問に答えても、それがすぐに複雑な質問となって返ってくるという経験もしました。たとえば、ただシャーディング コードを提供すればよかったのではなく、データ アクセス層が必要だった、というようなことです。さらに、データ アクセス層の回復性には再試行ロジックの開発が必要であることや、スケーラブルな環境でエラー ログを記録するためには正確なガイダンスを提供することが必要でした。また、OPS ストレージを構築するほかにも、レポートをクエリしたり、警告を生成することもできました。議論の進捗はコンポーネントごとに確認できますが、各コンポーネントはそれぞれの上に構築されており相互に依存しています。こうした議論や実装の結果、多数の基本コンポーネントと稼働中のクラウド アプリケーションとをつなぐ「Windows Azure でのクラウド サービスの基礎」(英語)というコード プロジェクトが生まれました。

このコード プロジェクトは、マイクロソフトの最大規模のお客様が、Windows Azure のデータベースを基盤とした複雑なサービスを確実にご利用いただけるようにするために、顧客アドバイス チームが進めてきたものです。Windows Azure ユーザーの皆様が抱える各種の問題を解決するために、実際の Windows Azure のお客様の協力の下で行いました。多くの場合、このような問題を解決するには、基本サンプルによるベスト プラクティスではなく、弾力的なスケーリング、分散可能なワークロード、可用性、業務継続性、広範に分散した大規模なユーザー、大容量、低遅延といった、大規模クラウド サービスに求められるさまざまな要件を組み合わせた場合のベスト プラクティスが必要になります。下の図は、「クラウドサービスでの基礎」コード プロジェクトのアーキテクチャを示したものです。

今回連載する技術記事でご紹介するコード プロジェクトのコンポーネントは、次のとおりです。

  1. テレメトリ – データ パイプラインに実装されたスケーラブルな環境の非同期メカニズムを通じて、アプリケーション サービスのインストルメンテーションおよびログ記録を実行する基本的な方法。サービスをトラブルシューティングしたり、健全性を判断するうえでは、テレメトリ データを効率よく活用することが欠かせません。このコード プロジェクトでは、バックグラウンドの Worker ロールを使用するスケジューラを実装し、アプリケーション、パフォーマンス カウンター、IIS のログ、イベント ログ、およびシャーディングされた SQL データベースの DMV から定期的にテレメトリ データを収集します。これらのデータは、Windows Azure SQL データベース内のカスタマイズ済み OPS ストレージに書き込まれます。スケジューラが収集したデータは、SQL レポートでホストされるレポートで確認できます。
  2. データ アクセス層 – Windows Azure SQL データベース内に存在する複数のデータベースに、高い信頼性と効率性を確保しながらアクセスするレイヤー。このコード プロジェクトには単一データベースと、シャーディングされたソリューションの両方のデータ アクセス ラッパーが存在し、シャードをまたぐ並列展開クエリなどの手法を実行できます。
  3. キャッシュ – Azure キャッシュを使用すると、データ アクセス層と組み合わせた場合に、専用キャッシュでより効率よくユーザー データを保存したり取得したりすることができます。
  4. 構成 – 構成ファイルは、構成パラメーターが web.config 形式かサービスの config 形式かにかかわらず、アプリケーションをシームレスに管理するために欠かせない重要な役割を担っています。構成は、アプリケーションに対して透過的である必要があります。
  5. アプリケーション要求ルーティング処理 – Cookie に基づいてユーザーを複数のホステッド サービスにルーティング/アフィニティ化する機能、およびシャーディングされたデータベースによってアプリケーション サービス レベルでスケールアウトを実施するために IIS の ARR (アプリケーション要求ルーティング処理) 技術を活用するシャーディングされたデータベースの実装。
  6. 展開 – PowerShell の Windows Azure コマンドレットを使用して、カスタマイズ済みの構成を複数のホステッド サービスやさまざまな数のインスタンスに展開し、多数のシャードを構成する方法。

技術的なブログや詳細情報については、TechNet Wiki (英語)に公開していく予定です。皆様のご意見およびご参加をお待ちしております。

Windows Azure Connect のサービス終了のご案内

$
0
0

このポストは、7 月 9 日に Windows Azure Connect Team Blog によって投稿された Windows Azure Connect Has Been Retiredの翻訳です。

今夏、Windows Azure Connect 機能が、古い Azure 管理ポータルから削除されます。削除後、Windows Azure Connect はご利用いただけなくなるので、Windows Azure 仮想ネットワークに切り替えるようにしてください。仮想ネットワークは新しい Windows Azure 管理ポータルからご利用いただけます。Windows Azure Connect から Windows Azure 仮想ネットワークへの移行方法の概要に関してのドキュメント(Migrating Cloud Services from Windows Azure Connect to Windows Azure Virtual Network , 英語)をご参照ください


Windows Azure Connect CTP をご利用いただき、ありがとうございました。

Windows Azure Connect Team

 

 

Windows Azure Web サイトのスケール アップとスケール アウト

$
0
0

このポストは、7 月 11 日に Scaling Up and Scaling Out in Windows Azure Web Sitesの翻訳です。

編集メモ: 今回は、Windows Azure Web サイト チームでプログラム マネージャーを務める Byron Tardif の投稿をご紹介します。

新規 Web プロジェクト、あるいは一般の Web サイトやアプリケーションの開発に着手する際、最初は小規模なものから始め、徐々に拡大していくということが多いのではないでしょうか。また、概念実証の初期段階でも、新しい Web ファームにリソースを費やそうとは考えないはずです。しかし、いざ本格的な運用が決定すれば、個人用のサーバーで大規模なマーケティング キャンペーンを実施しようとは思わないのではないでしょうか。その点、クラウド上の Windows Azure Web サイトには、開発と展開の両方が可能というメリットがあります。

この記事では、限られた予算と期間の中で、開発、テスト、運用のすべてを行う方法をご紹介します。

Windows Azure Web サイトの標準、無料、共有の各モードについて

Web サイトを展開するうえで最も重要な考慮事項は、サイトに適切な価格帯を選ぶことです。開発とテストのサイクルを完了したサイトは、企業の広告 Web サイトや、重要な新規デジタル マーケティング キャンペーン、基幹業務アプリケーションとして使用されます。このため、予算を考慮しつつ、ビジネス ニーズに合わせてサイトの可用性や応答性を確保しなければなりません。

価格帯を選定する際には、さまざまな要素を考慮する必要があります。その例としては、下記のようなものが挙げられます。

  • ホスティングを予定しているサイトの数。たとえば、デジタル マーケティング キャンペーンの場合には、使用中の各ソーシャル メディア サービスのページ、および各ターゲット セグメント向けのランディング ページがそれぞれ必要となります。
  • サイトの理想的なアクセス数やトラフィック レベルの変更時期。基幹業務アプリケーションを使用する従業員数、Twitter のフォロワー数、キャンペーン サイトに対する Facebook の「いいね!」の数を基に予想します。季節的な要因、およびソーシャル メディアでのアクティビティや広告などの需要創出活動によって、トラフィックが変化する可能性もあります。
  • 消費されるリソース (CPU、メモリ、帯域幅)。

Windows Azure Web サイトで得られる大きなメリットの 1 つは、Web アプリケーションや Web サイトの運用を開始するときに、上記のことを考慮する必要がないことです。管理ポータルからスケール オプションを使用すると、業務目標やユーザーのニーズに合わせて、運用を停止することなくサイトのスケールを変更できます。

Windows Azure Web サイトのサイトモード

Windows Azure Web サイト (WAWS) には、標準、無料、共有の 3 つのモードがあります。

標準、共有、無料の各モードで提供されるクォータでは、サイトで使用可能なリソース数やスケール機能が異なります。下の表は、それぞれのクォータの違いをまとめたものです。

 

標準 (旧称「占有」)

共有

無料

サイト数

サブ地域ごとに最大 500 サイト

最大 100 サイト

サブ地域ごとに最大 10 サイト

スケール アウト

最大 10 インスタンス

最大 6 インスタンス

使用不可

スケール アップ

S サイズの仮想マシン (CPU 1.6 GHz、RAM 1.75 GB)

M サイズの仮想マシン (CPU 1.6 GHz x 2、RAM 3.5 GB)

L サイズの仮想マシン (CPU 1.6 GHz x 4、RAM 7 GB)

使用不可

共有ホスティング環境

使用不可

共有ホスティング環境

ストレージ容量

10 GB (サブ地域ごとの全サイトで共有)

1 GB (サブ地域ごとの全サイトで共有)

1 GB (サブ地域ごとの全サイトで共有)

CPU

選択されたスケール アップ オプションに準じて全リソースの使用が可能

4 時間/日

運用時間: サイトごとに 5 分あたり 2.5 分

1 時間/日

運用時間: サイトごとに 5 分あたり 2.5 分

サブ地域ごとの全サイトで共有

メモリ

選択されたスケール アップ オプションに準じて全リソースの使用が可能

サイトごとに 512 MB

1 回あたりの運用時間は 1 時間

1 つのサブ地域あたりの全サイトで 1 GB

1 回あたりの運用時間は 1 時間

帯域幅

受信: 無制限

送信: Azure の帯域幅料金 (5GB/月以上の場合)

受信: 無制限

送信: Azure の帯域幅料金 (5GB/月以上の場合)

受信: 無制限

送信: 165 MB/日 (5GB/月)

SLA

月間 99.9%

プレビューとしてサービス提供

なし

標準モードとサービスレベルアグリーメント (SLA)

標準モードは、他の Windows Azure Web サイトのモードと異なり、専用インスタンス上で実行されます。また、CPU 使用も無制限で、ストレージ容量は 3 つのモードの中では最大です。詳細については、クォータの違いをまとめた上記の表をご覧ください。

標準モードでは下記のような重要な機能が使用できます。

  • 無制限のデータ送信帯域幅 – 5 GB までは無料で送信できます。超過分は従量課金でご使用いただけます。
  • DNS 名のカスタマイズ – DNS のカスタマイズは、無料モードでは使用できません。標準モードでは CNAME および A レコードが使用できます。

標準モードでは、1 インスタンスのみのサイトに対しても、SLA (サービス レベル アグリーメント)により月間 99.9% という企業レベルの可用性が保証されます。Windows Azure Web サイトでは、運用を停止せずにプロビジョニングする機能を含む設計上の理由により、1 インスタンスのみのサイトでもこの SLA を保証しています。プロビジョニングはバックグラウンドで実行され、サイトを変更する必要はありません。また、サイトへアクセスしたユーザーに対して透過的に実行されます。これにより、スケーリングにおける可用性の問題を回避しています。

共有モードと無料モード

共有モードと無料モードでは、標準モードで利用できるようなスケーリングの柔軟性はなく、一部に重要な制限があります。

無料モードは、他の無料モードや共有モードのサイトと同じコンピューティング リソースで実行されます。また、一定のクォータ期間のサイト (およびサブスクリプション内の他の無料サイト) の CPU 使用時間が制限されています。使用時間が制限に達した場合、そのサイトおよびサブスクリプション内にある他の無料モードのサイトで、次のクォータ期間までコンテンツおよびデータのサービスが停止されます。また、無料モードではサイトがクライアントへサービスを提供する際のデータ量 (データ送信) の制限があります。

共有モードでは、その名のとおり共有のコンピューティング リソースが使用され、前述の表で示されているように、無料モードよりは高い値に設定されていますが、CPU の使用は制限されています。共有モードのデータ送信制限は 5 GB で、超過分は従量課金制での利用になります。

上記の制限により無料モードや共有モードが運用環境に最適な選択ではない可能性がありますが、どちらも使い方によっては有用です。無料モードは、Windows Azure Web サイトの試用や学習などの限定的なケースに有効で、発行の構成方法、Visual Studio への接続、TFS や Git のような展開ツールを使用した展開などの習得に適しています。共有モードでは、無料モードよりも一部の機能が優れているので、負荷の制限や管理が適用される中でのサイトの展開やテストがしやすくなっています。運用環境でより厳しい条件が求められる場合は、さらに上位の機能や可用性を提供する標準モードをご利用ください。

スケーリング操作、お客様のコード、ユーザーのセッションとエクスペリエンス

サイトのスケール アップやスケール アウトを実行するとユーザー エクスペリエンスが改善されますが、それ以外に既存のユーザー セッションがスケーリング操作によって影響を受けることはありません。 

また、各操作は通常は数秒ほどの短時間で実行されます。この際、サイトのコード変更や再展開などは不要です。

次に、「スケール アップ」と「スケール アウト」の意味についてご説明します。

Windows Azure Web サイトにおけるダイナミックなスケーリング

Windows Azure Web サイトでは、管理ポータルから Web サイトのスケーリングを実行する方法が複数あります。サイト管理に Microsoft Visual Studio 2012 を使用している場合にもこの操作は実行できます。詳細については、マイクロソフト サービスのドキュメントをご覧ください。

スケール アップ

クラウド環境の Azure Web サイトでスケール アップ操作を実行することは、クラウド環境ではない Web サイトをより大規模な物理サーバーに移動するのと同じことです。したがってスケール アップ操作は、サイトがクォータ制限に達し、既存のモードやオプションが不適切になりつつある場合に有効です。さらに、ほぼすべてのサイトで、スケール アップの際に複数のインスタンス間でデータの一貫性が維持されます。

以下に Windows Azure Web サイトでのスケール アップ操作の例を 2 つご紹介します。

  • サイトのモード変更: 標準モードを選択した場合、Web サイトの運用に CPU 使用のクォータは適用されません。また、データ送信については、月 5 GB までは無料で利用できますが、それを超過すると料金が発生します。それ以外に制限はありません。
  • 標準モードのインスタンスサイズの決定: Windows Azure Web サイトの標準モードでは、インスタンスのサイズを S、M、L から選択できます。これは、CPU コア数が多くメモリ容量が大きい、より大規模な物理サーバーへの移行に相当するスケール アップ操作です。
    • S サイズ:コア数 1、メモリ容量 1.75 GB
    • M サイズ: コア数 2、メモリ容量 3.5 GB
    • L サイズ: コア数 4、メモリ容量 7 GB

スケールアウト

スケール アウト操作は、Web サイトのコピーを複数個作成し、ロード バランサーを導入して負荷を分散させるのと同じことです。Windows Azure Web サイトで Web サイトのスケール アウトを実施する際に、ロード バランサーの構成を個別に行う必要はありません。これは、既にプラットフォームに組み込まれています。

Windows Azure Web サイトで Web サイトをスケール アウトする場合、[INSTANCE COUNT] スライダーを使用してインスタンス数を変更します。共有モードでは 1 ~ 6、予約モードでは 1 ~ 10 に設定できます。これにより、実行中の Web サイトのコピーが複数個作成され、受信要求に応じて、全インスタンスに負荷分散の構成を適用します。

スケール アウト操作を活用するには、サイトがマルチインスタンス対応である必要があります。マルチインスタンス対応のサイトの構築方法の詳細については、この記事では説明しませんが、以下のページをはじめとする、.NET 言語に関する MSDN の記事を参考にしてください。http://msdn.microsoft.com/ja-jp/library/3e8s7xdd.aspx (機械翻訳)

Web サイトに対して、スケール アップとスケール アウトを組み合わせて、ハイブリッドなスケーリングを行うこともできます。マルチインスタンスのサイトでの競合は、このシナリオの場合でも同様に適用されます。

Windows Azure PowerShell を使用した自動および手動でのスケーリング

ここまで、Windows Azure Web サイトでのスケール アップとスケール アウトの概念について、管理ポータルから手動で実行する場合を想定して説明してきましたが、Visual Studio でも同様に手動で設定できます。

今回、Windows Azure Web サイトに自動スケーリング機能が追加され、スケール アップおよびスケール アウトの設定を、Web サイトのニーズに応じて自動的に変更できるようになりました。

さらに、サイトやサブスクリプションのさまざまな管理機能と同様に、Windows Azure PowerShell で一部のスケーリング操作を実行することができます。  

まとめ

Windows Azure Web サイトを使用すると、低コストまたは ”無償” で Web サイトや Web アプリケーションの開発、展開、テストを実施できます。また、そのサイトをより運用環境に近い構成へシームレスにスケーリングし、その後も経済的な方法でスケーリングを実施することが可能です。

この記事では Web サイトのスケール アップとスケール アウトを中心に説明しましたが、サイトは、データベース、データ フィード、ストレージ、サード パーティの Web API など、他のコンポーネントを使用する複雑なアプリケーションの一部に過ぎない場合があるので、注意が必要です。コンポーネントにはそれぞれスケール機能が備えられており、スケーリング操作を評価する際に考慮に入れる必要があります。

Web サイトのスケーリングは、当然コストにも影響します。Azure の料金計算ツールを使用すると、見積もりや一定のスケーリング操作による予算への影響を簡単に計算できます。ぜひご利用ください。


Windows Azure Marketplace が新たに 50 か国で利用可能に / Bing Optical Character Recognition サービスを含む注目の新コンテンツのご紹介

$
0
0

このポストは、7 月 11 日に Windows Azure Marketplace DataMarket Blog に投稿された Windows Azure Marketplace is available in 50 additional countries and features new exciting content including our own Bing Optical Character Recognition serviceの翻訳です。

Windows Azure Marketplace のユーザーの皆様に嬉しいお知らせです。

Windows Azure Marketplace の対象地域として、新たに 50 か国が加わりました! これで Marketplace のサービスをご利用いただける国や地域が、合わせて 88 か国となります。また、Marketplace にもいくつか新しいコンテンツが登場しました。先日の //build カンファレンスで発表したマイクロソフトの Optical Character Recognition (OCR) サービス、D&B 社の新しいデータ サービス、フランス郵政公社 (La Poste) が直接提供する郵便局の所在地データ、MapMechanics 社が提供する英国の位置情報サービスなど、魅力的なコンテンツが加わりました。

1) Marketplace 経由でアプリケーションやデータ サービスの購入および利用が可能になった国や地域は以下のとおりです。

アルジェリア、アルゼンチン、バーレーン、ベラルーシ、ブルガリア、クロアチア、キプロス、ドミニカ共和国、エクアドル、エジプト、エルサルバドル、エストニア、グアテマラ、アイスランド、インド、インドネシア、ヨルダン、カザフスタン、ケニア、クウェート、ラトビア、リヒテンシュタイン、リトアニア、マケドニア、マルタ、モンテネグロ、モロッコ、ナイジェリア、オマーン、パキスタン、パナマ、パラグアイ、フィリピン、プエルトリコ、カタール、ロシア、サウジアラビア、セルビア、スロバキア、スロベニア、南アフリカ、スリランカ、台湾、タイ、チュニジア、トルコ、ウクライナ、アラブ首長国連邦、ウルグアイ、ベネズエラ

お客様が既に別の国の Windows Azure Marketplace に登録している場合

お客様のアカウントは、次のような簡単な手順で、お住まいの国の Marketplace に移行することができます。

  • https://datamarket.azure.com/accountにアクセスします。
  • アカウント上の既存のアプリケーションやデータ サブスクリプションをすべて削除します。
  • [Account Information] ページの [Edit] をクリックします。
  • お客様の Microsoft アカウントに関連付ける国または地域を選択します。
  • [Save] をクリックします。
  • お気に入りのアプリケーションやデータをサブスクライブし直します。お住まいの地域の通貨で設定された価格および課金サービスなども新たにご利用いただけます。

2) Bing OCR (Optical Character Recognition) Control が、Windows Azure Marketplace に登場しました。これにより、マイクロソフトのクラウドベースの���字認識機能を Windows 8 や Windows 8.1 のアプリケーションと統合して活用することができます。Bing OCR Control の概要についてはこちらを、技術情報についてはこちら (英語)をご覧ください。

3) 格式あるフランス郵政公社 La Posteからデータセットが提供されました。詳細についてはこちらを参照してください。

以下は、サービス エクスプローラーで表示した La Poste のデータセットのスナップショットです。

4) D&B (Dun & Bradstreet) から、新たに 6 つの API が Windows Azure Marketplace に追加されました。D&B 社は、商業データやビジネス インサイトを提供しているリーダー企業です。D&B 社から新たに提供されたデータセットは以下のとおりです。

データの検証:

データの充実:

データの検出:

  • D&B Business Insight (別名 Company prospect builder) – アクセス方法は上と同じです。

Windows Azure Marketplace から利用可能なデータ サービスの一覧を参照するにはこちらを、購入可能なアプリケーションの一覧を参照するにはこちらをクリックしてください。

 

どうぞよろしくお願いいたします。

Windows Azure Marketplace チーム

クラウドとモバイルの共通点とは?

$
0
0

このポストは、7 月 16 日に投稿された What do cloud and mobile have in common?の翻訳です。

編集メモ: 今回は、MS Open Tech チームのシニア テクニカル エバンジェリストを務める Olivier Bloch の投稿をご紹介します。

クラウドとモバイルはどちらも 2013 年に注目を浴び、非常に多用されている言葉ですが、この 2 つにはさらに Microsoft Open Technologies, Inc. (MS Open Tech) という共通点があります。MS Open Tech はマイクロソフトの完全な子会社で、オープン ソース テクノロジと Windows Azure などのマイクロソフトのテクノロジを仲介する役割を担っています。ここ数か月間、MS Open Tech は Windows Azure モバイル サービスと組み、オープン ソース テクノロジを活用して、モバイル アプリや Web アプリの新しいクラウドベース エクスペリエンスをさまざまなタイプのデバイスへ配信できるようにしようと取り組みを続けています。

MS Open Tech は 3 月 (英語) に、Windows ストア、Windows Phone、iOS、HTML5 のアプリケーションをサポートする Windows Azure モバイル サービス向けの Android SDK を構築しました。この SDK により、Android 開発者は、ストレージ認証および通知に使用するクラウドベースの高度なサービスにアクセスできるようになりました。また、MS Open Tech は、Windows Azure 通知ハブ向け Android SDK のアップデートにも貢献 (英語) しました。これにより、Windows Azure でホストされているバックエンドのほとんどから、さまざまなプラットフォームが搭載されている膨大な数のデバイスに、プッシュ通知をブロードキャストできるようになりました。

さらに、MS Open Tech は先日 Windows Azure モバイル データ サービス向け Backbone アダプター (英語) を作成しました。これにより、使い慣れたお好みの Backbone API を使用して、お客様のデータとクラウドの間でシームレスに同期できます。この更新以降、一般的な JavaScript フレームワークである Backbone.JS で Web アプリを構築している開発者は、テーブルの名前と場所を示す値をいくつか追加するだけで、クラウドを活用したまったく新しいエクスペリエンスをユーザーに提供できるようになりました。

マイクロソフトはこのプロジェクトへの取り組みを継続し、近いうちにさらに魅力的な更新をお客様にお届けしたいと考えています。Windows Azure をサポートするオープン ソース テクノロジについてご要望がありましたら、MS Open Techまでメール (英語) をお送りいただくか、コメントをお寄せください。

Olivier

.NET および Windows Phone 8 向けストレージ クライアント ライブラリ 2.1 RC の概要

$
0
0

このポストは、7 月 12 日に投稿された Windows Azure Storage Team Blog の Introducing Storage Client Library 2.1 RC for .NET and Windows Phone 8の翻訳です。

マイクロソフトは、.NET および Windows Phone 8 向けストレージ クライアント ライブラリのリリース候補版 (RC) 2.1 の一般公開を発表しました。このブログ記事では、今回のリリース 2.1 でサポートされた拡張機能の詳細をご説明します。

RC 版を公開した経緯

マイクロソフトでは、ストレージ クライアントのリリース間隔を短縮し、クライアントのフィードバックに対してより迅速に対応できるように、多大な労力を注いでいます。この取り組みの一環として、次期リリースの RC 版を皆様に提供してフィードバックをお寄せいただき、「公式」リリースの改善に役立てたいと考えています。このリリース候補版は、皆様からフィードバックをいただくことを目的として公開いたします。ぜひご意見をお寄せください。

新機能

このリリースには多数の新機能が盛り込まれています。これからご紹介する新機能の多くは、クライアントのフィードバックを直接採用したものです。皆様からのご意見はこのような形で活用させていただいておりますので、今後ともぜひお気軽にお寄せください。

非同期タスク メソッド

特定の操作を目的としたタスクを返す非同期メソッドが、各パブリック API について新たに公開されました。さらに、これらのメソッドでは、CancellationTokenが適用されるオーバーロードを使用して、プリエンプティブに取り消しを実行することができます。.NET 4.5 で実行している場合、または Async Targeting Pack for .NET 4.0 (英語) を使用している場合は、ストレージに関連するアプリケーションを作成する際に、Async または Await を使用したパターンを簡単に利用できます。

テーブルの IQueryable

リリース 2.1 では、デスクトップおよびモバイル デバイス向けのテーブル サービス レイヤーで、新たに IQueryableがサポートされます。これにより、WCF Data Services と同様に、LINQ 経由でクエリの構築および実行が可能になります。ただし、これは Windows Azure テーブル、および NoSQL の概念に向けて特別に最適化されたものです。次のスニペットは、新しく実装された IQueryableを使用したクエリの構築例です。

var query = from ent in currentTable.CreateQuery<CustomerEntity>()

where ent.PartitionKey == “users” && ent.RowKey = “joe”

select ent;

IQueryable の実装により、継承が透過的に処理されます。また、RequestOptionsOperationContext、およびクライアント側の EntityResolversを式ツリーに直接追加できるようになります。これを使用する場合は、Microsoft.WindowsAzure.Storage.Table.Queryable 名前空間に using 文を追加した後、CloudTable.CreateQuery<T>()メソッドでクエリを構築します。さらに、これは既存のインフラストラクチャを利用しているため、IBufferManagerやコンパイル済みシリアライザーなどの最適化機能、およびログ記録が完全にサポートされています。

バッファーのプール

大規模なアプリケーションにおいて、バッファーのプールは、クライアントがさまざまな処理の実行に既存のバッファーを再利用するうえでとても重要な手法です。.NET などの管理環境下では、割り当て処理、およびその後に準長期的に保存されるバッファーのガベージ コレクションの際に消費されるサイクル数を、大幅に減少させることができます。

このような状況に対処するため、各サービス クライアントでは、IBufferManager型の BufferManagerプロパティを公開しています。このプロパティにより、クライアントは、割り当てられたバッファー プールを、任意の関連付けられたオブジェクトと共にサービス クライアントのインスタンスに対して使用できます。たとえば、CloudTableClient.GetTableReference()により作成されたすべての CloudTableオブジェクトは、関連付けられたサービス クライアントの BufferManager を使用します。IBufferManagerは、System.ServiceModel.dll の BufferManagerの後にパターン化されます。これにより、デスクトップ クライアントは、フレームワークにより提供された既存の実装を容易に使用できるようになります (WinRT または Windows Phone などの他のプラットフォーム上で実行されているクライアントでは、IBufferManagerインターフェイスに対してプールが実装されることがあります)。

マルチバッファー メモリ ストリーム

マイクロソフトは、パフォーマンス調査の実施中に、BCL で提供される MemoryStreamクラスで、パフォーマンスに関する問題を複数発見しました。これらは特に、非同期処理、可変長の場合の動作、1 バイト処理に関するものでした。これらの問題を解決するために、データ長が不明な場合でも一定のパフォーマンスを発揮する、新しいマルチバッファー メモリ ストリームを実装しました。このクラスでは、バッファーの割り当てが追加されたときに、クライアントから IBufferManagerの提供があった場合、これを利用してバッファー プールを使用します。その結果、任意のサービスにおいて、データのバッファリングを使用する任意の処理 (Blob ストリームやテーブル操作など) で CPU 負荷が減少し、共有メモリ プールが適切に使用されるようになります。

.NET MD5 が既定に

マイクロソフトがパフォーマンス テストを実施したところ、FISMA に準拠したネイティブな MD5 の実装は、.NET で構築された実装よりも多少のパフォーマンス低下が見られることが判明しました。このため、今回のリリースでは既定で .NET MD5 を使用するように設定されています。FISMA への準拠が必要な各クライアントでは、下記の方法で再有効化できます。

CloudStorageAccount.UseV1MD5 = false;

クライアントのトレース

リリース 2.1 では .NET トレース機能が実装されました。これにより、要求実行および REST 要求に関するログ情報を記録できるようになりました。ログが記録される情報の種類は、下の表でご確認ください。さらに、Windows Azure 診断ではトレース リスナーが使用できます。これは、クライアントのトレース メッセージをクラウドに保持する場合に、WADLogsTable にリダイレクトするものです。

.NET でのトレースを有効にする場合、トレース対象のストレージ クライアントを app.config に追加し、詳細を設定する必要があります。

<system.diagnostics>
  <sources>
    <source name="Microsoft.WindowsAzure.Storage">
      <listeners>
        <add name="myListener"/>
      </listeners>
    </source>
  </sources>
  <switches>
    <add name="Microsoft.WindowsAzure.Storage" value="Verbose" />
  </switches>

これで、ストレージ クライアントで生成されたすべてのトレース メッセージを、Verbose のレベルまでアプリケーションでログ記録するように設定されました。特定のクライアントまたは要求に対するログのみをクライアントで記録する場合は、OperationContext.DefaultLogLevelの設定を更新してアプリケーションの既定のログ レベルを変更した後、ログを記録する要求を OperationContext オブジェクトで追加します。

// Disbable Default Logging
OperationContext.DefaultLogLevel = LogLevel.Off;

// Configure a context to track my upload and set logging level to verbose
OperationContext myContext = new OperationContext() { LogLevel = LogLevel.Verbose };

blobRef.UploadFromStream(stream, myContext);

新しい Blob API

リリース 2.1 では、クライアントからのフィードバックを反映して、新たに Blob テキスト、ファイル、バイト配列の各 API が追加されました。さらに、新しい Blob ストリーム API では、Blob ストリームのオープン、フラッシュ、コミットを非同期で実行できるようになりました。

新しい範囲ベースのオーバーロード

リリース 2.1 では、Blob のアップロード API に新しいオーバーロードが追加されました。これを使用すると、クライアントは指定した範囲のバイト配列やストリームのみを Blob にアップロードできます。この機能により、ストレージ サービスにデータをアップロードする前に、クライアントがそのデータを事前にバッファーすることを回避できます。さらに、ストリームとバイト配列の両方に、新たにダウンロード範囲の API が追加されました。これにより、クライアント側でデータをバッファーしなくても、特定範囲のダウンロードをフォールト トレラントに実行できます。

IgnorePropertyAttribute

POCO オブジェクトを Windows Azure テーブルに保持するときに、特定のクライアントに依存するプロパティを省略する場合があります。今回のリリースで導入された IgnorePropertyAttributeを使用すると、エンティティのシリアル化および逆シリアル化の際にクライアントが特定のプロパティを無視するように、簡単に指定できます。次のスニペットは、IgnorePropertyAttributeを使用して、エンティティの FirstName プロパティを無視する方法を示しています。

public class Customer : TableEntity
{
   [IgnoreProperty]
   public string FirstName { get; set; }
}

コンパイル済みシリアライザー

POCO 型を取り扱っている場合、以前のリリースの SDK では、実行時のシリアル化および逆シリアル化に適用可能なすべてのプロパティを検出するときに、リフレクションを使用していました。この処理は繰り返し実行されるもので、コンピューティング料金を引き上げる原因となっていました。今回のリリース 2.1 ではコンパイル済みの式が新たにサポートされ、クライアントが実行時に特定の型に対して LINQ 式を動的に生成できるようになりました。これにより、クライアントはリフレクション処理を 1 回だけ行い、ラムダのコンパイルを実行時に行います。特定のエンティティ型に対するその後の読み書きは、すべてこれにより処理されます。パフォーマンスのマイクロベンチマークの結果、この手法では、リフレクション ベースの手法と比較して約 40 倍の計算速度が達成されました。

読み書き処理用にコンパイルされた式はすべて、TableEntityの静的な同時実行辞書に保持されます。この機能を無効にする場合は、TableEntity.DisableCompiledSerializers = true; と指定するだけです。

サードパーティのオブジェクトを簡単にシリアル化

フレームワーク オブジェクトやサードパーティのライブラリのオブジェクトなど、ソースを制御しないオブジェクトのシリアル化をクライアントで実行する場合があります。前のリリースのクライアントでは、シリアル化する型ごとに、独自のシリアル化ロジックを作成する必要がありました。今回のリリース 2.1 では、静的な TableEntity.[Read|Write]UserObjectメソッドを使用した CLR 型のシリアル化ロジックおよび逆シリアル化ロジックの基礎を公開しています。これにより、クライアントでの TableEntityから派生しない型のエンティティ オブジェクトの保持やリード バック、および ITableEntityインターフェイスの実装が簡単になりました。また、クライアントでエンティティの型を 2 つとも保持する必要がなく、また双方をマーシャリングする必要もないため、このパターンは DTO 型でサービスを公開する場合に特に便利です。

パフォーマンス向上へのさまざまな取り組み

現在特に力を入れているパフォーマンス向上への取り組みの一環として、Blob の並列アップロード、テーブル サービス レイヤー、Blob の書き込みストリームなど、各種 API でさまざまなパフォーマンス向上を実施しました。パフォーマンス向上に関する詳細な分析結果は、後日ブログでご紹介する予定です。

Windows Phone

Windows Phone クライアントのソース コードは、デスクトップ クライアントと同一のものを基礎としています。しかし、プラットフォームの制限により、重要な相違点が 2 つあります。1 つめは、Windows Phone のライブラリでは、アプリケーションの高速でスムーズな動作を確保するために、同期メソッドが公開されていないという点です。2 つめは、Windows Phone ライブラリでは、プラットフォームでの MD5 の実装が公開されていないため、MD5 をサポートしていないという点です。このため、MD5 を使用する場合は、アプリケーション レイヤーで MD5 の検証を実施する必要があります。現在、Windows Phone ライブラリでテストを実施中で、近日中に結果をお知らせできる予定です。ただし、これは Windows Phone 8 のみを対象としたもので、Windows Phone 7.x とは互換性がありませんのでご注意ください。

まとめ

マイクロソフトでは、このリリースのストレージ クライアント ライブラリの改善に向けて多大な労力を注いできました。皆様からのフィードバックをお待ちしておりますので、ぜひ下部のコメント欄、フォーラム、または GitHub までご意見をお寄せください。

Joe Giardino

参考資料

Windows Azure ストレージを最大限に活用する – TechEd NA ‘13 (英語)

Nuget (英語)

Github (英語)

リリース 2.1 の Changelog.txt の全文 (英語)

 

Windows Azure Web サイト: アプリケーション文字列と接続文字列の機能性

$
0
0

このポストは、7 月 18 日に投稿された Windows Azure Web Sites: How Application Strings and Connection Strings Workの翻訳です。

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

Windows Azure Web サイトには、Web サイト関連の構成情報の一部をキー値文字列のペアとして Azure に保存する便利な機能が備えられています。この機能を利用すると、Windows Azure Web サイトの実行時にこれらの値を自動的に取得し、Web サイトで実行するコードで利用できます。一般的で簡単なキー値ペアだけでなく、接続文字列として使用されるキー値ペアも保存できます。

このキー値ペアは、バックグラウンドで Windows Azure Web サイトの構成ストアに保存されるため、ユーザーの Web アプリケーションのファイル コンテンツに保存する必要はありません。これにより、パスワード付きの SQL 接続文字列などの機密情報が web.config や php.ini などのファイルでクリアテキストとして表示されてしまうことがないため、セキュリティ面でもメリットがあります。

Windows Azure ポータルの [Configure] タブで、Web サイトに使用するキー値ペアを入力できます。このタブには、キーと関連する値を入力する場所が 2 か所あります。下のスクリーンショットがその入力画面です。

ここには、「アプリケーション設定」または「接続文字列」としてキー値ペアを入力できます。この 2 つには、1 点だけ違いがあります。接続文字列の方には小さなメタデータが含まれており、Windows Azure Web サイトに対してその文字列値がデータベース接続文字列であること示します。これは、Web サイトでダウンストリーム コードを実行するうえで、接続文字列の特定の動作に対して有効な場合があります。

キー値ペアを環境変数として取得する

開発者が Web サイトで使用するキー値ペアを入力すると、Web サイト内で実行されているコードを使用して、実行時にデータを取得できます。

Windows Azure Web サイトで、実行中の Web サイトにこれらの値を渡す場合、環境変数を使用するのが最も一般的な方法です。たとえば、上のスクリーンショットに示したデータを使用した場合、環境変数を使用してデータをダンプする ASP.NET のコード スニペットは次のようになります。

このコード スニペットのサンプル ページの出力結果は、次のとおりです。

[メモ: この記事では、SQL 接続文字列のうち公開できない部分は意図的にアスタリスクで伏せています。実行時には、サーバー名、データベース名、ユーザー名、パスワードを含む完全な接続文字列が取得されます。]

「アプリケーション設定」および「接続文字列」のどちらの場合でも、キー値ペアは環境変数として保存されるため、これらの値は、Windows Azure Web サイトでサポートされている任意の Web アプリケーション フレームワークで簡単に取得できます。PHP を使用して同一の設定を取得するコード スニペットの例を次に示します。

この記事でお見せしたこれまでの例から、それぞれのキーを参照する場合、命名規則があることに気付かれたのではないでしょうか。「アプリケーション設定」の場合、対応する環境変数の名前の前に “APPSETTING_” という文字列が付きます。

「接続文字列」の場合は、データベースの種類ごとに命名規則があり、ドロップダウン リストで指定したデータベースの種類に応じて環境変数名の前に文字列が追加されます。このサンプルでは、ドロップダウン リストで [SQL Databases] を選択しているため、構成に従って接続文字列に “SQLAZURECONNSTR_“ が使用されています。

データベースの接続文字列の全種類と、環境変数名の前に追加される文字列は以下のとおりです。

[SQL Databases] を選択した場合は、“SQLAZURECONNSTR_“

[SQL Server] を選択した場合は、“SQLCONNSTR_“

[MySQL] を選択した場合は、“MYSQLCONNSTR_“

[Custom] を選択した場合は、“CUSTOMCONNSTR_“

ASP.NET でキー値ペアを取得する

ここまでは、ポータルで入力されたキー値ペアが、環境変数によって Web アプリケーションへ適用されるまでの流れを説明しました。ASP.NET Web アプリケーションでは、同様に使用可能な、ちょっとしたランタイム マジックがあります。各種キー値の名前は、意図的に .NET 開発者に馴染みがあるものにしています。「アプリケーション設定」の場合は、.NET フレームワークの appSettings構成に細かく対応しています。同様に、「接続文字列」の場合は、.NET フレームワークの connectionStringsコレクションに対応しています。

次に示すのは、System.Configuration型を使用してアプリケーション設定を参照する ASP.NET のコード スニペットです。

先に示した例でポータルに入力された値が、自動的に AppSettingsコレクションに組み込まれている点に注目してください。web.config ファイルの既存の値に対してアプリケーション設定が実行されると、Windows Azure Web サイトは、Web サイトに関連付けられている値を使用して、実行時にその部分を自動的に上書きします。

接続文字列もほぼ同様に機能しますが、小さな追加機能があります。先に示した例の中に、“example-config_db“ という Web サイトに関連付けられた接続文字列がありました。Web サイトの web.config ファイルが <connectionStrings /> 構成設定の同一の接続文字列を参照する場合、Windows Azure Web サイトは実行時に、接続文字列の該当部分を、ポータルで入力された値で自動的に更新します。

Windows Azure Web サイトが web.config から接続文字列の該当する名前を発見できない場合、前述のとおり、ポータルで入力された接続文字列は環境変数としてのみ使用できます。

たとえばここで、web.config のエントリを次のように仮定したとします。

Web サイトは、次のコード スニペットを使用してこの接続文字列を参照します。このとき、環境には依存しません。

このコードが開発者のローカル マシンで実行されている場合は、戻された値は web.config ファイルの値です。一方、このコードが Windows Azure Web サイトで実行されている場合は、戻された値はポータルで入力された値で上書きされます。

この機能は非常に便利です。と言うのも、アプリケーションの展開先にかかわらず、アプリケーションが使用している接続文字列情報を正しく把握することは、長い間開発者たちを悩ませてきた問題であり、この機能を使用することでこの問題を上手く解決できるからです。

コマンドラインからキー値ペアを構成する

ポータルでアプリケーション設定や接続文字列の保守を行う代わりに、PowerShell コマンドレットやクロスプラットフォームのコマンド ライン ツールでも、両方の種類のキー値ペアを取得したり更新したりすることができます。

たとえば、次の PowerShell コマンドでは、複数のアプリケーション設定のハッシュテーブルを定義し、“example-config“ という Web サイトに関連付けしつつ、Set-AzureWebsiteコマンドレットで Azure に保存します。

このコード スニペットを ASP.NET で実行すると、元のアプリケーション設定の値 (“some-key-here“) が更新され、2 つめのキー値ペア (“some-other-key“) が追加されます。

サンプルの HTML 出力を見ると、次のように更新されていることがわかります。

“some-other-key“ から “a-different-value“ に更新

“some-key-here“ から “changed-this-value“ に更新

接続文字列を更新した場合も、同様の作業が行われます。ただし、PowerShell コマンドレットでは、接続文字列が ConnStringInfoオブジェクト (正確には Microsoft.WindowsAzure.Management.Utilities.Websites.Services.WebEntities.ConnStringInfo) の List<T>として内部的に処理されるため、構文が多少異なります。

次の PowerShell コマンドは、新しい接続文字列を定義して、Web サイトに関連付けられたリストに追加し、その後すべての接続文字列を Azure に保存し直します。

$cs.Typeプロパティの種類を定義するうえで使用できる文字列は、“Custom“、“SQLAzure“、“SQLServer“、“MySql“ のいずれかです。

以下のコード スニペットを ASP.NET で実行すると、Web サイトの全接続文字列のリストが作成されます。

Windows Azure Web サイトで接続文字列を上書きし .NET フレームワークの接続文字列構成コレクションの値としてマテリアル化するには、接続文字列が事前に web.config で定義されている必要があるので注意してください。このサンプル Web サイトでは、web.config は次のように更新されました。

ASP.NET ページの実行時に、両方の接続文字列の値は PowerShell を介して保存された値で上書きされます (最初の接続文字列のうち公開できない部分は、意図的にアスタリスクで伏せています)。

まとめ

この記事では、構成データのシンプルなキー値ペアを Web サイトに関連付けて、実行時に環境変数として取得することがいかに簡単かをご紹介しました。この機能を活用すると、構成データを Web サイトの構成ファイルでクリアテキストとして表示することなく、安全に保存できます。また、ASP.NET を使用している場合、値を .NET の AppSettingsおよび ConnectionStrings構成コレクションの値として自動的にマテリアル化できる、ちょっとした「マジック」のような拡張構成機能を使用できます。

ぜひ、お試しください!

 

クロスポスト : Windows Azure 7 月アップデート情報 : SQL データベース、トラフィック マネージャー、オート スケール、仮想マシン

$
0
0

このポストは、7 月 23 日に投稿された Cross-Post: Windows Azure July Updates: SQL Database, Traffic Manager, AutoScale, Virtual Machinesの翻訳です。

本日、わたし達は Windows Azure の素晴らしい機能強化を発表しました。新しくアップデートされた機能は以下になります。

  • SQL データベース : 自動 SQL エクスポートおよび、新しいプレミアム SQL データベース オプション
  • トラフィック マネージャー : HTML ポータルでの Windows Azure トラフィック マネージャーを管理するための新しいサポート
  • オート スケール : Windows Azure モバイル サービスのサポート、オート スケール サービス バス キュー深度の規則、オート スケール操作のアラート
  • 仮想マシン : 管理ポータルでの IaaS 管理エクスペアリエンスの更新

これらのアップデート機能は今すぐにご使用になれます。 (注: 一部プレビューです。)

Scott ブログで詳細について読むことができます。

scott

 

クラウド サービスの基礎 – フォールト トレラントなデータ アクセス層のご紹介

$
0
0

このポストは、7 月 25 日に投稿された Cloud Service Fundamentals – Introduction into Fault-Tolerant Data Access Layerの翻訳です。

編集メモ:今回は AzureCAT チームの Valery Mizonov (英語)の投稿をご紹介します。

先日のブログ記事「テレメトリ – アプリケーションのインストルメント (英語)」では、Windows Azure SQL データベース サービスに一時的障害が発生しても運用を持続できるよう、「Windows Azure でのクラウド サービスの基礎」コード プロジェクトにおいてフォールト トレラントなデータ アクセス層の課題に取り組んだことをお伝えし、あわせて、アプリケーションのインストルメントに関するベスト プラクティスや、ソリューションの信頼性と回復性を高めるヒントをご紹介しました。

この記事では、回復性にすぐれたデータ アクセス層を構築するとは実際にどういうことか、またそのデータ アクセス層を構築するという重要な要件に対して、「クラウド サービスの基礎」プロジェクトでどのようにアプローチしたかについて、詳しく掘り下げていきます。

クラウドベースの分散アプリケーションや分散サービスの構築は、困難を極める作業です。最新のクラウド インフラストラクチャには、リソース調整、通信障害、プラットフォーム サービスの動作不安定など、設計上のものや異常に起因するものを含め、さまざまな落とし穴があるためです。このクラスの問題は通常、アプリケーション固有のサービス レベル契約 (SLA) について常に把握すると共に、潜在的な一時的障害を検出し、失敗した処理を再試行するという方法で解決されます。

処理を再試行するかどうか的確な判断を下すためには、既知の一時的障害およびその識別子 (エラー コードまたは例外のタイプ) のナレッジ ベースを構築する必要があります。これは、非常に煩雑で時間のかかる作業です。しかし、Windows Azure 開発者は、この作業を一切行わずに、より重要な作業に専念できます。一時的障害に対処するためのナレッジやインテリジェンスは、Enterprise Library の Transient Fault Handling Application Block (英語)によって実装されるためです。これにより、クラウドベース サービスの回復性を簡単に強化することができます。Transient Fault Handling Application Block は、Windows Azure に関連する潜在的な既知の一時的障害を含むナレッジ ベースと使いやすい API とから構成されます。

Cloud Service Fundamentals ソリューションは、Windows Azure SQL データベース サービスで起こりうる制限条件などの一時的エラーからデータ アクセス層を保護するうえで、Transient Fault Handling Application Block を大いに活用しています。

「クラウド サービスの基礎」コード プロジェクトにおいては、一時的障害に対する処置という観点から、以下のベスト プラクティスに沿ってデータ アクセス層を構築しました。

  • NuGet から Transient Fault Handling Application Block (英語)の最新版を使用して、最新の一時的障害ナレッジ ベースと検出ロジックを活用しました。
  • 一時的障害の等べきな境界を適切に定め、一時的障害が発生した場合にはアプリケーション ロジックを再試行する必要があります。
  • すべての再試行と一時的障害を記録し (デコード化された調整理由を含む)、アプリケーション テレメトリにこれらの障害に関するインサイトを追加して、トラブルシューティングを促進しました。
  • 特定のエンドツーエンド ビジネス トランザクションの SLA のパフォーマンスを見分け、高く評価する、再試行ロジックの期限付き動作を適用することで、具体的な再試行回数や遅延間隔についてではなく、ビジネスの SLA の観点から考えました。
  • 構成において再試行ポリシーを管理し、ハードコーディングの再試行方法パラメーターを回避して、実行時の変更をサポートできるよう敏捷性が向上しました。
  • SQL 接続とコマンドの(どちらか一方のみではなく) 双方に再試行ロジックを適用しました。一部の SQL コマンドは、トランザクションにより保護されていない限り、安全に再試行できないということを覚えておかなければなりません。
  • 一時的障害が長時間にわたる (場合によっては回復不可能となる) ことを想定して、復旧に影響がないように配慮する必要があります。たとえば、再試行の遅延間隔を急激に拡大することで、適切に再試行パターンを処理します。

このトピックに関する詳細については、wiki 記事「クラウド サービスの基礎におけるデータ アクセス層 – 一時的障害の対応 (英語)」をご参照ください。また、データベース サービス障害から回復する方法や、同様のテクニックやベスト プラクティスを利用して優れたクラウド アプリケーションを構築する方法についても、ご覧いただけます。

最後までお読みいただき、ありがとうございます。このシリーズ記事として、次回はレポート機能についてご説明します。これは、インストルメントしたアプリケーションからのテレメトリを実行するために実装されたもので、Windows Azure SQL レポートサービスおよびそのデータ仮想化機能を使用しています。

既成の Linux イメージを実行する Windows Azure 仮想マシンのスワップ領域 - パート 1

$
0
0

このポストは、7 月 29 日に投稿された SWAP space in Windows Azure Virtual Machines running pre-built Linux Images – Part 1の翻訳です。

この記事は、Azure CAT チームの Piyush Ranjan (MSFT)が執筆したものです。

近年、Windows Azure のインフラストラクチャ サービス (仮想マシンおよび仮想ネットワーク) の一般的な普及に伴い、クラウドの経済性、規模、速さという利点を得るために、より多くの企業のワークロードがパブリック クラウドに移行してきています。私は最近そのような企業のワークロード、つまりクラウド内のビッグ データ関連のプロジェクトにかかわっていました。ここではこれらに関連するいくつかのヒントとベスト プラクティスを皆さんにお伝えしたいと思います。

このプロジェクトでは、既成の Linux イメージを使用して、Windows Azure に複数ノードの Hadoop クラスターをデプロイする必要がありました。私は Windows Azure イメージ ギャラリーから入手した CentOS 6.3 イメージを使用して中規模な仮想マシン (VM) を準備し、単一ノードのコア Hadoop をデプロイしました。デプロイ自体は成功しましたが、テスト開始時にやや重いワークロードがかかっており、VM が頻繁にフリーズしたり応答を返さないという現象がみられました。

CPU コア 2 基とメモリ 3.5 GB しかない、中規模の VM のリソースが問題であることは容易に推測できました。しかし、VM 全体が応答を返さなかったり接続が途切れたりすることは予想外でした。この問題について友人や同僚と話し合ったところ、VM にはまったくスワップ (Windows ではページ ファイルと呼ばれる) が構成されていないことが判明しました。つまり、仮想メモリ システムはメモリ負担が増大したときに、ディスクにスワップすることができなかったのです。

システムによるメモリ制御状況を調べるには、Linux シェル プロンプトから "free" コマンドを実行します。特に、"cat /proc/swaps" を使用すると、スワップ領域の状態について、構成されているサイズと使用中のサイズを確認できます。下のスクリーンショットをご覧ください。

スワップ領域がまったく構成されていない場合 (Windows Azure 仮想マシンに用意された Linux VM のデフォルト状態)、"cat /proc/swaps" は何も返しません。同様に、"free" コマンドもスワップでの動作状況を何も表示しません。

興味深いのは、Linux ライブラリ イメージ (Windows Azure イメージ ギャラリーから入手するなど) を使用する VM プロビジョニングはなぜ自動的にスワップ領域を構成しないのか、ということです。ユーザーがスワップの大きさと場所を決め、プロビジョニング後にその設定を行うべきであると思われます。しかし、あるユーザーがスワップを構成せずに VM の使用を続け、やがてプロセスがクラッシュし始めたり VM がフリーズしたりすることは十分にあり得ます。

そうは言っても、必要なのはスワップ領域を確保することであると気付いた後、簡単な手順に従ってファイル ベースのスワップをリソース ディスクに構成しました。その結果、Windows Azure の中規模の仮想マシンには 135 GB のリソース ディスクが "/mnt/resource" としてマウントされました。ファイル ベースのスワップ領域を VM 上に構成する手順を以下に示します。

  • "fallocate" コマンドを使用して、適切なサイズ (たとえば 5 GB) のスワップ ファイルをリソース ディスクに割り当てます。構文は "fallocate -l 5g /mnt/resource/swap5g" であり、"swap5g" はファイルの名前です。
  • "chmod" コマンドを使用してファイルのパーミッションを変更し、root ユーザーのみがスワップ ファイルの読み取り/書き込み権限を持つようにします。構文は "chmod 600 /mnt/resource/swap5g" です。
  • "mkswap" コマンドを使用して、ファイルをスワップ領域として設定します。構文は "mkswap /mnt/resource/swap5g" です。
  • "swapon" コマンドを使用して、スワップ ファイルを使用可能にします。構文は "swapon /mnt/resource/swap5g" です。
  • これでスワップが使用可能になり、"cat /proc/swaps" コマンドによりそれが確認できるはずです。エントリを "/etc/fstab" ファイルに追加して、VM を Azure でリサイクルする場合にもスワップの設定が維持されるようにします。構文は echo “/mnt/resource/swap5g   none  swap  sw  0 0” >> /etc/fstab です。

上記のコマンドを私の VM で実行したときの画面コピーを以下に示します。

謝辞: スワップの問題のトラブルシューティングと解決を支援してくれた同僚の Amit Srivastava に感謝します。


Windows Azure 仮想マシンでの Windows システム ディスクのバックアップと復元の方法

$
0
0

このポストは、8 月 1 日に投稿された How to backup and restore a Windows system disk in a Windows Azure Virtual Machineの翻訳です。

バックアップと復元は、実際のシステム運用にとって重要な要素です。Windows Azure 仮想マシン環境の Windows Server では、バックアップと復元のためのツールを複数利用でき、また必要に応じてこれらのツールを組み合わせて使用することができます。各ツールの特徴と簡単な比較表を以下にまとめましたので、最適なソリューションを判断する際にお役立てください。

Windows Server バックアップ (WSB)

Windows Server バックアップは、仮想マシン内からのオンライン バックアップに使用します。ファイルやフォルダーのほか、システム状態もバックアップ可能です。

Windows Server バックアップでは、バックアップ ファイルが仮想マシン内に作成されます。仮想マシン内に作成されたバックアップ ファイルを外部の場所に移動する場合は、Windows Azure バックアップなどの他のソリューションを使用する必要があります。

Windows Azure バックアップ (WAB)

Windows Azure バックアップはローカル ファイルをクラウドにバックアップするためのソリューションで、このツールも Windows Azure 仮想マシンから使用できます。マイクロソフトの他のバックアップ ツールにクラウド バックアップ機能を追加するものであり、Windows Server バックアップと組み合わせたり、System Center 2012 Data Protection Manager と組み合わせたりするなど、いくつかの使い方があります。

チュートリアルについては、Windows Azure バックアップを使用したバックアップの設定方法 (英語)を参照してください。

また、Windows Azure バックアップに関心をお持ちの方は、料金の詳細をご覧ください。

System Center 2012

Windows Azure バックアップでは、System Center 2012 Data Protection Manager (DPM) と統合して、オンサイト サーバーのデータを保護することも可能です。この場合、Windows Azure バックアップ エージェント ソフトウェアを DPM サーバーにインストールします。これにより、DPM には環境内のサーバーを保護するという通常の機能に加えて、バックアップをクラウド ストレージに保存する機能が追加されます。

Windows Azure Copy Blob API および Storage Client Library API (Copy Blob)

Windows Azure ストレージ サービスの Copy Blob (REST API)を使用すると、開発者は Windows Azure または開発環境の BLOB、キュー、テーブルの各サービスにアクセスできます。Copy Blob 操作は BLOB を特定のコピー先にコピーします。

.NET 向け Windows Azure ストレージ クライアント ライブラリ (バージョン 2.0) にはストレージ クライアント ライブラリが含まれています。このライブラリを使って、.NET アプリケーションや PowerShell スクリプトから REST API にアクセスできます。使い方の詳細については、CloudPageBlob.StartCopyFromBlob (英語)を参照してください。

ファイルやフォルダーを仮想マシン内からバックアップする WSB や WAB とは異なり、この API を使用したコピーは、仮想マシン外からのベア メタルのバックアップと復元に使用します。たとえば、Active Directory ドメイン コントローラーをバックアップしたい場合は、Copy Blob を初期システム バックアップとして使用して、ベア メタルのバックアップを作成できます。その後から WSB を使用して、システム状態をファイルにバックアップし、WAB を使用して、システム状態のバックアップ ファイルを含むファイルやフォルダーを Windows Azure ストレージにバックアップします。これらのマシンを復元するには、まずベア メタル バックアップ VHD から復元し、WSB や WAB を使用して、作成したバックアップ ファイルから復元します。

ツールの比較

それぞれのツールの機能を比較した簡単な表を作成しましたのでご覧ください。

ツール

オンライン バックアップ

(アプリケーションでダウンタイムは発生しない)

バックアップ先

システム状態のバックアップ

ファイル/フォルダーのバックアップ

WSB

OS 内

WAB

BLOB ストア

Copy Blob

BLOB ストア

VHD 全体として

SQL Server のセキュリティ機能を Windows Azure 仮想マシンで使用する

$
0
0

このポストは、8 月 2 日に投稿された Using Microsoft SQL Server security features in Windows Azure Virtual Machinesの翻訳です。

編集メモ:今回は、SQL Server チームでシニア プログラム マネージャーを務める Sung Hsueh の投稿をご紹介します。

SQL Server の新しい利用方法として、マイクロソフトの Windows Azure インフラストラクチャ サービスで作成した Windows Azure 仮想マシンで SQL Server をホストすることができます。既にお読みになった方もいらっしゃると思いますが、昨年 Il-Sung が投稿したブログ記事 (http://blogs.msdn.com/b/windowsazurej/archive/2012/12/12/regulatory-compliance-considerations-for-sql-server-running-in-windows-azure-virtual-machine.aspx) では、コンプライアンス要件に対応しながら Windows Azure 仮想マシンで SQL Server を実行できることをお伝えしました。Windows Azure 仮想マシンには、事前構成済みですぐに展開できるというメリットがあり、実行した時間の合計分数に基づいて課金されます。この Windows Azure 仮想マシンで SQL Server 2008 R2 Enterprise Edition および SQL Server 2012 Enterprise Edition を実行して、SQL Server Audit や透過的なデータ暗号化などのエンタープライズ レベルの機能を利用することができます。もちろん、従量課金制ではなく、既存のソフトウェア アシュアランスまたは Enterprise Agreement のライセンスで提供されるライセンス モビリティ (http://www.microsoft.com/ja-jp/licensing/software-assurance/license-mobility.aspx) でも、これらの機能を活用できます。

SQL Server の透過的なデータ暗号化を Windows Azure 仮想マシンで使用する

ここからは、Windows Azure 仮想マシンで SQL Server の機能を活用する例として、透過的なデータ暗号化 (http://msdn.microsoft.com/ja-jp/library/bb934049.aspx) の使用手順について簡単にご説明します。まだお持ちでない場合には Windows Azure 仮想マシンを作成し、Windows Azure 管理ポータルから SQL Server をインストールしてください。

さらに、いくつかデータベースを作成しましょう。

データベースに暗号化を設定する手順は以下のとおりです。SQL Server をローカルで実行している場合にも、これと同じ手順で設定できます。

1.マスター データベースでオブジェクトを作成できるユーザーの資格情報を入力して、仮想マシンにログインします。

2.マスター データベースで、(“USE MASTER” に続けて) 以下の DDL を実行します。

CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘<your password here>’;

Go

CREATE CERTIFICATE TDEServerCert WITH SUBJECT = ‘My TDE certificate’;

Go

3.暗号化するデータベースに切り替えます。

4.以下の DDL を実行します。

CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE TDEServerCert;

Go

ALTER DATABASE [your_database_name] SET ENCRYPTION ON;

Go

これで完了です。暗号化はバックグラウンドで実行されます (暗号化の状態は、sys.dm_database_encryption_keys を実行することで確認できます)。オンプレミスの SQL Server インスタンスでも、同様です。また、SQL Server Audit (http://msdn.microsoft.com/ja-jp/library/cc280386.aspx) も、現在のオンプレミス環境とまったく同じようにお使いいただけます。

セキュリティに関するその他の考慮事項

これに加えて、セキュリティのベストプラクティス (http://msdn.microsoft.com/library/windowsazure/dn133147.aspx) を実践することも忘れてはいけません。たとえば、以下の考慮事項があります。

  • 攻撃対象領域を抑えるため、不要なサービスを無効化する
  • 弱いアルゴリズムを使用しているなどのセキュリティ状態を検出するため、ポリシーベースの管理を活用する
  • 可能な限り権限は最小限にとどめ、sa や sysadmin といった組み込みのアカウントまたはグループの使用を回避すると共に、管理操作の追跡に SQL Server Audit を使用する
  • 暗号化機能の使用を検討している場合、サービス マスター キーで開始されるキー エージングやキー ローテーションのポリシーを作成する
  • 特に、Windows Azure のパブリック エンドポイントから SQL Server に接続する場合は、SSL 暗号化の使用を検討する
  • 特に、Windows Azure のパブリック エンドポイントから SQL Server に接続する場合は、SQL Server が既定のインスタンスに使用するポートを 1433 以外に変更することを検討する (可能であれば、パブリック インターネット全体からの SQL Server インスタンスへの外部接続は避ける)

おわりに

SQL Server Enterprise Edition を Windows Azure 仮想マシンで実行すると、既存のアプリケーションのセキュリティに関するベスト プラクティスや専門知識を引き継ぐことができます。さらに、マイクロソフトの Windows Azure には従量課金制プランが用意されているため、クラウド上でアプリケーションを実行した分だけしかコストがかかりません。ぜひお試しいただき、ご意見をお聞かせください。

 

サーバーおよびツール製品に関するインターナショナル ユーザー アンケート 2013 ご協力のお願い

$
0
0

マイクロソフトでは、お客様によりよい製品をお届けするために言語版製品の品質について調査を行っております。アンケートはすべて無記名でお客様の個人情報をマイクロソフトが取得することはありません。このアンケートにかかる時間はお客様が選択される製品によって異なりますが、およそ 5 ~ 15 分ほどです。対象製品をご利用いただいているお客様は、ぜひご意見をお聞かせください。

対象製品

  • Visual Studio
  • SQL Server
  • Windows Azure
  • Windows Server
  • System Center

調査の表示言語

アンケートは以下の言語で表示することができます。ご希望の言語をクリックしてアンケートにお進みください。

クラウド サービスの基礎: テレメトリ – データ取得パイプライン

$
0
0

このポストは、8 月 8 日に投稿された Cloud Service Fundamentals: Telemetry – Data Acquisition Pipelineの翻訳です。

Windows Azure のクラウド サービスの基礎の一部であるテレメトリ ソリューションの中心ともいえるのが、データ取得パイプラインです。Wiki シリーズ (英語) の 3 つ目の記事 (英語) で取り上げているのがこのパイプラインですが、テレメトリ ソリューションにおけるこのパイプラインの役割は、各種リポジトリからさまざまな情報を抽出し、単一のリレーショナル データベースに集積することです。このデータベースを使用して情報を関連付け、記録した指標の長期的なトレンドを分析し、特定の問題およびインシデントについて掘り下げ、定型のレポート/ダッシュボードおよびアドホックなレポート/ダッシュボードの両方をフィードすることができます (これについては次回の記事で取り上げます)。このエンドツーエンドのテレメトリ ソリューションにより、「利用者からパフォーマンス低下の報告があったが、そのときのアプリケーション コンポーネントの状態はどうだったのか」、「協定世界時 (UTC) の午前 0 時から午後 1 時の間にアプリケーションがタイムアウト エラーを生成した際、データ層にはどのような変化が生じていたか」といった問いに簡単に答えられるようになります。

図 1 - テレメトリ ソリューション アーキテクチャ全体におけるデータ取得パイプラインの概念図

アーキテクチャの観点から見ると、データ取得パイプラインは次の 3 つに分類することができます。

  1. インポート タスクや変換タスクを実行する、構成可能なスケジューラー エンジン
  2. 各種情報源を照会して特定の変換ロジックを適用し、その結果を中央リポジトリにプッシュする拡張可能なタスク群
  3. データを一般的なリレーショナル スキーマに保存する Windows Azure SQL データベース インスタンス (これを使用して分析クエリを実行し、有意な情報を抽出)

スケジューラー エンジンを実装すると共に、一定の時間間隔で各種データ ソースを照会する「プル」メカニズムを導入していますが、より複雑な「プッシュ」や「ストリーミング」といった方法よりもこのアプローチを採用していることにはいくつか理由があります。その最大の理由は、Windows Azure ストレージ (Windows Azure 診断により生成された情報の場合) や Windows Azure SQL データベースの内部データ構造体 (動的管理ビューの場合) のような中間リポジトリに、データが既に保存されている点です。また、リアルタイムの継続的な分析に対する厳格な要件もなく、実装をできるだけシンプルな状態に保つことを目指しました。最新リリースでは、スケジューラーは Windows Azure の Worker ロールとして実装されており、Windows Azure ストレージの BLOB コンテナーにホストされている XML ファイルから構成を読み取ります。このファイルには、実行予定のジョブの数、種類、実行頻度のほか、すべての構成オプション、各種データ ソースおよびデータ保存先の接続文字列が定義されています。構成ファイルはいつでも変更可能で、タスクを追加/削除したり、特定の構成を変更したりすることができ、Worker ロールは更新された構成ファイルに基づいて実行を開始します。自社のソリューションをモニタリングしているお客様およびパートナー様にご協力いただき、このスケジューラー コンポーネントを運用環境へ展開した結果、この Worker ロールは S サイズの仮想マシンで数百件のコンピューティング インスタンスおよびデータベースに十分対応できることがわかりました。

また他にも、次の 2 つの重要な診断ソースに接続するための重要なタスクを実装しました。

  • Windows Azure 診断によって生成されたデータ
  • 動的管理ビューからアクセス可能な Windows Azure SQL データベースの内部状態

Windows Azure 診断はほとんどの情報を Windows Azure ストレージ テーブルに保存するため、インポート タスクの多くは非常によく似ています。基本的には、Windows Azure ストレージ クライアント ライブラリ v 2.0 のコンテキストを使用して、特定の時間帯 (startdate から enddate まで) にソース テーブルを照会し、直接いくつかのフィルター (重要なイベント、エラー イベントなど) を適用して、データ行をその場で整形または変換し、その結果得られた新たな情報を目的のデータベースに一括コピーします。Windows Azure コンピューティング ノードのパフォーマンス カウンターや Windows イベント ログおよびトレース ログのなどの情報がこれに当たります。より複雑な実装では、特定の構造で構成されている BLOB コンテナーに保存されているすべての Web ロールの IIS ログを Windows Azure 診断で収集します。この場合、最初に (特定の時間帯に生成されたすべてのログ ファイルへの参照が格納されている) テーブルを照会した後、IIS ログ ファイルを Worker ロールのローカル ストレージにダウンロードして分析を行い、Web ページや API 応答時間などの有意な情報を抽出します。

SQL データベース インスタンスについては、(並列展開ライブラリを使用して) すべての対象データベースの公開されている動的管理ビューを照会する特定のインポート タスクを作成し、クエリや要求の統計情報、接続エラー、不足しているインデックス、データベースのサイズといったさまざまな有用な情報を抽出します。

今後改善すべき点として、Windows Azure ストレージ分析およびキャッシュの診断情報を追加することを検討しています。

この診断情報はすべて、時間ベースの共通のキー定義を使用し、一定間隔のクエリに最適化された (SQL データベースでもホストされている) 単一のリレーショナル スキーマに保存されます。その理由はシンプルで、特定のインシデントの調査や経時的なトレンドの把握に使用する可能性が高いためです。

先に述べたとおり、次回の記事では OpsStatsDB を照会し有意な情報を抽出する方法について取り上げ、テーブル値関数 (TVF) 層に焦点を当てます。この TVF は、Excel を使用したアドホックなレポートの実装を簡素化することを目的として開発したものです。また、クラウド サービスの基礎コード パッケージに付属の Windows Azure SQL レポート サービスのレポートおよびダッシュボードについても見ていきます。

クラウド サービスの基礎シリーズの全記事はこちら (英語) の TechNet Wiki ページをご覧ください。

Windows Azure の Linux 仮想マシンにおけるスワップ領域 – パート 2

$
0
0

このポストは、8 月 9 日に投稿された SWAP space in Linux VM’s on Windows Azure – Part 2の翻訳です。

この記事は Azure CAT チームの Piyush Ranjan (MSFT)が担当しました。

前の記事「既成の Linux イメージを実行する Windows Azure 仮想マシンのスワップ領域 - パート 1」で説明したように、Azure IaaS でギャラリー イメージからプロビジョニングされる Linux 仮想マシンには、既定ではスワップ領域が構成されません。そこで前の記事では、リソース ディスク (/mnt/resource) にファイル ベースのスワップ領域を構成するための簡単な手順を紹介しました。ただ注意してほしいのは、その手順は、既にプロビジョニングされ、実行中の仮想マシンに対するものだという点です。それよりも、仮想マシンのプロビジョニングと同時に、スワップ領域が自動的に構成されれば理想的であり、後の段階で大量のコマンドを手動で実行する労力が省けます。

仮想マシンのプロビジョニング段階で自動的にスワップ領域を構成するうえで決め手となるのは、Windows Azure Linux エージェント (waagent) の使用です。大部分のユーザーは、Linux 仮想マシンの内部でエージェントが動作していることを漠然とは知っていても、よくわからないため放置している場合がほとんどです。実は、waagent に関する優れたドキュメントが Azure ポータルに用意されています。Windows Azure Linux エージェント ユーザー ガイドを参照してください。後ほど waagent について詳しく説明し、waagent を使って前述の問題を解決する方法を紹介しますが、その前に、もう 1 つ知っておくべきポイントがあります。それは、ユーザーが Linux 仮想マシンをカスタマイズし、今後プロビジョニングする際に再利用できるイメージとして、その Linux 仮想マシンをエクスポートする必要があるという点です。Azure ギャラリーにある未加工の Linux ベース イメージをそのまま使用する場合、waagent の機能を利用することはできません。これは実際のところ、制約ではありません。最も便利なユース ケース シナリオは、ギャラリー イメージを使ってプロビジョニングされた仮想マシンからスタートし、その後、自分が希望するコンポーネントを使ってカスタマイズする方法である、と考えるからです。たとえば、OpenJDK Java の代わりに標準の Java (英語)を使用することができます。あるいは、仮想マシンに Hadoop バイナリをインストールし、後でイメージを使用してマルチノード クラスターを作ってもいいでしょう。このようなシナリオでは、プロビジョニング プロセス中に自動的に実行したい追加的な処理を waagent で実行できるようにするほうが非常に簡単です。

Windows Azure Linux エージェント ユーザー ガイドで説明されているように、エージェントでさまざまな処理を実行するよう構成できます。たとえば次のような処理です。

  • リソース ディスクの管理
  • リソース ディスクのフォーマットとマウント
  • スワップ領域の構成

ギャラリー イメージからプロビジョニングされる仮想マシンには waagent が既にインストールされているので、必要なのは "/etc/waagent.conf" にある構成ファイルの編集だけです。この構成ファイルは、次のようになっています。

構成ファイルで、上の図に示す 2 行を変更して次のように設定し、スワップを有効にします。

ResourceDisk.EnableSwap=y

ResourceDisk.SwapSizeMB=5120

したがってプロセス全体をまとめると、次のようになります。

IaaS で通常どおり、いずれかのギャラリー イメージを使用して Linux 仮想マシンをプロビジョニングする。

ユーザーの好みに応じてソフトウェア コンポーネントのインストールや削除を行い、その仮想マシンをカスタマイズする。

"/etc/waagent.conf" ファイルを編集して、スワップ関連の行を設定する (上記参照)。スワップ ファイルのサイズを調整する (上記の例では 5 GB に設定)。

こちらで説明されている手順で、仮想マシンの再利用可能なイメージをキャプチャする。

エクスポートしたイメージを使用して、新しい Linux 仮想マシンをプロビジョニングする。これらの仮想マシンでは、自動的にスワップ領域が有効に設定されている。

以上は Windows Azure Linux エージェントに関する説明でしたが、waagent にはその他にも、興味深い機能があります。同じ構成ファイル "/etc/waagent.conf" に含まれている Role.StateConsumer プロパティを使用して、ユーザーが指定する任意のスクリプトを実行することができるのです。たとえば、次のようなシェル スクリプト "do-cfg.sh" を作成します。

次に、構成ファイル内で Role.StateConsumer=/home/scripts/do-cfg.shなど、このスクリプトのパスを設定します。waagent は、仮想マシンのプロビジョニングの際、Azure ファブリックに "Ready" シグナルを送信する直前に、このスクリプトを実行し、カスタム スクリプトにコマンド ライン引数 "Ready" を渡します。スクリプトでは、上の例のようにこの引数を確認し、何らかのカスタムな初期化を実行します。同様に、仮想マシンのシャットダウン時にも、waagent は同じスクリプトを実行し、コマンド ライン引数 "Shutdown" をスクリプトに渡します。それにより、この引数を確認したうえで、仮想マシン上で何らかのカスタムなクリーンアップ タスクを実行することができます。

Viewing all 711 articles
Browse latest View live