Scale out vs Scale up
저는 프로젝트의 개발 목표 중 하나인 대규모 트래픽을 처리하기 위한 앱을 만들기 위해서 두가지 방법을 생각했습니다. Scale out과 Scale up 서버 확장 방식입니다. 전자는 서버 하나의 성능을 올리는 방식이고, 후자는 서버의 개수 여러개로 늘리는 방법입니다. 서비스의 특성상 Scale out이 적합하다고 판단했습니다.
이유는 최악의 상황을 가정했을때, 하나의 서버가 하드웨어 성능 문제로 트래픽을 감당하지 못해서 사용자가 원하는 데이터를 받는 속도가 매우 느려지게 될 것이라 생각했기 때문입니다.
실제로 2014년도 말에 도서정가제 시행으로 인해 할인 도서 구매량이 급증하면서 온라인 서점이 마비되는 일이 있었습니다.
추후에 이러한 일이 벌어지지 않는다는것을 예측 하기 어렵기 때문에 트래픽을 무한하게 수용할 수 있는 방법인 Scale out으로 최악의 상황에 대처할 수 있도록 서버 구조를 생각했습니다.
Scale out을 도입하게 되면 두가지 문제가 생기게 됩니다. 트래픽 문제, 세션 데이터 불일치 문제입니다.
트래픽 문제
Scale out을 하게 되면 부하를 서버마다 적절하게 분배하는 방법을 검토 해야합니다. 최악의 상황에 사용자의 모든 요청이 하나의 서버에만 가게 되면, 다시 트래픽이 폭주하는 문제가 생기게 되기 때문입니다. 부하를 분산하는 로드밸런서를 사용하면 이 문제를 해결할 수 있습니다.
로드밸런서는 제가 사용중인 AWS를 기준으로 조사 했습니다.
로드 밸런서 유형
로드밸런서는 OSI Layer 중에서 4계층(Transport) 또는 7계층(Application Layer)에서 동작하는것을 사용합니다. AWS 에서는 세가지 로드밸런서를 제공하고 있습니다.
- Application Load Balancer (7 layer)
- Network Load Balencer (4 layer)
- Classic Load Balancer (4,7 layer)
L4 LoadBalancer
L4 로드밸런서는 L3, L4를 기반으로 동작합니다. port, ip를 기반으로 트래픽을 분산시킬 수 있습니다. L4는 L7보다 CPU 자원 소모를 적게 하는 경향이 있습니다. 그러나 NGINX 공식 홈페이지에 따르면, 요즘 하드웨어의 퍼포먼스를 생각하면 장점이 되기는 어렵습니다.
L7 LoadBalancer
http의 keep-alive를 옵션을 사용할 수 있습니다. L4에 비해 RPS(Request Per Second)가 적게 나오도록 할 수 있습니다. L7은 content를 기반으로 트래픽을 분산시킬 수 있습니다. 예를들어, 동영상 관련된 컨텐츠라면 동영상 서버로 보낼 수 있고 결제와 관련된 데이터를 처리하는 컨텐츠를 기반으로 라우팅을 할 수 있습니다.
세션 데이터 불일치
Scale out을 하게 되면 사용자가 로그인을 할때, 어플리케이션 서버에 있는 세션 데이터가 불일치하는 문제가 생길 수 있습니다. 예를들어 책을 구매하기 위해 A사용자가 로그인을 할때, 세션 데이터가 A서버에만 저장되는 문제가 생깁니다. B서버와 A서버가 A사용자의 세션 데이터가 일치하지 않게 됩니다.
'서버' 카테고리의 다른 글
| CPU Burst, IO Burst (0) | 2023.06.29 |
|---|---|
| linux file descriptor (0) | 2023.06.05 |
| 간단하고도 빠른 서버 성능 최적화 (node js를 중심으로) (0) | 2023.05.04 |
| HTTP 프로토콜이 만들어진 이유 (1) | 2022.09.11 |
| Scale out에 적합한 로그인 환경에 대해 검토한 글 (2) | 2022.09.11 |