아래에 적어두는 방식은 평상시 운영하고 있는 서비스가 특정 이벤트로 인해 더 많은 요청이 들어올 것을 대비하기 위한 계산 방식이다. 단순히 요청량과 CPU 사용률만으로 계산하는 방식으로 신뢰도가 굉장히 낮지만, 기본적인 지표로 삼고 메모리 혹은 로드 밸런서의 부하 등을 감안하여 인스턴스의 수를 조정할 수 있다.
평상시 인스턴스당 요청 처리량
먼저 이벤트 중이 아닌, 평상시 운영중인 서비스의 인스턴스당 요청량을 계산한다.
- 평상시 피크 타임의 Request 횟수를 획득한 후, 그 값을 인스턴스 개수로 나눠
피크 타임에 인스턴스 하나당 처리되는 요청의 양을 구한다.- 평상시 피크 타임(23시 ~ 00시) 총 250,000 Request, 16개의 인스턴스를 사용 중일 때
- 250,000 req / 16 instance (1 hour)
- = 15,625 req / 1 instance (1 hour)
- 이렇게 구한 1시간 동안 인스턴스 1대에 들어온 요청을 1초당 처리량으로 변환한다.
- 15,625 req / 3600 sec
- = 4.3 req / 1 sec
- 1초당 4.3회의 요청이 들어왔다고 볼 수 있다.
- 여기서 인스턴스의 평균 CPU 사용률을 가져오면, 초당 4.3회의 요청이 들어올 때 CPU의 사용률을 확인할 수 있게 된다.
- 평균(1초당 4.3회 요청시) CPU 사용률 25%
- = 1초당 17.2회 요청시 CPU 사용률 100%
- 위 과정을 통해 만약(아주 대략적으로) CPU 100%를 사용한다면 인스턴스 한대가 1초당 16 req정도는 감당할 수 있으리라고 예상할 수 있다.
- 이 값을 통해 평상시 운영에 사용할 인스턴스의 수를 늘리거나 줄일 수 있다.
다만 다양한 이유(경험적인 측면에서)로 CPU의 평균 사용률이 너무 높지 않게 유지되는 것이 좋았다.
이제 이렇게 구한 인스턴스 한대당 최대 요청 처리량으로 이벤트 기간 중 필요한 인스턴스의 수를 계산할 수 있다.
이벤트 기간에 필요한 인스턴스의 수
이벤트 기간의 요청량은 기존 진행했던 이벤트 기록을 통해 파악하는 것이 좋다. 이 요청량은 서비스마다, 혹은 마케팅에 투자된 만큼 크게 변할 것이다.
- 이벤트 시작 이후 1시간동안 평상시 피크 타임의 요청량보다 10배 증가하리라고 예상된다고 가정하고 계산을 진행한다.
- 2,500,000 req / 3600 sec (1시간동안 250만의 요청)
- = 694 req / 1 sec (1초당 694회 요청)
- = 694 req (이벤트 중 초당 요청량) / 16 req (인스턴스 한대당 최대 수용량)
- = 43.375 (필요한 인스턴스의 개수. 올림 필요)
- 위 계산 결과로 인스턴스 44대로 운영하여야 평상시 피크타임의 요청량보다 10배 증가된 요청을 수용 가능하다는 결과가 나온다.
위 계산 결과를 토대로 인스턴스 필요량을 구한 이후, 이 값을 이용해 Auto-Scaling 설정을 진행하여야 한다. 다만 많이 사용되는 AWS의 Auto-Scaling 기능은 인스턴스의 임계치에 도달했음을 확인하고 새로운 인스턴스가 로드 밸런서에 추가되기까지 생각보다 오랜 시간이 걸린다는 점을 감안해야 한다. 서비스의 인스턴스의 최소 개수를 위에서 계산한 이벤트 피크 타임에 감당 가능한 인스턴스의 수로 맞추는 것이 가장 무난하지만, 상황에 따라 임계치 관련 설정을 변환하거나 타임 플랜을 설정해야 할 수 있다.
'ETC' 카테고리의 다른 글
| 2022년 하반기를 보내며 (0) | 2023.01.07 |
|---|---|
| 내 문장이 그렇게 이상한가요? 를 읽고 (0) | 2022.11.15 |
| 2022년 상반기를 보내며 (0) | 2022.09.07 |
| 함수형 프로그래밍에 대해 (0) | 2022.02.26 |
| 전략과 전술 (0) | 2022.01.29 |