오토스케일링

서버를 몇 대 둘지는 오래도록 한 번 정해 놓고 그대로 두는 값이었습니다. 문제는 그 한 번을 어느 시점에 맞추느냐였습니다. 하루 중 사람이 가장 몰리는 때에 맞추면 나머지 스무 시간 동안 서버 대부분이 아무 일도 하지 않은 채 돈만 먹었고, 평소에 맞추면 공지 메일 한 통에 서비스가 멈췄습니다.

그래서 운영은 사람이 지키고 앉아 있는 모양이 됐습니다. 이벤트 전날 밤에 대수를 늘려 두고 다음 날 아침에 줄였습니다. 예고 없이 트래픽이 몰린 날에는 새벽 두 시에 알림을 받은 사람이 노트북을 열어 대수를 올렸습니다. 줄이는 것을 잊고 두 주가 지나서야 청구서에서 발견하는 일도 흔했습니다.

이 방식을 바꾼 계기는 클라우드입니다. 남이 지어 둔 데이터 센터에서 필요한 만큼만 빌려 쓰는 방식이 자리 잡으면서, 서버 한 대를 마련하는 데 걸리던 시간이 몇 주에서 몇 분으로 줄었습니다. 몇 분 만에 만들고 지울 수 있다면 그 판단을 사람이 지켜보며 할 이유가 없습니다. 오토스케일링은 그 판단을 규칙으로 적어 기계에 넘긴 것입니다.

노는 서버에 내는 돈과 몰릴 때 터지는 장애를 같이 줄입니다. 원래 이 둘은 맞바꾸는 관계였습니다. 대수를 넉넉히 두면 장애가 줄고 비용이 늘었고, 빠듯하게 두면 그 반대였습니다. 대수가 시간에 맞춰 움직이면 그 맞바꿈이 없어집니다.

페이지덱은 새벽 세 시에 접속자가 거의 없고 점심시간과 오후 세 시 무렵에 가장 많습니다. 가장 몰리는 때에 맞춰 8대를 상시로 두면 한 대에 월 20만 원일 때 월 160만 원이 나갑니다. 시간대별로 필요한 대수를 평균 내면 3.5대쯤이고 그만큼만 쓰면 70만 원입니다. 나머지 90만 원은 아무도 접속하지 않는 시간에 켜져 있던 값입니다.

동작은 네 단계가 계속 도는 모양입니다.

1. 관찰 — 서버의 처리 부하나 메모리 사용률, 또는 대기 중인 요청 수를 1분 간격으로 잽니다.
2. 판단 — 그 값을 미리 적어 둔 임계값과 견줍니다. "처리 부하가 5분 넘게 70퍼센트를 넘으면" 같은 조건입니다.
3. 조절 — 조건에 걸리면 대수를 올리거나 내립니다. 최소 2대, 최대 10대처럼 하한과 상한을 함께 적어 둡니다.
4. 대기 — 방금 바꾼 결과가 지표에 나타날 때까지 몇 분 동안 다음 판단을 멈춥니다. 이 단계가 없으면 늘렸다 줄였다를 반복합니다.

이 구조가 돌려면 앞에 로드 밸런서가 서 있어야 합니다. 요청을 여러 서버에 나눠 보내는 장치이고, 새로 뜬 서버를 목록에 넣어 줘야 그 서버가 실제로 일을 받습니다. 그리고 어느 대가 받아도 결과가 같아야 합니다. 수평 확장이 요구하는 조건이 그대로 걸립니다. 로그인 상태를 한 서버의 메모리에만 들고 있으면 대수가 줄어드는 순간 그 서버에 붙어 있던 사람들이 로그아웃됩니다.

대수를 자동으로 바꾸지 않고 몰리는 시간을 넘기는 방법은 네 가지입니다.

1. 고정 대수 — 가장 몰리는 때에 맞춰 늘 켜 둡니다. 규칙도 임계값도 없어 가장 단순하고, 하루 중 부하 차이가 두 배 안쪽이면 아껴 봐야 얼마 안 되니 이편이 낫습니다.
2. 예약 확장 — 시간표대로 대수를 바꿉니다. 평일 아침 아홉 시에 6대, 밤 열한 시에 2대 식입니다. 부하가 시계처럼 규칙적인 업무용 서비스에 잘 맞지만, 예고 없는 몰림에는 손을 못 씁니다.
3. 수직 확장 — 대수 대신 한 대의 성능을 키웁니다. 메모리를 8기가에서 32기가로 올리는 식이라 코드를 고칠 필요가 없고, 대수를 늘리기 어려운 데이터베이스 같은 자리에서는 사실상 이 방법뿐입니다. 다만 한 대가 커지는 데는 한계가 있고 바꾸는 동안 그 한 대가 멈춥니다.
4. 서버리스 — 확장이라는 판단 자체를 맡깁니다. 서버 대수라는 개념 없이 요청 하나당 함수 하나가 실행되고 요청이 없으면 아무것도 돌지 않습니다. 대신 한동안 쉬던 함수의 첫 실행만 유독 느려지는 콜드 스타트를 감수합니다.

무엇을 고를지는 부하가 얼마나 예측되느냐로 갈립니다. 거의 변하지 않으면 1번, 시계처럼 규칙적이면 2번, 언제 몰릴지 모르면 오토스케일링입니다. 어느 쪽이든 부하가 늘어도 키울 수 있는 성질, 곧 확장성이 프로그램에 없으면 대수를 조절해도 소용이 없습니다.

"오토스케일링 걸려 있으니까 공지 나가는 시간에 따로 안 붙어도 됩니다."

몰리는 시간에 사람이 대기하며 대수를 올릴 필요가 없다는 뜻입니다.

"최소 대수를 2에서 4로 올릴게요. 아침 첫 접속이 계속 느려요."

밤사이 2대까지 줄어든 상태에서 출근 시간 요청이 한꺼번에 들어오는데, 늘어나는 속도가 그 속도를 못 따라간다는 말입니다.

"임계값을 70에서 55로 내리죠. 대수가 늘기 전에 이미 3분 동안 오류가 났어요."

부하가 70퍼센트에 닿고 나서 움직이면 늦으니 더 일찍 움직이게 하자는 제안입니다.

페이지덱에서 현우가 신규 기능 안내 메일을 전체 사용자에게 보낸 날, 태오는 전날 저녁에 최소 대수를 2에서 6으로 올려 뒀습니다. 메일이 나간 지 10분 만에 접속자가 평소의 일곱 배가 됐고 대수는 9대까지 올라갔다가 두 시간 뒤 3대로 돌아왔습니다. 다음 달에 규원이 그날 요금이 평소의 두 배인 것을 보고 묻자 태오는 상한을 12대로 걸어 둔 설정을 보여 줬습니다.

걸어 두기만 하면 어떤 트래픽이 와도 버틴다고 생각하기 쉽습니다. 자동이라는 말이 즉시라는 뜻처럼 들리기 때문입니다. 실제로는 지표를 재는 데 1분, 새 서버가 떠서 요청을 받기까지 2~3분이 걸립니다. 30초 만에 열 배가 들어오는 트래픽은 따라잡지 못합니다. 이 간격을 모르고 두면 티켓 오픈 같은 순간에 첫 5분 동안 오류가 쏟아지고, 기록에는 제때 확장됐다는 줄만 남습니다.

비용이 저절로 줄어든다는 것도 흔한 오해입니다. 노는 서버를 꺼 주니 그렇게 보입니다. 하지만 늘리는 쪽에도 같은 자동이 걸려 있습니다. 잘못 배포한 코드가 처리 부하를 100퍼센트로 만들거나 봇이 요청을 퍼부으면 규칙은 성실하게 대수를 올립니다. 상한을 적어 두지 않으면 그 성실함이 월말 청구서로 돌아옵니다.