시스템 확장성

모든 시스템은 보통 단일 머신에서 시작하며, 처음에는 단순합니다. 낮은 규모에서는 서버가 들어오는 요청을 처리하고, 로직을 실행하며, 데이터를 관리하는 데 큰 부담이 없기 때문에 잘 동작합니다.

애플리케이션이 성장하면 수요도 증가합니다. 사용자가 많아질수록 동시에 들어오는 요청이 늘어나고, 이는 CPU, 메모리, 네트워크 자원에 압박을 줍니다.

데이터 증가도 또 다른 부담을 더합니다. 데이터셋이 커질수록 더 많은 저장 공간이 필요하고 쿼리도 느려져 응답 시간이 더 길어집니다.

결국 시스템은 한 대의 머신으로는 더 이상 따라갈 수 없는 지점에 도달합니다. 성능을 유지하고, 느려짐을 방지하며, 증가하는 부하 속에서도 시스템이 안정적으로 계속 동작하도록 하려면 확장이 필요합니다.

수직 확장, 또는 스케일 업이라고도 하는 방식은 단일 서버를 업그레이드하여 시스템 용량을 향상시킵니다. 일반적으로 더 많은 CPU 코어를 추가하거나, RAM을 늘리거나, 저장소를 확장하는 작업이 포함됩니다.

이 접근 방식은 간단합니다. 시스템 아키텍처는 그대로 유지되며, 네트워크 통신이나 데이터 동기화 같은 분산 시스템의 복잡성을 도입할 필요가 없습니다.

하지만 수직 확장에는 명확한 한계가 있습니다. 물리적 머신은 일정 수준까지만 업그레이드할 수 있고, 고성능 하드웨어는 점점 더 비싸집니다.

이러한 한계 때문에 수직 확장은 초기 단계에서는 잘 작동하지만, 결국 대규모 시스템에는 충분하지 않게 됩니다.

수평 확장은 스케일 아웃이라고도 하며, 단일 서버를 업그레이드하는 대신 더 많은 서버를 추가하여 시스템 용량을 향상시킵니다. 각 서버는 전체 작업 부하의 일부를 처리합니다.

들어오는 트래픽은 이러한 서버들에 분산되므로, 단일 머신 구성에 비해 시스템이 훨씬 더 많은 요청을 병렬로 처리할 수 있습니다.

이 접근 방식은 신뢰성도 향상시킵니다. 한 서버가 실패하더라도 다른 서버들이 계속 요청을 처리할 수 있어 장애의 영향을 줄입니다.

하지만 수평 확장은 분산 시스템의 복잡성을 도입하며, 이를 위해 조정, 로드 밸런싱, 데이터 일관성 메커니즘이 필요합니다.

시스템이 수평적으로 확장되면, 들어오는 트래픽을 여러 서버에 분산해야 합니다. 로드 밸런서는 이 서버들 앞에 위치하며 모든 요청의 진입점 역할을 합니다.

모든 트래픽을 한 대의 머신으로 보내는 대신, 로드 밸런서는 라운드 로빈(round-robin)이나 최소 연결 수(least connections) 같은 알고리즘을 사용해 요청을 고르게 분산합니다. 이렇게 하면 어떤 단일 서버도 병목이 되는 것을 방지할 수 있습니다.

로드 밸런서는 서버의 상태도 지속적으로 확인합니다. 서버가 느려지거나, 중단되거나, 헬스 체크에 실패하면 자동으로 풀에서 제거되어 사용자가 고장 난 인스턴스로 라우팅되지 않습니다.

또한 로드 밸런서는 SSL 종료, 경로 기반 요청 라우팅, 트래픽 셰이핑 같은 작업도 처리할 수 있습니다. Nginx, HAProxy, 그리고 클라우드 관리형 로드 밸런서 같은 도구는 현대 시스템에서 이 계층을 구현하는 데 널리 사용됩니다.

로드 밸런서는 단순히 트래픽을 나누는 장치가 아닙니다 — 트래픽을 어떻게 분산하느냐가 중요합니다.

가장 단순한 전략은 round-robin으로, 각 요청을 순서대로 다음 서버에 보냅니다. 이 방식은 서버가 동일할 때는 잘 동작하지만, 작업 부하가 달라지면 문제가 생깁니다.

Least connections는 현재 활성 요청 수가 가장 적은 서버로 트래픽을 라우팅하여 이를 개선하며, 과부하를 줄이고 응답 시간을 향상시킵니다.

Sticky sessions는 사용자를 같은 서버에 계속 연결합니다. 세션 데이터가 로컬에 저장될 때 유용하지만, 유연성을 떨어뜨리고 부하가 고르지 않게 될 수 있습니다.

현대 시스템은 health checks와 weights를 함께 사용합니다. 더 강력한 서버는 더 많은 트래픽을 처리할 수 있고, 장애가 발생한 서버는 자동으로 제외됩니다.

전략을 잘못 선택하면 로드 밸런서가 있어도 부하가 고르지 않게 분산되고, 지연 시간이 증가하며, 인프라가 낭비됩니다.

무상태 시스템에서는 각 요청이 독립적입니다. 서버는 이전 요청이나 사용자 세션에 대한 정보를 로컬 메모리에 저장하지 않습니다.

대신 사용자 세션이나 인증 데이터와 같은 필요한 상태는 데이터베이스, 캐시, 또는 전용 세션 저장소 같은 외부 시스템에 저장됩니다.

이 설계는 수평 확장을 훨씬 더 쉽게 만듭니다. 어떤 서버도 고유한 세션 데이터를 보유하지 않으므로, 이전 요청이 어디에서 처리되었는지 신경 쓰지 않고 사용 가능한 어떤 서버로도 요청을 라우팅할 수 있습니다.

무상태 아키텍처는 서버를 추가, 제거, 교체해도 사용자 상호작용에 영향을 주지 않기 때문에 신뢰성과 유연성도 향상시킵니다.

실제 시스템의 트래픽은 일정하지 않습니다. 사용량은 피크 시간대에 급증하고 비피크 시간대에는 감소할 수 있어, 고정된 인프라는 비효율적입니다.

오토스케일링은 시스템 용량을 자동으로 조정하여 이 문제를 해결합니다. 트래픽이 증가하면 새 서버를 추가해 부하를 처리하고, 트래픽이 감소하면 사용하지 않는 서버를 제거합니다.

이 과정은 일반적으로 CPU 사용률, 메모리 사용량, 요청률 같은 메트릭에 의해 결정됩니다. 시스템이 수요 변화에 빠르게 반응할 수 있도록 임계값이 정의됩니다.

오토스케일링은 성능과 비용 효율성을 모두 향상시킵니다. 시스템은 수동 개입 없이 갑작스러운 급증을 처리할 수 있으며, 사용량이 낮을 때 불필요한 인프라 비용도 피할 수 있습니다.

사용자가 애플리케이션에 접근하면, 데이터는 일반적으로 중앙 서버를 거치며 이동하는데, 이 서버는 지리적으로 멀리 떨어져 있을 수 있습니다. 이 거리는 지연 시간을 발생시키고 응답 속도를 느리게 만듭니다.

CDN은 이미지, 스크립트, 스타일시트와 같은 정적 콘텐츠를 전 세계에 분산된 엣지 서버에 캐시함으로써 이 문제를 해결합니다. 사용자가 요청을 보내면 가장 가까운 엣지 위치에서 응답이 제공됩니다.

이렇게 하면 데이터가 이동해야 하는 거리가 크게 줄어들어 로딩 시간이 빨라지고 사용자 경험이 향상됩니다.

CDN은 또한 트래픽의 상당 부분을 처리하여 원본 서버의 부하를 줄여줍니다. Cloudflare, AWS CloudFront, Fastly 같은 서비스는 확장 가능한 시스템에서 이 계층을 구현할 때 흔히 사용됩니다.

확장 가능한 시스템은 단일 구성 요소가 아니라, 증가하는 수요를 처리하기 위해 함께 동작하는 여러 계층의 조합입니다. 각 계층은 요청 흐름에서 특정 기능을 담당합니다.

사용자는 먼저 CDN과 상호작용하며, CDN은 캐시된 콘텐츠를 제공하고 지연 시간을 줄입니다. 동적 처리가 필요한 요청은 로드 밸런서로 전달됩니다.

로드 밸런서는 트래픽을 여러 애플리케이션 서버에 분산하여 시스템이 많은 요청을 병렬로 처리할 수 있게 합니다.

애플리케이션 서버는 분산 데이터베이스와 상호작용하며, 이 데이터베이스는 대용량 데이터셋과 높은 쿼리량을 처리하기 위해 데이터를 분할하거나 복제합니다.

이러한 계층형 접근 방식은 시스템의 각 부분이 독립적으로 확장되도록 하여, 전체 시스템을 다시 설계하지 않고도 사용자, 트래픽, 데이터의 증가를 처리할 수 있게 합니다.