8月, 2011 のアーカイブ

Windows Azure上のMemcached

Posted: 2011/08/31 カテゴリー: Uncategorized
タグ:, , , ,

Steve Marxが、2つのNuGetパッケージ (WazMemcachedServerWazMemcachedClient) を公開しました。これらのパッケージによって、Windows Azureの動的スケーリング、インプレース アップグレード、耐障害性を活用して、Windows AzureアプリケーションにMemcachedを追加することが、驚くほど簡単になります。

なぜMemcachedか?

Windows Azureは、組み込みの分散キャッシュ ソリューション (Windows Azure AppFabric Caching) を提供しています。これは、Windows Azureアプリケーションにキャッシュを簡単に追加したい.NET開発者にとって、優れた選択肢です。しかし、Memcachedを使いたいというお客様からの声を聞いています。

特にMemcached向きと思われるシナリオは、既存のRAMの再利用です。たとえば、Webロール インスタンスに使っていないRAMがある場合、Webロール インスタンスにMemcachedを追加すると、追加のVMなしで (つまり、追加コストなしで) インメモリー キャッシュを使うことができます。Windows Azure AppFabric Cachingは素晴らしい「ローカル キャッシュ」オプションを提供していますが、このオプションを使うには、リモート キャッシュがプロビジョニングされている必要があり、ローカル キャッシュは共有されない (インスタンスごとである) ことに注意しましょう。

Memcachedを選択する他の理由は、キャッシュを手動チューニングできることです。これは「気弱な人」向けではありませんが、すでに自身の特定のワークロードに対してMemcachedのチューニング (おそらく、キーごとの最小領域の変更) を行うエキスパートである人々にとっては、これは素晴らしい選択肢です。

どのように動作するか?

サーバーサイドの実装は単純で、内部エンドポイントをリスンするMemcachedを起動するだけです。クライアントサイドでは、多少の作業が行われます。クライアントには、達成したい2つの目標があります。

  • サーバーの追加/削除時の中断を最小化する、コンシステント ハッシュ法を使うこと
  • (スケーリング、アップグレード、障害の際の) クラスターに対するサーバーの追加/削除時に、自動的に対応すること

既定でコンシステント ハッシュ法を使う「Enyim Memcached Clientをベースにソリューションを構築することで、第1の目標は達成されます。第2の目標は、WindowsAzureServerPoolというカスタムIServerPool実装という形で、Enyimを拡張することを意味しています。このコードは、新たに追加/削除されたWindows Azureインスタンスを定期的に探し、Memcachedクライアントを自動的に再構成します。重要なのは、このコードが、新規Windows Azureインスタンスが初めて追加されたときに、すぐにそれを使おうとはしないことです。新規インスタンスをキャッシュ サーバーとして使うおうとする前に、そのインスタンスが接続を受け入れるまで待機します。

このパッケージは、Channel 9が使っているコードをベースにしています。助けてくれたChannel 9チームのMike Sampsonに、大きく感謝します。

サーバーの設定

任意のロール (Webロール、ワーカー ロール) で、Memcachedを実行できます。高負荷の分散キャッシュでは、おそらくキャッシュ専用のワーカー ロールを作成するでしょう。しかし、多くのWebアプリケーションでは、単にWebロールにMemcachedを追加するでしょう。どちらの場合でも、Memcachedを稼働させるための3つの手順があります。

1. NuGetを使って、WazMemcachedServerパッケージをインストールします (パッケージ マネージャー コンソールから、install-package WazMemcachedServerを実行します)。これによって、Memcachedバイナリ (Couchbaseの1.4.5 Windowsバイナリ) と、それを起動するための小さなヘルパー クラスが追加されます。

2. Memcachedがリスンするための、内部TCPエンドポイントを作成します (通常は、これを「Memcached」と命名します)。Visual StudioのUIを通して (ロールをダブル クリックし、左側の「エンドポイント」を選択して)、またはServiceDefinition.csdefに直接追加することで、これを行います。

3. Memcachedプロセスを起動し監視するコードを、WebRole.csまたはWorkerRole.csに追加します。

Process proc;
public override void Run()
{
    proc.WaitForExit();
}

public override bool OnStart()
{
    proc = WindowsAzureMemcachedHelpers.StartMemcached("Memcached", 512);
    return base.OnStart();
}

第1パラメーターは、手順2で作成したエンドポイント名です。第2パラメーターは、Memcachedで使いたいRAMの容量 (MB単位) です。このRunメソッドは、Memcachedプロセスの終了を (できれば永久に) 単に待機していることに注意しましょう。これによって、Memcachedがクラッシュすると、ロール インスタンスも停止し、Windows Azureがあなたに代わってすべてを再起動してくれます。ロールのRunメソッドで他のことを行っている場合は、代わりに、プロセスのExitedイベントを使ってプロセスのクラッシュに対応したいでしょう。

この時点で、ロールのすべてのインスタンスで、Memcachedが稼働し、内部エンドポイントをリスンしています。

クライアントの設定

コードからMemcachedサーバーのクラスターを利用するためには、スケーリングやアップグレードのためにMemcachedサーバー インスタンスが増減しても、それを見つける方法を知っているクライアントが必要です。その設定は簡単です。

1. install-package WazMemcachedClientで、WazMemcachedClientパッケージをインストールします。これによって、設定したMemcachedサーバーを発見して使うためにEnyim Memcached Clientを拡張する、いくつかのクラスが追加されます。

2. コードで、Memcachedと対話するためにアプリケーション ライフサイクル中に再利用するMemcachedClientを作成します。Webアプリケーションでは、ASP.NET MVCコントローラーのstatic変数に、MemcachedClientを格納します。

static MemcachedClient client = WindowsAzureMemcachedHelpers.CreateDefaultClient
    ("WorkerRole", "Memcached");

第1パラメーターは、Memcachedが稼働するロール名です。第2パラメーターは、Memcachedがリスンしている内部エンドポイント名です。クライアントを初期化する素晴らしい場所としては、他にApplication_Startがあります。

Application["memcached"] = WindowsAzureMemcachedHelpers.CreateDefaultClient("WorkerRole", "Memcached");

すると、コード内のどこからでも、Application["memcached"]を使ってクライアントにアクセスできます。

一度これら2つの手順を行うと、Memcached操作を実行するために、作成済みのMemcachedClientを使用できます。たとえば、次の通りです。

string value = client.Get(key) as string;
if (value == null)
{
    value = FetchFromStorage(key);
    client.Store(StoreMode.Set, key, value);
}
return value;

ダウンロード

NuGetパッケージはソース コード形式なので、2つのNuGetパッケージをインストールすることで、コード全体を読むことが (そして、変更を加えることが) できます。

関連情報:

広告

Windows Azure (英語 / 日本語) でクラウドに向かうための技術的な検討事項の詳細を探しているなら、Microsoft patterns & practicesによる次の優れた書籍をご確認ください。詳細情報については、各書籍をクリックしてください。

“A Guide to Claims-based Identity and Access Control”

「クレーム ベース ID およびアクセス コントロールのガイド」

認証について考慮する必要がない世界を想像してみてください。アプリケーションへのすべての要求の中に、アクセス コントロールを決定したり、ユーザーに合わせてアプリケーションをパーソナライズするために必要な情報が含まれている世界を。これは、『クレーム ベース ID およびアクセス コントロールのガイド』で説明されているクレーム ベース ID による理想的な世界です。クレームは、ユーザーを認証および承認するアプリケーションを構築してくれる革新的な方法です。

“Moving Applications to the Cloud on the Microsoft Windows Azure Platform”

「Microsoft Windows Azure プラットフォームでのクラウドへのアプリケーションの移行」

この書籍では、Adatum 社という名前の架空の会社の移行シナリオについて説明します。Adatum 社は、自社の経費追跡/経費精算システムを Windows Azure に展開するために、段階的な手順を踏んで変更を行っています。各章では、認証と承認、データ アクセス、セッション管理、展開と開発のライフサイクル、コスト分析といった、異なる考慮点を取り上げます。

“Developing Applications for the Cloud on the Microsoft Windows Azure Platform”

「Microsoft Windows Azure プラットフォームでのクラウド用アプリケーションの開発」

この書籍は、最新バージョンの Windows Azure ツールと最新の Windows Azure プラットフォーム機能を使用して、クラウドで実行されるマルチテナントの SaaS (サービスとしてのソフトウェア) アプリケーションを一から作成する方法を説明します。

“Windows Phone 7 Developer Guide”

「Windows Phone 7の開発者向けガイダンス」

Windows Phone 7 アプリケーションを、社内のサービスやアプリケーション、またはクラウド (Windows Azure テクノロジ プラットフォームを使用するものなど) で実行されるリモートのサービスやアプリケーションと組み合わせることにより、開発者は、従来のデスクトップまたはラップトップの機能を超えてポータブルおよびさらにアクセスしやすい環境まで強化した、拡張性と信頼性がはるかに高い、強力なアプリケーションを作成できます。

関連情報:

 

Nathan Tottenは、ブログ ポスト「Windows Azure Accelerator for Web Roles Version 1.1」で、Windows Azure Accelerator for Web Rolesのアップデートのリリースを発表しました。このアクセラレータによって、Web配置 (Web Deploy) を使って、複数インスタンスのWindows Azure WebロールにWebサイトを30秒以下でデプロイ可能になります。今回のアップデートでは、ロギングの改善やWindows Azure CDNのサポートなどの新機能を追加し、アクセラレータで動作するサイトのテストをより簡素化しました。加えて、MVC3とPHPのサポートが既定で有効化されたため、バイナリのデプロイやスタートアップ タスクの構成を心配する必要がなくなりました。ASP.NET、MVC、PHPのサイトをWindows Azure上でテストしデプロイするのがどれだけ簡単か確認するために、今すぐお試しください。

Windows Azure Accelerator for Web Rolesのダウンロードは、こちらから

詳細情報は、Nathanのブログ ポストをお読みください。

関連情報:

SQL Azureの2011年7月サービス リリースが展開されつつあるため、アプリケーション ロジックに対する重要な考慮点についてアドバイスしたいと思います。アプリケーションがSQL Azureに接続しているか、SQL Serverの他のエディションにに接続しているかを判断するために、プログラム的に確認しているお客様がいるかもしれません。サーバーのバージョン番号はアップグレードやサービス リリースによって変更されるので、アプリケーション ロジックがバージョン番号に基づかないようにすべきであることに、注意してください。ただし、ロギングの目的でバージョン番号を使うことは、問題ありません。

SQL Azureに接続しているかどうか確認したい場合、次のSQL文を使います。SQL Azureは「5」を返します。

  • SELECT SERVERPROPERTY(‘EngineEdition’)

SQL Azureのオンライン ドキュメントで、SERVERPROPERTY関数の完全な説明 (英語 / 日本語) をご覧ください 。

現在のSQL Azureサービス リリースは、SQL Azureデータベース エンジンのバージョンを10から11にアップグレードします。このサービス リリースは、データセンターに展開されつつあります。

今回のサーバー バージョン番号の変更は、次のサーバーサイドAPIで確認できます。

  • SELECT SERVERPROPERTY(‘ProductVersion’)
  • SELECT @@VERSION

次のクライアントサイドAPIでも、確認できます。

  • ODBC: SQLGetInfo (SQL_DBMS_VER)
  • SqlClient: SqlConnection.ServerVersion

サービス アップグレードの期間中 (数日間)、あるユーザー セッションがバージョン 10.25.bbbb.bb のSQL Azureに接続し、別のユーザー セッションがバージョン 11.0.bbbb.bb のSQL Azureに接続することがあります (bbbb.bb はビルド番号)。1つのデータベースに対するユーザー接続が、接続ごとに異なるバージョン番号となる可能性があります。アップグレード終了後には、すべてのセッションはバージョン 11.0.bbbb.bb のSQL Azureに接続します。

ユーザーのクエリやアプリケーションは、通常通り機能し続け、アップグレードによって悪影響を受けることはありません

2011年7月サービス リリースは根本的であり、全体的なパフォーマンスとスケーラビリティを向上するために設計された、基盤のエンジンの重大なアップグレードも含まれています。今回のアップグレードは、クラウドのSQL AzureサービスとSQL Serverの次期バージョン (コードネーム「Denali」) との間で、共通の基盤と機能セットを提供するための大きな第一歩でもあります。詳細情報は、ブログ ポスト「Announcing: SQL Azure July 2011 Service Release」(日本語訳「SQL Azure 2011年7月サービス リリース」) をお読みください。

関連情報:

Nathan Tottenの最新のブログ ポスト「Windows Azure Toolkit for Social Games & Tankster Version 1.0」で、「Windows Azure Toolkit for Social Games」とサンプル ゲーム「タンクスター」(Tankster) の最新版のリリースを発表しました。今回のリリースでは、いくつかの新機能を追加し、サーバーAPIのパフォーマンスと安定性を改善し、サンプル ゲームのユーザー インタフェースの多くを改善しました。このツールは、開発者の皆さんが、短時間、低コストで異なるデバイスに対して優れたゲームのエクスペリエンスを構築することを、より簡単にします。

Windows Azure Toolkit for Social Gamesを、ここからダウンロードしてください。

関連情報:

より柔軟で簡単な課金体系をお客様に提供するため、2011年10月1日より、Windows Azure Platformに2つの課金関連のアップデートを行います。

まず、XS (Extra Small) サイズのコンピューティング インスタンスの価格を、20%引き下げます。さらに、すべてのプランに対するコンピューティングの割り当てが、S (Small) サイズのコンピューティング時間に簡素化されます。お客様に柔軟性を提供するために、Sサイズのコンピューティング時間は、Sインスタンス 1時間あたり、XSインスタンス 3時間の比率で、XSインスタンスにも利用可能です。お客様は、プランで決められている所定の標準的な比率で、Sサイズのコンピューティング時間を、他のサイズにも活用可能です。さらに、現在、導入特別プラン (Introductory Special) をお使いのお客様、および10月1日より前に導入特別プランを契約したお客様は、プランの拡張に先立って最高の価値と柔軟性を得られるように、8月と9月に、XSサイズのコンピューティング時間 750時間とSサイズのコンピューティング時間 750時間をご利用いただけます。

プランごとの、コンピューティングの割り当ての詳細は、次の通りです。

 

10月1日以前

10月1日以降

プラン

XS

S

XS

S

XSで相当
する時間

導入特別 (*)

750

750

750

2250

Cloud Essentials

750

25

375

1125

MSDN Professional

750

375

1125

MSDN Premium

1500

750

2250

MSDN Ultimate

1500

1500

4500

(*) 8月1日に、導入特別プランに含まれるSサイズのコンピューティング時間を、25時間から750時間に増やしました。8月と9月の間は、導入特別プランをお使いのお客様は、XSサイズのコンピューティング時間 750時間とSサイズのコンピューティング時間 750時間の両方をご利用いただけます。Sサイズのコンピューティング時間とXSサイズのコンピューティング時間が交換可能になる10月1日以降は、導入特別プランは、Sサイズのコンピューティング時間 750時間のみを提供します。

また、2つのゾーン (ゾーン1、ゾーン2) のみを使うように、データ転送の測定を簡素化します。このゾーン測定システムは (複数の地域を含み、標準のデータ転送とCDNの測定を分離していた) 現在の測定システムを簡素化します。ヨーロッパと北米のデータ センターは、ゾーン1としてレポート/課金されます。それ以外の地域は、ゾーン2に分類されます。今回の変更は、お客様がデータ転送を監視し、課金を理解することを簡単にします。送信 (アウトバウンド) データ転送に対するGBあたりの価格は、変更されません。また、お客様は、プランに含まれているデータ転送量を使って、CDNデータ転送を活用する柔軟性を得られます。9月と10月にまたがる課金期間では、現在の地域別の測定と、新しいゾーン1、ゾーン2の測定の両方が、請求書に現れます。

今回の変更は、簡単で柔軟な方法で世界クラスのサービスをお客様に提供するという、我々の継続的な取り組みの一部です。

関連情報:

Q&A:

質問:同じゾーンに属するデータセンター間 (たとえば、北米のシカゴとヨーロッパのダブリン) のデータ転送量は、無料になりますか?

回答:なりません。データセンター間通信のデータ転送量課金に関する変更はありません。たとえば、シカゴで稼働するアプリケーションが、ダブリンのBLOBストレージから巨大なファイルをダウンロードする場合、ダブリンに対して、送信 (アウトバウンド) のデータ転送量課金が発生します。シカゴに対しては、受信 (インバウンド) のデータ転送量がありますが、受信データ転送は無償です!

 

我々は、Windows Azure Storage Analytics (ストレージ アナリティクス) を発表します。この機能は、Windows Azureストレージ (BLOB、テーブル、キュー) の利用を追跡、分析、デバッグできる機能を、開発者と運用担当者に提供します。アプリケーション設計やアプリケーションのWidnows Azureストレージへのアクセス パターンを改善するために、このデータを使ってストレージの利用を分析できます。分析データは、次のものから構成されます。

  • ログ:実行されたBLOB、テーブル、キューに対するリクエストのトレースを提供
  • メトリック:BLOB、テーブル、キューに対する主要な容量とリクエストの統計のサマリーを提供

ログ

この機能は、特殊なコンテナー $logs 内のブロックBLOB (英語 / 日本語) として、ストレージ アカウントに対して実行されたすべてのリクエストのトレースを提供します。BLOB内の各ログ エントリーはサービスに対するリクエストに対応し、リクエストID、リクエストURL、リクエストのHTTPステータス、リクエスト元のアカウント名、所有者のアカウント名、サーバーサイド レイテンシー、E2E (エンド ツー エンド) レイテンシー、リクエストのソースIPアドレスなどを含んでいます。

このデータによって、リクエストをずっと詳細に分析できるようになります。このデータを使って、次の種類の分析を実行できます。

  • アプリケーションで、得意帝のIPアドレスの範囲からの匿名リクエストがいくつあるか?
  • どのコンテナーが、最も多くリクエストされているか?
  • 特定のSAS (共有アクセス署名) (英語 / 日本語) URLが、何回、どのようにアクセスされているか?
  • コンテナーを削除するリクエストを、誰が発行したか?
  • 遅いリクエストに対して、どこで時間が消費されているか?
  • ネットワーク エラーが発生したとき、リクエストがサーバーに届いたか?

メトリック

メトリックは、ストレージ アカウントのBLOB、テーブル、キューに対する主要な統計のサマリーを提供します。この統計は、次のものに分類されます。

リクエスト情報リクエスト数、平均サーバー サイド レイテンシー、平均E2Eレイテンシー、平均帯域幅、全成功リクエスト、全失敗リクエストなどの、1時間ごとの集計を提供します。これらのリクエスト集計は、サービスのレベル、(その1時間にリクエストされたAPIに対しては) APIのレベルで提供されます。これは、BLOB、テーブル、キュー サービスで利用可能です。

容量情報サービスが消費した領域、サービス内に格納されているコンテナ数やオブジェクト数に関する、1日ごとの統計を提供します。これは、Windows Azure BLOBサービスに対してのみ提供されていることに注意してください。

すべての分析ログとメトリック データはあなたのストレージ アカウントに格納され、通常のBLOBとテーブルのREST API (英語 / 日本語) でアクセス可能です。Windows Azureで稼働しているサービスからも、HTTP/HTTPSリクエストを送受信できる任意のアプリケーションから直接インターネット経由でも、ログとメトリックにアクセス可能です。サービスのレベルで機能を有効化/無効化するREST APIを呼び出すことで、ログ データ、メトリックデータの両方または一方を格納することを選択できます。いったん機能が有効化されると、Windows Azureストレージは、分析データをストレージ アカウントに格納します。ログ データは、特殊なBLOBコンテナーにWindows Azure BLOBとして格納され、メトリック データは、Windows Azureテーブルの特殊なテーブルに格納されます。このデータの管理を簡素化するために、BLOBとテーブルの分析データを自動的にクリーン アップする保有ポリシーを設定できる機能を提供しています。

詳細情報については、次のリンクを確認してください。

関連情報: