Apache 리드·아키텍트 트러블슈팅 면접

먼저 server-status를 통해 현재 worker 상태와 요청 큐를 확인하여 MaxRequestWorkers 한계 도달 여부를 파악합니다. 동시에 시스템 리소스(CPU, 메모리, 네트워크)를 모니터링하여 병목 지점을 식별합니다. access_log와 error_log를 분석하여 특정 URL이나 패턴에서 응답 지연이 발생하는지 확인합니다. 즉시 조치로는 KeepAliveTimeout을 단축하여 유휴 연결을 빠르게 해제하고, 필요시 MaxRequestWorkers를 임시로 증가시킵니다. 백엔드 애플리케이션의 슬로우 쿼리나 외부 API 타임아웃이 원인이라면 ProxyTimeout 설정을 조정하고 문제 요청을 차단합니다. 재발 방지를 위해 APM 도구를 통한 실시간 모니터링 체계를 구축하고, 오토스케일링 정책과 Circuit Breaker 패턴을 도입합니다.

먼저 mod_status의 ExtendedStatus를 활성화하여 각 요청의 처리 시간과 상태를 실시간으로 모니터링합니다. access_log에 %D(마이크로초) 또는 %T(초) 지시자를 추가하여 정확한 응답 시간을 기록하고, 지연이 발생하는 특정 URI 패턴을 식별합니다. strace나 perf를 사용하여 Apache 프로세스가 시스템 콜 레벨에서 어디에 시간을 소비하는지 추적합니다. DNS 조회 지연 가능성을 확인하기 위해 HostnameLookups 설정을 점검하고, 백엔드 연결 시 DNS 캐싱 상태를 검증합니다. 디스크 I/O 지연 가능성을 위해 로그 파일 쓰기 패턴과 NFS/SAN 스토리지의 레이턴시를 분석합니다. 해당 시간대의 cron 작업, 백업 프로세스, 로그 로테이션 등 시스템 레벨의 스케줄 작업과의 상관관계를 조사합니다.

먼저 /proc/[pid]/status와 smem 도구를 사용하여 Apache 프로세스별 메모리 사용 패턴을 시계열로 모니터링합니다. MaxRequestsPerChild(또는 MaxConnectionsPerChild)를 설정하여 일정 요청 처리 후 worker를 재시작하도록 하여 임시 완화합니다. valgrind나 AddressSanitizer를 개발 환경에서 사용하여 메모리 누수 지점을 식별하고, 프로덕션에서는 경량 도구인 mtrace를 활용합니다. 로드된 모듈 목록을 검토하여 서드파티 모듈(mod_php, mod_perl 등)의 버전과 알려진 메모리 누수 이슈를 확인합니다. 특히 mod_php 사용 시 PHP 애플리케이션 코드의 메모리 누수 가능성을 프로파일링하고, 필요시 PHP-FPM으로 분리하여 Apache와 격리합니다. 장기적으로는 prefork에서 event MPM으로 전환하고, 애플리케이션을 별도 프로세스로 분리하는 아키텍처 개선을 고려합니다.

먼저 Apache의 SSL 에러 로그를 확인하여 handshake 실패 시 구체적인 에러 메시지와 클라이언트 정보를 수집합니다. openssl s_client 명령으로 다양한 TLS 버전(-tls1, -tls1_1, -tls1_2)을 테스트하여 어떤 프로토콜에서 연결이 실패하는지 확인합니다. SSLProtocol 설정을 검토하여 TLSv1이나 TLSv1.1을 지원하는지 확인하고, 구형 기기 지원이 필요하다면 보안 위험을 평가한 후 제한적으로 활성화합니다. SSLCipherSuite 설정에서 너무 제한적인 암호화 스위트만 허용하고 있는지 확인하고, Mozilla SSL Configuration Generator를 참고하여 'Intermediate' 수준의 설정을 적용합니다. SSL Labs의 Server Test를 통해 다양한 클라이언트와의 호환성을 검증하고, 비즈니스 요구사항에 따라 보안과 호환성의 균형점을 찾습니다. 장기적으로는 구형 기기 사용자 비율을 모니터링하고 단계적 지원 종료 계획을 수립합니다.

먼저 mod_proxy_balancer의 헬스체크 기능을 활성화하여 백엔드 서버의 가용성을 주기적으로 확인합니다. ProxyPass 지시자에 retry 파라미터를 설정하여 실패한 서버를 일정 시간 동안 제외하고, connectiontimeout과 timeout 값을 적절히 조정하여 빠른 실패 감지가 가능하도록 합니다. mod_proxy_hcheck 모듈을 사용하여 능동적인 헬스체크를 구현하고, 백엔드에 전용 헬스체크 엔드포인트(/health)를 만들어 실제 애플리케이션 상태를 확인합니다. balancer-manager를 활성화하여 실시간으로 백엔드 서버 상태를 모니터링하고 필요시 수동으로 서버를 비활성화할 수 있도록 합니다. 로드밸런서 알고리즘을 byrequests나 bybusyness로 설정하여 응답이 느린 서버로의 요청을 자동으로 줄입니다. 외부 모니터링 시스템과 연계하여 백엔드 장애를 감지하면 Apache 설정을 동적으로 변경하거나 DNS 페일오버를 트리거하는 자동화 스크립트를 구축합니다.

먼저 access_log를 분석하여 에러가 발생하는 URI 패턴, User-Agent, 소스 IP 분포를 파악합니다. awk나 grep을 사용하여 404/403 에러의 상위 요청 경로와 빈도를 추출하고, 특정 패턴(예: /.env, /wp-admin 등 취약점 스캐닝)이 있는지 확인합니다. 소스 IP를 분석하여 특정 IP 대역에서 집중적으로 발생하는지 확인하고, whois 조회로 출처를 파악합니다. 정상 트래픽과 비교하여 User-Agent가 비정상적이거나(봇, 스크래퍼) Referer가 없는 요청의 비율을 확인합니다. 만약 외부 공격이나 봇으로 판단되면 mod_security나 fail2ban을 통해 해당 IP를 차단하고, rate limiting을 적용합니다. 정상 서비스의 설정 변경(예: 외부 CDN이나 파트너사의 URL 변경)이 원인이라면 해당 팀과 커뮤니케이션하여 조정합니다. 재발 방지를 위해 WAF 규칙을 강화하고, 에러율 임계값 기반 알림을 설정합니다.

먼저 lsof나 /proc/[pid]/fd를 통해 Apache 프로세스가 실제로 열어둔 파일 디스크립터 수와 종류를 확인합니다. 특정 타입(소켓, 파일, 파이프)이 비정상적으로 많은지 파악하고, 오래된 CLOSE_WAIT 상태의 소켓이 쌓여있는지 netstat으로 확인합니다. systemd 환경이라면 서비스 유닛 파일의 LimitNOFILE 설정을 확인하고, ulimit -n 설정이 실제 Apache 프로세스에 적용되는지 검증합니다. KeepAlive 설정이 과도하게 높아 연결이 오래 유지되는지 확인하고, MaxKeepAliveRequests와 KeepAliveTimeout을 조정합니다. 백엔드와의 프록시 연결에서 connection pooling이 제대로 작동하지 않아 연결이 누적되는지 확인하고, ProxyPass의 ttl과 max 파라미터를 검토합니다. 로그 파일이 과도하게 많이 열려있다면 로그 로테이션 설정을 점검하고, piped logging 방식을 고려합니다. 근본적으로는 Apache의 연결 처리 모델을 검토하여 event MPM 사용 여부와 적절한 worker 설정을 재평가합니다.

먼저 문제가 되는 파일의 HTTP 응답 헤더를 curl -I로 확인하여 Cache-Control, ETag, Last-Modified, Expires 헤더 값을 검증합니다. mod_cache의 CacheIgnoreCacheControl, CacheIgnoreHeaders 설정이 백엔드의 캐시 제어 헤더를 무시하도록 설정되어 있는지 확인합니다. CacheDefaultExpire와 CacheMaxExpire 값이 과도하게 크게 설정되어 있어 강제로 오래된 캐시를 유지하는지 점검합니다. 백엔드 애플리케이션이 파일 변경 시 적절한 캐시 무효화 헤더(Cache-Control: no-cache 또는 새로운 ETag)를 전송하는지 확인합니다. htcacheclean을 사용하여 수동으로 캐시를 정리하거나, 특정 URL 패턴에 대해 PURGE 메서드를 지원하도록 구성합니다. CDN이나 중간 프록시가 있다면 다층 캐싱 구조에서 각 레이어의 캐시 정책을 일관되게 관리합니다. 장기적으로는 파일명에 버전이나 해시를 포함하는 cache busting 전략을 도입하여 캐시 무효화 의존성을 줄입니다.

즉시 조치로 RequestReadTimeout 지시자를 설정하여 헤더와 바디 읽기에 타임아웃을 적용하고, 느린 요청을 빠르게 종료합니다. mod_reqtimeout을 활성화하여 최소 데이터 전송 속도를 강제하고, 이를 만족하지 못하는 연결을 차단합니다. LimitRequestFields와 LimitRequestFieldSize를 적절히 제한하여 과도한 헤더 전송을 방지합니다. MaxRequestWorkers와 ServerLimit을 재검토하여 공격 트래픽이 모든 worker를 점유하지 못하도록 하되, 정상 트래픽 처리를 위한 여유를 확보합니다. mod_evasive나 mod_security를 활성화하여 동일 IP에서의 과도한 요청을 자동으로 차단하고, fail2ban과 연동하여 IP 레벨 차단을 수행합니다. 네트워크 레벨에서 iptables나 nftables로 connection rate limiting을 적용하고, SYN cookies를 활성화합니다. 장기적으로는 CDN이나 전용 DDoS 방어 서비스를 도입하여 공격 트래픽이 오리진 서버에 도달하기 전에 필터링하고, event MPM으로 전환하여 더 많은 동시 연결을 효율적으로 처리합니다.

먼저 apachectl configtest(또는 httpd -t)를 모든 서버에서 실행하여 설정 파일의 문법 오류를 확인합니다. error_log를 상세 레벨(LogLevel debug)로 설정하여 500 에러 발생 시 구체적인 원인을 파악합니다. 서버 간 환경 차이(OS 버전, 설치된 모듈, 파일 경로)를 확인하여 일부 서버에서만 특정 지시자가 작동하지 않는 이유를 찾습니다. Include 지시자로 분리된 설정 파일들이 모두 정상적으로 로드되는지, 파일 권한이나 SELinux 컨텍스트 문제가 없는지 검증합니다. 안전한 배포 프로세스로 Canary 배포를 도입하여 소수 서버에 먼저 적용하고 모니터링 후 점진적으로 확대합니다. 설정 변경 전 백업을 자동으로 생성하고, 문제 발생 시 즉시 롤백할 수 있는 스크립트를 준비합니다. CI/CD 파이프라인에 설정 검증 단계를 추가하여 문법 오류뿐 아니라 보안 정책 위반, 성능 설정 이슈를 사전에 감지합니다. Ansible, Chef 등 설정 관리 도구의 dry-run 모드를 활용하여 실제 적용 전 변경 사항을 검토합니다.