꾸준하게, 차근차근

(@DynamicUpdate, @Converter, dirty checking, equals/hashCode, Hibernate deep copy 내부 동작까지) 바쁜 주말을 보내고, 피로와 싸우며 출근을 짠! 했는데 출근과 동시에 이슈가 발생했다. 😱덕분에 피로고 나발이고 활기찬 오전을 보냈다... 1. 문제 상황: "조회만 했는데 update 쿼리가 나온다?"금요일 운영에 반영한 Search API가 update 쿼리를 대량으로 쏟아내는 현상이 발생했다... 🤯단순히 JPA로 엔티티를 여러 번 조회했을 뿐인데, 데이터베이스에 update 쿼리가 조회 횟수만큼 쏟아졌다.코드 상황은 이랬다:엔티티 클래스에 @DynamicUpdate 어노테이션이 선언되어 있었다.필드 중 하나는 @Converter를 적..

회사 업무에 적응하기도 바쁘지만, 바쁘다고 자기계발에 소홀하면 안되지!그 덕에 점점 일만 벌리고 있는 것 같지만 🤣🤣 친한 동생과 내년 상반기를 목표로 토이 프로젝트를 진행하기로 했고, 퇴근 후 틈틈이 개발해서 테스트 코드 작성 단계까지 도달했다. (나는 TDD가 잘 안돼 🤣)하지만 뭐든 쉽게 넘어가는 법이 없는게 세상의 이치 🧐 는 테스트 코드를 실행하면서 발생했다. 1. 문제 상황테스트 코드를 작성하고 실행하는데 아래와 같은 에러 로그가 찍히면서 테스트 코드가 정상 동작하지 않는 것! 자, 어디서 또 삽질하는 소리가 들리지 않는가... 2. 해결 방법2.1. IntelliJ 설정 수정GPT에게 물어보고(비록 헛소리로 하나도 도움이 되지 않았음 🤬), 구글링도 해보고 해서 찾은 첫번째 방법이 ..

드디어 입사하고 첫 서비스가 운영에 배포되는 날이었다.출근하자마자 각 서버의 인스턴스들을 모니터링하고, 모든 서비스가 배포된 후 운영 테스트가 진행되었다. 🫣 1. 문제 상황한참 운영 테스트가 진행되고 있는 와중에 서비스에서 예외가 발생했다. 😱확인 결과, 데이터 취득을 위해 타 서비스로 API를 요청하는데 이 과정에서 400(Bad Request) 응답 코드를 받게 된 것이었다. 🤯 결론적으로 요청을 받는 서비스 측의 문제로 문제가 해결되기를 기다릴 수밖에 없었지만, 문득 의아한 생각이 들었다. 정책상 위 과정에서 예외가 발생할 경우 2회 재시도가 발생했어야 하는데? 로그상으로는 1회 요청으로 끝난 것이다. 😳그래서 어김 없이 오늘도 원인을 파악하기 위해 삽질이 시작되었다. 2. Feign의 기..

오늘도 어김 없이 문제 상황에 부딪혔고 이를 해결하면서 알게 된 내용들을 정리하려고 한다. 🤣개발은 매일 매일이 배움의 시간이라는걸 뼈저리게 느끼며 삽질 시작! 1. 문제 상황Java로 배치 처리를 하다 보면 스트림(stream().forEach())나 람다식을 사용할 일이 참 많다.이번 문제는 스케줄러 내부, 람다식 사용에서 발생했다. 기존에는 람다식을 통해 코어 로직을 호출하고 해당 로직에서 예외가 발생할 경우 예외와 함께 알림 처리를 진행했다.하지만 모니터링을 통해 점진적으로 처리량을 늘려가야 할테지만, 현재 한번에 처리되는 데이터의 양은 200건으로 설정되어 있고, 그럴 일은 없겠지만 최악의 경우 200건 모두 예외가 발생하면 알림 또한 200개가 전송될 여지가 있기 때문에 예외를 누적하여 단건..

최근 도메인 서비스를 개발하면서 데이터 처리, 재처리 등을 위한 스케줄러를 구현하게 되었다.스케줄러는 이전 직장에서도 자주 구현해왔던지라 익숙했지만, 다중 인스턴스 환경에서의 구현은 처음이고 ThreadPoolTaskScheduler, ShedLock 활용도 처음이라 의도한대로 동작하는지 출근하면 로그를 모니터링하는 습관이 생길 정도였다. 하지만 왜 슬픈 예감은 틀린 적이 없는지... 🥲특정 주기의 스케줄러 로그가 누락되는 현상을 두 눈으로 확인한 후에 내 머릿속은 바빠지기 시작했다.왜 1개의 로그가 안찍혔지? 왜 2개만 로그가 찍힌거지? 내가 잘못 본건가? 😳😳 1. 시스템 구성 및 문제 상황먼저 시스템의 구성을 간단히 소개하자면,ThreadPoolTaskScheduler를 활용해 스케줄러를 관리..

Spring에서는 공통 인터페이스에 제네릭을 사용해 도메인마다 다른 타입을 주입받는 구조를 자주 활용한다.구조도 깔끔하고 재사용성도 높아서 자주 쓰이는 방식인데, 문제는 FeignClient에 이 구조를 적용하려고 할 때 발생한다. 실무로는 처음 다뤄보는 FeignClient, 하루하루를 고군분투하는 이제 막 입사한 한달차 새내기 개발자는 이 구조가 적용되어 있다는 사실을 인지하지 못한채 로컬 테스트 도중 예외를 만나게 되었고, 디버깅과 구글링으로 삽질을 하다 깨달음에 도달했다. 따라서 이번 글에서는 삽질의 깨달음을 잊지 않기 위해서 FeignClient에서 제네릭 타입이 유지되지 않는 이유, 그로 인해 만났던 예외, 이를 해결하기 위한 방법에 대해 정리하려 한다. 1. 문제 상황: ResponseEnt..

자, 드디어 Redis의 마지막 챕터에 도달했다.3일을 Redis를 위해 달려왔다!이번 계기로 나도 Redis를 활용해서 조회 성능을 개선할 수 있는 개발자로 성장하자! 1. ElasticCache 잘 생성된거 맞아?우선 대시보드에 들어가서 상태를 확인해보자. 상태가 Avaliable로 변경된 걸 보니 잘 생성된 것 같다.생각보다 엄청 오래 걸려서 한참 기다렸다. 2. EC2에서 ElastiCache 접속해보자! 기본 엔드포인트에서 Port만 빼고 복사하자.참고기본 엔드포인트: 모든 권한을 가지고 있는 주소리더 엔드포인트: 읽기 전용 주소 # EC2에서 ElastiCache 접속하는 명령어redis-cli -h instagram-cache-server.iaxvmk.ng.0001.apn2.cache.ama..

현업에서는 EC2에 Redis를 직접 설치해서 사용하지 않고,데이터베이스를 RDS를 활용하는 것처럼 Redis도 AWS의 ElastiCache를 활용해서 사용하고 있다고 한다.설정이 쉽고 부가적인 기능도 많고 안정성이 높은 이유 때문이다. 따라서 AWS ElasticCache를 마지막으로 활용해보자! 1. 아키텍처 구성이전 아키텍처기존의 아키텍처 구조는 취준생 레벨 또는 비용을 극단적으로 관리해야 하는 초기 스타트업에 적합한 구성이다.실제로 규모가 조금이라도 커지면 서비스를 이렇게 구성하는 경우는 드물다. ElasticCache 도입 아키텍처따라서 이런 식으로 구성하는게 실제 서비스 현업에 가까운 아키텍처 구조라 할 수 있다.우리는 현업에 가까운 배포 환경을 경험해야 하지 않겠는가? 지금부터 AWS 인프..