1. 트래픽이 늘어나면 어떻게 해야할까?
현재 작업 중인 팀 프로젝트에서 로그인 기능 구현 중 사용자가 많아져, 트래픽이 늘어날 경우 어떻게 대처할 것인가? 라는 문제에 대하여 이야기 중입니다.
사용자가 늘어나 트래픽이 늘어나게 된다면 언젠간 서버 하나로는 회원들의 로그인 정보가 담긴 session을 모두 저장할 공간이 없어질 때가 올텐데, 많은 양의 트래픽이 발생할 경우 어떻게 감당할것인가 하는 이야기가 나왔고, 해결 방법은 크게 두가지로 나뉜다는 것을 알게 되었습니다.
1. Scale-up
Scale-up은 수직적 확장이라고도 하는데, 서버의 사양을 높이는 것입니다.
CPU나 메모리 등 컴퓨터의 부품을 계속 교체해주는 방식인데, 하나의 컴퓨터로 모든 것을 해결할 수 있어 업그레이드가 쉽고(Scale-out과 비교시), 라이센스 비용을 아낄 수 있다는 장점이 있습니다.
하지만 컴퓨터를 업그레이드 할 때마다 서버가 종료되며, 부품을 추가할 슬롯이 부족하기 때문에 업그레이드에 한계가 있다는 단점이 있습니다.
또, 들이는 비용에 비해 서버의 성능이 크게 향상되지 않으며, 서버에 문제가 생겨 응답을 해줄 수 없는 상황이 온다면, 사용자는 아예 서비스를 사용할 수 없다는 단점도 있습니다.
2. Scale-out
Scale-out은 수평적 확장이라고도 하며, 서버의 수를 늘리는 것입니다.
Scale-up과는 다르게 제한없이 업그레이드를 할 수 있다는 것과, 서버가 여러대이기 때문에 하나의 서버가 문제가 생기더라도, 다른 서버를 이용하여 서비스를 제공할 수 있다는 장점이 있습니다.
하지만, 라이센스 비용이 들거나, 데이터 불일치 문제가 발생한다는 단점이 있습니다.
예를들어 위의 그림처럼 서버가 여러개로 나눠져 있을 경우, 사용자1이 1번 서버로 로그인 시, 2,3번 서버에는 로그인 세션이 없습니다.
그런데 이후에 세션이 없는 2번 서버로 요청을 하면 세션이 없기때문에 계속 로그인을 해달라는 문제가 발생할 수도 있습니다.
그래서 Scale-out으로 현재 문제를 해결한다면 데이터 불일치에 대한 해결도 생각해야 합니다.
2. 어떤 방식을 사용할까?
현재 프로젝트의 경우 이벤트의 등록, 신청이 실시간으로 이루어져야 하기 때문에, 서버에 장애가 일어나더라도 사용자에게 불편을 주지 않고, 서비스는 계속되어야 한다는 점을 중점으로 생각하고 진행하기로 하였습니다.
그래서 서버에 장애가 생길 경우 서비스를 이용하지 못하는 Scale-up이 아닌, 장애가 생기더라도, 다른 서버를 이용하여 서비스를 이어나갈 수 있는 Scale-out 방식으로 문제를 해결하기로 했습니다.
그 외에도 Scale-up의 단점 중 업그레이드에 한계가 있다는 단점이 있는데, 이는 Scale-up 방식만으로는 서비스의 성장에 한계가 있다는 뜻이기 때문에 좋은 방식이 아니라 생각했습니다.
그러면 이제 Scale-out을 적용하기 전 단점이었던 데이터 불일치 문제를 어떻게 해결하면 좋을지 더 알아보겠습니다.
데이터 불일치에 관한 해결은 다음 글에서 진행됩니다.
다음글
관련 프로젝트
- event-recommender-festa (2020-09 ~)