I/O Bound와 Context Switching

CPU bound  vs  I/O bound

프로그램이나 작업의 병목이 어디에서 발생하는지를 설명하는 개념

 

CPU bound (CPU 제한)

: 프로그램의 실행 속도가 CPU의 연산 능력에 의해 제한되는 경우.

I/O bound (입출력 제한)

: 프로그램의 실행 속도가 입출력 작업(I/O)에 의해 제한되는 경우.

 

CPU Bound

• CPU 때문에 bound
• CPU 사용량 높음, 복잡한 계산, 반복문, 알고리즘 연산 등이 주 원인.
• CPU가 쉬지 않고 계속 연산을 수행해야 하므로, CPU 사용률이 높음.
• 예시: 대규모 행렬 곱셈, 암호화/복호화, 머신러닝 모델 학습, 재귀 알고리즘을 이용한 수학 문제 계산
• 해결: 더 빠른 CPU / 멀티스레딩 / 병렬 처리

I/O Bound

• I/O 때문에 bound
• CPU는 대기 상태이고, 디스크, 네트워크, 파일 읽기/쓰기 등의 결과를 기다림.
• CPU 사용률은 낮고, 입출력 대기 시간이 문제.
• 예시: DB에서 대량의 데이터 조회, 파일 읽기/쓰기, 외부 API 호출, 사용자 입력 기다림
• 해결: 비동기 처리 / 캐싱 / 병렬 I/O

 

 

 

 

 

소프트 성능 분석 관점에서

CPU Bound vs I/O Bound

WebFlux는 대량 트래픽 요청에 용이하도록 설계되어 있고 I/O Bound에 좀 더 가깝다.

 

CPU: Computer Processing Unit, 기계어 명령어들을 기반으로 계산 수행하는 중앙처리 장치

CPU Bound : 단순히 CPU를 사용하는 작업들이 아니라, CPU를 중점적으로 다루는 작업

예를 들면 암호화나 압축과 같은 수학적 알고리즘 작업들, 집계를 위한 작업

주로 CPU 계산 능력에 따라 성능이 좌우되는 작업들

 

컨텍스트 스위칭

어플리케이션 레이어에 실행된 프로세스 2개는 하드웨어 레이어의 CPU(core)에 명령을 내림

이 때 CPU 코어에서는 동시에 실행되는 것으로 보이지만, 사실은 실제로는 번갈아가며 실행된다.

번갈아가며 실행하는 과정 자체를 OS에서는 컨텍스트 스위칭이라고 하고,

실행 관점에서 문맥을 바꿨다는 의미다.

이런 컨텐스트 스위칭은 스위칭 바운드 어플리케이션에서 성능 저하를 가져온다.

 

컨텍스트 스위칭과 CPU의 동작

어플리케이션은 실행돼서 메모리에 로드 되고, 프로세스로 동작할 텐데

CPU로 스케줄링 되어 실행될 때 기계어 실행을 위해 필요한 데이터를 CPU Register로 미리 가져옴.

그리고 ALU를 통해 실제 계산 진행.

레지스터에는 기존에 어떤 명령까지 진행했는지 저장도 하고 캐싱도 해줌. 그래서 동일한 프로세스의 일을 수행할 수록 성능이 높아진다.

 

하지만 컨텍스트 스위칭 하면 앱2 실행위해 레지스터 정보 초기화하는 가정부터 시작한다.

1을 메모리 저장해놓고, 2 저장 데이터를 가져와서 레지스터에 적재하고 명령어 실행.

하나의 시피유에서 다수의 프로세스 동작 => 성능상 오버헤드가 발생한다.

사실은 현대적 컴퓨터에서는 여러 프로세스 실행하도록 설계되어 있어서, 정상동작이지만, 성능 관점에서는 적절하지 않다고 볼 수 있다.

 

컨텍스트 스위칭이라는 오버헤드가 없으면 더 빠르게 수행될 수 있다.

그렇다면 어떻게 더 빠르게 만들 수 있을까?

컨텍스트 스위칭의 해결

흔히 말할 수 있는 전략은, 멀티 코어 CPU 사용. 병렬 처리 한다. 두 개의 코어에서 각각의 명령어를 사용할 수 있도록 한다.

컨텍스트 스위칭 오버헤드를 최소화 할 수 있다.

 

멀티코어 필요성에 또다른 배경이 있다.

컨텍스트 스위칭이 아니더라도, 하나의 씨피유 고속화 > 특정 지점부터는 발열 문제 해결 불가.

서버 CPU들은

일반적으로 5기가 이상으로는 고도화 하지 않고 멀티코어 방식으로 하드웨어가 발전.

평균 3, 저전력 CPU는 1기가도 많이 헤르츠 사용.

서버 하드웨어들은 대략 3~4 기가 헤르츠 기반으로 16코어 32코어 64코어… 118코어까지 탑재한 경우도 있음.

 

 

 

I/O Bound

I/O

: 인풋과 아웃풋, 입출력 장치의 중점적인 작업들, 예를들면 키보드와 같은 사용자 입력, 디스크 복사, 네트워크와 주고받는 행위들

I/O 예시

클리아이언트가 네트워크 통해 서버에 hello라고 전송

NIC 카드가 네트워크 패킷 전달받고 커널에서 네트워크 프로토콜 처리를 진행함.

서버 어플리케이션은 커널로부터 패킷 전달받기 전까지 대기를 하게 됨.

NIC로부터 패킷을 받고 커널까지의 과정 또한 CPU가 필요함.

엎 관점에서는 패킷 받기 전까지 대기하기 때문에 CPU를 중점적으로 사용하지 않는 상태라 할 수 있음.

만약 패킷이 오지 않았다면, 해당 서버의 프로세스는 계속해서 대기를 한다.

 

웹 어플리케이션 서버 관점에서 I/O 예시

클라이언트로부터 전달받는 Http 프로토콜을 처리하는 것도 웹 어플리케이션 입장에서는 I/O이고

웹 어플리케이션에서 비즈니스 로직 이후, DB에 쿼리하기, 조회, 삭제하기, 외부 API Server에 요청하기도 네트워크 I/O임

하나의 어플리케이션에도 이렇듯 I/O 개념이 산재한다.

 

만약 클라이언트로부터 많은 요청이 발생해서 I/O를 동시 처리하게 하려면?

전통적 방법 : 웹 어플리케이션 스레드 개수를 늘리는 것.

Thread per request/connection. 하나의 요청 당 하나의 스레드가 필요하다.

굉장히 많은 스레드가 실행된다고 가정하면, 성능관점에서 CPU 컨텍스트 스위칭 고려해야 한다. 오버헤드 감수하더라도 i/o 요청을 최대한 처리하도록 하는 관점이다

다른 추가 요청이 있게 되면, 대기하지 않고 또다른 스레드로 처리하기

 

그럼 만약 요청 수만큼 계속 스레드를 늘리게 된다면? 앺 어케?

성능과 리소스 관점에서 2가지 고려.

1. 메모리

스레드를 만들면 메모리가 필요하다. 10만 요청 * 스레드크기 용량이 필요해짐. 하드웨어 적으로도 최대 메모리까지 사용하면 시스템이 아예 동작하지 못할 수도 있다. 커널에서는 안전장치인 OOM이 있는데, 주요 프로세스들을 Kill out죽임으로서 시스템 다운을 예방하는 장치. 그래서 우리 어플리케이션 프로세스까지 말끔하게 정리하게 되어버릴 것이다.

2. 스레드 생성/삭제

또한 요청이 완료된, 사용이 완료된 스레드는 삭제하고 , 새요청에 새 스레드를 만든다면, 만들고 삭제하는 것 자체가 성능 관점에서 손해다.

 

스레드풀

생성 삭제 자체를 해결하는 방법으로 스레드풀이 활용된다.

가용 스레드 미리 만들어놓고 미리 만든 스레드를 활용, 반납하는 전략.

OS레벨의 스레드 생성과 삭제가 빈번하게 발생하지 않아 오버헤드를 조금 줄일 수 있고, 하드웨어 수준으로 메모리를 다 쓰는 걸 발생할 수 있다. 컨텍스트 스위칭 오버헤드는 발생할 수 있다.

 

실제로 스프링 mvc는 기본 내장된 톰캣에서 스레드풀 기반으로 동작.

시작시 최소 id스레드 개수와 최대 스레드 개수 통해 관리할 수 있다.

특정 맥스 스레드 개수만큼 유지하며 트래픽 처리하도록 설계되어 있다.