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
500
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
tessy
October 18, 2023
Tweet
Share
More Decks by tessy
See All by tessy
ALBがついに対応したmTLS認証でトラストストア、パススルーを検証してみた
tessy
0
960
Cloudflareで取得したドメインをRoute53+ACMで管理する
tessy
0
24
TerraformでEC2 Auto Scaling構築してみた
tessy
4
700
Other Decks in Technology
See All in Technology
2024春 注目のWeb系 OSS & SaaS 3選
makies
0
180
生成AIの変革の時代に、直近1年で直面した課題とその解決策
ktc_wada
0
650
LLM開発・活用の舞台裏@2024.04.25
yushin_n
3
1.2k
Amplify 🩷 Bedrock 〜生成AI入門〜
minorun365
PRO
8
680
今日からできる!簡単 .NET 高速化 Tips -2024 edition-
xin9le
7
3.9k
Improve Your Development Workflow with Gemini Code Assist
meteatamel
0
130
web-application-security
matsuihidetoshi
1
190
アクセス制御にまつわる改善 / Improving access control
itkq
0
590
LangSmith入門―トレース/評価/プロンプト管理などを担うLLMアプリ開発プラットフォーム
os1ma
5
710
コードファーストの考え方。 Amplify Gen2から学ぶAWS次世代のWeb開発体験
yoshiitaka
2
360
いいたいことちゃんという
tkengo
0
230
Google Cloud Next '24 Recap(Cloud Run/k8s)
mokocm
0
330
Featured
See All Featured
The Brand Is Dead. Long Live the Brand.
mthomps
49
29k
Principles of Awesome APIs and How to Build Them.
keavy
121
16k
Designing on Purpose - Digital PM Summit 2013
jponch
111
6.5k
Practical Orchestrator
shlominoach
183
9.7k
How GitHub (no longer) Works
holman
305
140k
Done Done
chrislema
178
15k
Rebuilding a faster, lazier Slack
samanthasiow
74
8.2k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
188
16k
Visualization
eitanlees
137
14k
Why Our Code Smells
bkeepers
PRO
331
56k
What’s in a name? Adding method to the madness
productmarketing
PRO
17
2.7k
It's Worth the Effort
3n
180
27k
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要素)
終わり