요청 흐름과 계층

브라우저 요청이 Web Server, WAS, Application, DBMS를 거쳐 응답으로 돌아오는 전체 흐름을 정리한다.


요청 처리 흐름

이 문서는 전체 미들웨어 지도의 출발점이다.

Client
  -> Web Server / Reverse Proxy
  -> WAS / Servlet Container
  -> Application
  -> DBMS
  -> Response

핵심 정의

웹 요청 처리는 “요청을 받는 계층”, “애플리케이션을 실행하는 계층”, “데이터를 조회하는 계층”으로 나눠서 보면 이해하기 쉽다.

왜 계층을 나누는가

한 서버에 Nginx, Tomcat, DB 클라이언트가 모두 설치되어 있더라도 역할은 분리해서 봐야 한다. 접속이 안 되는 문제, 404, 502, 500, 로그인 세션 문제는 서로 다른 계층에서 발생할 수 있기 때문이다.

계층을 나눠두면 장애 대응도 단순해진다.

외부에서 Web Server까지 오는가?
Web Server에서 WAS까지 가는가?
WAS에서 Application까지 매핑되는가?
Application에서 DB까지 연결되는가?
응답이 다시 같은 경로로 돌아오는가?

계층별 역할

계층역할대표 확인 지점
Client브라우저, 앱, API 호출자URL, DNS, 인증서 신뢰, 쿠키
Web ServerHTTP 요청 수신, 정적 파일, TLS, 프록시listen 포트, server block, VirtualHost, access/error log
WAS애플리케이션 실행, 요청 매핑, 세션Connector, Context, thread, catalina log
Application비즈니스 로직 수행app log, 환경변수, 외부 API
DBMS데이터 저장, 조회, 트랜잭션JDBC URL, 계정, listener, slow query

요청과 응답

요청은 앞에서 뒤로 흐르고, 응답은 뒤에서 앞으로 돌아온다.

Request:
Client -> Web -> WAS -> App -> DB

Response:
DB -> App -> WAS -> Web -> Client

장애를 볼 때는 요청이 어디까지 도달했는지 확인한다. Web Server access log에 기록이 없으면 요청이 Web Server까지 오지 않았을 수 있다. Web Server에는 기록이 있지만 WAS 로그가 비어 있으면 프록시 또는 upstream 연결 문제일 수 있다. WAS 로그에는 예외가 있는데 Web Server에는 500만 보이면 애플리케이션 내부 문제일 수 있다.

상태 코드로 보는 위치

상태자주 보는 위치의미
301/302Web Server, Application리다이렉트
400Web Server, Application요청 형식 문제
401/403Web Server, Application인증/인가 또는 접근 제한
404Web Server, WAS, Application경로 매핑 실패
500Application, WAS내부 예외
502Web Server -> WASupstream 연결 실패
503Web Server, WAS서비스 불가, backend down
504Web Server -> WAS/DBtimeout

공부할 때의 기준

처음부터 제품별 설정을 외우지 않는다. 먼저 다음 질문에 답해본다.

  1. 이 요청은 어느 계층에서 처음 받아지는가?
  2. 다음 계층으로 넘기는 설정은 어디에 있는가?
  3. 실패했을 때 어느 로그에 흔적이 남는가?

이 세 가지가 잡히면 Nginx, Apache, Tomcat 설정은 “제품별 문법”으로 바뀐다. 문법은 다르지만 보는 관점은 같다.

관련 블로그 기록

닫기 전 질문

  • 지금 보고 있는 오류는 Client, Web, WAS, Application, DB 중 어디에서 발생했을 가능성이 높은가?
  • 요청이 다음 계층으로 넘어갔다는 증거는 어떤 로그에서 확인할 수 있는가?
  • 응답이 느리다면 네트워크, WAS thread, DB query 중 무엇부터 볼 것인가?