Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
Search
tessy
October 18, 2023
Technology
0
700
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
tessy
October 18, 2023
Tweet
Share
More Decks by tessy
See All by tessy
ALBがついに対応したmTLS認証でトラストストア、パススルーを検証してみた
tessy
0
2.3k
Cloudflareで取得したドメインをRoute53+ACMで管理する
tessy
0
100
TerraformでEC2 Auto Scaling構築してみた
tessy
4
880
Other Decks in Technology
See All in Technology
エンジニア人生の拡張性を高める 「探索型キャリア設計」の提案
tenshoku_draft
1
120
なぜ今 AI Agent なのか _近藤憲児
kenjikondobai
4
1.4k
Adopting Jetpack Compose in Your Existing Project - GDG DevFest Bangkok 2024
akexorcist
0
110
AWS Lambda のトラブルシュートをしていて思うこと
kazzpapa3
2
170
RubyのWebアプリケーションを50倍速くする方法 / How to Make a Ruby Web Application 50 Times Faster
hogelog
3
940
適材適所の技術選定 〜GraphQL・REST API・tRPC〜 / Optimal Technology Selection
kakehashi
1
170
AIチャットボット開発への生成AI活用
ryomrt
0
170
Amazon CloudWatch Network Monitor のススメ
yuki_ink
1
200
Making your applications cross-environment - OSCG 2024 NA
salaboy
0
180
ハイパーパラメータチューニングって何をしているの
toridori_dev
0
140
Lambdaと地方とコミュニティ
miu_crescent
2
370
Terraform CI/CD パイプラインにおける AWS CodeCommit の代替手段
hiyanger
1
240
Featured
See All Featured
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
47
2.1k
Writing Fast Ruby
sferik
627
61k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
We Have a Design System, Now What?
morganepeng
50
7.2k
Designing for humans not robots
tammielis
250
25k
Git: the NoSQL Database
bkeepers
PRO
427
64k
Six Lessons from altMBA
skipperchong
27
3.5k
Music & Morning Musume
bryan
46
6.2k
KATA
mclloyd
29
14k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
364
24k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Transcript
EC2 AutoScalingでスケーリングポリシー設定を 失敗してうまく⾏かなった件とその対策 ⽇本IBM ⼿嶋 達也 2023/10/18
⾃⼰紹介 @tterima Teshima-Tatsuya 主なAWS資格
⽬次 • 構成 • オートスケーリングの設定 • 何がダメだったのか • 解決⽅法
構成
オートスケーリング要件 オートスケーリンググループ内の 平均CPU利⽤率での スケールイン・スケールアウト サーバ個別の メモリ利⽤率での スケールイン・スケールアウト
結果 分かりますか 負荷急上昇!!
パヤ…パヤ… 起動 停⽌ 起動 停⽌ ❌ ❌
何がダメだったのか? CPU ↑ メモリ↓ うわ、負荷上昇中や アラーム上げるで インスタンス増加や よっしゃ、低負荷や アラーム上げるで インスタンス削減や
何がダメだったのか? CPU ↑ メモリ↓ うわ、負荷上昇中や アラーム上げるで インスタンス増加や インスタンス増加が成⽴している場合は インスタンス増加を優先したい! よっしゃ、低負荷や
アラーム上げるで インスタンス削減や
解決⽅法は? 複合条件でポリシーを 設定したいな。 でも、複合条件のポリシーは 作れない。。 詰んだ。。。?
皆さんなら どう考えますか?
解決⽅法(1/2) オートスケーリングポリシーなんて邪道!! Lambdaで無理やり頑張る!! 1.LambdaでCloudWatchメトリクスを取得 2.CPU,メモリ使⽤率のうち、上昇している項⽬のみ抽出 3.スケールアウト発動!
解決⽅法(2/2) CloudWatchアラームには複合アラームがある。 これで、いずれか⼀⽅が負荷上昇中ものを判定 →スケールアウト発動! OR
解決したけどそれで⼤丈夫?
解決したけどそれで⼤丈夫? そもそもCPUとメモリで複合アラームを設定すべきなのか? メモリに関しては、⼀定以上の閾値を超える場合はメモリリーク を起こしている可能性が⾼い。 →インスタンス再起動が最善⼿の可能性もある。 このあたりはしっかりと、メトリクスを計測して、継続して改善 案を探していきましょう!(申し訳程度のSRE要素)
終わり