Web Service Architecture

지난 글에서 JAR, WAR 파일에 대해 학습하던 중 Web Service Architecture 관련 개념에서 어려움을 겪었습니다. 이에 이번 글에서는 이러한 난항을 극복하고자 Web Service Architecture의 전반적인 구조와 구성 요소를 깊이 있게 학습하고자 합니다. 이를 통해 웹 서비스의 동작 원리를 보다 명확히 이해하고, 실제 개발 과정에서의 활용 능력을 향상시키는 것을 목표로 합니다.

정적 페이지(Static Pages), 동적 페이지(Dynamic Pages)란?

웹 서비스를 이해하기 위해서는 먼저 정적 페이지, 동적 페이지의 개념을 이해할 필요가 있습니다.

• 정적 페이지(Static Pages): 내용이 고정되어 있고, 사용자 요청과 무관하게 항상 같은 결과를 제공하는 페이지입니다.
  Ex) HTML, CSS, JavaScript, 이미지 등

• 동적 페이지(Dynamic Pages): 사용자의 요청이나 입력에 따라 그때그때 다른 결과를 생성하여 제공하는 페이지입니다.
  Ex) 게시판 글 보기, 로그인 처리, 검색 결과 페이지 등

Web Server는 정적 콘텐츠 처리 전문가

Web Server는 정적인 콘텐츠 처리에 특화된 서버로, HTML, 이미지, CSS와 같은 파일을 빠르고 효율적으로 제공하는 데 적합합니다.

반면, 사용자 요청에 따라 내용이 달라지는 동적 콘텐츠의 경우, Web Server가 직접 처리하기에는 구조적으로 비효율적입니다. 따라서 이러한 요청은 WAS(Web Application Server)에게 위임하여 처리합니다.

Web Server는 왜 동적 콘텐츠를 처리하지 않을까?

과거에는 Web Server가 CGI(Common Gateway Interface) 방식을 통해 동적 콘텐츠를 처리했습니다. 하지만 CGI는 요청마다 새로운 프로세스를 생성하기 때문에, 리소스 소모가 크고 처리 속도가 느려 성능과 확장성에 한계가 있습니다.

이러한 문제를 해결하기 위해, 현대에는 WAS + Web Container 구조가 표준처럼 사용됩니다. 이 구조는 프로세스를 생성하지 않고 스레드 기반으로 요청을 처리하므로, 훨씬 더 가볍고 빠르며 많은 요청을 효율적으로 처리할 수 있습니다.

Web Server란?

Web Server는 웹 브라우저(클라이언트)로부터 HTTP 요청을 받아, 정적 콘텐츠를 처리하여 응답하는 서버 프로그램입니다.

예를 들어 사용자가 웹 페이지를 요청하면, Web Server는 미리 저장된 HTML, 이미지 등의 파일을 찾아 그대로 전달합니다.
대표적인 Web Server로는 Apache HTTP Server, Nginx, Microsoft IIS 등이 있습니다.

Web Server는 정적 콘텐츠는 직접 처리하고, 동적 콘텐츠 요청은 WAS로 전달한 뒤, WAS가 생성한 결과를 클라이언트에게 다시 전달하는 중계 역할을 수행합니다.

WAS와 Web Container의 관계

앞서 살펴본 것처럼, Web Server는 정적 콘텐츠만 직접 처리하며, 동적 콘텐츠에 대한 요청은 WAS로 전달한다고 설명했습니다. 하지만 보다 정확히 말하자면, 동적 콘텐츠의 실제 처리는 WAS 내부의 Web Container(웹 컨테이너)가 담당합니다.

Web Container는 WAS 내부에 포함된 핵심 구성요소 중 하나로, Servlet, JSP와 같은 동적 웹 기술을 실행하는 환경을 제공합니다.

Servlet: 자바 언어로 작성된 서버용 프로그램으로, 클라이언트의 요청을 받아 처리하고 그 결과를 만들어 내는 역할을 합니다.

JSP(JavaServer Pages): HTML 코드 안에 자바 코드를 삽입하여 동적으로 웹 페이지를 생성할 수 있게 해주는 기술입니다.

• 클라이언트로부터 요청이 들어오면, Web Container는 해당 요청에 맞는 Servlet이나 JSP를 실행합니다.

• 내부적으로 비즈니스 로직을 수행하고, 결과를 HTML과 같은 정적 형태의 콘텐츠로 변환합니다. (웹 브라우저는 정적인 콘텐츠만 해석 가능)

• 변환된 응답은 Web Server를 거쳐 클라이언트(웹 브라우저)로 전달됩니다.

그렇다면 WAS는 무엇을 할까?

WAS는 단순히 Web Container만 제공하는 것이 아니라, 웹 애플리케이션을 실행하는 데 필요한 다양한 기능을 통합적으로 제공합니다.

• Web Container 포함 (Servlet/JSP 실행)

• 보안 기능(인증, 권한 등)

• 세션 및 상태 관리

• 트랜잭션 처리

• 데이터베이스 연결 및 관리

이처럼 WAS는 복잡한 비즈니스 로직을 안정적으로 처리하고, 웹 서비스를 원활하게 운영할 수 있도록 다양한 기능을 함께 제공합니다.

Tomcat은 Web Server인가? WAS인가?

원래 개념상 WAS는 내부에 Web Container를 포함하는 구조이고, Web Server는 별도의 독립된 구성요소입니다.

하지만 대표적인 WAS인 Tomcat은 정적 콘텐츠 요청을 처리할 수 있는 Web Server 기능도 내장하고 있습니다. 즉, Apache HTTP Server 같은 별도의 Web Server 없이도 정적 콘텐츠(HTML, 이미지 등)를 직접 응답할 수 있다는 뜻입니다.

Web Server(Apache HTTP Server)를 사용하는 이유는?

그렇다면, Tomcat이 Web Server 기능까지 내장하고 있는데도 Apache HTTP Server 와 연동하는 경우가 존재하는 이유는 무엇일까요?

1. 성능 최적화

• Apache HTTP Server는 오랜 시간 동안 웹 서버 역할에 집중해서 개발되어 왔기 때문에, 정적인 파일을 빠르고 효율적으로 처리하는 데 최적화되어 있습니다.

• 반면 Tomcat은 주로 동적 콘텐츠를 처리하는 데 초점이 맞춰져 있기 때문에, 정적 콘텐츠 처리에서는 Apache만큼 빠르지 않을 수 있습니다.

• 그래서 보통 정적인 요청은 Apache가 빠르게 처리하고, 동적인 요청만 Tomcat에 넘겨주는 구조를 사용합니다. 이 방식은 각 서버가 잘하는 역할에 집중하게 해 전체적인 처리 속도를 높이고 서버 자원을 효율적으로 사용할 수 있게 해줍니다.

2. 로드 밸런싱

• 웹 서비스가 커지고 사용자 수가 많아지면, 하나의 Tomcat 서버만으로는 모든 요청을 처리하기 어려워집니다.

• Apache HTTP Server는 여러 대의 Tomcat 서버에 요청을 분산시키는 ‘로드 밸런싱’ 기능을 지원합니다.

• 이를 통해 트래픽을 균등하게 나누어 서버 과부하를 방지하고, 한 서버가 다운되어도 다른 서버가 서비스를 계속 제공하게 만들어 시스템의 안정성과 확장성을 높일 수 있습니다.

3. 보안성 향상

• Apache HTTP Server는 다양한 보안 모듈(예: mod_security)을 통해 세밀한 접근 제어나 방화벽 역할을 수행할 수 있습니다.

• SSL 인증서 설정, IP 차단, 요청 필터링 등도 Apache에서 더 쉽게, 그리고 강력하게 구현할 수 있습니다.

• Tomcat 서버를 직접 외부에 노출시키지 않고, Apache가 앞단에서 보안 계층 역할을 하면서 Tomcat을 보호하는 구조가 많이 사용됩니다. 이렇게 하면 보안 위험을 줄이고, 공격으로부터 시스템을 더 안전하게 지킬 수 있습니다.

4. 캐싱

• Apache HTTP Server는 정적 리소스에 대해 캐싱 기능을 제공해, 같은 파일을 여러 번 요청할 때 빠르게 응답할 수 있습니다.

• 캐싱 덕분에 서버가 매번 같은 파일을 디스크에서 읽지 않고도 빠르게 전달할 수 있어서 서버 부하가 줄고 사용자 경험도 개선됩니다.

• Tomcat은 이런 캐싱에 특화된 기능이 적기 때문에, 정적 자원은 Apache가 캐싱해서 처리하는 것이 효율적입니다.

Web Service Architecture의 구조와 흐름

이번에는 클라이언트가 웹 요청을 보낸 뒤, Apache HTTP Server와 Tomcat이 어떻게 협력하여 요청을 처리하고 응답을 전달하는지 그 구조와 흐름에 대해 알아보겠습니다.

1. 클라이언트 요청 (웹 브라우저)

• 클라이언트가 요청을 보냅니다. 예를 들어, http://example.com/index.html 같은 URL을 요청한다고 가정해보겠습니다.

2. Apache HTTP Server

• 클라이언트의 요청이 먼저 Apache HTTP Server에 전달됩니다. Apache는 정적 콘텐츠에 대해 매우 빠르게 응답할 수 있기 때문에, 정적 파일에 대한 요청은 Apache가 처리합니다. Apache는 index.html과 같은 파일을 바로 클라이언트에 전달합니다.

3. Tomcat으로 전달 (동적 요청)

• 만약 요청이 동적 콘텐츠에 관련된 것이라면, Apache는 해당 요청을 Tomcat으로 전달합니다. Apache는 Tomcat으로 프록시 요청을 보냅니다. 이때 mod_proxy나 mod_jk와 같은 모듈이 Apache와 Tomcat 간의 연결을 담당합니다.Tomcat은 Web Container로서, 해당 요청을 Servlet/JSP로 처리하고 응답을 생성합니다.

4. Tomcat 응답 처리

• Tomcat은 동적 콘텐츠 처리 후, 결과를 Apache HTTP Server로 전달합니다.

5. 최종 응답

• Apache는 Tomcat에서 받은 응답을 클라이언트에게 최종적으로 전달합니다.

프록시란?

앞서 설명한 "Apache는 Tomcat으로 프록시 요청을 보냅니다." 여기서 프록시란 무엇일까요?

프록시(Proxy)는 말 그대로 대리인이라는 뜻으로, 클라이언트와 서버 사이에 위치하여 요청이나 응답을 중계하는 중간 서버를 의미합니다.

프록시의 종류

정방향 프록시 (Forward Proxy)

• 클라이언트가 외부 서버에 직접 접근하지 않고, 프록시 서버를 거쳐 요청을 보냅니다.
• 외부 서버는 실제 클라이언트를 알 수 없고, 프록시 서버만 인식합니다.
• Ex) 회사 내부망에서 인터넷 접속 시 사용하는 프록시 서버.

역방향 프록시(Reverse Proxy)

• 클라이언트는 프록시 서버만 알고, 실제 응답을 처리하는 서버(Tomcat 등)는 숨겨집니다.
• Apache가 Tomcat 앞단에서 프록시 역할 수행하는 방식이 여기에 해당합니다.
• 클라이언트는 오직 Apache만 접촉하고, Apache가 요청을 내부 서버(Tomcat 등)로 전달합니다.

Apache와 Tomcat 연결하는 프록시 모듈

Apache가 Tomcat과 연동되기 위해서는 요청을 Tomcat으로 전달하는 프록시 모듈이 필요합니다.
다음은 대표적인 프록시 방식입니다.

mod_jk (AJP 기반)

• AJP(Apache JServ Protocol) 기반 통신을 지원하는 모듈
• AJP는 이진(binary) 프로토콜로 HTTP보다 데이터 전송 속도가 빠르다.
• 설정이 복잡하고 보안 취약점(Ghostcat 등)이 지적되면서 최근에는 사용이 줄어드는 추세입니다.

mod_proxy (HTTP 기반)

• 일반적인 HTTP 기반 프록시 서버처럼 동작하도록 해주는 모듈
• mod_proxy_http와 함께 사용하면 Apache가 받은 HTTP 요청을 Tomcat으로 간편하게 전달할 수 있습니다.
• 설정이 단순하고 다양한 프록시 시나리오(로드 밸런싱, 캐싱 등)를 유연하게 구성할 수 있어 현대적인 웹 시스템에서 더 많이 활용됩니다.

Apache와 Tomcat을 함께 사용할 때의 여러 이점은 사실 프록시 구조 덕분에 가능합니다.
Apache는 클라이언트의 요청을 중간에서 받아 처리하는 프록시 서버 역할을 하며, 이 기능은 mod_proxy 같은 프록시 모듈을 통해 구현됩니다.

결과적으로 각 서버의 특성을 최대한 활용한 Apache와 Tomcat의 조합은 성능 최적화, 보안 강화, 확장성 향상 등의 장점을 갖춘, 강력하고 유연한 웹 서비스 아키텍처를 만들어냅니다.

참고 문서

• Web Server와 WAS의 차이와 웹 서비스 구조
• 웹 서비스 구조 (Web서버 / 웹컨테이너 / WAS) 정리