RevComm Tech Blog

コミュニケーションを再発明し 人が人を想う社会を創る

Amazon S3 のコスト削減の計画から実施、効果測定まで

はじめに

RevComm CTO Office 高田です。 今回は RevComm が提供するクラウドIP電話サービス「MiiTel」の基盤となっている AWS のコストに関するお話です。

MiiTel は多くの音声データ・映像データを保持しているサービスになります。リリースされてから数年が経ち、またユーザも増加しサービス維持費が無視できないものとなってきました。そこでコスト削減の対象として S3 に保管されている音声データに白羽の矢が立ちました。

作業計画

最初にざっくりと作業計画を立てましょう。以下のような流れを想定しました。

  1. データの削除&低コストへの移動対象ピックアップ
  2. アプリケーションへの影響確認&改修
  3. 削除&移動の設定
  4. 効果測定

S3 のメトリクスを確認するためのツール

さて、作業に移る前にAWSのツールを確認していきましょう。 今回役立ちそうなのはこの3つです。

データの削除&低コストへの移動対象ピックアップ

MiiTelでは大きく3つのデータを保管しています。

  1. 生データ
  2. 音声解析用の中間データ
  3. UIでの再生用データ

今回はアプリケーションの仕様と相談し、 ①生データと②音声解析用の中間データを削除、③UIでの再生用データをGracier Instant Retrievalへ変更することとします。 ストレージクラスの選択はクラスメソッドさんのブログの S3 ストレージクラス選択チャートが便利でした。AWS公式のドキュメントも確認した上で参考にしましょう。

概算では費用を ⅓ くらいに抑えられそうです。

参考: https://aws.amazon.com/jp/s3/storage-classes/ https://dev.classmethod.jp/articles/should_i_choice_s3_storage_class_2023/

さて、次はどのくらいの期間を経て削除またはストレージクラスの変更をするかを決めましょう。 S3 Storage Class Analysis という機能で確認します。

画像を見ると MiiTel では30日経過後での利用以外はほぼないようです。

Storage Class Analysis 判断基準の参考画像

アプリケーションへの影響確認&改修

これまではなんらかの事情で再度解析の処理を行いたいといった場合に備え、長期間に渡り生データを保管していました。 しかしながら、今回の対応により保管期間が短くなるためエラー時の復旧や自動的なリトライをより厳密に行う必要がでました。 この対応のお話は長くなるので割愛します。

削除&移動の設定

S3 のライフサイクルを設定します。 MiiTel では 1 つの s3 bucket で先に挙げた 3 つのデータを prefix 別に管理しているため、prefixで指定してすることになります。余談ですが、イベントトリガと違いライフサイクルでは postfix が使えないことに注意しましょう。私はライフサイクルを設定するときに気付きました。

ここで注意したいのは設定次第では不可逆になりかねないことです。 特に削除に関する設定では、他の s3 bucket を用意しての動作確認は必須です。 今回はライフサイクルの適用を中間データの削除と生データの削除とで2ステップに分けて行うこととしました。

効果測定

S3 Storage Lens で残ったファイル数やサイズを確認しましょう。 また、Cost Explorer を使って実際のコストも確認します。

画像を見ると、10月の終わりに1回目のコスト減、11月の頭にGracier Instant Retrievalへ移動したことによる瞬間的なコスト増、12月の終わりに2回目のコスト減がわかります。

Cost Explorer コスト減少が見える実際の画像

ストレージクラスの変更により瞬間的なコストは発生しましたが、予想通りだいたい ⅓ になりました。 重箱の隅をつつけば、もっと削減できるかと思いますが短期間でできる対応としては十分かと思います。

終わりに

以上、RevComm で行った S3 のコスト削減の計画から実施、効果測定までと利用したツールの紹介でした。皆さまのお役に立てれば幸いです。