지난번 이벤트 스토밍 설계에 이어 이번엔 이 설계를 어떻게 기술적으로 구현할지에 대한 고민을 해보려 한다.
서비스는 회원, 공연, 대기, 결제 도메인으로 나뉘는데 가장 중요하고 트래픽이 많이 발생할 것으로 보이는 공연/대기/결제 도메인 먼저 설계하려한다.
이 중에서도 결제는 외부 시스템 연동 예정이므로 공연, 대기 도메인을 먼저 설계하겠다.
설계는 우선 가능한 많은 트래픽을 받을 수 있다고 가정한 상황에서 진행하였다.
설계 시 다음과 같은 기술적 고려사항들과 그에 따른 방법이 도출되었다.
- 대기 서버와 예약 서버 Scale out을 어떤 기준과 방법으로 해야할지?
- 대기 서버는 단순히 예약 서버로 넘겨줄 큐에 넣어주는 역할만 하는 방식으로 구상해보자
- 예약 풀 자리가 났을때 대기 서버로의 분배는 어떻게 할지?
- 1번 방식으로 하면 분배가 필요없어짐
- 예약 풀이 다 찼다의 기준은 어떻게 할지?
- 기준은 여러가지가 될 수 있으나 1차적으로 시간당 100~200명 같은 기본 정책으로 접근해보자
- 대기 순번은 어떻게 제공할지?
- 예약이 완료된 건마다 예약 서버에서 큐를 감소시킴.
- 서비스 특성 상 1의 자리까지 정확한 순번 제공은 필요하지 않으니, 큐의 사이즈를 이용해 대기 순번으로 제공해줘도 될
- 웹소켓을 사용하지 않고 구현하는 방법도 찾아보자(풀링 등)
- 공연 좌석 예약 특성 상 많은 Write가 동시에 발생할텐데 어떻게 처리할건지?
- DB 샤딩 측면으로 접근해 방법을 찾아보자
이렇게 결정이 되었을 때, 대기 서버는 각 유저별 대기 순번과 예약 서버에 자리가 났는지 여부를 read해오는 역할, 그리고 예약 서버에 자리가 나면 대기 인원을 감소시키고 예약 인원을 추가하는 command역할로 분리가 된다.
이 두 역할은 변경 빈도(write가 훨씬 잦은 빈도)와 서로 다른 성능 향상 방법(read : 캐싱, write : 샤딩 등)을 가졌다고 판단하였고, 이에 적용할 수 있는 CQRS 모델에 대해 다음 편에서 알아보려고 한다.
매일 발전