【AWS】S3への通信量削減の手法

便利なストレージサービスであるS3を皆さん使っていますか…!?

静的コンテツの配信サーバーの役割をこなしたり、イレブンナインの耐久性を持ったストレージサービスといった点からAWSの中でも大好きなサービスです。

便利が故にコスト面でネックになってしまう状況が多々あるかと思いましたので、個人的に経験したコストダウンの設計手法をご紹介したいと思いますー！

手始めに

まず初めにS3に関わる費用のざっくりとした内訳を確認しておきましょう。

• ストレージ
• データ転送（IN/OUT）
• セキュリティコントロール
• レプリケーション
• etc...

一般的な運用を想定すると ストレージ と データ転送 が費用の大部分を占めるはずです。

その中でストレージに関しては、
不必要なデータを置かない, データのライフサイクルを短くする, ストレージクラスを最適なものに設定するなどはありますが、S3にどのようなデータを置くかは各システムで要件が異なってくるため、費用の削減はあまり期待できません。

そうなってくるとデータ転送の部分でコストを最適化するのが必要になってきます。

通信量削減の取り組み

イメージ図

やりたいこと

S3に゙保管しているコンテンツを毎回S3からダウンロードすることを辞めるための設計です。

これにより、キャッシュを用いてS3からの転送量を大幅に減らすことができます。（サイトへのアクセスが多ければ多いほど今回の設計は意味を増してくると思います。

添付した画像のフローを改めて文字に起こします。

1. ページアクセス後に、必要なViewやCSS、画像などがリクエストされます。
2. まずアプリケーションサーバー（EC2）にコンテンツがキャッシュされているか確認します。
3. キャッシュに存在する場合は、そのままレスポンスを返します（転送料金が発生しません）。
4. キャッシュに存在しない場合は、S3からコンテンツを取得し、その後キャッシュします（S3へのアクセスを減らす）。

ChatGPT に計算してもらった

### 東京リージョン（Asia Pacific (Tokyo)）でのS3のデータ転送料金

2023年9月現在、東京リージョンでのS3のデータ転送料金は次の通りです：

- 最初の1GB: **無料**
- 1GB～10TBまでのデータ転送: **$0.114/GB**

これに基づいて、東京リージョンでの転送料金削減を計算します。

### 仮定
- 1回のアクセスでS3からダウンロードされるデータの量：**1MB**
- 1日のアクセス数：**10,000回**
- キャッシュ成功率：**80%**
- 東京リージョンでのS3データ転送料金：**$0.114/GB**

### 計算式（東京リージョン）
1MBのデータが10,000回ダウンロードされる場合：
```
1MB × 10,000 = 10,000MB = 10GB
```

#### S3へのアクセスがない場合のコスト（全アクセスがS3の場合）
```
10GB × 0.114 = $1.14
```

#### キャッシュ導入後のコスト
キャッシュ成功率80%の場合、S3へのアクセスが20%：
```
10,000 × 0.2 = 2,000回
```

2,000回分のダウンロードデータ量：
```
1MB × 2,000 = 2,000MB = 2GB
```

これに対する転送料金：
```
2GB × 0.114 = $0.228
```

#### 削減額
S3にすべてのリクエストを送る場合のコストは**$1.14**、キャッシュを利用した場合のコストは**$0.228**。
したがって、削減できる金額は：
```
$1.14 - $0.228 = $0.912
```

### 結論
キャッシュを使うことで、東京リージョンの場合は、
1日あたり約**$0.912**の転送料金削減が見込めます。

これを1ヶ月（30日）分に換算すると、約**$27.36**の削減が期待できます。

もちろん、アクセス数やキャッシュ成功率、ダウンロードデータのサイズによって結果は変わりますが、
このざっくりとした計算での削減効果は**80%**程度です。

注意点①

キャッシュクリアの方法を適切に設定しない場合、全てのコンテンツリクエストがキャッシュデータを返却してしまいます。

各方面から以下のようなお叱りが届いてしまうので、今回ご紹介した設計を取る場合は、しっかりとキャッシュクリアの戦略を練りましょう。。。

エンドユーザー

ユーザーから保存したデータが古いままなんだけどどうなってるの!?

注意点②

アプリケーションサーバーにコンテンツを配置するので、アプリケーションサーバー自体のストレージを圧迫する可能性が大いにあります。
アプリケーションサーバーのストレージを外部に移す目的でS3を導入している場合は、今回の手法は取れないので、CDNサービス等を用いてキャッシュさせるのも一つの手になってくると思います。

注意点③

注意点②と同様にアプリケーションサーバーにコンテンツを配置するが故の問題として、センシティブなデータをアプリケーションサーバーに配置する可能性があります。
例： 個人情報の類のコンテンツ（運転免許証、何らかの明細）

これらを一時的にではありますが、アプリケーションサーバーに配置するのがシステム要件的にNGの場合は、絶対に今回の手法は取れません！

最後に

ちょいとした工夫でコストダウンを見込めますので、皆さんも試してみて欲しいですー！

システムの要件等で導入できなければごめんさい！！