일반적인 자동 스케일링 패턴
이 단원에서는 자동 스케일링을 위한 패턴을 살펴보겠습니다.
자동 크기 조정은 인스턴트 솔루션이 아닙니다. 그저 리소스를 시스템에 추가하거나 프로세스의 더 많은 인스턴스를 추가하기만 해서는 시스템 성능 향상이 보장되지 않습니다. 자동 크기 조정 전략을 디자인할 때 다음 사항을 고려하십시오.
권장 사항
병목 상태 식별: 스케일링을 통해 모든 성능 문제를 해결할 수 있는 것은 아닙니다. 예를 들어 백 엔드 데이터베이스가 병목 상태인 경우 웹 서버를 더 추가해도 도움이 되지 않습니다. 문제 지점에 인스턴스를 더 추가하기 전에 시스템의 먼저 병목 상태를 식별하고 해결하세요. 일반적으로 시스템의 상태 저장 부분이 병목 상태의 주요 원인입니다.
스케일링 성능 요구 사항별 워크로드 분해: 애플리케이션은 종종 스케일링 요구 사항이 각기 다른 여러 워크로드로 구성되어 있습니다. 예를 들어 애플리케이션에 공용 사이트와 별도의 관리 사이트가 있을 수 있습니다. 퍼블릭 사이트의 트래픽은 갑자기 급증할 수 있는 반면 관리 사이트의 부하는 더 적고 예측 가능합니다.
리소스를 많이 사용하는 태스크 오프로드. 가능한 경우 많은 CPU 또는 I/O 리소스가 필요한 태스크를 백그라운드 작업으로 이동해야 합니다. 태스크를 오프로드하면 사용자 요청을 처리하는 프런트 엔드의 부하가 최소화됩니다.
기본 제공 자동 스케일링 기능 사용: 애플리케이션의 워크로드가 예측 가능하고 정기적인 경우 일정에 따라 스케일 아웃합니다. 예를 들어 업무 시간 중에 확장합니다. 그렇지 않고 워크로드를 예측할 수 없는 경우 CPU 또는 요청 큐 길이와 같은 성능 메트릭을 사용하여 자동 스케일링을 트리거합니다.
중요한 워크로드에 대한 적극적인 자동 스케일링 고려: 중요한 워크로드의 경우 수요보다 앞서 작업해야 합니다. 부하가 높은 상태에서 새 인스턴스를 신속하게 추가하여 다른 트래픽을 처리한 다음, 점진적으로 스케일 다운하는 것이 좋습니다.
스케일 인을 고려한 디자인: 탄력적 스케일링을 사용하는 경우 인스턴스가 제거되면 애플리케이션이 스케일 인되는 기간이 발생합니다. 애플리케이션이 제거되는 인스턴스를 정상적으로 처리해야 합니다. 다음은 스케일 인을 처리하는 몇 가지 방법입니다.
- 종료 이벤트(사용 가능한 경우)를 수신 대기하고 정상적으로 종료합니다.
- 일시적인 오류 처리를 지원하고 다시 시도합니다.
- 장기 실행 태스크의 경우 작업을 분리하는 것이 좋습니다.
- 처리 중에 인스턴스가 제거될 경우 다른 인스턴스가 작업을 선택할 수 있도록 큐에 작업 항목을 배치합니다.
공지
- 모든 자동 크기 조정 실패는 활동 로그에 기록됩니다. 그런 다음, 자동 스케일링 오류가 있을 때마다 메일이나 SMS(문자 서비스) 또는 webhook를 통해 알림을 제공하는 활동 로그 경고를 구성할 수 있습니다.
- 마찬가지로, 모든 성공한 크기 조정 작업도 활동 로그에 게시됩니다. 다음으로, 성공적인 자동 스케일링 작업이 있을 때마다 메일이나 SMS, 웹후크를 통해 알림을 받을 수 있도록 활동 로그 경고를 구성할 수 있습니다. 또한 자동 스케일링 설정의 알림 탭을 통해 성공적인 스케일링 작업에 대한 알림을 받도록 메일 또는 웹후크 알림을 구성할 수도 있습니다.
Azure에서 리소스를 스케일링하는 일반적인 패턴
수요에 따라 스케일링
고객 수요가 증가하는 근무일 시작 시 서비스 인스턴스 수를 자동으로 스케일 아웃합니다. 근무일이 끝날 때 애플리케이션 인스턴스 수를 자동으로 스케일 인하여 애플리케이션 사용이 적은 야간에 리소스 비용을 최소화합니다.
평일과 주말에 대해 다르게 크기 조정
저녁이나 주말에는 애플리케이션 수요가 낮을 수 있습니다. 이 부하가 일정 기간 동안 일관된 경우 확장 집합의 서비스 인스턴스 수를 낮추도록 자동 스케일링 규칙을 구성할 수 있습니다. 이 스케일 인 작업을 수행하면 현재 수요를 충족하는 데 필요한 수의 인스턴스만 실행하므로 확장 집합의 실행 비용이 줄어듭니다.
휴일 동안에 대해 다르게 크기 조정
월 또는 회계 주기의 특정 부분에서 서비스를 많이 사용하는 경우 서비스 인스턴스 수를 자동으로 스케일링하여 추가 수요를 수용할 수 있습니다. 마케팅 이벤트, 판촉 또는 휴일 판매가 있는 경우 예상 고객 수요보다 앞서 서비스 인스턴스 수를 자동으로 스케일링할 수 있습니다.
사용자 지정 메트릭 기준 크기 조정
마지막으로, 자동 스케일링 규칙을 신중하게 정의하는 것이 가장 좋습니다. 예를 들어 DoS(서비스 거부) 공격이 발생하면 대규모 트래픽이 유입될 수 있습니다. DoS 공격으로 인해 급증하는 요청을 처리하려고 하면 효과가 없고 비용이 많이 듭니다. 이러한 요청은 참된 것이 아니므로 처리하지 않고 취소해야 합니다. 이러한 공격 중에 발생하는 요청은 서비스에 도달하기 전에 감지하고 필터링하도록 구현하는 것이 더 좋은 해결 방법입니다.
자동 스케일링 규칙을 구성한 후 시간이 지남에 따라 애플리케이션의 성능을 모니터링합니다. 이 모니터링 결과를 사용하여 필요한 경우 시스템 스케일링 패턴을 조정합니다.