[OS] TPS는 왜 수렴하지 않았을까

팀 프로젝트 festabook에서 학습한 내용을 정리한 글입니다.
시스(CS 스터디)에서 발표한 내용을 정리한 글입니다.

 

💭 들어가며

본 글은 시스(CS 스터디)에서 발표한 내용을 정리한 자료로, 발표용 흐름에 맞추어 순차적으로 구성되어 있다. 개념에 대한 보다 정확한 이해가 필요하다면, 시스 유튜브에 업로드된 영상 자료를 함께 참고 바란다.

 

 

✅ 문제 상황

부하 테스트를 진행했는데, TPS가 수렴하지 않는다.

TPS(Transaction Per Second)는 초당 처리 완료된 트랜잭션 수를 의미한다. 이론적으로 TPS는 요청 수가 증가함에 따라 증가하다가, 시스템의 처리 한계(Saturation Point)에 도달하면 특정 값으로 수렴해야 한다.

TPS 그래프

🔽 실제 부하 테스트 결과

• 요청 수 300 -> TPS 약 165
• 요청 수 1,000 / 3,000 / 5,000 -> TPS 약 145

즉, 처리 한계를 넘긴 이후 TPS가 유지되지 않고 오히려 감소했다.

 

 

✅ 사전 지식

▶ TCP 3-Way Handshake

TCP 연결은 다음 과정을 통해 성립된다.

1. 클라이언트 -> 서버 : SYN
2. 서버 -> 클라이언트 : SYN-ACK
3. 클라이언트 -> 서버 : ACK

이 시점부터 TCP 연결은 ESTABLISHED 상태가 된다.

 

 

✅ 파고들기

▶ Accept Queue

리눅스 기준 TCP 백로그에서, TCP 연결 과정 중 서버는 내부적으로 두 종류의 큐를 사용한다.

🔽 SYN Queue

• SYN만 수신된 상태
• 반연결(half-open) 상태
• ACK를 기다리는 단계
• 커널 자원을 일부 점유

SYN Flood 공격과 관련 있음

🔽 Accept Queue

• 3-Way Handshake가 완료된 연결
• 애플리케이션(Tomcat)이 accept()로 가져가기 전 상태
• 이미 커널 자원을 점유한 상태

 

▶ Keep-Alive

HTTP Keep-Alive는 하나의 TCP 연결을 여러 HTTP 요청에 재사용하는 기능이다.

• 장점
  • TCP Handshake 비용 감소
  • RTT 감소
  • 네트워크 지연 감소
• 단점
  • 요청 처리가 끝나도 TCP 연결이 유지됨
  • 동시 접속 수가 많을 경우, 유휴 TCP 연결이 커널 자원을 점유

 

▶ max-connections

max-connections는 Tomcat이 동시에 유지할 수 있는 최대 TCP 연결 수를 의미한다.

• Keep-Alive 연결 포함
• 처리 가능 여부와 무관하게 TCP 연결 자체는 수락

처리할 수 없는 요청이라도 TCP 연결 자체는 수락될 수 있다.

 

▶ 요청 처리 흐름

요청 하나가 처리되기까지의 전체 흐름은 다음과 같다.

1. 클라이언트 -> TCP 연결 요청
2. TCP 3-Way Handshake 완료
3. Accept Queue 대기
4. Tomcat이 connection을 accept
5. 요청을 처리하기 위한 Runnable 생성
6. ExecutorService(Thread Pool Queue)에 Runnable 등록
7. Worker Thread 할당
8. 실제 요청 처리

여기서 Tomcat 기본 작업 큐(Thread Pool Queue)는 Integer.MAX_VALUE로 사실상 무한이다. 따라서, 처리 불가능한 요청도 Runnable 객체로 계속 생성되어 JVM 힙에 쌓인다.

Apache Tomcat 공식 문서

각 들어오는 비동기 요청이 아닌 요청은 해당 요청이 처리되는 동안 스레드를 필요로 한다. 현재 사용 가능한 요청 처리 스레드보다 더 많은 동시 요청이 들어오면, 추가 스레드가 구성된 최대값(maxThreads 속성 값)까지 생성된다. 그럼에도 불구하고 더 많은 동시 요청이 들어오면, Tomcat은 현재 연결 수가 maxConnections에 도달할 때까지 새 연결을 수락한다. 연결은 Connector가 생성한 서버 소켓 내부에 대기열로 저장되며, 스레드가 연결을 처리할 수 있을 때까지 대기한다. maxConnections에 도달하면 운영 체제가 추가 연결을 대기열에 저장한다. 운영 체제에서 제공하는 연결 대기열의 크기는 acceptCount 속성으로 제어할 수 있다. 운영 체제 대기열이 가득 차면 추가 연결 요청이 거부되거나 시간 초과될 수 있다.

 

▶ 실험을 통한 검증

다음과 같이 설정을 변경했다.

accept-count: 0
max-connections: 300
max-keep-alive-requests: 1

• Accept Queue 대기 제거
• Keep-Alive 비활성화
• 처리 불가능한 요청은 즉시 Drop

결과적으로 요청 수가 증가해도 TPS는 약 170 수준에서 안정적으로 유지되었다.

 

 

✅ 확장하기

▶ 왜 TPS가 수렴하지 않았는가

요청 수가 증가할수록 다음 현상이 동시에 발생한다.

• 처리되지 못한 TCP 연결 증가
• Thread Pool Queue에 쌓이는 Runnable 객체 증가
• JVM 힙 사용량 증가
• GC 빈도 및 소요 시간 증가
• Context Switching 비용 증가

결과적으로 CPU는 실제 비즈니스 로직보다 큐 관리, 객체 생성, GC, 스케줄링에 더 많은 시간을 사용하게 되고, TPS는 이론적인 Saturation Point에 수렴하지 않고 오히려 감소한다.

 

▶ Keep-Alive로 커넥션이 재사용되는 경우

• 동일한 클라이언트 ↔ 동일한 서버 (4-tuple 동일)
  • 4-tuple: client IP, client port, server IP, server port
• 요청 1, 요청 2를 보냈을 때 요청 1의 응답이 완전히 종료된 이후
• Keep-Alive 타임아웃 내에 다음 요청 도착
• 서버가 Connection: close로 연결을 종료하지 않음
• Connection: keep-alive 헤더 명시

 

▶ SYN Flood 공격이란

SYN Flood는 TCP 3-Way Handshake의 구조적 특성을 악용한 공격이다.

1. 대량의 SYN 패킷 전송
2. ACK를 보내지 않음
3. 서버는 SYN Queue에 반연결 상태를 유지
4. SYN Queue 고갈
5. 정상 연결 거부

 

 

📍 참고 자료

• veithen.io - How TCP backlog works in Linux
• Wikipedia - HTTP persistent connection
• MDN - Keep-Alive header
• Apache Tomcat 공식 문서 - The HTTP Connector
• Apache Tomcat 공식 문서 - The Executor (thread pool)
• cloudflare 공식 문서 - What is a SYN flood attack?
• 사진
  • emqx - EMQX Performance Tuning: TCP SYN Queue and Accept Queue