Apache SSL에서 주기적으로 속도가 느리다면

5분마다 느려지는 이미지 서버, 범인은 SSLSessionCache였습니다

핵심 요약

• 증상 — SSL을 전면 적용한 뒤 분리해 둔 이미지 서버가 주기적으로 매우 느려짐
• 헛짚은 곳 — Timeout, KeepAliveTime 등을 바꿔봤지만 소용없었음
• 원인 — 느려지는 주기가 정확히 5분. 아파치 설정의 SSLSessionCacheTimeout 300과 같은 값이었고, 세션 캐시 백엔드가 dbm으로 잡혀 있었음
• 조치 — 세션 캐시 설정을 변경한 뒤 스트레스 테스트에서 문제 재현되지 않음
• 남는 교훈 — 증상에 주기가 있으면, 그 주기와 같은 숫자를 설정에서 찾으면 된다

---

이번에 참여해서 진행하고 있는 프로젝트 요구사항 중 하나가 보안서버를 적용하는 것이었습니다.

그런데 몇 가지 이슈 때문에 전체에 SSL을 적용하는 것으로 했습니다.

그리고 몇 가지 우여곡절 끝에 Application이 있는 서버와 이미지 서버를 분리하기로 했습니다.

그런데 이미지 서버가 주기적으로 매우 느려지는 현상을 발견했습니다.

Timeout도 바꿔보고 KeepAliveTime 등도 바꿔봤지만 소용이 없었는데요.

그래서 아파치 설정을 변경하던 중에 이렇게 되어 있는 것을 발견했습니다.

#SSLSessionCache        none
#SSLSessionCache        shmht:/usr/********/apache2/logs/ssl_scache(512000)
#SSLSessionCache        shmcb:/usr/********/apache2/logs/ssl_scache(512000)
SSLSessionCache         dbm:/usr/********/apache2/logs/ssl_scache
SSLSessionCacheTimeout  300

그리고 그 주기가 5분이라는 것을 알았습니다. ^^;;

SSLSessionCacheTimeout 300 — SSL 세션 캐시를 남기는 시간이 300초, 즉 5분이었던 거죠. T.T

그래서 맨 위에 있는 none의 주석을 풀고, 아래에 있는 두 줄(캐시 파일 설정과 시간 설정)을 주석 처리했습니다.

SSLSessionCache         none
#SSLSessionCache        shmht:/usr/********/apache2/logs/ssl_scache(512000)
#SSLSessionCache        shmcb:/usr/********/apache2/logs/ssl_scache(512000)
#SSLSessionCache        dbm:/usr/********/apache2/logs/ssl_scache
#SSLSessionCacheTimeout 300

그리고 아파치를 다시 켜서 스트레스 테스트를 진행했는데, 끄떡없는 것을 발견했습니다.

참고로 이 스트레스 테스트를 돌리려고 5일 전에 ab를 SSL 되게 다시 컴파일했습니다. 기본으로 컴파일된 ab는 https 주소를 못 치거든요.

👉 ab로 HTTPS를 테스트할 수 없을 때 — "SSL not compiled in; no https support"

저거 발견하기 전에 삽질한 걸 생각하면 T.T

다른 분들은 이런 삽질을 좀 안 하셨으면 해서 적어 봅니다.

좋은 하루 되십시오.

이 글은 스프링노트에서 작성되었습니다.

---

추기 — 17년 만에 다시 봅니다 (2026년)

이 글은 2009년에 쓴 글입니다.

지금 다시 본다면 none으로 끄는 대신 shmcb로 바꿨을 것입니다.

당시엔 "캐시를 껐더니 해결됐다"까지만 알았습니다. 지금 보면 문제는 캐시 자체가 아니라 dbm 백엔드였습니다.

• dbm은 mod_ssl 기본 설치에 포함된 세션 캐시 중 가장 느리고, 플랫폼에 따라 불안정한 것으로 알려져 있습니다
• shmcb는 공유 메모리 기반 순환 버퍼를 사용하는 권장 옵션이며, dbm 대비 약 30% 개선되었다는 벤치마크 보고가 있습니다

그리고 공교롭게도 그 shmcb 줄이 바로 위에 주석 처리된 채로 있었습니다. 답이 두 줄 위에 있었던 셈이죠. T.T

SSLSessionCache         shmcb:/usr/********/apache2/logs/ssl_scache(512000)
SSLSessionCacheTimeout  300

shmcb를 쓸 때는 캐시가 너무 차지 않게 두는 것이 좋습니다. 사용률이 75%에서 80%를 넘어서면 성능이 떨어지기 시작하고, 세션 하나가 대략 140바이트에서 150바이트 정도이므로 기본값 512000바이트면 동시 세션 3,500개 정도가 기준이 됩니다.

이 글을 읽고 오해하지 마셔야 할 것

none으로 끄면 세션 재사용이 사라져 매 연결마다 full handshake를 하게 됩니다. 보통은 오히려 손해인 방향입니다.

당시 대상이 이미지 서버였고 keep-alive로 연결 재사용이 많았기 때문에 손해가 크지 않았고, 그래서 스트레스 테스트도 통과했던 것으로 보입니다.

그러니 "세션 캐시를 끄면 빨라진다"로 이해하지는 마세요. 정확히는 "dbm 백엔드가 문제였고, shmcb로 바꾸는 것이 정석"입니다.

그래도 이 글에서 안 바뀌는 것

조치 방법은 지금 기준으로 다듬을 게 있지만, 진단 방법은 17년이 지나도 그대로 유효합니다.

증상에 주기가 있으면, 그 주기와 같은 숫자를 설정에서 찾아라.

5분마다 느려졌고, 설정에 300이 있었습니다. 이 매칭 하나로 끝났습니다. Timeout과 KeepAliveTime을 아무리 만져도 안 되던 문제였고요.

성능 문제에서 주기성은 가장 강력한 단서입니다.

• 부하량에 비례해서 느려지면 → 용량 문제
• 부하와 무관하게 일정 간격으로 느려지면 → 거의 항상 어딘가에 설정된 타이머

캐시 만료, 세션 정리, 배치 실행, GC, 로그 로테이션 — 후보는 많지만 찾는 방법은 하나입니다. 주기를 재고, 그 숫자를 설정 파일에서 grep 하세요.

이 이야기는 5일 전에 시작됐습니다

돌아보면 이 문제를 잡기까지 순서가 이랬습니다.

측정 도구가 안 됨 → 도구를 되게 만듦 → 측정 → 진단 → 해결 → 재검증

ab로 https를 못 쳐서 그것부터 해결한 게 9월 3일, 그걸로 이 문제를 잡은 게 9월 8일이었습니다. 측정 도구가 대상과 같은 조건을 못 만들면 측정 자체가 성립하지 않으니까요.

👉 ab로 HTTPS를 테스트할 수 없을 때 — "SSL not compiled in; no https support"

---

참고

• ab로 HTTPS를 테스트할 수 없을 때 (2009년, 이 글의 앞 이야기)
• Apache HTTPD Wiki — SSLSessionCache
• Apache mod_ssl — SSLSessionCache 지시자
• Which SSLSessionCache to use for best performance? (modssl-users)