CPU Burst - I/O Burst

애플리케이션은 이용자에게 다양한 기능을 제공하지만

Process의 생애만 놓고 보면 CPU 실행(CPU burst)과 I/O Wait(I/O burst) 두가지 사이클을 가집니다.

CPU burst | 단어가 풍기는 느낌 그대로 연산을 실행하는 작업이고

I/O burst | I/O 시스템으로부터 데이터가 전송이 끝나기를 기다리는 것입니다.

CPU burst와 함께 프로세스가 실행해서 CPU burst와 I/O Burst가 계속 번갈아 동작하다가 terminate 요청(이때도 CPU burst)과 함께 프로세스가 종료됩니다.

그리고 CPU burst duration은 컴퓨터 그리고 프로세스에 따라 다르지만 대체로 위와 같은 분포를 보인다고 합니다. 대체로 CPU burst가 짧은 경우가 많고 긴 경우는 적습니다. 일반적인 I/O-bound 프로그램이 전자에 해당할 것입니다.

CPU Bound - I/O Bound

앞서 프로세스의 생애에 두가지 사이클이 있다고 했습니다.

CPU Bound 프로그램 | CPU Burst한 실행을 하는 프로그램으로 생애동안 CPU 실행 시간이 I/O Wait하는 시간보다 많은 프로그램입니다. 

많은 연산을 필요로하는 작업들 영상, 이미지 처리나 기계학습이 예입니다.

I/O Bound 프로그램 | I/O Bound 프로그램은 그 반대가 되겠죠. DB, Network request/response가 많은 것, 보통의 백엔드 서버를 떠올릴 수 있습니다.

코어가 2개인 싱글 프로세서에서 cpu bound 작업할 때 적절한 스레드 수는 ? core수 + 1개 (일반적으로 CPU 독점을 막기 위해서 preemtive process/thread를 채택합니다. 이 점과 context switch overhead를 고려하면 스레드 수가 많은 것은 오히려 독이 된다는 것을 알 수 있습니다.)
그러면 i/o bound 작업에서는? 시스템 환경을 고려해서 적절한 수를 찾아가는 최적화 작업이 필요합니다!

CPU 1 cycle을 1초라고 했을 때 다른 작업들의 소요 시간을 환산한 것입니다.

보이는 바와 같이 I/O 작업은 CPU 연산 속도에 비교하면 수천 수만 배의 시간이 소요됩니다. 

일반적인 백엔드 서버는 Network I/O 뿐만 아니라 요청을 처리하기 위해서 DB read/write 등 I/O bound한 작업을 주로 합니다. 만약 서버가 싱글 프로세서 싱글 스레드 환경에서 동작한다면, request를 응답하는 동안 cpu는 idle 상태로 아무 것도 하지 않고 놀 것입니다. CPU 효율성을 떠나 요청을 처리하는 동안 다른 요청을 받을 수도 없어 제대로 된 서비스가 불가능할 것입니다.

이런 불상사를 막고 많은 요청을 원활히 처리하기 위해서 이전 포스팅에서 소개한 멀티 태스킹과 비동기 처리가 쓰일 수 있습니다!  (물리적으로 서버를 늘리는 것도 방법이지만... 설마...)