웹 어플리케이션 이해하기

#1. HTML의 탄생 

버너스 리 선생님은 컴퓨터로 논문을 자주 읽으셨습니다. 근데 왠걸 맨 마직막에 참조 논문들도 읽어야해서 필요한데 찾기가 힘들었습니다. 책으로 찾거나 인터넷으로 따로 검색해서 찾는게 귀찮으셨던거죠. 그래서 HTML이라는 언어를 만드십니다. 그때부터 문서에 링크도 달 수 있고 사진도 넣을 수 있게 됐어요. 

 

웹브라우저에서도 규칙에 따라서 작성되는 HTML의 구문을 분석할 수 있는 엔진이 필요했고 화면에 그려줄 수 있는 랜더링 엔진도 생겨났죠. 사용자들이 화면으로 글자를 보고 링크도 타고 들어갈 수 있어야하는데 웹 브라우저가 그 역할을 못하면 좀 이상하겠죠? 

 

근데 똑똑한 분들은 생각했더레요. HTML파일이 모든 컴퓨터/웹브라우저에서 똑같이 해석 되려면 어떻게 해야하지? 규칙을 만들자! 해서 만들어진게 HTTP 통신 규약입니다.

 

하나의 서버에 다양한 웹브라우저에서 요청을 해도 같은 값을 화면에 랜더링 해줄 수 있게 됐어요.

 

에이 근데 너무 글씨만 있으니깐 밋밋하네 좀 꾸며볼까? 하고 나온게 CSS에요. 이제 형형색색의 포인트도 있는 논문을 볼 수 있게 되었습니다.  

 

사용자 별로 화면을 다르게 보여주려면 로그인을 해야하는데 이 로직을 어디서 처리하지? 이제 Was가 나옵니다. 많은 블로그 글들을 보면 WAS가 로직을 담당하는 서버라고 말하죠? was에서 이 로그인 로직을 처리합니다. 근데 이 사람이 우리 서비스의 회원인지 어떻게 알아? 사용자에 따라 데이터가 다른데 어떻게 하지? 저장하고 있어야겠다. 이제 DB를 사용합니다.   

 

WAS에서 end-point를 받는 역할을 하는 컴포넌트를 Controller라고 부릅니다. 그리고 HTML에 사용자에 따른 데이터를 가져와야하는데 이 부분들을 모두 Model 컴포넌트라고합니다. 이제 사용자에 맞는 데이터를 가지고 HTML파일을 동적으로 생성합니다. 이 컴포넌트가 View입니다. 뭔가 어디서 많이 들어봤죠? MVC 아키텍쳐가 기술의 발전 속에서 만들어진 겁니다. 

 

더 많은 이야기들이 있지만 웹 어플리케이션 서비스를 이해하기 위해서는 지금 이정도면 충분할 것 같습니다.  

 

이제 강의를 따라가면서 스프링 MVC패턴의 발전 과정을 짚어 나가봅시다.  

 

#2.  서블릿과 톰캣의 멀티쓰레딩 지원

대부분의 웹 어플리케이션은 HTTP API를 가지고 통신합니다. 우리는 이 HTTP API를 통해 받은 긴 STREAM데이터(한줄로 나열된 데이터)를 해석해야하는데 누군가의 도움도 없이 해석하려면 해야할 일이 너무 많습니다.  서버의 TCP/IP 연결 대기, 소캣 연결, HTTP 요청 메세지 파싱해서 읽기, URL 인지 Content-Type 확인등 주요 서비스 로직을 제외하고도 해야할 일이 많아진거죠. 이걸 서블릿이 모두 지원해주는거죠. 이제 개발자는 의미있는 서비스 로직만 개발하면 그만입니다. 정말 편하죠? 

 

이제 HttpServletRequest, HttpServletResponse 등과 같이 서블릿이 지원해주는 편리한 기능들을 개발자는 사용하면 됩니다.  

 

요청과 응답은 새로운 객체를 생성하여 반환하지만 서블릿의 경우는 싱글톤으로 관리됩니다. 싱글톤으로 관리된다는 말의 의미는 WAS에 단 하나의 서블릿만 만들어져서 재활용된다는 의미입니다.  하지만 공유 변수들을 사용할 때는 유의해야합니다.  

 

하나의 프로세스 당 하나의 쓰레드가 기본적으로 생성됩니다. 이게 무슨 말이냐구요? Tomcat을 WAS의 한 종류라고 봅니다. 서블릿을 지원하는 application을 WAS라고 통칭합니다. 이 WAS도 종류가 뭐가 됐든 하나의 application 입니다. 결국 WAS는 이 쓰레드라는 녀석을 사용해서 사용자의 요청을 처리합니다. 만약 사용자의 요청이 하나의 쓰레드를 사용해서 처리된다면 100건 정도의 트레픽은 금방 처리할 수 있지만 1000건, 1000만건이되면 사용자의 대기시간이 길어지거나 서버가 죽어버리는 경우가 발생합니다. 그래서 WAS들은  쓰레드를 여러개 만들어서 사용하는 멀티 쓰레딩을 지원합니다. 이제 사용자의 요청이 다수 들어오면 쓰레드를 생성하여 해당 요청을 처리해주면 됩니다. 

 

요청마다 쓰레드를 생성하면 요청 1000건에 1000개의 쓰레드가 만들어지는데 이건 CPU 자원을 많이 잡아먹는 일입니다. 효율도 떨어지고 쓰레드를 새로 생성하는데 드는 시간 때문에 서버의 성능이 저하됩니다. 

 

그래서 WAS는 Thread Pool이라는 것을 사용합니다. 프로그래밍에서는 pooling기법을 자주 사용합니다. 재사용가능한 소스들을 담아 놨다가 다시 사용한다는 의미에서 pooling이라고 표현한 것 같습니다. 공구함에 들어있는 공구들을 생각하시면 좋을 것 같습니다. 

 

어플리케이션이 실행될때 100개의 쓰레드를 미리 생성하여 pool에 담아놓습니다. 그리고 이 풀에서 쓰레드를 꺼내와서 사용하고 반납합니다. WAS 튜닝에서 가장 중요한 부분은 이 쓰레드 풀 내부의 쓰레드를 최대 몇개 둘것이가를 결정하는 것입니다. 너무 작게 두면 CPU 사용율이 10%도 안되는 경우가 발생하기 때문에 그렇게 하지말고 최대한 CPU자원을 활용할 수 있게 끔 성능 체크를 해줘야합니다.