수직 확장

사용자가 늘면 어느 시점에 서버가 버티지 못합니다. 동시 접속 500명에서 0.3초였던 응답이 2,000명에서 8초로 늘어나면 기능은 멀쩡해도 사용자에게는 고장 난 것과 같습니다.

이때 할 수 있는 일은 둘뿐입니다. 지금 쓰는 기계를 더 좋은 것으로 바꾸거나, 같은 기계를 여러 대로 늘리는 것입니다. 앞엣것이 수직 확장이고 뒤엣것이 수평 확장입니다.

물리 서버를 직접 사서 쓰던 시절에는 앞엣것이 큰 일이었습니다. 메모리를 늘리려면 부품을 주문해 데이터 센터에 가야 했고, 기계를 아예 바꾸려면 견적을 받고 결재를 올리고 배송을 기다려 6주가 걸렸습니다. 그사이 서비스는 느린 상태로 돕니다.

클라우드가 이 일을 화면에서 사양을 바꾸고 재시작하는 작업으로 만들었습니다. 금요일 저녁에 사용량이 튀어 응답이 밀리면, 코드 구조를 바꿀 시간이 없어도 사양을 두 단계 올려 주말을 넘길 수 있습니다. 선택지 하나가 몇 주에서 몇 분으로 짧아진 것이 이 방식을 다시 실무의 첫 수단으로 만들었습니다.

무엇이 부족한지를 먼저 재고, 그 자원만 키운 사양으로 바꿔 재시작합니다.

1. 부족한 자원을 확인합니다. 후보는 넷입니다. 연산을 맡는 CPU, 데이터를 잠시 얹어 두는 메모리, 디스크를 읽고 쓰는 속도, 그리고 네트워크 대역입니다. 메모리가 모자라 디스크로 밀려 쓰고 있는 상황인데 CPU 개수를 올리면 요금만 오르고 응답 시간은 그대로입니다.
2. 한 단계 위 사양을 고릅니다. 클라우드의 사양 목록은 대개 2배 단위로 놓여 있어서 8코어 32기가바이트 다음이 16코어 64기가바이트입니다. 필요한 자원만 큰 사양을 따로 고를 수도 있습니다.
3. 전환 방식을 정합니다. 사양을 바꾸려면 재시작이 필요하고 그동안 몇 분간 멈춥니다. 앞에 로드 밸런서가 있어 여러 대로 요청을 나눠 주는 구조라면 한 대씩 차례로 바꿔 멈춤 없이 넘길 수 있고, 한 대뿐이라면 사용자가 적은 시간대를 골라야 합니다.
4. 바꾼 뒤 다시 잽니다. 응답 시간과 자원 사용률을 함께 봅니다. 사양을 2배로 올렸는데 응답이 1.3배만 빨라졌다면 병목이 그 자원에 있지 않았다는 뜻입니다.
5. 되돌릴 길을 남깁니다. 사양은 내릴 수도 있어서 과하게 올린 것을 다음 주에 되돌릴 수 있습니다. 다만 디스크 용량은 대개 늘리기만 되고 줄이지 못하니 이 항목만 신중하게 정합니다.

맞는 자리는 넷입니다. 첫째는 상태를 들고 있는 서버입니다. 관계형 데이터베이스처럼 한곳에 데이터가 모여 있어야 하는 것은 대수를 늘리는 쪽이 어렵기 때문에 사양을 키우는 것이 기본 수단입니다. 둘째는 코드가 여러 대에 나눠 돌 준비가 안 된 경우입니다. 로그인 상태를 서버 메모리에 들고 있으면 대수를 늘리는 순간 사용자가 접속할 때마다 로그인이 풀립니다. 셋째는 지금 당장 넘겨야 하는 상황이고, 넷째는 아직 규모가 작아 한 대로 충분한 단계입니다.

한계는 넷입니다.

1. 상한이 있습니다. 가장 큰 사양이 존재하고 그 위는 없습니다. 거기에 닿으면 선택지가 하나로 줄어듭니다.
2. 값이 사양에 비례하지 않습니다. 사양이 커질수록 성능당 단가가 올라가서, 월 9만 원짜리를 네 단계 올리면 월 70만 원이 됩니다. 같은 돈으로 작은 기계 여덟 대를 빌릴 수 있는 구간이 옵니다.
3. 한 대가 서비스 전체입니다. 그 기계가 멈추면 서비스도 멈춥니다. 대수를 늘리면 한 대가 죽어도 나머지가 받아 주지만, 키우는 쪽에는 그 여유가 없습니다.
4. 재시작이 필요합니다. 부하가 오르내리는 데 맞춰 자동으로 자원을 조절하는 오토스케일링은 대수를 늘리고 줄이는 쪽에 붙는 기능이고, 사양을 바꾸는 쪽은 사람이 판단해 실행하는 작업으로 남습니다.

"지금은 사양부터 올리고 넘기죠. 구조 바꾸는 건 다음 스프린트에요."

시간이 없을 때 쓰는 수단이라는 판단입니다.

"데이터베이스는 수직으로 갑니다. 나눠 붙이는 건 다른 문제예요."

상태를 들고 있는 서버에는 다른 기준이 적용된다는 뜻입니다.

"사양 두 배 올렸는데 응답이 거의 그대로예요. 병목이 CPU가 아니었던 겁니다."

무엇이 부족한지를 먼저 재지 않은 결과라는 지적입니다.

페이지덱에서는 태오가 데이터베이스는 사양을 키우는 쪽으로, 웹 서버는 대수를 늘리는 쪽으로 나눠 두었습니다. 웹 서버는 로그인 상태를 서버 메모리가 아니라 별도 저장소에 두어 몇 대로 늘려도 문제가 없게 만들어 두었습니다.

데이터베이스 사양은 지난 1년에 두 번 올렸습니다. 처음에는 CPU 사용률이 높아 연산 쪽을 키웠는데 응답이 거의 나아지지 않았고, 다시 재 보니 메모리가 모자라 디스크를 계속 읽고 있었습니다. 두 번째에는 메모리만 큰 사양으로 바꿨고 응답 시간이 절반이 됐습니다.

수직 확장이 임시 방편이고 결국 수평으로 가야 한다고 보는 경우가 가장 많습니다. 큰 서비스의 구조를 소개하는 글이 대개 여러 대로 나눈 그림을 보여 주기 때문입니다. 하지만 자리에 따라 정답이 다릅니다. 데이터를 한곳에 모아 두고 값이 어긋나지 않게 지켜야 하는 데이터베이스는 대수를 늘리는 순간 어느 기계의 값이 맞는지를 관리해야 하는 문제가 새로 생깁니다. 그래서 규모가 큰 회사도 데이터베이스는 사양을 키우는 쪽으로 오래 버티고, 나누는 것은 다른 방법을 써서 따로 다룹니다. 임시와 항구의 문제가 아니라 상태를 들고 있느냐의 문제입니다.

사양을 2배로 하면 2배 빨라진다고 보는 것도 흔합니다. 숫자가 그렇게 적혀 있으니 자연스러운 오해입니다. 다만 늘어난 자원을 프로그램이 다 쓸 수 있어야 그 계산이 맞습니다. 코드가 한 번에 한 코어만 쓰도록 짜여 있으면 코어를 8개에서 16개로 늘려도 같은 속도로 돕니다. 병목이 디스크에 있었다면 메모리를 두 배로 늘린 효과가 먼저 나타나고 CPU는 그대로입니다. 1번 단계를 건너뛰고 사양부터 올리는 일이 잦은데, 그렇게 쓴 돈은 다음 달 청구서에만 남습니다.