축구팀 관리 프로젝트 16일차 - 대용량 트래픽을 처리하는 두가지 방법

축구팀 관리 프로젝트 16일차 - 대용량 트래픽을 처리하는 두가지 방법

 

 

축구팀 관리 프로젝트를 진행한지도 2주가 지나고 있습니다. 이동안 대략적인 API 설계와 화면이 나타나고 있습니다. 다음주 중에는 최대한 만들어진 화면을 연결하고 서비스가 정상동작하는지 테스트하는데 많은 시간을 쓸 것 같습니다.  프로젝트의 서비스 기능은 어느정도 윤곽을 잡고 있지만 한가지 중요한 점을 놓치고 있었습니다. 바로 프로젝트의 '챌린지'적인 요소가 빠졌다는 점입니다. 

 

 

개인별 기록이 저장 안된 이유

 

축구팀 관리 프로젝트 15일차 - 경기 후 기록 등록하는 로직 수정

전날 작업한 기록입니다

 

오늘 작업한 내용은 전날 작성한 경기 후 팀별, 선수별 기록 저장하는 로직을 수정했습니다. 전날 힘겹게 코드를 작성하고 깃허브에 올리니 팀원이 확인하다가 기록 저장이 안된다는 소식을 듣게 되었습니다. 코드를 살펴보니 첫번째 팀 기록 하는 부분은 정상적으로 동작했으나 선수별 기록 저장시 오류가 있었습니다. 

 

더 상세히 설명하자면 선수별 기록 저장시 경기를 치른 두 팀이 각각 자신의 선수 기록을 저장하게 됩니다. 여기서 첫번째로 입력한 팀은 선수별 기록이 문제없이 저장되지만 마지막(두번째로) 저장하는 팀의 경우에 저장이 안되는 오류가 있었습니다.

 

 

저장이 안된 이유는 저장 시 두번째로 저장한 팀을 찾는 조회 메서드에서 조회 조건이 잘 못 되어 있었기 때문입니다. 그 조회 메서드에서 조회가 되어 조회된 정보로 다음 로직을 진행해야 하는데, 조회 후 undefined가 뜨니까 다음 로직을 수행하지 못하였습니다.

 

이 저장 진행시 저장하는 테이블이 두 곳이나 되는데 다행히도 이 저장 로직에 트랜잭션을 걸어둬서 오류가 나타나자마자 앞서진행한 결과들을 모두 rollback 할 수 있었습니다. 그래서 저장 처리가 안되었던 것이었습니다.

 

 

이 조회조건을 수정하고 다시 테스트해보니 정상적으로 저장되는 것을 확인할 수 있었습니다.  조회조건 하나 바꾸면 되는 오류 찾으려고 30여분을 고민하고 있었습니다.

 

 

대용량 데이터 처리를 어떻게 경험할 것인가

 

축구팀 관리 프로젝트의 서비스적인 부분은 어느정도 윤곽이 잡히고 있습니다. 필수 API도 작성하였고, 화면도 어느정도 구현중에 있습니다. 이제 여기서 더 심화적으로 넘어가려 하면 이 '대용량 데이터 처리'를 경험하지 않을 수 없습니다. 백엔드 개발을 한다면 이 영역은 꼭 경험해봐야 현업에서도 많이 활용될 것이기 때문입니다. 

 

 

우선 사전조사부터 시작했습니다. 

 

대규모 트래픽 처리

 

이 글 보면서 굉장히 공감되는 부분이 많았습니다. 특히 이 문구,

 

 

왜 그렇게 다들 대규모 트래픽 거리는가

 

필자 역시도 궁금했습니다. 왜 그렇게 대규모 트래픽을 강조하는 지에 대해서.

이 글에서 그 이유를 정리할 수 있었습니다. 서비스 사용자가 대거 진입시 그 모든 요청을 수용하지 못하면 페이지는 다운 될 수 밖에 없습니다. 이렇듯 순간적으로 많은 요청자가 서버에 몰릴 때 어떻게 대응할 것인가에 대한 고민은 실제 현업에서 자주하는 고민이고, 이는 곧 기업의 '수익'과도 밀접하게 연결된 요소라고 이해할 수 있었습니다. 많은 사용자의 요청을 감당하지 못한다면 사용자는 이 서비스를 이용하려 하지 않을 테니까요.

 

 

서버가 터지는 이유에 대해서도 이 글에서 쉽게 이해할 수 있었습니다. 쉽게 말하면 서버가 지니고 있는 CPU, 메모리, 저장장치가 감당할 수 있는 처리량이 있는데 이것을 넘어서는 요청이 한꺼번에 들어왔기 때문에 서버가 터지는 것이었습니다. 

 

서버 안 터지게 하는 방법

 

그러면 어떻게 하면 서버가 안터질까.

위 글에서는 두가지 방법을 알려주었습니다. 

 

1. scale-out 

scale-out은 쉽게 말해 서버를 물리적으로 늘리는 것을 말합니다. 장비를 추가해서 확장하는 것입니다. 업무를 1명이서 맡을 때보다 2명, 두명 보다는 3명일때 처리하는 속도가 빨라지는 것과 같은 이치입니다. 서버를 추가로 확장한다고 해서 '수평 스케일링(horizontal scaling)이라고 합니다.

 

이렇게하면 처리할 수 있는 데이터 용량을 늘릴 수 있을 뿐만 아니라 기존 서버의 부하를 분담하여 성능 향상의 효과를 기대할 수 있게 됩니다.

 

 

여기서 고려해야 할 점은 '업무의 배분'입니다. 모든 요청이 동일한 처리시간을 요구하지 않기 때문에 요청에 따라 시간이 많이 요구되는게 있고, 상대적으로 적은 시간이 드는 요청이 생기기 마련입니다. 이 때, 특정 서버에 장시간 처리가 필요한 요청이 몰리게 되면, 그 서버는 결국 터지게 될 것이고, 해당 서버로 요청을 보낸 사용자는 페이지 접속 오류를 경험할 수 밖에 없습니다. 

 

이에 대한 대안으로는 로드밸런싱이 있습니다.

 

로드 밸런싱이란 무엇인가요? - 로드 밸런싱 알고리즘 설명 - AWS

 

위 사이트에 상세하게 로드밸런싱에 대해 설명하겠지만 간략하게 설명하면 리소스 전체에 해당하는 네트워크 트래픽을 균등하게 배포하는 방법을 말합니다. 이를 통해 서버의 들어오는 요청들을 균등하게 분배하여 특정 서버에만 과부화 되는 것을 막을 수 있습니다.

 

2. Scale-up

서버를 안 터지하는 두번째 방법은 scale-up 즉, 기존 서버의 사양을 높이는 것을 말합니다. 예를 들어 하드웨어 성능이나 용량 증강을 목적으로 하나의 서버에 디스크를 추가하거나 CPU, 메모리를 업그레이드 하는 과정을 말합니다.  하나의 서버의 능력을 향상시킨다 하여 '수직 스케일링(vertical scaling)'이라고도 합니다.

 

 

Scale-up과 Scale-out 비교

다음은 scale-up과 scale-out을 비교하여 정리한 표입니다.

 

구분	스케일 업(Scale-up)	스케일 아웃(Scale-out)
정의	기존 서버의 하드웨어 성능을 강화하는 방식 (예: CPU, RAM 추가)	여러 서버를 네트워크로 연결하여 처리 능력을 확장하는 방식
장점	- 관리가 비교적 간단함 - 소프트웨어 호환성 문제가 적음	- 확장성이 높음 - 서버 한 대의 장애가 전체 시스템에 미치는 영향이 적음
단점	- 확장에 한계가 있음 (하드웨어의 물리적 한계) - 비용이 높을 수 있음	- 초기 설정과 관리가 복잡할 수 있음 - 소프트웨어가 분산 처리를 지원해야 함
적용 사례	- 데이터베이스 서버 - 고성능 컴퓨팅 작업	- 웹 서버 - 클라우드 스토리지 시스템

PC버전에 최적화 되어 있습니다

 

 

끝으로

 

인프라 확장 방법으로 스케일 업과 스케일 아웃을 살펴보았습니다.

글을 읽어보면 스케일 아웃이 스케일 업보다 우수해 보일 수도 있지만, 모든 상황에서 무조건적으로 우월하다고 말하기는 어렵습니다. 어플리케이션의 유형이나 스토리지의 용도 등에 따라 적절한 선택이 달라지기 때문입니다.

 

예를 들어, 빅데이터의 데이터 마이닝이나 검색엔진 데이터 분석과 같이 OLAP(Online Analytical Processing) 환경에서는 대량의 데이터 처리와 복잡한 쿼리가 필수적입니다. 이러한 환경에서는 여러 서버에 걸쳐 작업 부하를 분산시키는 스케일 아웃 구성이 더 효율적일 수 있습니다.

 

반면, 온라인 금융거래와 같은 OLTP(Online Transaction Processing) 환경에서는 빠르고 정확한 처리가 필요합니다. 이런 경우, 고성능의 단일 시스템에서 작업을 처리하는 스케일 업 방식이 더 적합할 수 있습니다.

 

따라서 서버 확장 방식을 결정할 때는 단순히 기술적인 장단점만을 고려하는 것이 아니라, 서비스의 특성과 요구사항을 면밀히 분석하여 최적의 방법을 선택해야 합니다. 이처럼 스케일 업과 스케일 아웃은 각각의 상황에 맞게 적절히 활용되어야 하며, 이를 통해 서비스의 안정성과 효율성을 극대화할 수 있습니다.

 

참고자료

로드 밸런싱이란 무엇인가요? - 로드 밸런싱 알고리즘 설명 - AWS

Scale-up과 Scale-out에 대해 알아보자!

 

대규모 트래픽 처리