SREとソフトウェア開発者の合同チームはどのようにS3のコストを削減したか？

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. 自己紹介吉澤政洋 @muziyoshiz ● 2017年8月からSRE ● 2023年3月にアンドパッド入社 ○ インフラセキュリティ ○ インフラコスト可視化・最適化 ○ SREチームの社外発信・イベント参加の主導 ● SREコミュニティのスタッフ経験あり ○ SRE NEXT（2020〜2023）のコアスタッフ ○ Tamachi.sreのスタッフ ● 趣味はボルダリング 2

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

S3のコスト削減の背景

Slide 6

Slide 6 text

現場の効率化から経営改善まで一元管理できる建設DX プロジェクト管理サービス

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. マルチプロダクト戦略、多数の開発チーム 9 Frontend Backend Native App QA Frontend Backend QA Frontend Backend Native App 開発チームA 開発チームB 開発チームC Frontend Backend 開発チームD 横断的な関心事を扱うチーム（SRE, DBRE, CRE, セキュリティ, インフラコストマネジメントなど）

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. インフラコスト削減の取り組み ● 2024年6月にSREとソフトウェア開発者の合同チームを結成し、「インフラコストマネジメントプロジェクト」を開始 ○ SRE 1名（発表者、SREチームと兼務） ○ ソフトウェア開発者 1〜2名（時期により増減） ● 2025年3月時点で当初のコスト削減目標を達成し、現在はインフラコスト削減と並行して、FinOpsの土台作りを進めている ● 今回の発表では、このプロジェクトで行ったインフラコスト削減のうち、 S3のコスト削減に絞って紹介する 11

Slide 12

Slide 12 text

Slide 13

Slide 13 text

S3のコストが高かった理由

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. システム構成(1)：モノリシックなバケット ● 複数プロダクトから利用されているバケットA（東京）とそのレプリケーション先バケットA-replica（米国）で、S3のコストの8割以上を占める ● バケットAには大量のファイル（主に写真）がアップロードされる ● レプリケーション先バケットは、東京リージョンの障害発生時に用いるもので、通常時はアクセスされない 16 バケットA バケットA-replica レプリケーション

Slide 17

Slide 17 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. システム構成(2)：写真のサムネイル生成 17 ● プロダクトによって必要なサムネイルのサイズが異なるため、写真1枚に対して、8種類のサムネイルを非同期ジョブ（Sidekiq）で自動生成する ● Sidekiqのサムネイル生成が終わるまで（数秒程度）は、Lambda@Edgeでオンデマンド生成したサムネイルを返す（図中では省略）バケットA アプリケーションサーバ（Rails）ジョブサーバ（Sidekiq）写真アップロードユーザー写真ダウンロード・サムネイル生成ジョブ登録

Slide 18

Slide 18 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. システム構成(3)：レプリケーションとStandard-IA移行 ● 長期保存にかかるストレージ料金の削減のため、レプリケーションルールで、ストレージクラスをStandardからStandard-IA（標準 - 低頻度アクセス）に移行する ● サムネイルは128KB未満のファイルが多いため、サムネイルはStandard-IAに移行することで、かえってストレージ料金が上がっていた 18 バケットA バケットA-replica レプリケーション時に Standard-IA移行

Slide 19

Slide 19 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. 付録：Standard-IAの料金料金ページの説明 19 S3 標準 – IA および S3 1 ゾーン – IA ストレージの課金対象最小オブジェクトサイズは 128 KB です。128 KB より小さいサイズのオブジェクトを保存することもできますが、適切なストレージクラス料金で 128 KB のストレージとして課金されます。例：30KBのサムネイル10,000,000件（約28.6GB） ● Standardなら、28.6*0.025=$0.715/月 ● Standard-IAなら、(28.6+934.6)*0.0138=$13.292/月 ○ 128KBに達しなかった分が (128-30)*10000000/1024/1024=934.6GBあるため

Slide 20

Slide 20 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. システム構成(4)：S3から他サービスの呼び出し ● PUTされるオブジェクトの数だけ、以下の呼び出しも増える ○ CloudTrailのデータイベント配信 → GuardDuty S3 Protection ○ EventBridge → SQS → ECS（ウイルススキャン、Antivirus for Amazon S3） ● ウイルススキャンのためのオブジェクトタグもコスト増につながっていた 20 バケットA CloudTrail GuardDuty S3 Protection EventBridge SQS ECS （ウイルススキャン）

Slide 21

Slide 21 text

ソフトウェア開発者と合同で実施した対策

Slide 22

Slide 22 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. 理由1（大量の写真およびサムネイル）への対策 ● レプリケーションバケット先からサムネイルを削除する → 断念 ○ 写真からサムネイルを再生成するバッチ処理を試作し、実行時間を計測したところ、現実的な時間で復旧できないことがわかった ● 使われていないサムネイル2種類の削除 → 採用 ○ ソースコードおよびアクセスログの調査結果から、8種類のうち2種類は全く使われていないことを発見 ○ 2015年から(!)生成されていたが、結局今まで使われていなかった ● アクセス頻度が低いサムネイル2種類のオンデマンド生成 → 採用 ○ アクセスログの調査結果から、8種類のうち2種類はアクセス頻度が低いことを発見 ○ 性能測定およびプロダクトチームとの調整の結果、この2種類をオンデマンド生成に変えても、そのプロダクトが求めるサービスレベルを満たすことを確認できた 22

Slide 23

Slide 23 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. 理由2（非効率なストレージクラス移行）への対策 ● Standard-IAへの移行を止める → 断念 ○ バケットAには多数のファイルが混在している。サムネイル以外はStandard-IAのほうが安く、総合的に見てコスト削減効果は低いことがわかった ● サムネイルのみ移行するストレージクラスの変更 → 断念 ○ レプリケーションルールを分けるためには、サムネイルだけ特定のパスに切り出す必要がある ○ そのためには、サムネイル生成に使用するgem（CarrierWave）の修正 or リプレースが必要で、すぐには難しいことがわかった ● 理由2への対策は断念したが、理由1への対策でサムネイルが減れば、間接的に、非効率なストレージクラス移行の影響も小さくなる 23

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. 大量のS3オブジェクト削除時の課題 ● Rate Limitによるサービス影響 ○ ドキュメントには「パーティショニングされた Amazon S3 プレフィックスごとに毎秒 3,500 回以上の PUT/COPY/POST/DELETE リクエスト」とある ○ S3 DeleteObjects APIで1,000件削除すると、1,000回のDELETEリクエスト扱い ○ 最初から 3,500件/秒で削除できるわけではなく、徐々にスケーリングする。それまでは 503 (Slow Down) エラーが頻発する ● DELETEリクエストに伴う一時的なコストの発生 ○ DELETEリクエスト自体は無料 ○ CloudTrail、GuardDuty S3 Protection、Detectiveなどのコストが発生 ○ 特にCloudTrailは、2025年6月からS3 DeleteObjects API（最大1,000オブジェクトの一括削除）のロギングが強化された結果、ログが増加した ○ CloudTrailのログ数は、GuardDuty S3 ProtectionとDetectiveのコストにも影響 25

Slide 26

Slide 26 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. 内製スクリプトをECSタスクで実行 ● S3 DeleteObjects API を用いて 200件/秒 × 10スレッドで削除 ○ 何パターンか試した結果、これなら503の発生頻度が十分低くなると判断 ○ 速度よりもサービス影響の小ささを優先 ○ それでも5xxが返ることはあるため、リトライ処理は必須 ● 削除したいオブジェクトのリストを事前に作成し、各スレッドに渡す ○ 各スレッドが、なるべく異なるパーティションのオブジェクトを削除するように、削除したいファイルをプレフィックスに基づいて10分割 ● CloudTrail、GuardDuty、Detectiveなどの一時的なコストについては、ストレージ料金の削減によって短期間で回収できることを事前に確認 26

Slide 27

Slide 27 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. 余談：S3 Batch Operationsを使わなかったのはなぜ？ ● S3 Batch Operationsで削除する場合、以下のステップで行う ○ ステップ1. 削除したいオブジェクトに、S3 Batch Operationsでタグを付与 ○ ステップ2. 上記のタグを対象としたライフサイクルルールを作成 ● この方法の問題 ○ オブジェクトタグ付与のためのPUTリクエストのコストがかかる ○ 少なめのファイルで試したところ、S3 Batch Operationsは503エラーが返るまで最大速度でリクエスト送信し、503が返されたら速度を下げるように見えた。サービス影響の懸念があり、断念 27

Slide 28

Slide 28 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. サムネイルのオンデマンド生成 ● アクセス頻度が低いサムネイル2種類については常にLambda@Edge用のURLを返すように、アプリケーションを修正 ● オンデマンド生成したサムネイルは専用のバケットに保存 ○ この専用バケットはレプリケーションせず、古いサムネイルはライフサイクルルールで削除する ● 安定動作の確認後、このサムネイル2種類のSidekiqでの生成を停止 28

Slide 29

Slide 29 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. 改善後のシステム構成 29 アクセス頻度が高いサムネイル（ 4種類）アクセス頻度が低いサムネイル（ 2種類）バケットA バケットA-replica レプリケーションユーザー CloudFront サムネイル専用バケットユーザー CloudFront バケットA Lambda@Edge 写真を取得サムネイルを保存（以後のアクセスで再利用）レプリケーション不要

Slide 30

Slide 30 text

コスト削減効果

Slide 31

Slide 31 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. コスト削減効果の試算 ● 実測による、正確なコスト削減効果の確認は難しい ○ 1年間を通して、段階的に施策を実施した（今回紹介した方法以外もある） ○ その間もサービス成長に伴いコストが増加している ● S3のインベントリから取得した 2024年12月時点の合計ファイルサイズ・合計ファイル数に基づいて、今回紹介した対策のコスト削減効果を試算した 31

Slide 32

Slide 32 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. コスト削減効果（S3） ● 今回紹介した対策で、S3のコストを約15.3%削減できた ● レプリケーション先バケット（Standard-IA）のコスト削減が特に大きかった 32 使用タイプ内容コスト削減率 APN1-TimedStorage-ByteHrs 東京リージョンの Standard のストレージ料金 20.7% USW2-TimedStorage-SIA-ByteHrs 米国リージョンの Standard-IA のストレージ料金 23.5% USW2-TimedStorage-SIA-SmObjects 米国リージョンの Standard-IA のストレージ料金（128KB 未満） 41.4% 全体 15.3%

Slide 33

Slide 33 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. コスト削減効果（CloudTrail） ● 今回紹介した対策で、PUTされるオブジェクト数が減った結果、 CloudTrailのコストも約16.5%削減できた ● 東京リージョンのほうがコスト削減率が高いのは、レプリケーション元バケットのみウイルススキャンシステムによるアクセスが発生するため 33 使用タイプ内容コスト削減率 APN1-DataEventsRecorded 東京リージョンへのデータイベントの配信料金 17.7% USW2-DataEventsRecorded 米国リージョンへのデータイベントの配信料金 12.5% 全体 16.5%

Slide 34

Slide 34 text

Slide 35

Slide 35 text

再発防止に向けた取り組み

Slide 36

Slide 36 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. 開発チームへの問題の周知とお願い ● 不必要なデータをS3に保存することによって、思わぬコストが発生している（レプリケーション元バケットのストレージ料金だけでは済まない） ● 将来必要かもしれないデータを事前に作成する場合は、一定期間後に見直しを行い、不要な場合には削除してほしい ● 小さいファイルを大量に保存する場合は、レプリケーションのことを考えて、他のファイルとはバケットやパスを分けてほしい 36

Slide 37

Slide 37 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. 「コスト版ポストモーテム」という新しい取り組み ● 本来不必要なコストが発生した事例をドキュメントにまとめて、開発チームに向けて共有する取り組みを開始した ● アンドパッドはすでにポストモーテムを実践しているため、ポストモーテムを知っている人にとって理解しやすいように、この新たな取り組みを「コスト版ポストモーテム」と名付けた ● 詳しくは、プロポーザルが通ったら SRE Kaigi 2026 にて 37

Slide 38

Slide 38 text

まとめ

Slide 39

Slide 39 text

Copyright © 2025 ANDPAD Inc. All Rights Reserved. まとめ ● 不適切なアーキテクチャは思わぬコスト増に繋がることがある ● SREに加え、プロダクトに詳しいソフトウェア開発者の協力を得ることで、アーキテクチャの改善によるインフラコスト削減を実施できた ● 不適切なアーキテクチャによる問題の再発を防ぐために、ソフトウェア開発者へのナレッジ共有や、FinOpsの土台作りを進めている 39