감사(audit) 훅이 소켓을 느리게 죽인다: PR #146248이 보여준 관측 코드의 메모리 누수 패턴
meta_description: CPython PR #146248은 socket 모듈에서 audit hook을 통해 참조(reference)와 버퍼(buffer)가 새는 문제를 수정했다. 보안/관측을 위해 sys.addaudithook를 붙였는데, 의도치 않게 객체 수명을 늘려 메모리 누수처럼 보일 수 있다. 운영 코드에서 audit hook를 안전하게 쓰는 패턴(최소 정보만 복사, 객체 저장 금지, 버퍼 처리, 샘플링/비동기화)을 정리한다. meta_keywords: python, socket, audit hook, sys.addaudithook, CPython, memory leak, reference leak, buffer leak, observability, security, GC, tracemalloc, weakref, logging, sampling, asyncio, 운영, 메모리 meta_robots: index,follow
운영에서 메모리가 서서히 오르는 서비스를 잡다 보면, 진짜 원인이 비즈니스 로직이 아닌 경우가 꽤 많다.
- 디버그 로그
- 트레이싱/계측(telemetry)
- 보안/감사(audit)
즉, 관측 코드가 시스템을 갉아먹는 케이스.
CPython PR #146248(gh-146245)은 이걸 아주 교과서적으로 보여준다. socket 모듈이 audit hook과 엮이는 과정에서 reference/buffer leak이 생길 수 있었고, 그걸 고쳤다.
이 글은 PR을 번역하려는 글이 아니다. 실무에서 바로 쓰는 관점으로 정리한다.
- audit hook가 왜 메모리 누수처럼 보일 수 있는지
- sys.addaudithook를 붙일 때 뭘 저장하면 위험한지
- 로그를 남기면서도 객체 수명을 늘리지 않는 방법
import sys
def hook(event, args):
# event: 문자열
# args: 튜플(이벤트별로 다양한 객체가 들어올 수 있음)
pass
sys.addaudithook(hook)
여기서 흔한 실수는 로그를 더 잘 남기기 위해 args를 통째로 저장하는 것이다.
# 안 좋은 예: args를 그대로 쌓아두기
seen = []
def hook(event, args):
seen.append((event, args))
이 코드는 작은 테스트에선 멀쩡해 보이는데, 운영에서 터진다.
- args 안에 socket 객체가 들어올 수 있고
- args 안에 버퍼/데이터 조각이 들어올 수 있고
- 심지어 args 안에 다른 큰 객체로 이어지는 참조가 들어올 수 있다
결과적으로 훅이 이벤트를 기록하는 게 아니라, 객체 수명을 연장한다.
PR #146248이 다루는 것도 결국 같은 계열이다. audit hook 경로에서 참조/버퍼가 새면, 사용자 입장에서는 socket이 메모리를 먹는 것처럼 보인다.
3) 안전한 audit hook의 기본 원칙: 객체를 저장하지 말고 값을 저장하라
운영에서 내가 지키는 원칙은 하나다.
훅이 보관하는 건 객체(object)가 아니라 값(value)만.
예를 들어 로깅이 목적이라면, 보통 이 정도면 충분하다.
- event 이름
- 필요한 필드 몇 개(정수/문자열)
- 크기(길이)
- 에러 코드
import sys
import time
def hook(event, args):
# 최소 정보만 추출(문자열/숫자)
# args 자체는 저장하지 않는다
record = {
"ts": time.time(),
"event": str(event),
"argc": len(args),
}
# args 중 일부가 문자열화 과정에서 커질 수 있으니,
# repr()도 길이 제한을 둔다
# (그리고 args 원본은 버린다)
# record["args"] = (repr(args)[:200])
emit(record)
sys.addaudithook(hook)
여기서 emit()은 파일/소켓/OTel 등 무엇이든 될 수 있다. 중요한 건 hook 내부에서 큰 것을 만들지 않는 것.
버퍼/바이너리가 args로 올 때
버퍼가 딸려온다고 의심되면, 내용이 아니라 길이만 남긴다.
def safe_len(x):
try:
return len(x)
except Exception:
return None
def hook(event, args):
sizes = [safe_len(a) for a in args]
emit({"event": event, "sizes": sizes})
이 방식은 무슨 데이터가 오갔는지까지는 모르지만, 운영에서 필요한 건 대개 그게 아니다.
- 터졌다(스파이크가 있다)
- 얼마나 컸다
- 어느 이벤트에서 잦다
이 정도가 대부분의 원인 규명에 충분하다.
4) 메모리 누수인지 관측 부하인지 구분하는 체크리스트
audit hook로 의심되는 상황에서, 나는 이렇게 본다.
1) 훅을 잠깐 끄면(또는 샘플링을 0으로 하면) 메모리 증가가 꺾이나? 2) tracemalloc 상위 스택이 훅/로깅/직렬화 쪽으로 몰리나? 3) 이벤트당 처리 시간이 길어졌나? (로그 I/O, JSON dumps 등)
여기서 1)만으로도 거의 결론이 난다. 관측 코드가 원인이면, 관측을 줄이면 증상이 즉시 완화된다.
그래서 운영 훅은 처음부터 줄일 수 있게 설계해야 한다.
- 샘플링 비율
- 이벤트 화이트리스트
- 비동기 큐(백프레셔)
- 레이트 리밋
5) 실전 패턴: 샘플링 + 큐 + 백프레셔(훅은 얇게)
audit hook에서 모든 걸 다 하면 실패한다. 훅은 얇게, 밖에서 처리한다.
import queue
import random
import sys
import time
q = queue.Queue(maxsize=10_000)
def hook(event, args):
# 1% 샘플링
if random.random() > 0.01:
return
# 얇은 레코드만
rec = {
"ts": time.time(),
"event": str(event),
"argc": len(args),
}
# 큐가 꽉 차면 드롭 (백프레셔)
try:
q.put_nowait(rec)
except queue.Full:
return
sys.addaudithook(hook)
이렇게 하면 훅이 기록 장치가 아니라 신호 생성기가 된다.
그리고 진짜 직렬화/전송은 별도 스레드나 별도 프로세스에서 한다.
이 패턴을 쓰면 PR #146248 같은 사고(훅 경로에서 참조/버퍼가 잡히는 문제)를 운영 코드에서도 상당 부분 피할 수 있다.
6) 결론: audit는 강력하지만, 관측이므로 비용을 가진다
PR #146248은 개발자 입장에서 보면 CPython 내부 수정이지만, 운영자 입장에선 메시지가 선명하다.
- audit hook는 강력한 관측 장치다
- 관측 장치는 코드 경로에 끼어들며, 잘못 쓰면 객체 수명을 바꾼다
- 그래서 훅은 값만 남기고, 객체/버퍼는 잡지 않는 게 안전하다
요약 체크리스트(운영용):
- [ ] args 원본 저장 금지
- [ ] repr/str 길이 제한
- [ ] 내용 대신 길이/카운트 중심
- [ ] 샘플링/화이트리스트
- [ ] 큐 + 드롭(백프레셔)
Keywords
python,socket,audit,sys.addaudithook,observability,security,refleak,buffer,leak,memory,GC,tracemalloc,logging,sampling,queue,backpressure,production,debug,event
References
- CPython PR #146248
- https://github.com/python/cpython/pull/146248
- Diff
- https://github.com/python/cpython/pull/146248.diff
이미지 크레딧/라이선스
- Mobile developer at work (Unsplash).jpg — Parker Byrd / CC0
- https://commons.wikimedia.org/wiki/File:Mobile_developer_at_work_(Unsplash).jpg
- http://creativecommons.org/publicdomain/zero/1.0/deed.en
댓글
댓글 쓰기