[CS] Context Switching이란?

Hyunjun Kim·2025년 5월 17일

Computer_Science

목록 보기

6/19

Context Switching: 성능 병목의 실체

1. 왜 Context Switching을 알아야 할까?

'Context switching'은 많은 개발자에게 익숙한 용어지만, 그 구체적인 과정과 성능 병목의 원인으로서의 중요성은 종종 간과된다. 단순히 "스레드 전환" 정도로 이해하고 넘어가는 경우가 많지만, 백엔드 서버나 고성능 시스템을 다룰 때 context switching은 성능 최적화의 핵심 요소다. 특히 병렬성과 동시성이 중요한 환경에서는 context switching의 이해 여부가 시스템 설계의 품질을 좌우할 수 있다.

이 문서에서는 context switching의 개념, 발생 원인, 성능에 미치는 영향, 그리고 이를 최소화하기 위한 실무 전략을 체계적으로 다룬다.

2. Context Switching의 개념 이해

2.1 Context Switching이란?

현대 멀티코어 CPU는 여러 작업이 동시에 실행되는 것처럼 보이지만, 실제로 하나의 CPU 코어는 한 번에 하나의 작업만 처리할 수 있다. 여러 작업이 동시에 실행되는 것처럼 보이는 이유는 context switching 때문이다.

Context switching은 운영체제가 현재 실행 중인 프로세스 또는 스레드의 상태(context)를 저장하고, 다음 작업의 상태를 복원하여 CPU에 전달하는 과정이다. 예를 들어, CPU가 작업 A를 실행하다가 작업 B로 전환해야 할 때, A의 상태를 저장하고 B의 상태를 불러와 교체한다.

2.2 왜 필요한가? – 멀티태스킹과 스케줄링

컴퓨터는 웹 브라우징, 알림 처리, 서버 요청 처리 등 다양한 작업을 동시에 수행해야 한다. CPU는 물리적으로 한 번에 하나의 작업만 처리하므로, 멀티태스킹을 위해 작업 간 전환이 필요하다. 운영체제는 시분할 스케줄링을 통해 작업들에게 공정한 실행 시간을 할당하며, 이 과정에서 context switching이 발생한다.

2.3 Context에는 어떤 정보가 담기는가?

Context switching은 CPU의 실행 상태를 저장하고 복원하는 과정으로, 다음과 같은 정보가 포함된다:

항목	설명
프로그램 카운터 (PC)	다음에 실행할 명령어의 주소
레지스터	연산에 필요한 값들을 담는 CPU 내부 저장소
스택 포인터 (SP)	현재 함수 호출 스택의 위치
메모리 매핑 정보	해당 프로세스의 가상 메모리 구조
프로세스 상태	실행 중, 대기 중, 블록 등
기타 제어 정보	인터럽트, 권한, I/O 상태 등

3. Context Switching은 언제 발생하는가?

Context switching은 다양한 상황에서 발생하며, 주요 원인은 다음과 같다:

3.1 인터럽트 기반 전환

하드웨어 인터럽트(키보드 입력, 네트워크 수신 등)가 발생하면 CPU는 현재 작업을 중단하고 인터럽트 핸들러로 전환한다. 이 과정에서 context switching이 발생한다.

3.2 시분할(Time-slicing) 스케줄링

운영체제는 각 프로세스에 일정 시간(time quantum)을 할당하고, 시간이 만료되면 다음 프로세스로 전환한다. 이 전환 과정에서 context switching이 수행된다.

3.3 I/O Wait 시의 전환

프로세스가 디스크 읽기, 네트워크 통신 등 느린 I/O 작업을 수행할 때, CPU는 대기하지 않고 다른 작업으로 전환한다. 이 역시 context switching을 유발한다.

4. Context Switching의 작동 원리: 내부 동작 과정

Context switching은 다음과 같은 단계로 진행된다:

4.1 인터럽트 감지

// Pseudo code
while (true) {
    if (interrupt_received()) {
        save_current_context();
        load_new_context();
    }
}

하드웨어 인터럽트가 발생하면 CPU는 인터럽트 벡터 테이블을 통해 적절한 핸들러로 진입한다.

4.2 현재 상태 저장

운영체제는 현재 작업의 context를 PCB(Process Control Block)에 저장한다. PCB는 다음과 같은 정보를 포함한다:

struct PCB {
    int process_id;
    int program_counter;
    int stack_pointer;
    RegisterSet registers;
    ProcessState state;
};

4.3 다음 작업 불러오기

스케줄러가 다음 실행할 프로세스를 선택하고, 해당 PCB에서 context를 복원한다.

4.4 상태 복원 및 실행

복원된 context는 CPU 레지스터에 로드되며, CPU는 이전 작업을 이어가듯 새로운 작업을 실행한다.

5. Context Switching이 성능에 미치는 영향

Context switching은 멀티태스킹을 가능하게 하지만, 성능에 부정적인 영향을 줄 수 있다. 주요 오버헤드 요인은 다음과 같다:

5.1 PCB 저장/복원 오버헤드

PCB에 context를 저장하고 복원하는 과정 자체가 CPU 시간을 소모한다.

5.2 CPU 캐시 무효화

작업 전환 시 이전 작업의 L1/L2 캐시 데이터가 무효화되고, 새 작업은 캐시를 새로 채워야 한다. 이로 인해 캐시 미스가 증가하고 성능이 저하된다.

5.3 시스템 콜과 커널 모드 전환

Context switching은 커널 모드와 사용자 모드 간 전환을 동반하며, 메모리 보호와 권한 검사로 추가 오버헤드가 발생한다.

5.4 과도한 전환 비용

초당 수천 번의 context switching이 발생하면, CPU가 실제 작업보다 전환에 더 많은 시간을 소모할 수 있다. 예를 들어, Linux에서 vmstat 명령어로 context switching 횟수를 확인할 수 있다:

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 123456  7890  34567    0    0     1     1    4  4000 20 10 70  0  0
# cs 컬럼: 초당 context switching 횟수

6. 실무 사례로 본 Context Switching 문제

6.1 Apache Spark에서의 병목

Apache Spark는 대용량 데이터 처리를 위한 분산 프레임워크지만, 잘못된 설정은 context switching 비용을 증가시킨다. 예를 들어, 1억 건 데이터를 1만 개 파티션으로 나누면 executor가 수천 개의 태스크를 빠르게 전환하며 OS 수준의 thread/process switching이 빈번해진다. 이는 캐시 미스와 성능 저하로 이어진다.

개선 방안:

repartition() 또는 coalesce()를 사용해 파티션 수를 CPU 코어 수에 맞게 조정
Executor와 코어 설정을 최적화하여 오버 프로비저닝 방지
task deserialization time, scheduler delay 지표로 전환 오버헤드 분석

6.2 Airflow DAG의 과도한 병렬성

Airflow는 워크플로우 스케줄러로, 병렬 실행이 가능하지만 parallelism, dag_concurrency, max_active_runs 설정이 과도하면 context switching 병목이 발생한다. 특히 KubernetesExecutor 사용 시 Pod 간 전환과 컨테이너 자원 할당으로 오버헤드가 증가한다.

개선 방안:

병렬성 설정을 작업 성격에 맞게 제한하고, I/O 작업을 Batch 처리
Sensor 사용 최소화 및 airflow statsd exporter로 지표 모니터링
DAG 설계 시 작업 그룹핑으로 전환 빈도 감소

6.3 JupyterLab과 Pandas의 성능 저하

JupyterLab과 Pandas는 싱글 스레드 기반이지만, 대규모 데이터 연산(예: groupby().apply()) 시 context switching이 간접적으로 영향을 미친다. 특히 다른 작업(웹 브라우징, 시각화 등)이 병렬로 실행되면 OS가 자원을 분산시키며 전환 빈도가 증가한다.

개선 방안:

modin.pandas 또는 dask로 멀티프로세싱 전환
대형 연산은 외부 스크립트로 실행하여 자원 집중
중간 결과 캐싱으로 반복 연산 최소화

7. Context Switching 이슈를 피하기 위한 전략

Context switching의 오버헤드를 줄이기 위해 다음과 같은 전략을 적용할 수 있다:

7.1 비동기 처리 구조 설계

Python 환경: asyncio, aiohttp, FastAPI 사용 시 await 지점을 명확히 정의하고, blocking I/O를 최소화
동기 작업은 ThreadPoolExecutor 또는 ProcessPoolExecutor로 분리
비동기 작업과 동기 작업의 혼합으로 인한 전환 비용 방지

7.2 작업 단위 최적화

과도한 세분화 피하기: 작업이 너무 잘게 나뉘면 전환 비용이 증가한다. 예를 들어, Spark의 파티션 수를 적절히 조정하거나 Airflow의 태스크를 묶어 처리
데이터 처리: Pandas의 고비용 연산은 modin 또는 dask로 분산 처리
작업 단위를 적절히 묶어 전환 빈도를 줄이고 처리 시간을 확보

7.3 자원 기반 병렬성 조절

스레드/프로세스 수 제한: CPU 코어 수보다 많은 스레드는 캐시 경쟁을 유발한다. 일반적으로 (CPU 수 × 2) + 1 또는 워크로드 특성에 맞게 조정
Spark/Airflow 설정: 코어 수와 작업 부하에 맞춘 worker/process 수 설정
스레드 affinity: 특정 워크로드에 맞게 스레드를 특정 코어에 고정

7.4 스케줄러 및 자원 모니터링

스케줄러 튜닝: OS의 CFS, FIFO, RR 등 스케줄링 정책을 워크로드에 맞게 조정
모니터링 도구 활용: htop, vmstat, top, Spark UI, Airflow Metrics로 context switching 횟수와 병목 지점 확인
지표 분석: scheduler delay, task deserialization time 등을 통해 전환 비용 모니터링

7.5 I/O와 CPU 작업 분리

I/O 작업은 비동기 처리 또는 별도의 executor로 분리하여 CPU 작업과의 혼합을 방지
예: Airflow에서 I/O 기반 태스크를 Batch 처리하거나, Spark에서 shuffle 작업 최적화

8. 정리 및 결론

항목	요약
정의	실행 중인 프로세스/스레드를 바꾸기 위한 상태 저장 및 복원 과정
발생 조건	인터럽트, 시분할, I/O 대기 등
저장 내용	레지스터, 프로그램 카운터, 스택 포인터 등
장점	멀티태스킹을 가능하게 하여 자원 효율성 증대
단점	캐시 무효화, 커널 모드 전환 등으로 성능 저하

Context switching은 멀티태스킹의 핵심이지만, 빈번한 전환은 성능 병목을 유발한다. 고성능 서버나 동시성 시스템 설계 시 전환 비용을 고려한 구조적 설계가 필수적이다. 단순히 worker 수를 늘리거나 작업을 세분화하는 것은 오히려 성능 저하로 이어질 수 있다.

핵심은 균형이다. 시스템 자원, 작업 특성, 스케줄링 전략을 종합적으로 고려하여 context switching의 오버헤드를 최소화해야 한다. 이를 통해 하드웨어의 잠재력을 최대한 활용하고, 안정적이고 효율적인 시스템을 구축할 수 있다.

Hyunjun Kim

Data Analytics Engineer 가 되

이전 포스트

[CS] 동기와 비동기의 차이, Nginx 구조로 쉽게 이해하기

다음 포스트

[CS] Context Switching이란?

Computer_Science

Context Switching: 성능 병목의 실체

1. 왜 Context Switching을 알아야 할까?

2. Context Switching의 개념 이해

2.1 Context Switching이란?

2.2 왜 필요한가? – 멀티태스킹과 스케줄링

2.3 Context에는 어떤 정보가 담기는가?

3. Context Switching은 언제 발생하는가?

3.1 인터럽트 기반 전환

3.2 시분할(Time-slicing) 스케줄링

3.3 I/O Wait 시의 전환

4. Context Switching의 작동 원리: 내부 동작 과정

4.1 인터럽트 감지

4.2 현재 상태 저장

4.3 다음 작업 불러오기

4.4 상태 복원 및 실행

5. Context Switching이 성능에 미치는 영향

5.1 PCB 저장/복원 오버헤드

5.2 CPU 캐시 무효화

5.3 시스템 콜과 커널 모드 전환

5.4 과도한 전환 비용

6. 실무 사례로 본 Context Switching 문제

6.1 Apache Spark에서의 병목

6.2 Airflow DAG의 과도한 병렬성

6.3 JupyterLab과 Pandas의 성능 저하

7. Context Switching 이슈를 피하기 위한 전략

7.1 비동기 처리 구조 설계

7.2 작업 단위 최적화

7.3 자원 기반 병렬성 조절

7.4 스케줄러 및 자원 모니터링

7.5 I/O와 CPU 작업 분리

8. 정리 및 결론

[CS] 동기와 비동기의 차이, Nginx 구조로 쉽게 이해하기

자료구조 및 알고리즘 면접 예상 문제 + 정리

0개의 댓글