웹서버·WAS·미들웨어와 배치
웹서버·WAS·리버스 프록시·로드밸런서, 세션·커넥션풀·메시지 미들웨어와 배치 운영을 학습한다.
1. 웹 요청 처리 구조
사용자 브라우저
│ HTTPS
▼
DNS·로드밸런서
│
▼
리버스 프록시·웹서버
│ 정적 파일 또는 동적 요청 전달
▼
WAS·응용 서버
│
├─ DB
├─ 캐시
├─ 메시지 브로커
└─ 외부 API
제품마다 경계가 다를 수 있으므로 역할을 기준으로 구분한다.
2. 웹서버와 WAS
| 구분 | 웹서버 | WAS·응용 서버 |
|---|---|---|
| 주 역할 | HTTP 연결, 정적 파일, 프록시 | 업무 로직, 동적 응답, 트랜잭션 |
| 예시 기능 | TLS 종료, 압축, 캐시, 리버스 프록시 | 세션, DB 연결, API, 애플리케이션 실행 |
| 장애 영향 | 요청 진입 불가·정적 콘텐츠 장애 | 업무 기능·동적 요청 장애 |
최근 제품은 역할이 겹칠 수 있으므로 “웹서버는 정적 파일만 처리한다”는 절대 규칙으로 보지 않는다.
3. 리버스 프록시와 포워드 프록시
포워드 프록시:
내부 사용자 → 프록시 → 외부 서버
사용자 측의 출구·정책·캐시
리버스 프록시:
외부 사용자 → 프록시 → 내부 서버
서버 측의 진입·분산·보호
리버스 프록시의 역할:
- TLS 종료
- 경로·호스트 기반 라우팅
- 로드밸런싱
- 압축·캐시
- 요청 크기·속도 제한
- 내부 서버 주소 은닉
- 보안 헤더와 접근 정책
4. 로드밸런싱
| 방식 | 개념 |
|---|---|
| Round Robin | 서버를 순서대로 선택 |
| Weighted | 서버 용량에 따라 가중치 |
| Least Connections | 연결이 적은 서버 선택 |
| Hash | 클라이언트·키 기반으로 같은 서버 선택 |
┌─► App 1
Load Balancer├─► App 2
└─► App 3
로드밸런서는 단순 분배뿐 아니라 헬스체크로 장애 서버를 제외한다. 헬스체크가 너무 단순하면 프로세스는 살아 있지만 DB 연결이 끊긴 서버를 정상으로 오판할 수 있다.
5. 세션 관리
서버 세션
브라우저 쿠키: SESSION_ID=abc
│
▼
서버 세션 저장소
abc → 사용자ID, 권한, 만료시간
여러 WAS를 사용할 때 로컬 메모리에만 세션을 저장하면 다른 서버로 요청이 이동할 때 세션을 찾지 못할 수 있다.
해결 방법:
- Sticky Session
- 공유 세션 저장소
- 상태를 서버에 최소화한 토큰 기반 구조
- 애플리케이션을 가능한 무상태로 설계
토큰 기반이라고 취소·권한변경·보안통제가 자동 해결되는 것은 아니다.
6. DB 커넥션풀
DB 연결 생성은 비용이 크므로 미리 연결을 만들어 재사용한다.
응용 요청
│
▼
커넥션풀
[사용중][사용중][대기][대기]
│
▼
DB
주요 설정:
- 최소·최대 연결 수
- 연결 대기시간
- 유휴 연결 만료
- 유효성 검사
- 누수 탐지
- 트랜잭션 종료 후 반환
풀을 무조건 크게 만들면 DB의 동시 처리 한계를 넘어 오히려 지연과 장애를 키울 수 있다.
7. 미들웨어
미들웨어는 서로 다른 응용·시스템 사이의 통신과 공통 기능을 제공한다.
- 메시지 지향 미들웨어
- 원격 호출·RPC
- API Gateway·ESB
- 트랜잭션·보안·세션 서비스
- 데이터 변환·라우팅
- 서비스 발견
시스템 A ─ 형식변환·라우팅·보안 ─► 시스템 B
미들웨어
ESB는 중앙 통합 기능을 제공하지만 과도한 중앙 집중은 병목과 변경 복잡성을 만들 수 있다.
8. 메시지 브로커
메시지 큐는 송신자와 수신자의 실행 시점을 분리한다.
Producer → Queue → Consumer
├─ 재시도
├─ 지연 처리
└─ 실패 메시지 보관
장점:
- 비동기 처리
- 부하 완충
- 생산자·소비자 결합 감소
- 재시도·확장
고려사항:
- 중복 전달
- 메시지 순서
- 유실 방지
- 처리 완료 확인
- 독성 메시지와 Dead Letter Queue
- 멱등성
9. 배치 처리
배치는 대량 데이터를 일정 시간이나 조건에 따라 일괄 처리한다.
스케줄 시작
↓
입력 파일·대상 데이터 확인
↓
작업 분할·읽기
↓
변환·검증·업무 처리
↓
저장·집계·출력
↓
건수 대사·상태 기록
↓
성공 또는 재처리
배치 설계의 핵심:
- 재실행 가능성
- 체크포인트
- 중복 처리 방지
- 대량 커밋 전략
- 오류 건 격리
- 처리 건수 대사
- 업무 마감시간
- 선행·후행 작업 의존성
10. 배치 장애와 재처리
| 상황 | 대응 |
|---|---|
| 일부 건 오류 | 오류 건 분리 후 정상 건 계속 처리 여부 결정 |
| 중간 실패 | 체크포인트부터 재시작 |
| 중복 실행 | 실행 ID·업무키·멱등성으로 방지 |
| 파일 재수신 | 파일명뿐 아니라 해시·업무일자·순번 검증 |
| 후행 작업 실패 | 선행 결과 상태 유지 후 후행만 재처리 가능하게 설계 |
단순히 처음부터 다시 실행하면 중복 청구·중복 이체 같은 업무 사고가 발생할 수 있다.
11. 운영 점검 포인트
- 요청량·응답시간·오류율
- WAS 스레드·큐·메모리·GC
- 커넥션풀 사용률·대기시간
- 외부 API 지연·타임아웃
- 메시지 적체량·재시도·DLQ
- 배치 처리건수·소요시간·미처리건
- 로드밸런서 헬스체크
- 세션 저장소 상태
12. 요청 경로와 병목 위치
Client → LB/Reverse Proxy → Web Server → WAS Thread Pool
│
├→ DB Connection Pool → DB
└→ Message Broker → Worker
스레드 풀을 크게 늘려도 DB 연결 풀이 작으면 대기열만 길어질 수 있고, DB 연결 풀을 과도하게 늘리면 DB 동시성·메모리를 압박한다. 각 큐의 도착률, 서비스율, 대기시간과 timeout을 함께 조정한다.
13. 연결 풀 계산과 누수
동시 실행 스레드 100개 중 최대 40%만 DB를 사용한다면 시작점으로 40개 안팎을 검토할 수 있지만, 쿼리 시간·트랜잭션 길이·DB 수용량·다중 인스턴스 총합을 반영해야 한다.
전체 DB 연결 = 인스턴스 수 × 인스턴스별 pool max
인스턴스 8개가 각각 50개를 열면 DB에는 최대 400개가 연결된다. timeout, max lifetime, validation query와 누수 탐지 로그가 필요하다.
14. 메시지 전달과 멱등 처리
at-least-once 브로커에서는 처리 성공 후 ACK 전 장애가 나면 같은 메시지가 다시 전달될 수 있다.
메시지 수신 → idempotency key 중복 확인 → 업무 변경+처리이력 원자적 기록 → ACK
ACK를 업무 처리 전에 보내면 장애 시 메시지를 잃을 수 있다. exactly-once라는 제품 기능도 외부 부수효과까지 자동으로 한 번만 보장하는지 범위를 확인한다.
15. 배치 checkpoint와 재시작
Reader → Processor → Writer
chunk 1 commit
chunk 2 commit
chunk 3 실패
재시작: 완료 checkpoint 다음부터 처리
재처리 안전성을 위해 자연키·업무키 기반 upsert, 처리 이력, 출력 파일 임시 이름 후 원자적 rename 등을 사용한다. 실패 레코드를 무조건 건너뛰면 전체 정합성을 깨뜨릴 수 있으므로 skip 정책과 한도를 명시한다.
16. 운영형 상태 판정
- HTTP 200이지만 의존 DB가 끊긴 상태는 심층 readiness에 실패할 수 있음
- 로컬 메모리 세션은 수평 확장·장애조치 시 세션 유실 또는 sticky 의존을 만듦
- retry는 timeout보다 길게 대기하거나 무제한으로 중첩되지 않게 budget을 둠
- poison message는 별도 DLQ와 원인 분석·재처리 절차가 필요
확인 문제
- 8개 WAS 인스턴스가 pool max 50이면 최대 DB 연결 합은?
- 업무 처리 전에 메시지 ACK를 보내면?
- at-least-once 소비자의 기본 방어는?
- 배치 checkpoint의 목적은?
- readiness 실패와 liveness 실패의 차이는?