티켓팅 서버 구상해보기!

2 분 소요

서론

취업을 준비하면서 신입 개발자로써의 필요 역량은 어떤 것일까? 에 대한 고민을 자주 했었다.

탄탄한 CS 지식도 있을 것이고, 프로젝트 경험도 있을 것이고, 여러가지가 있겠지만 나는 항상 ‘대용량 처리’에 대해 고민해보았는지가 중요하다는 생각이 들었다.

결국 엔터프라이즈급 서비스에서 백엔드 개발자가 가장 중요시 해야할 일은, 얼마나 안정적으로 끊임 없이 서비스를 제공하느냐 일 것 이다. 요즘 대부분의 회사는 서버가 터지면 그 시간동안 아예 아무것도 못하는 경우가 많기 때문에, 그 트래픽이 얼마나 많건 적던간에 비즈니스를 유지하기 위해 항상 서버는 돌아야한다.

그렇기 위해서는 마케팅적으로 꼭 필요한 이벤트라던가, 비즈니스 특성 상 사람들이 유독 몰리는 시간대라던지 등등의 돌발 상황에 대한 대처 능력이 결국 백엔드 개발자로써의 능력일 것 이다.

하지만 신입의 가장 문제점은 이런 환경을 접하기 어렵다는 것 이다. 프로젝트를 진행한다고해도 유저가 많지 않고, 운좋게 뭐 어디서 인턴을 한다고 쳐도 신입에게 그런 대용량 처리를 맡길 회사는 없다.

결국 그럼 기업에서 요구하는 것은 일정 부분 ‘신입이 대용량 트래픽 경험하기 어려운 것은 알겠어, 그럼 대용량 처리에 대해서 고민이라도 해봤니?’와 비슷할 것 같은데, 그래서 가상의 티켓팅 서비스 프로젝트를 진행해보며 수많은 트래픽을 처리해보기로 했다.

nGrinder vs JMeter

찾아보니 성능 부하 툴이 여러개 있었는데, 대략 아래의 조건을 기준으로 몇개를 찾았다.

  1. 무료일것…
  2. 레퍼런스가 많을 것
  3. 실제로 현업에서도 쓰는 툴일 것

그래서 이 기준에 부합하는건 nGrinder와 JMeter 정도가 있었다.

그래서 두가지를 간단히 비교해보았다.

nGrinder

네이버에서 The Frinder라는 오픈소스를 기반으로 만든 오픈소스 프로젝트다.

스크립트를 작성할때 Jython과 Groovy 두가지 중 하나를 선택 할 수 있다고 하는데, Groovy의 경우 Junit 기반으로 되어있어 테스트 스크립트를 관리하기 편하다고 한다.

JMeter

JMeter는 아파치에서 만든 순수 자바코드로만 이루어진 성능 테스팅 도구라고 한다. 장점으로는 플러그인이 굉장히 많고 젠킨스와 연동이 가능하다고 한다. 다만 다양한 기능들이 많아 조금 무겁다고 한다.

두가지 모두 간단하게 어떤 툴인지만 알아보고, 적절한 레퍼런스가 있늕지를 더 중점으로 봤는데, nGrinder가 아무래도 네이버에서 제작한 툴이라 그런지 국내 기업에서 사용하는 경우도 많다고 하고, 레퍼런스도 더 많았다.

그리고 결정적으로 러닝커브가 JMeter에 비해서 nGrinder가 쉽다고 한다!

실제 서비스라면 툴 자체의 성능이나 편의성도 고민을 많이 해야겠지만, 나는 지속적인 테스트를 통한 실제 비즈니스를 하는 게 아니기 때문에, 비교적 러닝 커브가 낮은 nGrinder를 선택하고 그 시간에 서버의 성능을 높이는데에 더 시간을 사용해보기로 했다.

필요한 기능 구상하기

사실 이 부분에 있어서 고민이 많이 됐는데, 비즈니스 로직의 복잡성을 최대한 간단히 하고 단순 요청을 빠르게 처리하는데에 집중해보는 것에 집중하는 게 좋을지, 그래도 어느정도의 복잡성을 가진 비즈니스로직을 작성하고 이를 기반으로 테스트를 해보는게 나을지에 대한 고민이 됐다.

대략 생각해본 정말 정말 필수 기능은 아래와 같다.

  1. 로그인하기
  2. 현재 좌석 정보 불러오기
  3. 티켓 예매 하기

여기서 고민되는건 실제 웹사이트처럼 유저 회원가입과 로그인 및 실제 좌석들과 티켓 정보도 실제와 같이 구현할지, 정말 단순화해서 처리량을 늘리는데에만 집중할지 였는데, 단순하게 진행해본 뒤, 복잡하지 않은 비즈니스 로직에서의 부하 처리 난이도가 생각보다 낮다면 그때 비즈니스 로직을 추가해주는게 낫겠다는 생각이 들었다.

아키텍처 구상하기

앞서 말했듯이 비즈니스로직 자체는 단순하게 가겠지만, 서버 환경만큼은 실제와 얼추 비슷하게 진행해보고 싶었다.

현재 구상하는건 가장 저렴한 서버를 임대하고, 이 서버에 DB도커와 웹어플리케이션 도커를 배포한 상태로 부하테스트를 진행해보도록 할것이다. 가능하다면 도커를 통한 분산 부하 처리도 경험해보고 싶다.

아마 가장 저렴한 서버인만큼 처리량이 높지는 않을 것 같아보이지만, 그래도 그 적은 처리량을 최대한 많게, 빠르게 하는걸 목표로 해보려 한다!

마무리

이걸 구상하며 가장 중요한건 서버를 먼저 결제하는거라는 생각이 들었다…

구상만 하고 끝나기전에 먼저 서버를 결제 해버리면, 내일의 나는 어쩔 수 없이 이 프로젝트를 진행하겠지.

그래서 이 글의 마무리와 함께 서버를 결제하며 이 글을 마친다!

카테고리:

업데이트:

댓글남기기