Azure Storage Analytics サービスについて

Winodws Azure のストレージ サービスでは、Storage Analytics サービスが2011年8月より提供されています。リリースされた直後では、REST APIを使って有効や無効を切り替えていましたが、Windows Azure SDK  for .NET(1.6)ではマネージ API が提供されています。  Storage Analytics サービスは、ログ($Logs)がBlob ストレージに記録し、メトリック($MetricsTransactionsBlob、$MetricsTransactionsTable、$MetricsTransactionsQueue、$MetricsBlobCapacity)が Table ストレージに記録されます。 Storage Analytics サービスをマネージ API で有効にするには、以下のようなコードを使用します。Storage Analytics サービスの有効や無効の設定には、少し時間がかかることに注意してください。 

 var serviceProperty = new ServiceProperties()
                         {   Logging = new LoggingProperties()
                                   {   Version = "1.0",
                                       LoggingOperations = LoggingOperations.All, 
                                       RetentionDays = 7 },
                             Metrics = new MetricsProperties() 
                                   {   Version = "1.0",
                                       MetricsLevel = MetricsLevel.ServiceAndApi, 
                                       RetentionDays = 7 }
                         };
var blobClient = storageAccount.CreateCloudBlobClient();
blobClient.SetServiceProperties(serviceProperty);

上記のコードは、サービス プロパティの新規のインスタンスを作成して SetServiceProperties メソッドで設定を行っています。設定で重要なことは、RetentionDays(Retation ポリシー)になります。 Storage Analytics サービスは、記録するデータを 20TBを上限として、一杯になると空きができるまで記録を停止します。もちろん、Storage サービスの上限である 100TB とは独立しています。この記録する領域を再利用するための設定が、Retention ポリシーになります。具体的には、RetationDays にデータを保持する日数を設定することで、古いデータは自動的に消去されるようになります。RetatntionDays の上限は、365、即ち 1 年ということになりますから Retation ポリシーを設定しないということは、RetaionDays を 365 に設定したということになります。
Storage Analytics サービスを無効にするには、RetationDays に null を設定します。具体的には、ServicePropertyを以下のようにするのが良いでしょう。

 var serviceProperty = new ServiceProperties()
                         {   Logging = new LoggingProperties()
                                   {   Version = "1.0",
                                       LoggingOperations = LoggingOperations.None, 
                                       RetentionDays = null },
                             Metrics = new MetricsProperties() 
                                   {   Version = "1.0",
                                       MetricsLevel = MetricsLevel.None, 
                                       RetentionDays = null }
                         };

Storage Analytics サービスで記録されるデータを取得するには、ログであれば $Logsコンテナーに対して ListBlobs API で Blobのコレクションを取得してから該当する Blob を取得します。記録されるログは、このようなフォーマットになっています。メトリクスに対しては、$Metrics で始まる Tableに対してクエリーを実行してエンティティを取得します。メトリクスは、このようなフォーマットになっています。

Storage Analytics サービスで注意しないといけないのは、記録するデータも Storage サービスとして課金対象になることです。つまり、記録容量とトランザクション(ListBlobs、Tableに対するクエリーなどの API 呼び出し)が課金されるのです。記録するデータの上限が 20TB で Storage サービスの上限である 100TB とは独立していることを既に説明しましたが、このことから類推できることは Storage Analytics サービスの記録場所が Storage サービスから独立していることです。この理由から、Azure Storage Explorer などでは記録したデータを取得することができません。これは、Storage サービスのアカウントに対して ListContainers API などを呼び出してもコンテナーを取得できないことからも明らかです。これらの事から考えると、Storage Analytics サービスとは、Storage サービス側の課金システムが取得している情報を利用者に提供するサービスであり、課金システム側がデータを記録する仕組みのためパフォーマンスへ影響を与えないものだと理解することができます。

Storage サービスに対するトランザクションの考え方は、Windows Azure Storage Team のBlog に記載があります。細かい部分は割愛しますが、大まかにまとめれば以下のようになります。

  • 全ての REST API 呼び出し毎にトランザクションとしてカウントする。
  • リスト系の API は、継続トークンが含まれている場合に +1 が加算される。
  • PutBlob では、32MB以上の場合は データ/4MB(切り上げ) + 1 (PutBlockList)がカウントされる。
  • Table に対するバッチトランザクションは、1 トランザクションとしてカウントされる(SaveChanges)。
  • Tableに対するバッチでないトランザクションは、AddObjectなどが 1トランザクションとしてカウントされる。

特に規模が大きくなる場合は、Storage サービスに対するトランザクション数の見積もりを事前に行って、Storage アカウントが 5 つで十分かどうかを検討した方が良いでしょう。

追記:$Logsコンテナーの内容を参照するには、CloudBerryのフリー版を使用することができます。また、メトリクスについてTableXplorerのフリー版を使用することができます。これらのツール使わない場合は、自分で内容を参照するためのコードを作成する必要があります。