회사에서 담당하는 티켓 한 티켓 서비스의 QA(품질 보증) 과정에서 중복 등록 이슈가 보고되었습니다. 사용자가 등록 버튼을 연속으로 빠르게 클릭할 경우 티켓이 중복으로 등록되는 현상입니다. 본 글은 이 문제를 접하며 문제를 정의하고 해결하는 과정을 기록하고 사내에 공유한 글을 재편집한 글입니다. 여러 가지 고민과 결론, 그리고 서버 개발을 하며 만나는 멱등성과 동시성에 있어서 추가로 생각해볼 거리들을 다뤘습니다. 업무의 특성상 구체적인 용어나 코드는 컨셉으로 대체하였습니다.
티켓 서비스의 QA 과정 중 발견된 중복 등록 이슈에 대해 다룹니다. 사용자가 등록 버튼을 연속으로 빠르게 클릭할 때 발생하는 중복 등록 현상에 대한 해결 방안 모색 과정을 기술합니다. 어플리케이션 수준의 검증과 한계를 먼저 다루고 실질적인 해결책으로 데이터베이스 수준의 제약 조건 설정과 분산 환경의 최종 일관성 관점에서의 접근을 제시합니다.
티켓 서비스의 QA 과정에서 중복 등록 이슈가 보고되었습니다. 이 문제는 사용자가 등록 버튼을 연속으로 클릭할 경우, 현장정기권이 중복 등록되는 현상입니다. 사용자가 웹 페이지에서 등록 팝업을 열고 필수 값을 설정한 후, 등록 버튼을 클릭 할 때 세 번 이상 연속해서 클릭하면 티켓이 중복으로 등록됩니다. 즉, 동일한 티켓이 여러 번 등록되고 노출되는 상황입니다.
검증을 한다 ! 😭
먼저 현재 플로우는 다음과 같습니다.
클라이언트요청 -> LB -> 게이트웨이 -> 오케스트레이션 -> 도메인 서비스 - DB
중앙 집중식 오케스트레이션 서비스를 구현한 사가 패턴의 아키텍처를 구성하고 있습니다. 이 MSA 아키텍처에서 도메인 서비스는 응집력을 갖춘 컴포넌트이며 최소화된 기능 단위로 다수 존재하는 서비스입니다. 오케스트레이션은 비즈니스 규칙과 제약에 따라 이들을 조합하거나 호출하여 트랜잭션을 실행하거나 전체적인 비즈니스 프로세스를 달성합니다.
따라서 비즈니스를 관장하는 컴포넌트는 오케스트레이션입니다. 오케스트레이션은 클라이언트의 요청을 받고 비즈니스 규칙과 제약에 따라 검증 로직을 생성하고 도메인 서비스에게 요청합니다. 오케스트레이션과 도메인은 신뢰 기반의 프로세스입니다.
운영상황에서 서버 인스턴스는 4중화되어 있는 상황입니다.