다중 서버 환경 1편 - Scale Up & Scale out
네이버, 카카오, 배민 또는 chatGPT, BARD 등 대형 서비스의 경우 사용자가 많다. 이렇게 크고 사용자가 많을수록 트래픽이 늘 수밖에 없는데 어떻게 서버를 안정적으로 운영할까?
이를 위해 대규모 트래픽을 해결하기 위한 방법에 대해 알아보고자 한다.
1. 기존 서비스의 문제점
- AWS에 발급받은 서버 한 대에서 Nginx - Apache - DB 이렇게 3개의 서버가 연결되어 있다. 이때 어느 한 쪽이라도 문제가 있어도 서비스가 제대로 작동하지 않는다.
- 만약 서비스의 사용자가 늘어나게 된다면, 트래픽을 감당하지 못하고, 서버가 터지게 된다.
이 밖에도 여러 문제점이 있다고 한다. 이러한 대규모 트래픽을 감당하기 위해서는 서버를 업그레이드 해야 한다.
2. 서버 Upgrade
따라서 서버를 업그레이드 하도록 해야 한다. 이를 위한 방법으로는 크게 2가지로 나뉜다.
- 현재 서버를 업그레이드 하는
Scale-Up과 - 서버를 여러 개로 만드는
Scale-Out이 있다.
💪Scale-Up
캐쉬템 장착!
Scale-Up은 기존의 하드웨어를 보다 높은 사양으로 업그레이드 하는 것을 의미한다. 서버의 처리 능력을 좋게 만들어 많은 트래픽을 해당 서버가 처리할 수 있도록 한다.- 더 좋은 CPU, 더 좋은 디스크를 추가하여 업그레이드를 시키는 것을 의미한다.
- 하나의 서버의 능력을 높이는 것이기 때문에 수직 스케일링(vertical scaling)이라고도 한다.
장점
- [설계] 간단하고, 따로 프로그램 작업을 해줄 필요가 없다. 따라서, 구축 설계가 쉽다.
- 여러 대의 서버에 대해 데이터 일관성을 유지해야 할 작업이 필요하지 않다.
- 컨트롤러나 네트워크 비용이 별도로 발생하지 않다
- [확장성] CPU 변경, RAM 추가 등으로 하드웨어 장비의 성능을 높인다. (비교적 업그레이드가 쉬음)
- 듀얼 컨트롤러로 고가용성(High Availability, HA) 구성이 가능해 다운타임을 줄일 수 있다.
단점
- [확장성] 하드웨어 허용 범위 내에서만 확장이 가능하기 때문에 그 이상으로 업그레이드 하기에는 용량 및 성능 확장에 한계가 있다. 이를 위해서는 새로운 장비를 교체하는 방법밖에 없다. 새로운 장비로 교체할 때에도
- [비용] 성능 증가에 따른 비용 증가폭이 크다.
- [장애] 서버 한 대에 모든 부하가 집중되므로 장애 영향도가 크다. (치명적이다)
Scale-Up 구조에서는 추가적인 네트워크 연결 없이 용량을 높일 수 있고, 추가 용량이나 업그레이드 비용만 부가되기 때문에 비용적인 증강은 Scale-Out에 비해 낮다. 무엇보다 비교적 업그레이드가 쉽다.
👩👩👧👦Scale-Out
복사복사!
Scale-Out은 여러 대의 서버가 트래픽을 나눠 가진다.Scale-Up과는 달리 업그레이드에 제한이 없으며, 경제적이다.- 하지만 하나의 서버가 아니기 때문에 메모리를 공유하지 않는 다는 점에서 일관성을 유지하기 위한 비용이 든다는 문제가 있다.
- 수평 스케일링이라고도 한다.
이때, 세션 쿠키가 공유되지 못하거나 DB의 데이터가 불일치 하는 상황이 발생하게 되는데 이렇게 발생한 데이터 불일치 문제를 “데이터 정합성 문제”라고 한다. 이에 대해서는 다음 글에서 더 자세히 살펴보겠다.
장점
- [확장성] 하나의 장비에서 처리하던 일을 여러 장비에서 처리가능함. 즉, 수평 확장으로, 지속적인 확장이 가능하다.
- [비용] 비교적 저렴한 서버 사용으로 비용 부담이 적음,
Scale-Up에 비해 경제적이다. - [장애] 분산 처리로 인한 장애 시 전면 장애의 가능성이 적다. (서버 한 대가 장애가 발생하더라도 다른 서버로 서비스 제공할 수 있다.)
단점
- [설계] 모든 서버의 데이터 일관성을 유지해야 하므로, 설계 관리하기 복잡하다.
- [관리] 관리 비용이 증가한다.
🔧활용
스케일업이 더 좋은지, 스케일아웃이 더 좋은지에 대해서는 질문이 많이 제기가 되었다. 하지만 두 가지 유형 모두 장점과 단점이 있으며, 어떤 상황에는 Scale-Out이 더 잘 맞을 수 있고, 또 어떤 상황에서는 Scale-Up이 더 유리할 수도 있다.
📌Scale-Up
- 성능 중심의 작업
- 특히 데이터베이스와 같은 워크로드에서 고성능 스토리지가 필요할 때 스케일업은 적합하다.
- 온라인 금융 거래와 같이 워크플로우 기반에 빠르고 정확하면서 단순한 처리가 필요한 OLTP(Online Transaction Processing) 환경
- 하나의 강력한 시스템을 관리하는 것이 여러 시스템을 관리하는 것보다 더 쉬울 수 있다.
- 강력한 하드웨어의 모든 자원을 최대한 활용하고 싶을 경우.
- 개별 파일이나 데이터 세트가 크기 때문에 여러 노드에 분산되지 않아야 하는 경우.
- 엔터프라이즈 수준의 하드웨어에서는 종종 높은 수준의 구성 요소 중복성을 제공하여 높은 안정성을 확보할 수 있다.
📌Scale-Out
- 대규모 데이터 저장
- 대용량의 데이터를 저장하고 관리해야 할 때, 스케일아웃 방식이 더 경제적이고 효율적일 수 있다.
- 데이터의 데이터 마이닝이나 검색엔진 데이터 분석 처리 등을 대표하는 OLAP(Online Analytical Processing) 애플리케이션 환경
- 백업하고자 하는 데이터가 수십 TB에서 페타바이트급을 넘어선다면 스케일아웃 스토리지를 도입하는 편이 성능 면과 비용효율 면에서 더욱 뛰어나다.
- 일반적인 하드웨어를 사용하여 구축할 수 있으므로 초기 비용과 확장 비용이 저렴하길 원하는 경우.
- 하나의 노드가 실패해도 시스템 전체가 계속 동작할 수 있으므로 높은 가용성이 필요할 때 적합하다.
- 다양한 워크로드와 어플리케이션 요구 사항에 따라 시스템을 쉽게 조정할 수 있길 원하는 경우.
Scale-Out을 이용했을 때, 데이터가 불일치 하는 상황이 발생하게 된다. 이러한 발생한 데이터 불일치 문제를 “데이터 정합성 문제”라고 한다. 이를 해결하기 위해, 어떻게 여러 대의 서버에서 사용자의 세션 정보를 공유할 것인가를 정해야 한다.
다음 글은 "데이터 정합성 문제"를 해결하기 위한 세션 정보에 관한 글로 가져오겠다.
References
스케일업 & 스케일아웃
- 초보 개발자가 대규모트래픽에 대응하는 과정(Scale Up vs Scale Out), rudus1012, https://velog.io/@rudus1012/초보-개발자가-대규모트래픽에-대응하는-과정Scale-Up-vs-Scale-Out
- 서버가 대량의 트래픽을 해결하는 방법 (Scale-Out, 다중서버), wkdgus7113, https://velog.io/@wkdgus7113/서버가-대량의-트래픽을-해결하는-방법-Scale-Out-다중서버-jk063hwk
- 스토리지 기초 지식 3편: 스케일 업과 스케일 아웃, 박 주형 (jhpark@gluesys.com), https://tech.gluesys.com/blog/2020/02/17/storage_3_intro.html
- Scale-Up vs. Scale-Out Storage: Why Choose?, Brien Posey, https://www.itprotoday.com/storage/scale-vs-scale-out-storage-why-choose#close-modal
'🗃️Backend' 카테고리의 다른 글
| [Server] 로드밸런싱 (Load Balancing) 내 맘대로 쉽게 요약 (4) | 2023.08.23 |
|---|---|
| [Spring] 0. About Spring + 1. 프로젝트 환경설정 (ing) (2) | 2023.07.25 |
