2023년 12월 4주차(12/25 ~ 12/29) Weekly I Learned "Good Bye 2023, Hello 2024!!"

지난 한 주 되돌아보기

드디어 2023년의 마지막 WIL 작성이다. 🎊 2023년의 경우, SSAFY 1학기 과정과 백엔드 엔지니어로 근무하면서 웹 개발과 관련하여 정말 많은 것을 배우고 경험할 수 있었던 한해였다. 다만, 아쉬웠던 점은 그동안 많은 지식과 경험을 습득했음에도 불구하고 시간적 및 마음적 여유가 없어 해당 내용들을 기술 블로그에 남기지 못했었 점이었다. 그리하여 이번 WIL 을 끝으로 2024년부터는 Tech 위주의 글을 하나씩 작성해볼까 한다. ✍

 

요구사항 구체화하기..🔧

지난 주에 이어 계속해서 최적화 작업을 진행하고있다. 🛴 이번 주에 처리하려는 요구사항 중에는 작업하는데 있어 다소 모호한 요구사항이 있었기에 PMO 측과 해당 요구사항에 대해 구체적으로 재정의할 필요가 있었다. 예를 들어, 어떤 데이터 리스트를 조회함에 있어 해당 데이터들이 항상 최신화되어있어야 한다는 것이 있었는데, 구체적으로 어떤 이벤트가 발생했을 때 해당 데이터들이 최신화되어야 하는지 정의될 필요가 있었다. 아울러, 실제로는 일부 데이터의 경우에는 생성 당시의 값을 그대로 유지했어야만 했다. 이에, 구체적으로 어떤 이벤트가 발생했을 때, 어떤 데이터들이 최신화되어야하는지 등 요구사항에 대해 재정의하는 시간을 가졌다. 👀

 

여러가지 기술적 이슈를 겪을 수 있었던 한 주..🌠

이번 주 역시 작업하면서 기술적으로 몇가지 이슈가 있었다. 👋 우선, grpc 를 사용하면서 겪었던 이슈가 있었다. grpc 프로토콜로 어떤 요청을 받아 처리함에 있어 No thread-bound request found 라는 메시지와 함께 에러가 발생했었는데, 구체적으로는 SimpleJpaRepository 에서 제공하는 save 메서드를 사용하는 경우 해당 에러가 발생하게되었다. 결론적으로, 이에 대한 원인은 grpc 요청을 받아 처리할 때에는 기본적으로 grpc-default-excutor 라는 스레드가 생성되어 요청을 처리하는데, 일반적인 http request 요청과 다르게 HttpServletRequest 정보를 지니고 있지 않다는 점이었다. 현재 서비스 로직 상 AuditorAware 을 구현하는 과정에서 HttpServletRequest 데이터에 접근하고 있었는데, 현 스레드가 지니고 있는 데이터에는 해당 데이터가 없었기에 발생하는 에러였다. 👀 해당 이슈는 grpc 로 요청을 처리하지 않고 http 로 요청을 처리하는 것으로 해결할 수 있었다. (실제로는 굳이 grpc 로 요청을 처리할 필요가 없었다. 👀)

 

아울러, 특정 리포트를 생성하는 단계에서 Out of range value for column 에러가 발생하는 일도 있었다. 해당 에러는 MySQL 특정 칼럼에 정의된 데이터 타입의 허용 값을 벗어났을 때 발생하는데, 해당 칼럼의 경우 double unsigned 로 설정되어있음에도 불구하고 실제 insert 쿼리에서는 음의 정수 값으로 할당되어있었던 것이다. 그럼 결국 애플리케이션 단에서 음의 정수 값을 할당했을 터이니 생각하고 관련된 애플리케이션 로직들을 모두 살펴보았는데, 해당 데이터를 최초 소싱하는 곳은 네이티브 쿼리 기반으로 percent_rank 함수를 이용하여 데이터를 추출하는 곳이었는데, 추출한 데이터를 Double 필드를 지닌 DTO 에 projection 해주는 것이었다. 이때, percent_rank 함수는 0 ~ 1 의 데이터를 반환해주기에 음수가 발생할 일은 없었고, Double 필드로 매핑해주고 해당 데이터를 그대로 save 처리하고 있었기에, 왜 음수 데이터가 insert 쿼리에 할당되어 나갈지 의문이었다. 사실, 해당 에러의 원인은 아직 명확히 밝혀지지 않은 채로 남아있다. 👀 정말 미스테리한 것은 local 이나 stage 환경에서는 정상적으로 돌아가는데, production 환경에서만 이러한 이슈가 발생한다는 것이다. 아울러, 리포트 생성만 개별 처리할 때에는 또 정상적으로 처리가 된다는 것이다. 👀 이 이슈에 대한 원인은 우선 시간을 두고 차차 알아가봐야겠다. 🏃‍♂️

 

서버 성능 최적화에 다시 한 번 기여할 수 있었다..⭐

이번 12월 4주차에는 3주 전에 성능 최적화 작업을 했었던 것이 production 에 배포되어 처음으로 기능이 동작했었다. N + 1 문제를 개선하고 bulkUpdate 및 bulkInsert 처리를 해줌으로써, 기존 초당 144 건 처리했었던 것에서 초당 1475 건을 처리할 수 있게 되었다. 더욱이, 기존 기능에 더해 부수적인 기능(데이터 생성)이 추가되었음에도 불구하고 많은 성능 개선을 이루어 낼 수 있었다. 🔧 이 작업을 하면서도 여러 이슈들을 만나면서 많은 것을 배울 수 있었는데, 이에 대해선 추후에 별도의 Tech 글로 다루고자 한다.

 

(백준 1일 1커밋 운동은 365일을 향해 달려가고 있다..🏃‍♂️)