アクセスパターンを分析し、最も費用対効果の高い Amazon S3 ストレージクラスを使用する

このブログは 2024 年 10 月 21 日に Durga Prasad Katrapally によって執筆された内容を日本語化したものです。原文はこちらを参照してください。

データレイク、機械学習 (ML)、分析を使用する企業には、スケーラブルなデータストレージが必要です。ただし、保存されているすべてのデータに同じようにアクセスするわけではありません。データの中には頻繁にアクセスされる部分もあれば、ほとんどアクセスされないデータ部分もあります。最新のクラウドストレージでは、使用頻度の低いコールドデータを低コストのストレージクラスに移動できます。これにより、ユーザーは頻繁にアクセスされないデータのストレージにかかる費用を節約できます。データ量が増えるにつれて、アクセスパターンを追跡し、データを適切なストレージクラスに移動してコストメリットを最大限に引き出すことが難しくなります。企業はストレージ階層を活用したコスト削減を最大化するために、データ使用量とストレージコストを注視する必要があります。

Amazon S3 は、パフォーマンス、アクセス、耐障害性、コストなどの異なるニーズを満たすさまざまなストレージクラスを提供するオブジェクトストレージサービスです。 S3 ライフサイクル および Amazon S3 Intelligent-Tiering ストレージクラスを使用すると、異なるストレージクラスまたは階層間でデータを自動的に移行してコストを最適化できます。ただし、完全なコスト削減を実現するには、まず実際のアクセスパターンを理解する必要があります。S3 Standard ストレージクラスにデータを保存すると、頻繁にアクセスされるデータとあまりアクセスされないデータで同じストレージコストが発生するため、節約できる可能性は限定的です。アクセスパターンの予測が可能か不可能かを考慮せずに S3 ライフサイクルポリシーや S3 Intelligent-Tiering を使用すると、オブジェクトが最小期間より前に削除された場合に取り出し料金や早期削除料金が高くなったり、より安価なストレージへの移行が遅れて、節約の機会を逃したりする可能性があります。

この記事では、S3 ストレージクラス分析を使用してアクセスパターンを分析し、データを別のストレージクラスに移行するタイミングを決定するのに役立つ情報を提供します。S3 ストレージクラス分析では、一定期間にわたってフィルタリングされたデータセットのアクセスパターンを観察し、その結果に基づいて、予測可能なデータアクセスパターンには S3 ライフサイクルポリシー、予測不可能なアクセスパターンには S3 Intelligent-Tiering ストレージクラスというように、適切な選択を行うことができます。このソリューションでは、ストレージアクセスパターンを分析し、異なるストレージクラスと階層を最大限に活用することで、ストレージコストを最適化することができます。

ソリューションの説明

このアプローチは 3 つのフェーズに分かれています。

有効化 : 特定のバケットで S3 ストレージクラス分析レポートを有効にします。このフェーズが終了すると、S3 ストレージクラス分析レポートが、設定時に指定した Amazon S3 のパスに配信されます。
分析 : 毎日更新される S3 ストレージクラスの分析レポートを分析します。このフェーズの終了時には、バケットのワークロードパターンが予測可能または予測不可能のいずれかで描画されます。
アクション : アクセスパターンの明確な指標を基に、分析フェーズの結果に基づいてアクションをします。

注意 : S3 ストレージクラスの分析は、Amazon S3 の料金ページに記載されているように、有料機能であり、オブジェクトごとに課金されます。

1. 有効化

このフェーズに進む前に、このブログ記事では、S3 Storage Lens を使用してコスト最適化に適した大きなバケットを特定し、ターゲットにする方法を説明します。この記事のポイントは、S3 Storage Lens を使用して特定したバケットで S3 ストレージクラスの分析レポートを有効にすることです。

S3 Storage Lens は、お客様のすべての S3 バケットにわたる S3 の使用状況とアクティビティのメトリクスを組織全体で高レベルに表示します。最適化の機会を見つけ出し、ベストプラクティスを導入するのに役立ちます。ストレージクラス分析では、通常はペタバイトレベルの特定の大規模 S3 バケットのストレージアクセスパターン、オブジェクトの保存期間分布、移行の機会をモニタリングすることができます。これにより、個々の高いインパクトがあるバケットの正確なライフサイクル管理とコスト最適化が可能になります。

S3ストレージクラス分析レポートは、2つの形式で利用できます。S3バケットのメトリクスタブの分析機能として直接表示する方法と、カンマ区切り（CSV）形式で別のS3バケットにエクスポートする方法です。 この記事では、後者の形式、つまりCSV形式での分析に関する推奨事項に焦点を当てます。CSV形式のレポートでは、日付をドリルダウンして詳細に分析できるのに対し、メトリクスタブでは一定期間のメトリクスを適切に表示できます。

S3 ストレージクラスの分析レポートを有効にする

Amazon S3 コンソールで、バケットを選択し、分析するバケットを選択し、メトリクスタブを選択します（図 1 参照）。

図 1：S3ストレージクラスの分析レポートの作成

ストレージクラス分析に移動し、Create configurationをクリックします。

図 2：ストレージクラス分析レポートの設定を作成

Create Configuration をクリックした後、設定の詳細を入力します。

• 名前にある S3 Storage Class Analysis レポートの設定名を入力します。
• 設定スコープでは、レポートの適用範囲を指定します。特定のプレフィックスに対しては 1 つ以上のフィルターを使用してこのルールのスコープを制限するを、バケット全体に対してはバケット内のすべてのオブジェクトに適用を選択します。
• CSV をエクスポートでは、レポートのフォーマットを選択し、CSV をエクスポートの下で 有効にするにチェックを入れます。
• 送信先バケットのアカウント選択では、このアカウントまたは別のアカウントを選択します。
• 送信先で、図 3 のようにレポートをリダイレクトする宛先バケットを選択します。

図 3：S3ストレージクラスの分析レポート有効化

S3ストレージクラス分析レポートの設定が完了したら、S3コンソールでフィルタに基づくデータ分析の監視を 24-48 時間後に開始します。ただし、S3 ストレージクラス分析では、結果を出す前に分析用の情報を収集するために、フィルタリングされたデータセットのアクセスパターンを30 日以上モニタリングします。アクセスパターンが変化するにつれて、最初の推奨事項が出された後も分析は継続され、更新されます。

S3 ストレージクラス分析レポートからの推奨事項は、S3 Standard-Infrequent Access (S3 Standard-IA) への移行のみを示します。しかし、検出されたパターンを使用して、既知または未知のパターンを導き出すことができます。既知および未知のパターンの例については、次のフェーズで説明します。 このフェーズの終了時には、設定を作成した際に指定した Amazon S3 バケットに S3 ストレージクラス分析レポートが送信されているはずです。

2. 分析

このフェーズでは、毎日更新される S3 ストレージクラスの分析レポートの分析に重点を置きます。有効化すると、各日付に対して複数のエントリが作成されます。 以下はサンプルレポートの例です。

図 4：複数のエントリーを含む S3 ストレージクラス分析レポートのサンプル

S3 ユーザーガイドには、分析に使用される ObjectAge、Storage_MB、DataRetrieved_MB、GetRequestCount など、各カラムの説明が記載されています。

分析の開始点として、図 5 に示されているように、レポートの最新の日付でフィルタリングすることが有効です。

図 5：日付を 1 つ指定してフィルタリングした S3 ストレージクラス分析レポートのサンプル

パターンを導き出すために注目すると良い列には、Object Age、Storage_MB、DataRetrieved_MB、GetRequestCountなどがあります。

予測可能なワークロードの例

このセクションでは、図 6 に示されているような予測可能な作業負荷パターンに関する S3 ストレージクラス分析レポートの例を紹介します。

図6：予測可能なパターンを持つ S3 ストレージクラス分析レポートのサンプル

ObjectAge 列にはバケットに配置された経過時間のリストが表示され、例えば 000-014 は 0 日から 14 日の間のオブジェクト、015-029 は 15 日から 29 日の間のオブジェクトであることを意味します。

Storage_MB はバケットに配置された ObjectAge における総ストレージ容量を示します。例えば、000-014 日経過のオブジェクトの総使用ストレージ容量は 277847 MB、015-029 日経過のオブジェクトの総使用ストレージ容量は 290350 MB などです。

GetRequestCount は、バケットに配置された経過時間のグループ (ObjectAge のグループ) に送信された API コールの総数です。この例では、000-014 日のオブジェクトには約 12369 件の API コールがあり、その他の ObjectAge グループには API コールはありません。

DataRetrieved_MB Data は、ObjectAge グループにおけるその日の GET リクエストによるストレージクラスごとの転送データ量（MB）です。ObjectAge=’ALL’ の場合、その日のすべての ObjectAge グループに対する GET リクエストによる転送データ量（MB）の合計値となります。

分析をすると、前掲のレポート（図 6）からパターンが予測できることが分かります。0-14 日経過したオブジェクトは活発に使用されていますが、それ以降は他の経過日数のオブジェクトに対する API リクエストはありません。したがって、S3 ライフサイクルポリシーを使用して、ほとんどアクセスされないデータを 15日 経過後に S3 Glacier ストレージクラスに移動することができます。

予測不可能なワークロードの例

ここでは、予測不可能なパターンに関する S3 ストレージクラス分析レポートの例を見てみましょう。

次の S3 ストレージクラス分析レポート（図 7）は、最初の 30 日間にアクティブなアクセスがあります。次の 30 日間（つまり 30 日から 59 日まで）はアクティブなアクセスがなく、60 日から 119 日まで再びアクセスされ、120 日から 179 日まではアクセスリクエストがありません。ここには予測性はありません。古いデータの一部は依然としてアクセスされている一方で、まったくアクセスされない部分もあります。このシナリオでは、アクティブにアクセスされる部分と、アクセス頻度が低い部分の両方に対して、S3 Standard の料金を支払うことになるでしょう。

このバケットは、S3 Intelligent-Tiering に適しています。アクセスされないコールドな部分を、30日または90日後に自動的に低頻度アクセス階層またはアーカイブインスタントアクセス階層に移動させるからです。

図 7：予測不可能なパターンを含むS3ストレージクラス分析レポートのサンプル

この分析では、特定の日のパターンを確認しました。一般的には、例えば 1 か月間といった一定期間のパターンを観察し、アクセス・パターンに関する結論を出します。このフェーズの終了時には、バケットワークロードのパターンは、予測可能なものと予測不可能なもののどちらかとして分類されます。

3. アクション

最後のフェーズでは、アクセスパターンを明確に示しながら、分析フェーズの結果に基づいてアクションをします。

予測可能なパターンに対するアクション

予測可能なパターンについては、S3 ライフサイクルポリシーを有効にして、アクセス頻度の低いデータを S3 Glacierストレージクラスに移動することで、最大限のコスト削減を実現できます。

S3 Glacier Instant Retrieval、S3 Glacier Flexible Retrieval、S3 Glacier Deep Archive のどれを選択するのかは、バケットのビジネス上のユースケースにより異なります。 データがミリ秒単位の検索パフォーマンスで利用可能であり、四半期に 1 回アクセスされる必要がある場合は、S3 Glacier Instant Retrieval が適しています。 データが非同期で数分から数時間でアクセス可能であり、半年に 1 回アクセスされる場合は、S3 Glacier Flexible Retrieval が適しています。24-48時間以内にデータが利用可能になり、毎年定時にアクセスされるというユースケースであれば、S3 Glacier Deep Archive が適しています。 S3 ライフサイクルポリシーを通じてデータを移動する際には、一時的な移行料金が発生し、アクセス時にはデータ取り出し料金が発生します。以下の表は、米国東部（バージニア北部）AWSリージョンの料金をまとめたものです。

表 1：米国東部（バージニア北部）リージョンの移行費用

一時的な料金を計算するには、移行するコールドオブジェクトの総数が必要です。移行料金は1000オブジェクト単位であり、サイズによる料金設定ではないからです。

一時的な料金の計算

ここでは、パターンが予測可能な図 6 と同じ例を使用します。現在のストレージでは、データのコールド部分（バケットに配置されて15日を越えるグループの合計）は約 6.31 TB です。これは、約 6.31 TB が 100 万のオブジェクトであり、ユーザーは 24-48 時間データ取得を待つことができると仮定しています。コールド部分は、S3 Glacier Deep Archive に移動できます。

S3 Standard から S3 Glacier Deep Archive にデータを移行する際には、1000 オブジェクトあたり $0.05 の一時的な移行料金が発生します（表 1 ）。

100 万個のオブジェクトの場合、移行料金は（1,000,000/1000）*0.05、つまり $50 となります。

この移行について考慮すべき重要な要素は、オブジェクトのサイズです。移行料金はオブジェクトの数に基づいており、サイズに基づいていないため、オブジェクトが大きければ大きいほど、ストレージの GB あたりの移行コストは低くなります。

例えば、10 TB のデータがあるとします。1 MB の小さなオブジェクトが 1000 万個ある場合、S3 Glacier Deep Archive への移行費用は $500 かかります。一方、10 MB のオブジェクトが 100 万個ある場合、移行費用は $50 です。

節約の効果

例えば、一時的な費用を差し引いた実質的な節約額を計算することができます。図 6 から、15 日以上経過したオブジェクトのデータはほとんどアクセスされていないことが分かります。

15 日以上経過したオブジェクトを移動する S3 ライフサイクルポリシーにより、合計約 6.40 TB のオブジェクトがより安価なストレージクラスに移動されます。この例では、前述のとおり、S3 Glacier Deep Archive を移行先のストレージクラスとします。

表 2 : 予測可能なアクセスパターンの節約計算

*$0.00099 は、米国東部（バージニア北部）リージョンにおける S3 Glacier Deep Archive の GB あたりの料金です。

予測不可能なパターンに対するアクション

予測不可能なパターンに対しては、S3 Intelligent-Tiering が費用対効果に優れており、S3 ライフサイクルを使用してデータをS3 Standard ストレージクラスからS3 Intelligent-Tiering ストレージクラスに移行することができます。

S3 Intelligent-Tiering では、オブジェクトのモニタリングに少額の料金がかかります。さらに、128 KB を超えるオブジェクトのみがモニタリングの対象となり、最後にアクセスされた時間に基づいてストレージクラス間で移動されます。128 KB 未満のオブジェクトにはモニタリング料金はかかりません。また、S3 ライフサイクルでは、128 KB 未満のオブジェクトは S3 Intelligent-Tiering に移行されません。

一時的な料金の計算

まず、バケット全体で予測不可能なワークロードがあります。そのため、S3 Standard ストレージクラスのオブジェクトは S3 Intelligent-Tiering ストレージクラスに移行する必要があります。 S3 Standard から S3 Intelligent-Tiering への移行には、1000 オブジェクトあたり $0.01 の移行料金がかかります（表1）。 バケット内に 128 KB 以上のオブジェクトが合計 1000 万個あると仮定すると、移行料金は（10,000,000/1000）*$0.01 、つまり $100 となります。

S3 Intelligent-Tieringのモニタリング料金

次に、オブジェクトが S3 Standard ストレージクラスから S3 Intelligent-Tiering ストレージクラスに移動された場合、モニタリング料金が適用されます。

128 KB を超えるサイズのバケットに合計 1000 万のオブジェクトがある場合、そのバケットのモニタリング料金は次のようになります。（10,000,000/1000）*0.0025 = 1 か月あたり $25。

*米国東部（バージニア北部）リージョンでは、モニタリング料金は 1 か月あたり 1,000 オブジェクトあたり $0.0025 です。

節約の効果

例えば、1 回限りの料金の支払い後にどれほど効果的な節約ができるかを見てみましょう。図 7 から、30-44 日間、45-59日間、120-149日間、150-179日間の経過時間層のデータはアクセスされていません。

30日後

S3 Intelligent-Tiering がバケット上で有効になっている場合、S3 Intelligent-Tiering に移行してから 30 日後には、合計約5.82 TB がコールドとして識別されます。さらに、30 日後には低頻度アクセス階層に、90 日後にはアーカイブインスタントアクセス階層に移行します。

表3 : 30 日後の予測不能なパターンの節約額の計算 *$0.0125は、米国東部（バージニア北部）リージョンにおける 1 GB あたりの低頻度アクセス階層ストレージクラス料金です。

90日後

オブジェクトが低頻度アクセス階層に移動されてから 60 日後、S3 Intelligent-Tiering は移行コストなしで自動的にアクセスがない場合、現在の低頻度アクセス部分をアーカイブインスタントアクセスに移動します。これにより、コールドデータ部分がさらに節約できます。

わかりやすくするために、この例では、 アーカイブインスタントアクセスクラスに移動した低頻度アクセスデータの総量は 5820 GB のみとします。しかし、一般的に S3 Intelligent-Tiering は、新たにインポートされたオブジェクトで 30 日間アクセスがないものをモニタリングし S3 Standard-IA へ、90 日後にアーカイブインスタントアクセスクラスに移動します。

表4：90日後の予測不能パターンの節約額計算

考慮すべきその他のツール

予測可能なアクセスパターンまたは予測不可能なアクセスパターンのいずれかで、他のストレージクラスへの移行対象となるオブジェクトの正確な数を把握するには、Amazon S3 Inventoryと Amazon Athenaという 2 つの主要なツールが役立ちます。

Amazon S3 Inventory は、S3 バケット内のオブジェクトとそれに対応するメタデータを、日次または週次でリスト化したレポートを、CSV、Apache最適化行列形式（ORC）、またはApache Parquet出力ファイルのいずれかで提供します。Athena は、オープンテーブルおよびファイル形式をサポートするオープンソースフレームワークを基盤としたサーバーレスのインタラクティブな分析サービスです。Athena は Amazon S3 と緊密に統合されており、Amazon S3 インベントリレポートの分析が可能です。

ブログ「Manage and analyze your data at scale using Amazon S3 Inventory and Amazon Athena」では、Athena と Amazon S3 インベントリレポートの統合、および Amazon S3 インベントリメタデータに対するクエリについて説明しています。Amazon S3 インベントリレポートにクエリを実行することで、移行対象となる 128 KB を超えるオブジェクトや、一定期間以上経過したオブジェクトなどの洞察を得ることができます。これにより、S3 ライフサイクルアクションの初期費用や、S3 Intelligent-Tiering のモニタリング料金をより正確に算出することができます。

クリーンアップ

アクセスパターンが分かったら、Amazon S3 ストレージクラス分析レポートを停止して、課金を停止できます。レポートを停止するには、以下の手順に従います。

1. Amazon S3 コンソールで、バケットを選択します。S3 ストレージクラス分析レポートを無効にする必要があるバケットを選択します。メトリクスタブに移動し、ストレージクラス分析を選択します。
   
   図 8 : S3 ストレージクラス分析レポートのクリーンアップ方法
2. 削除するレポートを選択し、削除を選択します。
   

図 9 : ストレージクラス分析レポートの削除

まとめ

この記事では、S3 ストレージクラス分析レポートの設定方法と、コストを最適化するために大規模な Amazon S3 バケット全体のアクセスパターンの分析の重要性について説明しました。また、アクセス頻度の低いデータを、S3 ライフサイクルルールや Amazon S3 Intelligent-Tiering を使用して、よりコスト効率の高い Amazon S3 のストレージクラスに移動することで、大幅なコスト削減を実現できるシナリオも確認しました。さらに、S3 Storage Lens やストレージクラス分析レポートなどのツールを使用して、S3 ライフサイクルポリシーと S3 Intelligent-Tiering のユースケースを紹介しました。また、コスト削減額と移行時の一時的な費用を計算することで、意思決定プロセスを導くこともできました。

Amazon S3 は、ストレージクラスと Intelligent-Tiering のオプションを提供しており、お客様のワークロードとビジネスニーズに基づいてコストを最適化することができます。S3 バケットのアクセスパターンを理解することは、最適化の機会を活用するために極めて重要です。S3 ストレージクラス分析レポートは、お客様のバケットを分析することでアクセスパターンを特定し、データを最も最適なストレージクラスに配置できるようにします。

この記事をお読みいただきありがとうございました。

追加のリソースについては、この動画「Amazon S3 Storage Class Analysis」や、その他の関連ストレージブログを参照してください。

• Amazon S3 cost optimization for predictable and dynamic access patterns
• Dialog Axiata saves significantly on storage using Amazon S3 Intelligent-Tiering and S3 Storage Lens
• How Toyota Connected North America reduced storage costs by optimizing its growing data on Amazon S3