03. Latency Throughput Availability 상세

이 문서를 통해 아래 질문들에 답할 수 있게 됩니다.

• Latency, throughput, availability를 서로 다른 요구사항으로 어떻게 계산하는가?
• p95 latency budget, peak 처리량, 월 장애 허용 시간을 어떻게 설계 판단으로 연결하는가?
• 이 세 지표는 성능, 장애 격리, 운영 복잡도 사이에 어떤 trade-off를 만드는가?

개요

Latency, throughput, availability는 모두 “성능”이라는 한 단어로 묶기 쉽다.

하지만 세 지표는 서로 다른 질문에 답한다.

Latency는 한 요청이 얼마나 빨리 끝나는가를 본다.

Throughput은 단위 시간에 얼마나 많은 일을 처리하는가를 본다.

Availability는 사용자가 필요한 시간에 기능을 사용할 수 있는가를 본다.

이 셋을 구분하지 않으면 “빠른데 자주 실패하는 시스템”이나 “처리량은 높은데 개별 요청이 너무 느린 시스템”을 만들 수 있다.

Latency budget

Latency 목표는 전체 숫자보다 budget으로 나눠야 한다.

알림 캠페인 접수 API 목표가 p95 300ms라고 하자.

Gateway/Auth = 30ms
Spring validation = 30ms
DB transaction = 80ms
Outbox write = 40ms
Serialization/network = 40ms
Margin = 80ms
Total = 300ms

이 budget 안에 provider API 호출 1초를 넣는 것은 불가능하다.

따라서 발송 provider 호출은 접수 API 밖으로 빼고 queue나 worker로 넘겨야 한다.

이 선택은 접수 latency를 낮추지만 발송 완료 정합성을 지연시킨다.

Throughput 계산

Throughput은 평균이 아니라 peak와 burst를 봐야 한다.

캠페인 대상자 = 1,000,000명
발송 완료 목표 = 30분
필요 처리량 = 1,000,000 / 1,800s = 약 556 messages/sec
provider limit = 300 messages/sec
필요 전략 = provider 추가, 발송 시간 확대, throttling, queue buffering

처리량 요구가 provider limit보다 크면 내부 worker를 늘려도 해결되지 않는다.

오히려 retry와 timeout이 늘어 장애를 증폭할 수 있다.

Throughput 계산은 병목이 내부 CPU인지, DB인지, broker인지, 외부 provider인지 드러내야 한다.

Availability 계산

Availability는 퍼센트로 쓰면 좋아 보이지만 운영 시간으로 바꿔야 감이 온다.

99.0% = 월 약 7.2시간 장애 허용
99.9% = 월 약 43분 장애 허용
99.99% = 월 약 4.3분 장애 허용

알림 캠페인 생성 API가 99.9%를 요구한다면 월 43분 이상 막히면 SLO 위반이다.

하지만 외부 SMS provider 장애까지 포함할지 제외할지 정해야 한다.

provider 장애를 제외하더라도 사용자는 알림을 받지 못하므로 degraded 응답과 대체 채널 정책이 필요할 수 있다.

지표별 설계 영향

요구	설계 질문	가능한 선택	비용
p95 300ms	동기 경로에 무엇을 넣을 것인가?	provider 호출 비동기화	pending 상태
556 msg/sec	어디가 처리량 병목인가?	worker scale out, throttling	queue age 운영
99.9%	장애 때 무엇을 유지할 것인가?	degraded mode, failover	fallback 정책
p99 2s 이하	tail latency 원인은 무엇인가?	timeout, bulkhead	일부 요청 실패
peak 10배	burst를 흡수할 곳은?	queue, rate limit	지연 또는 거절

같은 요구라도 선택지가 다르다.

Latency는 경로 단축을 요구하고, throughput은 병렬 처리와 병목 제거를 요구하며, availability는 장애 격리와 기능 축소를 요구한다.

API 계약

세 지표를 API 계약으로 드러낼 수 있다.

{
  "dispatchJobId": "job-1001",
  "status": "ACCEPTED",
  "acceptedAt": "2026-07-01T10:15:00+09:00",
  "expectedStartWithinSeconds": 60,
  "rateLimitPerSecond": 300
}

이 응답은 접수 latency와 실제 발송 처리량을 분리한다.

사용자에게 즉시 완료를 약속하지 않고, 시스템이 감당 가능한 처리량과 지연을 계약으로 보여준다.

Spring 설정 예시

Latency와 availability는 timeout으로 연결된다.

notification:
  dispatch:
    accept-timeout-ms: 300
    provider-timeout-ms: 1500
    max-provider-rate-per-second: 300
    queue-age-warning-seconds: 60
    queue-age-critical-seconds: 300

접수 API timeout과 provider timeout을 같은 값으로 두면 경계가 흐려진다.

접수 API는 빠르게 job을 만들고, provider 호출은 worker에서 별도 timeout과 retry 정책을 가진다.

Availability와 장애 격리

Availability를 높이려면 모든 기능을 살리는 것보다 핵심 기능을 분리해야 한다.

예를 들어 provider 장애 중에도 다음은 가능할 수 있다.

• 캠페인 생성은 허용한다.
• 발송 예약은 허용한다.
• 실제 발송은 DELAYED로 둔다.
• 관리자 화면에는 provider 장애와 queue age를 보여준다.
• 긴급 알림은 대체 provider를 사용한다.

이 구조는 가용성을 높이지만 상태와 운영 복잡도를 늘린다.

DELAYED, RETRYING, FAILED_PROVIDER 같은 상태가 필요하고, 사용자와 운영자는 이를 이해해야 한다.

측정 위치

지표는 어디서 재느냐에 따라 의미가 달라진다.

• client latency: 사용자 네트워크 포함
• gateway latency: edge부터 API 응답까지
• application latency: Spring 처리 시간
• DB latency: query와 transaction 시간
• queue age: 발행 후 처리 시작까지
• provider latency: 외부 API 호출 시간

설계 문서에는 어떤 latency를 SLO로 삼는지 명시해야 한다.

그렇지 않으면 같은 장애를 두고 “서버는 빠른데 사용자는 느리다”라는 논쟁이 생긴다.

위험 신호

• latency, throughput, availability를 모두 “성능”으로만 부른다.
• 평균 latency만 보고 p95, p99를 보지 않는다.
• throughput 목표가 외부 provider limit을 넘는데 대안을 정하지 않는다.
• 99.9% availability를 쓰지만 제외 범위와 error budget이 없다.
• queue를 도입하고도 queue age SLO가 없다.
• timeout을 늘려 availability를 높이려 한다.

개인 프로젝트 기준

개인 프로젝트에서는 다음 계산만으로도 충분히 좋다.

• 핵심 API p95 목표
• 동기 경로 latency budget
• 예상 peak QPS 또는 작업량
• 외부 API timeout
• 가용성 목표 대신 장애 때 보여줄 fallback

숫자가 정확하지 않아도 된다.

가정을 드러내고 측정 후 수정할 수 있으면 된다.

기업 운영 기준

기업 운영에서는 지표가 알림과 capacity plan으로 이어져야 한다.

• p95/p99 latency dashboard
• consumer throughput과 queue age
• provider rate limit 사용률
• monthly availability와 error budget burn
• saturation 지표
• SLO 위반 시 대응 owner

이 연결이 없으면 목표 수치가 설계 리뷰 문구로만 남는다.

확인 질문

확인 질문

• 확인 질문: Latency와 throughput을 구분해야 하는 이유는 무엇인가?
  • 답변: 한 요청의 응답 시간과 전체 처리량은 병목과 해결책이 다르기 때문이다.
• 확인 질문: 99.9% availability를 월 장애 허용 시간으로 바꿔야 하는 이유는 무엇인가?
  • 답변: 운영자가 실제로 허용되는 장애 시간과 error budget을 이해할 수 있기 때문이다.
• 확인 질문: queue 도입은 세 지표를 어떻게 바꾸는가?
  • 답변: 접수 latency와 spike 흡수는 좋아질 수 있지만 queue age와 비동기 완료 운영 복잡도가 생긴다.

참고 문서

• Google SRE Book, Service Level Objectives
• Google SRE Book, Handling Overload
• AWS Well-Architected Framework, Performance Efficiency Pillar
• Microsoft Azure Well-Architected Framework, Reliability