서론
흔히 알고 있는 "트래픽이 증가하면 서버를 늘린다"에서 그치는 것이 아니라, 어떻게 서버를 늘리는지 그 방법은 어떤 것이 있는지 궁금하여 포스팅하게 되었습니다.
팀구라는 프로젝트를 진행하면서 채팅 서버에 약 40명 정도의 인원이 동시에 채팅을 연사 한 적이 있습니다. t2.micro 서버였지만 거뜬하더라구요. 그때 느낀 점이 "내 생각보다 서버는 튼튼하다"와 "대체 얼마나 많은 트래픽이 있어야 터질까?"였습니다.
국내에서 흔히 접할 수 있는 카카오, 네이버, 당근마켓, 배달의민족과 같은 서비스를 한다면, 사용자가 늘어남에 따라 많은 트래픽을 견디기 위해 어떤 대처를 하면 좋을까요?
"요새 내 몸이 하나로 부족해.."
다들 바쁘실 때 이런 말 쓰시죠? 이 상황에서 우리에겐 2가지 선택권이 있습니다. 더욱 높은 업무 강도를 수행할 수 있게끔 나를 강화하거나, 여러 업무를 나눠서 처리할 수 있도록 나를 분신술처럼 늘리거나.
자 어떤 선택을 하실 건가요?
서버도 이와 비슷한 선택을 할 수 있습니다. 바로 나를 강화하는 것인 Scale up과 나를 분신술처럼 몸을 여러 개 두는 Scale out입니다.
이 2가지 전략에 대해 조금 더 자세히 알아보도록 합시다.
Scale Up
사양을 증가시키는 방법. 즉 수직적 확장입니다. 서버에 CPU, 메모리 등을 추가해 서버 자체의 성능을 증강시켜 처리능력을 향상합니다.
AWS를 사용해보신 분들이라면 아시겠지만, 서버 사양을 늘리는 방법은 클릭 몇 번으로 해결이 가능합니다. 정말 간단하죠.
Scale up의 장점으로 어떤 것이 있을까요?
- 서버 장비를 추가 또는 교체하므로 방법이 간단하다
- 인프라 비용이 추가적으로 발생하지 않는다
- Scale out에 비해 데이터 정합성에서 자유롭다
위 점만 봤을 때는 Scale up으로만 확장해도 될 것 같습니다. 하지만, 이 것도 함께 살펴보시죠.
Intel의 대표적인 CPU를 예로 들어보겠습니다. i3에서 i5로 사양을 업그레이드했을 때 약 2배의 성능 증가가 이뤄진다고 합시다. 그럼 i5에서 i7으로 증가했을 때도 약 2배의 성능이 증가될까요? 만약, 1.5배라면? 점점 이 증가 수치가 줄어든다면? 그럼 이 부품 구매 비용이 성능 증가 비율과 정확히 비례할까요?
그렇지 않습니다.
i3에서 i5로 갈 때 2배의 성능 증가와 10만원의 비용이 발생할 때, i5에서 i7으로 갈 때 1.5배의 성능 증가와 20만원의 비용이 발생하는 것처럼 우리가 생각하는 이상적인 증강은 이루어지지 않습니다. 이 비용 증가는 위 사진처럼 칩 설계 등 매우 복잡한 상관관계가 있겠죠?
이처럼 Scale up에는 한계가 존재합니다.
- (물리적환경) 추가할 수 있는 부품의 개수가 제한되어 있음
- (물리적환경) 하드웨어의 냉각, 공간, 전력공급 등의 문제가 발생할 수 있음
- (물리적환경) 한정된 자원을 초과하기 위해서는 서버 자체를 변경해야 함
- 서버 한 대에 모든 부하가 집중되므로 장애가 발생한다면 장애 극복 기능이 현저히 떨어짐(서버가 복구될 때까지 중단해야 할지도?)
만약 Sacle up 이후 사용자가 또 늘어난다면, 하나의 서버에 트래픽이 집중되는 문제는 여전히 남아있습니다.
Scale out
Scale up이 수직적 확장이었다면, Scale out은 옆으로 퍼지는 느낌의 수평적 확장을 의미합니다.
"내 몸이 부족하다면 내 몸을 늘리자!"인 셈이죠. 내 몸이 Scale out 된다면 얼마나 좋을까...
계속해서 서버 확장의 문제에 부딪힌다면, 정말 말 그대로 계속해서 서버 대 수를 늘리면 되는 것이죠. 당연하게도, 확장에 제약이 없습니다.
다만 Scale up에서 언급한 데이터 정합성(데이터 불일치)에 대해 생각해봐야 합니다.
자, 조금 극단적인 예를 들어보겠습니다.
특정 웹사이트에 접속해 로그인을 한다고 해봅시다. 로드 밸런서에 의해 특정 서버를 통해 로그인을 진행하게 되겠죠.
A서버를 통해 로그인한 이후, 로드밸런서에 의해 서버가 변경된다고 가정합니다.
하지만 로그인 데이터가 동기화되지 않았거나 A 서버만 갖고 있어서 B서버가 알지 못한다면 이는 정합성에 문제가 생깁니다.
이게 로그인 데이터가 아닌 중요 정보인 금융 정보라면 어떻게 될까요?
이처럼 Scale out은 데이터 변화가 적거나 정합성을 유지하기 쉬운 경우에 적합하며, 대표적인 예시가 웹서버라고 볼 수 있습니다.
정리하자면 Scale out의 장점으로는
- Scale up에 비해 확장이 유연하다
- 부하를 분산할 수 있다
- 한 서버에 장애가 발생하더라도 다른 서버에서 서비스할 수 있으므로 가용성을 높일 수 있다
단점으로는
- 여러 서버를 관리하므로 운영 비용이 증가한다
- 데이터 일관성(정합성)을 유지해야 하므로 설계 및 관리가 복잡해진다
- 문제 발생의 잠재적 원인 또한 증가한다
- 그렇다 보니 안정성에서는 Scale up 보다 떨어진다
Scale up, Scale out 뭘 선택할까?
세계관 최강자들의 대결이다 웅장이 가슴해진다..
데이터베이스 서버, 금융거래 등은 Scale up
- 데이터 정합성 요구
- 빠르고 정확한 처리
- 잦은 갱신이 발생하는 OLTP (Online Trasaction Processing) 환경
메일, 게시판, 데이터 읽기 전용 앱, 웹 서버 등은 Scale out
- 높은 병렬성 실현이 쉬움
- 정합성 유지가 쉬움
포스팅 후 생기는 의문점
전 세계의 엄청난 트래픽을 담당하는 구글은 대체 어떤 방식을 이용하고 있을까요?
극한의 Scale out과 Scale up을 함께 하고 있는 걸까요?
참고자료
'Tech > Server' 카테고리의 다른 글
| 리더가 MSA 전환을 하자고 했다. 그리고 처참히 실패했다. (2) | 2024.10.27 |
|---|
인프런 지식공유자로 활동하고 있으며 MSA 전환이 취미입니다. 개발과 관련된 다양한 정보를 몰입감있게 전달합니다.
