Tweet
Tweet

Slide 1

Slide 1 text

EC2 AutoScalingでスケーリングポリシー設定を 失敗してうまく⾏かなった件とその対策 ⽇本IBM ⼿嶋 達也 2023/10/18

Slide 2

Slide 2 text

⾃⼰紹介 @tterima Teshima-Tatsuya 主なAWS資格

Slide 3

Slide 3 text

⽬次 • 構成 • オートスケーリングの設定 • 何がダメだったのか • 解決⽅法

Slide 4

Slide 4 text

構成

Slide 5

Slide 5 text

オートスケーリング要件 オートスケーリンググループ内の 平均CPU利⽤率での スケールイン・スケールアウト サーバ個別の メモリ利⽤率での スケールイン・スケールアウト

Slide 6

Slide 6 text

結果 分かりますか 負荷急上昇！！

Slide 7

Slide 7 text

パヤ…パヤ… 起動 停⽌ 起動 停⽌ ❌ ❌

Slide 8

Slide 8 text

何がダメだったのか？ CPU ↑ メモリ↓ うわ、負荷上昇中や アラーム上げるで インスタンス増加や よっしゃ、低負荷や アラーム上げるで インスタンス削減や

Slide 9

Slide 9 text

何がダメだったのか？ CPU ↑ メモリ↓ うわ、負荷上昇中や アラーム上げるで インスタンス増加や インスタンス増加が成⽴している場合は インスタンス増加を優先したい！ よっしゃ、低負荷や アラーム上げるで インスタンス削減や

Slide 10

Slide 10 text

解決⽅法は？ 複合条件でポリシーを 設定したいな。 でも、複合条件のポリシーは 作れない。。 詰んだ。。。？

Slide 11

Slide 11 text

皆さんなら どう考えますか？

Slide 12

Slide 12 text

解決⽅法（1/2） オートスケーリングポリシーなんて邪道！！ Lambdaで無理やり頑張る！！ １．LambdaでCloudWatchメトリクスを取得 ２．CPU,メモリ使⽤率のうち、上昇している項⽬のみ抽出 ３．スケールアウト発動！

Slide 13

Slide 13 text

解決⽅法（2/2） CloudWatchアラームには複合アラームがある。 これで、いずれか⼀⽅が負荷上昇中ものを判定 →スケールアウト発動！ OR

Slide 14

Slide 14 text

解決したけどそれで⼤丈夫？

Slide 15

Slide 15 text

解決したけどそれで⼤丈夫？ そもそもCPUとメモリで複合アラームを設定すべきなのか？ メモリに関しては、⼀定以上の閾値を超える場合はメモリリーク を起こしている可能性が⾼い。 →インスタンス再起動が最善⼿の可能性もある。 このあたりはしっかりと、メトリクスを計測して、継続して改善 案を探していきましょう！（申し訳程度のSRE要素）

Slide 16

Slide 16 text

終わり