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
830
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
250
TerraformでEC2 Auto Scaling構築してみた
tessy
4
1k
Other Decks in Technology
See All in Technology
東京海上日動におけるセキュアな開発プロセスの取り組み
miyabit
0
200
【CEDEC2025】LLMを活用したゲーム開発支援と、生成AIの利活用を進める組織的な取り組み
cygames
PRO
1
1.6k
手動からの解放!!Strands Agents で実現する総合テスト自動化
ideaws
3
390
私とAWSとの関わりの歩み~意志あるところに道は開けるかも?~
nagisa53
1
130
[TechNight #91] Oracle Database 最新パフォーマンス分析手法
oracle4engineer
PRO
3
150
alecthomas/kong はいいぞ
fujiwara3
6
1.1k
Wasmで社内ツールを作って配布しよう
askua
0
150
VLMサービスを用いた請求書データ化検証 / SaaSxML_Session_1
sansan_randd
0
120
なぜAI時代に 「イベント」を中心に考えるのか? / Why focus on "events" in the age of AI?
ytake
2
800
今日からあなたもGeminiを好きになる
subaruhello
1
660
完璧を目指さない小さく始める信頼性向上
kakehashi
PRO
0
110
ML Pipelineの開発と運用を OpenTelemetryで繋ぐ @ OpenTelemetry Meetup 2025-07
getty708
0
320
Featured
See All Featured
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Into the Great Unknown - MozCon
thekraken
40
1.9k
How STYLIGHT went responsive
nonsquared
100
5.7k
Git: the NoSQL Database
bkeepers
PRO
431
65k
Designing Experiences People Love
moore
142
24k
Building a Modern Day E-commerce SEO Strategy
aleyda
42
7.4k
Automating Front-end Workflow
addyosmani
1370
200k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Balancing Empowerment & Direction
lara
1
510
Speed Design
sergeychernyshev
32
1k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.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要素)
終わり