본문으로 바로가기

10

오토스케일링

손님이 시간마다 다른데 창구 수는 하나로 고정되어 있다면

먼저 보면 좋은 강의: 웹 요청의 해부, 지연 시간과 처리량

단계별로 보기

스페이스바로 재생/정지, 좌우 화살표로 단계 이동, R로 처음으로 돌아갑니다.

대기 중1 / 4 단계 — 새벽 — 한 대로 충분하다

초당 40건이 들어옵니다. 서버 한 대가 초당 50건을 처리하니 여유가 있습니다. 여기서 서버 2와 서버 3은 켜져 있을 뿐 아무 일도 하지 않습니다. 그런데도 요금은 세 대분이 그대로 나갑니다. 이것이 최대치에 맞춘 고정 용량의 비용입니다.

유입 요청초당 40건
사용률0.0%

이 강의를 마치면

  • 트래픽이 시간에 따라 크게 달라진다는 사실과, 그것이 용량 결정에 미치는 영향을 설명한다.
  • 최대치에 맞춘 고정 용량과 평균에 맞춘 고정 용량이 각각 어떤 대가를 치르는지 비교한다.
  • 서버가 준비되는 데 시간이 걸리기 때문에 '수요를 보고 늘리면 늦는다'는 점을 관찰한다.
  • 자동 확장을 쓰더라도 최소 대수와 확장 속도는 사람이 정해야 함을 설명한다.

하루는 평평하지 않다

식당을 생각해 봅시다. 점심 12시에는 자리가 없어서 밖에 줄이 섭니다. 오후 3시에는 홀 전체에 손님이 두 명입니다. 같은 식당, 같은 하루입니다.

서비스도 똑같습니다. 출근길, 점심시간, 저녁 9시에 몰리고 새벽 4시에는 거의 없습니다. 차이는 두 배가 아니라 흔히 다섯 배에서 열 배입니다. 명절이나 티켓 오픈 같은 날은 수십 배가 됩니다.

고정 용량이 치르는 두 가지 대가

서버 대수를 하나로 정해 두면 선택지는 둘뿐입니다.

어디에 맞추나몰릴 때한산할 때
최대치에 맞춘다문제없다대부분의 장비가 논다. 그 비용은 그대로 나간다
평균에 맞춘다줄이 서고, 결국 요청이 버려진다적당하다

세 번째 선택지는 없습니다. 용량이 고정된 이상, 변하는 수요와 언젠가는 어긋납니다.

새벽에 노는 장비가 왜 문제인가 하면, 그 장비는 새벽에도 돈을 받기 때문입니다. 최대치가 평균의 다섯 배라면, 최대치에 맞춘 설비의 80%는 하루 대부분 놀고 있습니다.

그래서 대수를 바꾼다

자동 확장(오토스케일링)의 아이디어는 단순합니다.

손님이 늘면  → 창구를 연다
손님이 줄면  → 창구를 닫는다

식당이 아르바이트를 점심에만 부르는 것과 같습니다. 앞의 표에서 두 칸 모두를 좋게 만드는 유일한 방법이고, 그래서 오늘날 거의 모든 서비스가 이렇게 합니다.

그런데 창구를 여는 데 시간이 든다

여기서부터가 진짜입니다. 아르바이트생은 전화하면 즉시 오지 않습니다. 옷을 갈아입고, 자리에 앉고, 시스템에 로그인해야 합니다. 서버도 마찬가지로 켜고 준비되기까지 보통 수십 초에서 몇 분이 걸립니다.

이 시간 때문에 "바빠진 걸 보고 늘리면 이미 늦습니다."

  • 12시 00분: 손님이 몰리기 시작한다
  • 12시 01분: 사용률이 높다는 경보가 뜬다
  • 12시 01분: 서버 두 대를 켠다
  • 12시 04분: 서버가 준비된다
  • 12시 01분부터 04분까지 3분간, 요청은 버려지고 있었습니다.

그래서 실제로는 미리 늘립니다. 어제와 지난주 같은 요일의 곡선을 보고 11시 50분에 이미 켜 두거나, 사용률 70%를 넘으면(꽉 차기 전에) 늘리기 시작합니다.

그리고 줄이는 건 더 조심스럽다

손님이 잠깐 줄었다고 바로 창구를 닫으면, 5분 뒤 다시 몰릴 때 또 3분을 기다려야 합니다. 늘리기와 줄이기를 짧은 간격으로 반복하는 것을 플래핑이라고 하고, 안 하느니만 못한 결과를 냅니다. 그래서 줄일 때는 대개 훨씬 천천히, 오래 지켜보고 줄입니다.

결정권자가 알아야 할 것

자동 확장은 "알아서 다 해 준다"가 아닙니다. 사람이 반드시 정해야 하는 숫자가 있습니다.

  • 최소 대수: 아무리 한산해도 이 밑으로는 안 내린다. 갑작스러운 증가를 버티는 완충재입니다.
  • 최대 대수: 여기까지만 늘린다. 잘못된 트래픽(공격, 버그)에 무한히 돈을 쓰지 않기 위한 안전장치입니다.
  • 늘리는 기준: 사용률 몇 %에서 늘릴 것인가. 낮게 잡으면 안전하고 비싸며, 높게 잡으면 싸고 위험합니다.

이 숫자들은 기술 문제가 아니라 비용과 위험 중 무엇을 더 싫어하는가에 대한 경영 판단입니다.

직접 해보세요

아래 과제에는 자동으로 늘려 주는 장치가 없습니다. 최대 부하를 직접 보고, 필요한 대수를 직접 정해야 합니다. 그리고 그 대수가 한산한 시간에도 그대로 돌아간다는 점을 기억해 두세요. 그 낭비가 바로 오토스케일링이 푸는 문제입니다.

이 강의가 단순화한 것

교육용 모형은 언제나 무언가를 생략합니다. 무엇을 생략했는지 아는 것도 학습의 일부입니다.

전제한 것

  • 이 시뮬레이터에는 자동 확장 장치가 없다. 대수는 사람이 미리 정하고, 실행 중에는 바뀌지 않는다.
  • 서버가 켜지고 준비되는 데 걸리는 시간(워밍업)은 모델링하지 않는다. 현실에서는 이 시간이 자동 확장 설계의 핵심 제약이다.
  • 모든 서버의 처리 능력이 완전히 동일하고, 로드밸런서는 요청을 정확히 균등하게 나눈다.
  • 트래픽 곡선은 설명을 위해 만든 것이며 실제 서비스의 측정값이 아니다.

다루지 않은 것

  • 예측 기반 확장(시계열 예측, 예약 확장)
  • 컨테이너 오케스트레이터의 스케줄링과 노드 풀 확장의 2단 구조
  • 확장 정책의 쿨다운·히스테리시스 설정
  • 예약 인스턴스·스팟 인스턴스 같은 비용 최적화 수단

더 읽을거리: Google SRE Book — Handling Overload

이제 직접 만들어 보세요

읽어서 아는 것과 만들어서 아는 것은 다릅니다. 컴포넌트를 배치하고 트래픽을 흘려서 실제로 동작하는지 확인해 보세요.

실습 과제 열기

이 강의에 물어보기

하루 5번

이 강의 본문만 근거로 답합니다. 강의에 없는 내용은 지어내지 않습니다.