クラウド サービスの基礎 - キャッシュの基本事項
このポストは、10 月 4 日に投稿された Cloud Service Fundamentals Caching Basics の翻訳です。
「Cloud Service Fundamentals (英語)」アプリケーション (別名「CSFundamentals」) は、データベースをバックエンドとする Azure サービスの構築方法を説明するためのものです。前回の「DAL – RDBMS のシャーディング」という記事では、データベース層を水平方向に拡張する「シャーディング」という技術について取り上げました。今回は、キャッシュの必要性や考慮すべき事項、Windows Azure での構成方法と実装方法について解説します。
分散キャッシュ アーキテクチャは拡張部分に構成されます。そこではもともと備わっているパーティショニング機能と共に、複数の (物理または仮想) マシンがクラスター リングの一部として協働しており、ワークロードを分散させています。キャッシュは <キー, 値> の検索パラダイムであり、値はシリアル化されたオブジェクトであるため、データベース内の複数のテーブルにまたがる JOIN などのような、非常に複雑なデータ保存処理の結果セットとなる可能性があります。そのため、データ ストアに対して処理を複数回行う代わりに、キャッシュに対してすばやいキー検索を実行します。
キャッシュの対象を理解する
まず始めに、ワークロードを分析し、適切なキャッシュ対象の候補を決定する必要があります。あらゆる時点のデータがキャッシュされますが、キャッシュと「真の情報源」との間に許容される「古さ」は、アプリケーションに受け入れられる範囲内である必要があります。一般的に、キャッシュは、ユーザー プロファイルやユーザー セッション (単一ユーザーの読み取りと書き込み) などの参照用 (すべてのユーザーの読み取り専用データ) に使用したり、リソース データ (ロック API を使用するすべてのユーザーによる読み取り/書き込み) に使用することができます。ただし、場合によっては、特定のデータセットがキャッシュ対象として適切でないことがあります。たとえば、特定のデータセットが急速に変化したり、アプリケーションが許容する古さの限度を超えていたり、トランザクションの実行が必要であったりする場合です。
容量を計画する
次に、アプリケーションに必要なキャッシュの容量を推測します。このとき、キャッシュ サイズだけでなく、一連の指標を調べて、開始時のサイズの目安を決定します。
- キャッシュ サイズ:必要なメモリ容量の概算には、オブジェクトのサイズとオブジェクトの数の平均値を使用できます。
- アクセス パターンとスループットの要件:読み取りと書き込みが混在している場合、新しいオブジェクトの作成、既存のオブジェクトのリライト、またはオブジェクトの読み取りが起きていることを示しています。
- ポリシー設定:Time-To-Live (TTL)、高可用性 (HA)、有効期限の種類、削除ポリシーを設定します。
- 物理リソース:外部メモリ、ネットワーク帯域幅、CPU 使用率も重要な要素です。ネットワーク帯域幅は特定の入力に基づいて推測することが可能ですが、ほとんどの場合はモニタリングを行い、その後、再計算用のベースとする必要があります。
処理能力の計画に役立つスプレッドシートを次のサイトに用意しましたのでご利用ください。https://msdn.microsoft.com/ja-jp/library/hh914129
Azure キャッシュ トポロジ
下の表に、Azure で使用可能な一連の PAAS オプションと簡単な説明を示します。
種類 |
説明 |
ロール内専用 |
専用トポロジで、キャッシュ専用の Worker ロールを定義します。これにより、Worker ロールの使用可能なメモリすべてが、キャッシュと動作オーバーヘッドに使用されることになります。 https://msdn.microsoft.com/ja-jp/library/windowsazure/hh914140.aspx |
ロール内共存 |
共存トポロジで、キャッシュのアプリケーション ロールで使用可能なメモリの割合 (%) を使用します。たとえば、各 Web ロール インスタンスでキャッシュに物理メモリの 20% を割り当てることができます。 https://msdn.microsoft.com/ja-jp/library/windowsazure/hh914128.aspx |
Windows Azure キャッシュ サービス |
Windows Azure キャッシュ サービスは、2013 年 9 月時点でプレビュー段階にあります。ご参考までに、以下の情報をご覧ください。 https://msdn.microsoft.com/en-us/library/windowsazure/dn386094.aspx (英語) |
Windows Azure 共有キャッシュ |
マルチテナント型のキャッシュ (スロットルとクォータを含む) であり、2014 年 9 月までに廃止される予定です。詳細については、https://www.windowsazure.com/ja-jp/pricing/details/cache/ をご確認ください。キャッシュの活用には、上記のいずれかのオプションを使用されることをおすすめします。 |
実装の詳細
CSFundamentals アプリケーション (英語) では、ロール内専用の Azure キャッシュを使用することで、ユーザーのプロファイルやコメントといった頻繁にアクセスされる情報を効率よく読み取れるようにしています。ロール内専用の実装を行うと、キャッシュ関連のワークロードが隔離されるため、この方法がおすすめです。また、パフォーマンス カウンター (CPU 使用量、ネットワーク帯域幅、メモリなど) で監視できるため、キャッシュ ロールのインスタンスが適切にスケーリングされます。
注: 新しい Windows Azure キャッシュ サービスは、CSFundamentals の実装中は使用できませんでした。これは、キャッシュされたデータを CSFundamentals アプリケーションの外部で使用できるようにする必要があった場合に、その方が好都合であったためです。
ICacheFactory インターフェイスにより GetCache メソッドのシグネチャが定義されます。ICacheClient インターフェイスにより GET<T> メソッドと PUT<T> メソッドのシグネチャが定義されます。
public interface ICacheClient
AzureCacheClient はこのインターフェイスを実装したものであり、Windows Azure キャッシュのクライアント アセンブリへの参照があります。これは、Windows Azure キャッシュ NuGet パッケージによって追加されたものです。
DataCacheFactory オブジェクトを作成すると、キャッシュ ロール インスタンスに対してリソース消費量の多い接続が確立されるため、static として定義され、Lazy<T> (機械翻訳) を使用して遅延インスタンス化されます。
app.config では自動検出が有効になっており、識別子を使用してキャッシュ Worker ロールが正しく示されています。
<autoDiscover isEnabled="true" identifier="CSFundamentalsCaching.WorkerRole" />
注: 新しい Windows Azure キャッシュ サービスを使用するようにソリューションを変更するには、identifier 属性を、Windows Azure ポータルで作成したキャッシュ サービスのエンドポイントに置き換えます。さらに、API キー (ポータルの Manage Keys オプションから取得可能) を app.config の 'messageSecurity authorizationInfo' フィールドにコピーする必要があります。
GET<T> メソッドと PUT<T> メソッドの実装では BinarySerializer クラスが使用され、そのクラスが次に Protobuf クラスを利用してシリアル化およびシリアル化解除を行います。protobuf-net はプロトコル バッファー (英語) の .NET 実装であり、.NET オブジェクトのシリアル化を効果的かつ容易に行えます。これは protobuf-net NuGet パッケージにより追加されました。
シリアル化により、パラメーター T が渡される byte[] 配列が生成され、それが Windows Azure キャッシュ クラスターに格納されます。特定のキーにより要求されたオブジェクトを返すために、GET メソッドでは Deserialize メソッドが使用されます。
このブログでは、キャッシュの基本事項についてご紹介しました。さらに詳しい情報については、CloudServiceFundamentals Visual Studio ソリューション (英語) の ICacheClient.cs、AzureCacheFactory.cs、AzureCacheClient.cs、BinarySerializer.cs を参照してください。