インスタンスのキャッシュとキャッシュ管理

これは、シリーズ「AtContent.comサービスの内部構造とアーキテクチャ」の3番目の記事です。 ここから、Windows Azureプラットフォームを使用するときに、Azure Table StorageとAzure Blob Storageの呼び出し回数を減らす方法と理由を学習できます。 私たちのサービスでは、著者が出版物を投稿し、さまざまなサイトに埋め込まれます。 したがって、公開されたコンテンツが多数のリソースに表示されると、サービスを通じてこれらのサイトに配信されます。 したがって、Azureストレージへのアクセス数を減らすために、インスタンスストレージのパブリケーションキャッシュを使用します。これには追加料金はかかりません。



また、この記事では、アプリケーションのインスタンスが複数ある場合にキャッシュを管理する方法と、インスタンス間でキャッシュの状態を同期する方法について質問します。

画像





まず、Windows Azureのすべてのアプリケーションデータは、アプリケーションまたはサービスインスタンスの外部に保存する必要があります。ロールがリロードされると、インスタンスストレージ内のすべてのデータが失われるためです。 現在、サービスは非常にアクティブな開発段階にあり、展開は非常に頻繁に行われる必要があるため、これは平均して1〜2日ごとに発生します。 したがって、最も効果的なソリューションは、このデータをAzure Table StorageやAzure Blob StorageなどのAzureストレージに配置することです。 ただし、このストレージを使用する操作ごとに料金がかかります。 それほど大きくはありませんが、Azureストレージにアクセスするコストを削減したいと考えています。



キャッシュの導入により、Azureストレージの運用コストを大幅に削減することができました。 そのため、パブリケーションを表示すると、Azureストレージから初めて選択され、その後キャッシュからすべて選択されます。 著者が出版物を編集することはめったにないので、この段階でキャッシュを更新する主なイニシエーターは新しい展開です。 展開が1日に1回発生することを考慮しても、たとえば1日に100回表示されるパブリケーションでは、Azureストレージの節約は99%になります。 そして、これは最も人気のある出版物ではありません。



キャッシュの問題を解決するために、インスタンスストレージを使用します。 それを使用できるようにするには、対応する名前空間を接続する必要があります。

using Microsoft.WindowsAzure; using Microsoft.WindowsAzure.ServiceRuntime;
      
      





その後、ローカルストレージを決定する必要があります。 ロール設定でこれを行うことができます。

画像



デフォルトでは、ストレージサイズは1000 MBに設定され、最小サイズは1 MBで、最大サイズはロールサイズに依存します。 スモールインスタンスの場合、このサイズは165 GBです。 詳細については、MSDN( http://msdn.microsoft.com/en-us/library/ee758708.aspx )をご覧ください



ストレージをセットアップした後、いくつかの機能のみを備えた通常のファイルシステムと同様に、ストレージを操作できます。 ファイルの場所を特定するには、ストアへのパスとストアのルートからのファイルへの相対パスを組み合わせる必要があります。

 var Storage = RoleEnvironment.GetLocalResource(LocalResourceName); var FinalPath = Path.Combine(Storage.RootPath, RelativePath);
      
      





.NETオブジェクトをファイルシステムに格納できるようにするには、それらをシリアル化する必要があります。 このために、JSON.Netライブラリー( http://json.codeplex.com/ )を使用します。



さらに、アプリケーションで複数のインスタンスを使用すると、キャッシュの緊急性の問題が発生します。 Azureストレージのデータの変更に関係するインスタンスのキャッシュを更新しても、残りのインスタンスはキャッシュについて何も知りません。 これに対処するために、前の記事( http://habrahabr.ru/post/140461/ )で説明されている、インスタンスとロール間でメッセージを交換するメカニズムを開発しました。



ここでは、キャッシュの中で無関係になった部分を削除する必要があることをインスタンスに通知するために使用されます。



前述のように、AtContent.comではパブリケーションキャッシュを使用します。 同時に、パブリケーションは、Azureストレージから選択されたときにインスタンスによってキャッシュされます。 したがって、パブリケーションにアクセスすると、インスタンスキャッシュが読み込まれます。 作成者がパブリケーションを更新すると、このパブリケーションのキャッシュをクリアする必要性に関するメッセージがロールのすべてのインスタンスに送信され、キャッシュの処理後、再び関連性が高まります。



このメカニズムにより、Azureストレージのコストを削減し、インスタンスのすべての機能を効果的に使用できます。



Windows Azureのキャッシュとして、ハードドライブだけでなく、RAMまたはWindows Azure Cacheも使用できます。 データの処理速度を上げる必要がある場合は、それらの使用が正当化されます。 さらに、このデータのボリュームを大きくすることはできません。 インスタンス上のRAMの量は、ハードドライブの量よりも大幅に少なくなります。 Windows Azureキャッシュも大量のデータを提供しません-取得できる最大量は4 GBであり、そのために月額325ドルを支払う必要があります( http://www.windowsazure.com/ru-ru/home/tour/caching/ ) 。



したがって、ほとんど変更されないが読み取りに頻繁に必要なデータのAzureストレージアクセスの数を本当に減らす必要がある場合は、記事で説明されているメカニズムが非常に役立ちます。 また、OpenSource CPlaseライブラリの一部としても利用可能になり、まもなく一般公開されます。



シリーズを読む:




All Articles