만약 서비스를 운영중인데 사용자가 계속해서 증가한다면? 우리는 당연하게도 서버 증설을 고민할 수 밖에 없을 것이다.
요지는 사용자가 점점 늘어남에 따라 트래픽이 몰리게 된다면 서버를 어떤 식으로 확장 해야할까?
아마 제일 먼저 생각나는 단어가 Scale-Up
과 Scale-Out
일 것이다.
물리적으로 생각해도 사용자가 늘어난다면 그만큼 서버의 크기 또한 늘려야한다.
Scale-Up?
수직적 확장을 의미하며, 말 그대로 추가적인 RAM, CPU 등을 컴퓨터에 달아 업그레이드 하는 방식이다.
현재 서버의 성능을 향상하기위해 자원을 증가시키는 방법이다.
하지만 계속해서 추가적인 부품을 달아 해결할 수 없듯이 지속적인 확장이 불가하다. (가능할 수 있지만, 비용적인 지출이 상당해지기에 사실상 불가)
해결책으로는 새로운 기기를 사용하는 방법인데, 서로 다른 독립적인 기기로 데이터를 옮기기 위해 기존의 데이터를 백업 시킨 후, 데이터 migration을 매번 하는 것은 매우 시간이 오래걸리고 복잡한 작업이고, 데이터의 단위는 시간이 지날수록 점점 증가하기에 이 또한 불가하다고 봐야한다.
그리고 해당방법의 가장 큰 문제점이 뒤에 나올 Scale-Out
과 비교되는 부분인데, 하나의 서버를 확장한 것이기에 트래픽을 감당하지 못하고 서버가 죽게될 경우 서비스는 큰 타격을 입게된다.
Scale-Out?
수평적 확장 이라고도 불리며 추가적인 부품을 다는게 아닌, 새로운 서버를 추가하는 방식입니다. Scale-up
에서 부품 추가의 한계를 극복한 방법이다.
또한 트래픽이 많이 몰리게 되면, 로드밸런서를 통해 트래픽을 여러 서버로 분산시켜 작동할 수 있도록 설계하는 것이 가능하고 한 서버가 다운이 되더라도 다른 서버가 살아있기 때문에 전면장애 문제 또한 극복하였다.
사실 다른건 둘째치더라도 Scale-Out의 가장 큰 문제는 분산서버 환경에서 일어나는 데이터 불일치이슈가 제일크다.
예를 들어, 사용자1의 로그인 요청을 서버1이 받아 처리를 해서 서버1에는 사용자의 데이터가 존재하지만 서버2에서는 그러한 요청을 받은 적이 없기 때문에 만약 다시 로그인을 시도했는데 서버2가 받았다면 로그인이 안되는 문제점이 발생한다.
그럼 어떻게 해야돼요?
Scale-out 을 사용하는 적합 케이스
개개의 처리는 단순하지만 다수의 요청을 동시 병행적으로 처리 해야만 하는 상황 이거나, 갱신할 데이터의 정합성 유지에 특별한 요건이 없을 경우 적절하다.
대표적으로 웹 서버가 이에 해당된다.(클라이언트가 서버에 데이터를 요청하는 방식이기에)
만약 데이터베이스의 분할이 비교적 쉽다면 이러한 Scale-out의 장점을 적극적으로 활용을 할 수가 있다. 하나의 서버가 다운이 되어도 다른 서버에서 즉시 처리가 가능하기 때문이다.
Scale-Up을 사용하는 적합 케이스
Scale-up 은 데이터베이스에 갱신이 자주 발생을 하는 경우 적절하다.
Scale-out처럼 다른 조건의 네트워크를 통해 통신하게 되면 지연이 되버리고 곧 전체의 장애로 번지기에 서버를 추가해도 처리 능력이 비례하여 증가하지 않기 때문에 이러한 상황이라면 Scale-up이 적합하다.
'Tech-Interview' 카테고리의 다른 글
[Redis] Redis Eviction 정책 (0) | 2025.03.07 |
---|---|
JPA ID 생성전략 (0) | 2024.12.06 |
JPA N+1 문제 (0) | 2024.11.28 |
리터럴 String과 new String()의 차이 (0) | 2024.11.13 |
Docker와 컨테이너 (0) | 2024.11.04 |