節約は技術!削減は芸術!何より必要なものは覚悟!
by
Masaya Hayashi
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
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
ボトルネックから潰す 「覚悟」を持つ コスト削減で重要なコト