[Performance 06] Introduction: OS·런타임 Low-latency 운영환경

이 트랙은 “코드는 빠른데 프로세스가 느린 이유"를 운영환경에서 찾고 고칩니다. µs 단위에서는 context switch, syscall, 스케줄링 정책, 코어 배치가 지연시간의 바닥을 결정합니다.

이 트랙이 책임지는 범위

애플리케이션이 커널·스케줄러와 맞닿는 지점에서 발생하는 비용을 다룹니다. 다음 다섯 가지가 그 접점입니다.

• context switch 비용과 회피 전략(스레드/코어 배치)
• syscall 비용과 경로 단축(가능한 범위의 사용자 공간 설계)
• CPU pinning/affinity 전략, NUMA 고려
• realtime scheduling의 개념과 적용 시 고려사항
• 타이밍/클럭/시간 측정 이슈(정확한 시간 기반 검증)

이 트랙이 다루지 않는 것 (경계)

이 트랙은 커널이 제공하는 설정·API를 어떻게 쓸지까지만 다루고, 커널 자체를 고치거나 다른 트랙의 범위와 겹치는 하드/소프트 최적화는 넘깁니다.

• 커널/스케줄러 구현을 직접 수정하는 수준의 튜닝 (→ 필요 시 별도 심화)
• C++ 언어/컴파일러/데이터 구조 자체의 최적화 상세 (→ 각 트랙)
• CPU 전력 관리(C-state/P-state, cpuidle/cpufreq governor)와 tickless 커널(NOHZ_FULL)·RCU 콜백 오프로드 튜닝 — 이 트랙의 스케줄링·affinity 챕터와 맞닿아 있지만, 커널 부팅 파라미터·전력 정책 자체의 심화 튜닝은 이 커리큘럼에 포함되지 않습니다. sched(7) 공식 문서를 참고하세요.

흔히 “코어를 고정(affinity)하면 항상 더 빨라진다"고 생각하기 쉽지만, 이는 오개념입니다. 잘못된 코어에 스레드를 고정하면 오히려 캐시 지역성이 나빠지거나(예: NUMA 원격 노드에 고정), 같은 코어를 다른 워크로드와 경합시켜 p99가 악화될 수 있습니다. 03·04번 챕터에서 다루는 것처럼, affinity는 “무조건 적용"이 아니라 토폴로지를 먼저 파악한 뒤 측정으로 검증해야 하는 전략입니다.

커리큘럼

난이도 범례: 기초(입문) · 중급(실무 핵심) · 심화(깊은 분석·전문 주제) · 전문(극한·니치). Tr.NN은 optimization-NN-* 트랙을 가리킵니다. 개요(본 트랙) 행은 동일 주제의 심화가 Tr.09(I/O)·Tr.10(네트워크) 등에 있음을 뜻합니다.

운영환경 최적화가 처음이라면 16 → 01 → 02 → 03 → 06 → 11 순서로 읽는 것을 권장합니다. 16은 process/thread의 기본 mental model을 맞추고, 01–03과 06은 context switch·syscall·affinity·시간 측정의 바닥 비용을 먼저 이해하게 해 줍니다. 그 위에서 04–05, 10, 12–18의 심화 주제를 읽으면 훨씬 덜 가파릅니다.

이 문서에서 표 순서를 유지하는 이유는 참조성과 경계 설명 때문입니다. 07~09처럼 “개요(본 트랙)” 성격의 장과 이후 심화 장을 장 번호 기준으로 찾기 쉬워야 하므로, 표는 지도 역할을 맡고 위 추천 순서는 입문자용 진입 경로를 설명합니다.

측정과 검증 (이 트랙 기준)

운영환경 설정은 코드와 달리 배포된 하드웨어·커널 버전에 따라 효과가 달라지므로, 코드 트랙보다 “같은 조건에서 재현했는가"를 더 엄격하게 따집니다.

• 운영환경 변경(affinity/scheduler) 전후 레이턴시 분포 비교
• 동일 하드웨어에서 재현 가능한 기준선 확보(변수 최소화)
• 시스템 레벨 회귀를 자동화(환경/런타임 설정 포함)

추천 선행/병행 트랙

이 트랙의 설정 변경이 실제로 유의미한지 판단하려면 측정 도구가 먼저 있어야 하고, 스케줄링 이슈는 종종 락 경합·CPU 이벤트와 뒤섞여 나타나므로 인접 트랙과 함께 읽는 편이 유리합니다.

• 선행: Low-latency 프로파일링·성능 분석 (Tr.01)
• 병행: 동시성 (Tr.07), CPU 마이크로아키텍처 (Tr.05)

플랫폼별 읽기 힌트

같은 주제라도 Linux와 Windows는 API·도구가 다르므로, 운영체제에 따라 커리큘럼을 도는 순서를 다르게 잡는 것이 효율적입니다.

• Linux 중심 독자는 01–03, 06, 07–10, 12–14를 먼저 읽으면 syscall·affinity·io_uring·IRQ·cgroups 흐름이 자연스럽습니다.
• Windows 중심 독자는 06, 11, 15를 먼저 읽고, 02·03을 “시스템 호출 경로와 스레드 배치” 관점에서 대응시켜 읽으면 ETW/IOCP 같은 Tr.01·Tr.09 주제와 연결하기 쉽습니다.

왜 이 트랙인가 (동기)

애플리케이션 코드와 빌드 설정을 다듬은 뒤에도, 스케줄링·시스템 콜·IRQ·컨테이너 오버헤드가 바닥 지연을 지배할 수 있습니다. 특히 실시간에 가까운 목표에서는 affinity 한 줄이 평균보다 꼬리 지연에 더 큰 영향을 줍니다. 이 트랙은 커널 구현을 고치는 범위가 아니라, 운영 가능한 설정과 측정으로 지연 분포를 안정화하는 데 초점을 둡니다.

Phase별 학습 궤적

Phase A — 컨텍스트와 syscall (챕터 01–03, 06) 비용의 “바닥”을 이해하고 측정합니다.

Phase B — NUMA·실시간·고정 (챕터 04–05, 10, 14) Tr.04 메모리 할당·Tr.07 경합과 맞물립니다. 건너뛰면 NUMA 머신에서 이상하게만 느린 코어만 남기도 합니다.

Phase C — 커널 바이패스·고급 주제 (챕터 07–09, 11–13, 15–18) 챕터 07–09는 개요(본 트랙)이며, io_uring·XDP/eBPF·DPDK의 심화 실전은 Tr.09·Tr.10에서 이어집니다. 챕터 17–18은 클라우드 및 eBPF 환경의 특수 운영 주제를 다룹니다.

이 트랙을 마친 후 달성할 목표

• 설명: context switch·syscall·affinity가 지연에 미치는 영향을 말로 설명할 수 있다.
• 적용: 배포 환경에서 재현 가능한 방식으로 affinity·스케줄 정책을 시험할 수 있다.
• 연계: Tr.09·Tr.10로 넘길 때 “개요에서 무엇을 이미 알았는지”를 정리할 수 있다.
• 경계: 커널 소스 수정 수준의 튜닝은 범위 밖임을 팀과 합의할 수 있다.

평가 기준과 이 장을 읽은 후 확인

위 목표를 “설명할 수 있다"에서 그치지 않고, 실제로 아래를 실습해봤는지 스스로 점검합니다.

• 동일 바이너리에서 affinity·스케줄 정책만 바꿔 레이턴시 분포 변화를 실제로 측정해 봤는가?
• taskset/numactl 등으로 코어를 고정하고, 고정 전후 p99를 비교해 본 적이 있는가?
• NUMA 머신에서 “이상하게 느린 코어"를 원격 메모리 접근으로 진단해 본 적이 있는가?

범위와 경계

flowchart LR
  subgraph inScope [이 트랙]
    A["syscall·컨텍스트"]
    B["affinity·NUMA"]
    C["io_uring·XDP 개요"]
  end
  subgraph outScope [경계 밖]
    D["파일 심화 Tr.09"]
    E["네트워크 심화 Tr.10"]
    F["커널 패치"]
  end
  inScope --> outScope

심화·전문가 확장 궤적

IRQ·cgroups·mlock 등은 운영 권한과 워크로드에 강하게 의존합니다. 심화 난이도 챕터는 스테이징에서 지표·분포를 확보한 뒤 적용하세요.

시리즈 전체 로드맵

12개 트랙의 권장 순서·심화 진입 조건은 Low-latency 최적화 시리즈 개요를 참고하세요.

지금 바로 이어 읽을 곳

01 → 02 → 03 → 16 순으로 읽으면 컨텍스트 스위치·syscall 비용의 기초에서 프로세스/스레드 아키텍처 선택까지 이어집니다.

• Context Switch 비용 분석과 회피 (챕터 01)
• Syscall 비용과 최소화 기법 (챕터 02)
• CPU Pinning/Affinity 전략 (챕터 03)