초보 개발자가 대규모트래픽에 대응하는 과정(Scale Up vs Scale Out)

Rm·2021년 3월 13일

server

대규모 트래픽 대응 전략

목록 보기

1/3

현재 BackEnd 포토폴리오로 Gift-club 이라는 선물하기 서비스 프로젝트를 진행중에 있다가 한가지 의문점이 들었습니다.

네이버, 카카오, 배민 등 대형 서비스의 경우 사용자가 많은데 어떻게 안정적으로 서버를 운영하고 관리할까?

기존에 진행했던 서비스의 문제점과 해결방안을 찾고 현재 서비스에 적용해보려고합니다.

기존 서비스의 문제점

사실 기능 구현에 급급했던 과거 프로젝트 아키텍처는 많은 단점들을 포함하고 있었습니다.

AWS에 발급받은 서버 한대에서 Nginx - Apache - DB 3개의 서버를 돌려 어느 한곳만 문제가 있어도 서비스가 제대로 작동하지 않는 단점이 존재합니다.
만약에 서비스가 잘알려져 사용자가 늘어나게 된다면 트래픽을 감당하지 못하고 서버가 버티지 못하는 이슈가 발생합니다.

이 밖에도 여러 이슈가 있겠지만 이번 프로젝트에서는 이러한 부분을 해결하고자 합니다.

먼저 대규모트래픽을 감당하기 위해 스케일 업, 스케일 아웃 2가지 방법 중 트레이드오프를 고려해야 합니다.

Scale Up

Scale Up 방식은 말그대로 고성능 CPU, 메모리 확장, SSD 등 서버의 스펙을 높이는 수직 확장 방식입니다.

1) 장점

구축 설계가 쉬움
여러 대의 서버에 데이터 일관성을 유지해야하는 작업이 필요하지 않음
컨트롤러나 네트워크 비용이 별도로 발생하지 않음

2) 단점

서버 한대에 모든 부하가 집중되므로 장애 발생 시 치명적
용량, 성능 확장 제한
비용이 많이 듬

정리하자면 스케일업 아키텍처에서는 추가적인 네트워크 연결 없이 용량을 증강할 수 있고, 추가되는 용량이나 업그레이드 비용만 부가되기에 비용적인 증강은 스케일아웃에 비해 낮습니다. 무엇보다 비교적 업그레이드가 쉽고, 필요 장비와 전력 소모를 어느 정도 아낄 수 있습니다. 또한 스케일업도 듀얼 컨트롤러로 고가용성(High Availability, HA) 구성이 가능해 다운타임을 줄일 수 있습니다.

하지만 스케일업 아키텍처가 스키일아웃 아키텍처에 비해 무조건적으로 좋은건 아닙니다. 온라인 금융 서비스같은 경우 빠르고 정확하면서 단순한 처리가 필요한 OLTP(Online Transaction Processing) 환경에서는 고성능의 스케일업 방식이 적합합니다.

또한, 백업용 스토리지를 구축하는 데 있어서 향후 수년간 데이터 증가 폭이 미미하거나 규모가 작은 경우 스케일업 방식으로 구축하는 편이 경제적일 수도 있습니다.

Scale Out

스케일아웃은 비슷한 스펙의 서버를 여러대로 증설하여 로드밸런싱을 통한 병렬처리가 가능한 수평 스케일업 아키텍처입니다.

1) 장점

서버 한 대가 장애가 발생하더라도 다른 서버로 서비스 제공 가능
지속적인 확장성
분산 처리로 인한 장애 가능성이 낮아짐
저렴

2) 단점

설계 관리의 복잡성
관리 비용이 증가
모든 서버의 데이터 일관성을 유지해야함

스케일아웃 아키텍처의 가장 큰 장점 중 하나는 확장의 유연성에 있습니다.

또한, 하나의 시스템을 모니터링하기 쉬워 보다 이슈에 대응하기 좋습니다.

데이터베이스 워크로드 타입에 따라서 그에 적합한 확장 방식도 달라집니다. 빅데이터의 데이터 마이닝이나 검색엔진 데이터 분석 처리 등을 대표하는 OLAP(Online Analytical Processing) 애플리케이션 환경에서는 대량의 데이터 처리와 복잡한 쿼리가 이루어지기 때문에 스케일아웃 구성이 더 효율적이라고 할 수 있습니다.

하지만 스케일아웃도 단점이 존재합니다. 신입개발자가 아키텍처를 구성할 때 로드밸런싱의 이해도 문제, 서버가 증가함에 따라 같이 증가하는 장애 발생의 확률 또한 올라가는 단점이 있습니다.

서버가 증가하면서 자연스럽게 발생하는 I/O로 인해 지연이 발생할 가능성이 증가합니다.