Starvation

Starvation

Starvation(기아 상태) 은 동시성 환경에서 특정 프로세스나 스레드가 자원을 장기간 할당받지 못해 무한히 대기하게 되는 현상이다.
주로 우선순위 기반 스케줄링, 불공정한 자원 접근, 락 경쟁 등에서 발생하며, 시스템은 작동하나 일부 작업은 실행되지 않아 Liveness 를 침해한다.
Deadlock 과 달리 전체 시스템이 멈추지는 않지만, 처리량과 공정성에 악영향을 준다.

예방책으로는 Aging, 공정한 스케줄링 (CFS, Fair Lock), 자원 예약, 우선순위 재조정 등이 있으며, 운영체제, DBMS, 분산 시스템 등에서 중요한 동시성 제어 이슈로 다뤄진다.

핵심 개념

1. Starvation(기아 상태): 실행 흐름이 자원을 무기한 할당받지 못해 실행되지 못하는 상태
2. 공정성 (Fairness): 자원이 모든 프로세스에게 균등하게 배분되어야 한다는 원칙
3. 우선순위 역전 (Priority Inversion): 낮은 우선순위 작업이 높은 우선순위 작업의 실행을 막는 현상
4. 에이징 (Aging): 대기 시간이 길어질수록 우선순위를 높여 Starvation 을 방지하는 기법
5. Fair Lock (공정한 락): 락을 요청한 순서에 따라 공평하게 자원을 할당하는 구조
6. Liveness & Starvation-Free: 시스템이 멈추지 않고 모든 작업이 결국 실행되어야 하는 성질
7. Finite Bypass (유한 우회): 어떤 프로세스도 자원 접근이 무한히 지연되면 안 됨
8. 스케줄링 정책: 자원의 할당 방식에 따라 Starvation 여부가 결정됨

핵심 개념과 실무 구현 연관성 정리

Starvation(기아 상태) 은 동시성 환경에서 특정 실행 흐름이 자원을 할당받지 못해 무한히 대기하는 현상이다.
주로 우선순위 기반 스케줄링이나 불공정한 락 획득에서 발생하며, 시스템 공정성과 응답성을 저하시킨다. 이를 해결하기 위해 Aging, Fair Lock, 우선순위 역전 방지, Finite Bypass 등을 적용한다.
운영체제, 데이터베이스, 분산 시스템 등에서 Starvation 방지는 시스템 안정성과 성능 확보를 위해 필수적이다.

기초 이해 (Foundation Understanding)

개념 정의 및 본질

정의:

• Starvation(기아 상태) 은 병렬 또는 동시성 시스템에서 하나 이상의 프로세스 또는 스레드가 필요한 자원이 있음에도 불구하고, 특정 자원 할당 정책 또는 스케줄링 우선순위의 불균형으로 인해 자원을 무한히 할당받지 못해 실행되지 않는 상태를 말한다.

본질적 특성:

• 무한 대기 (Indefinite Waiting): 자원은 충분히 존재하지만, 특정 실행 흐름은 자원을 할당받지 못해 무기한 대기
• 불공정성 (Unfairness): 자원 분배 정책의 편향성으로 특정 작업이 반복적으로 제외됨
• 시스템 활성성 유지 (System Liveness): 시스템 전체는 계속 동작하지만, 특정 실행 흐름만 진행되지 않음
• 라이브니스 (Liveness) 속성 위반: 모든 실행 흐름은 결국 진전되어야 한다는 원칙에 위배됨
• Deadlock 과의 차이: Deadlock 은 모든 실행 흐름이 멈추지만, Starvation 은 일부만 멈추고 나머지는 정상 수행

발생 가능한 자원 범위:

• CPU, 메모리, 네트워크 대역폭, 디스크, I/O 장치, 락 및 세마포어 등 모든 공유 자원에서 Starvation 이 발생할 수 있음

등장 배경 및 발전 과정

등장 배경

• 동시성 환경의 등장: 1960 년대 멀티프로그래밍 시스템 도입으로 다양한 실행 흐름이 동시에 자원을 요청하게 되며 자원 충돌 및 대기 문제 발생
• 우선순위 기반 스케줄링의 한계: CPU 우선순위 방식이 도입되면서 낮은 우선순위 프로세스의 무한 대기가 현실화됨
• 다익스트라의 문제 제기: 1965 년 세마포어 및 Dining Philosophers 문제를 통해 이론적으로 기아 상태가 처음 구조화됨
• 현실적 사례: MIT IBM 7094 시스템에서 우선순위 스케줄링으로 인해 프로세스가 수년간 실행되지 못한 사례가 보고됨

발전 과정

• 1970 년대: Round-Robin, 에이징 (Aging) 등 공정성 확보를 위한 스케줄링 기법 연구 시작
• 1980~90 년대: 실시간 시스템 (RTOS) 에서 우선순위 역전 (Priority Inversion) 및 기아 현상 해결이 핵심 과제로 부각
• 2000 년대: 멀티코어 환경 확산 → 공정한 락 (Fair Lock), CFS 등 실무 시스템에서 기아 방지 알고리즘 채택
• 2010 년대~현재: 클라우드, 컨테이너 기반 시스템 (Kubernetes, Serverless 등) 에서 QoS 기반 자원 정책이 기아 현상의 원인이자 해결점으로 작용함

발생 원인 및 문제 상황

graph TD
    A[자원 요청] --> B[우선순위 기반 스케줄러]
    B --> C{낮은 우선순위?}
    C -- Yes --> D[대기 큐로 이동]
    D --> E[다른 태스크에게 계속 선점]
    E --> F[자원 획득 실패 반복 → Starvation 발생]

발생 원인

Starvation 은 스케줄링 우선순위의 불균형, 자원 경합, 락의 불공정성, 정책 부재, 자원 누수, 그리고 악의적 부하와 같은 다양한 기술적 조건에서 발생할 수 있다. 특히 이러한 원인들은 대부분 자원 분배의 불공정성에 뿌리를 두고 있으며, 시스템 수준에서 적절한 보정 메커니즘 없이 방치될 경우 기아 현상으로 이어진다.

문제 상황

Starvation 은 단일 태스크의 무한 대기뿐 아니라 전체 시스템의 응답 지연, 처리량 감소, 자원 불균형, 서비스 불안정 등 다양한 성능 및 신뢰성 문제로 확산될 수 있다. 특히 공정성의 저하는 사용자 경험과 직결되며, 장기적으로는 서비스 가용성에 악영향을 줄 수 있다.

주요 특징

Starvation 은 시스템이 계속 동작함에도 특정 작업이 자원을 할당받지 못하고 무기한 지연되는 비결정적이고 탐지 어려운 동시성 문제이다.
이는 우선순위 기반 스케줄링이나 락 경합 구조의 불균형에서 발생하며, 공정성 저하, 응답 지연, 시스템 처리량 감소 등의 실질적인 성능 저하로 이어진다.
Deadlock 과 달리 자원의 상호 의존성이 없고 런타임에서 Aging, Fair Lock, 스케줄링 정책 변경 등을 통해 해결 가능하다.
특히 시스템 설계 초기부터 이러한 특성을 고려한 예측 가능한 스케줄링 전략 수립이 중요하다.

핵심 이론 (Core Theory)

핵심 설계 원칙

1. 공정성 (Fairness)

   • 모든 실행 흐름이 자원 접근 기회를 고르게 가질 수 있어야 하며, 선점 스케줄링에서도 이 원칙이 반영되어야 함

2. 라이브니스 (Liveness)

   • 시스템이 계속 진행될 수 있도록 보장되어야 하며, 어떤 작업도 무한히 차단되면 안 됨

3. 우선순위 역전 방지 (Priority Inversion Prevention)

   • 낮은 우선순위 작업이 고우선순위 작업을 차단하지 않도록 Priority Inheritance 등을 사용

4. Bounded Waiting (유한 대기 보장)

   • 어떤 프로세스도 유한 횟수 이상 자원 요청에서 밀려서는 안됨

5. 자원 할당 예측 가능성 (Predictability)

   • 시스템은 최대 대기 시간이나 자원 할당 시점을 예측할 수 있어야 하며, 특히 실시간 시스템에 필수

6. 비선점 제어 (Controlled Preemption)

   • 선점형 스케줄링일 경우, 지속적인 선점으로 특정 작업이 starvation 에 빠지지 않도록 빈도를 제어해야 함

• 공정성 (Fairness) 은 starvation 방지의 핵심 원칙으로, 자원 분배와 기회 제공의 균형을 통해 모든 태스크가 합리적 시간 내 실행될 수 있도록 한다.

• 라이브니스 (Liveness) 는 시스템이 멈추지 않고 모든 작업이 실행 가능함을 보장하는 설계 기준이며, starvation 은 이 원칙의 위반이다.

• 우선순위 역전 방지는 낮은 우선순위 태스크가 시스템 전체 흐름을 막지 않도록 하기 위한 보호장치이며, 실시간 시스템에서 중요하다.

• Bounded Waiting은 무한 대기를 구조적으로 차단하는 기준이며, Starvation-Free 시스템의 근간이 된다.

• Predictability는 특히 실시간 시스템이나 QoS 보장이 필요한 환경에서 자원 할당의 신뢰성을 높이는 데 필수적이다.

• Controlled Preemption은 선점 정책이 오히려 starvation 을 유발하지 않도록 빈도나 우선순위를 동적으로 조절하는 메커니즘이다.

기본 원리 및 동작 메커니즘

기본 원리

Starvation 은 우선순위 기반 또는 자원 경합 상황에서 특정 작업이 반복적으로 자원을 할당받지 못하면서 무한 대기에 빠지는 현상이다. 이는 정책적 불공정성, 자원 독점 구조, 그리고 반복 요청 구조에 의해 강화되며 시스템의 일부 작업이 무기한 실행되지 않는 문제를 초래한다. 외형상 시스템은 정상 동작하므로 탐지와 해결이 지연될 수 있으며, 스케줄러 설계 및 락 정책이 주요 원인이 된다.

동작 메커니즘 흐름

sequenceDiagram
    participant LP as 낮은 우선순위 프로세스 (P1)
    participant HP as 높은 우선순위 프로세스 (P2, P3, …)
    participant SCHED as 스케줄러
    participant RES as 자원

    LP->>SCHED: 자원 요청
    SCHED-->>LP: 대기 (낮은 우선순위)

    loop 반복
        HP->>SCHED: 자원 요청
        SCHED->>RES: 자원 할당
        RES-->>HP: 자원 사용
        SCHED-->>LP: 대기 유지
    end

    Note over LP: 높은 우선순위 프로세스의 지속적 선점으로 인해 P1은 무한 대기  

**낮은 우선순위 프로세스 (P1)**가 자원을 요청하지만, 지속적으로 도착하는 높은 우선순위 프로세스 (P2, P3 등) 에 의해 자원이 계속 선점되는 구조를 표현한다.
스케줄러는 항상 높은 우선순위의 프로세스에 자원을 할당하고, 낮은 우선순위 프로세스는 반복적으로 대기만 하게 된다.
이러한 순환 구조가 지속되면 P1 은 실행 기회를 얻지 못한 채 무기한 대기 상태, 즉 Starvation 상태에 빠지게 된다.
겉보기에는 시스템이 정상적으로 작동하지만, 내부적으로는 특정 작업이 영원히 처리되지 않는 비활성 문제가 발생하는 것이다.

아키텍처 및 구성 요소

graph TB
    subgraph Application Layer
        T1["작업 요청(Task/Thread)"]
    end

    subgraph Scheduling Layer
        A1[Scheduler]
        A2[Priority Queue]
        A3[Aging Engine]
        A4[Policy Manager]
    end

    subgraph Resource Layer
        B1[Resource Manager]
        B2[Fair Lock / Semaphore]
        B3[Resource Pool]
        B4[Reservation Manager]
        B5[Resource Leak Detector]
    end

    subgraph Monitoring Layer
        C1[Fairness Monitor]
        C2[Logging / Alerting]
    end

    T1 --> A1
    A1 --> A2
    A2 --> A3
    A3 --> A4
    A1 --> B1
    B1 --> B2
    B1 --> B3
    B3 --> T1

    B1 --> B4
    B1 --> B5

    A1 --> C1
    C1 --> C2
    C2 --> A4

Starvation 방지 또는 완화는 시스템 구조 차원에서 다음과 같은 구성 요소 간의 협업을 필요로 한다:

• 핵심 흐름은 스케줄러 → 우선순위 조정 → 자원 할당으로 이어지며, 여기서의 공정성이 보장되지 않으면 Starvation 이 발생한다.
• 선택적 구성요소인 에이징, 리소스 예약, 정책 관리자, 공정 큐잉 등은 Starvation 완화를 위한 전략적 도구로 기능하며, 모니터링 시스템은 이상 징후를 조기에 탐지해 대응을 유도한다.
• 아키텍처적으로는 Application → Scheduling → Resource → Monitoring 흐름을 따라 설계되며, 각 계층 간 책임이 명확히 구분되어야 Starvation 예방이 구조적으로 가능해진다.

아키텍처 구성 요소

주요 기능과 역할

기능과 역할 간 관계 정리

Starvation 을 방지하거나 완화하기 위해 시스템은 자원 할당, 우선순위 관리, 락 동기화, 모니터링, 정책 실행 등 다양한 기능을 수행한다.
이 기능들은 스케줄러, 리소스 관리자, 락 제어기, 감시자 등 시스템 내 서로 다른 주체들이 맡아 수행하며, 각 기능은 " 공정성 유지 “, " 대기 시간 보장 “, " 자원 독점 방지 " 등의 역할을 달성하기 위해 존재한다.
기능은 시스템이 무엇을 하는가를 나타내며, 역할은 왜 그 기능이 필요한가에 대한 목적을 명확히 해준다.
이 둘의 연결을 이해하면 Starvation 문제를 구조적으로 파악하고 설계 수준에서 대응할 수 있다.

특성 분석 (Characteristics Analysis)

예방 및 해결 방안

Starvation 을 효과적으로 방지하고 해결하기 위해 시스템은 **자원 분배의 공정성 (Fairness)**과 **대기 시간에 따른 실행 보장 (Liveness)**을 균형 있게 유지해야 한다.

• 예방 측면에서는 Aging, 공정한 스케줄링, 우선순위 역전 방지, 자원 예약 등이 대표적이며, 이는 기아 상태 자체가 발생하지 않도록 설계하는 전략이다.
• 해결 측면에서는 Timeout, 선점 회수, 동적 우선순위 조정, 모니터링 시스템 등을 통해 이미 발생한 기아 상태를 조기 탐지하고 회복할 수 있다.
• 실무 시스템에서는 멀티레벨 큐 + Aging이나 자원 사용량 제한 같은 하이브리드 기법이 병용되어, 성능·공정성·응답성을 동시에 달성하고 있다.

발생 시 영향 및 피해

Starvation 이 발생하면 단순히 하나의 태스크가 대기하는 데 그치지 않고, 시스템 전체 성능, 자원 활용도, 공정성, 신뢰성에 걸쳐 광범위한 피해를 유발한다. 응답 시간 증가, 자원 낭비, 데이터 일관성 붕괴, 서비스 품질 저하, 심지어 보안 위협까지도 초래할 수 있다.

Starvation 은 단순한 " 작업 대기 " 현상을 넘어, 시스템 성능 저하, 서비스 품질 악화, 공정성 침해, 데이터 무결성 붕괴, 에너지 낭비, 그리고 보안 위협까지 야기할 수 있는 복합적인 위험 요소다. 이를 탐지하기 위해서는 정교한 모니터링 및 진단 도구가 필요하며, 사전 예방과 사후 복구를 위한 정책 기반의 스케줄링 전략, 자원 관리 기법, 타임아웃, 보안 설계 등이 병행되어야 한다.

트레이드오프 관계 분석

Starvation 방지를 위한 시스템 설계에서 공정성, 효율성, 예측 가능성, 성능 오버헤드, 자원 활용률 간에는 피할 수 없는 상충 관계가 존재한다. 각 정책과 메커니즘은 하나의 가치를 지키기 위해 다른 가치를 희생시킬 수 있으며, 실무 설계자는 시스템 목적과 SLA 를 기준으로 적절한 균형점을 찾아야 한다.

Starvation 을 방지하기 위한 설계는 단순히 한 가지 정책으로 해결되는 것이 아니라, 공정성 보장과 성능 최적화 사이의 균형을 어떻게 설계하느냐에 달려 있다.

• 우선순위 기반 처리, Aging, 공정 락, 자원 예약 등 각각의 전략은 특정 문제를 해결하면서 동시에 다른 리스크를 초래할 수 있다. 예컨대, Aging 은 기아를 줄이는 반면 예측 가능성을 떨어뜨릴 수 있고, 공정 락은 자원 분배를 고르게 하지만 시스템 처리량을 저해할 수 있다.
• 따라서 시스템 특성, 작업 특성, QoS 요구사항에 따라 설계자의 전략적 판단이 필요하다.

구현 및 분류 (Implementation & Classification)

탐지 및 진단 기법

대기 시간 기반 Starvation 탐지기

Starvation 탐지 구조를 Prometheus + Grafana + Slack 알림까지 실서비스 환경 수준으로 확장하는 아키텍처 및 구현 구조를 구현

확장 목표:

전체 아키텍처:

flowchart TD
    A[Python Starvation Monitor] --> B[Prometheus Exporter Endpoint]
    B --> C[Prometheus Server]
    C --> D[Grafana Dashboard]
    C --> E[Alert Rule Engine]
    E --> F[Slack Webhook]
    F --> G[Slack 채널 알림 전송]

구성 요소별 확장 방식:

1. Prometheus Exporter 통합 (Python)

   • http://localhost:8000/metrics 에서 starving_thread_count 지표 확인 가능
   • threshold 기준 이상으로 대기한 스레드를 탐지
   • start_waiting 과 stop_waiting 으로 상태 추적

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51

   from prometheus_client import start_http_server, Gauge import threading import time from collections import defaultdict # 지표 정의: starving_thread_count starving_thread_gauge = Gauge('starving_thread_count', 'Number of starving threads') class StarvationMonitorExporter: def __init__(self, threshold_sec=10): self.wait_start = defaultdict(float) self.lock = threading.Lock() self.threshold = threshold_sec def start_waiting(self, tid): with self.lock: self.wait_start[tid] = time.time() def stop_waiting(self, tid): with self.lock: if tid in self.wait_start: del self.wait_start[tid] def check_starvation(self): now = time.time() starving = [] with self.lock: for tid, start in self.wait_start.items(): if now - start > self.threshold: starving.append(tid) starving_thread_gauge.set(len(starving)) # Prometheus 지표 설정 return starving def exporter_runner(monitor): while True: monitor.check_starvation() time.sleep(5) # 5초마다 지표 갱신 # 실행 if __name__ == "__main__": monitor = StarvationMonitorExporter(threshold_sec=10) start_http_server(8000) # Prometheus가 수집할 HTTP endpoint threading.Thread(target=exporter_runner, args=(monitor,), daemon=True).start() # 예시: 테스트용 쓰레드 def test_thread(tid, delay): monitor.start_waiting(tid) time.sleep(delay) monitor.stop_waiting(tid) threading.Thread(target=test_thread, args=("T1", 15)).start()

2. Grafana Alert Rule 구성

   • 예시 YAML (Grafana Alert rule as code)
   • Grafana UI 에서도 Alert → New Alert Rule 로 설정 가능
   • 조건: starving_thread_count > 0 이 1 분 이상 지속될 경우

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

   apiVersion: 1 groups: - name: starvation-alerts rules: - uid: starving-threads title: "Starvation 감지 알림" condition: "B" data: - refId: "A" queryType: "instant" relativeTimeRange: from: 0 to: 300 datasourceUid: "prometheus" model: expr: starving_thread_count interval: "" legendFormat: "" refId: "A" - refId: "B" condition: "A > 0" annotations: summary: "Starvation 발생" description: "1개 이상의 스레드가 임계 대기 시간을 초과했습니다." for: 1m labels: severity: critical

3. Slack 알림 연동

   1. Slack Webhook 설정
      • Slack → App → Incoming Webhook 생성
      • Webhook URL 복사 (예: https://hooks.slack.com/services/TXXXX/BXXXX/XXXX)
   2. Grafana 알림 채널 설정 (UI)

      • Alerting > Contact points > Add contact point

      • 이름: Slack-Starvation

      • Type: Slack

      • Webhook URL 입력

      • 메시지 템플릿:

        1 2 3

        🚨 Starvation Alert 🚨 {{ .CommonLabels.severity }} - {{ .CommonAnnotations.summary }} {{ .CommonAnnotations.description }}

에이징 기법 (Aging Technique)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

class AgingScheduler:
    def __init__(self, aging_factor=1, aging_interval=10):
        self.aging_factor = aging_factor
        self.aging_interval = aging_interval
        self.processes = []
    
    def age_processes(self):
        """대기 중인 프로세스들의 우선순위를 증가"""
        for process in self.processes:
            if process.waiting_time >= self.aging_interval:
                process.priority += self.aging_factor
                process.waiting_time = 0

분류 기준에 따른 유형 구분

Starvation 은 시스템의 우선순위 구조, 자원 경쟁, 설계 오류, 또는 환경적 요인에 의해 다양한 형태로 발생한다.

• 분류 기준에 따라
  • 우선순위 기반, 락 기반, 네트워크 기반, 스케줄링 오류 기반 등 원인 중심 분류
  • OS/앱/분산 시스템/스레드 풀 등 시스템 환경 기준
  • 일시적/영구적/그룹적 영향 등 지속 시간 및 영향 범위 기준으로 세분화할 수 있다.

이러한 유형 구분은 Starvation 을 정확히 진단하고 유형에 맞는 대응책을 설계하기 위한 전제 조건이며, 각 유형별로 공정성 확보, 우선순위 보정, 자원 할당 개선, 스케줄링 정책 교체와 같은 맞춤형 대응 전략이 필요하다.

실무 적용 (Practical Application)

실제 도입 사례

실제 시스템들은 Starvation 을 단순한 성능 문제로 넘기지 않고, **공정성 (Fairness)**과 **활성성 (Liveness)**을 보장하기 위한 설계 요소로 적극적으로 다루고 있다.

• 운영체제 수준에서는 스케줄러가 이를 방지하는 핵심 기제로 작동하며, Java 나 DBMS 에서는 락 관리 전략과 타임아웃 조정이 중요한 역할을 한다.
• 클라우드 환경에서는 리소스 스케줄링과 우선순위 정책이 연계되어, 다중 사용자 환경에서 특정 워크로드의 무한 대기를 막는다.
• 특히 분산 시스템 및 멀티스레딩 환경에서는 자원 경합이 복잡하게 발생하므로, 큐 구조의 정렬, 워커 풀 설계, 우선순위 조정, 자원 예약 등이 반드시 고려되어야 한다.

이처럼 Starvation 은 모든 계층에서 일어날 수 있는 시스템적 현상이므로, 정책적·구조적·운영적 대응이 통합적으로 이루어져야 한다.

실습 예제 및 코드 구현

실습 예제: 웹 서버에서 높은 우선순위 요청

시나리오: 웹 서버에서 높은 우선순위 요청으로 인한 일반 요청 처리 지연

시스템 구성:

• 요청 처리 스레드 풀
• 우선순위 기반 작업 큐
• 공정성 보장 메커니즘

graph TB
    subgraph "Client Requests"
        HR[High Priority Requests]
        NR[Normal Priority Requests]
    end
    
    subgraph "Web Server"
        LB[Load Balancer]
        subgraph "Request Processing"
            PQ[Priority Queue with Aging]
            TP[Thread Pool]
            FM[Fairness Monitor]
        end
        subgraph "Backend Services"
            DB[(Database)]
            CACHE[(Cache)]
        end
    end
    
    HR --> LB
    NR --> LB
    LB --> PQ
    PQ --> TP
    TP --> DB
    TP --> CACHE
    FM --> PQ
    
    style NR fill:#ffcccc
    style FM fill:#ccffcc

Workflow:

1. 클라이언트 요청 수신 및 우선순위 분류
2. 우선순위 큐에 요청 삽입
3. 에이징 메커니즘으로 대기 시간 기반 우선순위 조정
4. 스레드 풀에서 요청 처리
5. 공정성 모니터로 기아 상태 감지 및 조정

핵심 역할:

• 에이징 메커니즘: 장기간 대기하는 일반 요청의 우선순위 점진적 상승
• 공정성 모니터: 기아 상태 실시간 감지 및 알람
• 적응적 스케줄링: 시스템 부하에 따른 동적 우선순위 조정

유무에 따른 차이점:

• 도입 전: 높은 우선순위 요청 집중 시 일반 요청 무한 대기
• 도입 후: 모든 요청이 합리적 시간 내 처리, 응답 시간 예측 가능

구현 예시 (Python):

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181

import heapq
import time
import threading
from dataclasses import dataclass
from typing import Optional
from enum import Enum

class Priority(Enum):
    HIGH = 1
    NORMAL = 2
    LOW = 3

@dataclass
class Request:
    """웹 요청을 나타내는 클래스"""
    id: str
    priority: Priority
    created_at: float
    data: dict
    
    def get_effective_priority(self) -> float:
        """에이징을 적용한 실제 우선순위 계산"""
        wait_time = time.time() - self.created_at
        # 대기 시간에 따라 우선순위 향상 (낮은 숫자가 높은 우선순위)
        aging_factor = min(wait_time / 10, 1.0)  # 10초마다 우선순위 1단계 향상
        return self.priority.value - aging_factor
    
    def __lt__(self, other):
        """우선순위 큐 정렬을 위한 비교 연산자"""
        return self.get_effective_priority() < other.get_effective_priority()

class FairRequestProcessor:
    """기아 상태를 방지하는 공정한 요청 처리기"""
    
    def __init__(self, max_workers=10, starvation_threshold=30):
        self.request_queue = []  # 우선순위 큐
        self.queue_lock = threading.Lock()
        self.max_workers = max_workers
        self.starvation_threshold = starvation_threshold
        
        # 기아 상태 모니터링
        self.processing_times = {}  # request_id -> start_time
        self.starvation_alerts = []
        
        # 워커 스레드 풀
        self.workers = []
        self.shutdown_event = threading.Event()
        self._start_workers()
        
        # 공정성 모니터링 스레드
        self.monitor_thread = threading.Thread(target=self._monitor_fairness)
        self.monitor_thread.daemon = True
        self.monitor_thread.start()
    
    def submit_request(self, request: Request):
        """요청을 큐에 추가"""
        with self.queue_lock:
            heapq.heappush(self.request_queue, request)
            print(f"Request {request.id} queued with priority {request.priority.name}")
    
    def _start_workers(self):
        """워커 스레드들을 시작"""
        for i in range(self.max_workers):
            worker = threading.Thread(target=self._worker_loop, args=(i,))
            worker.daemon = True
            worker.start()
            self.workers.append(worker)
    
    def _worker_loop(self, worker_id: int):
        """워커 스레드의 메인 루프"""
        while not self.shutdown_event.is_set():
            request = self._get_next_request()
            if request:
                self._process_request(request, worker_id)
            else:
                time.sleep(0.1)  # 큐가 비어있을 때 잠시 대기
    
    def _get_next_request(self) -> Optional[Request]:
        """큐에서 다음 요청을 가져옴 (우선순위 + 에이징 적용)"""
        with self.queue_lock:
            if self.request_queue:
                # 에이징 적용을 위해 큐 재정렬
                heapq.heapify(self.request_queue)
                return heapq.heappop(self.request_queue)
            return None
    
    def _process_request(self, request: Request, worker_id: int):
        """실제 요청 처리"""
        start_time = time.time()
        wait_time = start_time - request.created_at
        
        print(f"Worker {worker_id} processing request {request.id} "
              f"(waited {wait_time:f}s, effective_priority: {request.get_effective_priority():f})")
        
        # 실제 작업 시뮬레이션
        if request.priority == Priority.HIGH:
            time.sleep(0.5)  # 빠른 처리
        else:
            time.sleep(1.0)   # 일반 처리
        
        processing_time = time.time() - start_time
        print(f"Request {request.id} completed in {processing_time:f}s")
    
    def _monitor_fairness(self):
        """공정성 모니터링 및 기아 상태 감지"""
        while not self.shutdown_event.is_set():
            current_time = time.time()
            starving_requests = []
            
            with self.queue_lock:
                for request in self.request_queue:
                    wait_time = current_time - request.created_at
                    if wait_time > self.starvation_threshold:
                        starving_requests.append((request.id, wait_time))
            
            if starving_requests:
                print(f"🚨 STARVATION ALERT: {len(starving_requests)} requests waiting too long:")
                for req_id, wait_time in starving_requests:
                    print(f"   - Request {req_id}: {wait_time:f}s")
                self.starvation_alerts.extend(starving_requests)
            
            time.sleep(5)  # 5초마다 모니터링
    
    def get_queue_status(self):
        """현재 큐 상태 반환"""
        with self.queue_lock:
            return {
                'queue_length': len(self.request_queue),
                'starvation_alerts': len(self.starvation_alerts),
                'requests_by_priority': {
                    priority.name: sum(1 for req in self.request_queue if req.priority == priority)
                    for priority in Priority
                }
            }
    
    def shutdown(self):
        """처리기 종료"""
        self.shutdown_event.set()
        for worker in self.workers:
            worker.join()

# 사용 예제
def main():
    """공정한 요청 처리 시스템 데모"""
    processor = FairRequestProcessor(max_workers=3, starvation_threshold=15)
    
    try:
        # 다양한 우선순위의 요청들을 시간차를 두고 추가
        requests = [
            Request("REQ-001", Priority.NORMAL, time.time(), {"type": "user_query"}),
            Request("REQ-002", Priority.HIGH, time.time(), {"type": "admin_task"}),
            Request("REQ-003", Priority.NORMAL, time.time(), {"type": "user_query"}),
            Request("REQ-004", Priority.HIGH, time.time(), {"type": "critical_update"}),
            Request("REQ-005", Priority.LOW, time.time(), {"type": "background_job"}),
        ]
        
        # 요청들을 순차적으로 제출
        for i, request in enumerate(requests):
            processor.submit_request(request)
            time.sleep(1)  # 1초 간격으로 요청 제출
            
            # 중간에 더 많은 높은 우선순위 요청 추가 (기아 상황 시뮬레이션)
            if i == 2:
                for j in range(5):
                    high_priority_req = Request(f"HIGH-{j}", Priority.HIGH, time.time(), {"type": "urgent"})
                    processor.submit_request(high_priority_req)
                    time.sleep(0.5)
        
        # 처리 상황 모니터링
        for _ in range(10):
            status = processor.get_queue_status()
            print(f"\n📊 Queue Status: {status}")
            time.sleep(3)
            
    except KeyboardInterrupt:
        print("\n⏹️  Shutting down processor…")
    finally:
        processor.shutdown()

if __name__ == "__main__":
    main()

실습 예제: 다수의 쓰레드가 동시에 공유 자원을 요청

시나리오: 다수의 쓰레드가 동시에 공유 자원 (예: DB Connection Pool) 을 요청할 때, 특정 쓰레드가 계속 자원을 할당받지 못하는 상황을 구현.

시스템 구성:

• Thread Pool: 여러 쓰레드가 자원을 경쟁적으로 요청
• Resource Pool: 제한된 수의 자원 (예: DB Connection 3 개)
• Scheduler: 자원 할당 정책 (FIFO, Priority, Aging 등)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

import threading
import time
import random

class ResourcePool:
    def __init__(self, size):
        self.pool = [True] * size  # True: 비어있음, False: 사용중
        self.lock = threading.Lock()

    def acquire(self, thread_id):
        # 불공정한 자원 할당(Starvation 유발)
        while True:
            with self.lock:
                for i, available in enumerate(self.pool):
                    if available:
                        self.pool[i] = False
                        print(f"Thread {thread_id} acquired resource {i}")
                        return i
            # 공정한 할당을 위해 짧은 sleep 추가(예: time.sleep(0.1))
            time.sleep(1)  # 이 부분이 없으면 Starvation 발생 가능

    def release(self, idx):
        with self.lock:
            self.pool[idx] = True
            print(f"Resource {idx} released")

def worker(thread_id, pool):
    res_idx = pool.acquire(thread_id)
    time.sleep(random.random())  # 자원 사용 시간
    pool.release(res_idx)

def main():
    pool = ResourcePool(3)
    threads = []
    for i in range(10):
        t = threading.Thread(target=worker, args=(i, pool))
        threads.append(t)
        t.start()
    for t in threads:
        t.join()

if __name__ == "__main__":
    main()

실행 결과 해석:
acquire() 메서드에서 락을 획득한 쓰레드가 자원을 탐색할 때, 항상 처음부터 순차적으로 검사하므로, 운이 나쁘면 특정 쓰레드는 자원을 할당받지 못하고 무한 대기 (Starvation) 에 빠질 수 있다.
이를 해결하려면 공정한 스케줄링(예: 요청 순서 큐, Aging 등) 이 필요하다.

유무에 따른 차이점

• Starvation 발생 시: 일부 쓰레드는 영원히 자원을 받지 못해 작업이 진행되지 않음.
• 공정 스케줄링 적용 시: 모든 쓰레드가 일정 시간 내 자원을 할당받아 작업 완료.

실습 예제: 운영체제 (OS) 에서 여러 프로세스가 CPU 를 사용하는 상황

시나리오: 운영체제 (OS) 에서 여러 프로세스가 CPU 를 사용하는 상황에서, 우선순위 기반 스케줄링 (Priority Scheduling) 을 적용하여 낮은 우선순위의 프로세스가 계속 선점되지 못하는 경우 Starvation(기아 현상) 이 발생.

시스템 구성:

• 프로세스 그룹 (고우선, 저우선)
• 스케줄러 (우선순위/에이징 기능 포함)
• 자원 (CPU)

flowchart TD
  HighP[고우선 프로세스] --요청--> Sched1[우선순위 스케줄러]
  LowP[저우선 프로세스] --요청--> Sched1
  Sched1 --자원할당(CPU)--> HighP
  Sched1 --반복대기--> LowP
  subgraph Aging Process
    Sched1 --우선순위 상승--> LowP
  end

Workflow:

• 고우선 프로세스가 CPU 반복 점유
• 저우선 프로세스는 대기만 반복
• Aging 도입 → 일정 대기 후 저우선 우선순위 상승 → CPU 기회 부여

역할:

• 고우선 프로세스: 반복 요청/자원 점유
• 저우선 프로세스: 무한 대기/우선순위 상승 기대
• 스케줄러: 자원 할당 및 우선순위 관리
• Aging: 우선순위 자동 조정

유무에 따른 차이점:

• Starvation(기아 현상) 미적용: 저우선 프로세스가 영원히 끝나지 않음
• Starvation(기아 현상) 방지 (Aging 등): 저우선 프로세스도 결국 CPU 사용

구현 예시 (Python)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

import time
from queue import PriorityQueue

# 우선순위와 도착시간을 기준으로 프로세스 관리
class Process:
    def __init__(self, name, priority, arrival_time):
        self.name = name
        self.priority = priority
        self.arrival_time = arrival_time

    def __lt__(self, other):
        # 우선순위와 도착시간(aging 고려)로 비교
        return (self.priority, self.arrival_time) > (other.priority, other.arrival_time)

# 프로세스 생성 (도착시간에 따라 aging 적용 가능)
pq = PriorityQueue()
now = time.time()
pq.put(Process('Low', 1, now))
pq.put(Process('High', 10, now + 1))

# Aging 알고리즘: 일정 시간마다 낮은 우선순위의 priority 증가
def apply_aging(processes, current_time):
    for p in processes:
        if current_time - p.arrival_time > 5:  # 5초 이상 대기 시 우선순위 1 상승
            p.priority += 1

# 실행 시뮬레이션
processes = [Process('Low', 1, now), Process('High', 10, now + 1)]
for _ in range(10):
    apply_aging(processes, time.time())
    next_p = max(processes, key=lambda p: (p.priority, -p.arrival_time))
    print(f"실행 프로세스: {next_p.name}, 우선순위: {next_p.priority}")

사례: 대용량 웹 서비스에서 사용자 요청 처리

시나리오: 대용량 웹 서비스에서 사용자 요청 처리 시 스타베이션 방지

시스템 구성:

• 로드 밸런서 (Load Balancer)
• 웹 서버 클러스터 (Web Server Cluster)
• 데이터베이스 서버 (Database Server)
• 캐시 서버 (Cache Server)
• 모니터링 시스템 (Monitoring System)

graph TB
    A[클라이언트 요청] --> B[로드 밸런서<br/>가중 라운드 로빈]
    B --> C[웹 서버 1<br/>공정 큐 스케줄러]
    B --> D[웹 서버 2<br/>공정 큐 스케줄러]
    B --> E[웹 서버 3<br/>공정 큐 스케줄러]
    
    C --> F[커넥션 풀]
    D --> F
    E --> F
    
    F --> G[데이터베이스<br/>Wait-Die 스키마]
    
    H[모니터링 시스템] --> B
    H --> C
    H --> D
    H --> E
    H --> G
    
    I[캐시 서버<br/>LRU + 에이징] --> C
    I --> D
    I --> E

Workflow:

• 클라이언트 요청이 로드 밸런서에 도착
• 가중 라운드 로빈 알고리즘으로 웹 서버 선택
• 각 웹 서버에서 공정 큐 스케줄러가 요청 처리 순서 결정
• 데이터베이스 접근 시 Wait-Die 스키마로 트랜잭션 스타베이션 방지
• 모니터링 시스템이 실시간으로 성능 지표 추적

역할:

• 로드 밸런서: 서버 간 요청 분산을 통한 전체적인 공정성 보장
• 웹 서버: 개별 요청에 대한 공정한 처리 순서 보장
• 데이터베이스: 트랜잭션 레벨에서의 스타베이션 방지
• 모니터링 시스템: 스타베이션 발생 징후 실시간 탐지

유무에 따른 차이점:

• 스타베이션 방지 미적용 시: 일부 사용자 요청이 무한 대기, 시스템 불안정성 증가
• 스타베이션 방지 적용 시: 모든 사용자의 공정한 서비스 이용, 시스템 안정성 향상

구현 예시:

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137

import time
import threading
from queue import Queue, PriorityQueue
from dataclasses import dataclass
from typing import Dict, List

@dataclass
class Request:
    """웹 요청을 나타내는 클래스"""
    id: str
    priority: int
    arrival_time: float
    waiting_time: float = 0.0
    
    def __lt__(self, other):
        return self.priority < other.priority

class FairQueueScheduler:
    """공정한 큐 스케줄러 구현"""
    
    def __init__(self, aging_factor: int = 1, aging_interval: float = 5.0):
        self.request_queue = PriorityQueue()
        self.aging_factor = aging_factor
        self.aging_interval = aging_interval
        self.running = False
        self.lock = threading.Lock()
        
    def add_request(self, request: Request):
        """요청을 큐에 추가"""
        with self.lock:
            self.request_queue.put(request)
    
    def age_requests(self):
        """대기 중인 요청들의 우선순위를 에이징"""
        current_time = time.time()
        temp_requests = []
        
        with self.lock:
            # 큐에서 모든 요청을 꺼내어 에이징 적용
            while not self.request_queue.empty():
                request = self.request_queue.get()
                request.waiting_time = current_time - request.arrival_time
                
                if request.waiting_time >= self.aging_interval:
                    # 에이징 적용: 우선순위 증가
                    request.priority -= self.aging_factor
                    print(f"Request {request.id} aged: priority = {request.priority}")
                
                temp_requests.append(request)
            
            # 에이징이 적용된 요청들을 다시 큐에 추가
            for request in temp_requests:
                self.request_queue.put(request)
    
    def process_requests(self):
        """요청 처리 메인 루프"""
        while self.running:
            try:
                # 에이징 적용
                self.age_requests()
                
                # 가장 높은 우선순위 요청 처리
                if not self.request_queue.empty():
                    with self.lock:
                        request = self.request_queue.get()
                    
                    print(f"Processing request {request.id} "
                          f"(priority: {request.priority}, "
                          f"waiting: {request.waiting_time:f}s)")
                    
                    # 실제 요청 처리 시뮬레이션
                    time.sleep(1)
                    
                time.sleep(0.5)  # 스케줄링 간격
                
            except Exception as e:
                print(f"Error in scheduler: {e}")
    
    def start(self):
        """스케줄러 시작"""
        self.running = True
        threading.Thread(target=self.process_requests, daemon=True).start()
    
    def stop(self):
        """스케줄러 정지"""
        self.running = False

class WebServerMonitor:
    """웹 서버 모니터링 시스템"""
    
    def __init__(self):
        self.request_stats: Dict[str, float] = {}
        self.starvation_threshold = 10.0  # 10초 이상 대기 시 스타베이션으로 간주
    
    def check_starvation(self, requests: List[Request]) -> List[str]:
        """스타베이션 발생 요청 탐지"""
        starved_requests = []
        current_time = time.time()
        
        for request in requests:
            waiting_time = current_time - request.arrival_time
            if waiting_time > self.starvation_threshold:
                starved_requests.append(request.id)
                print(f"ALERT: Request {request.id} may be starving "
                      f"(waiting: {waiting_time:f}s)")
        
        return starved_requests

# 사용 예시
if __name__ == "__main__":
    # 공정 큐 스케줄러 생성
    scheduler = FairQueueScheduler(aging_factor=2, aging_interval=3.0)
    scheduler.start()
    
    # 모니터링 시스템 생성
    monitor = WebServerMonitor()
    
    # 다양한 우선순위의 요청 생성
    requests = [
        Request("req_1", priority=10, arrival_time=time.time()),
        Request("req_2", priority=5, arrival_time=time.time()),
        Request("req_3", priority=15, arrival_time=time.time()),
        Request("req_4", priority=1, arrival_time=time.time()),  # 높은 우선순위
    ]
    
    # 요청들을 스케줄러에 추가
    for request in requests:
        scheduler.add_request(request)
        print(f"Added request {request.id} with priority {request.priority}")
    
    # 시뮬레이션 실행
    try:
        time.sleep(20)  # 20초간 실행
    except KeyboardInterrupt:
        print("\nSimulation stopped")
    finally:
        scheduler.stop()

사례: 멀티스레드 기반 주문 처리 시스템에서 고우선 알림 처리 쓰레드가 무한 반복

시나리오: 멀티스레드 기반 주문 처리 시스템에서 고우선 알림 처리 쓰레드가 무한 반복적으로 실행됨에 따라, 주문 저장 스레드가 자원을 얻지 못해 고객의 주문이 반영되지 않는 문제가 발생.

시스템 구성:

• 고우선 알림 처리 스레드
• 주문 저장 스레드
• 공통 DB 접속 락
• 스케줄링 제어 모듈

flowchart TB
    Client --> Web[Web API]
    Web --> ThreadPool
    ThreadPool --> Notify[알림 처리 스레드]
    ThreadPool --> Order[주문 저장 스레드]
    Notify --> DB[공용 데이터베이스 락 점유]
    Order --> DB

Workflow:

• 사용자 요청이 들어오면 알림/주문 스레드로 분기
• 알림 스레드는 빠르게 실행되고 락을 자주 점유
• 주문 스레드는 락을 얻지 못해 starvation 발생

역할:

• 스레드: 알림과 주문을 병렬 처리
• DB 락: 리소스 제어
• 스케줄러: 실행 우선순위에 따라 분기

유무에 따른 차이점:

• Starvation 미적용: 주문 처리 지연 → 매출 손실
• Starvation 방지 적용: 공정한 자원 분배로 문제 없음

구현 예시:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

from threading import Lock, Thread
import time

db_lock = Lock()

def notify_thread():
    while True:
        if db_lock.acquire(timeout=0.1):
            print("알림 처리 중…")
            time.sleep(0.1)
            db_lock.release()
        time.sleep(0.05)

def order_thread():
    while True:
        if db_lock.acquire(timeout=0.1):
            print("주문 저장 중…")
            time.sleep(0.2)
            db_lock.release()
        else:
            print("주문 대기 중… (Aging 필요)")

# aging 혹은 우선순위 보정 필요
Thread(target=notify_thread).start()
Thread(target=order_thread).start()

운영 및 최적화 (Operations & Optimization)

보안 및 거버넌스

Starvation 은 단순한 기술적 이슈가 아닌 정책적 통제 실패로부터 비롯된 구조적 문제일 수 있다.

따라서 보안 및 거버넌스 측면에서의 대응은 다음 세 가지 관점으로 구분되어야 한다:

• 보안 관점: 특정 사용자의 리소스 선점이나 우선순위 남용을 차단하여 시스템의 공정성과 접근 제어를 확보한다. 이를 위해 RBAC, Rate Limiting, 인증 기반 우선순위 부여 등이 사용된다.
• 거버넌스 관점: 서비스 레벨에서 자원 할당, 우선순위 관리, SLA 준수 여부를 정책적으로 제어하고 기록한다. Starvation 발생 시점에 자동 대응하거나 사후 감사가 가능하도록 설계하는 것이 핵심이다.
• 운영 자동화: 시스템은 Starvation 발생 징후 (지속 대기, 자원 선점 반복 등) 를 실시간으로 감지하고, 자동으로 우선순위를 재조정하거나 자원 분배 정책을 변경하여 선제적으로 문제를 해결할 수 있어야 한다.

이러한 보안 및 거버넌스 체계는 특히 멀티 테넌시 환경, 클라우드, 분산 시스템에서 필수적이며, Starvation 을 예방하기 위한 기술적 기반 위의 정책적 방패 역할을 한다.

모니터링 및 관측성

• Starvation 탐지를 위한 모니터링은 대기 시간, 처리량, 공정성이라는 3 대 메트릭이 핵심이며, 이를 실시간으로 추적해야 경고를 빠르게 발생시킬 수 있다.
• 스레드 상태나 락 충돌, 스케줄링 히스토리와 같은 운영체제 수준의 진단 지표는 실제 Starvation 원인 분석에 필수.
• Prometheus Exporter, Grafana 대시보드, 알림 시스템 (Slack 등) 을 연계하면 Kubernetes 환경에서도 자동화된 탐지와 대응이 가능함.

실무 적용 고려사항 및 주의점

• 정책 단순성과 공정성 균형이 중요하며, 공정성만 강조하면 성능 저하 가능성이 있으므로 하이브리드 접근이 실무적.
• 동기화 메커니즘과 자원 관리는 starvation 발생의 주요 원인이 되므로 공정 락 및 타임아웃 설정이 필수적.
• 관측성과 실시간 경고 체계 없이는 조기 감지가 어려우므로, 슬라이딩 윈도우 기반 메트릭과 alert 연동이 효과적.
• 시스템 통합 및 테스트는 점진적으로 접근하고, 장애 복구 대안을 반드시 고려해야 지속 가능한 운영이 가능.

최적화하기 위한 고려사항 및 주의할 점

Starvation 방지 메커니즘은 시스템의 성능, 안정성, 공정성을 확보하기 위한 핵심 구성요소이지만, 무조건적 적용은 오히려 새로운 병목을 초래할 수 있다. 특히 우선순위 조정, 락 구조 설계, 자원 할당 정책, 모니터링 체계는 서로 유기적으로 맞물려야 하며, 이 중 하나라도 과도하게 동작하거나 무시되면 Starvation 완화보다는 예측 불가능한 시스템 동작으로 이어진다.

효과적인 최적화를 위해선 다음이 중요하다:

• 최소한의 오버헤드로 동작하는 정책 설계
• 결정론적 우선순위 알고리즘 중심 운영
• 자원 독점을 막기 위한 격리와 모니터링 체계
• 확장 가능한 구조와 이벤트 기반 대응 정책

결국, Starvation 방지는 기술보다 운영 전략과 시스템 이해의 문제이며, 최적화는 단순한 속도 향상이 아니라 ” 예측 가능하고 공정한 시스템 " 을 구축하는 과정이다.

고급 주제 (Advanced Topics)

현재 도전 과제

• 공정성 스케줄링: 글로벌 수준의 fairness 확보는 필수이며, local 최적화만으로는 Starvation 회피가 불가능함.
• 멀티테넌시 자원 분배: QoS 기반 리소스 분리와 격리 없이는 낮은 우선순위 워크로드가 지속적인 자원 기아 상태에 빠짐.
• GPU 및 AI 환경: GPU 와 같은 고비용 자원은 공유 모델과 선점 정책 없이는 특정 작업이 기회를 얻지 못함.
• 마이크로서비스 아키텍처: 비동기 간섭으로 발생하는 간접적 Starvation 을 제어하기 위해 백프레셔 제어 메커니즘이 중요함.
• 관측성 및 대응성: 실시간 메트릭 수집, 시스템 전역의 상태 추적 없이는 Starvation 을 정량적으로 포착하기 어려움.
• 확장성 있는 Fairness 보장: 대규모 분산 환경에서 모든 노드/작업의 공정성을 보장하기 어려움.
• 동적 부하 대응: 시스템 부하가 급변할 때, 자원 할당 정책이 실시간으로 적응해야 함.
• 복합적 Starvation: 여러 자원 (CPU, 메모리, I/O 등) 이 복합적으로 Starvation 을 유발할 수 있음.
• 클라우드/멀티테넌트 환경: 여러 조직/서비스가 동일 인프라를 공유할 때, Starvation 리스크 관리가 복잡해짐.

생태계 및 관련 기술

• 운영체제는 CFS 나 POSIX 스케줄링 정책을 통해 낮은 우선순위 작업이 무기한 밀리는 현상을 구조적으로 방지할 수 있도록 돕는다.
• 프로그래밍 레벨에서는 Java 나 Go 등의 프레임워크가 **공정 락 (Fair Lock)**이나 비동기 처리를 통해 락 경합과 큐 기아 현상을 제어할 수 있다.
• Kubernetes 및 cgroups 는 자원 할당을 통해 특정 컨테이너나 프로세스가 자원을 독점하지 않도록 제어하고, 이를 기반으로 멀티 테넌시 환경에서도 공정성 확보가 가능하다.
• Kafka, Flink 등 메시지 기반 시스템은 처리량이 높은 환경에서도 이벤트나 메시지가 오래 대기하지 않도록 적절히 분산 처리하거나 제한 정책을 두는 백프레셔 메커니즘을 사용한다.
• 관측성과 조기 대응 측면에서는 Prometheus, OpenTelemetry 가 시스템 내부 지표를 분석하여 기아 발생의 징후를 빠르게 감지하고 관리자나 시스템이 자동으로 대응할 수 있는 기반을 제공한다.

결론적으로, Starvation 은 단일 기술로 해결되는 것이 아니라 생태계 전반에 걸친 통합 전략이 필요하며, 운영체제 - 프로그래밍 - 자원관리 - 관측성 - 표준이 유기적으로 연동되어야 근본적인 방지가 가능하다.

최신 기술 트렌드와 미래 방향

• AI 기반 스케줄링은 현재 가장 핵심적인 트렌드 중 하나로, 시스템 상태와 워크로드 패턴을 실시간 학습하여 starvation 발생 가능성을 예측하고 선제적 대응이 가능하게 한다. 특히 머신러닝 모델을 통해 자원 할당 정책을 동적으로 조정하는 방향으로 진화 중이다.
• 서버리스/이벤트 기반 아키텍처는 우선순위 기반 스케줄링 개념 자체를 제거하면서도 기아 상태를 완화할 수 있으며, 자동 확장성과 자원 할당의 유연성이 매우 크다.
• 엣지 컴퓨팅 환경에서는 노드 간 자원 경쟁이 더욱 분산되고 계층화됨에 따라, 각 레이어별 공정성 보장과 starvation 방지가 복잡해지고 있으며, 이로 인해 계층적 분산 스케줄링 프레임워크가 주요 기술로 부상하고 있다.
• 보안 중심의 스케줄링은 블록체인 및 동형암호 기술을 통해 요청과 우선순위의 신뢰성과 투명성을 높이고 있으며, 이를 통해 공정성의 객관적 검증 가능성이 확보되고 있다.
• Prometheus, OpenTelemetry 같은 관측성 기반 도구들은 실시간 모니터링을 통해 starvation 징후를 감지하고, AIOps 또는 정책 기반 자동화 도구와 연동해 자동 대응 체계로 전환되고 있다.

기타 고급 사항

정리 및 학습 가이드

내용 정리

• 정의: Starvation 은 자원 접근이 불공정하게 이루어져, 특정 프로세스 또는 요청이 자원을 무한정 획득하지 못하는 상태를 의미한다. 이는 공정성 (Fairness) 과 활성성 (Liveness) 을 훼손하는 주요 원인이다.

• 원인: 주로 우선순위 기반 스케줄링, 리소스 경합, 선점 정책 결함, 서버리스 환경의 콜드 스타트, 멀티 테넌시에서의 자원 쏠림 등에서 발생한다.

• 해결 방안:

  • Aging: 대기 시간이 길수록 우선순위 상향
  • Fair Lock: FIFO 기반 동기화
  • Preemption: 우선순위 기반 선점 제어
  • Timeout: 장시간 대기에 대한 자동 회피
  • Resource Isolation/Quota: 테넌트 간 자원 격리
  • Backpressure: 상위 시스템의 처리 속도 조절

• 최신 트렌드:

  • AI 기반 스케줄링: 예측 기반 자원 분배로 사전 예방
  • 서버리스 환경 대응: 콜드 스타트/자원 대기 방지
  • 멀티 클라우드 자원 공정화: Federation Scheduling
  • 실시간 스트리밍 공정성 제어: Kafka QoS Scheduling
  • 관측성과 자동화 강화: Prometheus + Grafana + Slack Alert 연동

• 실무 전략:

  • 설계 단계 고려: 공정성 메커니즘 내장 설계
  • 계층별 대응: OS → 스케줄러 → 애플리케이션 → 인프라
  • 관측 가능성 확보: 지표 수집 + 경고 연동
  • 비즈니스 우선순위와 기술 우선순위의 조율

학습 로드맵

학습 항목 매트릭스

용어 정리

참고 및 출처

• Starvation (computer science) - Wikipedia
• Starvation and Aging in Operating Systems | GeeksforGeeks
• Scheduling (computing) - Wikipedia
• Aging (scheduling) - Wikipedia
• Synchronization (computer science) - Wikipedia
• Difference between Deadlock and Starvation in OS | GeeksforGeeks