우리 호텔의 요금 정책 중 하나는 고객들에게 미래 3개월치의 요금 정보를 보여주는 것이다. 이를 위해선 ‘현재 날짜 + 3개월’ 날짜의 요금을 매일 요금 테이블에 생성해줘야 한다.
데이터의 크기를 계산해보면, 5000개의 호텔 * 5개 타입 = 2.5만개이다. 대규모 데이터를 한번에 처리해야 하기에, 몇가지 고민을 하게 됐다.
현재 모든 서비스는 도메인 별로 마이크로 서비스로 설계 되어있다.
요금 서비스의 요금 테이블에는 모든 호텔의 객실 타입 별 요금 데이터가 저장된다. 그런데 각 호텔의 객실 타입들은 호텔 서비스의 호텔 테이블에 존재한다.
따라서 새로운 데이터를 매일 생성해줄 때마다 호텔 서비스에 API를 호출해야 한다. 전체 데이터를 가져오는 작업은 DB에도 부하가 크고, 두 서비스 간의 장애 요소를 증가시키게 된다.
상황
이러한 조건 때문에, 호텔 서비스의 호텔 데이터를 요금 서비스에서도 ‘조회 only’ 로 갖고있어도 된다고 결론을 지었다.
따라서, 요금 서비스는 호텔 DB에서 필요한 데이터만 갖고있게 됐고, 조회 시에 호텔 서비스에 API를 호출하지 않아도 됐다.
요금 서비스의 조회용 호텔 DB
매일 데이터를 생성해줘야 하는 조건을 고민했다. 서비스의 트래픽이 높지 않은 시간대에 스케줄된 로직을 돌리면 된다고 생각을 했고, 간단하게 스케줄링으로 해결을 했다.