본문으로 바로가기

07

수평 확장과 수직 확장

더 큰 기계를 사느냐, 기계를 더 사느냐

먼저 보면 좋은 강의: 지연 시간과 처리량, 로드밸런서

단계별로 보기

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

대기 중1 / 4 단계 — 더 큰 기계 한 대

대형 서버 한 대가 초당 160건을 처리합니다. 들어오는 120건을 여유 있게 소화합니다. 코드는 한 줄도 바꾸지 않았고, 구조도 그대로입니다. 클릭 몇 번으로 CPU를 늘렸을 뿐입니다. 작은 서비스라면 여기서 끝내는 것이 정답입니다.

처리 완료초당 120건

이 강의를 마치면

  • 수직 확장과 수평 확장의 차이를 비용과 한계의 관점에서 구분한다.
  • 수직 확장이 왜 어느 지점에서 반드시 멈추는지 설명한다.
  • 수평 확장이 처리량뿐 아니라 가용성까지 얻는 이유를 설명한다.
  • 수평 확장이 불가능한 경우가 무엇인지 예를 든다.

트럭 한 대로 이사할 것인가, 트럭 열 대로 할 것인가

이삿짐이 늘었습니다. 방법은 둘입니다.

  • 더 큰 트럭을 산다 — 1톤 트럭을 5톤 트럭으로 바꿉니다. 운전은 여전히 한 명입니다.
  • 트럭을 더 산다 — 1톤 트럭 다섯 대를 씁니다. 운전사도 다섯 명이 필요합니다.

서버도 똑같습니다. 앞의 방법을 수직 확장(scale up), 뒤의 방법을 수평 확장(scale out) 이라고 부릅니다.

수직 확장수평 확장
하는 일서버를 더 좋은 것으로 교체서버를 여러 대로 늘림
난이도쉽다. 코드를 안 고쳐도 된다준비가 필요하다
한계있다사실상 없다
한 대 고장 시전부 멈춤나머지가 버팀
중단 시간교체하는 동안 멈춤없음

수직 확장이 편한 이유

솔직히 말해 수직 확장은 아무것도 바꾸지 않아도 됩니다. 코드도 그대로, 구조도 그대로, 설정도 그대로입니다. 클라우드에서는 클릭 몇 번으로 CPU를 두 배로 만듭니다.

그래서 첫 번째 선택지로 아주 합리적입니다. 작은 서비스라면 수직 확장이 정답입니다. 트래픽이 초당 50건인 서비스에 로드밸런서와 서버 다섯 대를 두는 것은 과잉입니다. 복잡도만 늘고 얻는 게 없습니다.

"일단 수직으로 키워라, 아플 때 수평으로 가라"는 말은 냉소가 아니라 실무 조언입니다. 문제는 그 '아플 때'가 언제 오는지 아는 것입니다.

그런데 반드시 벽에 부딪힌다

벽 1 — 값이 선형이 아니다

성능을 두 배로 올릴 때 값도 두 배면 좋겠지만, 그렇지 않습니다.

CPU 4개  →  10만원
CPU 8개  →  22만원   (2.2배)
CPU 16개 →  55만원   (5.5배)
CPU 64개 →  400만원  (40배)

성능 16배에 값은 40배입니다. 고성능 하드웨어는 만드는 사람도 적고, 사는 사람도 적어서 비쌉니다. 어느 지점부터는 작은 기계 여러 대가 압도적으로 쌉니다.

벽 2 — 세상에서 가장 큰 기계도 유한하다

이게 결정적입니다. 아무리 돈이 많아도 세상에 없는 기계는 살 수 없습니다. 가장 큰 서버를 샀는데 그것도 부족하면, 그날로 수직 확장은 끝입니다. 다음 수가 없습니다.

벽 3 — 교체하려면 꺼야 한다

서버를 더 큰 것으로 바꾸려면 지금 서버를 끄고 옮겨야 합니다. 그동안 서비스가 멈춥니다. 새벽에 공지를 띄우고 작업합니다.

벽 4 — 계란을 한 바구니에 담는다

이게 진짜 무서운 부분입니다. 수직 확장의 끝은 아주 크고 아주 비싼 서버 한 대입니다. 그 한 대가 고장 나면? 전부 끝입니다. 성능에 돈을 쓸수록 그 한 대에 대한 의존이 커집니다. 잘 될수록 더 위험해지는 구조입니다.

수평 확장이 진짜로 사는 것

수평 확장을 "처리량을 늘리는 방법"으로만 이해하면 절반만 이해한 것입니다. 서버를 두 대로 만들면 두 가지를 삽니다.

  1. 처리량 — 두 배로 처리한다
  2. 가용성 — 한 대가 죽어도 서비스는 산다

두 번째는 수직 확장으로는 아무리 돈을 써도 살 수 없습니다. 500만원짜리 서버 한 대는 100만원짜리 서버 두 대보다 빠를지 몰라도, 고장 났을 때 대신할 것이 없습니다.

서버 1대(초당 200건) : 처리량 200, 고장 시 → 0
서버 5대(초당 40건씩) : 처리량 200, 고장 시 → 160

같은 처리량인데 하나는 장애 시 0이고 하나는 160입니다. 이것이 큰 서비스가 예외 없이 수평 확장을 쓰는 이유입니다. 값이 싸서가 아니라 안 죽어서입니다.

공짜는 아니다 — 전제 조건

수평 확장에는 조건이 있습니다. 서버가 상태를 들고 있으면 안 됩니다. 앞의 "상태 없는 서버" 강의에서 본 그것입니다. 서버가 사용자의 기억을 자기 안에 들고 있으면 대수를 늘리는 순간 로그인이 풀립니다.

그래서 순서가 있습니다.

1. 상태를 서버 밖으로 뺀다   (stateless)
2. 요청을 나눠줄 것을 앞에 둔다 (load balancer)
3. 그제서야 서버를 늘린다     (scale out)

1번을 건너뛰고 3번을 하면 이상한 버그가 나오고, 원인을 찾는 데 몇 주가 걸립니다.

그리고 모든 것을 수평 확장할 수 있는 건 아닙니다. 데이터베이스는 어렵습니다. "지금 잔고가 얼마인가"에 대해 모든 기계가 같은 답을 해야 하는데, 기계가 여러 대면 그것을 맞추는 일 자체가 어려운 문제가 됩니다. 그래서 데이터베이스는 마지막까지 수직 확장으로 버티는 경우가 많고, 그 이야기는 데이터 편에서 따로 다룹니다.

직접 해보세요

아래 과제의 서버는 한 대이고 초당 40건이 한계인데, 초당 150건이 들어옵니다. 두 가지 방법이 다 열려 있습니다. 서버 한 대의 동시 처리 수를 올려보고(수직), 서버 대수를 늘려보고(수평), 둘 다 해 보세요. 그리고 왜 하나만 통과하는지 보세요.

이 강의가 단순화한 것

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

전제한 것

  • 서버를 늘리면 처리량이 대수에 비례해 늘어난다고 본다. 실제로는 공유 자원 때문에 완전히 비례하지는 않는다.
  • 서버들의 성능이 모두 같다고 가정한다.
  • 데이터베이스는 이 강의의 그래프에 없다. 실제로는 서버를 늘리면 데이터베이스가 다음 병목이 된다.
  • 제시한 하드웨어 가격은 경향을 보여주기 위한 예시이며 특정 시점의 실제 가격이 아니다.

다루지 않은 것

  • 자동 확장(오토스케일링)의 판단 기준과 지연
  • 데이터베이스의 수평 확장(샤딩·복제)
  • 암달의 법칙과 확장의 이론적 한계
  • 컨테이너·오케스트레이터를 통한 실제 배포 방법

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

이제 직접 만들어 보세요

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

실습 과제 열기

이 강의에 물어보기

하루 5번

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