<aside> 💡 2024/04/28 → 2024/05/07
</aside>
저는 금융,핀테크 도메인에서 일하고 싶습니다.
저는 기술을 사용할 때 기본적인 원리와 주의 사항을 파악한 후에 사용하며, 성능 테스트를 통해 발생한 문제들을 분석하고 해결하면서 더 깊게 학습하는 방식으로 지식을 습득합니다.
회사에서 Stored Procedure로 이루어진 레거시 코드를 Spring Boot와 JPA로 개편하는 프로젝트에 참여한 적이 있습니다. JPA를 적용하기 위해 해당 프로젝트에 참여하는 사원들과 약 한 달간 사내 스터디를 수행했고, 모두가 원리를 파악한 후에 프로젝트에 적용하기 시작했습니다.
이를 위해 아키텍처를 고민해야 했고, 유지보수가 쉬운 방향으로 프로젝트를 구성하기 위해 헥사고날 아키텍처를 공부하여 포트-어댑터 개념을 차용해 아키텍처를 구성했습니다. 이에 더해 단위 테스트를 작성하며 더 좋은 아키텍처를 만들었습니다. 해당 프로젝트는 RDB 뿐만 아니라 MongoDB도 사용해야 했는데, 간단한 기능만 필요했기에 간단한 원리와 필요한 내용만 숙지하여 프로젝트에 적용하였습니다.
프로젝트를 완성한 후, 구현한 애플리케이션의 안정성을 테스트하고자 부하 테스트를 수행했는데, 결과가 처참했습니다. TPS와 Latency가 매우 나빴고, 커넥션 풀에 많은 스레드가 대기 중이거나 심지어 Out-Of-Memory(OOM)까지 발생했습니다.
이러한 문제들을 분석하고 하나씩 개선하면서 많은 것을 배웠습니다. 특히 OOM을 해결하기 위해 힙 덤프를 떠본 것이 기억에 남습니다. 로컬 캐시로 인해 MongoDocument가 과도하게 캐싱 되어 OOM이 발생했습니다. 캐시 만료 후 요청 시 재생성 정책 때문에 중복 쓰기가 발생하며 너무 많은 것들이 캐싱 되기 시작했습니다. 이를 @CachePut을 이용해 적정 시간마다 덮어쓰는 방법으로 해결했습니다. 또한, 로컬 캐시를 사용할 때는 객체 크기를 계산하고 평소 메모리 사용량을 고려해 적절한 힙 크기를 설정해야 함을 깨달았습니다.