Windows Azure: SQL Server AlwaysOnサポートと通知ハブの一般提供、自動スケールの改善など

Posted: 2013/08/14 カテゴリー: Uncategorized
タグ:, , , , , ,

今朝、Windows Azureに対するいくつかのアップデートをリリースしました。新機能は次の通りです:

  • SQL Server AlwaysOnのサポート: Windows Azure仮想マシンでのサポートの一般提供 (高可用性と災害復旧の両方を実現)
  • 通知ハブ: Windows Azure通知ハブの一般提供リリース (Windows 8、Windows Phone、iOS、Android向けのブロードキャスト プッシュ)
  • 自動スケール: スケジュール ベースの自動スケール規則と、より高度なログ記録のサポート
  • 仮想マシン: ロード バランサーの構成と管理
  • 管理サービス: 操作ログと警告向けの新しいポータル拡張

これらの改善すべては利用可能になっており、今すぐ使うことができます (注: 自動スケールはまだプレビューですが、他のすべては一般提供です)。詳細は次の通りです:

Windows Azure仮想マシンでのSQL Server AlwaysOnのサポート

Widnows AzureにおけるSQL Server AlwaysOn可用性グループ (英語 / 日本語 (機械翻訳) / 日本語 (現時点で未更新)) のサポートの一般提供リリースを発表できて、興奮しています。Windows Server 2012におけるSQL Server 2012 (以降) 向けの可用性グループ リスナーをサポートするために、公式のドキュメント (英語 / 日本語 (機械翻訳) / 日本語 (現時点で未更新)) をアップデートしました。

SQL Server 2012で導入されたSQL Server AlwaysOn可用性グループのサポートは、SQL Serverで高可用性と災害復旧を実現するためのMicrosoftの最高のソリューションです。SQL Server AlwaysOn可用性グループは、複数データベースのフェイルオーバー、複数のレプリカ (SQL Server 2012では5個、SQL Server 2014では9個)、(レポート/BIアプリケーションをオフロードするために使える) 読み取り可能なセカンダリ レプリカ、構成可能なフェイルオーバー ポリシー、セカンダリ レプリカでのバックアップ、簡単な監視をサポートしています。

本日、(SQL Server AlwaysOn可用性グループ リスナーのサポートを含む) Windows Azure仮想マシンにおけるSQL Server AlwaysOn可用性グループのテクノロジー スタックの完全なサポートを発表できて、興奮しています。SQL Server AlwaysOn可用性グループで実現される幅広いシナリオをサポートする最初のクラウド プロバイダーになれて、本当に興奮しています。我々は、これによって、お客様が多数の新しいシナリオに対応できると考えてます。

仮想マシンで稼働するSQL Serverの高可用性

高可用性とグローバルのビジネス継続性を達成するために、Windows Azure仮想マシン内でSQL Server AlwaysOnを使うことができるようになりました。このサポートの一部として、1つ以上の「読み取り可能なデータベース セカンダリ」をデプロイできるようになりました。これは、SQL Serverの可用性を改善するだけでなく、BIレポート作業とバックアップをセカンダリ マシンにオフロードできることで、効率を改善します。

Windows Azureの本日のリリースには、Windows Azureネットワーク ロード バランサーでSQL Server AlwaysOn機能をより良くサポートするための変更が含まれています。本日のアップデートで、可用性グループ リスナー エンドポイントを使った単一のクライアント接続 (英語 / 日本語) 文字列で、SQL Serverデプロイに接続できるようになりました。これは、データベース接続をプライマリ レプリカ ノードに自動的にルーティングします。そして、自動または手動のフェイルオーバーが発生した場合、Windows Azureネットワーク ロード バランサーは、リクエストをセカンダリ レプリカ ノードにルーティングするように、自動的にアップデートされます:

1この新しいSQL Server AlwaysOn可用性グループ リスナーのサポートによって、Windows Azure仮想マシンに高可用性構成のSQL Serverを簡単にデプロイし、SQL Serverの完全な機能セットをフル活用できるようになります。また、これは、アップグレード操作の間や仮想マシンへのパッチ適用時に、ダウンタイムが発生しないことを保証するためにも使えます。

Windows Azureを使ったオンプレミスSQL Serverの災害復旧

また、新しいSQL Server AlwaysOnサポートは、Windows Azure内で高可用性を実現することに加えて、「オンプレミスSQL Serverソリューション」が、Windows Azure仮想マシンを使ってクラウドで稼働する1つ以上のセカンダリ レプリカを持つように拡張できるようにするためにも使えます。これによって、企業は、高可用性/災害復旧シナリオを実現できます。(たとえば、台風や自然災害のために) ローカル データセンターがダウンした場合や、単にオンプレミスのネットワーク ハードウェア障害が発生した場合に、Windows Azureを使ってクラウドにデプロイされている仮想マシンを使って、フェイルオーバーして操作を継続できます。

2

上の図は、オンプレミスSQL Server AlwaysOn可用性グループが、プライマリ レプリカとセカンダリ レプリカ (S1) という、2つのデータベース レプリカで定義されているシナリオを示しています。もう1つのセカンダリ レプリカ (S2) は、クラウドのWindows Azure仮想マシンで稼働するように構成されています。このセカンダリ レプリカ (S2) は、オンプレミスのプライマリ レプリカからトランザクションを継続的に同期します。オンプレミスの災害時には、クラウドのレプリカにフェイルオーバーし、ビジネスへの影響なしに操作を継続できます。

また、セカンダリ レプリカは、災害復旧の実現に加えて、レポート アプリケーションとバックアップをオフロードするためにも使えます。これは、コンプライアンスの理由でデータセンター外でバックアップをメンテナンスする必要がある企業にとって有益であり、災害復旧ではなくコンピューティングのシナリオで、お客様がレプリカを活用できるようにします。

Windows AzureにおけるSQL Server AlwaysOnサポートに関してさらに学ぶ

ドキュメント「High Availability and Disaster Recovery for SQL Server in Windows Azure Virtual Machines」(Windows Azure 仮想マシン内の SQL Server の高可用性と災害復旧) (英語 / 日本語 (機械翻訳) / 日本語 (現時点で未更新)) を読むことで、Windows AzureにおけるSQL Server AlwaysOnサポートの有効化方法に関してさらに学べます。また、TechEd 2013のプレゼンテーション「Microsoft SQL Server High Availability and Disaster Recovery on Windows Azure」(Windows AzureにおけるMicrosoft SQL Serverの高可用性と災害復旧) も確認してください。

SQL Server AlwaysOn可用性グループで実現される幅広いシナリオをサポートする最初のクラウド プロバイダーになれて、本当に興奮しています。我々は、これによって、お客様が多数の新しいシナリオに対応できると考えてます。

Windows Azure通知ハブ

本日、Windows Azure通知ハブの一般提供リリースを発表できて、興奮しています。通知ハブによって、数百万のWindows 8、Windows Phone 8、iOS、Androidのモバイル デバイスに対して、個人用に設定されたクロス プラットフォームのブロードキャスト プッシュ通知を即座に送信できるようになります。

1月の通知ハブの最初のプレビュー (英語 / 日本語) の際に、通知ハブについて最初にブログを書きました。最初のプレビュー以降、(Windows 8、iOSに加えて、Android、Windows Phoneのサポートを追加したことを含め) 多数の新機能を追加し、システムが次世代のアプリが必要とする任意のスケールに対応する準備ができていることを、検証してきました。

Windows Azureモバイル サービスと、(Windows Azureにホストされていないものを含む) すでに構築済みの他の任意のカスタム モバイル バックエンドの両方から、通知ハブを使えます。これによって、任意の既存アプリから活用し始めることが、本当に簡単になります。

通知ハブ: スケールする、個人用に設定されたクロス プラットフォームのブロードキャスト プッシュ

プッシュ通知は、モバイル アプリケーションの重要なコンポーネントです。これは、モバイル アプリ開発者が利用可能な、最も強力な顧客エンゲージメントの仕組みです。1人のモバイル ユーザーに対する1通のプッシュ通知メッセージの送信は、比較的単純です (そして、現在すでに、Windows Azureモバイル サービスを使って簡単に行うことができます)。しかし、数百万のモバイル ユーザーに対して、短い待機時間で同時にプッシュつ通知を送信し、ローカライズ、複数のプラットフォーム デバイス、ユーザー個人用設定といった現実の要件に対処することは、ずっと難しいものです。

Windows Azure通知ハブは、数百万のユーザーに対して個人用に設定されたクロス プラットフォームのプッシュ通知メッセージを効率的に送信するために役立つ、極めてスケーラブルなプッシュ通知インフラストラクチャを提供します:

  • クロス プラットフォーム。通知ハブを使うと、単一のAPI呼び出しで、自分のアプリのバックエンドから、Windowsストア、Windows Phone 8、iOS、Androidのデバイスを使っているユーザーに対して、プッシュ通知を送信できます。
  • 高度な個人用設定。通知ハブの組み込みテンプレート機能によって、通知の形式やロケールをクライアントに選択させながらも、バックエンドのコードをプラットフォーム非依存で本当にきれいなままにできます。
  • デバイス トークン管理。通知ハブは、プラットフォーム通知サービス (WNS、MPNS、Apple PNS、Google Cloud Messaging) が使うチャネルURIとデバイス トークンを格納、管理する必要から、自分のアプリのバックエンドを解放します。我々は、あなたに代わって、PNSフィードバック、デバイス トークンの有効期限などを、セキュリティで保護された方法で処理します。
  • 効率的なタグ ベースのマルチキャストとPub/Subルーティング。通知ハブへの登録時に、クライアントは1つ以上のタグを指定でき、それによって、通知におけるユーザーの一連のトピック (好きなスポーツやチーム、地理的位置、銘柄記号、論理ユーザーIDなど) に対する関心を表現します。これらのタグは、事前プロビジョニングや破棄を行う必要がなく、独自のユーザー別通知送信インフラストラクチャを実装する必要なしに、アプリから単一のAPI呼び出しで数百万のユーザー/デバイスに対して的を絞った通知を送信するための、極めて簡単な方法を提供します。
  • 極めてスケーラブル。通知ハブは、短い待機時間での数千から数百万のデバイスに対するプッシュ通知ブロードキャストを実現するために、最適化されています。自分のサーバー バックエンドが1通のメッセージを通知ハブに送信すると、アプリケーションのアーキテクチャ再設計やシャーディングを行う必要なしに、数千/数百万のプッシュ通知をユーザーに自動的に配信できます。
  • 任意のバックエンドから使用可能。通知ハブは、.NET SDK、Node.js SDK、使いやすいREST APIを使って、任意のバックエンド サーバー アプリに簡単に統合できます。通知ハブは、Windows Azureモバイル サービスで構築されたアプリとシームレスに連携します。また、Windows Azure仮想マシン (WindowsまたはLinux)、クラウド サービス、Webサイトにホストされたサーバー アプリからも、通知ハブを使えます。

Bingニュース: 数百万のデバイスにニュース速報を配信するために、Windows Azure通知ハブを使用

本日の一般提供リリース以前にも、多数の巨大アプリがWindows Azure通知ハブを使い始めていました。その1つが、すべてのWindows 8、Windows Phone 8デバイスに含まれているBingニュース アプリです。

Bingニュース アプリは、ユーザーにニュース速報を即座に通知する機能を必要としています。これは、いくつかの理由で困難な仕事です:

  • 極端なスケール: すべてのWindows 8ユーザーはニュース アプリをインストールしており、Bingニュースのバックエンドは、毎月、数億のニュース速報通知を配信する必要があります。
  • トピック ベースのマルチキャスト: 各ユーザーの関心をベースにした異なる市場へのプッシュ通知のブロードキャストには、効率的なPub/Subルーティングとトピック ベースのマルチキャスト ロジックが必要です。
  • クロス プラットフォームの配信: 通知の形式とセマンティクスはモバイル プラットフォーム間で異なり、すべてのモバイル プラットフォームにわたるチャネル/トークンの追跡は複雑になります。

Windows Azure通知ハブがBingニュースに最適であることが判明し、Bingニュース アプリの最も最近のアップデートで、毎日、数百万のWindows/Windows Phoneデバイスにプッシュ通知を配信するために、通知ハブを使うようになりました。

3

クライアント上のBingニュース アプリは、Windows 8向けのWindows Notification Service (WNS) とWindows Phone向けのMicrosoft Push Notification Service (MPNS) から適切なチャネルURIを取得し、それから、それをWindows Azure通知ハブに登録します。特定の市場向けのニュース速報を配信する必要がある際に、Bingニュース アプリは、通知ハブを使って、適切なメッセージをすべてのデバイスに即座にブロードキャストします。Bingニュース アプリは、通知ハブに対する単一のREST呼び出しで、トピック (スポーツのアップデートなど) に関心のあるユーザーを自動的にフィルターし、数百万のユーザーにメッセージを即座に配信できます:

4

Windows Azureは、Bingニュース アプリに代わって、複雑なPub/Subフィルタリング ロジックのすべてを処理し、短い待機時間でメッセージ配信を効率的に処理します。

最初の通知ハブの作成

通知ハブは、無料で毎月、500の登録デバイスに10万の通知を送信できる無料層をサポートしています。これは、使い始めるのを本当に簡単にします。

新しい通知ハブを作成するには、Windows Azure管理ポータルで、「新規」>「アプリケーション サービス」>「Service Bus」>「通知ハブ」を選択するだけです:

5

通知ハブの新規作成には1分もかからず、作成されたら、通知ハブのアクティビティのダッシュボード表示を確認するために、通知ハブに進めます。特に、ダッシュボードによって、通知ハブに登録済みのデバイス数、通知ハブにプッシュ済みのメッセージ数、通知ハブを介して配信に成功したメッセージ数、配信に失敗したメッセージ数を確認できます:

6

通知ハブを作成したら、「構成」タブをクリックして、通知ハブが連携する様々なプッシュ通知サービス (Windowsストア、Windows Phone、iOS、Android) 向けのアプリ資格情報を入力します:

7

そして、これで通知ハブを使う準備ができました!

デバイスの登録とブロードキャスト通知の送信

通知ハブを作成したので、デバイスのアプリを通知ハブに登録したいでしょう。これを行うのは本当に簡単です。Windows 8、Windows Phone 8、Android、iOS向けのデバイスSDKを提供しています。

「myTag」や「myOtherTag」タグ/トピックに送信されたブロードキャスト通知へのユーザーの関心を登録するために、C# Windows 8クライアント アプリで書くコードを、次に示します:

await hub.RegisterNativeAsync(channel.Uri, new string[] { "myTag", "myOtherTag" });

デバイスが登録されたら、自分のアプリ バックエンドがそのデバイスが登録したトピック/タグにメッセージを送信したときに、そのデバイスが自動的にプッシュ通知メッセージを受信します。Windows Azureモバイル サービス、カスタムの.NETバックエンド アプリ、Node.js SDKやREST APIを使う他の任意のアプリ バックエンドから、通知ハブを使えます。次のコードは、.NET SDKを使ったカスタムの.NETバックエンドから通知ハブへのメッセージ送信方法を示しています:

var toast = @"<toast><visual><binding template=""ToastText01""><text id=""1"">Hello everybody!</text></binding></visual></toast>";
await hub.SendWindowsNativeNotificationAsync(toast);

上のコードのような、自分のアプリのバックエンドからの単一の呼び出しによって、セキュリティで保護された方法で、通知ハブに登録された多数のデバイスに対してメッセージが配信されます。通知ハブは、配信するユーザー数に関係なく (ユーザー数が数千万であっても)、配信の詳細のすべてを処理します。

通知ハブのスケーリングと監視

アプリを構築したら、Windows Azure管理ポータルから直接、アプリを数百万ユーザーまで簡単にスケールさせることができます。管理ポータルで通知ハブの「スケール」タブをクリックして、サポートしたいデバイスとメッセージの数を構成するだけです:

8

また、容量のスケーリングに加えて、通知と通知のユーザーへの配信に関する、ほぼ50個の異なるメトリックを監視/追跡できます:

9

通知ハブに関してさらに学ぶ

通知ハブ サービスのページ (英語 / 日本語 (機械翻訳)) を使って、通知ハブに関してさらに学んでください。このページには、ビデオ チュートリアル、詳細なシナリオのガイド、SDKリファレンスへのリンクがあります。

2013年9月30日まで、すべてのWindows Azureサブスクライバーに対して通知ハブを無料で提供し続けます。2013年10月1日から、基本層と標準層で通知ハブに対する課金を開始する予定です。無料層は引き続き利用可能で、毎月無料で500個の登録デバイスに対して10万の通知をサポートします。

自動スケール: スケジュールされた自動スケール規則と、より高度なログ記録

今夏、Webサイト、クラウド サービス、モバイル サービス、仮想マシンを自動的にスケールできるようにする新しい自動スケールのサポートを、Windows Azureに導入しました。自動スケールによって、パフォーマンスとコストとの理想的なバランスを達成できるように、(手動介入の必要なしに) あなたに代わって動的にアプリケーションを自動的にスケールさせるように、Windows Azureを構成できるようになります。自動スケールを構成すると、自動スケールは、アプリケーションの負荷に応じて、稼働しているインスタンス数を定期的に調整します。

本日、時間でスケジュールされた規則を使ってクラウド サービスのインスタンス数を積極的に調整する機能を含む、自動スケールのさらなる機能を導入します。

スケジュール自動スケール規則

クラウド サービスの「スケール」タブをクリックすると、スケジュール規則をベースにした異なるスケーリング規則を構成/制御する機能を追加したことが分かるでしょう。

既定では、「スケジュールされた時間なし」に対するスケール設定を編集します。これは、日次に関係なく、スケール設定が常に同じであることを意味しています。「メトリックによるスケール」セクションで「なし」を選択することで、手動でスケールできます。これによって、なじみのある従来型のインスタンス数スライダーが表示されます:

10

あるいは、CPUアクティビティやキューの深さに反応することで、動的に自動スケールできます。次のスクリーンショットは、WebロールのCPUをベースにした自動スケール規則の構成を示しており、CPUの集計によって1から3のインスタンス数でスケールすることを示しています:

11

また、本日のリリースで、1日の異なる時間に対して、異なるスケール設定を設定できるようになりました。上の「スケジュール時間の設定」ボタンをクリックすることで、これを有効化できます。これによって、新しいダイアログが表示されます:

12

本日のリリースで、2つの異なる定期的なスケジュール (日中と夜間) を定義できる機能を提供します。1つ目のスケジュール「日中」は、一日の開始から一日の終了までです (ここでは、午前8時から午後8時と定義しました)。2つ目のスケジュール「夜間」は、一日の終了から一日の開始までです。両方のスケジュールは、一日の開始/終了を定義する時間とタイムゾーンのオプションを使います。そのタイムゾーンに夏時間が適用される場合、スケジュールは夏時間を順守します。今後、他の時間ベースのスケジュールも追加する予定です。

日中/夜間スケジュールを設定したら、「スケール」ページに戻り、スケジュールのドロップダウンに、作成済みの2つのスケジュールが含まれていることを確認できます:

13

リストから各スケジュールを選択し、そこでそのスケジュールの固有のスケーリング規則を編集できます。たとえば、日中スケジュールを選択し、クラウド サービス ロールのインスタンス数を5に設定し、それから、夜間スケジュールを選択し、インスタンス数を3に設定できます。これによって、Windows Azureが、日中は最大5インスタンスまでサービスをスケールさせ、夜間には3インスタンスまで減らすことが保証されます。

また、スケジュールされた自動スケール規則とメトリック ベースの自動スケール規則を組み合わせることもできます。CPUまたはキューのトグルを選択することで、日中または夜間に別々に適用される自動スケール規則を構成できます。たとえば、CPUアクティビティをベースにして、インスタンス範囲を日中は5から10に、夜間は3から6に設定できます。

本日のリリースでは、クラウド サービスに対してのみ、スケジュールされた自動スケール規則がサポートされています。しかし、近いうちに (Webサイト、モバイル サービス、仮想マシンを含む) すべてのコンピューティング リソースで、この機能を有効化する予定です。

自動スケールの履歴

サービスに対して自動スケールが何を行ったかを正確に知りログ記録することが、簡単になりました。本日のリリースでは、これを助けるための、4つの新しい自動スケール履歴機能があります。

まず、Windows Azureの操作ログ機能に、2つの新しい操作 (AutoscaleActionPutAutoscaleSetting) を追加しました。自動スケールがスケール アップ/ダウン アクションを行ったことを毎回記録し、「詳細」に新規/以前のインスタンス数を含めるようになりました。加えて、誰かが自動スケール設定を変更したことを毎回記録します。これを使って、チームの誰がいつ、自動スケールのオプションを変更したか確認できます。これらは両方とも、Windows Azure管理ポータルの新しい「管理サービス」ノードの「操作ログ」タブで公開されるようになりました:

14

また、クラウド サービスに対しては、過去7日間にわたるインスタンス数を示す履歴グラフも追加しました。次のように、1週間にわたる自動スケールの傾向を確認できます:

15

第3に、自動スケールが2時間以上失敗している場合、サブスクリプションのサービス管理者と共同管理者に電子メールで自動的に通知します:

16

第4に、あなたがサブスクリプションのアカウント管理者の場合、アカウントの通貨で自動スケールに関する課金情報をあなたに示します:

17

自動スケールが有効化されている場合は、現在のインスタンス数と最大インスタンス数との間の違いと、自動スケールを使うことでいくら節約したかを示します。

自動スケールが無効化されている場合は、自動スケールを有効化した場合にいくら節約できると予想されるかを示します。言い換えれば、今後、我々に支払う料金をいくら減らせるかに関する提案を含めるように、請求書をアップデートします (私の上司には、このことを言わないでください…(^_^) )。

仮想マシン: ロード バランサー プローブの構成のサポート

Windows Azureにデプロイされたすべての仮想マシン、クラウド サービス、Webサイト、モバイル サービスには、アプリのスケール アウトと高可用性の実現の両方に使える、組み込みのロード バランサーのサポートが付属しています。このロード バランサーのサポートは、Windows Azureに組み込まれており、追加料金なしで提供されています (他のほとんどのクラウド プロバイダーでは、ロード バランサーに対して追加料金が発生します)。

Windows Azureの本日のアップデートには、仮想マシンに対する負荷分散サポートの構成/管理をさらに簡単にする、いくつかの素晴らしい新機能が含まれています。また、仮想マシンが健全でありロード バランサーのルーティング先に含まれたままにされるべきであるかどうか判断するためにロード バランサーが使う、ネットワーク プローブ ロジックのカスタマイズのサポートも含まれています。

ロード バランサー プローブの理解

複数VMにわたるトラフィックのスケールアウトを実現し、(前述のSQL Server AlwaysOnセクションで議論したように) アプリのフロントエンドやバックエンドの仮想マシンの高可用性を実現するために、複数の仮想マシン インスタンスにわたるネットワーク トラフィックの負荷分散は、重要です。ネットワーク プローブは、Windows Azureロード バランサーが (ソフトウェア障害、またはハードウェア障害が原因の) 1つ以上の仮想マシン インスタンスの障害を検出する方法です。ネットワーク プローブが、特定の仮想マシン インスタンスに問題があることを検出した場合、健全な仮想マシン インスタンスにトラフィックを自動的にフェイルオーバーし、ユーザーがアプリケーションがダウンしていると思うことを防ぎます。

Windows Azureロード バランサーのネットワーク プローブに対する既定の構成では、アプリケーションが負荷分散しているのと同じポートに対して単にTCPを使います。次の例に示したように、負荷分散セット内の各仮想マシンは、パブリック インターネットからポート80でTCPトラフィックを受信します (恐らく、WebサイトやWebサービス)。単純なTCPプローブでは、ロード バランサーは、各仮想マシンの同じポートに、既定では15秒おきに継続的にメッセージを送信し、健全性を確認します。仮想マシンはWebサイトを稼働しているので、仮想マシンとWebサイトが健全な場合、仮想マシンは、ロード バランサーに対する単純なACKで、TCPプローブに自動的に返信します。このACKが続いている間は、ロード バランサーは、Webサイトが応答することを知っているので、トラフィックを送信し続けます。

Webサイトが健全ではないどんな状況でも、ロード バランサーはWebサイトからの応答を受信しません。これが発生した時には、ロード バランサーは、(次の図で「Virtual Machine 2」(仮想マシン2) と示されている) 問題のある仮想マシンへのトラフィックの送信を停止し、代わりに他の2つのインスタンスにトラフィックを向けます。VM内でネットワーク プローブに応答するための特殊なコードを何も書く必要なしに、この単純な高可用性オプションは動作し、アプリケーション、仮想マシン、または基になるハードウェアが原因の障害から保護できます (注: Windows Azureがハードウェア障害を検出した場合、我々は仮想マシン インスタンスを新しいサーバーに自動的に移行します)。

18

Windows Azureでは、各ネットワーク プローブ送信の時間間隔 (既定では15秒) とロード バランサーがインスタンスをオフラインにする前に失敗すべきプローブ試行数 (既定では2回) の両方を構成できます。従って、既定では、Webサイトからの応答が30秒間なかった後に、ロード バランサーはそれが応答しないと考え、後で健全な応答を受信するまで (プローブあたり15秒 * 2回のプローブ)、それに対するトラフィック送信を停止します。

また、より高度なオプションであるカスタムHTTPプローブも構成できるようになりました。HTTPプローブでは、ロードバランサーのネットワーク プローブ要求が、負荷分散しているネットワーク ポートとは別のネットワーク ポートに送信されるように構成できます (そして、このポートはインターネットに公開されている必要はありません。推奨は、ロード バランサーだけがアクセスできるプライベート ポートにすることです)。これは、サービスやアプリケーションがこの別のポートをリッスンし、アプリケーションの健全性をベースにしてプローブ要求に応答することを必要とします。HTTPプローブでは、ロード バランサーは、ネットワーク プローブ用要求に対してHTTP 200 OK応答を受信したら、仮想マシンにトラフィックを送信し続けます。前述のTCP間隔と同様に、既定では、仮想マシンが30秒間 (2回 * 15秒のプローブ)、HTTP 200 OKJで応答しなかった時に、ロード バランサーは、次のプローブで200 OKを受信するまで、自動的に仮想マシンをトラフィックのルーティング先から外します。この高度なオプションは、別のポートをリッスンして応答するためのコードの作成を必要としますが、サービスに配信されるトラフィックに対するずっと細かい制御を提供します:

19

ロード バランサー プローブ設定の構成

本日のリリース以前は、カスタムのネットワーク プローブ設定を構成するためには、PowerShellやクロス プラットフォームCLIツールを使うか、またはREST管理APIに対してコードを書く必要がありました。Windows Azureの本日のリリースでは、Windows Azure管理ポータルを使ってこれらの設定を構成するサポートも追加しました。

仮想マシンの新規または既存のエンドポイントに対して、負荷分散セットを構成できます。仮想マシンでエンドポイントを追加または編集することで、これを行えます。既存の仮想マシンでこれを行うには、管理ポータルでVMを選択し、そのVMの「エンドポイント」タブに進みます。それから、外部の呼び出し元に対してオープンしたいエンドポイントを追加または編集します:

20

「エンドポイントの編集」ダイアログで、インターネットにオープンされるポートの表示または変更が可能です (このダイアログは、本日のリリース以前にも存在していました):

21

このダイアログ内の「負荷分散セットの作成」または「負荷分散セットの再構成」チェックボックスを選択することで、負荷分散セットとネットワーク プローブのプロパティを表面化させる、ウィザードの別ページに進めるようになりました:

22

ネットワーク プローブ設定をTCPまたはHTTPベースに変更し、(ネットワーク プローブをプライベートにし、パブリック トラフィックに対応するために使うポートとは異なるポートを使いたい場合に) プローブしたい内部ポートを構成し、(既定では15秒ごとの) プローブ間隔を構成し、(既定では2回の) 仮想マシンがネットワーク ルーティング先から自動的に削除される前に失敗できるネットワーク プローブ回数を、この画面を使って構成できるようになりました。

ネットワーク プローブの問題の識別

また、Windows Azure管理ポータルの本日のリリースでは、ネットワーク プローブ設定を作成/編集できることに加えて、ネットワーク プローブが誤って構成されていたり、ネットワーク プローブに問題がある状況を表面化するようにもなりました。たとえば、仮想マシンのプレビュー期間中にVMを作成し、プローブが必須の構成項目になる前に負荷分散セットを構成していた場合、負荷分散セットが正しく構成されていないことを示すために、負荷分散セット名の列に、プローブ構成がないことを示すエラー アイコンを表示します:

23

操作ログと警告が、ポータルの「管理サービス」セクションに

以前は、「警告」と「操作ログ」のタブは、Windows Azure管理ポータルの「設定」拡張にありました。本日のリリースで、これらの横断的な管理/監視機能を、Windows Azure管理ポータルの「管理サービス」という新しい拡張に移動しました。その目的は、共有の管理サービスの発見可能性を高め、すべてのWindows Azureサービスにわたる横断的な機能のより良い分類を提供することです。我々は、今後のいくつかのリリースで、Windows Azureにおけるこういった横断的な機能の強化と追加を続けていく予定です。この変更が、以前に構成済みの既存の警告規則に影響を与えないことに注意してください。ポータルで表示される場所が変わっただけです。

24

操作ログへの追加

本日以前では、クラウド サービスとストレージに対する操作履歴を参照できました。今回のリリースで、次の追加領域に対する追加の操作履歴データを追加しました:

  • ディスク操作: 仮想マシン ディスクの追加と削除
  • 自動スケール: 自動スケール設定の変更、自動スケール アクション
  • 警告
  • SQLデータベースのバックアップ構成の変更

年内の今後のアップデートで、他のすべてのサービス/操作も含まれるように、この一覧に追加する予定です。

まとめ

本日のリリースには、さらに優れたクラウド ソリューションの構築を可能にする、多数の素晴らしい機能が含まれています。もしWindows Azureアカウントをまだ持っていない場合は、無料評価版に登録して、これらの機能すべてを今日から使い始めることができます。それから、Windows Azure開発者センターにアクセスして、アプリの構築方法についてさらに学んでください。

関連情報

コメント
  1. […] Infrastructure ServicesにおけるSQL Server可用性グループ (英語 / 日本語) のサポートを開始しました。この構成では、それぞれが独自のAzure […]

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中