最新の Redis Cache については「Azure Redis Cache の使用 (.NET, PHP, Node.js)」に記載しました。(これは、古い記事です。)
関連ナンバー
- Windows Server AppFabric Cache v1.0
- Cache 機能一覧
- Azure Shared Cache
- Windows Server AppFabric Cache v1.1 (新機能紹介)
- Azure Role-based Cache
- New Azure Cache (留意点)
こんにちは。
今回は Azure セミナーの補足の 2 つ目として、デモを飛ばした最新の Windows Azure Cache (Preview) について以下に補足しておきます。
概要 (事前説明)
Windows Azure では、これまで、Windows Azure Shared Cache、Windows Azure Role-based Cache とありましたが、今回は 3 世代目の Cache になります。(すでに登場して随分とたちます…)
セミナーでご説明した通り、新しい Cache では、Windows Azure Cloud Services だけでなく Windows Azure Virtual Machines、Windows Azure WebSites などでも使える点や、パフォーマンスの向上などいくつかのメリットがあります。
使い方 (セットアップと開発) も従来とほぼ同じ概念で、既にインターネット上にもセットアップやプログラミング方法などが多数載っていますので参照してください。(ブチザッキさんの「Windows Azure Cache Service (Preview)を使ってみる」ではレイテンシー評価なども含めて書かれています。)
.NET (VB/C#) から使用する場合、大雑把に記述すると以下の手順で利用します。(.NET 以外については後述します。)
- Windows Azure Management Portal の [新規] – [データサービス] – [CACHE] を選択して Cache Service を作成します。
- Visual Studio で Web アプリケーションを新規作成し、NuGet で Microsoft.WindowsAzure.Caching パッケージをインストールします (必要なライブラリーのインストールと、Web.config の追加がおこなわれます)
- Web.config を変更します (接続先の endpoint と authorizationInfo を設定します。authorizationInfo は、作成した Cache Service の [Manage Kyes] ボタンで取得できます。)
- コードを記述します (「Windows Azure Role-based cache」と同様です)
機能一覧は「MSDN : Windows Azure Cache Service (Preview) Features」に記載されている通りです。
ほぼ、これまでの機能を踏襲しており、Azure 版では Windows PowerShell などの管理 API が提供されていない点も従来通りです。
機能 | Server AppFabric cache | Azure cache |
---|---|---|
Region / Tags | Y | Y |
Version | Y | Y |
Local Cache | Y | Y |
通知 (Notification) | Y | Y |
HA (High Availavility) | Y | Y |
Windows PowerShell による管理 | Y | N |
Cache Through (Read Through / Write Behind) | Y | N |
Memcache protocol | N | Y |
なお、Cache Service の作成時に (上記の 1 で)、Basic、Standard、Premium の各 OFFERING 情報を選択できますが、通知 (Notification) や HA (High Availability) は、この選択によって使用可否が決まるので注意してください。(例えば、下図は、Premium の場合の Cache 作成画面です。後述しますが、あとから、この OFFERING を変更できます。)
今回は、この Cache について、いくつかセミナーで説明できなかった注意点 (補足) を記載します。
スケール変更の際の注意
新しい Cache の大きなメリットの 1 つとして、アプリケーションの配置後、下図のように Azure Portal を使ってスケールの変更が容易に可能な点です。(Expiry Policy や Eviction なども変更できます。)
Cache Service の作成時に下記の OFFERING (Basic, Standard, Premium) を設定し、この OFFERING の内容によって割り当て可能なメモリー量が異なります。
そして、この OFFERING の設定も変更可能です。キャパや機能が不充分になってきたら、アプリケーションを配置したままで、新しい契約 (OFFERING) に変更できます。(もちろん利用料金にも反映されますが。。。)
- Basic :
128MB – 1GB - Standard :
1GB – 10GB - Premium :
5GB – 150GB
さて、この変更ですが、いくつか「癖」があるので注意してください。
例えば、「Scale a Cache for Windows Azure Cache Service (Preview)」に記載されているように、OFFERING を変更した場合は、Cache 上のアイテムが すべてクリアされます。(Scale の変更時は残ります。しかし、実際に動かしていただくとわかりますが、Eviction により、多くは消えてしまいますが。。。)
以前も記載しましたが、Cache を使う際は、そもそも揮発的であることを想定してプログラミングすべきなので多くの場合は問題とならないでしょう。しかし、例えば、特定の Named Cache のアイテムを揮発せずに持続させているような場合を考えてみましょう。(Expiry policy を Never、Eviction を Disabled にした場合、持続します。なお、この設定は推奨はされていません。) この場合であっても、OFFERING を変えると、アイテムはすべてクリアされてしまいます。
また、ドキュメントに依ると、OFFERING の変更時は、更新 (Update) 完了後に Server の Switch が発生すると書かれています。これにより、一時的な寸断が発生したり、プログラムの書き方によっては接続に問題が生じるケースもあるので注意が必要です。
例えば、通常、DataCacheFactory や DataCache の再作成はオーバーヘッドとなるため、「Windows Azure Role-based caching」で紹介したソースコードのように DataCache を単一サーバー上で再利用する場合が多いでしょう。(下記にコードを抜粋しておきます。) 今回の件に限ったことではありませんが、こうしたコードにおいても、ちゃんと Retry ロジックを入れておかないと、OFFERING 変更の際に、保持している DataCache が無効となり、Cache の操作の際に Exception が発生することになるでしょう。
. . .private static DataCache _mycache = null;internal DataCache MyCache{ get {if(_mycache == null){ var factory = new DataCacheFactory(); _mycache = factory.GetDefaultCache();}return _mycache; }}. . .
他にも、一度に 2 段階以上に下げることはできない (段階的に下げていく必要がある) といった点も注記されています。(例えば、384 MB から 128 MB に変更する場合は、いったん 256 MB に変更してから 128 MB に変更します。)
いろいろと留意点が多いので、スケール変更は慎重に計画したほうが良いでしょう。
移行時の注意
Windows Azure Shared Caching パッケージなど、古い Cache client のライブラリーを使用している場合は、無論、ライブラリーを入れなおす必要があります。しかし、新しい Windows Azure Cache では、以前の Windows Azure Role-based Cache などでも使用していた Microsoft.WindowsAzure.Caching パッケージをそのまま使用するため、一般には、移行に際してライブラリーの入れ替えは不要です。(Web.config の構成のみ変更すれば充分です。)
ただし、ここにも注意点があります。
MSDN のドキュメントを見ると書いていますが、今回の Cache では、Microsoft.WindowsAzure.Caching の Version 2.1.0.0 以上を使用する必要があります。(以前のライブラリーは、Autodiscover で占有型の Cache を探しに行きません。)
例えば、v2.0 の client (Microsoft.WindowsAzure.Caching) を使用すると、以下のエラー (ErrorCode<UnspecifiedErrorCode>:SubStatus<ES0001>:The role <endpoint name> was not found in the current deployment.) が発生します。
もし、こうしたエラーが表示される場合には、ライブラリー (Microsoft.WindowsAzure.Caching パッケージ) を新しいバージョンに変更してください。
Memcache protocol サポートに関する注意
.NET 以外のプログラミング言語を使用している方にとっては、この Memcache protocol サポート は気になるところでしょう。(セミナーで説明したように、オープンソース系のライブラリーから接続可能になります。)
以前、「Windows Azure Role-based Cache」で記載したように、Memcached サポートには、Server 側の wire protocol のサポートと、client 側の shim を使ったサポートの 2 種類の方法があります。そして、「MSDN : Run your Memcache app with Windows Azure Cache Service (Preview)」に書かれているように、新しい Windows Azure Cache では双方がサポートされる予定です。
ただし、ScottGu の Blog Comment にも書いていますが、現在の Preview 段階では memcache wire protocol は実装されておらず、shim (Windows Azure Cache Memcache Shim) を使用した方法しかサポートされていないので注意してください。
Azure Websites や IaaS などから memcache を介して使用する場合は、GAを待ってください。
Categories: Uncategorized
6 replies»