서블릿과 JSP의 한계 서블릿으로 개발할 때는 뷰(View)화면을 위한 HTML을 만드는 작업이 자바 코드에 섞여서 지저분하고 복잡했다. JSP를 사용한 덕분에 뷰를 생성하는 HTML 작업을 깔끔하게 가져가고, 중간중간 동적으로 변경이 필요한 부분에만 자바 코드를 적용했다. 그러나 이러한 형태는 비즈니스 로직과 뷰 영역이 혼재되어 코드를 이해하기 어렵고 유지보수가 힘들어진다는 단점이 있다. MVC 패턴 - 개요 하나의 서블릿이나 JSP만으로 비즈니스 로직과 뷰 렌더링까지 모두 처리하게 되면, 변경의 라이프 사이클이 다르기 때문에 유지보수하기 좋지 않다.

웹 서버(Web Server) HTTP 기반으로 동작 정적 리소스 제공, 기타 부가기능 정적(파일) HTML, CSS, JS, 이미지, 영상 예) NGINX, APACHE 웹 애플리케이션 서버(WAS - Web Application Server) HTTP 기반으로 동작 웹 서버 기능 포함+ (정적 리소스 제공 가능) 프로그램 코드를 실행해서 애플리케이션 로직 수행 동적 HTML, HTTP API(JSON) 서블릿, JSP, 스프링 MVC 예) 톰캣(Tomcat) Jetty, Undertow 웹 서버, 웹 애플리케이션 서버(WAS) 차이 웹 서버는 정적 리소스(파일), WAS는 애플리케이션 로직 사실은 둘의 용어도 경계도 모호함 웹 서버도 프로그램을 실행하는 기능을 포함하기도 함 웹 애플리케이션 서버도 웹 서버의 기능을 제공함 자바는 서블릿 컨테이너 기능을 제공하면 WAS 서블릿 없이 자바코드를 실행하는 서버 프레임워크도 있음 WAS는 애플리케이션 코드를 실행하는데 더 특화 웹 시스템 구성 - WEB, WAS, DB 정적 리소스는 웹 서버가 처리 웹 서버는 애플리케이션 로직같은 동적인 처리가 필요하면 WAS에 요청을 위임 WAS는 중요한 애플리케이션 로직 처리 전담 효율적인 리소스 관리 정적 리소스가 많이 사용되면 Web 서버 증설 애플리케이션 리소스가 많이 사용되면 WAS 증설 WAS, DB 장애시 WEB 서버가 오류 화면 제공 가능 정적 리소스만 제공하는 웹 서버는 잘 죽지 않음 애플리케이션 로직이 동작하는 WAS 서버는 잘 죽음 참고 https://www.

서블릿 사용 시 HTTP 요청, 응답 흐름 HTTP 요청시 WAS는 Request, Response 객체를 새로 만들어서 서블릿 객체 호출 개발자는 Request 객체에서 HTTP 요청 정보를 편리하게 꺼내서 사용 개발자는 Response 객체에 HTTP 응답 정보를 편리하게 입력 WAS는 Response 객체에 담겨있는 내용으로 HTTP 응답 정보를 생성 서블릿 컨테이너 톰캣처럼 서블릿을 지원하는 WAS를 서블릿 컨테이너라고 함 서블릿 컨테이너는 서블릿 객체를 생성, 초기화, 호출, 종료하는 생명주기 관리 서블릿 객체는 싱글톤으로 관리 고객의 요청이 올 때 마다 계속 객체를 생성하는 것은 비효율 최초 로딩 시점에 서블릿 객체를 미리 만들어두고 재활용 모든 고객 요청은 동일한 서블릿 객체 인스턴스에 접근 공유 변수 사용 주의 서블릿 컨테이너 종료시 함께 종료 JSP도 서블릿으로 변환 되어서 사용 동시 요청을 위한 멀티 쓰레드 처리 지원 웹 애플리케이션 서버의 요청 응답 구조 HttpServletRequest 역할 HTTP 요청 메시지를 개발자가 직접 파싱해서 사용해도 되지만, 매우 불편할 것이다.

사설 IP(Private IP) 사설 IP(Private IP)는 한정된 IP 주소를 최대한 활용하기 위해 IP주소를 분할하고자 만든 개념이다. IPV4 기준으로 최대 IP 개수는 약 43억개이다. 사설망 내부에는 외부 인터넷 망으로 통신이 불가능한 사설 IP가 구성된다. 그리고 외부로 통신할 때는 통신 가능한 공인 IP를 사용한다. 보통 하나의 망은 사설 IP를 부여받은 기기들과 NAT 기능을 갖춘 Gateway로 구성한다. NAT(Network Address Translation) NAT(Network Address Translation)는 사설 IP가 공용 IP로 통신할 수 있도록 주소를 변환해주는 방법이다.

스프링 비동기 설정 @Async는 비동기적으로 처리를 할 수 있게끔 스프링에서 제공하는 어노테이션이다. 해당 어노테이션을 붙이게 되면 각기 다른 쓰레드로 실행이 된다. 즉, 호출자는 해당 메서드가 완료되는 것을 기다릴 필요가 없다. 이 어노테이션을 사용하기 위해서는 @EnableAsync 가 달려있는 configuration 클래스가 우선적으로 필요하다. @EnableAsync는 스프링의 @Async 어노테이션을 감지한다. 1 2 3 4 @Configuration @EnableAsync public class AsyncConfig { } 기본적으로, 스프링은 비동기적으로 메서드를 실행하기 위해서 SimpleAsyncTaskExecutor를 사용한다. SimpleAsyncTaskExecutor는 요청이 오는대로 계속해서 쓰레드를 생성하는 방식이다.

쿠버네티스 클러스터의 전체 구조 마스터에는 etcd, kube-apiserver, kube-scheduler, kube-controller-manager,kubelet, kube-proxy, docker 등의 컴포넌트가 실행된다. 컴포넌트 각각이 다른 마스터나 노드 서버에서 별개로 실행되어도 실제 쿠버네티스 클러스터를 운영하는 데 이상은 없다. 하지만 마스터가 서버 1대라면 방금 소개한 프로세스 한 묶음을 해당 서버에서 같이 실행하는 것이 일반적인 구성이다. 마스터는 보통 고가용성을 만족하고자 서버 3대 정도 구성해서 운영한다. 평소 실제 클러스터를 관리하는 리더 마스터는 1대고 나머지 2대는 대기한다. 리더 마스터에 장애가 발생하면자연스럽게 나머지 2대 중 1대가 리더 역할을 맡다.