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
850
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
tessy
October 18, 2023
Tweet
Share
More Decks by tessy
See All by tessy
ALBがついに対応したmTLS認証でトラストストア、パススルーを検証してみた
tessy
1
3.5k
Cloudflareで取得したドメインをRoute53+ACMで管理する
tessy
1
280
TerraformでEC2 Auto Scaling構築してみた
tessy
4
1.1k
Other Decks in Technology
See All in Technology
COVESA VSSによる車両データモデルの標準化とAWS IoT FleetWiseの活用
osawa
1
380
「全員プロダクトマネージャー」を実現する、Cursorによる仕様検討の自動運転
applism118
22
12k
2025/09/16 仕様駆動開発とAI-DLCが導くAI駆動開発の新フェーズ
masahiro_okamura
0
120
エンジニアが主導できる組織づくり ー 製品と事業を進化させる体制へのシフト
ueokande
1
100
Firestore → Spanner 移行 を成功させた段階的移行プロセス
athug
1
500
Automating Web Accessibility Testing with AI Agents
maminami373
0
1.3k
今日から始めるAWSセキュリティ対策 3ステップでわかる実践ガイド
yoshidatakeshi1994
0
110
エンジニアリングマネージャーの成長の道筋とキャリア / Developers Summit 2025 KANSAI
daiksy
3
890
Claude Code でアプリ開発をオートパイロットにするためのTips集 Zennの場合 / Claude Code Tips in Zenn
wadayusuke
5
840
Modern Linux
oracle4engineer
PRO
0
160
Unlocking the Power of AI Agents with LINE Bot MCP Server
linedevth
0
110
複数サービスを支えるマルチテナント型Batch MLプラットフォーム
lycorptech_jp
PRO
1
890
Featured
See All Featured
Reflections from 52 weeks, 52 projects
jeffersonlam
352
21k
Unsuck your backbone
ammeep
671
58k
How to Ace a Technical Interview
jacobian
279
23k
Typedesign – Prime Four
hannesfritz
42
2.8k
Rebuilding a faster, lazier Slack
samanthasiow
83
9.2k
How GitHub (no longer) Works
holman
315
140k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
127
53k
It's Worth the Effort
3n
187
28k
Site-Speed That Sticks
csswizardry
10
820
Producing Creativity
orderedlist
PRO
347
40k
Scaling GitHub
holman
463
140k
Fireside Chat
paigeccino
39
3.6k
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要素)
終わり