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
820
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
tessy
October 18, 2023
Tweet
Share
More Decks by tessy
See All by tessy
ALBがついに対応したmTLS認証でトラストストア、パススルーを検証してみた
tessy
1
3.4k
Cloudflareで取得したドメインをRoute53+ACMで管理する
tessy
0
240
TerraformでEC2 Auto Scaling構築してみた
tessy
4
1k
Other Decks in Technology
See All in Technology
AWS Organizations 新機能!マルチパーティ承認の紹介
yhana
1
220
あなたの声を届けよう! 女性エンジニア登壇の意義とアウトプット実践ガイド #wttjp / Call for Your Voice
kondoyuko
4
510
Claude Code Actionを使ったコード品質改善の取り組み
potix2
PRO
6
2.6k
事業成長の裏側:エンジニア組織と開発生産性の進化 / 20250703 Rinto Ikenoue
shift_evolve
PRO
1
390
Tokyo_reInforce_2025_recap_iam_access_analyzer
hiashisan
0
140
AI導入の理想と現実~コストと浸透〜
oprstchn
0
150
Lambda Web Adapterについて自分なりに理解してみた
smt7174
5
140
GitHub Copilot の概要
tomokusaba
1
150
生成AI時代 文字コードを学ぶ意義を見出せるか?
hrsued
1
730
整頓のジレンマとの戦い〜Tidy First?で振り返る事業とキャリアの歩み〜/Fighting the tidiness dilemma〜Business and Career Milestones Reflected on in Tidy First?〜
bitkey
0
380
PHPでWebブラウザのレンダリングエンジンを実装する
dip_tech
PRO
0
220
KubeCon + CloudNativeCon Japan 2025 Recap Opening & Choose Your Own Adventureシリーズまとめ
mmmatsuda
0
230
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
How STYLIGHT went responsive
nonsquared
100
5.6k
Navigating Team Friction
lara
187
15k
The Cost Of JavaScript in 2023
addyosmani
51
8.5k
Building Adaptive Systems
keathley
43
2.6k
VelocityConf: Rendering Performance Case Studies
addyosmani
331
24k
Building Applications with DynamoDB
mza
95
6.5k
Optimizing for Happiness
mojombo
379
70k
Improving Core Web Vitals using Speculation Rules API
sergeychernyshev
17
950
Java REST API Framework Comparison - PWX 2021
mraible
31
8.7k
For a Future-Friendly Web
brad_frost
179
9.8k
The Straight Up "How To Draw Better" Workshop
denniskardys
234
140k
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要素)
終わり