1472 words
7 minutes
[Web]WAS의 구성
01. WAS
WAS의 핵심 컴포넌트들
Concept
- WAS(Web Application Server) : 웹 애플리케이션 서버는 웹 요청을 받아 애플리케이션 코드를 실행하고 응답을 반환하는 서버 플랫폼. 일종의 어플리케이션 런타임 환경을 제공. 단순 정적 파일을 제공하는 웹 서버와 달리, 세션, 보안, 트랜잭션, 리소스 관리 등 애플리케이션 실행에 필요한 공통 인프라 기능을 함께 제공한다.
- Web Server : HTTP 프로토콜을 기반으로 정적 리소스(HTML, CSS, JS, 이미지 등)를 제공하는 서버. 대표적으로 Nginx, Apache httpd가 있으며, TLS 종료, 로드밸런싱, 캐싱, 압축 등 네트워크 경계 처리의 책임을 가짐. 하지만 사용자 애플리케이션 로직을 직접 실행하지는 않음.
- 핸들러(Handler) : Handler/ Controller. 특정 요청 경로와 HTTP 메서드에 매핑되어 실제 비즈니스 로직을 실행하는 함수나 메서드. 예를 들어 /users/
요청을 처리하는 핸들러는 사용자 데이터를 조회하고 Response 객체에 담아 반환한다. - 라우터(Router) : 요청 메서드(GET, POST 등)와 경로(Path)를 분석해 적절한 핸들러를 찾아 실행하는 일종의 매칭엔진. 정적 경로뿐 아니라 파라미터(
), 와일드카드(*rest)를 지원하며, 매칭 실패 시 404, 메서드 불일치 시 405 응답을 반환한다. - 미들웨어(Middleware) : 요청 처리 파이프라인에 삽입되어, 핸들러 전후로 횡단 관심사를 처리하는 모듈. 로깅, 에러 복구, 세션 관리, 인증/인가, CORS, Rate Limiting 같은 기능이 미들웨어로 구현된다. 체인 형태로 조합되며, 재사용성과 확장성이 높다.
- 세션(Session) : 클라이언트와 서버 간 상태를 유지하기 위한 메커니즘이다. 일반적으로 서버는 SID(Session ID)를 쿠키로 발급하고, 이를 키로 삼아 세션 데이터를 메모리나 외부 저장소(Redis 등)에 저장한다. 인증 상태 유지, 장바구니, 사용자 컨텍스트 관리에 활용된다.
- HTTP 요청 파싱(Request Parsing) : TCP 커넥션에서 수신한 ByteStream을 해석해 Method, Path, Headers, Body, Cookies를 구성하는 과정. Content-Length를 기준으로 Body를 읽으며, 쿠키는 Cookie 헤더를 파싱해 key-value 맵으로 변환한다.
- HTTP 응답 작성(Response Serialization) : 핸들러나 미들웨어가 생성한 Response 객체를 HTTP/1.1 형식으로 직렬화해 클라이언트에 반환하는 과정. 상태 코드와 사유 구절(200 OK, 404 Not Found 등), 헤더(Content-Length, Content-Type, Set-Cookie), Body를 순서대로 직렬화.
- Access Log : 요청 처리 결과를 기록하는 기능. 메서드, 경로, 상태 코드, 응답 시간 등을 로그에 남겨 성능 모니터링, 장애 분석, 보안 추적에 활용. 미들웨어로 쉽게 구현할 수 있다.
- Recover(에러 복구) : 핸들러에서 발생하는 예외나 패닉을 잡아 서버 전체가 죽지 않고 500 응답으로 변환하는 기능. 안정적인 서비스 운영을 위해 필수적인 미들웨어.
- 트랜잭션(Transaction) : 여러 리소스(DB, MQ 등)에 걸친 작업을 하나의 단위로 묶어 원자적으로 처리하는 기능. WAS는 보통 트랜잭션 관리 모듈을 포함해 Commit/Rollback을 일관되게 제공하며, 분산 트랜잭션을 위해 XA 같은 프로토콜을 지원하기도 한다.
- WAS에서의 보안 : WAS가 제공하는 보안 기능은 인증(Authentication), 인가(Authorization), 세션 관리, 암호화(TLS/SSL, 데이터 암호화) 등을 포함함.
- 운영/관측(Observability) : WAS는 상태 모니터링, 메트릭 수집, 로그 관리, 헬스체크 엔드포인트(/healthz)를 제공해 운영자가 서버의 상태와 성능을 관리할 수 있도록 한다. Prometheus 메트릭, OpenTelemetry 트레이싱 같은 확장도 가능
- Nginx와 WAS의 경계 : Nginx는 TLS 종료, 정적 파일 제공, 캐싱, 로드밸런싱 같은 네트워크 레벨 기능을 담당하고, WAS는 라우팅, 세션, 비즈니스 로직 실행 같은 애플리케이션 레벨 기능을 담당. 일반적인 아키텍처는 Client → Nginx → WAS → DB/Cache로 구성
Takeaways
Key_Takeaways
- *WAS(Web Application Server) 는 단순히 웹 서버(Nginx, Apache HTTPD)와 다르게, 웹 요청을 받아 애플리케이션 코드를 실행하는 실행 컨테이너다.
- WAS는 기본적으로 HTTP 문자열을 직접 파싱 → Request 객체 생성 → 라우터로 전달 → 매칭된 컨트롤러 실행 → Response 직렬화/전송 과정을 수행
- WAS의 본질은 “요청 → 라우팅 → 애플리케이션 실행 → 응답” 흐름을 책임지는 것이다.
- Nginx는 정적 파일 서빙, TLS 종료, 로드밸런싱/캐싱 등 네트워크 경계 역할에 강하고, 애플리케이션 코드를 직접 실행하지는 않는다.
- 라우팅은 단순한 경로 일치뿐 아니라
파라미터, *rest 와일드카드, 404/405 처리까지 포함해야 한다. - 미들웨어 체인은 횡단 관심사(로깅, 에러 복구, 인증, 세션 등)를 깔끔하게 주입하는 구조적 방법이다.
- 세션은 쿠키 기반(SID)으로 유지하며, 인메모리 저장은 학습용으로는 충분하지만 운영환경에서는 Redis 같은 외부 저장소가 권장된다.
- 응답 작성 시에는 상태 코드/사유구절, Content-Length, Content-Type, Set-Cookie 등 HTTP 규격을 정확히 맞춰야 한다.
Links
- [[nginx]]
- [[asgi]]
[Web]WAS의 구성
https://yjinheon.netlify.app/posts/03be/02was/was/