예매, 예약 시스템에 대한 고찰 - 1

대부분의 개발자는 분산 처리와 인프라에 대해 고민할 경우가 많지 않다.

 

분산 처리의 경우 대부분 Message Queue라던지, 비동기 처리를 공부할 것이다.

 

여기서 다루고자 하는 것은 대량 접속자에 대한 처리에 대한 고민이다.

 

우리가 영화나 공연 또는 기차 예매 시스템을 개발한다고 하자.

 

예로 공연 예매 시스템을 구현한다면 어떻게 해야 할까?

 

일반적인 개발자는 모든 서버와 인프라를 하나의 시스템으로 간주한다.

 

즉, 모든 시스템은 동일한 역활을 수행하는데 있어, 특정 영역이나 구분 없이 모두 공통적인 기능을 수행하는 시스템을 구축하게 된다.

 

이러한 경우 대량 접속자 또는 처리에 취약할 수 밖에 없다.

 

특히 도메인과 많은 연관성이 있는데 그림으로는 아래와 같다.

 

 

위와 같은 예매 좌석이 있다고 하자.

각 구역별로 예매가 가능한 좌석은 차등이 있겠지만 여기서 예상할 수 있는 시나리오는 아래와 같다.

1. S 구역은 매우 혼잡할 것이다.

2. B 지역은 S에 비하여 덜 혼잡하겠지만 S에 따라 혼잡도가 높아질 것이다.

3. D 지역은 S나 B에 비하여 혼잡도가 상당히 떨어질 것이다.

 

즉, 위와 같이 모든 시스템이 하나의 도메인에 의해 S,B,D 가 모두 동일한 접속자, 부하는 받는다면 접속자의 순간 증가에 대응하지 못하고 많은 오류 상태가 발생할 것이다.

 

어떻게 대응해야 할까?

 

각 구역에 별도의 도메인을 설정해야 한다.

즉, 모든 구역은 독립적 시스템이다. 

각 구역에 독립적인 DB가 별도로 존재하고 독립적으로 운영된다면 각 구역에 문제가 되는 상태는 다른 구역에 문제를 일으키지 않게 된다.

 

S 구역은 초기에 많은 부하자 몰리고 최악의 경우 시스템 다운이 발생할 수 있다.

B, D 구역은 S 구역과는 별도의 시스템이므로 해당 영역의 부하에서 독립적으로 운영되고 부하 문제에서 자유로울 수 있다.

 

또한 위와 같은 구역으로 부하에 따라 유연하게 접근할 수 있으므로 위와 같은 방법을 고민해 볼만하다.

 

따라서, 아래와 같은 결론에 도달할 수 있다.

 

1. 메인 페이지에서 구역별로 접근할 수 있도록 한다.

2. 각 구역은 별도의 도메인, 즉, 각 구역의 시스템에 접근하도록 한다.

3. DB는 각 구역별 시스템에 있으므로 문제 상황에 대해 구역별 접근이 가능하므로 신속하게 대응할 수 있다.

 

또한, 예매 시스템은 결국 마지막 결과에 대한 데이터 만이 중요하므로 RDB보다는 높은 INSERT를 견딜 수 있는 NOSQL을 사용해도 무방하다.

 

또한, 예매 시스템을 구성하는 각종 디스플레이 정보는 CACHE형으로 가능하므로 적극적으로 CACHE를 사용하는 것이 좋다.