현재 진행중인 프로젝트는 중고거래 플랫폼인 당근마켓의 API 서버를 구현해보는 토이 프로젝트입니다.
당근마켓은 2020년 9월을 기준으로 월간 이용자 수 1000만에 이르는 대규모 서비스입니다. 이와 같은 서비스 플랫폼을 개발하면서 반드시 고민해야하는 문제는 "수많은 사용자가 서비스를 이용한다면 과연 서버가 이를 감당할수 있을까?" 라는 점입니다.
아마도 지금과 같이 하나의 서버로 구성된 서비스는 밀려오는 수많은 클라이언트들을 단 몇초도 감당하지 못할 것입니다. 만약 실제로 운영되는 서비스였다면 이는 곧 회사의 금전적인 손실로 연결될 것입니다.
그렇다면 이러한 대규모 트래픽을 처리해야하는 문제를 서버는 어떻게 해결할 수 있을까요?
Scale Up과 Scale Out 이라는 것이 존재합니다.
수많은 사용자의 트래픽을 서버가 견딜수 있도록 하려면 어떻게 해야할까요? 간단하게 생각해보면 다음의 두 가지 경우를 고려해볼 수 있을 것 같습니다.
- 더 좋은 성능을 가진 서버로 업그레이드한다.
- 서버를 여러대 설치하여 다수의 서버가 이를 처리하도록 한다.
두 가지 방법 모두 정답이 될 수 있습니다. 앞서 언급한 서버의 성능을 업그레이드 하는 방법은 Scale Up 이라고 하고 서버의 개수를 늘리는 방법을 Scale Out 이라고 합니다.
그럼 Scale Up과 Scale Out에 대해서 좀 더 자세히 알아보도록 하겠습니다.
Scale Up
Scale Up은 단어 뜻 그대로 수직적인 확장 방법을 의미합니다. 서버에 CPU나 메모리 등을 추가하여 서버 자체의 성능을 증강시켜 처리능력을 향상시키는 방법입니다.
Scale Up을 사용한 성능 향상 방법에는 어떠한 장점이 있을까요?
- 단순히 서버의 장비를 추가하거나 교체하면 되기 때문에 구축 및 설계가 간단합니다.
- 별도의 컨트롤러나 네트워크 인프라 비용 등이 발생하지 않습니다.
- 별도의 서버를 추가하지 않기 때문에 여러대의 서버를 관리하면서 발생할 수 있는 데이터 정합성 문제에서 자유롭습니다.
그렇다면 Scale Up만으로 무한대로 서버의 성능을 향상시킬 수 있을까요?
그렇지 않습니다. Scale Up의 성능향상에는 한계가 존재합니다.
- 하나의 서버에는 추가할 수 있는 부품의 개수가 제한되어 있습니다.
- 한정된 자원을 초과하여 성능을 향상시키기 위해서는 서버 자체를 변경해야 합니다.
- 매번 장비가 업그레이드 될 때마다 서버의 장비를 교체하는 것은 비용이라는 문제가 존재하기 때문에 지속적인 확장이 불가능합니다.
- 하나의 서버에서 모든 트래픽을 감당해야 하기 때문에 장애극복 기능이 현저히 떨어지게 됩니다.
여기서 가장 중요한 문제점은 바로 마지막 항목입니다. 아무리 서버의 성능을 향상시키더라도 하나의 서버에 트래픽이 집중되는 문제는 여전히 남아있습니다. 또한 서버를 하나만 사용한다는 것은 곧 서버가 다운되면 시스템 전체의 장애로 이어진다는 것입니다.
때문에 해당 서버가 복구되기 전까지 정상적으로 서비스를 운영할 수 없는 상황이 발생할 것입니다.
Scale Out
Scale Out은 Scale Up과는 반대로 수평적인 확장을 의미합니다. 서버 자체의 성능을 향상시키는 방법이 아닌 서버의 대수를 늘려서 성능을 향상시키는 방법입니다.
Scale Out을 사용한 성능향상 방법에는 어떠한 장점이 있을까요?
- 필요에 따라 서버의 개수를 추가하거나 감소시킬 수 있기 때문에 확장이 유연합니다.
- 여러대의 서버를 이용한 분산처리가 가능하기 때문에 특정 서버에 트래픽이 집중되어 부하가 발생하는 것을 분산할 수 있습니다.
- 하나의 서버에 장애가 발생하더라도 다른 서버에서 서비스 제공이 가능하기 때문에 시스템의 가용성을 높일 수 있습니다.
Scale Up과 마찬가지로 Scale Out 또한 여러가지 한계점을 가지고 있습니다.
- 서버를 추가하는 복잡성 때문에 Scale Up 보다 유연한 확장이 가능하지만 무한정으로 확장이 가능하지는 않습니다.
- 여러대의 서버를 관리하기 위한 설계와 구현이 복잡해지고 이에 따른 관리 비용 또한 증가하게 됩니다.
- 서버의 개수가 늘어난 만큼 문제 발생의 잠재적인 원인 또한 증가할 것입니다.
- 서버 각각의 성능이나 안정성 면에서는 Scale Up 방식보다 뒤쳐질 수 밖에 없습니다.
- 데이터 불일치 문제가 발생할 수 있습니다.
Scale Out에서 고민해야하는 가장 큰 문제점은 바로 데이터 불일치 문제입니다. 만약 로그인된 사용자의 정보와 같은 특정 정보가 특정 서버에만 저장되어있다면 어떠한 문제가 발생할까요?
만약 로드 밸런서에 의해 사용자의 요청이 다른 서버로 매칭된다면 해당 서버에는 사용자의 데이터가 존재하지 않기 때문에 사용자는 다시 로그인을 시도해야할 것입니다.
로그인과 같은 문제는 클라이언트 입장에서 다시 로그인을 하면 되기 때문에 간단한 헤프닝으로 끝날 수 있지만 금융 데이터와 같은 민감한 데이터에 이와 같은 문제가 발생한다면 간단한 헤프닝으로 끝날 수 있을까요?
때문에 Scale Out을 이용한 확장 방식에서는 반드시 데이터 정합성에 대한 문제를 고민해야합니다.
Scale Up과 Scale Out 중에서 어떠한 확장 방식을 사용해야 할까요?
Scale Up과 Scale Out 중 어느 한 가지 방법이 무조건 뛰어나다고 할 수는 없습니다. 서비스할 애플리케이션의 성격이나 스토리지의 용도 등에 따라서 각각의 장단점이 극명하게 나누어지기 때문에 이를 고려한 선택이 필요합니다.
데이터의 정합성을 요구하는 데이터베이스 서버나 금융거래와 같이 빠르고 정확한 처리가 필요하고 잦은 갱신이 발생하는 OLTP (Online Transaction Processing) 환경에서는 고성능의 Scale Up 방식이 적합합니다.
반면에 메일 서버, 게시판 서버, 데이터 읽기 전용 애플리케이션, 웹 서버 등 높은 병렬성을 실현하기 쉬우며 데이터의 정합성 유지가 쉬운 환경에서는 Scale Out 방식을 이용한 확장 방식을 통해서 높은 효율을 기대할 수 있습니다.
당근마켓 API 서버를 확장해봅시다
Scale Up과 Scale Out 방식에 대해 알아보면서 당근마켓이라는 서비스를 운영할 때에는 어떠한 방법으로 서버를 확장하는 것이 더 적합하고 효율적일지 고민해보았습니다.
당근마켓이라는 서비스의 특성상 평상시에도 많은 유저 트래픽이 발생하며, 수 많은 거래 정보를 조회하는 요청을 동시에 그리고 병렬적으로 처리해야합니다.
수 많은 사용자가 이용하는 만큼 애플리케이션 자체의 신뢰성 또한 중요하기 때문에 특정 서버에 장애가 발생하더라도 정상적으로 서비스를 제공할 수 있어야 합니다.
이러한 점들을 고려했을 때 트래픽을 분산시켜줄 수 있고, 시스템의 신뢰성이 높은 Scale Out 방식이 적합할 것이라는 결론을 내릴 수 있었습니다.
하지만 당근마켓 서비스는 사용자의 로그인 정보와 위치정보 등 특정 데이터를 반드시 필요로하는 서비스이기 때문에 Scale Out을 적용함으로써 발생할 수 있는 데이터 불일치 문제에 대해서는 반드시 해결이 필요로합니다.
다음 포스트에서는 Scale Out에서의 데이터 정합성 문제를 해결하기 위해 어떠한 방법들을 고려할 수 있는지 알아보도록 하겠습니다.
