画像提供: Molnia
Amazon S3バケットを管理するうえで、正確なストレージメトリクスはコスト管理とキャパシティプランニングの要となります。ところが、表示されるストレージサイズに食い違いが生じ、混乱やコスト見積もりの誤りを招くことがあります。本記事では、AWSの異なるツールが同一のS3バケットに対して大きく異なるストレージサイズを示した、当社のお客様の実例を取り上げ、実際のストレージ消費量を正確に把握する方法をご紹介します。
あるお客様が特定バケットのS3ストレージメトリクスを確認していたところ、次のような大きな食い違いに気づきました。
- S3メトリクスおよびCloudWatch: 220TBを超えるストレージを表示
- AWS CLIおよびS3の「合計サイズを計算」オプション: 8TB未満のストレージを表示
この27倍もの差は、データの正確性とコストへの影響という観点から、看過できない問題でした。
調査の結果、バケットの設定は次のとおりでした。
- ストレージクラス: すべてのオブジェクトがS3 Standardに格納
- バージョニング: 無効
- ライフサイクルルール: 45日経過後にオブジェクトを削除する設定
これらの設定だけでは、表示されるストレージサイズの大きな差を説明できなかったため、さらに調査を進めました。
食い違いを確認するため、まずS3バケットとCloudWatchのメトリクスを確認しました。
- S3コンソール: バケットのストレージメトリクスを確認
- CloudWatch: バケットに対応するメトリクスを確認
いずれのソースでも、バケットには200TBを超えるデータが格納されていると一貫して表示されていました。
S3バケットメトリクス
CloudWatchメトリクス
原因をさらに掘り下げるため、バケットのストレージを測定する別の2つの方法も試しました。
- S3コンソールの「合計サイズを計算」機能
- バケットの内容を一覧するAWS CLIコマンド
S3の「合計サイズを計算」とAWS CLIコマンドのいずれでも、バケットには600万を超えるオブジェクトと7.5TBのストレージがあると示されました。
S3バケットでの「合計サイズを計算」の実行
S3「合計サイズを計算」の出力結果
バケットサイズを算出するAWS CLIコマンド:
aws s3 ls — summarize — human-readable — recursive s3://
このCLIコマンドは、指定したバケット内のすべてのオブジェクトを一覧表示し、合計サイズのサマリーを出力します。
AWS CLIの出力
表示されるストレージサイズの大きな差は、不可解な謎を投げかけるものでした。同じバケットなのに、なぜこれほどデータ量が違って見えるのか? この食い違いはコスト管理とストレージプランニングに直結するため、さらに踏み込んだ調査が必要でした。謎を解き明かすために、次のステップを実施しました。
- S3 Storage Lensの有効化: 強力なクラウドストレージ分析機能であるAmazon S3 Storage Lensの有効化をお客様にご提案しました。このツールにより、組織全体のオブジェクトストレージの使用状況や利用傾向を可視化できます。
- データ収集の待機: S3 Storage Lensがメトリクスを収集して公開するまでには最大24時間かかる点に留意が必要です。
- 結果の分析: データが揃った段階で、S3 Storage Lensのダッシュボードを丁寧に確認しました。このツールから得られた知見は、調査において非常に有益でした。
未完了マルチパートアップロードの合計サイズを示すS3 Storage Lens
S3 Storage Lensの分析により、食い違いの原因がS3の未完了マルチパートアップロードにあることが明らかになりました。
S3の未完了マルチパートアップロードとは、途中までアップロードされたものの完了に至らなかったオブジェクトのパーツを指します。重要なのは、これらの未完了アップロードは通常のバケット一覧には表示されないにもかかわらず、ストレージ容量を消費し、課金対象となる点です。
未完了マルチパートアップロードのサイズは200TBを超えていました。ツール間で差が生じた理由は、S3コンソールおよびAWS CLIの「合計サイズを計算」操作が未完了マルチパートアップロードを集計対象に含めないためです。
この原因を特定したことで、表示されるストレージサイズの大きな差を説明でき、お客様のS3ストレージ利用を最適化する道筋を示すことができました。
お客様のバケットのクリーンアップを支援するため、未完了マルチパートアップロードを削除するS3ライフサイクルルール「delete-incomplete-mpu-7-days」を設定しました。
未完了マルチパートアップロードを削除するS3ライフサイクルルール
ライフサイクルルール「delete-incomplete-mpu-7-days」を数日間動かし、CloudWatchメトリクスが追いつくのを待ってから、再度バケットメトリクスを確認しました。その結果、ライフサイクルルールが想定どおりに機能し、未完了マルチパートアップロードがすべて削除されていることを確認できました。同じツールでストレージメトリクスを再確認したところ、各ツールが示すバケットのストレージ値は一致していませんでした。
ライフサイクルルール適用後のS3バケットメトリクス
ライフサイクルルール適用後のCloudWatchメトリクス
S3ライフサイクルルール「delete-incomplete-mpu-7-days」適用後の、S3「合計サイズを計算」の実行結果。
S3バケットでの「合計サイズを計算」の実行
S3ライフサイクルルール適用後のS3「合計サイズを計算」
S3ライフサイクルルール適用後にバケットサイズを算出するAWS CLIスクリプト
本ケーススタディは、企業がAWS環境を運用する中で直面する複雑な課題の一例にすぎません。AWSサービスに関する深い知見と、クラウドメトリクスを読み解く力を活かして、ストレージサイズの不一致の根本原因を突き止め、効果的な解決策をご提供しました。これにより、目の前の課題を解消するだけでなく、お客様にS3ストレージの利用実態とコスト構造への理解を深めていただくことができました。
DoiT Internationalは、企業がクラウド環境の複雑さを乗り越え、課題を解決し、AWSインフラを最適化していくためのご支援を専門としています。同じようなストレージメトリクスの不一致でも、その他クラウドにまつわる課題でも、当社の専門家チームがサポートいたします。クラウドの複雑さがビジネスの足かせとならないよう、ぜひDoiTまでお問い合わせください。クラウド環境の効率性とコスト効果を最大化し、AWS投資から最大の価値を引き出す方法をご一緒に検討します。