개요
지난 시간 세션과 쿠키를 이용한 로그인에 대해 알아보았습니다. 이러한 개념을 바탕으로 로그인 기능 개발을 들어가기 전에 생각해볼 문제가 생겼습니다. 현재 프로젝트의 사용자가 많아져서 가용 중인 서버로 수많은 클라이언트들을 감당할 수 없는 환경에 이르면 어떻게 해야 할까요?
지금부터 서버가 대량의 트래픽을 해결하는 방법에 대해서 알아보겠습니다.
Scale-Up / Scale-Out에 대해 알아보자!
스케일 업이란 단일 서버(하드웨어)의 성능을 증가시켜서 더 많은 요청을 처리하는 방법을 의미합니다. 즉, 단일 하드웨어의 성능을 높이기 위해 CPU, 메모리, 하드디스크 등을 업그레이드하거나 추가하는 것을 의미합니다.
반면, 스케일 아웃은 동일한 사양의 새로운 서버를 추가하여 성능을 증가시키는 방법을 말합니다. 서버가 증설됨에 따라 여러 대의 서버가 트래픽을 나누어 갖게 되고, 각각의 서버가 이를 처리하게 됩니다.
두 방법 다 다수의 트래픽을 처리하는데 좋은 방법임에는 분명합니다. 그렇다면 두 방법 중 어떤 방법을 선택해야 할까요?
조금 더 자세히 알아보도록 하겠습니다!
스케일 업(Scale-Up)
스케일업은 별도의 서버를 추가하지 않기 때문에 여러 대의 서버를 관리하면서 발생하는 데이터 정합성 이슈에서 자유롭습니다.
또한 서버를 한 대로 관리하면 별도의 소프트웨어 라이선스 추가 비용이 발생하지 않습니다.
무엇보다도 스케일 업은 하드웨어를 추가하고 교체하는 작업이기 때문에 구현이 어렵지 않습니다.
이렇게 구현도 쉽고, 관리도 쉽다면 과연 스케일 업의 한계는 무엇일까요?
스케일 업은 이러한 장점들에 비해서 무시하지 못할 단점들도 존재합니다.
하나의 서버 장비에는 설치 가능한 CPU, 메모리, 디스크 수의 제한이 있습니다. 한정된 자원을 초과하여 성능을 증가시키기 위해서는 서버 자체를 변경해야만 합니다.
또한 소프트웨어 구조상 아무리 스케일 업을 한다고 하더라도 일정 수준이 넘어가는 순간 성능 증가 폭이 미미해지게 됩니다.
그러므로 최종적으로는 성능 증가 대비 업그레이드 비용 굉장히 비싸집니다.
이보다 더 큰 문제는 스케일 업으로만 성능을 증가시킨 서버는 한 대가 모든 클라이언트의 트래픽을 감당해야 하기 때문에 심각할 경우, 해당 서버가 복구되기 전까지 서비스를 중단해야 하는 상황에 빠질 수 있습니다.
이와 같이 스케일 업을 한 서버의 스펙으로도 감당하지 못할 트래픽이 발생한다면 어떨까요?
장애가 발생할 때마다 서비스는 끊기고 복구하더라도 서비스 이용자가 지속적으로 증가한다면 이러한 일이 반복되겠죠?
그렇기 때문에 스케일 아웃이 필요합니다. 다음은 스케일 아웃에 대해 알아보겠습니다.
스케일 아웃(Scale-Out)
스케일 아웃은 동일한 사양의 새로운 서버를 추가하여 성능을 증가시키는 방법을 말합니다. 스케일 아웃을 하게 되면 하나의 노드에서 장애가 발생하더라도 다른 노드에서 서비스 제공이 가능하여 가용성을 높일 수 있다는 장점이 있습니다.
무엇보다도 필요에 따라 더 많은 서버를 추가하고 감소시킬 수 있습니다. 즉 스케일 업이 확장에 한계가 있는 반면에 스케일 아웃의 경우 확장에 유연합니다.
스케일 아웃을 하면 로드 밸런싱을 구현해야만 합니다. 이는 트래픽이 증가함에 따라 서버의 로드율, 부하량, 처리 속도 등을 고려하여 여러 대의 서버가 트래픽을 아래 그림과 같이 적절히 분담하여 처리할 수 있도록 합니다. 이를 통해 상대적으로 단일 서버에 작업이 쌓여서 멈춰있는 병목현상을 줄일 수 있습니다.
스케일 아웃도 역시 단점은 존재합니다. 서버가 여러 대로 늘어남에 따라서 각 서버에 설치해야 하는 소프트웨어 라이선스 비용이 증가합니다. 이러한 단점의 경우에는 가능한 오픈소스를 활용한다면 어느 정도 비용을 절약할 수 있겠죠?
이보다 가장 치명적인 단점은 여러 대의 서버로 하나의 서비스를 위해 사용함으로써 데이터 불일치가 잠재적으로 발생할 수 있다는 점입니다.
위 그림을 보시면 다중 서버에서 로그인 요청 시 발생하는 데이터 불일치 문제를 확인할 수 있습니다.
간략히 설명하자면 User1의 경우 로그인 시, 최초 접속한 서버(그림에서는 WAS_1)의 세션 저장소에 세션을 생성하고 로그인 정보를 저장합니다.
이후에 세션 ID를 클라이언트에게 발급하게 되고, 이를 클라이언트의 쿠키 저장소에 저장하여 다음 요청을 보낼 때마다 이를 꺼내서 HTTP 요청 헤더에 실어서 보내게 됩니다.
단일 서버의 경우에는 문제없이 동작하지만 그림과 같이 서버가 2대 이상 늘어날 시에는 WAS_1에서 발급받은 세션 ID를 WAS_2에서 인증하게 되면 WAS_2 에는 존재하지 않는 세션이므로 인증이 처리되지 않습니다.
이렇게 장점과 단점이 있는 스케일 업과 스케일 아웃 중 어떤 방법을 사용해야 하는지에 대해서 알아보겠습니다.
Scale-Up과 Scale-Out 무엇을 선택해야 할까?
지금까지 사용자 증가에 따른 서버 성능 증가 방법에 대해서 알아보았습니다. 결론적으로 서버는 스케일 아웃과 스케일업을 적절한 용도에 맞게 사용해야 합니다.
스케일 업의 경우에는 빈번한 갱신이 일어나는 가운데 철저하게 ACID를 지켜야만 하는 관계형 데이터베이스 서버와 같은 시스템에서 적절합니다. 스케일 아웃은 정합성 이슈에서 자유로울 수 없기 때문입니다.
스케일 아웃의 경우에는 각각의 트랜잭션 처리는 비교적 단순하지만 다수의 처리를 동시 병행적으로 실시하지 않으면 안 되는 경우에 적절합니다. 가장 적절한 예가 웹 서버입니다. 웹 서버는 네트워크로부터 보내온 다수의 요구를 동시 병행하여 처리할 필요가 있지만 각각 처리는 비교적 단순하기 때문입니다.
현재 진행 중인 프로젝트인 'AGORA' 웹 애플리케이션은 소셜 네트워크 서비스이므로 다수의 클라이언트가 접속하고 요청을 처리하는 웹 서비스입니다. 이러한 서비스를 감당하는 서버의 경우 스케일 아웃이 적절할 것이라고 생각되는데 지속적으로 의문이 생기는 정합성 문제는 어떻게 해결해야 할까요?
이에 대해서는 다음 포스트에서 자세히 알아보겠습니다~!!
정리해보기
1. Scale-Up은 서버의 성능을 높이기 위해서 CPU, 메모리, 디스크 등의 하드웨어를 추가하거나 더 좋은 하드웨어로 교체하여 단일 서버 자체의 성능을 높이는 것을 의미합니다.
2. Scale-Out은 서버의 성능을 높이기 위해서 동일 성능의 서버를 추가하여 부하를 분산시켜 처리 능력이 향상하는 것을 의미합니다.
3. Scale-Up과 Scale-Out은 각각 장점과 단점을 갖고 있지만 이에 따라 적절한 시스템에 사용하면 서버 성능에 있어서 긍정적인 효과를 얻을 수 있습니다.
참고
- 이것이 레디스다, 2015년 2월 2일 전자책 발행본
- "스케일 아웃과 스케일 업 - 서버 처리능력 향상의 길", 쿠리하라 키요시, 2006-09-19
https://www.zdnet.co.kr/view/?no=00000039151294
프로젝트 참고
- Social Network Service AGORA, https://github.com/f-lab-edu/sns-project
f-lab-edu/sns-project
Contribute to f-lab-edu/sns-project development by creating an account on GitHub.
github.com
다음 포스팅에는!
'다중 서버 환경에서 세션을 어떻게 공유하고 관리할까? - 2편 (Multi Server 환경에서 세션을 어떻게 관리할까?)'에 대해 알아보겠습니다!
