[ETC] Hyper-Threading 이란?
서버 모니터링 시스템을 보면 아래와 같은 황당한 상황을 마주하게 될 수 있다.
"프로세스 A의 CPU 사용률: 150%" 아니, 전체 최고 수치가 100% 아닌가?
어떻게 혼자서 100%를 넘게 쓰고 있지? 버그인가?
이는 버그가 아니라 현대 서버의 핵심 기술인 하이퍼스레딩(Hyper-Threading)과 관제 시스템이 병목 현상을 잡아내는 방식 때문에 발생하는 지극히 정상적인 현상이다.
오늘은 하이퍼스레딩의 내부 원리와 관제의 방식을 정리해 보자.
1. 하이퍼스레딩(Hyper-Threading): 물리 코어를 속이는 마법
굳이 비싼 돈을 들여 물리적인 CPU 코어를 2배로 늘리지 않고도, 성능을 끌어올리기 위해 탄생한 기술이 바로 하이퍼스레딩이다.
- 개념: 하나의 물리적 코어(Physical Core)를 운영체제(OS)가 두 개의 논리적 코어(Logical Core)로 인식하게 만드는 기술
- 왜 쓸까? 하나의 스레드가 CPU 내부에서 연산을 할 때, 메모리에서 데이터를 가져오거나 버퍼를 기다리는 등의 '대기 시간(Idle Time)'이 필연적으로 발생한다. 하이퍼스레딩은 이 찰나의 빈틈을 타서 다른 스레드의 연산을 실행하는 것.
- 결과: OS 입장에서는 코어가 2개 있는 것처럼 보이고, 노는 자원을 알뜰하게 쓰기 때문에 CPU 처리량이 극대화 된다.
2. 왜 관제 시스템은 CPU 사용율을 '전체 75%'가 아닌 '150%'로 보여줄까?
예를 들어 물리 코어 1개(논리 코어 2개 = 총 용량 200%)를 가진 서버가 있고. 특정 작업을 돌렸더니 논리 코어 1번은 100% 풀가동되고, 논리 코어 2번은 50%를 쓴다면. 이걸 표기하는 방법은 두 가지가 일 것이다.
- 전체 기준 표기: "이 서버는 총 200% 중 150%를 쓰니까, 전체 사용률 75% 이다."
- 논리 코어 기준 표기: "이 프로세스는 CPU 150%를 점유하고 있다."
대부분의 리눅스(top, ps) 및 모니터링 에인전트는 2번 방식을 택한다. 바로 진짜 병목 현상을 가리지 않기 위해서 이다.
- 75%로 퉁치면 생기는 문제 (병목의 은폐)
만약 4차선 도로(4코어 서버 = 총 400%)가 있는데, 어떤 무거운 배치 프로세스 하나가 1번 차선(1코어)을 100% 독점해서 꽉 막아버렸다고 가정해 보자. 전체 기준으로 계산하면 겨우 25% 사용 중이라고 나올 것 이다. 관리자는 "어? 아직 25%밖에 안 쓰네? 널널하구나!" 하고 방심하게 되지만, 실질적으로 그 프로세스는 1번 코어 한계치에 부딪혀 끙끙 앓고 있는 병목 상태인 것이다.
- 150%로 보여주면 얻는 이점 (실질적 병목 확인)
코어 기준으로 합산해서 150%로 보여주면 관리자는. "아, 이 녀석이 코어 한 개 반 분량의 연산을 집어삼키며 리소스를 엄청나게 점유하고 있구나!" 즉, 어떤 프로세스가 시스템을 갉아먹는 '헤비 업로더'인지 직관적으로 파악할 수 있게 된다.
3. "그럼 150%를 치는 프로세스가 무조건 CPU 사용율을 높이는 진범일까?"
여기서 한 번 더 생객해봐야 하는 것이 있다. 눈에 보이는 사용률 150%짜리 프로세스가 '진짜 범인'이 아닐 수도 있기 때문이다.
- 현상: 특정 배치 스크립트 프로세스가 CPU 150%를 치고 있다고 가정.
- 실제 배후: 알고 보니 그 배치 스크립트가 잘못된 쿼리를 날려서 DB 프로세스(PostgreSQL 등)나 미들웨어(Kafka, RabbitMQ)가 락(Lock) 경합에 걸려 연쇄적으로 CPU를 쥐어짜고 있는 상황일 수 있다.
즉, 모니터링 화면에 찍히는 수치는 "지금 여기서 불이 크게 났다!"는 증상을 보여주는 것이고, 진짜 범인을 잡으려면 그 프로세스가 어떤 자식 프로세스를 만들었는지, 어떤 미들웨어와 통신하며 자원을 독점하고 있는지 프로세스 간의 연관 관계를 함께 추적해야 한다.
4. 요약 및 결론
- 하이퍼스레딩은 노는 CPU 자원을 쥐어짜기 위해 하나의 물리 코어를 두 개의 논리 코어로 쪼개 쓰는 기술이다.
- 관제 시스템이 CPU 사용률을 100% 넘게 표현하는 이유는 특정 코어가 독점당해 발생하는 병목 현상을 직관적으로 포착하기 위함이다.
- 모니터링 수치는 '증상'일 뿐이므로, 100% 넘게 튀는 프로세스를 기점으로 실제 리소스 경합을 일으킨 배후(진범)를 찾는 눈을 길러야 한다.