수평 확장

수평 확장은 서버 대수를 늘려 더 많은 일을 받는 것입니다. 한 대의 성능을 키우는 대신 같은 일을 하는 기계를 옆에 더 세웁니다. 그래서 기계 한 대가 감당하는 양이 서비스 전체의 끝이 되지 않게 합니다.

쉽고 빠른 이해

수평 확장은 같은 서버를 여러 대 두고 일을 나눠 받는 것입니다. 한 대로 버티던 서비스에 똑같은 서버 두 대를 더 붙이는 식입니다.

이게 없으면 서비스가 받을 수 있는 양이 기계 한 대의 한계에 묶입니다. 그 한 대가 멈추면 서비스도 함께 멈춥니다.

어떻게 도나:

같은 애플리케이션을 여러 대에 똑같이 띄웁니다
앞에 선 장치가 들어온 요청을 그 대수만큼 나눠 보냅니다
요청 사이에 기억할 것은 서버 밖 저장소에 둡니다. 그래야 어느 대가 받아도 결과가 같습니다

대가도 있습니다. 관리할 기계와 설정이 늘어납니다. 데이터를 여러 대가 나눠 갖게 되면 어느 대를 봐도 같은 값이 나오도록 맞추는 일이 새로 생깁니다.

상세

이삿짐을 옮긴다고 해 봅시다. 한 사람이 한 번에 드는 짐에는 끝이 있습니다. 더 힘센 사람 하나로 바꾸는 방법이 있고, 사람을 여럿 불러 나눠 드는 방법이 있습니다. 수평 확장은 뒤쪽입니다.

다만 사람은 현장에서 서로 말을 주고받으며 몫을 나눕니다. 서버는 스스로 나누지 못합니다. 누가 어느 몫을 맡을지 정해 주는 쪽이 따로 있어야 합니다.

수평 확장(horizontal scaling)은 같은 일을 하는 기계를 여러 대로 늘려 처리할 수 있는 양을 키우는 것입니다. 스케일 아웃이라고도 부릅니다. 웹 서버를 한 대에서 다섯 대로 늘리고 그 앞에서 요청을 나눠 보내는 구성이 그것입니다.

이 절은 한 대를 키우는 길과 대수를 늘리는 길을 견준 뒤, 늘리려면 무엇이 먼저 갖춰져야 하는지와 늘려도 안 풀리는 것을 차례로 봅니다.

한 대를 키우는 길과 대수를 늘리는 길

기계 한 대가 처리하는 일의 양에는 끝이 있습니다. CPU(Central Processing Unit, 중앙 처리 장치) 코어 수와 메모리 크기가 그 끝을 정합니다. 요청이 그 끝을 넘으면 응답이 늦어지다가 실패합니다.

그 끝에 닿았을 때 길은 둘입니다. 한 대를 더 큰 기계로 바꾸는 것을 수직 확장이라고 부릅니다. 대수를 늘리는 것이 수평 확장입니다.

flowchart TD
    A["요청이 한 대의 끝을 넘었다"] --> B["수직 확장 · 그 한 대를 더 큰 기계로"]
    A --> C["수평 확장 · 같은 기계를 옆에 더"]
    B --> V
    C --> H
    subgraph V["수직 확장 뒤"]
        V1["큰 서버 한 대"]
    end
    subgraph H["수평 확장 뒤"]
        H1["서버 1"]
        H2["서버 2"]
        H3["서버 3"]
    end

그림의 두 갈래는 늘리는 대상이 다릅니다. 왼쪽은 기계 하나의 성능을, 오른쪽은 기계의 개수를 늘립니다. 이 차이가 아래 표의 나머지 줄을 전부 만듭니다.

	수직 확장	수평 확장
무엇을 늘리나	기계 한 대의 성능	기계 대수
애플리케이션	대개 손대지 않는다	여러 대에 나눠 돌 수 있게 고친다
늘릴 수 있는 끝	그때 살 수 있는 가장 큰 기계까지	대수를 더 붙이는 동안
한 대가 멈추면	서비스가 멈춘다	남은 대가 받는다
되돌리기	기계를 바꿔야 해서 멈춤이 따른다	대수를 빼면 된다

표에서 눈여겨볼 줄은 둘째 줄입니다. 수직 확장은 애플리케이션을 손대지 않아도 되는 대신 끝이 정해져 있습니다. 수평 확장은 끝이 열려 있는 대신 애플리케이션을 먼저 고쳐야 합니다.

나눌 수 있어야 늘릴 수 있다

대수를 늘려도 요청이 한 대로만 가면 달라지는 것이 없습니다. 들어온 요청을 대수만큼 나눠 주는 쪽이 앞에 있어야 합니다. 그 일을 부하 분산이 맡고, 그 일을 하는 장치를 로드 밸런서라고 부릅니다.

나눠 보내려면 어느 대가 받아도 결과가 같아야 합니다. 로그인 정보처럼 요청 사이에 이어지는 정보를 세션이라고 부릅니다. 세션을 서버 메모리에 두면 다음 요청이 다른 대로 갔을 때 그 기억을 잃습니다.

그래서 요청 사이의 정보를 자기 메모리에 안 들고 있는 서버로 만듭니다. 이런 서버를 무상태 서버라고 부릅니다. 세션은 모든 서버가 함께 보는 저장소로 옮깁니다.

무상태로 만들어 두면 대수를 늘리는 일이 로드 밸런서의 목록에 한 줄 더하는 일이 됩니다. 수평 확장이 어렵다는 말은 대개 이 조건이 아직 안 갖춰졌다는 뜻입니다.

상태를 가진 것은 늘리기가 다르다

애플리케이션 서버는 무상태로 만들 수 있지만 데이터베이스는 데이터를 들고 있어야 합니다. 데이터를 든 쪽은 대수를 늘린다고 일이 저절로 나뉘지 않습니다.

여기서 갈래가 둘입니다. 같은 데이터를 여러 대에 복사해 두고 읽기를 나누는 것을 복제라고 합니다. 데이터를 조각으로 갈라 대마다 다른 조각을 맡기는 것을 샤딩이라고 합니다.

복제는 읽기를 나누고 쓰기는 한 대에 모읍니다. 읽기가 훨씬 많은 서비스에 맞습니다. 샤딩은 쓰기까지 나누지만, 어느 조각이 어느 대로 갈지 정하는 샤드 키를 먼저 골라야 합니다.

샤드 키를 잘못 고르면 요청이 한 조각에 몰립니다. 그러면 대수는 늘었는데 일은 한 대가 다 합니다.

늘린 만큼 늘어나지는 않는다

대수를 두 배로 늘려도 처리할 수 있는 양이 두 배가 되지는 않습니다. 여러 대에 나눠 준 일이 결국 한 곳을 같이 거치기 때문입니다. 이렇게 전체를 묶어 버리는 단계를 병목이라고 부릅니다.

앱 서버를 열 대로 늘려도 모두 같은 데이터베이스 한 대를 부르면 병목이 그쪽으로 옮겨 갈 뿐입니다.

flowchart TD
    subgraph 앱["앱 서버 · 대수를 늘렸다"]
        A1["서버 1"]
        A2["서버 2"]
        A3["서버 3"]
    end
    A1 --> D["데이터베이스 한 대"]
    A2 --> D
    A3 --> D
    D --> R["전체는 이 한 대에 묶인다"]

그림에서 늘어난 것은 위쪽 세 대뿐이고 아래로 내려가는 길은 하나입니다. 그래서 수평 확장을 붙이기 전에 병목이 어느 단계인지부터 찾습니다. 그 단계가 아닌 곳을 늘리면 대수만 늘고 처리량은 그대로입니다.

나눌 수 없는 부분이 남아 있으면 대수를 아무리 늘려도 얻는 것에 천장이 생깁니다. 암달의 법칙이 이 천장을 다루는 이야기입니다. 여러 작업이 같은 잠금을 기다리는 락 경합처럼 나눠 가질 수 없는 자원이 그런 부분입니다.

늘리고 나면 새로 생기는 일

대수가 늘면 관리할 기계와 설정이 함께 늡니다. 요청 하나를 따라가려면 여러 대에 흩어진 로그를 한곳에 모아야 합니다.

데이터를 여러 대가 나눠 갖게 되면 어느 대를 봐도 같은 값이 나오도록 맞추는 일이 새로 생깁니다. 이 맞춤을 다루는 성질이 일관성입니다. 복제한 데이터가 모든 대에 닿기까지는 시간이 걸리므로, 방금 쓴 값을 다른 대에서 읽으면 옛 값이 나올 수 있습니다.

한 대 안에서 함수 호출이던 것이 대 사이 네트워크 호출로 바뀌면 그만큼 시간이 더 듭니다. 상대가 응답하지 않는 경우도 새로 생깁니다. 분산 시스템을 다루는 이야기가 여기서 시작됩니다.

언제 늘리고 언제 안 늘리나

요청이 한 대의 끝을 넘거나, 한 대가 멈춰도 서비스가 계속 돌아야 할 때 대수를 늘립니다. 부하에 따라 이 대수를 자동으로 조절하는 것이 오토스케일링입니다.

한 대로 요청을 넉넉히 받고 잠깐 멈춰도 괜찮은 서비스라면 한 대로 두는 편이 단순합니다. 나눌 수 없는 일이 병목이라면 대수를 늘려도 그 병목은 그대로 남습니다. 그때는 수직 확장이나 병목 자체를 고치는 쪽이 먼저입니다.

수평 확장

상세

한 대를 키우는 길과 대수를 늘리는 길

나눌 수 있어야 늘릴 수 있다

상태를 가진 것은 늘리기가 다르다

늘린 만큼 늘어나지는 않는다

늘리고 나면 새로 생기는 일

언제 늘리고 언제 안 늘리나

관련 항목

수평 확장과 맞세워지는 다른 확장 방식

수평 확장이 요청을 나눌 때 쓰는 수단

수평 확장이 서버에 요구하는 성질

수평 확장이 데이터를 나누는 방법

수평 확장으로 올리려는 지표

수평 확장을 가로막는 병목과 한계

수평 확장 뒤에 새로 생기는 문제

수평 확장을 굴리는 운영 기반