Amazon Web Services ブログ

S3 ストレージ管理アップデート – 分析、オブジェクトのタグ付け、インベントリ、メトリクス

本日、皆様がお持ちのストレージとそのアクセスパターンを詳しく知るための 4 つの S3 機能についてご説明したいと思います。何をどのくらい保管しているのか、どのように使用しているのかを知ることができ、その結果として、S3 ストレージクラスの使用に関する情報に基づいた意思決定を行うことができます。これらの機能は、バケットに何十万、何千、何百万、何十億というオブジェクトを持っていても、S3 を使用するすべての人にとって価値があります。

以下が概要です:

S3 分析 – オブジェクトの格納状況と取得パターンを分析し、その結果を使って、最適なストレージクラスを選択することができます。あなたは S3 コンソールで表示される分析の結果を検査したり、お好みの BI ツールにロードし深掘りしても良いでしょう。そうすることで、ストレージの利用傾向を見て、それらが使い方や成長度合いにどのように関連しているのかがつかめます。

S3 オブジェクトのタグ付け – 複数のキーと値のペア(タグ)をそれぞれの S3 オブジェクトに関連付けることができ、いつでも変更することができます。タグは、アクセスの管理と制御、S3 ライフサイクルポリシーの設定、S3 分析のカスタマイズ、CloudWatch メトリクスのフィルタリングに使用できます。バケットをデータレイクと考えることができ、タグを使用してそのデータレイクの中のオブジェクトの分類を作成できます。これは、バケットとプレフィックスを使用するよりも柔軟性があり、オブジェクトの名前を変更、移動、またはコピーせずに意味付けの変更を行うことができます。

S3 インベントリ – S3 インベントリを使用して、ビジネスワークフローやビッグデータのジョブを加速できます。この機能は、毎日または毎週の単位で、バケットの全部または一部の内容(プレフィックスによって識別される)の CSV 形式のフラットファイル表現を提供します。

S3 CloudWatch メトリクス – 13 種類の Amazon CloudWatch メトリクスを監視やアラームを設定することで、S3 を活用するアプリケーションのパフォーマンスを向上させる可能性があります。

詳細を見てみましょう。

S3 分析
S3 のユーザは、標準、標準 IA (標準低頻度アクセス)、Glacier と 3 つのストレージクラスを選択することができます。S3 のオブジェクトライフサイクル管理を使用して、オブジェクトが期限切れになるか、標準 IA もしくは Glacier に移行するかを指定することができます。

S3 分析機能は、オブジェクトについて、標準と標準 IA のどちらを選択したら良いのかの必要な情報を提供します。多くの顧客は、処理を容易にするために、複数の異なるタイプまたはカテゴリの情報を 1 つのバケットに格納するため、バケット内のオブジェクトのサブセット(共通のプレフィックスまたはタグ値によって定義)で分析を実行できます。各サブセットはフィルタによって定義されます。各バケットは最大 1,000 のフィルタを持つことができます。私の jbarr-public バケットのフィルタは次のとおりです:

プレフィックスが www で始まるオブジェクトを分析する簡単なフィルタを定義する方法は次のとおりです:

代わりにタグ名と値でフィルタリングすることができます。type という名前のタグに page という値を持つオブジェクトを分析する方法は次のとおりです:

各フィルタは、任意の好みの数のタグが付いた、多くとも1つのプレフィックスを指定することができます。分析内容を毎日ファイルにエクスポートすることもできます:

1 つ以上のフィルタが配置されると、分析は毎日実行され、フィルタをクリックするだけで分析を表示できます。たとえば、私の Archive と設定したフィルタをクリックすると、次のように表示されます:

この分析から、多くの良い情報が読み取れます!以下のようなことがわかります。

  • 127 日を振り返ってみると、30 日以上経過したオブジェクトのほとんどはアクセス頻度が低いことがわかります。私は、これらのオブジェクトを標準 IA のストレージに移行するライフサイクルルールを作成することで、コストを削減できます。
  • この時点で、私のストレージの大半(6.39 PB)は標準ストレージにあり、ほんの少しだけが標準 IA にあります(実のところ、私のバケットにはあまりデータがありませんでした。S3 チームは、私のアカウントにいくつかのテスト用メトリクスをロードしてくれました。非常に寛大です!)。
  • 127 日間の観測期間にわたって、標準ストレージの 16 %から 30 %くらいのデータが 1 日単位で、リトリーブされました。
  • 30 〜 45 日後、45 〜 60 日後、60 〜 90 日後、90 〜 180 日後、180 日以上後のオブジェクトは、まれにしかアクセスされず、標準 IA に配置するのに適しています。

ストレージクラス分析は、コンソール、CLI、または S3 API を使用して設定できます。

詳細は、Amazon S3 分析 – ストレージクラス分析 をご覧ください。

S3 オブジェクトのタグ付け
既存のロケーションベースの S3 オブジェクト管理モデル(バケットとプレフィックス)加えて、タグ付けは、そのオブジェクトは何か?という観点に基づいてストレージを管理する機能を提供してくれます。たとえば、部門の名前でオブジェクトをタグ付けし、そのタグに基づいてアクセスを許可する IAM ポリシーを構築することができます。これにより、単にタグを変更するだけで変更を反映させることができるなど、多くの柔軟性が得られます。

オブジェクトのライフサイクルのどの部分でも、それらを作成、更新、または削除することができます。タグは、IAM ポリシー、S3 ライフサイクルポリシー、および先ほど紹介した分析フィルタで参照できます。各オブジェクトは最大 10 個のタグを持つことができ、オブジェクトの各バージョンは異なるタグセットを持ちます。タグを利用して、ライフサイクルポリシーにてオブジェクトの有効期限を管理したり、特定のタグに関するアクティビティを反映する CloudWatch メトリクスを設定しても良いでしょう。

各オブジェクトのプロパティページには、現在のタグセットが表示され、それらのタグを編集できます:

また、CLI または S3 API からタグを設定してアクセスすることもできます。これら 2 つの方法のいずれかを使用する場合は、常に完全なタグセットの単位で設定する必要があります。たとえば、オブジェクトに 4 つのタグがあり、5 つ目のタグを追加する場合は、現在のセットを読み込み、新しいセットを追加してから、セット全体を更新する必要があります。

タグは、クロスリージョンレプリケーションを介してリージョン間で複製できますが、ソース側の IAM ポリシーでは s3:GetObjectVersionTagging 及び s3:ReplicateTags アクションを有効にする必要があります。

タグの費用は、10,000 個のタグにつき月額 0.01 ドルです。タグを追加または更新するリクエスト(それぞれ PUT および GET)は、通常の料金で課金されます。

詳細は、S3 オブジェクトのタグ付け を参照してください。

S3 インベントリ
S3 の LIST 操作は同期的で、一度に 1,000 個までのオブジェクトと、2 回目の LIST を開始するために使用するキーを返します。これは小規模から中規模のバケットやシングルスレッドのプログラムでは効果的ですが、大規模なバケットや複数のスレッドと組み合わせて使用するのは難しくなるかもしれません。

S3 インベントリを使用すると、バケットのインベントリレポートを毎日または毎週という形で受け取ることができます。プレフィックスを使用してレポートをフィルタリングしたり、サイズ、ストレージクラス、およびレプリケーションステータスなどをオプションのフィールドとして含めることができます。レポートは、ご自身のアカウントの S3 バケットに送信することも、適切な権限設定を使用して別のアカウントに送信することもできます。

以下は、www で始まるすべてのオブジェクトに対して、WebStuff という名前の、毎日のインベントリレポートをリクエストする方法の例です:

また、宛先のバケット(jbarr-s3-inventory)に書き込むための S3 権限を与える必要があります。使用したポリシーは次のとおりです(詳細は、Amazon S3 インベントリおよび Amazon S3 分析に対するアクセス権限の付与 を参照):

このインベントリのメカニズムは、マニフェスト、マニフェストのチェックサム、およびデータファイルの 3 つのファイルを作成します。マニフェストには、データファイルの場所とチェックサムが格納されています:

{
   "sourceBucket":"jbarr-public",
   "destinationBucket":"arn:aws:s3:::jbarr-s3-inventory",
   "version":"2016-11-30",
   "fileFormat":"CSV",
   "fileSchema":"Bucket, Key, Size, LastModifiedDate, ETag, StorageClass",
   "files":[
      {
         "key":"jbarr-public/DailyInventory/data/cf1da322-f52b-4c61-802a-b5c14f4f32e2.csv.gz",
         "size":2270,
         "MD5checksum":"be6d0eb3f9c4f497fe40658baa5a2e7c"
      }
   ]
}

解凍された後のデータファイルの外観は次のとおりです:

インベントリレポートを使用して毎日または毎週の処理ワークフローを強化する場合は、S3 通知機能の設定を忘れないでください!チェックサムファイルは他の 2 つのファイルの後に書かれていますので、安心して活用することができます。また、ライフサイクルポリシーを使用して、累積されていくインベントリファイルのコレクションを管理することを忘れないでください。

補足として、毎日または毎週のレポートを使用すると、複数の LIST 操作を何度も行うことと比較して最大 50 %節約できます。この機能の詳細については、Amazon S3 ストレージインベントリを参照してください。

S3 CloudWatch メトリクス
S3 は、ストレージ、リクエスト、およびデータ転送のメトリクスを CloudWatch に公開できるようになりました。ストレージメトリクスについては毎日レポートされ、追加料金なしで利用できます。リクエストとデータ転送のメトリクスは 1 分間隔で(処理待ち時間の後に)利用可能で、いつもの CloudWatch 課金レートで請求されます。 S3 分析の場合と同様に、CloudWatch メトリクスは、バケット全体でレポート化できますし、プレフィックスまたはタグを介して選択されたサブセットについて収集してレポート化することもできます。

メトリクスのフルセットは次のとおりです:

Storage Requests Data Transfer
  • Bucket Size Bytes
  • Number Of Objects
  • GET
  • LIST
  • PUT
  • POST
  • DELETE
  • ALL
  • HEAD
  • 4xx Errors
  • 5xx Errors
  • Total Request Latency
  • First Byte Latency
  • Bytes Uploaded
  • Bytes Downloaded

このメトリクス、S3 および CloudWatch コンソールで利用できます。私のバケットの S3 コンソールでの Total Request Latency の外観は次の通りです:

View in CloudWatch (CloudWatch で表示)をクリックし、任意のメトリックの CloudWatch アラームを設定することもできます。こちらは、私のバケットが 100 MB より大きくなった場合、通知を受けようと設定しているところです:

詳細は、S3 バケットにリクエストメトリクスを設定する方法 をご覧ください。

今すぐ利用可能
昨年末に、これらの機能にアクセスできるようになりました。アップデートされた S3 Console からアクセスできます。他にも多くの新機能が含まれています(詳しくは Introduction to the New Amazon S3 Console をご覧ください)。

– Jeff ; (原文:S3 Storage Management Update – Analytics, Object Tagging, Inventory, and Metrics / 翻訳: SA 焼尾)