Slide 1

Slide 1 text

2024/02/01 第1回 AWSコスト削減 天下一武道会 節約は技術!削減は芸術! 何より必要なものは覚悟! @rinchsan

Slide 2

Slide 2 text

今日のキーワード

Slide 3

Slide 3 text

ボトルネックから潰す 「覚悟」を持つ 今日のキーワード

Slide 4

Slide 4 text

目次 プロダクトの急成長 1 コスト削減もボトルネックから 2 いろいろなコスト削減 3 おまけ 4

Slide 5

Slide 5 text

CTO @SODA inc. ○ 2020年10月に入社 ○ Webエンジニア → VPoE(2022/01) → CTO(2023/10) ⇧⇧⇧ Backend Engineer @CyberAgent ○ 2019年新卒入社 バックエンドエンジニア ○ Go / AWSでサービス開発 Masaya Hayashi - @rinchsan X@rinchsan

Slide 6

Slide 6 text

プロダクトの急成長 1

Slide 7

Slide 7 text

鑑定付き 利用者数 No.1 スニーカー・トレカ フリマアプリ

Slide 8

Slide 8 text

MAU リクエスト数 デプロイ頻度 AWS月額利用料 プロダクトの急成長

Slide 9

Slide 9 text

3年で 100万人 → 500万人 MAU プロダクトの急成長

Slide 10

Slide 10 text

負荷スパイク(人気スニーカー発売など) 1万〜2万 rps リクエスト数 プロダクトの急成長

Slide 11

Slide 11 text

Monthlyで 60回 〜 90回 Dailyで 3回 〜 4.5回 デプロイ頻度 プロダクトの急成長

Slide 12

Slide 12 text

2020/02〜2022/08で $43,000 → $146,000 AWS月額利用料 プロダクトの急成長

Slide 13

Slide 13 text

コスト削減もボトルネックから 2

Slide 14

Slide 14 text

パフォーマンスチューニングの鉄則は?

Slide 15

Slide 15 text

ボトルネックから潰す ボトルネックを放置したら効果ゼロ パフォーマンスチューニングの鉄則

Slide 16

Slide 16 text

“一カ所でも大きなボトル ネックが存在していると、 システム全体の性能が大き く上がることは決してあり ません。” ISUCON本

Slide 17

Slide 17 text

“実際に存在しているボトル ネックを解消せずに、他の 事例において効果的だった 手段だけをいくら積み重ね ても効果は薄いのです。” ISUCON本

Slide 18

Slide 18 text

支配的なコストから減らす 支配的な部分を放置したら効果ゼロ コスト削減も同じく ※ パフォーマンスの議論では計算量のオーダーが違うことが多いため、それと比べるとゼロというわけではない。

Slide 19

Slide 19 text

実際にどう削減されていったか

Slide 20

Slide 20 text

2022/08 - 2023/01 $146,000 → $87,000 半年で $60,000 削減

Slide 21

Slide 21 text

施策A:$40,000削減 施策B:$12,000削減 施策C:$2,700削減 ︙ 支配的なコストから削減

Slide 22

Slide 22 text

施策A:$40,000削減 施策B:$12,000削減 施策C:$2,700削減 ︙ 支配的なコストから削減 まさにコレが Elephant in the room

Slide 23

Slide 23 text

あともう1つ重要なもの

Slide 24

Slide 24 text

覚悟

Slide 25

Slide 25 text

事業成長が大事 コストには目をつぶることも 後回しになりがち コスト削減には「覚悟」も必要 ※ 会社の文化やフェーズにもよるため、すべての会社に当てはまることではないはずです。

Slide 26

Slide 26 text

覚悟 「早く削減するほど 効果が高い」 耳が痛いですね

Slide 27

Slide 27 text

いろいろなコスト削減 3

Slide 28

Slide 28 text

まずはボトルネックを探す

Slide 29

Slide 29 text

削減金額予想が支配的なものを優先 ※ 構想段階のシートのため最終的な実施有無とは異なる部分があります。 ←サッと対応できるものもやる

Slide 30

Slide 30 text

VPC Endpoint導入:削減金額予想が最も大きいところから

Slide 31

Slide 31 text

まずは VPC Endpoint から!

Slide 32

Slide 32 text

スニダンはECS, Aurora, Elasticache, S3, ... などのオーソドックスな構成 ECS Aurora S3 Elasticache

Slide 33

Slide 33 text

VPC Endpoint導入の背景 ECS NAT Gateway ECR S3 Internet Private subnet 大量にNAT Gatewayを通っているのは主にECR/S3への通信のはず

Slide 34

Slide 34 text

数百MBytesなコンテナイメージのPullが大量に走る ECS Task起動数は35〜150個。デプロイは月に多くて100回 (=1日に5回)

Slide 35

Slide 35 text

S3/ECRに対するVPC Endpointを作成 ECS VPC Endpoint ECR S3 Private subnet NAT Gatewayの料金が $50,000 削減される見込み Private接続

Slide 36

Slide 36 text

NAT Gatewayの通信料が一気に削減!

Slide 37

Slide 37 text

ここまでで $40,000 の削減 🎉

Slide 38

Slide 38 text

あれ、 $10,000 足りない…?

Slide 39

Slide 39 text

あ!! ECR Public からの Pull が!!

Slide 40

Slide 40 text

ECS Taskの中に、ECR PublicからPullするサイドカーコンテナが ECS VPC Endpoint ECR S3 Private subnet Private接続 NAT Gateway Internet ECR Public 試算すると、予想通り $10,000 に

Slide 41

Slide 41 text

ECR pull through cache の導入

Slide 42

Slide 42 text

ECR Public をキャッシュ Privateに自前で置かなくていい キャッシュ更新でイメージタグ更新 (自動でイメージタグが変わると困ることも多いので注意です) ECR pull through cache とは

Slide 43

Slide 43 text

ECR pull through cache の利用 Pull through cache ECR Public ECS VPC Endpoint ECR S3 Private subnet Private接続 Privateな ECR 上に ECR Public のイメージがキャッシュできるように 🎉

Slide 44

Slide 44 text

今度こそNAT Gatewayの通信量を大幅に削減!

Slide 45

Slide 45 text

ここまでで $52,000 の削減 🎉

Slide 46

Slide 46 text

次のボトルネックを探す

Slide 47

Slide 47 text

次のボトルネックを探す

Slide 48

Slide 48 text

WAFのログ配信先変更

Slide 49

Slide 49 text

WAFのログ配信先をCloudwatch LogsからS3へ Cloudwatch Logsに比べると可視化・分析は難しくなることに注意 ログ Cloudwatch Logs WAF ログ S3 WAF

Slide 50

Slide 50 text

ここまでで $54,700 の削減 🎉

Slide 51

Slide 51 text

次のボトルネック探しの旅へ...

Slide 52

Slide 52 text

不要リソースの削除 Gravitonインスタンスの利用 Auto-scaling policyの見直し 他にもいくつか細かいコスト削減を

Slide 53

Slide 53 text

不要リソースの削除 Gravitonインスタンスの利用 Auto-scaling policyの見直し 他にもいくつか細かいコスト削減を

Slide 54

Slide 54 text

アタッチされてないEIP削除 使われていない環境を削除 (EC2, ECS, Aurora, Elasticache…) 不要リソースの削除

Slide 55

Slide 55 text

不要リソースの削除 Gravitonインスタンスの利用 Auto-scaling policyの見直し 他にもいくつか細かいコスト削減を

Slide 56

Slide 56 text

Intelに比べてコスト効率20%向上 データストア系のみに適用 (ECSはARMで動くかの検証が必要でPendに) Gravitonインスタンスの利用

Slide 57

Slide 57 text

不要リソースの削除 Gravitonインスタンスの利用 Auto-scaling policyの見直し 他にもいくつか細かいコスト削減を

Slide 58

Slide 58 text

Step-scalingのしきい値調整 Target-tracking scalingの検証 Scheduled-scalingの設定調整 余分なECS/Auroraインスタンスが起動しないように

Slide 59

Slide 59 text

最終的に $60,000 の削減 🎉

Slide 60

Slide 60 text

おまけ 4

Slide 61

Slide 61 text

CloudFront の Request-Collapsing

Slide 62

Slide 62 text

CloudFront Request-Collapsing(リクエスト折りたたみ)とは CloudFront ALB S3 Origin接続 Users Originへのリクエストを最低回数に折りたたんでくれる https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorCustomOrigin.html#request-custom-traffic-spikes

Slide 63

Slide 63 text

ALB スニダンの課題:スパイク時の負荷が高くて大変! Users スパイクすると 2万rps くらいに跳ねる 💣💥 Aurora Elasticache ECS

Slide 64

Slide 64 text

スニダンではALBの前段にCloudFrontを設置して、Request-Collapsingの準備 CloudFront ALB ECS Route53の加重ルーティングを利用してダウンタイムなしで移行 👏

Slide 65

Slide 65 text

TTLが1秒のキャッシュポリシーを設定

Slide 66

Slide 66 text

TTL 1秒でも意外に高いキャッシュヒット率 対象エンドポイントのキャッシュヒット率は約12%に 🎉

Slide 67

Slide 67 text

Datadog APMから見たリクエスト数も大きく削減され、ECSやAuroraへの負荷が軽減 🎉 対象エンドポイントのリクエスト数も約半分に

Slide 68

Slide 68 text

もちろんコスト削減も

Slide 69

Slide 69 text

2023/06 - 2023/09 $26,400 → $24,300 DataTransfer + CloudFront が $2,100 削減 ※ コスト削減はメインの目的ではありませんでしたが、ある程度の削減に成功 🎉

Slide 70

Slide 70 text

ユーザ体験も改善しつつコスト削減も 🎉

Slide 71

Slide 71 text

まとめ

Slide 72

Slide 72 text

ボトルネックから潰す 「覚悟」を持つ コスト削減で重要なコト

Slide 73

Slide 73 text

支配的コストを放置すると効果ゼロ まずは作戦を練るところから ボトルネックから潰す ※ パフォーマンスの議論では計算量のオーダーが違うことが多いため、それと比べるとゼロというわけではない。

Slide 74

Slide 74 text

コスト削減は後回しになりがち 削減しないと削減されない (あたりまえ) 「覚悟」を持つ

Slide 75

Slide 75 text

ボトルネックから潰す 「覚悟」を持つ コスト削減で重要なコト