? SLAs 는 뭐고 뭐가 어떻게 달라? 증권사 도메인을 예를 들어서 알려줄래 ?
1. SLA란 무엇인가?
SLA(Service Level Agreement) = “이 시스템이 어느 수준까지 정상적으로 작동할 것을 보장하겠다”는 서비스 품질 계약 지표이다.
보통 다음을 포함한다:
- 가용성(Availability %) — 99.9%, 99.99% 같은 숫자
- 지연 시간(Latency) — 응답이 몇 ms 안에 나와야 하는가
- 처리량(Throughput) — 초당 요청 수
- 오류율(Error rate) — 허용되는 실패율
- RPO/RTO — 장애 시 데이터 손실 허용 범위, 복구 시간
즉, "이 기능은 어느 수준의 품질/속도/안정성을 가져야 하는가"를 숫자로 약속하는 것.
2. 왜 API / 체결(매칭) / 원장은 서로 다른 SLA를 가지는가?
이 세 시스템의 역할과 성격이 완전히 다르기 때문에 요구되는 품질과 성능 기준이 전혀 다르다.
아래 비교가 가장 이해가 잘 된다.
3. API, 매칭 엔진, 원장의 SLA 비교
3.1 API Layer (입력 검증·인증·Rate-Limit)
역할:
사용자 요청 받기, 인증, 파라미터 검증, 기본 비즈니스 검증, Rate limit, 트래픽 보호.
SLA 특징:
- 지연(latency): 수십 ms 내면 충분
예: 20~50ms - 가용성: 높지만 초고가용까지는 아님
예: 99.9% - 장애 복구: 빠르게 롤백해도 괜찮음
- 배포: 하루에도 여러 번 배포 가능
- 데이터 일관성: 강하게 요구되지 않음 (API 서버는 stateless)
이유:
API는 단순히 요청을 받아 큐나 매칭 엔진으로 전달하는 게 메인이다.
절대 초저지연 영역이 아님.
3.2 체결 엔진(Matching Engine)
역할:
주문을 순서대로 받고, 오더북을 조작하고, 매칭을 확정한다.
(증권사/거래소의 핵심)
SLA 특징:
- 초저지연!
수 마이크로초(us) ~ 수 밀리초(ms) 단위 요구
예: 50µs ~ 1ms - 가용성 최상급
99.99% 이상 - 장애 복구:
실시간 복구, 상태 복제, in-memory snapshot - 배포:
함부로 배포 못함 (1~2달에 한 번, 심지어 야간)
배포 전에 수십 차례 시뮬레이션 필요 - 데이터 일관성:
오더북은 절대 틀리면 안 됨 → Strong Consistency
이유:
체결 엔진은 돈이 걸린 로직이며 지연이 단 5ms만 늘어도 고객이 다른 거래소로 간다.
장애가 나도 절대 오더북 깨지면 안 됨.
3.3 원장(Ledger)
역할:
거래 내역, 체결 결과, 잔고 변동을 영속적으로 저장하는 최종 시스템.
은행의 Account Book 같은 역할.
SLA 특징:
- 지연: 반드시 초저지연은 아님
예: 5~20ms 정도 허용 - 가용성: 매우 높음
99.99% 또는 그 이상 - 핵심은 데이터 무결성, 원자성, 정합성
직전 1건이라도 손실되면 법적 문제 발생 - 장애 복구:
RPO = 0(단 1개의 트랜잭션도 잃으면 안 됨)
동기 복제, 트랜잭션 로그 기반 복구 - 배포 주기:
느림. 변경되면 계정/잔고 모델 전체 검증 필요
(1~2개월 단위)
이유:
원장은 속도보다 안정성·영속성·법적 기준이 최우선이다.
잘못 저장되면 회사 망함.
4. 한눈에 보는 SLA 비교표
| 기능 | 지연 시간 요구 | 가용성 | 장애 복구 방식 | 배포 주기 | 최우선 목표 |
|---|---|---|---|---|---|
| API Layer | 20–50ms OK | 99.9% | Blue/Green, 빠른 롤백 | 자주 배포 가능 | 트래픽 방어, 안정적 요청 처리 |
| 매칭 엔진 | µs ~ sub-ms | 99.99% 이상 | In-memory snapshot, 복제, 실시간 failover | 매우 제한적 | 초저지연, 순서 보장, 정합성 |
| 원장(Ledger) | 5–20ms | 99.99% | 동기복제, Write-Ahead Log, RPO=0 | 느림 | 원자성·무결성·영속성 |
5. 결론: 왜 분리해야 하는가?
API, 매칭 엔진, 원장은 각각 목표하는 SLA 자체가 완전히 다르기 때문이다.
- API는 트래픽을 잘 받고 많이 배포해야 한다.
- 매칭 엔진은 1µs 지연도 조심해야 하므로 코드가 더럽더라도 절대 안정적으로 유지해야 한다.
- 원장은 속도보다 정확성이 우선이다.
그러므로 하나의 모놀리식으로 합치면:
- API의 자주 배포 → 매칭 엔진의 안정성을 깨뜨림
- 원장의 무거운 트랜잭션 → 매칭 엔진의 지연을 폭발시킴
- 장애 복구 전략도 서로 다름
즉, “서로 다른 SLA = 서로 다른 기술적 성격 = 반드시 분리해야 하는 아키텍처”다.
기술정리