画像提供:dennizn(Shutterstock)
先日、あるお客様がS3バケット内のオブジェクトをStandardストレージからGlacier Deep Archiveへ移行する際にトラブルに遭遇しました。Glacier Deep Archiveに移したはずのオブジェクトが、Standardストレージにそのまま残って表示され続けていたのです。
該当のS3バケットを調査したところ、確かにStandardストレージは元の4.9TBから減っていませんでした。その様子は下図(お客様のS3バケットのストレージメトリクスから取得)で確認できます。
S3メトリクス Total Bucket Size
S3メトリクスのTotal Bucket Sizeを見ると、Standard Storageが4.9TBあることが分かります。図のオレンジの線がStandardストレージです。お客様は5月6日にGlacier Deep Archiveへの移行を開始されましたが、5月10日時点でもメトリクスにはこの変更がまったく反映されていませんでした。
Standardストレージ用のS3メトリクス
CloudWatchでTotal Bucket Sizeメトリクスを開いてみると、S3メトリクスとCloudWatchメトリクスの間に差があることに気付きました。S3メトリクスではStandardストレージが4.9TBと表示されていたのに対し、CloudWatchメトリクスでは5.3TBと表示されていたのです。
ストレージクラス別のCloudWatchメトリクス
ストレージクラスごとのメトリクス内訳
調査の結果、お客様のストレージクラス間移行について、次の2つの問題が浮かび上がりました。
(1) オブジェクトを別のストレージクラスへ移したにもかかわらず、S3 Standard Storageのメトリクスが減っていない。
(2) Standardストレージの合計値について、S3メトリクスとCloudWatchメトリクスの間に大きな差が出ている。
問題を解き明かす
StandardからGlacier Deep Archiveへの移行手順を詳しく伺ったところ、お客様はS3コンソールから手動で操作されていたことが判明しました。具体的には、コンソールでオブジェクトを開き、「Action」→「Edit actions」→「Edit storage class」と選択する流れです。
手動でオブジェクトのストレージクラスを変更
コンソール経由でストレージクラスを変更すると、実態としてはオブジェクトのコピーが作成されるだけで、元のオブジェクトは(バケットでバージョニングが有効な場合)旧バージョンとして残ります。
つまり、コンソール上で「ストレージクラスを編集」しても既存のクラスが変わるわけではなく、選択したストレージクラスに新しいファイルが作られているだけなのです。
このバケットではバージョニングが有効だったため、ファイルには2つのバージョンが存在する状態になっていました。Glacier Deep Archive側が現行バージョン、Standard側が非現行バージョンです。これこそが、Standardストレージのサイズが減らなかった理由でした。
ライフサイクルルール
StandardクラスにおけるS3メトリクスとCloudWatchメトリクスの差を掘り下げて調べたところ、バケットページに表示されるS3メトリクスはS3バケット内の現行ファイルの合計サイズだけを示すのに対し、CloudWatchは現行ファイルに加えて非現行バージョンや失敗したマルチパートアップロードまで含めて表示することが分かりました。
お客様が手動でストレージクラスを編集した結果、Glacier Deep Archive側に新しいコピーが現行バージョンとして置かれ、Standardストレージに残ったオブジェクトは非現行バージョンになっていたのです。
お客様としてはStandardストレージ内の非現行バージョンは不要だったため、ライフサイクルルールを設定してバケットを整理し、Standardから非現行バージョンを削除することをご提案しました。
お客様には以下のライフサイクルルールを導入していただきました。オブジェクトが非現行になってから(つまり新しいバージョンに置き換わってから)2日後に、そのオブジェクトの非現行バージョンをすべて完全に削除する、という内容です。
非現行バージョンを削除するライフサイクルルール
**実施後の効果**
5月14日にライフサイクルルールを適用したところ、S3が自動的に非現行バージョンを削除し始める様子が確認できました。
ライフサイクルルール適用後、Standardストレージが減少
このルールによってS3バケットのストレージは4.9TBから1.3TBへと大幅に削減されました。お客様のS3バケットのコスト削減につながっただけでなく、バケットのパフォーマンス向上にも寄与しています。
このシンプルな対応によって、ストレージ料金の削減とバケットパフォーマンスの最適化を同時に実現できたわけです。下のグラフでは、5月6日にGlacier Deep Archiveへの手動移行を行った際にS3コストが跳ね上がり、5月14日にライフサイクルルールを適用した後にストレージコストが下がっていく様子が見て取れます。このチャートはDoiT Cloud Navigator — Cloud Analyticsで提供されているものです。
まとめ
今回の事例は、S3バケットの運用とストレージクラス間の移行において、S3ライフサイクルルールがいかに重要かを浮き彫りにしました。手動による変更がGlacier Deep ArchiveとStandardの両方にデータを残し、不要な重複を生んでしまいましたが、ライフサイクルルールがあればこのような事態は避けられたはずです。
あわせて、S3メトリクスとCloudWatchメトリクスを併用することは、バケットの中身を正確に把握し、コスト管理とパフォーマンス最適化を進めるうえで欠かせません。
お問い合わせ
S3の最適化についてご質問がある場合や、AWSアーキテクチャのレビューをご希望の場合は、お気軽にDoiT Internationalまでご連絡ください。専門家チームがいつでも喜んでサポートいたします。