Container in springboot
'Container' 하면 무엇이 떠오르는가?
Docker Container 혹은 Spring에서 Ioc container가 떠오를 것이다.
우리가 Web program을 개발한다는 것은 Server에서 동작하며 무언가 기능을 제공해 주는 여러가지 Component를 만드는 것이다.
에를 들어 Component 하나를 만들었다고 가정한다면
회원 가입 이런 기능을 담당하는 Web Component를 만들었다고 한다면
Component는 서버에 존재하게 될 텐데 혼자서 일을 하지 못한다.
Component는 뭐가 필요하냐면 앞에 항상 'Web Client'가 필요하다.
Web Client가 뭔가 요청을 주면 그때 Component가 일을 한다.
Component는 여러 가지 기능이 있겠지만 핵심적인 목표는 Dynamic Content를 만드는 것이다.
만약에 Dynamic 하게 매번 바뀌는 Content가 아닌,항상 고정되어 있는 똑같은 페이지를 띄운다면 Static한 Resource를 올려놓고 항상 똑같은 화면을 보세요. 이렇게 응답을 주면 되는 것이다.
Component를 만든다 혹은 코드를 작성한다는 것은 Dynamic content를 만들어서 다시 Client한테 Request 한다는 것이다.
요청과 응답 쌍으로 돌아가게 되어 있고
그 요청을 처리하는 하나의,하나 이상을 웹컴포넌트가 존재하고, 그 웹컴포넌트 하는 중요한 일은 다이나믹 컨텐트를 만드는 일 이다.
근데 웹 컴포넌트는 항상 웹 컨테이너 안에 들어가 있어야 한다.
웹 컨테이너는 1차적으로 웹 컴포넌트를 관리하는,컴포넌트가 서버 쪽에서 떠 있는 거니 누군가가 시작할 시켜 줘야 할 것 아닌가?
Component를 Memory에 올리고, New 해서 진입해 주는 그런 Class를 Internet으로 생성을 해주고, Service가 되는 동안에 계속 메모리 위에서 동작하도록 관리해 주는 작업이 필요하다. 그런 Memory에서 관리를 해주는, 흔히 말하는 lifecycle을 관리해 주는 그런 역할을 한다.
그리고
일반적으로 하나의 Container는 하나의 Component만 가지고 있지 않다.
이 안은 많은 종류의 하나의 웹컨테이너가 제공하는 서비스를 담당하는 컴포넌트들을 여러 개를 가지고 있을 수 있다.
회원 가입도 해야 되고, 로그인도 해야 되고, 조회도 해야 되고, 주문도 나와야 될 것 같은 그런 등 등의 기능을 가진 여러 개의 컴포넌트들 컨테이너가 다 관리를 해줘야 된다.
또 해줘야 하는 중요한 것은
클라이언트로부터 들어온 요청을 어느 컴포넌트가 담당 할지 결정해서 연결해주는 작업을 해 줘야 된다. 그래서 웹 요청이 들어오면 컨테이너는 정해진 어떤 룰에 따라서 '어느 컴포넌트가 요청을 처리해줘' 라고 넘겨준다.
어떤 컴포넌트가 요청을 처리할지 결정하는 것, 그리고 그거를 선택하는 작업을 우리가 흔히 라우팅 또는 맵핑이라고 얘기한다. 스프링에서 HandlerMapping 이라고 하는 이런 것들이 웹 요청을 담당하는 컴포넌트를 결정 해주는 것이다.
우리가 웹컨테이너 웹컴포넌트라고 얘기를 했는데 이거를 이제 자바 용어로 한번 바꿔 보자. 자바에서는 Web component를 뭐라고 부를까? 바로 Servlet이라고 부른다.
우리가 잘 알고 있는 Servlet이 바로
'Web component'다. 그리고 Servlet을 관리해주는
Container가 'Servlet Container'라고 불린다.
유명한 Servlet Container는 'Tomcat' 같은 것이 있다.
위의 사진을 보면, Tomcat에 여러 개의 SERVLET들을 여러 개 띄어놓고, 그 다음에
Mapping information를 넣으면 Request에 따라서 특정 SERVELT이 해당 Request를 처리할 수 있도록, 그 응답을 Response해서, 다시 Client, Browser라든지 아니면 API call한 Client한테 return해주는 이런 작업을 담당하는 Servelt Container가 존재 한다.
이 것이 전통적인, 90년대 후반부터 시작되는 Java Web programming basic Component가 되는 것이다.
그런데 Servlet에 대해서 불만을 가진, 너무 제한적이고, 더 나은 방법으로 개발을 할 수 있으면 좋겠다 라고 생각했던 사람들이 만든 것 중에 하나가 바로, Spring Framework이다.
Spring도 Container라고 말 했었다.Spring Container는 그럼 무엇일까?
Servlet container를 대신 하는 건가? 라고 생각 할 수 있지만, 그것은 아니다.
Spring container는 뒤에 존재 한다.
Servlet container 뒤쪽에 있으면서도 Spring container도 똑같이 어떤 기능을 담당하는 BEAN을 (spring container에 들어가는 component들은 BEAN이라고 부른다.
JAVA BEAN에서 그 용어를 따 온것)
여러 개의 BEAN을 가지고 있는 Spring container가 Servlet container 뒤쪽에서
Servlet을 통해서 외부로 들어온 Request를 받아가지고 Spring container한테 다시 넘겨 주는 것이다.
그럼 Spring container가 이거는 어느 BEAN이 Request를 처리해라.
그럼, 하나의 BEAN이 이 것은 내가 작업 하는 동안에 이런 기능이 필요하니까 네가 이 작업을 해라. 라고 다른 BEAN을 호출 하기도 하고. Spring container안에서 우리가 만든
Application이 동작을 하는 것이다.
그럼 이러한 의문이 들 것이다. 그럼 Spring Container가 아예 Servlet container를 대체 하면 안될까? 근데 안된다.
기본적으로 자바의 표준 웹 기술을 사용하려면 어쨌건 Servlet container가 존재 해야 한다.
그런데 문제는 Spring Application을 개발하는 거에만 집중을 해서 저 Bean들은 구성은
어떻게 할 것이고 이거를 Spring container에 어떻게 담을 것이며 이런 것만 고민하고 개발을 하면 좋겠는데 이거를 동작 시키려면 가장 간단한 'Hello world' 서버 프로그램 하나라도 띄우려면 Servlet container가 반드시 무조건 떠야 한다.
Servlet container가 필요하다는 것이다.
근데 이 Servlet container를 띄우는 것이 간단하지가 않다. 굉장히 오래된 기술이기도 하고 많은 것을 고려 하려고 다양한 설정 방법들 이런 것들을 요구 하고 있다.
아마 연차가 있는 개발자는 Web.xml이라는 file을 보았을 것이다.
아마 꽤 많은 Spring framework 책에 이것이 등장 할 것이다.
'일단 Spring project를 만들려면 project에 web.xml을 다음과 같이 작성해 주세요.'
라고 전형적으로 나오는 그런 것이다.
Root context는 무엇이며 dispatcherservlet을 등록하는데 설정은 뭐고..
여기에 Servlet Mapping은 어디다, 이런 내용이 들어가 있고 위에도 ContextLoaderListener이런 것들을 설정 해줘야 한다.
이런게 들어가야지만 Servlet container가 뜨고, 그 Servlet container를 통해서 Spring container가 Call 되는 것이다.
근데 이것을 Spring develop하려면 이것을 다 기억 해야 하는 복잡함이 있다.
이런 많은 정보들을 우리가 단순한 스프링컨테이너 들어간 애플리케이션을 만든다고 하더라도 항상 이거를 설치하고 그다음에 실행하도록 하기 위해서는
꼭 필요하지만 그렇게 중요하지 않은,우리가 개발한 동안은 계속 신경 써야 되는게 아닌 이런 내용들을 알고 있어야 되는 번거로움이 있다.
저런 설정들을 모르면 기존 프로젝트에 복사를 해서 붙여 놨는데 하다가 오타 하나 생기면은 에러가 나서, '아 이건 어떻게 해결 해야 되나요?' 물어보고 다녀야 되고 굉장히 번거로운 일이 아닐 수 없다.
더 큰 문제는 뭐냐면 Servlet Container는 표준 스펙이고 그거를 구현한 제품을 갔다가 여러분이 사용해야 되는데,
우리가 잘 알고 있는 Tomcat 같은게 있긴 하지만
프로젝트를 하러 어떤 새로운 환경에 들어갔다고 가정 한다면.
프로젝트에서 '우리는 Tomcat 쓰지 않습니다. 다른 종류의 서블릿컨테이너 없습니다.'
그러면 그 Servlet container에는 web.xml file형식 말고 그 외의 설치부터 해서 배포방식, server, 여러가지 설정 방법 이런 것을 새로 배워야 한다. 또 tomcat마다 조금씩 달라지는 설정 까지도...
그래서 '서블릿컨테이너'가 없는 'Containerless web architecture' 만들어 줬으면 좋겠다.
이 얘기는 뭐냐면 서블릿컨테이너 아예 안 쓰고 어떻게 스프링 컨테이너가 웹 요청을 바로 받을 수 있을까 뭐 이런 얘기는 아니고 서블릿컨테이너라는게 필요 하지만, 이 동작을 해야 되지만 이거를 설치하고 관리하고 신경 쓰기 위해서 개발자가 뭔가를 시간을 들이고 지식을 학습을 하고 적용하는 이런 위에 수고들 없이 할 수 있으면 좋겠다.
제거해 줬으면 좋겠다. 라는 것.
Containerless가 적용이 되면 어떻게 될까?
실제로는 Servlet container가 동작을 하고 있다. 거기 web.xml 이나 혹은 요즘에 그것에 대응되는 java code를 작성하는방법. 아무튼 이런 것들이 다 알아서 Spring boot를 통해서 제공이 된다.그렇게 설정들이 다 Setting 되니까, 거기에 대한 설정을 우리가 하나도 신경 쓰지 않고 개발을 시작하고 서버를 띄우고 동작을 시킬 수 있다.
실제로 코드를 만들어 보면 스프링부트에서 항상 메인메소드가 등장 한다. 거기서 뭔가 이게 처음 시작이 되는구나라는 걸 볼 수가 있다.
근데 그것만으로도 서블릿컨테이너 와 관련된 모든 필요한 것들이 다 쓰레기 되는 것이다. 이것이 컨테이너 리스 개발 방법이다.
'스프링부트' 카테고리의 다른 글
| ApplicationException code analysis (0) | 2023.04.05 |
|---|---|
| IoC(Inversion of Control) 제어의 역전 (0) | 2023.04.04 |
| ResponseEntity 고찰 (0) | 2023.04.04 |
| Model이라는 데이터 전달자 (0) | 2023.04.04 |
| @DataTimeFormat 고찰 (0) | 2023.04.04 |