배경사내 OpenAPI에 RateLimiter를 추가하면서 테스트를 강화하고 회귀 오류를 방지하기 위해 철저한 검증을 진행했습니다. 그럼에도 불구하고 예상치 못한 장애가 발생했습니다.회귀 오류를 방지하기 위해서 테스트 코드를 강화했음에도 불구하고 테스트에서 장애가 검출되지 않는 이유는 무엇이었을까요?결론부터 말씀을 드리자면, 사내에서는 OpenAPI 요청 서버와 인증 서버를 분리하여 운영하고 있는데, 테스트 환경에서 네트워크 I/O 발생 부분을 Mocking 처리한 것이 원인이었습니다. 그리고, 실제 디버깅을 하면서 문제를 추적하는 과정에서 FeignClient의 @SpringQueryMap을 사용한 특정 요청이 실패한다는 사실을 발견했습니다.개발 환경Java Version : 14Spring Boot ..
서론데이터 통신 비용 절감의 필요성안녕하세요. 최근에 환율이 올라가게 되면서 자연스럽게 서버의 지출 비용이 늘어나게 되었습니다. 아래 사진은 최근 6개월간의 환율 변동입니다.회사에서는 불필요한 비용 지출이 없는지 점검하는 시간을 가졌습니다. 이 과정에서 데이터 전송 비용에서 이상치 데이터가 발견되었고, 해당 원인을 분석하고 개선하는 업무를 맡게 되었습니다. 이번 글에서는 그 과정과 해결 방안을 공유하고자 합니다.비용이 발생하는 주요 원인클라우드 비용을 추적하기 위해 메가존에서 제공하는 Hyperbilling 서비스를 사용하고 있습니다. 해당 서비스에서 특정 리소스의 Out 대비 비용이 유독 높게 발생하고 있음을 확인했습니다.특히 비용이 발생하는 카테고리는 APN2-DataTransfer-Out-Bytes..
트렌비에서는 대부분의 서버가 분산된 EKS 환경에서 운영되고 있습니다. 하지만, 새로운 프로젝트를 만들 때에 분산 환경을 위한 분산 락 설정을 매 번 추가해주어야 하는 번거로움과 레거시 시스템에서는 분산 환경을 충분히 고려하지 못한 경우가 있어 동시성 문제가 발생하는 경우가 종종 있었습니다. 이를 해결하기 위해, 사내 공통 분산 락 라이브러리를 개발하자는 아이디어를 팀장님에게 제안하였고 자유롭게 만들어 볼 수 있는 기회를 주어서 제작해보게 되었습니다. 분산 락Java와 Kotlin에서는 Monitor 인터페이스로 ReentrantLock, synchronized 키워드 등을 통해 락을 관리할 수 있습니다. 하지만 이러한 방식은 인메모리에서만 작동하여 분산 환경에서는 적용하기 어렵습니다. 예를 들어, 클라..
서론 Spring Security를 Security 5로 공부를 진행해나가면서 Security6 에서 많은 부분이 변경되었다는 얘기를 듣고 공식문서를 보면서 학습한 내용에 대해 Security5를 Secuirty6로 Migration을 진행 해 나갔습니다. 그 중에서 SecurityFilterChain에 등록을 할 때 정적 자원들에 대해서 ignoring 설정을 해주지 않으면, SecurityFilterChain에서 이전에 등록되어있는 정적 자원들에 대해 모든 Filter들이 적용이 되기에 쓸데없는 메모리 낭비가 발생하고, ignoring설정을 해서 새로운 SecurityFilterChain을 만들어 주되 Filter 들은 추가되지 않는 방향으로 성능 개선을 진행한 사례를 볼 수 있었습니다. 이에 대해,..
OAuth2(Open Authenticaiton, Open Authorization) 표준 인증 프로토콜이다. 사람들은 타 사이트의 비밀번호를 제 3의 서버에서 노출하기를 꺼린다. → 노출되며 다른 정보도 노출 될 것이 자명하기 때문. 사용자가 타 사이트의 비밀번호를 변경하게 되면 제 3의 서버에 저장된 비밀번호도 바꿔야 해서 정상적인 서비스가 불가능하다. 주요 용어 Resource Owner : 서비스를 이용하는 사용자, 즉 리소스 보유자 Client : Resource Server에 자원을 요청하는 제 3 서버, RO를 대신하여 리소스를 요청한다. Resource Server : 클라이언트의 요청을 수락하고 응답할 수 있는 서버, ex) 네이버, 카카오 등 Authorization Server : 성..
Postman을 사용하여 스프링의 @ResponseBody로 api 통신을 하고 있던 와중에 다음과 같은 오류를 겪게 되었다. Error parsing HTTP request header Invalid character found in method name HTTP method names must be tokens 대충 에러를 보면 HTTP 요청헤더에 뭔가 잘못되었다고 하고 HTTP 메서드 이름에서 유효하지 않은 문자가 발견됐다는 것이다. 그리고 토큰화 되어야 한다고 한다. 먼저 헤더부터 살펴봤다. Content-type도 application/json으로 일치하고, Accept는 따로 설정하지 않았으니까 별 문제가 없을 것이고 Connection 또한 tcp 연결을 time-out 만큼 유지하고, ma..
Aspect의 등장 이유 스프링 AOP는 부가 기능 추가시 횡단 관심사로 인한 문제 때문에 등장하게 되었다. 만약 횡단 관심사를 객체 지향적으로 해결하기 위해서는 많은 문제들이 발생한다. 부가 기능을 적용할 때, 부가 기능을 적용하기 위한 코드를 작성해주어야 한다.(템플릿 적용 전) 부가 기능이 여러곳에 퍼져서 중복 코드를 만들어 낸다. (적용 이후에도 동일) 부가기능 변경 시 많은 부분을 수정해야 한다. (제대로 된 캡슐화가 되지 않음) 부가기능 적용대상 변경 시 많은 수정이 필요하다. (적용하지 않을 대상들을 직접 찾아야 함.) 이러한 문제점을 해결하기 위해 핵심 로직과 부가 기능 로직을 나누고, 부가 기능을 어디에 적용하고 어떤 부가 기능을 적용할 지 선택하는 기능을 합한 하나의 모듈로서 등장한 것..
빈 후처리기라고 얘기를 하면 먼저 떠오르는 것은 @PostConstruct가 떠오를 것이다. 빈을 초기화하는데에 있어서, 초기화 이후 어떠한 작업을 추가해서 하기 위한 애노테이션인데 이 또한 빈 후처리기에 속한다. 오늘은 스프링의 빈 후처리기가 무엇인지 살펴보자. Bean PostProcessor(빈 후처리기) 빈 후처리기란 빈 저장소에 사용될 목적으로 생성할 객체를 빈 저장소에 등록되기 직전에 조작하는 것이다. 따라서, 빈 객체가 스프링 컨테이너에 등록되기 전에 저장 될 객체를 다른 객체로 바꾼다거나, 프록시를 적용한다거나 여러가지가 가능하다. 빈 후처리기 적용 과정 빈 후처리기의 적용 과정은 크게 4가지로 구분 할 수 있다. 1. 생성 : 스프링 빈 대상이 되는 객체를 생성한다. 2. 전달 : 생성된..
