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
860
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
EC2 AutoScalingでスケーリングポリシー設定を失敗してうまく行かなった件とその対策
tessy
October 18, 2023
Tweet
Share
More Decks by tessy
See All by tessy
ALBがついに対応したmTLS認証でトラストストア、パススルーを検証してみた
tessy
1
3.6k
Cloudflareで取得したドメインをRoute53+ACMで管理する
tessy
1
300
TerraformでEC2 Auto Scaling構築してみた
tessy
4
1.1k
Other Decks in Technology
See All in Technology
[CV勉強会@関東 ICCV2025] WoTE: End-to-End Driving with Online Trajectory Evaluation via BEV World Model
shinkyoto
0
270
【M3】攻めのセキュリティの実践!プロアクティブなセキュリティ対策の実践事例
axelmizu
0
160
re:Invent2025 事前勉強会 歴史と愉しみ方10分LT編
toshi_atsumi
0
130
[mercari GEARS 2025] Keynote
mercari
PRO
1
280
Proxmox × HCP Terraformで始めるお家プライベートクラウド
lamaglama39
1
210
改竄して学ぶコンテナサプライチェーンセキュリティ ~コンテナイメージの完全性を目指して~/tampering-container-supplychain-security
mochizuki875
1
250
マイクロリブート ~ACEマインドセットで実現するアジャイル~
sony
1
390
自己的售票系統自己做!
eddie
0
460
Kubernetesと共にふりかえる! エンタープライズシステムのインフラ設計・テストの進め方大全
daitak
0
250
今、MySQLのバックアップを作り直すとしたら何がどう良いのかを考える旅
yoku0825
2
390
AWS オブザーバビリティサービスアップデート
o11yfes2023
0
120
アジャイル社内普及ご近所さんマップを作ろう / Let's create an agile neighborhood map
psj59129
1
130
Featured
See All Featured
Product Roadmaps are Hard
iamctodd
PRO
55
12k
Done Done
chrislema
186
16k
Optimizing for Happiness
mojombo
379
70k
Into the Great Unknown - MozCon
thekraken
40
2.2k
Principles of Awesome APIs and How to Build Them.
keavy
127
17k
Building Applications with DynamoDB
mza
96
6.8k
Why Our Code Smells
bkeepers
PRO
340
57k
Bash Introduction
62gerente
615
210k
KATA
mclloyd
PRO
32
15k
Rebuilding a faster, lazier Slack
samanthasiow
84
9.3k
Side Projects
sachag
455
43k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.3k
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要素)
終わり