저는 티켓팅 판매 서비스 프로젝트를 만들면서 티켓 판매가 시작될 때 유저들이 동시에 많은 접속을 하여 서버 처리량의 한계가 올 경우 어떻게 해야 할지 고민을 하고 있습니다. 그러다가 서버의 확장 방법이 Scale Up과 Scale Out이 있다는 걸 알게 되었습니다. 둘 다 장단점이 있어서 먼저 간략한 소개를 해드리겠습니다.
Scale Up
Scale Up 이란 CPU나 RAM 등 장비의 성능을 향상시키는 것입니다. 성능을 향상시킨 후에는 관리가 쉽고 많은 지식을 필요로 하지 않는 장점이 있습니다. 그리고 서버 한대로 운영하기 때문에 빈번한 데이터 작업을 쉽게 해결할 수 있습니다. 하지만 더 많은 사람들이 접속할 시 서버 확장이 언젠가 한계가 올 수 있다는 단점과 서버 하나로 운영하기 때문에 서버 장애가 발생할 시 전체적으로 영향을 받아 가용성이 떨어집니다.
Scale Out
Scale Out은 서버를 여러 대 추가하여 성능을 향상시키는 것을 말합니다. 계속해서 유저가 증가하여도 서버를 더 추가하면 되기 때문에 성능의 한계가 없고 서버 한 대가 장애가 발생했다고 해도 다른 서버로 유지하면 되기 때문에 전체적으로 장애가 발생하지 않아 가용성이 증가합니다. 뿐만 아니라 아래 사진처럼 Scale Up보다 Scale Out이 성능 향상 대비 비용이 더 저렴합니다. 하지만 여러 서버를 관리해야 되기 때문에 관리가 어렵고 세션 불일치 현상이 발생할 수 있습니다.
저는 사이드 프로젝트이지만 실제로 운영한다면 어떻게 해야 될지 많은 생각을 해본 결과 Scale Out으로 확장을 하기로 결정 했습니다. 점점 더 티켓팅 판매 서비스가 유명해져서 확장의 한계가 있다는 건 있을 수 없는 일이어야 하고 서버가 전면 장애가 발생한다면 그만큼의 매출이 떨어지고 손해가 클 것이라고 생각했습니다. 세션이나 DB 등 정합성 문제가 있지만 어떻게 하면 최대한 해결할 수 있을지 다음 블로그에 작성해 보겠습니다.
사이드 프로젝트
github.com/f-lab-edu/show-ticketing-service
참고
한국데이터산업진흥원
데이터 기술 동향 < 정보마당 - 한국데이터산업진흥원
고성능 스토리지 기반의 DB통합 MySQL 컨솔리데이션(Consolidation) 작게 시작했던 서비스가 점점 커져 DB용량이 한계에 다다르면 수평으로 부하를 분산하는 스케일아웃(Scale out) 방식으로 확장할 것인
www.kdata.or.kr
www.avantra.com/blog/scaling-up-vs-scaling-out-sap-on-the-public-cloud
Scaling Up vs Scaling Out: SAP on the Public Cloud
There are two types of dynamic scaling in the SAP public cloud area, scaling up/down and scaling in/out. They each come with their own set of pros & cons and it can be a bit daunting architecting this all out, so here’s the simple breakdown of what each
www.avantra.com
www.factioninc.com/blog/hybrid-multi-cloud/scale-up-vs-scale-out-scale-out-nas-meets-multi-cloud/
Scale-Up vs. Scale Out: Scale Out NAS Meets Multi-Cloud
Although scaling up has worked well in the past, it’s often ill-equipped for the demands of today’s data. Let's dive in.
www.factioninc.com