사용했던 기술: spring webmvc, sns, spring batch, spring event publisher, spring sqslistener, sqs
상품 노출 ON/OFF를 할 수 있는 기능을 개발했다.
요구사항
상품 판매자들이 자신의 상품 노출을 ON/OFF 할 수 있어야 한다.
기능
- 상품 판매자들이 자신의 상품 노출 여부를 업데이트할 수 있다.
- 상품 판매자들이 자신의 상품 노출 여부 수정 이력을 볼 수 있다.
- 상품 판매자들이 자신의 상품 노출 여부를 볼 수 있다.
- 상품 판매자들의 노출 여부에 따라 실제로 노출되어야 한다.
개발 목록
- 상품 노출 여부 테이블 및 노출 여부 이력 테이블을 만든다.
- 상품 노출 여부 UPDATE API를 만든다.
- 상품 노출 여부 GET API를 만든다.
- 상품 노출 여부 이력 GET API를 만든다.
- 상품이 생성될 때마다 자동으로 노출 OFF(DEFAULT) 정보가 생성되도록 한다.
- 상품 노출 여부 정보를 외부 시스템(노출 시스템)으로 보낸다.
- 노출 시스템에서 상품 노출 여부에 따라 노출시키도록 한다.
- 모든 상품에 대해 노출 여부를 OFF(DEFAULT)로 저장하는 배치를 만든다.(마이그레이션 배치라고 하자)
개발 특이사항
배포 문제
배포 전략은 다음과 같이 정했다.
상품 배치/워커/API 배포 -> 노출 배치/워커 배포 -> 마이그레이션 배치 실행 -> 노출 API 배포로 마무리한다.
상품 배치 배포로 마이그레이션 배치 실행 환경을 만들고, 마이그레이션 배치 전에 노출 워커를 배포하여 노출 워커가 마이그레이션 배치에서 발생하는 이벤트를 수신하도록 의도했다.
마이그레이션 배치에서 기본값(OFF)로 세팅한 후, 노출 이벤트가 발생하여 노출 워커로 전달된다.
위 전략대로 배포하면서 두 가지 문제를 만났다.
(1) 상품 API를 노출 워커보다 이전에 배포하면서, 노출에 이벤트가 전달되지 않은 상품들이 일부 나타났다.
상품 API를 배포한 시간부터 시작해서 노출 워커를 배포하기까지 변경된 상품들의 변경 이벤트가 노출에 전달되지 않았던 것이다.
기존에는 상품 워커는 다른 시스템과 의존성이 없다고 생각하여 임의로 맨 앞에 배포가 되도록 했지만, 의존성이 있었다.
노출 워커가 상품 워커 이전에 배포되어야 했다.
(2) 일부 노출 시스템의 워커 배포 시간을 인지하지 못했다. 노출 시스템은 여러 개가 있다. 만약 일부 노출 시스템이 마이그레이션 배치 이후에 워커를 배포하게 되면, 그 워커는 마이그레이션 배치에서 실행한 이벤트를 수신받지 못한다.
뒤늦게 상황을 파악하고 일부 노출 시스템을 맡는 팀에 문의하여 워커 배포 시간을 알아냈다. 다행히도 이미 OFF를 DEFAULT로 하는 fallback 구조로 만들어서 마이그레이션 배치에서 발행하는 이벤트가 필요없었다.
배치 배포 누락 문제
배치 배포를 누락했다.
그래서 이전 버전 테이블로 롤백되면서(테이블 생성 배치 동작) 그 테이블에 row를 insert하는 워커가 실패했다.
배포 시간 당시 페어와 다른 팀과 소통하고 있었다. 배치 배포에 집중하지 못했다.
종료된 상품
업주가 종료된 상품의 노출 ON/OFF 데이터를 볼 때, 데이터가 없어 에러가 발생했다. 종료된 상품은 마이그레이션 배치의 대상이 아니었다. 종료된 상품의 노출 정보는 디비에 없었고, 그래서 GET으로 노출 ON/OFF를 조회할 경우 에러가 발생했다.
종료된 상품의 경우 기본 노출값을 OFF로 리턴하도록 추가 개발하여 배포했다.
더 잘하려면
- 배포 시간에는 배포에 집중한다. 다른 팀에게 문의하거나 다른 작업을 하지 않는다.
- 이벤트 수신자가 먼저 배포되어야 하는 것 아닌지 항상 검토하자. 이벤트의 수신자가 이벤트를 받아야할 준비를 해야하기 때문에, 대부분의 경우 이벤트를 수신하는 시스템이 먼저 배포되어야 한다.
- 종료된 상품의 처리를 어떻게 할지 고민하자. 기획자에게 종료된 상품도 신규 기능이 적용되는지 물어보고, 만약 적용된다면 정책을 어떻게 할지 추가로 물어본다.
