Latency vs Throughput

Latency vs. Throughput

Latency 와 Throughput 은 시스템 성능 평가의 양대 축으로 상호 보완적인 지표이다. Latency는 데이터 전송 지연 시간 (밀리초 단위) 으로, 실시간 화상 회의나 온라인 게임에서 사용자 경험에 직접적 영향을 미친다. Throughput은 초당 처리 가능한 데이터량 (MBps) 으로 대용량 트래픽 처리 능력을 결정한다. 시스템 설계자는 대역폭, 병목 현상, 하드웨어 자원 등 다양한 요소를 고려하여 균형점을 찾아야 한다. 이를 통해 실시간 시스템, 대용량 데이터 처리 등 다양한 응용 분야에서 최적의 성능을 달성할 수 있다.

핵심 개념

• 지연시간 (Latency)
  지연시간은 데이터가 한 지점에서 다른 지점으로 이동하는 데 걸리는 시간이다. 시스템에서 요청이 시작된 시점부터 응답을 받는 시점까지의 지연을 의미합니다. 주로 밀리초 (ms), 마이크로초 (μs) 또는 나노초 (ns) 단위로 측정됩니다. 낮은 지연시간은 시스템의 응답성이 좋다는 것을 의미하며, 실시간 상호작용이 중요한 애플리케이션에서 특히 중요합니다.

• 처리량 (Throughput)
  처리량은 시스템이 단위 시간당 처리할 수 있는 작업량을 나타낸다. 네트워크에서는 초당 비트 수 (bps), 초당 요청 수 (RPS), 또는 초당 트랜잭션 수 (TPS) 등으로 측정된다. 높은 처리량은 시스템이 효율적으로 많은 작업을 처리할 수 있음을 의미하며, 대용량 데이터 처리가 필요한 시스템에서 중요한다.

• 대역폭 (Bandwidth)
  대역폭은 통신 채널의 최대 이론적 처리량을 나타낸다. 네트워크 케이블이나 연결이 처리할 수 있는 최대 데이터 양을 의미하며, 일반적으로 초당 비트 수 (bps) 로 표시된다. 대역폭은 처리량의 상한선을 설정하며, 실제 처리량은 대역폭보다 낮다.

• 상충관계 (Trade-off)
  지연시간과 처리량 사이에는 상충관계가 존재한다. 처리량을 높이기 위해 배치 처리, 병렬 처리 등의 기법을 사용하면 개별 요청의 지연시간이 증가할 수 있다. 반대로 지연시간을 최소화하기 위해 자원을 최적화하면 전체 처리량이 감소할 수 있다. 시스템 설계자는 애플리케이션의 요구사항에 따라 적절한 균형점을 찾아야 한다.

• 병목 현상 (Bottlenecks)
  시스템 내에서 전체 성능을 제한하는 요소를 병목 현상이라고 한다. 네트워크 대역폭, CPU 처리 능력, 메모리 접근 속도, 디스크 I/O 등 다양한 요소가 병목 현상을 일으킬 수 있으며, 이는 지연시간 증가와 처리량 감소로 이어진다. 효율적인 시스템 설계를 위해서는 병목 현상을 식별하고 해결하는 것이 중요하다.

• 확장성 (Scalability)
  시스템이 증가하는 부하를 처리하기 위해 자원을 효율적으로 추가할 수 있는 능력을 의미한다. 수평적 확장 (더 많은 서버 추가) 과 수직적 확장 (더 강력한 서버로 업그레이드) 을 통해 처리량을 증가시킬 수 있다. 그러나 확장 시 지연시간에 미치는 영향도 고려해야 한다.

• 응답 시간 (Response Time)
  응답 시간은 사용자가 요청을 보내고 완전한 응답을 받는 데 걸리는 총 시간을 의미한다. 지연시간과 관련이 있지만, 응답 시간에는 처리 시간과 대기 시간도 포함된다. 사용자 경험에 직접적인 영향을 미치는 중요한 지표이다.

• 큐잉 이론 (Queueing Theory)
  큐잉 이론은 대기열 (큐) 의 동작을 수학적으로 연구하는 분야로, 지연시간과 처리량의 관계를 이해하는 데 중요한 이론적 기반을 제공한다. Little 의 법칙 (L = λW) 과 같은 원리를 통해 시스템의 성능을 예측하고 최적화할 수 있다.

지연 시간 (Latency) vs. 처리량 (Throughput) 비교

사용자 경험 향상, 자원 활용 효율성 증대, 성능 병목 현상 파악, 확장성 계획 수립 등 다양한 목적을 위해 이 두 지표의 이해와 관리가 필요하다.

주요 기능 및 역할

지연시간과 처리량은 시스템 성능을 다각도로 평가하고 최적화하는 데 핵심적인 역할을 한다.

특징

지연시간과 처리량은 다양한 요소에 의해 영향을 받으며, 각기 다른 특성을 가지고 있다.

핵심 원칙

지연시간과 처리량을 최적화하기 위한 핵심 원칙.

주요 원리 및 작동 원리

지연시간과 처리량의 관계는 다양한 이론과 원리로 설명될 수 있다.

큐잉 이론과 Little 의 법칙

큐잉 이론은 지연시간과 처리량 사이의 관계를 수학적으로 설명한다. Little 의 법칙 (L = λW) 은 시스템 내 평균 요청 수 (L) 가 도착률 (λ) 과 평균 대기 시간 (W) 의 곱과 같다는 원리를 설명한다. 이는 처리량 (λ) 과 지연시간 (W) 사이의 근본적인 관계를 보여준다.

지연시간 - 처리량 곡선

아래의 이미지는 분산 네트워크 성능 분석을 위한 **지연시간 - 처리량 곡선 (Latency-Throughput Curve)**을 보여주며, 다음과 같은 핵심 요소를 포함한다.

1. X 축 (Injection Rate)

   • 트래픽 주입률: 네트워크에 초당 주입되는 데이터 양 (단위: flits/cycle).
   • **0 부터 포화점 (Saturation Point)**까지 증가하며, 네트워크 부하를 점진적으로 높임.

2. Y 축 (Latency)

   • 패킷 지연시간: 데이터가 네트워크를 통과하는 데 걸리는 시간 (단위: cycles).
   • 초기에는 낮은 값 유지 → 트래픽 증가 시 급격히 상승.

3. 곡선 형태

   • 선형 구간 (Linear Region): 낮은 주입률에서 처리량 증가 ↔ 지연시간 완만 상승.
   • 포화 구간 (Saturation Region): 주입률 증가해도 처리량 정체 ↔ 지연시간 급증.

곡선 해석 및 성능 지표

성능 영향 요소

1. 토폴로지 (Topology)

   • 예시: 메시 (Mesh), 토러스 (Torus) → Bisection Bandwidth가 처리량 상한 결정.
   • 영향: 높은 대역폭 → 포화점 지연.

2. 라우팅 알고리즘 (Routing)

   • Minimal vs. Non-Minimal: 비최소 라우팅은 지연시간 증가 대신 포화 처리량 향상.
   • Adaptive Routing: 트래픽 부하에 따라 경로 동적 조정 → 곡선 형태 최적화.

3. 플로우 컨트롤 (Flow Control)

   • Virtual Channel 사용: 버퍼 경쟁 감소 → 포화 처리량 40% 향상 가능.
   • Credit-Based vs. On/Off: 신호 오버헤드 차이로 지연시간 변동.

처리량 제한 요소

처리량은 다양한 요소에 의해 제한될 수 있다:

1. 하드웨어 제한: CPU, 메모리, 디스크 I/O 등
2. 네트워크 제한: 대역폭, 패킷 손실, 혼잡 제어
3. 소프트웨어 제한: 비효율적인 알고리즘, 동기화 오버헤드

지연시간 구성 요소

지연시간은 여러 구성 요소로 이루어져 있다:

1. 전파 지연 (Propagation Delay): 데이터가 물리적 거리를 이동하는 데 걸리는 시간
2. 전송 지연 (Transmission Delay): 데이터를 매체에 전송하는 데 걸리는 시간
3. 처리 지연 (Processing Delay): 데이터를 처리하는 데 걸리는 시간
4. 대기열 지연 (Queuing Delay): 처리를 기다리는 동안 발생하는 지연

지연시간과 처리량의 관계

구조 및 아키텍처

지연 시간 최적화 아키텍처

지연 시간을 최소화하기 위해, 클라이언트와 서버 간의 거리를 줄이고, 데이터 처리 경로를 최적화하는 구조를 채택한다.
요청 처리 경로를 최소화하고, 캐싱과 지역성을 활용하여 빠른 응답 시간을 제공한다. 예를 들어, CDN(Content Delivery Network) 을 활용하여 사용자와 가까운 위치에서 콘텐츠를 제공함으로써 지연 시간을 줄일 수 있다. 실시간 시스템, 온라인 게임, 고주파 거래 시스템 등에 적합하다.

주요 특징:

• 요청 경로 최소화 (홉 수 줄이기)
• 엣지 컴퓨팅 활용
• 캐싱 최적화
• 비동기 처리 대신 동기 처리 활용
• 지역성 (Locality) 최적화

처리량 최적화 아키텍처

처리량을 극대화하기 위해, 시스템은 병렬 처리, 배치 처리, 큐 시스템와 리소스 확장을 활용하여 높은 처리량을 제공한다. 예를 들어, 마이크로서비스 아키텍처를 도입하여 각 서비스가 독립적으로 확장 가능하게 설계함으로써 전체 시스템의 처리량을 향상시킬 수 있다. 이는 대용량 데이터 처리, 분석 시스템, 백업 시스템 등에 적합하다.

주요 특징:

• 병렬 처리 극대화
• 배치 처리 활용
• 큐 시스템 구현
• 비동기 처리 활용
• 수평적 확장성 설계

균형 잡힌 아키텍처

대부분의 실제 시스템은 지연시간과 처리량 사이의 균형을 맞추어야 한다. 이를 위해 다양한 기법을 조합하여 사용한다.

주요 특징:

• 마이크로서비스 아키텍처
• 캐싱과 큐 시스템의 조합
• 적응형 배치 처리
• 우선순위 기반 스케줄링
• 지능형 부하 분산

구성 요소

장점과 단점

지연시간과 처리량 최적화의 장단점과 운영 기준.

실무 적용 예시

활용 사례

시나리오: 대규모 E- 커머스 플랫폼의 성능 최적화

상황: 대규모 온라인 쇼핑몰이 블랙프라이데이와 같은 특별 할인 기간 동안 트래픽이 평소의 10 배 이상 증가하는 문제에 직면했습니다. 사이트 로딩 시간이 길어지고, 결제 프로세스가 지연되며, 일부 사용자는 서비스를 이용할 수 없는 상황이 발생했습니다.

목표:

• 사이트 로딩 시간을 2 초 이내로 유지
• 장바구니 추가 및 결제 프로세스 응답 시간을 500ms 이내로 유지
• 초당 최소 5,000 건의 트랜잭션 처리 가능
• 99.99% 서비스 가용성 확보

E- 커머스 플랫폼 지연시간/처리량 최적화 다이어그램

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61

                              [글로벌 사용자]
                                     │
                                     ▼
                          +----------------------+
                          │   CloudFront CDN      │◄─정적 자원(이미지,JS,CSS)
                          │  (Edge Lambda@Edge)   │─┐
                          +-----------+-----------+ │
                                      │             │
                                      │API 요청      │동적 콘텐츠 처리
                                      ▼             │
                          +----------------------+  │
                          │  AWS Global Accelerator │
                          +-----------+-----------+  │
                                      │              │
                           +----------+-----------+  │
                           ▼                       ▼  │
               +-----------------------+   +-----------------------+ 
               │  API Gateway (REST)   │   │  WebSocket Gateway    │
               │  - Rate Limiting      │   │  - 실시간 재고 업데이트 │
               │  - JWT 인증           │   +-----------+-----------+
               +-----------+-----------+               │
                           │                           │
         ┌─────────────────┴─────────────────┐         │
         ▼                                   ▼         ▼
+------------------+               +------------------+       +------------------+
│ Auto-Scaling Group             │  Elastic Container    │       │   Serverless     │
│  - Web Server Cluster          │  Service (ECS)        │       │   (Lambda)       │
│  - CPU 80% 기준 확장            │  - 결제/주문 마이크로서비스   │       │  - 추천 엔진     │
+------------------+               +------------------+       +------------------+
         │                                   │                           │
         │                                   │                           │
         ▼                                   ▼                           ▼
+------------------+               +------------------+       +------------------+
│   Redis Cluster  │◄─세션/캐시────│   API Cache Layer │       │  Event Bridge    │
│  (Multi-AZ)      │─┐            │  (DynamoDB DAX)  │       │  - 이벤트 오케스트레이션│
+------------------+ │            +------------------+       +------------------+
                     │                     │                           │
                     │                     ▼                           ▼
                     │            +------------------+       +------------------+
                     │            │   Read Replicas   │       │  SQS/SNS/Kafka   │
                     │            │  (Aurora Global DB)│       │  - 비동기 작업 큐   │
                     │            +------------------+       +------------------+
                     │                     ▲                           │
                     │                     │                           │
                     └───────┐     +------------------+       +------------------+
                             │     │  Primary Database │◄─────│  Batch Workers    │
                             │     │  (Sharded RDS)    │       │  (EC2 Spot)       │
                             │     +------------------+       +------------------+
                             │                                           │
                             │                                           ▼
                             │                                 +------------------+
                             │                                 │  Data Lake       │
                             │                                 │  (S3 + Athena)   │
                             │                                 +------------------+
                             │
                   +------------------+
                   │  모니터링 시스템    │
                   │  - CloudWatch    │
                   │  - X-Ray         │
                   │  - Prometheus    │
                   +------------------+

최적화 전략 (지연시간 vs. 처리량)

계층별 최적화

1. 프론트엔드 계층 (지연시간 <1s)

   • 점진적 정적 재생성 (ISR): Next.js 15+ 의 On-demand ISR 로 실시간 콘텐츠 갱신
   • WebAssembly 최적화: 이미지 리사이징을 WASM 으로 엣지 처리
   • HTTP/3 + QUIC: 멀티플렉싱으로 연결 지연시간 40% 감소

2. API 계층 (지연시간 <300ms)

   • 계층적 캐싱 전략:

     graph LR  
       A[User] --> B[Edge API Cache - 50ms]  
       B --> C{Cache Hit?}  
       C -->|Yes| D[Return Response]  
       C -->|No| E[Region API Cache - 100ms]  
       E --> F{Cache Hit?}  
       F -->|Yes| G[Return Response]  
       F -->|No| H[Origin Server - 300ms]  
     

   • GraphQL 지연 로딩: @defer 지시어 활용해 부분 응답 스트리밍

3. 데이터 계층 (처리량 >10k TPS)

   • AI 기반 샤딩:

     1 2 3 4

     # 머신러닝 기반 샤드 키 생성 model = CatBoostClassifier() model.fit(user_behavior_data, shard_hotspots) shard_key = model.predict(new_data)

   • 벡터화 쿼리 처리: PostgreSQL pgvector 확장으로 유사도 검색 가속화

4. 배치 처리 계층

   • 서버리스 스팟 인스턴스: AWS Lambda + EC2 Spot 혼합 배치로 비용 70% 절감
   • 예측 확장: Prophet 모델 기반 트래픽 예측 → 리소스 사전 할당

핵심 설계 원칙

1. 지연시간 민감도 계층화:

   1 2	사용자 체감 영역 (Tier 0) → 마이크로초 단위 최적화 백오피스 영역 (Tier 2) → 처리량 중심 설계

2. 비용 - 성능 최적화 곡선:

   1 2	$1/ms 감소 당 월 $2,400 절감 (10M MAU 기준) → CloudFront Intelligent Tiering + Lambda@Edge 조합으로 달성

3. 장애 전파 차단:

   1 2	회로 차단기(Circuit Breaker) 패턴 구현 → Istio 서비스 메시에서 500ms 타임아웃 기준 자동 차단

Google, Meta 사례 기반 구조 선택 전략

Google 과 Meta(Facebook) 는 각자의 서비스 특성에 맞는 지연시간과 처리량 최적화 전략을 구현했다.

Google 의 접근법

Google 은 다양한 서비스에 따라 다른 최적화 전략을 적용한다:

• 검색 엔진: 낮은 지연시간을 위해 글로벌 분산 아키텍처와 인메모리 캐싱을 활용한다. Google 의 검색은 사용자 쿼리를 즉각 처리하기 위해 처리량보다 지연시간을 우선시한다.
• BigTable/Spanner: 분산 데이터베이스 시스템으로, 지연시간과 처리량의 균형을 맞추기 위해 설계되었다. Google 의 SRE(Site Reliability Engineering) 책에서는 BigTable 에 대해 " 지연 시간이 낮은 사용자는 시스템이 도착하는 각 요청을 즉시 처리할 수 있도록 큐가 (거의 항상) 비어 있기를 원하지만, 오프라인 분석에 관심이 있는 사용자는 처리량에 더 관심이 있습니다 " 라고 설명한다.
• Google 클라우드 네트워크: 프리미엄 티어에서는 자체 글로벌 백본 네트워크를 활용하여 지연시간을 최소화하고, 표준 티어에서는 인터넷을 통한 라우팅으로 비용 대비 처리량을 최적화한다.

Meta(Facebook) 의 접근법

Meta 는 소셜 네트워크 특성에 맞게 다음과 같은 최적화 전략을 사용한다:

• TAO(The Associations and Objects): Facebook’s 소셜 그래프를 저장하는 분산 데이터 저장소로, 읽기 중심 워크로드에 최적화되어 있다. 다중 레이어 캐싱으로 지연시간을 최소화한다.
• Proxygen: Facebook 의 HTTP 서버 프레임워크로, 처리량 최적화를 위한 멀티스레딩과 지연시간 최적화를 위한 비동기 I/O 를 모두 활용한다.
• TCP BBR(Bottleneck Bandwidth and Round-trip propagation time): Google 이 개발하고 Meta 도 채택한 TCP 혼잡 제어 알고리즘으로, 네트워크 지연시간과 처리량을 모두 개선한다.

실무에서 효과적으로 적용하기 위한 고려사항 및 주의할 점

최적화하기 위한 고려사항 및 주의할 점

주제와 관련하여 주목할 내용

최신 동향

앞으로의 전망

추가로 학습해야할 내용

학습 주제 정리

용어 정리

참고 및 출처

Latency & Throughput 관련

• Latency and Throughput in System Design | GeeksforGeeks
• System Design: Latency vs Throughput - cs.fyi
• Latency, throughput, and availability: system design interview concepts - IGotAnOffer
• Latency and Throughput for Systems Design Interview - Java Challengers
• Throughput vs Latency - AWS 비교 문서
• Latency, Bandwidth, Throughput and Response Time | PerfMatrix
• Optimizing web servers for high throughput and low latency - Dropbox
• The Latency/Throughput Tradeoff - Dan Slimmon

모놀리포 Vs 폴리레포 (참고 추가)

• Monorepo vs. Polyrepo - GitHub
• Monorepo VS Polyrepo - DEV Community

최신 기술 동향 및 성능 최적화 사례

• Google Cloud Rapid Storage - InfoQ
• Meta RTC Optimization - Facebook Engineering
• Meta ServiceRouter at Scale - CACM

성능 인프라 관련 도구 및 문서

• Cloudflare CDN Documentation
• AWS Auto Scaling
• Prometheus Official Docs
• Kubernetes Horizontal Pod Autoscaler

기타

• AWS 공식 문서 - Latency/Throughput 개념
• Google QUIC 프로토콜 백서
• 2025 네트워크 트렌드 리포트 - IEEE