Audit Log
주요 business transaction이 rollback돼도 attempt, actor, failure reason 같은 감사 기록은 남겨야 할 수 있다. 같은 transaction에 audit write를 넣으면 본 작업 rollback과 함께 사라져 원인 추적이 불가능해진다. 이 패턴은 Transaction Propagation의 REQUIRES_NEW가 로그 기록·독립 알림 전송처럼 기존 트랜잭션과 무관하게 항상 새 트랜잭션을 시작해야 하는 상황의 대표 유스케이스로 꼽히는 지점에서 직접 이어진다.[1]
이 페이지의 적용 조건, 절차, tradeoff는 그 REQUIRES_NEW 유스케이스를 감사 로그 패턴으로 일반화한 이 페이지의 해석이며, 아래 항목들이 source에 개별 문장으로 존재하지는 않는다.[2]
적용 조건
- audit record가 business data와 다른 retention·failure policy를 가진다.
- audit 저장 실패가 본 transaction을 무조건 실패시켜야 하는지 정책적으로 분리할 수 있다.
- compliance, incident investigation, reconciliation에 실제 기록이 필요하다.
해결 절차
- 본 transaction과 audit record의 consistency requirement를 분리한다.
- audit operation을 별도 service boundary에 둔다.
- 필요한 경우
REQUIRES_NEW로 독립 transaction을 시작한다.[1:1] - actor, event type, correlation id, transaction outcome, timestamp를 기록한다.
- audit 실패 정책과 retry/idempotency를 명시한다.
Tradeoff
| 이점 | 비용 |
|---|---|
| 본 transaction rollback 뒤에도 기록 보존 | business data와 audit data가 일시적으로 불일치 가능 |
| 장애·분쟁 조사 용이 | transaction과 connection 사용량 증가 |
| audit retention 정책 분리 | 실패 시 retry와 duplicate record 처리 필요 |
실패 모드
REQUIRES_NEW를 남용하면 connection pressure와 partial-commit 이해 비용이 증가한다.- audit 성공을 business success로 오해하면 잘못된 상태를 기록한다.
- event identity가 없으면 retry가 duplicate audit row를 만든다.
- 민감 데이터를 그대로 남기면 audit 자체가 privacy risk가 된다.
관련
출처
테스트 질문
- 어떤 기록은 본 transaction과 분리돼야 하는가?
- REQUIRES_NEW audit의 consistency cost는 무엇인가?
Transaction.md — "REQUIRES_NEW | 진행 중인 트랜잭션 여부와 상관없이 항상 새로운 트랜잭션을 시작합니다. 기존 트랜잭션은 보류(Suspend)됩니다. | 로그 기록, 독립 알림 전송 등에 활용" ↩︎ ↩︎
출처 매핑 미확인 — audit record의 retention/failure policy 분리, actor·correlation id 기록, idempotency/retry 실패 모드 등 이 패턴의 구체적 절차와 tradeoff 항목은
Transaction.md에 없다. 이 페이지가 REQUIRES_NEW 유스케이스 한 줄을 감사 로그 설계 패턴으로 일반화하며 종합한 내용이며, 별도의 감사 로그 관련 Raw source는 아직 이 볼트에 없다. ↩︎