개발과 일상

개요난 꽤 오랫동안 "서비스 로그를 어떻게 남겨야 할까?"라는 고민을 해왔고, 이 고민은 다음의 블로그 글들로 이어져 왔다.스프링부트 서비스에 LOG 남기기 (with. Logback)스프링부트 AOP를 이용해 로깅 처리하기스프링부트에서 Multipart/form-data 요청의 MultipartFile 정보 로그 남기기Terraform으로 EKS 배포하기 11. Grafana Loki와 로그 모니터링 로그를 남길 때 가장 많이 고민한 건 다음과 같은 질문들이었다. API마다 어떤 로그를 남겨야 하는가?예외 발생 시 어떤 정보를 남겨야 대응하기 좋을까?known 에러는 어떻게 표기할까?서버 에러는 어떻게, 또 알람은 어떤 기준으로 발생시킬까?이번 서비스 개발을 계기로, 어느 정도 최종안을 정리할 수 있었..

이전 글에서 JWT가 무엇이고 어떤 데이터를 실어서 보낼 수 있나를 알아봤다. 그럼 이번 글부터는 어떻게 적용하면 될지 알아보자. 이번 글에서 소개할 방식은 interceptor에 적용하는 방식이다. interceptor는 스프링에서 제공하는 컨트롤러 이전에 위치하는 공통처리부 중 하나이다. 아래 그림을 확인하면 편하다. 공통처리부에 관한 글을 예전에 썼었는데, 이 때는 스프링 MVC를 쓰던 시절이라 필터와 인터셉터를 xml에서 제어를 하도록 구성되어 있었다. (왜 썼는지, 어떤 역할을 하는지 보다 이런게 있다라고 정리한 글이었다) 여기서 추가적으로 간단하게 짚고 넘어가면, Interceptor는 스프링 내부에서 Dispatcher Servlet 이후에 동작한다. 컨트롤러 앞단에 위치해 요청과 응답을 간..

이전 게시글(Thread Safety)과 연관된 글로 과부하 로직을 구현하며 고민했던 것에 대한 내용 정리이다. 현재 운영/개발 중인 서버에 보안 로직으로 과부하 제어 로직을 추가하게 됐다. 아래는 과부하 로직의 명세이다. WAS로 들어오는 모든 request를 카운팅한다. 카운팅한 횟수는 response로 빠져나갈 때 차감된다. request가 reponse로 빠져나가지 않으면 count는 계속 누적되고, 특정 임계치 이상이 넘어가면 서버의 과부하 상태를 response로 내보낸다. 위 로직을 구현하기 위해 Apache Tomcat의 멀티쓰레드 구조에 대한 대응으로 Atomic Integer 클래스를 이용해 동시성 이슈를 제어하도록 했다. 이번 글에서는 과부하 제어 로직이 위치할 부분에 대한 쓰려고 한..