Alpine Linux에서 Apache(httpd)를 운영하다 보면 “특정 시간대에만 접속이 느려진다”, “간헐적으로 연결이 뚝 끊긴다”, “헬스체크는 정상인데 사용자만 실패한다” 같은 네트워크성 장애가 반복되는 경우가 있습니다. 이런 문제는 앱 코드보다 KeepAlive/커넥션 수명, 파일 디스크립터 한도, 커널 TCP 파라미터, NAT/로드밸런서 동작 같은 운영 요소에서 원인이 나오는 일이 많습니다.
아래는 빠른 복구(임시) → 근본 해결 → 재발 방지 순서로, Alpine + Apache 기준의 점검/조치 흐름입니다.
1) 빠른 복구(임시): 지금 당장 에러율/지연부터 낮추기
원인 분석 전에 서비스 영향부터 줄이는 단계입니다. 목표는 “대기열/리소스 고갈”을 잠깐 풀어주는 것입니다. 단, 임시 조치는 원인을 가릴 수 있으니 변경 기록을 남기고 짧게 가져가세요.
- Apache graceful 재시작: 갑자기 느려졌다면 먼저 graceful로 워커를 정리해 쌓인 커넥션을 털어냅니다. (서비스 중단 최소화)
- MaxRequestWorkers(또는 ServerLimit) 과부하 완화: 동시 처리량이 부족해 대기열이 늘어나는 상황이면, OS 한도(파일 디스크립터/프로세스) 여유가 있을 때에만 임시로 상향합니다.
- KeepAlive 임시 완화: 느린 클라이언트가 KeepAlive로 연결을 오래 잡고 있으면 워커가 고갈됩니다. 임시로 KeepAliveTimeout을 낮추거나 트래픽 급증 시간에 한해 KeepAlive를 꺼서(또는 짧게) 워커 회전을 빠르게 합니다.
- 로그/지표 우선 확보: 복구와 동시에 Apache access/error 로그, 커널 로그, 소켓 상태를 남겨두면 재현이 없어도 원인을 좁힐 수 있습니다.
이 단계에서 중요한 건 “바꾼 설정을 되돌릴 수 있게” 변경 전/후 값을 기록하는 것입니다. 특히 KeepAlive는 성능에 영향을 주기 때문에, 임시로 껐다가 장기적으로 다시 켜는 경우가 많습니다.
2) 증상 분류: 끊김인지, 지연인지, 한도 초과인지부터 나누기
같아 보이는 장애도 원인이 완전히 다릅니다. 아래 중 무엇에 가까운지 먼저 분류하세요.
- 끊김(Reset/Timeout): 브라우저는 “ERR_CONNECTION_RESET”, 모니터링은 502/504/timeout처럼 보일 수 있습니다. 커널/방화벽/NAT 이슈, conntrack, 서버 FD 고갈에서 자주 나옵니다.
- 지연(느림): 응답은 오지만 TTFB가 늘어나거나, 연결/SSL 핸드셰이크가 느려집니다. KeepAlive/워커 고갈, DNS 지연, MTU/패킷 손실, 큐 적체가 의심됩니다.
- 일부 클라이언트만 문제: 특정 ISP/리전에서만 실패하면 MTU, 경로, 로드밸런서 헬스체크/idle timeout 불일치가 흔합니다.
가능하면 장애 시간대에 아래를 함께 확인하세요: 현재 연결 수, TIME_WAIT 비율, Apache scoreboard(상태 페이지), 에러 로그의 패턴(“server reached MaxRequestWorkers”, “Too many open files”).
3) 근본 해결 A: Apache KeepAlive/MPM 설정을 “트래픽 패턴”에 맞추기
간헐적 지연/끊김의 대표 원인 중 하나가 KeepAlive로 워커가 붙잡히는 상황입니다. 특히 짧은 응답이 많고 동시접속이 높은 서비스에서 KeepAliveTimeout이 길면, 요청은 적어도 연결이 오래 살아서 워커가 빨리 소모됩니다.
- KeepAliveTimeout: 길수록 재사용 이점은 있지만, 피크 시간에 워커를 잠식합니다. 보통은 “짧게” 가져가고, 실제 RTT/클라이언트 특성을 보고 조정합니다.
- MaxRequestWorkers: 늘리기 전에 ulimit -n(파일 디스크립터), 메모리, 그리고 MPM(event/prefork/worker) 특성을 먼저 봅니다.
- Timeout/RequestReadTimeout: 느린 클라이언트가 연결을 오래 끌면 전체가 느려집니다. 보호 목적의 타임아웃을 합리적으로 설정합니다.
포인트는 “무조건 KeepAlive를 끄기”가 아니라, 타임아웃/워커/OS 한도가 서로 맞물리도록 설정을 맞추는 것입니다. KeepAlive는 잘 쓰면 이득이 크지만, 운영 패턴에 안 맞으면 장애를 만들기도 합니다.
4) 근본 해결 B: TIME_WAIT 폭증, 포트/FD 고갈, 커널 TCP 파라미터 점검
장애 시간대에 TIME_WAIT가 비정상적으로 많거나, “cannot assign requested address”, “Too many open files” 같은 증상이 보이면 OS/커널 쪽을 봐야 합니다. Alpine도 결국 Linux 커널이기 때문에 방향은 같습니다.
- 파일 디스크립터(ulimit -n): Apache 프로세스가 열 수 있는 FD가 낮으면 커넥션이 끊기거나 accept가 실패합니다. 서비스 단위(오픈 방식)에 따라 제한이 달라질 수 있어 “실제 Apache 프로세스에 적용된 값”을 확인하세요.
- somaxconn / listen backlog: 순간 폭주에 accept 대기열이 짧으면 연결 실패가 늘어납니다.
- TIME_WAIT 자체는 정상: 문제는 비율/지속시간/동반 증상입니다. 짧은 요청이 매우 많거나, upstream/LB와의 연결 방식 때문에 과도하게 생성되기도 합니다.
- conntrack(NAT/방화벽): 동일 서버에서 iptables/nftables NAT를 쓰거나, 앞단 장비에서 conntrack 테이블이 꽉 차면 “간헐적” 드랍이 잘 발생합니다.
이 파트는 튜닝을 바로 때리기보다, 먼저 “한도에 닿았는지”를 증거로 확인하는 게 좋습니다. 예를 들어 FD 고갈이면 로그에 흔적이 남고, conntrack이면 드롭/테이블 사용량이 튈 때가 많습니다. 증거 없이 sysctl을 크게 바꾸면 재현이 더 어려워질 수 있습니다.
5) 재발 방지(운영 관점): 변경 관리 + 모니터링 + 안전장치
같은 장애가 반복되는 가장 흔한 이유는 “그때그때 복구만 하고, 조건(피크 트래픽/배포/배치/외부 연동)이 다시 오면 같은 한도에 걸리기” 때문입니다. 아래 체크리스트를 운영 루틴으로 가져가면 재발률이 확 내려갑니다.
- 설정 변경 기록: Apache(MPM, KeepAlive, timeouts), sysctl, ulimit 변경은 날짜/사유/값을 남기고, 되돌리는 기준(에러율, 지연)을 함께 적어둡니다.
- 피크 시간대 지표: 평균이 아니라 피크에서의 동시 연결 수, TIME_WAIT, FD 사용량, accept queue 관련 지표를 봅니다.
- 로그 경보: “server reached MaxRequestWorkers”, “Too many open files”, connection reset/timeout 패턴을 경보 룰로 만듭니다.
- LB/프록시 idle timeout 정합성: 앞단(Load Balancer, reverse proxy)의 idle timeout과 Apache KeepAliveTimeout이 엇갈리면 반쯤 열린 연결이 늘어 문제를 키울 수 있습니다.
- 용량 가드레일: MaxRequestWorkers를 올릴 때는 메모리/FD/conntrack 한도를 같이 올리거나, 올리지 못하면 오히려 “대기열이 길어져” 지연이 악화될 수 있음을 문서화합니다.
운영 관점에서는 “잘 돌아갈 때” 값을 기준선으로 잡아두는 게 중요합니다. 기준선이 있으면, 다음 장애 때도 TIME_WAIT/FD/워커/에러 로그만 봐도 어디가 병목인지 훨씬 빨리 결론이 납니다.
마무리
Alpine + Apache의 간헐적 끊김/지연은 대개 KeepAlive/워커 고갈, FD 한도, TCP/conntrack 한도 같은 운영 요소가 겹치면서 발생합니다. 그래서 “임시로 살리는 조치”와 “근본 원인(한도에 닿았는지) 확인”을 분리해 진행하는 게 안전합니다.
한 번 해결하고 끝내기보다, 피크 지표와 경보/기준선을 만들어두면 같은 유형의 장애는 재발해도 훨씬 빨리 복구할 수 있습니다.