10강
오토스케일링
손님이 시간마다 다른데 창구 수는 하나로 고정되어 있다면
먼저 보면 좋은 강의: 웹 요청의 해부, 지연 시간과 처리량
단계별로 보기
스페이스바로 재생/정지, 좌우 화살표로 단계 이동, R로 처음으로 돌아갑니다.
대기 중1 / 4 단계 — 새벽 — 한 대로 충분하다
초당 40건이 들어옵니다. 서버 한 대가 초당 50건을 처리하니 여유가 있습니다. 여기서 서버 2와 서버 3은 켜져 있을 뿐 아무 일도 하지 않습니다. 그런데도 요금은 세 대분이 그대로 나갑니다. 이것이 최대치에 맞춘 고정 용량의 비용입니다.
이 강의를 마치면
- 트래픽이 시간에 따라 크게 달라진다는 사실과, 그것이 용량 결정에 미치는 영향을 설명한다.
- 최대치에 맞춘 고정 용량과 평균에 맞춘 고정 용량이 각각 어떤 대가를 치르는지 비교한다.
- 서버가 준비되는 데 시간이 걸리기 때문에 '수요를 보고 늘리면 늦는다'는 점을 관찰한다.
- 자동 확장을 쓰더라도 최소 대수와 확장 속도는 사람이 정해야 함을 설명한다.
하루는 평평하지 않다
식당을 생각해 봅시다. 점심 12시에는 자리가 없어서 밖에 줄이 섭니다. 오후 3시에는 홀 전체에 손님이 두 명입니다. 같은 식당, 같은 하루입니다.
서비스도 똑같습니다. 출근길, 점심시간, 저녁 9시에 몰리고 새벽 4시에는 거의 없습니다. 차이는 두 배가 아니라 흔히 다섯 배에서 열 배입니다. 명절이나 티켓 오픈 같은 날은 수십 배가 됩니다.
고정 용량이 치르는 두 가지 대가
서버 대수를 하나로 정해 두면 선택지는 둘뿐입니다.
| 어디에 맞추나 | 몰릴 때 | 한산할 때 |
|---|---|---|
| 최대치에 맞춘다 | 문제없다 | 대부분의 장비가 논다. 그 비용은 그대로 나간다 |
| 평균에 맞춘다 | 줄이 서고, 결국 요청이 버려진다 | 적당하다 |
세 번째 선택지는 없습니다. 용량이 고정된 이상, 변하는 수요와 언젠가는 어긋납니다.
새벽에 노는 장비가 왜 문제인가 하면, 그 장비는 새벽에도 돈을 받기 때문입니다. 최대치가 평균의 다섯 배라면, 최대치에 맞춘 설비의 80%는 하루 대부분 놀고 있습니다.
그래서 대수를 바꾼다
자동 확장(오토스케일링)의 아이디어는 단순합니다.
손님이 늘면 → 창구를 연다
손님이 줄면 → 창구를 닫는다식당이 아르바이트를 점심에만 부르는 것과 같습니다. 앞의 표에서 두 칸 모두를 좋게 만드는 유일한 방법이고, 그래서 오늘날 거의 모든 서비스가 이렇게 합니다.
그런데 창구를 여는 데 시간이 든다
여기서부터가 진짜입니다. 아르바이트생은 전화하면 즉시 오지 않습니다. 옷을 갈아입고, 자리에 앉고, 시스템에 로그인해야 합니다. 서버도 마찬가지로 켜고 준비되기까지 보통 수십 초에서 몇 분이 걸립니다.
이 시간 때문에 "바빠진 걸 보고 늘리면 이미 늦습니다."
- 12시 00분: 손님이 몰리기 시작한다
- 12시 01분: 사용률이 높다는 경보가 뜬다
- 12시 01분: 서버 두 대를 켠다
- 12시 04분: 서버가 준비된다
- 12시 01분부터 04분까지 3분간, 요청은 버려지고 있었습니다.
그래서 실제로는 미리 늘립니다. 어제와 지난주 같은 요일의 곡선을 보고 11시 50분에 이미 켜 두거나, 사용률 70%를 넘으면(꽉 차기 전에) 늘리기 시작합니다.
그리고 줄이는 건 더 조심스럽다
손님이 잠깐 줄었다고 바로 창구를 닫으면, 5분 뒤 다시 몰릴 때 또 3분을 기다려야 합니다. 늘리기와 줄이기를 짧은 간격으로 반복하는 것을 플래핑이라고 하고, 안 하느니만 못한 결과를 냅니다. 그래서 줄일 때는 대개 훨씬 천천히, 오래 지켜보고 줄입니다.
결정권자가 알아야 할 것
자동 확장은 "알아서 다 해 준다"가 아닙니다. 사람이 반드시 정해야 하는 숫자가 있습니다.
- 최소 대수: 아무리 한산해도 이 밑으로는 안 내린다. 갑작스러운 증가를 버티는 완충재입니다.
- 최대 대수: 여기까지만 늘린다. 잘못된 트래픽(공격, 버그)에 무한히 돈을 쓰지 않기 위한 안전장치입니다.
- 늘리는 기준: 사용률 몇 %에서 늘릴 것인가. 낮게 잡으면 안전하고 비싸며, 높게 잡으면 싸고 위험합니다.
이 숫자들은 기술 문제가 아니라 비용과 위험 중 무엇을 더 싫어하는가에 대한 경영 판단입니다.
직접 해보세요
아래 과제에는 자동으로 늘려 주는 장치가 없습니다. 최대 부하를 직접 보고, 필요한 대수를 직접 정해야 합니다. 그리고 그 대수가 한산한 시간에도 그대로 돌아간다는 점을 기억해 두세요. 그 낭비가 바로 오토스케일링이 푸는 문제입니다.
이 강의가 단순화한 것
교육용 모형은 언제나 무언가를 생략합니다. 무엇을 생략했는지 아는 것도 학습의 일부입니다.
전제한 것
- 이 시뮬레이터에는 자동 확장 장치가 없다. 대수는 사람이 미리 정하고, 실행 중에는 바뀌지 않는다.
- 서버가 켜지고 준비되는 데 걸리는 시간(워밍업)은 모델링하지 않는다. 현실에서는 이 시간이 자동 확장 설계의 핵심 제약이다.
- 모든 서버의 처리 능력이 완전히 동일하고, 로드밸런서는 요청을 정확히 균등하게 나눈다.
- 트래픽 곡선은 설명을 위해 만든 것이며 실제 서비스의 측정값이 아니다.
다루지 않은 것
- 예측 기반 확장(시계열 예측, 예약 확장)
- 컨테이너 오케스트레이터의 스케줄링과 노드 풀 확장의 2단 구조
- 확장 정책의 쿨다운·히스테리시스 설정
- 예약 인스턴스·스팟 인스턴스 같은 비용 최적화 수단
이제 직접 만들어 보세요
읽어서 아는 것과 만들어서 아는 것은 다릅니다. 컴포넌트를 배치하고 트래픽을 흘려서 실제로 동작하는지 확인해 보세요.
이 강의에 물어보기
하루 5번이 강의 본문만 근거로 답합니다. 강의에 없는 내용은 지어내지 않습니다.