개발 일기

이전 편: https://writerroom.tistory.com/379상황 공제 가맹점이라는 테이블 특성 상, Hit 가 적을 수 밖에 없기에 여기서는 성능 개선의 여지가 적다고 판단했다.다시 로직을 보면, 아래 6개의 과정으로 분류할 수 있다. 팀과 논의 후, 슬로워 쿼리 개선 /캐시 적용 등을 이미 해보았으니, DB 부하 감소로는 최적화의 여지가 없다고 판단했다. 현재 로직이 이미 복잡하기에, 작업을 멀티 쓰레드에서 동시에 실행해서 처리 속도를 높여보기로 했다 [로직]  1)올해 국내 결제 내역 조회(Reader) *2-5는 Processor2)결제 건의 가맹점 번호를 기반으로 공제 타입 확인3)이미 연말정산 된 거래인지 중복 확인4)할인,그룹, 거래 타입 분류 등 기타 상세 내역 확인5)정산에 필..

문제 2024년 국내 결제 건을 연말 정산 하여, 국세청에 제출한다. 결제팀에서는 보통 매일 정산을 하지만, 연말정산은 한 번에 1년치를 정산하기 때문에 배치의 소요 시간이 매우 길다.이때 정산 내역을 만드는 배치의 소요 시간이 매우 길었다. 참고로 복잡한 비즈니스 로직을 수행하는 processor 에서 소모한 시간이 대부분이다. Reader/writer는 I/O 작업 위주라서 영향이 거의 없다. Read Time: 20초Process Time: 6시간 10분 Write Time: 4분긴 배치 시간은 1)지속적인 모니터링으로 작업 효율성을 떨어트리며 (오후에 실행 했을 때, 퇴근 후에도 봐야 했음) ,2) 최악의 상황에서는 다른 배치가 실행되지 못하는 위험이 있다 (현재 여러 배치가 한 EC2 인스턴..