하드웨어 기초 #1 컴퓨터를 움직이는 네 가지 자원 — CPU, 메모리, 스토리지, 네트워크

서버를 운영하다 보면 같은 질문에 반복해서 부딪힙니다. 이 서버는 왜 느릴까. 이 인스턴스는 왜 이렇게 비쌀까. 어제는 멀쩡하던 서비스가 오늘은 왜 응답이 밀릴까. 원인은 거의 항상 네 가지 중 하나로 좁혀집니다. CPU, 메모리, 스토리지, 네트워크입니다. 이 시리즈는 그 네 가지 물리 자원을 운영자 관점에서 정리하고, 마지막에는 그것들이 클라우드 인스턴스의 사양표로 어떻게 나타나는지까지 이어가겠습니다.

리눅스나 도커, AWS를 다루는 글들은 이 네 자원을 이미 안다고 전제하고 시작합니다. 이 시리즈는 그런 전제를 이해하기 위한 기초를 다룹니다. 부품을 고르거나 PC를 조립하는 이야기가 아니라, 서버와 클라우드 위에서 성능과 비용이 어디서 결정되는지를 다루겠습니다.

하드웨어 기초, 총 9편으로 묶었습니다. 이 글은 그 출발점입니다.

왜 하드웨어를 알아야 하는가 #

요즘은 물리 서버를 직접 만질 일이 거의 없습니다. EC2 인스턴스를 고르고, 데이터베이스 메모리 값을 조정하고, 디스크 종류를 선택하는 일은 전부 콘솔의 클릭 몇 번으로 끝납니다. 그래서 하드웨어를 검은 상자처럼 두고 넘어가기 쉽습니다.

문제는 성능과 비용이 바로 그 검은 상자 안에서 결정된다는 점입니다. c5.xlarge가 왜 그 가격인지, gp3 디스크와 io2 디스크가 왜 다른지, 메모리를 늘렸는데 왜 여전히 느린지는 하드웨어를 모르면 추측만 하게 됩니다. 반대로 네 자원의 동작을 이해하면 성능 문제와 비용 문제를 추측이 아니라 측정과 진단의 대상으로 볼 수 있게 됩니다.

네 가지 자원 #

컴퓨터 한 대는 결국 네 가지 자원이 협력하는 장치입니다. 각자 맡은 일이 다르고, 부족할 때 나타나는 증상도 다릅니다.

CPU — 계산을 담당한다 #

CPU는 실제로 계산을 수행하는 부품입니다. 코드의 모든 연산, 조건 분기, 데이터 가공이 여기서 일어납니다. CPU가 부족하면 처리할 일이 줄을 서고, 요청은 그 줄 뒤에서 기다립니다. 자세한 구조는 #2에서 다루겠습니다.

메모리(RAM) — 지금 쓰는 데이터의 작업 공간 #

CPU가 계산하려면 데이터가 메모리에 올라와 있어야 합니다. RAM은 CPU가 작업 중인 데이터를 임시로 보관하는 공간입니다. 빠르지만 전원이 꺼지면 내용이 사라지는 휘발성 저장소이고, 용량이 한정돼 있습니다. 메모리가 부족해지는 순간 시스템은 느린 디스크를 임시 메모리로 끌어쓰기 시작하고, 이때 성능이 절벽처럼 떨어집니다. #3의 주제입니다.

스토리지 — 전원이 꺼져도 남는 보관소 #

스토리지는 데이터를 영구히 보관하는 장치입니다. RAM과 달리 전원이 꺼져도 내용이 남습니다. 대신 RAM보다 훨씬 느립니다. 데이터베이스 파일, 로그, 업로드된 이미지가 모두 여기에 저장되고, 종류(HDD,SSD,NVMe)와 구성(RAID)에 따라 속도가 크게 갈립니다. #4와 #5에서 다루겠습니다.

네트워크 — 바깥과 연결하는 통로 #

서버 한 대로 끝나는 서비스는 없습니다. 사용자, 데이터베이스, 다른 서비스와 끊임없이 데이터를 주고받아야 하고, 그 통로가 네트워크입니다. 대역폭이 넓어도 거리가 멀면 느릴 수 있는데, 이 구분이 운영에서 자주 혼동됩니다. #6에서 정리하겠습니다.

한 번의 웹 요청이 네 자원을 모두 지난다 #

네 자원은 따로 노는 것이 아니라 한 번의 요청 안에서 차례로 협력합니다. 사용자가 상품 상세 페이지를 여는 단순한 요청을 따라가 보겠습니다.

사용자 브라우저
   │  ① 네트워크 — 요청이 서버까지 전달
   ▼
웹 서버 (CPU/메모리)
   │  ② CPU — 요청을 해석하고 처리 로직 실행
   │  ③ 메모리 — 처리 중 데이터를 올려둠
   ▼
데이터베이스
   │  ④ 스토리지 — 디스크에서 상품 데이터를 읽음
   │  ⑤ 메모리 — 자주 쓰는 데이터는 캐시에서 바로
   ▼
응답 생성 (CPU/메모리)
   │  ⑥ 네트워크 — 응답이 사용자에게 되돌아감
   ▼
사용자 브라우저

여섯 단계 중 하나라도 느리면 사용자가 체감하는 응답 시간도 그만큼 늘어납니다. 디스크가 느리면 ④에서, CPU가 부족하면 ②에서, 메모리가 모자라면 ③에서, 거리가 멀면 ①과 ⑥에서 시간이 새어 나갑니다.

병목은 한 곳에서 생긴다 #

성능에서 가장 중요한 원칙입니다. 전체 속도는 가장 느린 한 곳이 결정합니다. CPU가 아무리 빨라도 디스크 읽기에서 막히면 전체 처리 속도는 디스크 성능에 좌우됩니다.

그래서 사양을 무작정 올리는 방식은 효과가 없을 때가 많습니다. CPU가 병목인데 메모리를 늘리면 비용만 오르고 속도는 그대로입니다. 먼저 어느 자원이 병목인지 측정하고, 그 자원만 보강하는 것이 순서입니다.

CPU 8코어  메모리 충분  디스크 느림(HDD)  네트워크 충분
   빠름        빠름         ← 병목            빠름

→ 디스크를 SSD로 교체하면 병목이 사라지고,
   다음으로 느린 자원이 새 병목이 된다.

병목은 하나를 해결하면 다음 자원으로 옮겨갑니다. 성능 개선은 이 병목을 따라가며 한 번에 하나씩 푸는 작업입니다.

CPU와 메모리는 떨어져 있다 #

오늘날 거의 모든 컴퓨터는 **계산하는 곳(CPU)**과 **데이터를 두는 곳(메모리)**이 분리된 구조를 따릅니다. CPU는 메모리에서 명령과 데이터를 가져와 계산하고, 결과를 다시 메모리에 저장합니다. 이 왕복이 끊임없이 일어납니다.

여기서 중요한 사실 하나가 나옵니다. CPU는 메모리보다 훨씬 빠릅니다. 그래서 CPU는 메모리를 기다리느라 시간을 허비하기 쉽고, 이 격차를 메우기 위해 CPU 안에 작은 고속 저장소인 캐시를 둡니다. 캐시가 왜 성능을 좌우하는지는 #2와 #3에서 이어가겠습니다.

자주 만나는 오해 #

“코어를 늘리면 항상 빨라진다” #

아닙니다. 한 작업이 여러 코어로 나뉘어야 효과가 있습니다. 단일 스레드로만 도는 작업은 코어를 8개로 늘려도 1개일 때와 속도가 같습니다. #2에서 자세히 다루겠습니다.

“메모리가 많으면 빠르다” #

부분적으로만 맞습니다. 메모리가 부족하면 확실히 느려지지만, 충분한 상태에서 더 늘린다고 빨라지지는 않습니다. 메모리는 속도를 올리는 자원이라기보다 부족할 때 절벽을 만드는 자원에 가깝습니다.

“용량이 크면 스토리지가 빠르다” #

용량과 속도는 다른 축입니다. 1TB 디스크가 100GB 디스크보다 반드시 빠른 것은 아닙니다. 속도는 종류(HDD,SSD,NVMe)와 IOPS가 결정합니다. #4에서 구분하겠습니다.

“느린 원인은 감으로 안다” #

가장 비싼 오해입니다. 네 자원 중 무엇이 병목인지는 측정해야 알 수 있습니다. 추측으로 사양을 올리면 비용만 늘고 병목은 그대로일 때가 많습니다.

정리 #

이번 글에서 잡은 그림입니다.

• 서버의 성능과 비용은 CPU, 메모리, 스토리지, 네트워크 네 자원에서 결정됩니다.
• CPU는 계산, 메모리는 작업 공간, 스토리지는 영구 보관, 네트워크는 바깥과의 통로입니다.
• 한 번의 요청은 네 자원을 차례로 지나며, 가장 느린 한 곳이 전체 속도를 결정합니다.
• 성능 개선은 병목을 측정해 한 번에 하나씩 푸는 작업입니다. 추측으로 사양을 올리는 방식은 비용만 키웁니다.
• 이 네 자원은 시리즈 끝에서 클라우드 인스턴스의 사양표로 다시 만납니다.

다음 — CPU #

네 자원 중 계산을 맡은 CPU부터 한 층 깊이 들어가겠습니다. #2 CPU — 코어 / 스레드 / 클럭 / 캐시, 그리고 vCPU의 정체에서는 코어와 스레드의 차이, 클럭만으로 성능을 비교할 수 없는 이유, 캐시가 속도를 좌우하는 원리, 그리고 클라우드에서 말하는 vCPU가 실제로 무엇인지까지 정리하겠습니다.