190. 공평 몫 스케줄링 (Fair-share Scheduling)

핵심 인사이트 (3줄 요약)

본질: 공평 몫 스케줄링 (Fair-share Scheduling)은 CPU 자원을 프로세스나 스레드 등 "개별 실행 단위"가 아니라, 그 프로세스들을 소유하고 있는 "사용자(User) 또는 그룹(Group)" 단위로 묶어 지분(Share)을 공평하게 배분하는 거시적 스케줄링 전략이다.

가치: 특정 악성 사용자가 수천 개의 자식 프로세스(Fork Bomb 등)를 고의로 생성하여 시스템 전체 CPU를 독점해 버리는 권력 남용을 구조적으로 원천 차단하고, 다중 사용자 환경에서 완벽한 자원 격리와 계약 보장을 실현한다.

융합: 이 철학은 리눅스 컨테이너 환경의 핵심인 **cgroups (Control Groups)**로 발전하여 클라우드 서비스(Docker, K8s)가 테넌트별 물리 CPU 파이를 쪼개서 분양하는 현대 인프라 아키텍처의 완벽한 뼈대가 되었다.

Ⅰ. 개요 및 필요성 (Context & Necessity)

개념: 기존의 모든 스케줄링(RR, SJF, MLFQ)이 "어떤 프로세스가 불쌍한가? 어떤 프로세스가 짧은가?"만을 쳐다볼 때, 시야를 한 단계 높여 **"이 프로세스들의 주인이 누구인가?"**를 따져, 주인(User) 단위로 부여된 퍼센트(%) 몫을 보장하는 방식이다. 비례 배분 스케줄링(Proportional Share Scheduling)의 한 갈래다.
필요성: 전통적인 라운드 로빈(RR) 환경에서 사용자 A가 프로세스 1개를 띄우고, 사용자 B가 프로세스 99개를 띄우면, CPU는 A에게 1%, B에게 99%를 나눠주는 멍청한 평등을 시전한다. A 입장에서는 같이 돈 내고 서버를 쓰는데 B의 꼼수 때문에 속도가 100배 느려지는 극악의 불합리를 겪게 된다. 이를 막기 위해 프로세스 개수와 무관하게 사용자 기준의 파이(Pie) 쪼개기가 절실했다.
💡 비유: 뷔페식당에서 "사람 수"대로 밥을 주지 않고(기존 방식), "예약한 테이블 단위"로 똑같이 피자 1판씩을 먼저 내려주는(공평 몫) 것과 같다. A 테이블은 혼자서 피자 1판을 다 먹고, 10명이 앉은 B 테이블은 그 1판을 10명이 쪼개 먹어야 하는 엄격한 구역 할당제다.
등장 배경: 메인프레임 시분할 시스템이나 대학교 유닉스 서버에서, 똑똑한 컴퓨터 공학과 학생 한 명이 fork() 폭탄 코드를 짜서 CPU를 무단 점거하여 다른 교수와 학생들의 시스템이 모조리 뻗어버리는 사태가 비일비재하자, 유저 단위의 자원 통제를 위해 유닉스 진영(System V)에서 처음으로 고안되었다.

  [기존 프로세스 기반 vs 사용자 기반(Fair-share) 분배의 치명적 차이]

  (상황: 사용자 A는 프로세스 1개, 사용자 B는 꼼수로 프로세스 9개 띄움)

  [1. 기존 RR 스케줄링 (개체 수 평등)]
  전체 프로세스 10개 ─▶ 각각 10%씩 분배
  ▶ 사용자 A 획득량: 10% 
  ▶ 사용자 B 획득량: 90% (🚨 꼼수로 시스템 90% 강탈 성공! A는 분통 터짐)

  [2. Fair-share 스케줄링 (사용자별 50:50 보장)]
  시스템이 먼저 사용자 단위로 반반(50%) 쪼갬.
  ▶ 사용자 A 획득량: 50% (자신의 1개 프로세스에 50% 통째로 투입. 초고속!)
  ▶ 사용자 B 획득량: 50% (이 50%를 내부의 9개 프로세스가 피 터지게 나눠 가짐)
      └─▶ 꼼수를 써봐야 자기 몫 안에서만 싸우므로 남에게 피해 불가!

[다이어그램 해설] 공평 몫 스케줄링의 혁명적 철학을 완벽히 보여준다. 기존 알고리즘의 눈에는 오직 프로세스라는 말단 병사만 보였기에 머릿수대로 밥을 주어 '의도된 물량 공세'에 무력하게 당했다. 반면 Fair-share는 위에서 내려다보며 장군(User) 단위로 식량을 뭉텅이로 떨어뜨려, 각 진영 안에서 지들이 굶어 죽든 말든 남의 진영(타 사용자)은 절대 침범하지 못하게 철통 방어벽을 세운 것이다.

📢 섹션 요약 비유: 아빠가 유산 100억을 남길 때, 자식 머릿수(프로세스 수)대로 나누는 것이 아닙니다. 첫째 아들 네(User A)에 50억, 둘째 아들 네(User B)에 50억을 던져줍니다. 첫째는 혼자라 50억을 다 쓰고, 둘째는 자식이 10명이라 5억씩 쪼들리게 나눠 가져야 하는 철저한 가문(User) 단위 분배 원칙입니다.

Ⅱ. 아키텍처 및 핵심 원리 (Deep Dive)

계층적(Hierarchical) 동적 우선순위 갱신 알고리즘

공평 몫을 구현하기 위해 운영체제 커널은 단순히 프로세스의 CPU 사용량뿐만 아니라, **"해당 프로세스가 속한 그룹(사용자)의 총 CPU 누적 사용량"**을 함께 계산하는 2차원 회계 장부를 가동한다.

지분 설정 (Share Assignment): 시스템 관리자가 User A: 50%, User B: 50% 등 사전에 그룹별 권리(Weight)를 설정한다.
트래킹 (Usage Tracking): 타이머 인터럽트가 뜰 때마다, 현재 돌고 있는 프로세스의 CPU 사용 시간을 기록하고, 동시에 그 프로세스 주인의 그룹 계좌(누적 사용량)에도 시간을 합산시킨다.
페널티 부과 (Dynamic Priority Decay):
- 특정 그룹의 총사용량이 자신에게 할당된 지분(50%)을 초과하려 하면, 커널은 그 그룹에 속한 **모든 프로세스들의 우선순위를 일제히 수직 하락(Demotion)**시켜 버린다.
- 우선순위가 떨어졌으므로 단기 스케줄러(RR/MLFQ)는 이 그룹의 프로세스들을 레디 큐 바닥으로 유배 보내고, 아직 지분을 못 채운 다른 그룹의 프로세스를 멱살 잡고 끌어올려 CPU를 먹여준다.

  ┌──────────────────────────────────────────────────────────────────────┐
  │        Fair-share 내부의 그룹 연대 책임(Penalty) 메커니즘            │
  ├──────────────────────────────────────────────────────────────────────┤
  │                                                                      │
  │   [그룹 B (목표 지분: 50%)]                                          │
  │   - 소속 프로세스: P1, P2, P3, P4                                    │
  │                                                                      │
  │   1. P1이 CPU를 미친듯이 씀 ─▶ 그룹 B 전체의 누적 사용량 급증!       │
  │   2. 커널 스케줄러: "그룹 B가 지분 50%를 뚫고 60%를 먹으려 하네?"    │
  │   3. [연대 책임 발동] 💥                                             │
  │      P1 때문에 CPU 구경도 못 한 P2, P3, P4의 우선순위까지            │
  │      싸잡아서 몽둥이로 내려쳐 바닥으로 강등시켜 버림.                │
  │   4. 그 사이 그룹 A의 우선순위가 상대적으로 역전되어 CPU 탈환.       │
  │                                                                      │
  │   ✅ 효과: 어떤 꼼수를 써도 그룹 B의 뚝배기를 깨서 50%로 맞춰버림.   │
  └──────────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 이것이 Fair-share의 가장 가혹하면서도 위대한 매커니즘인 '연대 책임'이다. 한 사용자가 프로세스 백만 개를 띄워서 스케줄러를 압도하려 해도, 그 백만 개의 프로세스가 사용하는 순간 그룹 계좌의 잔고가 초당 백만 배로 깎여나간다. 잔고가 바닥나는 순간 백만 개의 프로세스 전체의 우선순위가 -1000으로 처박혀 즉각 정지되므로 시스템 점거는 수리적으로 불가능하다.

📢 섹션 요약 비유: 가족 결합 데이터 요금제와 같습니다. 아빠, 엄마, 아들이 매달 총 50GB를 쓰기로 계약(지분)했는데, 아들이 하루 만에 게임을 다운받느라 50GB를 다 써버리면(CPU 독점), 다음 날부터는 꼼짝없이 아빠와 엄마 핸드폰 데이터까지 모조리 다 끊겨버리는(연대 강등) 무시무시한 연대 책임 스케줄링입니다.

Ⅲ. 융합 비교 및 다각도 분석 (Comparison & Synergy)

일반 비례 할당 (복권/보폭 스케줄링) 과의 차이

공평 몫 스케줄링(Fair-share)과 복권 스케줄링(Lottery)은 같은 "비례 배분(Proportional Share)" 사상을 공유하지만 타겟팅 범위가 다르다.

비교 항목	복권 스케줄링 (Lottery)	공평 몫 스케줄링 (Fair-share)
할당의 기준점	개별 프로세스 단위로 티켓 분배	거시적인 사용자(User) / 그룹 단위 파이 분배
적용 목적	프로세스 간 유연한 자본주의적 양도와 부스트	이웃의 난동(Noisy Neighbor)으로부터 서버 격리
오버헤드	난수 한 번 굴리면 끝남 (매우 가벼움)	그룹 계좌 갱신과 연대 책임 점수 계산으로 인해 몹시 무거움
운영체제 융합	상용 OS 도입 실패	현대 클라우드 Cgroups 아키텍처로 100% 흡수/승리

다단계 큐(MLFQ)와의 환상적인 융합

Fair-share는 혼자서 돌아가는 게 아니라 기존의 다단계 피드백 큐(MLFQ)를 조종하는 보이지 않는 손으로 융합되어 사용된다. MLFQ에서 각 프로세스의 우선순위 번호를 매길 때, 단순히 (기본 점수 - 최근 CPU 사용량) 공식을 쓰던 것에 추가로 **(- 소속 그룹의 누적 사용량)**이라는 폭탄 페널티를 하나 더 더해버리는 식으로 커널에 접목되었다.

📢 섹션 요약 비유: 복권 스케줄러가 시장 바닥에서 개인끼리 티켓을 거래하는 '자유 시장 자본주의'라면, 공평 몫 스케줄러는 정부가 도별로 예산 쿼터를 정확히 잘라 배급하고 초과하면 징수해 버리는 철저한 '계획 통제 경제'입니다. 클라우드 사업자 입장에서는 맘대로 요동치는 자본주의보다, 통제 가능한 계획경제가 훨씬 안전하여 승리하게 되었습니다.

Ⅳ. 실무 적용 및 기술사적 판단 (Strategy & Decision)

실무 시나리오

AWS EC2 / 클라우드 인스턴스의 훔쳐 쓰기 방지 (Noisy Neighbor): 클라우드 제공자(CSP)의 베어메탈 서버 한 대에는 넷플릭스의 가상 머신(VM) 1대와 듣보잡 회사의 VM 3대가 같이 얹혀있다. 넷플릭스가 돈을 50% 냈으므로 CPU의 50%를 받아야 하는데, 듣보잡 회사들이 봇넷을 깔아서 스레드를 무한대로 돌린다 치자.
- 실무 조치: CSP의 하이퍼바이저(Xen/KVM) 내부에 탑재된 Fair-share 스케줄러가 테넌트(사용자 그룹) 단위의 CPU 어카운팅을 감시하다가, 듣보잡 3인방의 지분이 자신들의 쿼터(예: 총합 50%)를 넘으려 하는 찰나에 멱살을 잡고 우선순위를 쓰레기통에 처박아 강제 쓰로틀링(Throttling)을 건다. 이로 인해 넷플릭스는 옆집이 터지든 말든 쾌적하게 50%를 영원히 쓴다.
쿠버네티스 Cgroups (Control Groups) 의 CPU Share: 리눅스 환경의 Docker, K8s는 이 Fair-share 스케줄링의 끝판왕인 cgroups를 사용한다. Pod를 띄울 때 cpu.shares=1024, cpu.shares=512를 주는 행위가 바로 리눅스 커널에게 "내 그룹(Pod)의 몫(Share)을 저 비율 2:1로 찢어서 Fair-share의 연대 책임 룰에 넣어라"라고 명령을 내리는 것이다. 이 값이 없었다면 마이크로서비스 하나가 뻗었을 때 Node 전체가 즉사했을 것이다.

  ┌─────────────────────────────────────────────────────────────────┐
  │     Linux Cgroups의 계층적 Fair-share 아키텍처 의사결정         │
  ├─────────────────────────────────────────────────────────────────┤
  │                                                                 │
  │   [ 리눅스 물리 서버 CPU 100% ]                                 │
  │        │ (Cgroup 기반 계층적 몫 분배)                           │
  │        │                                                        │
  │        ├─ [ 시스템 데몬 그룹 ]  ─── CPU Shares 2048 (66%)       │
  │        │                                                        │
  │        └─ [ 사용자 컨테이너 그룹 ] ── CPU Shares 1024 (33%)     │
  │                 │                                               │
  │                 ├─ [ Nginx 컨테이너 ] ── Shares 512             │
  │                 └─ [ Redis 컨테이너 ] ── Shares 512             │
  │                                                                 │
  │   🚨 튜닝 포인트: 만약 Redis에서 무한 루프 버그가 터져서        │
  │      CPU를 100% 땡겨 쓰려 해도, 리눅스 스케줄러는 부모 그룹의   │
  │      방파제(33%)와 자신의 몫(512)에 의해 막혀, 전체 시스템의    │
  │      16.5% 선에서 Redis의 모가지를 가차 없이 쳐버린다.          │
  └─────────────────────────────────────────────────────────────────┘

[다이어그램 해설] Fair-share는 평면적이지 않다. 현대 리눅스는 이 몫(Share)을 파일 시스템 디렉터리 구조처럼 트리(Tree) 계층으로 무한히 파고들 수 있게 설계했다. 부모 그룹의 제한을 자식 그룹이 절대 뚫을 수 없게 만듦으로써, 한 프로세스의 미친 짓이 시스템 루트(Root)로 전파되는 장애 전이(Cascading Failure) 현상을 OS 커널 레벨에서 원천적으로 폭파시킨 위대한 아키텍처다.

📢 섹션 요약 비유: 타이타닉 호 배 밑바닥에서 구멍이 나 물(버그)이 들어와도, 격벽(Cgroups의 몫 제한)을 꽝 닫아버리면 그 칸(컨테이너)만 물에 잠기고 배 전체(물리 서버)는 멀쩡하게 항해를 계속하는 완벽한 선박 방수 설계와 같습니다.

Ⅴ. 기대효과 및 결론 (Future & Standard)

기대효과

악의적인 사용자나 버그에 빠진 포크 폭탄(Fork Bomb) 프로세스들이 무한 증식하더라도 다른 선량한 사용자의 CPU 할당량을 1%도 침해할 수 없는 "완벽한 테넌트 격리(Multi-Tenant Isolation)" 환경을 제공한다. 클라우드 컴퓨팅과 호스팅 비즈니스를 물리적으로 성립하게 만든 1등 공신이다.

결론 및 미래 전망

공평 몫 스케줄링은 1980년대 멍청한 시분할 유닉스 서버의 기아와 폭주를 막기 위해 개발되었지만, 수십 년이 지난 지금 **모든 가상화(Virtualization) 및 컨테이너(Container) 인프라를 지탱하는 절대 진리(CFS + Cgroups)**로 융합되어 진화의 정점에 도달했다. 미래에는 CPU 사이클뿐만 아니라 LLC(L3 캐시), 메모리 대역폭, 네트워크 I/O 병목까지 하드웨어(Intel RDT 등) 레벨에서 사용자/그룹 단위의 몫(Share)으로 쪼개서 분배하는 '포괄적 하드웨어 Fair-share' 기술로 스케일이 진화하고 있다.

📢 섹션 요약 비유: 과거에는 동네 구멍가게의 식량 배급을 싸우지 않게 나눠주던 작은 장부(Fair-share)였지만, 이제는 아마존과 구글이라는 거대한 전 세계 클라우드 빌딩 숲에서 입주사들의 영토 싸움을 단 1cm의 오차 없이 막아내는 절대적인 헌법 제1조로 승격되었습니다.

📌 관련 개념 맵 (Knowledge Graph)

개념 명칭	관계 및 시너지 설명
Cgroups (Control Groups)	공평 몫 스케줄링의 철학을 리눅스 커널에 트리 구조로 물리적으로 박아 넣어, 프로세스를 사용자 단위로 가둬버린 컨테이너의 핵심 기술이다.
비례 배분 스케줄링 (Proportional Share)	공평 몫 스케줄링을 포함하는 더 상위 개념의 학술적 갈래로, 복권/보폭 스케줄링도 이 가문 출신이다.
CFS (Completely Fair Scheduler)	공평 몫(Share) 철학을 받아들여, 그룹별 가중치(Weight)를 vruntime 계산 수식에 분모로 넣어 무거운 나눗셈 없이 몫을 보장해 낸 현대판 마스터피스다.
다단계 피드백 큐 (MLFQ)	Fair-share는 이 스케줄러의 우선순위 강등 룰에 '사용자 그룹의 죄악(누적시간)'을 더해 넣는 플러그인(Plug-in) 방식으로 초기 유닉스에서 기생하며 동작했다.
자원 격리 (Resource Isolation)	공평 몫 스케줄러가 시스템에 궁극적으로 제공하는 비즈니스적 가치로, 남의 버그가 나에게 번지지 않는 클라우드의 핵심 보안선이다.

👶 어린이를 위한 3줄 비유 설명

뷔페에 온 1번 테이블에는 1명, 2번 테이블에는 10명이 앉았어요. 예전 규칙(RR)은 11명에게 똑같이 피자를 1조각씩 주니까, 10명이 짜고 쳐서 피자를 싹쓸이했어요.
억울함을 막기 위해 만든 공평 몫 스케줄링은 사람 수가 아니라 "예약한 테이블 단위"로 피자 1판씩을 툭 얹어주는 완벽한 분배 방식이에요.
꼼수를 부려 10명, 100명을 데려온 나쁜 테이블도 자기 테이블에 놓인 피자 1판만 피 터지게 나눠 먹어야 하니까, 옆에 1명 앉은 테이블의 평화를 절대 뺏어갈 수 없는 최고로 안전한 규칙이랍니다!