필터 , 인터셉터의 차이와 이해

들어가며

 

실무를 하다보면 자연스럽게 접근제어에 대한 이해도가 요구된다.

단순하게 요청을 처리 한다는 개념을 넘어서 어떻게 효과적으로

요청을 관리하고, 처리할 수 있을지에 대해 고민하게 된다.

 

필자도 저연년차 개발자이때문에 이전 기술스택과 현재 사용되는 기술스택을

비교하여 어떤 방법으로 처리하는지를 고민할 수 밖에 없다. 이를 고민한 결과를 공유하는 포스트이다.

 

또한, 필자는 JAVA 기반 응용소프트웨어를 개발하고 있다보니,

자바기반의 처리를 중점적으로 정리한다.

 

(Filter)필터란?

개념

이름그대로 걸러주는 망 이라고 생각할 수 있다.

가장 처음에 들어오는 레벨로 서블릿레벨에서 처리가 시작된다.

 

일반적으로, 보안헤더나 인코딩과정과 같은 선제적인 처리를 할 때

활용되는데 가장 Low한레벨에서 I/O를 관리되기 때문에

단순하고, 경량적인 환경에서 매우 유용하게 사용할 수 있다.

실무 활용팁

실무에서는 주로 타 업체가 기존에 쓰고 있는 서비스들과

SSO연동작업을 할때 사용하거나, 내부 SSO 시스템을 구축할때

선제적으로 처리하는 파트를 이용할 때 활용하였다.

 

SSO라는 것은 하나의 아이디로 여러 시스템에 접근할 수 있게해주는

기술을 의미하는데, 이때 내부에 있는 특정 보안된 정보를 풀어내서

해당 정보가 옳바르다면 다음 체인으로, 아니라면 호출이전에 거부할 수 있어

효과적으로 처리할 수 있는 방안이다.

 

또한, JWT를 기반한 인증체계를 작성할때 스프링 시큐리티를 활용하게 되는데 이때 인증처리 기반을 필터체인레벨에서 관리한다는 점도

함께 알아두면 좋다.

 

단점

 

다만, 단점으로 스프링에서 등록되는 빈을 접근하는데는 어려움이 있고,

(서블릿보다 상위 개념에 있기 때문에) , 필터체인이라는 기술을 이용해

순서를 배정하는데 이때 약간의 오버헤드가 발생하는 문제점이 있다.

 

필터에서 인터셉터로

 

https://sejin-technology.tistory.com/59

일단, 위에 기존에 설명해둔 자료를 한번확인해보자

방금말한 필터 서블릿 이외에도 여러가지 서블릿들이 동작하게 되는

곳을 서블릿 컨테이너라고 말한다.

 

이다음에 우리가 알아야하는것은

dispatcher Servlet이라고 하는데 요청을 처리할 핸들러(컨트롤러)를 찾고 해당 객체의 메소드를 호출 하는 업무를 담당하게 되며 이것이

실제 컨트롤러를 찾아갈 수 있도록 하는 역할을 하게 되는 것이다.

 

이때 우리가 어떤 컨트롤러인지 찾아가는것을 “핸들러 어뎁터”를 사용하게 된다.

 

인터셉터

위에서설명한 필터레벨의 서블릿이 완료가 되면

dispatcher Servlet에 의해 핸들러 어뎁터에 접근하게 된다.

 

이 핸들러 어뎁터가 실행되기전에 또는 실행된 직후 관리가 되게 되는데

해당 핸들러 어뎁터의 경우 view를 생성하기 이전으로 데이터를 가공하기 전에 사용하는 것이 매우 용의하다.

 

또한, 데이터를 생성할때 필요한 생성 시간에 대한 조절을 하는 단계도

해당 레벨에서 지원할 수 있다. (실제로 해본적은 없고, 개념적으로 알고있다.)

실무에서의 활용

먼저 권한이 존재하는가를 처리하는데는 해당 인터셉터를 활용하는것이

유리하다. 실제 뷰나 데이터가 생성되기 이전에 상태이기 때문에

서버 리소스를 사용하지 않도록 유도할 수 있으며 ,

 

최근 다국어 지원에 대한 공부를 하고 있는데 해당 다국어 지원을 위해

Accept‑Language·Tenant‑ID를 이용해보는 방안을 공부해보고있다.

단점

먼저 웹계층이 없으면 사용못한다. 당연하게도 dispatcher Servlet이 실행된후 핸들러 어뎁터로 타야하기 때문에 우리가 실무에서 마이크로서비스 아키텍처를 다루게 된다면, 카프카나 큐관련된 리스너 “소비자” 입장에서는 사용이 가능하지만, 불편하며 굳이? 라는 내용이 당연하게도 담기게 된다.

 

또한, 예외처리의 한계가 존재하는데 우리가 일반적으로 예외를 발생되면 관리되는 HandlerExceptionResolver 의 경우 생성 시점에 따라 문제상황을 다르게 인식할 수 있다. 즉시 발생되는게 아닌, 위임후 발생되어 문제를 확인하기 때문인데 이러면 의도한

로그가 발생되지 않는 가능성이 존재하게 된다.

 

마지막으로 필자가 최대한 인터셉터를 활용을 자제하는 이유이기도한, 오버헤드에 대한 문제이다.

 

위에서 설명한대로 특정 컨트롤러에 요청하기 이전에 발생된다고 했는데

이러려면 먼저 URL 그러니까 자원의 위치를 확인을 하고 시작되는데

이게 찾는 과정이 발생하게 되어서 아무생각없이 달면

 

트래픽이 많아지는 부분에서 생각보다 큰 부하가 발생되며,

이를 위해 경량화하는 작업을 진행해야하는데 이게 진짜 까다롭다.

(필자가 어렵게 느끼는 것일 수 도 있다.)

 

다음 포스팅

다음 포스팅은 이를 기반한 AOP에서의 활용도 봐보겠다.

물론 약간레벨이 다른감이 있긴한데, AOP는 프로그래밍 기법론 이기 때문에!

그럼에 주로 활용하고 있는 부분이 예외처리에서 사용하고 있어서

(아직 필자가 AOP를 활용하는 레벨이 로깅 , 성능측정 , 예외처리 수준)

이것도 한번 같이 정리해 보겠다.