최근 교내 정보 큐레이션 서비스를 개발하며 모놀리식 멀티 모듈 아키텍처를 적용하여 백엔드를 구현하고 있다. 모듈별 프로퍼티는 각 모듈 내 프로퍼티 파일을 두고 필요한 값을 작성하여 관리한다. 모놀리식 단일 모듈에서의 application.yml, application-dev.yml, application-production.yml을 사용하던 방식을 멀티 모듈에서는 어떻게 적용시키는 가에 관한 의문이 들었다. 이번 프로젝트를 진행하며 멀티 모듈 구조와 설정에 대해 깊이 학습을 진행하며 알아본 프로퍼티 설정 방법들과 주의 사항을 공유하고자 한다.
모의주식 투자 웹 서비스 '무주시'를 리팩토링하며 주식 종목 검색 기능을 개선하기로 결정하였다. MongoDB의 정규식 매칭 기능을 활용하여 결과를 조회하고, 검색 빈도로 정렬하여 반환하던 구조에서 MySQL로 데이터를 이관하고 Lucene을 통하여 자체 인덱스를 구축하여 검색 경험을 개선하였다. 최종적으로 검색 결과를 우선 순위대로 정렬하기 위하여 최종 점수를 계산할 때, 검색어와 결과 매칭 점수와 검색 빈도(인기도)를 기반으로 최종 점수를 도출하는 과정과 그 과정에서 Saturation 함수를 사용한 경험을 정리하고자 한다.
모의 주식 투자 웹 서비스 '무주시' 운영 환경의 에러 모니터링과 장애 대응 속도·경험 개선을 위해 Sentry를 도입하였다. Sentry 도입 후 빌드 과정에서 QueryDSL의 Q 클래스와 충돌이 일어나며 빌드가 실패하였다. 해당 문제를 해내가며 QueryDSL 생성 방식과 충돌 원인 등을 알아보았다.
모의 주식 투자 서비스 '무주시'를 리팩토링하며 가장 먼저 한국투자증권 실시간 체결가 웹소켓 세션 및 구독 관리 구조를 되돌아보았다. 이전에도 리팩토링을 진행하였지만, 그 과정에서도 구조에 대한 몇 가지 의문이 남아있었다. 웹소켓 세션과 구독 종목 관리 책임이 혼재되어 있어 계층간 경계가 모호하다는 느낌을 받았었다. 특히, 도메인 주도 설계와 헥사고날 아키텍처의 Port&Adapter를 통해 외부 인프라와 계층간 결합도를 분리하는 중요성에 대한 지식을 얻은 뒤 기존 리팩토링 구조에 대한 아쉬움이 크게 부각되었다. 이번 포스팅에서는 기존 리팩토링 구조에서 위와 같은 아쉬웠던 문제를 개선해 피드백한 과정을 정리하고자 한다.
대기열 시스템을 학습하며, 대기열을 통과한 사용자를 참여열로 이동시킬 때 "적절한 배치 사이즈와 스케줄링 주기는 얼마인가?"라는 의문이 들었다. 배치 사이즈가 너무 크면 대기열의 의미가 퇴색되고, 너무 작으면 서버 자원이 낭비되고 사용자 대기 시간이 길어져 사용자 경험이 떨어진다. 이 글에서는 실제 테스트와 계산을 통해 적정한 배치 사이즈를 찾아본 과정을 공유하고자 한다.