[Infra Ops] httpd VirtualHost 설정과 리버스 프록시 운영

Apache와 Nginx가 동시 요청을 처리하는 방식은 근본적으로 다릅니다. 이 차이를 모르면 "Apache가 왜 느린가"라는 질문에 답하지 못하고, 레거시 서버를 최적화할 때 잘못된 판단을 하게 됩니다.

확대

Apache는 Multi-Processing Module(MPM) 방식으로 요청을 처리합니다. 어떤 MPM을 쓰느냐에 따라 프로세스/스레드 사용 방식이 달라집니다.

# 현재 사용 중인 MPM 확인
httpd -V | grep -i mpm
# 또는
apachectl -V | grep MPM

# 출력 예시:
# Server MPM:     event
# httpd compiled with: -D APR_HAS_SENDFILE ...

Nginx와의 핵심 차이:

Nginx는 마스터 프로세스 하나와 소수의 worker 프로세스가 이벤트 루프로 수만 개의 연결을 처리합니다. Apache event MPM도 비슷하게 진화했지만, 역사적으로 prefork가 기본이었고 모듈 생태계가 프로세스 기반을 전제로 만들어진 것이 많습니다.

현장에서 Apache가 여전히 쓰이는 이유:

• mod_php: PHP를 Apache 프로세스 내에서 직접 실행 — 공유 호스팅 환경 다수
• mod_jk / mod_proxy_ajp: Tomcat과의 AJP 연결 — 레거시 Java EE 인프라
• 모듈 호환성: mod_rewrite, mod_auth_*, .htaccess — 기존 설정 자산
• 레거시 유지: 수십 년 된 배포를 건드리지 않는 조직 다수

curl http://api.example.com/app/page 한 줄, 또는 브라우저 주소창에 도메인을 치고 Enter를 누르면 화면이 뜹니다. 이 짧은 순간에 Apache 안에서는 연결 수락 → 워커 배정 → VirtualHost 선택 → 모듈 훅 통과 → 핸들러 실행 → 응답이 순서대로 일어납니다. 이 흐름을 단계로 나눠 두면 "왜 403이지", "왜 503이지", "왜 502지"를 특정 단계로 좁혀 진단할 수 있습니다. Apache는 요청을 뭉뚱그려 처리하는 게 아니라 아래 7단계를 순서대로 밟습니다.

[클라이언트]  GET /app/page HTTP/1.1   Host: api.example.com
   │
   ① 리스너 소켓 accept                    (Listen 80/443, MPM이 TCP 연결 수락)
   │
   ② MPM 워커 배정                          (prefork=자식 프로세스 / worker·event=스레드)
   │    → 유휴 워커에 연결을 넘김. 없으면 대기·거부
   │
   ③ 요청 파싱 → VirtualHost 선택           (Host 헤더로 매칭되는 VirtualHost 결정)
   │
   ④ 모듈 훅 체인 통과                       (mod_rewrite → mod_authz → mod_headers ...)
   │    → URL 재작성·접근제어·인증·헤더를 단계별 훅으로 순서대로 처리
   │
   ⑤ 핸들러 결정·실행                        (정적파일 core / mod_proxy / CGI·PHP)
   │
   ⑥ 출력 필터 통과 → 클라이언트로 응답       (mod_deflate 압축, mod_headers 등)
   │
   ⑦ 액세스 로그 기록 → 워커 반납            (keep-alive면 연결 유지하며 다음 요청 대기)
   ▼
[클라이언트]  200 OK   (워커는 풀로 돌아가 다음 요청 대기)

각 단계에서 무슨 일이 일어나고, 막히면 어떤 증상인가:

즉 에러 코드는 어느 단계에서 났는지를 알려주는 지도입니다. 403·401은 ④(접근제어·인증)에서, 404는 ⑤(핸들러가 파일·매핑을 못 찾음)에서, 502·503·504는 ⑤의 프록시 백엔드에서 갈립니다 — 502는 백엔드 연결 실패, 504는 백엔드 응답 타임아웃, 503은 워커 고갈(②) 또는 백엔드 unavailable입니다. 그래서 503을 만나면 먼저 mod_status의 scoreboard에서 BusyWorkers가 MaxRequestWorkers에 닿았는지(②)를 보고, 아니라면 프록시 백엔드 상태(⑤)를 봅니다. 요청이 어느 단계까지 갔는지는 error_log의 단계별 메시지로 좁힙니다.

고객사 서버를 인수인계받아 VirtualHost 파일을 처음 열었을 때 /etc/httpd/conf.d/ 아래 .conf 파일이 10개 이상 있는 경우가 있습니다. 어떤 도메인이 어느 파일에서 처리되는지 모르면 Nginx 설정이라도 짐작하겠지만, Apache 문법이 낯설면 더 막막합니다. VirtualHost를 이해하면 이 구조를 5분 안에 파악할 수 있습니다. 서버 IP가 하나뿐인데 여러 도메인이 돌아가야 할 때, HTTP의 Host 헤더를 보고 요청을 구분하는 것이 Name-based VirtualHost입니다.

VirtualHost는 Apache에서 멀티도메인 서비스를 구현하는 핵심 메커니즘입니다. 클라이언트가 HTTP 요청을 보낼 때 Host 헤더에 도메인을 담아 보내고, Apache는 그 헤더 값을 보고 어느 VirtualHost 블록이 처리할지 결정합니다.

확대

설정 파일 위치:

• CentOS/RHEL: /etc/httpd/conf.d/*.conf
• Ubuntu/Debian: /etc/apache2/sites-available/*.conf (활성화는 a2ensite)

# /etc/httpd/conf.d/example.conf

<VirtualHost *:80>
    # 이 VirtualHost가 응답할 기본 도메인
    ServerName www.example.com
    # 동일 콘텐츠로 응답할 추가 도메인 (별칭)
    ServerAlias example.com

    # 정적 파일을 서빙할 루트 디렉터리
    DocumentRoot /var/www/example

    # DocumentRoot에 대한 접근 제어
    <Directory /var/www/example>
        # -Indexes: 파일 목록 노출 금지 (보안)
        Options -Indexes
        # AllowOverride None: .htaccess 무시 (성능 향상)
        AllowOverride None
        # Require all granted: 모든 클라이언트 허용
        Require all granted
    </Directory>

    # 이 VirtualHost 전용 로그 (전역 로그와 분리)
    ErrorLog /var/log/httpd/example-error.log
    CustomLog /var/log/httpd/example-access.log combined
</VirtualHost>

주요 지시어 설명:

Apache를 단순 파일 서버로만 쓰는 시대는 지났습니다. 레거시 환경에서 Apache는 앞단에서 요청을 받아 뒤에 있는 Tomcat, Node.js, Python 앱으로 프록시하는 역할을 합니다. 이 구조를 구현하는 것이 mod_proxy입니다.

모듈 활성화가 먼저입니다. 모듈 없이 ProxyPass를 쓰면 Invalid command 'ProxyPass' 에러가 납니다.

# CentOS/RHEL: 모듈 설정 파일 확인
cat /etc/httpd/conf.modules.d/00-proxy.conf

# 아래 줄들이 주석 해제되어 있어야 함:
# LoadModule proxy_module modules/mod_proxy.so
# LoadModule proxy_http_module modules/mod_proxy_http.so
# LoadModule headers_module modules/mod_headers.so

# Ubuntu/Debian: a2enmod로 활성화
sudo a2enmod proxy proxy_http headers
sudo systemctl reload apache2

모듈이 활성화됐다면 VirtualHost 블록 안에서 ProxyPass를 사용합니다:

<VirtualHost *:80>
    ServerName api.example.com

    # ProxyPreserveHost On: 원본 Host 헤더를 백엔드로 그대로 전달
    # Off로 하면 백엔드는 127.0.0.1을 Host로 받음
    ProxyPreserveHost On

    # /api/ 로 들어온 요청을 백엔드 8080 포트로 전달
    ProxyPass /api/ http://127.0.0.1:8080/api/

    # 백엔드가 응답에 Location 헤더를 보낼 때 URL을 클라이언트 주소로 재작성
    ProxyPassReverse /api/ http://127.0.0.1:8080/api/

    # 실제 클라이언트 IP와 프로토콜을 백엔드에 전달
    RequestHeader set X-Real-IP "%{REMOTE_ADDR}s"
    RequestHeader set X-Forwarded-Proto "http"
</VirtualHost>

ProxyPass vs ProxyPassReverse:

• ProxyPass: 요청을 백엔드로 포워딩하는 규칙
• ProxyPassReverse: 백엔드 응답의 Location, Content-Location, URI 헤더에 포함된 내부 URL을 외부 URL로 재작성

ProxyPassReverse가 없으면 백엔드가 302 Redirect를 보낼 때 클라이언트가 http://127.0.0.1:8080/api/login 같은 내부 주소로 리다이렉트되어 접근 실패가 납니다.

Apache 로그를 읽지 못하면 장애 원인을 찾는 데 두 배 시간이 걸립니다. 기본 combined 포맷의 각 필드 의미와, 운영에서 반드시 추가해야 하는 응답시간 항목을 익힙니다.

combined 포맷 기본 필드:

%h   %l   %u   %t          "%r"                  %>s  %b
IP  ident user  시각    "메서드 URI 프로토콜"  최종상태 바이트수

실제 로그 예시 한 줄:

203.0.113.42 - jdoe [30/May/2026:14:23:05 +0900] "GET /api/users HTTP/1.1" 200 1523 "https://example.com" "Mozilla/5.0"

응답시간 필드 추가 — 슬로우 리퀘스트 탐지 필수:

# /etc/httpd/conf/httpd.conf 또는 VirtualHost 블록의 CustomLog 수정
LogFormat "%h %l %u %t \"%r\" %>s %b %T %D" combined_time
CustomLog /var/log/httpd/example-access.log combined_time

슬로우 리퀘스트 분석에는 %D를 사용합니다. %T는 1초 미만 요청은 모두 0으로 보여 실용성이 낮습니다.

# 응답시간 기준으로 느린 요청 상위 10개 추출 (%D가 마지막 필드인 경우)
awk '{print $NF, $7}' /var/log/httpd/example-access.log | sort -rn | head -10

Apache 설정을 바꿀 때마다 서비스를 완전히 껐다 켜면 처리 중인 요청이 끊깁니다. graceful은 이 문제를 해결합니다.

확대

# 설정 문법 검사 (서비스 영향 없음)
sudo apachectl configtest
# 또는 동일하게
sudo apachectl -t

# 시작 / 중지 / 완전 재시작
sudo apachectl start
sudo apachectl stop
sudo apachectl restart        # 프로세스 완전 종료 후 재시작 (순간 중단 발생)

# 무중단 재기동 (권장)
sudo apachectl graceful       # 기존 요청 완료 후 worker 교체, 새 설정 적용

# 무중단 중지 (마지막 요청 완료 후 종료)
sudo apachectl graceful-stop

restart vs graceful 비교:

# 운영 서버 표준 절차 (검증 후 무중단 반영)
sudo apachectl configtest && sudo apachectl graceful

# error_log 레벨 설정 (httpd.conf 또는 VirtualHost)
# LogLevel warn  ← 기본값 (debug/info/notice/warn/error/crit/alert/emerg)

MPM의 종류(prefork/worker/event)를 아는 것과, 그 MPM이 '동시에 몇 개의 요청까지' 처리할 수 있는지를 아는 것은 다른 문제입니다. 장애는 대부분 후자에서 터집니다.

• 동시 처리량의 상한은 워커 수입니다: prefork는 자식 프로세스 하나가 요청 하나를 처리하므로 동시 처리량 = 살아 있는 자식 수입니다. worker/event는 자식 프로세스 × ThreadsPerChild 만큼의 스레드가 상한이고, 그 총합을 MaxRequestWorkers(구 MaxClients)가 제한합니다. 이 한도에 닿으면 새 요청은 처리되지 못하고 TCP 백로그에서 대기합니다.
• ServerLimit가 진짜 천장입니다: MaxRequestWorkers를 올려도 ServerLimit(prefork) 또는 ServerLimit × ThreadsPerChild(event/worker)를 넘길 수 없습니다. 두 값을 함께 올리지 않으면 설정 숫자만 크고 실제 상한은 그대로입니다.
• 느린 백엔드가 워커를 오래 붙잡습니다: ProxyPass로 넘긴 백엔드가 느리면 워커는 응답을 기다리는 동안 다른 요청을 받지 못합니다. 백엔드 지연이 곧 워커 고갈로 번지므로, 프록시에는 ProxyPass ... timeout=과 백엔드 자체 타임아웃을 반드시 둡니다.
• prefork에서 keep-alive는 양날의 검입니다: keep-alive로 연결을 유지하면 그 자식은 다음 요청을 기다리며 놀지만 다른 요청에는 못 쓰입니다. 동시 연결이 많은 환경에서 prefork + 긴 KeepAliveTimeout은 워커를 빠르게 소진합니다. event MPM은 keep-alive 유휴 연결을 전용 리스너 스레드가 비동기로 들고 있어 이 문제를 완화합니다 — 그래서 프록시·고동시 워크로드에 event가 유리합니다.

핵심 한계: 워커를 무작정 늘리면 프로세스/스레드가 RAM을 먹어 스왑이 시작되고, 그러면 오히려 전체가 느려집니다. 워커 1개 메모리 × MaxRequestWorkers < 가용 RAM을 먼저 계산한 뒤 올려야 합니다. 실시간 워커 사용률은 mod_status의 scoreboard로 봅니다.