개발과 일상

이전 글에선 JWT 검증 코드를 인터셉터에 적용해봤다. 이번 글에선 Filter에 적용해보자. 먼저 가볍게 Filter에 대해 짚고 넘어가보자. Filter는 Interceptor와 다르게 Dispatcher Servlet이 동작하기 이전에 위치한다. 그리고 별도의 필터에 대한 설정이 없으면 모든 요청에 대해서 반드시 한번 실행이 된다. 때문에 인터셉터보다는 더 범용적이고, 한번은 무조건 타야하는 보안, 인증/인가 작업이 주로 Filter에서 이뤄지게 된다. 흔히 알고 있는 스프링 시큐리티의 필터 체인들이 여기서 수행된다. Filter는 별도의 설정없이 Filter 인터페이스만 implements해도 요청이 들어올 때마다 실행되기 때문에 구현은 비교적 간단하다. 구현 여기서부터 등장할 jwt 관련 코드는..

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