Today I Learned ...
오늘은 Ticketing Service 팀프로젝트의 기능 개발을 얼추 마무리했다!
🖥️ Ticketing Service 팀프로젝트 #5
오늘 드디어 이번 프로젝트의 기능 개발을 얼추 마무리했다!
이제 앞으로는 리펙토링을 조금만 하면 끝난다!
오늘 나는 어제 못다한 스케줄러 기능 구현을 이어갔다.
어제 스케줄러와 함께 레디스를 사용해서 실제 예매가 이루어지고 있는 시간에만 스케줄러가 동작하도록 로직을 구현했는데, 오늘 그 모든 로직들을 다 삭제했다.
성공했다면 그대로 유지했겠지만, 로직을 구현하다보니 레디스에 마지막 생성 일시를 새롭게 덮어쓰는 것으로 위 내용을 해결할 수 없었다.
10시 00분에 생성된 예매에 대해 스케줄러는 10시 10분에 기능을 실행해야 하는데, 이 사이에 10시 09분에 예매가 생성되면 레디스의 값이 덮어씌워져 스케줄러는 10시 19분에 기능을 실행하게 된다.
이걸 해결하기 위해서는 스프링 전체에서 싱글톤으로 관리되는 리스트를 만들고,
예매가 생성되면 여기에 예매 정보를 추가하고, 예매가 취소되거나 결제된다면 리스트에서 해당 내용을 삭제하도록 한 뒤,
스케줄러가 이 리스트의 내용을 읽고 해당 기능을 실행하도록 구현하면 된다.
해결책을 찾기는 했지만, 이 기능이 우리 프로젝트의 핵심 기능이 아니기 때문에, 이렇게 수정하지는 않기로 했다.
대신 수정해야 할 예매의 조회와 수정 로직을 나누어서 조회된 결과가 없다면 아무런 동작도 하지 않고, 조회된 결과가 있다면 그 결과들에 대해 예매 취소와 자리 취소를 진행했다.
어제 또 모든 기능을 한번에 해결하지만 인덱스를 사용하지 못하는 1개의 쿼리를 사용하는 로직과 인덱스를 사용하지만 5개의 쿼리를 사용하는 로직 사이에 어떤 것을 선택해야 할지 고민했다.
사실 두 내용 다 부하 테스트를 진행해보고 싶었는데, DB에 대한 부하테스트를 어떻게 진행해야할지 모르겠어서 포기하였다.
우리 프로젝트에서 한 공연당 좌석이 2,500건 정도 생성되는데, 공연이 10개만 생성되어도 좌석 수가 25,000건이 되어버린다.
이런 상황에서 인덱스를 사용하지 않고 좌석을 검색하게 되면 여기에서 병목 현상이 발생할 것이다.
그래서 결국은 1개의 쿼리를 사용하는 로직 대신, 5개의 쿼리를 사용하지만 인덱스를 사용하는 로직을 사용하기로 결정하였다.
이렇게 스케줄러에 대한 내용을 끝으로 내가 맡은 기능 개발은 모두 마무리 되었다.
사실 어제까지가 기능 개발 완료 목표일이었고, 오늘과 내일이 버퍼 기간이었다.
지난 팀 프로젝트를 하면서는 사전에 버퍼 기간을 생각해두지 않았어서 진행하던 기능 개발을 마무리하지 못하고 종료했었다.
지난 프로젝트 때 이 부분이 가장 아쉬웠었는데, 이번 프로젝트 때 버퍼 기간의 효능을 제대로 맛볼 수 있었다.
앞으로는 어떤 프로젝트를 진행하든 버퍼 기간을 꼭 미리 설정해두고 진행해야겠다.
이제 내일부터는 발표 자료를 준비하고, 다른 사람들이 진행한 개발 내용들을 천천히 읽어볼 예정이다.
내일은 전체 프로젝트에 대한 내용을 정리해보아야겠다.
우리 팀이 작성한 코드는 깃허브를 통해 업로드해두었다.
GitHub 보러가기
🙃 오늘의 느낀점
팀 프로젝트를 진행하면서 개인 시간이 없어서 여러 궁금증들을 모아두기만 했는데, 내일부터는 개인 시간이 조금 생길 것 같다.
내일은 정말 스프링 시큐리티를 마스터 해봐야겠다..
