ECS에서 Auto Scoling Policy의 Target Specification 및 STEP 정보
배율 유형
두 가지가 있는데 구분 사용이 잘 안 돼서 조사를 했습니다.
유사한 결론의 물건
다음과 같은 구분이 있는 것 같습니다.
通常のスケールアウト・イン → ターゲット追跡スケーリング
負荷スパイク時のスケールアウト・イン → ステップスケーリング
먼저 Target Track 확대/축소 설정
필요에 따라 보진식 고리라는 형식을 토론해도 되겠습니까?
두 가지 배율 유형 피쳐
이쪽 기사는 알기 쉬워서 옮겨 싣습니다.
### ステップスケーリング
指定した閾値に基づいてスケールアウト/インを行うオートスケールです。
スケールアウト/インを段階的に定義できるのが特徴で、例えば以下のような設定が可能です。
CPUの平均使用率が61-70% -> コンテナを1つ増やす
CPUの平均使用率が71-80% -> コンテナを3つ増やす
CPUの平均使用率が81%以上 -> コンテナを5つ増やす
CPUの平均使用率が50%以下 -> コンテナを1つ減らす
適切な値を設定する難易度は低くないですが、うまく使うとリソースを急激に変化させることができます。
### ターゲットスケーリング
指定したメトリクスが指定した数値になるようにスケールアウト/インを行うオートスケールです。
イメージとしてはKubernetesのHorizontal Pod Autoscalerが近いと思います。
例えばCPUの平均使用率が60%となるように指定した場合
CPUの平均使用率が70% -> スケールアウト
CPUの平均使用率が50% -> スケールイン
というような振る舞いをし、CPUの平均使用率が60%になるように努めてくれます
オートスケールの設定をする時にみなさん頭を悩ませるのがスケールインの閾値だと思いますが、これをある程度いい感じにやってもらえるのが便利です。
축척 유형의 중요한 차이점
아마도 이것은 상당히 중요한 것 같다.
Cloud Watch Alarm을 직접 정의할 수 있는지 여부
대상 추적 배율 조정 시
Scalling Policy를 생성하면 다음 Cloud Watch Alarm이 자동으로 생성됩니다.
3分内の3データポイントの「メトリクス」 > 閾値
15分内の15データポイントの「メトリクス」 < 閾値 - 数%
한편, 스텝 패키지에서 클라우드 워치 알람을 스스로 준비하기 때문에 위와 같은 엄격한 경보를 만들 수 있다.
어깨끈
보태다
공식 문서에도 다음과 같은 기록이 있다.
Amazon ECS サービスの Auto Scaling は Application Auto Scaling ステップスケーリングポリシーの使用をサポートしていますが、
代わりにターゲット追跡ポリシーを使用することをお勧めします。
*
高度なスケーリングポリシー設定に、
ターゲット追跡スケーリングをステップスケーリングと共に使用することもできます。
たとえば、必要に応じて、使用率が一定のレベルに達したときにより積極的なレスポンスを設定できます。
Reference
이 문제에 관하여(ECS에서 Auto Scoling Policy의 Target Specification 및 STEP 정보), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://zenn.dev/techno_koki/articles/082e7bbe1a3605텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념
(Collection and Share based on the CC Protocol.)
좋은 웹페이지 즐겨찾기
