글을 작성하게 된 계기
최근 스케줄링 시스템(Scheduling System) 에 대해 관심을 가지게 되었고, 학습한 내용을 정리하기 위해 글을 작성하게 되었습니다.
1. 스케줄러 시스템
스케줄러 설계는 일반적으로 작업의 실행 시점을 기준으로 시간 중심과 조건 중심의 두 가지 방식으로 분류할 수 있습니다. 이 두 접근은 작업을 언제, 어떻게 실행할지를 결정하는 데 서로 다른 관점을 제공합니다.
- 시간 기반 스케줄링
- 조건 기반 스케줄링
1-1. 시간 기반 스케줄링
첫 번째는 시간 기반(Time-Driven) 스케줄링입니다. 이는 언제 작업을 실행할 것인가? 라는 질문에 초점을 맞춥니다. 즉, 특정 시간, 정해진 주기, 또는 사전에 정의된 스케줄 에 따라 작업을 실행 합니다. 대표적인 예로 Unix/Linux 환경의 cron 작업, Quartz CronTrigger 등이 있습니다. 이러한 시간 기반 스케줄링은 작업 실행 시점을 예측이 쉽고, 반복적인 정기 작업에 유용 합니다.
이는 주기적 클록 인터럽트(Clock Interrupts) 에 의해 이루어 집니다. 시스템 내부 타이머가 일정한 간격으로 인터럽트를 발생 시키면, 해당 시점에서 스케줄러는 다음에 실행할 작업을 선택하고 필요한 경우 문맥 교환을 수행합니다. 스케줄링 포인트는 사전에 정의된 클록 인터럽트 발생 시점으로 고정되며, 주기적인 작업(Periodic Tasks) 처리에 적합합니다.
스케줄링 로직이 비교적 간단해 구현 및 이해가 용이하지만 유연성이 부족 하다는 단점이 있습니다. 예를 들어, 클록 인터럽트 주기 사이에 예상치 못한 중요 이벤트가 발생했을 때, 스케줄러는 다음 정해진 클록 인터럽트 시점까지 해당 이벤트에 대한 즉각적인 반응을 못 할 수도 있습니다.
1
2
3
4
5
6
7
8
9
10
11
12
# Activity A, Activity B는 각 시점에서 수행 중인 작업
# B 이벤트는 클록 인터럽트 전에 도착했지만 반응은 지연됨
| | | | | |
↓ tick ↓ tick ↓ tick ↓ tick ↓ tick |
| | | | | |
| AAAAAAA| | | AAAAAAA| |
| | | | | |
| BBBBBBBBBBBBBB| |BBBBBBBBB| |
| | | | | |
+------------------------------------------------
Δt: 클록 인터럽트 간격
이러한 특성으로 인해 임베디드 시스템 과 같이 자원이 제한적 이고 예측 가능성 및 시스템 안정성이 중요한 환경 에서 활용됩니다. 정적인 주기적 작업들로 구성되고 복잡도가 낮을 경우, 이벤트 구동 방식에 비해 관리 비용이 적어 효율적이기 때문입니다.
이벤트 발생이 불규칙하거나 우선순위가 급격히 바뀌는 시스템에서는 이벤트 기반 스케줄링이 더 적합할 수 있습니다.
1-2. 조건 기반 스케줄링
두 번째 스케줄링 패러다임은 조건 기반(Condition-Driven) 스케줄링입니다. 조건 기반 스케줄링은 실행 조건의 충족 여부 에 따라 작업을 수행합니다. 조건 기반 스케줄링은 다음과 같이 세 가지 하위 유형으로 나눌 수 있습니다.
상태 기반(State-Driven): 시스템 또는 객체의 내부 상태가 특정 값으로 전이될 때 작업을 실행합니다.이벤트 기반(Event-Driven): 외부 또는 내부에서 발생한 이벤트(사건) 를 트리거로 작업을 실행합니다.데이터 기반(Data-Driven): 특정 데이터 조건이 충족되거나 데이터의 변경을 감지했을 때 작업을 실행합니다.
이는 시스템 내부 특정 상태 변화, 새로운 데이터의 발생이나 변경, 혹은 외부로부터의 이벤트 수신과 같이 특정 조건이 충족되었을 때 작업을 실행합니다. 예를 들어, 특정 디렉터리에 파일이 도착하면 해당 파일을 처리하는 작업, 데이터베이스 테이블에 새로운 레코드가 삽입되면 관련 알림을 보내는 작업, 메시지 큐에 메시지가 도착했을 때 이를 소비하는 작업, 또는 워크플로우 시스템에서 이전 단계가 완료 상태로 변경되면 다음 단계를 실행하는 작업 등이 여기에 해당합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[메시지 수신]
│
▼
[조건 검사: 메시지 필드 유효한가?]
│
┌───┴─────┐
│ │
[유효] [무효]
│ │
▼ ▼
[처리 시도] [DLQ로 이동]
│
┌───┴──────┐
│ │
[성공] [실패 → DLQ로 이동]
상태 기반 스케줄링은 시스템 내부 또는 외부에서 발생하는 변화에 따라 작업을 유연하게 실행할 수 있으며, 이벤트나 상태 변화가 발생했을 때 즉시 반응할 수 있어 실시간성 이 요구되는 환경에 적합합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# 상태 기반 스케줄링: 이벤트가 도착하자마자 즉시 작업이 실행됨
# Activity A는 평상시 작업
# B 이벤트가 발생하자마자 즉시 B 작업 실행 (tick 시점과 무관)
시간 →
|---------|---------|---------|---------|---------|
이벤트 B 발생
└──▶ BBBBBBB
| AAAAAA AAAAAAA |
| BBBBB|
|--------|---------|---------|---------|----------|
▲ ▲
시스템 상태 변경 이벤트 B 발생
설명:
- 이벤트가 발생하는 순간 스케줄러는 즉시 반응하여 작업 B 실행
- 클록 인터럽트 시점(시간 간격 Δt)과는 무관하게 반응
- 상태 기반(이벤트 중심) 시스템의 즉각적 반응성을 강조
또한 단순한 이벤트 발생 여부뿐만 아니라, 특정 조건이 충족되었을 때만 작업을 실행 하도록 설정할 수 있어 흐름 제어 가 유연합니다. 예를 들어, 메시지가 도착하더라도 특정 필드 값이 존재할 경우에만 알림을 전송하거나, 업로드된 파일의 확장자가 .csv인 경우에만 처리를 수행하도록 구성할 수 있어 응답성 과 리소스 효율성 을 동시에 확보할 수 있습니다.
1
2
3
[이벤트1] → 조건 불충족 → 실행 생략
[이벤트2] → 조건 충족 → 작업 실행 → 완료
[이벤트3] → 조건 불충족 → 실행 생략
2. 테이블/사이클 기반 스케줄링
위에서 소개한 시간 기반 스케줄링 과 상태 기반 스케줄링 외에도, 시간 기반 스케줄링은 더 세부적으로 나누어 볼 수 있습니다. 대표적으로 테이블 기반(Table-driven) 과 사이클 기반(Cyclic) 스케줄링 으로 분류할 수 있으며, 이들은 시간 기반 스케줄링의 하위 개념으로 볼 수 있습니다.
1
2
3
4
5
스케줄링 시스템
├── 시간 기반 스케줄링
│ ├── 테이블 기반 스케줄링
│ └── 사이클 기반 스케줄링
└── 조건 기반 스케줄링
두 방식 모두 실행 시점이 정해진 작업들을 반복적으로 수행하지만, 테이블 기반은 각 작업의 실행 시각을 세밀하게 명시하는 방식이라면, 사이클 기반은 고정된 주기 내에 작업을 순차적으로 반복 실행하는 방식입니다. 즉, 테이블 기반은 정밀한 제어와 높은 정확성이 요구되는 환경에서 사용되며, 사이클 기반은 상대적으로 단순하고 반복적인 작업 흐름이 많은 시스템에서 효율적으로 사용됩니다.
테이블 기반 스케줄링: 정해진 시간표에 따라 작업을 정확히 실행사이클 기반 스케줄링: 고정된 주기 내에 작업을 순차적으로 반복 실행
2-1. 테이블 기반 스케줄링
테이블 기반 스케줄링은 시스템이 수행해야 할 모든 작업의 실행 시점 과 실행 순서 를 시스템 설계 단계에서 미리 계산하고, 이를 스케줄 테이블 에 정적으로 정의해 둡니다. 테이블은 특정 시점에 어떤 작업이 어떤 순서로 실행되어야 하는지가 명확하게 기록되어 있으며, 시스템은 테이블을 참조해 정해진 시간에 그 작업을 실행하며, 시간 흐름에 따라 순차적으로 다음 작업을 처리합니다.
이는 대표적으로 항공기 제어 시스템, 우주선, 철도 제어 시스템 등 하드 리얼타임 시스템(Hard Real Time System) 에서 사용됩니다. 시스템은 작업이 반드시 정해진 시간에 완료되어야 하며, 미세한 타이밍 오류조차도 치명적인 결과를 초래할 수 있기 때문입니다. 즉, 스케줄의 예측 가능성, 정밀도, 일관성 이 중요한 곳에서 사용 합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 테이블 기반 스케줄링: 사전에 정의된 시간표(schedule table)에 따라 작업이 정확히 실행됨
# 각 작업은 실행 시각이 고정되어 있으며, 오차 없이 순서대로 수행되어야 함
시간 →
|---------|---------|---------|---------|---------|
t=0ms t=10ms t=20ms t=30ms t=40ms
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
[작업 A] [작업 B] [작업 C] [작업 A] [작업 B]
스케줄 테이블:
t=0ms → 작업 A 실행
t=10ms → 작업 B 실행
t=20ms → 작업 C 실행
t=30ms → 작업 A 실행
t=40ms → 작업 B 실행
...
하지만 이는 유연성이 낮다 는 단점이 있습니다. 작업의 추가, 제거, 변경이 필요할 경우 전체 스케줄 테이블을 다시 계산해야 하며, 이는 시간도 오래 걸리고 오류 가능성도 높습니다. 특히 작업 간 우선순위나 외부 이벤트 변화에 따라 유동적으로 대응해야 하는 상황에서는 부적합합니다. 또한 시스템이 커질수록 스케줄 테이블의 크기와 복잡성이 증가하게 되어 유지보수가 어려워집니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 테이블 기반 스케줄링: 작업 변경이 발생하면 전체 테이블을 다시 계산해야 함
기존 스케줄 테이블
시간 →
|----|----|----|----|----|----|
A | B | C | A | B | C |
작업 D 추가 요청
▼
변경 후 테이블
시간 →
|----|----|----|----|----|----|
A | D | B | C | A | B |
2-2. 사이클 기반 스케줄링
사이클 기반 스케줄링(Cyclic Scheduling)은 일정한 시간 주기(cycle time)를 기준으로 작업들을 미리 정해진 순서에 따라 주기적으로 반복 실행하는 방식입니다.
예를 들어, 하나의 사이클이 100ms이고 그 안에서 A → B → C 작업이 차례로 실행된다고 하면, 시스템은 100ms마다 동일한 순서로 A → B → C 작업을 반복해서 수행하게 됩니다. 사이클이 종료되면 다시 처음부터 동일한 작업 흐름이 시작되며, 이 구조는 무한히 반복됩니다. 구조가 단순하고 비교적 구현이 쉬우며, CPU 사용을 예측 가능하게 할 수 있다는 장점이 있습니다. 특히 일정 간격으로 반복되는 작업이 많은 임베디드 시스템, 공장 자동화, 센서 데이터 수집 장치 등에 활용됩니다.
1
2
3
4
시간 흐름 →
|------------ Cycle 1 ------------|------------ Cycle 2 ------------|------------ Cycle 3 ------------|
작업 A → 작업 B → 작업 C 작업 A → 작업 B → 작업 C ......
그러나 이 방식도 단점이 있습니다. 작업 간의 우선순위를 고려하기 어렵고, 사이클 내에 모든 작업을 처리하지 못할 경우 다른 작업에 영향이 발생할 수 있습니다.
1
2
3
시간 흐름 →
[ tick ]──▶[ 인터럽트 ]──▶[ 스케줄링 ]──▶[ 작업 실행 ]
타이머 시점 도달 순서/우선순위
또한, 외부 이벤트에 대한 즉각적인 반응이 어렵고, 모든 작업이 동일한 주기로 반복되므로 불필요한 반복 실행 이 발생할 수 있습니다.
- 작업 간 우선순위 조정이 어렵고,
- 사이클 내 모든 작업이 완료되지 않으면 타이밍 누락이 발생할 수 있으며,
- 외부 이벤트에 즉시 반응하지 못하고,
- 모든 작업이 동일 주기로 반복되므로 불필요한 실행이 생길 수 있습니다.
3. 세분화된 스케줄링 관점들
이 두 가지 핵심 축 외에도 스케줄러 설계를 더 깊이 이해하기 위해 고려할 수 있는 세분화된 관점들이 있습니다.
3-1. 워크플로우/의존성 기반 스케줄링
워크플로우/의존성 기반 스케줄링은 작업 간의 순서 와 의존 관계 를 기반으로 실행 순서를 제어하는 방식입니다. 예를 들어 A 작업이 완료된 후에만 B 작업이 실행되어야 하는 상황처럼, 선행 작업의 성공 여부나 특정 조건의 충족 여부에 따라 후속 작업이 실행됩니다. 이는 정교한 흐름 제어 가 가능하며 복잡한 데이터 파이프라인이나 비즈니스 프로세스를자동화하는 데 적합합니다.
이러한 스케줄링은 일반적으로 작업 간의 실행 순서와 의존 관계를 그래프 형태로 표현합니다. 그중 가장 널리 사용되는 방식이 방향성 비순환 그래프(DAG: Directed Acyclic Graph) 입니다.DAG는 방향성을 가지되 순환이 없는 구조로, 작업 흐름을 안정적으로 표현할 수 있으며, 무한 루프 없이 의존성을 따라 작업을 순차적으로 실행하도록 구성할 수 있습니다.
In mathematics, particularly graph theory, and computer science, a directed acyclic graph (DAG) is a directed graph with no directed cycles.
각 작업은 노드로 표현되고, 노드 간의 간선은 작업 간의 의존성을 의미합니다. 예를 들어 데이터 수집 → 정제 → 리포트 생성 → 리포트 발송 과 같은 작업 흐름을 정의하면, 스케줄러는 DAG 구조를 기반으로 각 작업의 상태를 추적 하고, 조건이 충족된 작업부터 실행 합니다. 대표적으로 Apache Airflow, AWS Step Functions 등이 있습니다. 이는 순차 실행뿐만 아니라, 조건 분기, 실패 시 재시도, 알림 발송 등 다양한 제어 로직도 지원합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
[Node A] 데이터 수집
│
├──▶ (성공) ──▶ [Node B] 데이터 정제
│ │
│ ├──▶ (성공) ──▶ [Node C] 리포트 생성
│ │ │
│ │ ├──▶ (성공) ──▶ [Node D] 리포트 발송
│ │ │
│ │ └──▶ (실패) ──▶ [Node X] 에러 알림
│ │
│ └──▶ (실패) ──▶ [Node X] 에러 알림
│
└──▶ (실패) ──▶ [Node X] 에러 알림
워크플로우/의존성 기반 스케줄링은 유연하고 정교한 흐름 제어가 가능하지만, 몇 가지 단점도 존재합니다. 먼저 작업 수가 많아질수록 DAG 구조가 복잡해져 가독성이 떨어지고 유지보수가 어려워집니다. 또한, 특정 작업에서 실패가 발생하면 후속 작업들이 모두 영향을 받기 때문에 디버깅이 까다롭습니다. 실행 중 조건 분기나 반복 같은 동적 흐름을 표현하기 어렵다는 점도 제약이며, 선행 작업 지연이나 실패로 인해 후속 작업이 대기하거나 불필요하게 리소스를 점유하는 비효율도 발생할 수 있습니다.
복잡한 DAG 구조: 작업 수가 많아질수록 가독성이 떨어지고 유지보수가 어려워짐실패 시 후속 작업 영향: 특정 작업 실패로 인해 전체 흐름이 중단되거나 지연될 수 있음동적 흐름 표현 어려움: 조건 분기나 반복 같은 동적 흐름을 표현하기 어려움비효율적인 리소스 사용: 선행 작업 지연이나 실패로 인해 후속 작업이 대기하거나 불필요하게 리소스를 점유할 수 있음
3-2. 리소스 기반 스케줄링
리소스 기반 스케줄링은 시스템 자원의 상태를 고려해 작업 실행 여부를 결정하는 스케줄링 방식입니다. 단순히 시간이나 작업 간의 의존성만을 기준으로 판단하는 것이 아니라, 현재 시스템에 해당 작업을 처리할 수 있는 리소스가 충분히 있는지를 먼저 확인하고, 조건을 만족할 때만 작업을 실행합니다. 이는 특히 분산 환경이나 클라우드, 고성능 컴퓨팅(HPC) 환경처럼 자원이 제한적 이고 동적으로 변화하는 시스템 에서 사용됩니다.
예를 들어 어떤 작업이 CPU 2코어와 메모리 4GB를 요구한다고 가정해 봅시다. 리소스 기반 스케줄러는 현재 클러스터 내에 그러한 자원을 확보할 수 있는 노드가 존재하는지를 탐색하고, 가능한 경우에만 작업을 해당 노드에 할당합니다.
1
2
3
4
5
6
7
[클러스터 상태]
Node A | CPU: 2 / 2 | Mem: 4GB / 4GB | ⭕ 가용
Node B | CPU: 4 / 4 | Mem: 8GB / 8GB | ⭕ 가용
Node C | CPU: 1 / 2 | Mem: 2GB / 4GB | ❌ 부족
[작업 요청]
작업 X 요구사항 → CPU: 2, Memory: 4GB
만약 리소스가 부족하다면, 스케줄러는 작업을 대기 상태로 유지하거나 리소스가 확보될 때까지 할당을 유보합니다. 이렇게 함으로써 시스템의 안정성을 유지하고, 과도한 리소스 점유로 인한 실패나 병목 현상을 방지할 수 있습니다.
1
2
3
4
5
6
7
8
9
[스케줄링 평가]
→ Node A: 조건 충족 → 작업 X 할당
→ Node B: 충족하지만 대기 중 or 예비 노드
→ Node C: 리소스 부족 → 할당 불가
[결과]
Node A | CPU: 0 / 2 | Mem: 0GB / 4GB | 🟢 작업 X 실행 중
Node B | CPU: 4 / 4 | Mem: 8GB / 8GB | 💤 대기
Node C | CPU: 1 / 2 | Mem: 2GB / 4GB | 🔴 부족
대표적인 시스템으로는 Kubernetes의 스케줄러가 있습니다. Kubernetes에서는 각 Pod의 리소스 요구사항(cpu, memory 등)을 정의하고, 클러스터 내 상태를 고려하여 적절한 노드에 할당합니다. Hadoop의 YARN도 클러스터 전체의 리소스를 효율적으로 분배하여 MapReduce, Spark 등 대규모 데이터 처리 작업을 관리합니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apiVersion: v1
kind: Pod
metadata:
name: resource-based-example
spec:
containers:
- name: example-container
image: busybox
command: ["sh", "-c", "sleep 3600"]
resources:
requests:
cpu: "2"
memory: "4Gi"
limits:
cpu: "3"
memory: "6Gi"
리소스 기반 스케줄링의 장점은 자원을 보다 효율적으로 사용할 수 있다는 점입니다. 시스템의 총 리소스를 고려해 작업을 배치하므로 과도한 부하 없이 안정적인 운영이 가능합니다. 또한 우선순위 설정, 자원 예약, 선점 등 다양한 정책을 통해 중요한 작업에 자원을 우선 배정하거나, 비중요 작업을 지연시켜 전체 시스템의 품질을 제어할 수도 있습니다.
효율적 자원 사용: 시스템의 총 리소스를 고려해 작업을 배치하여 안정적인 운영 가능우선순위 설정 및 예약: 중요한 작업에 자원을 우선 배정하거나 비중요 작업을 지연시켜 전체 시스템 품질 제어 가능동적 리소스 관리: 클러스터 상태에 따라 자원을 동적으로 할당하고 해제하여 유연한 운영 가능장애 대응 및 회복력 향상: 리소스 부족 시 작업을 대기 상태로 유지하거나 다른 노드로 재배치하여 시스템 안정성 향상
반면, 단점도 존재합니다. 리소스 상태가 계속 변하므로 스케줄링 결정이 복잡해지고, 대기 시간이 발생하거나 스케줄링 자체에 오버헤드가 생길 수 있습니다. 또한, 리소스를 요구한 대로 정의하지 않거나 너무 크게 정의할 경우, 실제 필요한 작업보다 많은 리소스를 점유하게 되어 다른 작업들의 실행을 방해할 수 있습니다.
복잡한 스케줄링: 리소스 상태가 계속 변하므로 스케줄링 결정이 복잡해짐대기 시간 및 오버헤드: 리소스 확보를 기다리는 동안 대기 시간이 발생하거나 스케줄링 자체에 오버헤드가 생길 수 있음리소스 정의 문제: 리소스를 요구한 대로 정의하지 않거나 너무 크게 정의할 경우, 실제 필요한 작업보다 많은 리소스를 점유하게 되어 다른 작업들의 실행을 방해할 수 있음
3-3. 수요 기반/온디맨드 스케줄링
수요 기반(Demand-Driven) 또는 온디맨드(On-Demand) 스케줄링은 미리 정해진 실행 시간이나 주기 없이, 외부의 요청이나 이벤트가 발생했을 때 그 즉시 작업을 실행하는 방식입니다. 이 방식은 시스템이 항상 대기 상태에 있으면서, 트리거가 발생하는 순간 즉각적으로 반응해 작업을 수행 합니다.
특정 시각이나 주기에 얽매이지 않고, 그 순간 필요한 일을 즉시 처리할 수 있어 유연하고 반응성이 뛰어납니다.
수요 기반 스케줄링은 주로 실시간 반응이 필요한 작업에 적합한데, 예를 들어, 이미지가 업로드되었을 때 자동으로 썸네일을 생성하거나, 사용자가 회원 가입을 완료했을 때 바로 환영 이메일을 발송하는 것 등이 있습니다. 이는 시스템 리소스를 불필요하게 점유하지 않고, 필요한 순간에만 작업을 실행하기 때문에 효율적입니다. 동시에 예측 불가능한 이벤트나 사용자 행동에도 유연하게 대응할 수 있어, 실시간성과 사용자 중심 서비스를 구현할 때 적합합니다. 다만 요청량이 급격히 증가할 경우를 대비해 확장성과 처리 대기 설계가 함께 고려되어야 합니다.
실시간 반응성: 외부 이벤트나 요청에 즉시 반응하여 작업을 실행유연한 작업 처리: 미리 정해진 시간이나 주기에 얽매이지 않고, 필요한 순간에만 작업을 수행효율적인 리소스 사용: 불필요한 리소스 점유 없이 필요한 순간에만 작업을 실행예측 불가능한 이벤트 대응: 사용자 행동이나 시스템 이벤트에 유연하게 대응 가능확장성 고려 필요: 요청량 급증 시 확장성과 처리 대기 설계가 필요
3-4. 목표 지향/선언적 스케줄링
목표 지향 또는 선언적 스케줄링은 기존의 명령형 또는 이벤트 기반 스케줄링과는 달리, 사용자가 원하는 최종 상태 를 선언하면, 시스템이 그 상태를 자동으로 유지하거나 달성하기 위해 필요한 작업을 알아서 수행하는 방식입니다. 사용자는 작업의 구체적인 실행 순서나 조건을 직접 지정하지 않습니다.
대표적인 예로 Kubernetes의 컨트롤러(Controller)가 있습니다. 예를 들어 인스턴스가 2개로 줄어들었다면 1개를 추가하고, 4개로 늘어났다면 1개를 제거하는 식입니다. 이러한 반복적인 조정 과정을 Reconciliation Loop 또는 Control Loop 라고 부르며, 시스템은 항상 현재 상태(Current State)와 목표 상태(Desired State)의 차이를 줄이기 위해 주기적으로 움직입니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3 # Desired State: 항상 3개 유지
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
이러한 방식은 단순히 장애를 복구하는 데 그치지 않고, 전체 시스템의 상태를 지속적으로 목표에 맞춰 일관되게 유지하려는 데 초점이 맞춰져 있습니다. 갑작스러운 노드 장애, 컨테이너 중단, 설정 손상 등의 상황이 발생하더라도, 시스템은 이를 감지하고 자동으로 원래 상태로 복구하려는 동작을 반복하게 됩니다. 이 덕분에 운영자가 직접 개입하지 않아도 시스템은 스스로 안정적인 상태를 유지하려고 노력하며, 회복 탄력성( Resilience) 과 자율성(Self-Healing) 이 생깁니다.
최종 상태 선언: 사용자가 원하는 최종 상태를 선언하면, 시스템이 이를 자동으로 유지하거나 달성하기 위해 필요한 작업을 수행자동 조정 및 복구: 시스템은 현재 상태와 목표 상태의 차이를 줄이기 위해 주기적으로 조정 작업을 수행회복 탄력성 및 자율성: 갑작스러운 장애나 설정 손상에도 시스템이 스스로 안정적인 상태를 유지하려고 노력
목표 지향 스케줄링은 시스템이 스스로 상태를 조정하는 자율성을 제공하지만, 몇 가지 단점도 존재합니다. 먼저, 선언된 설정이 잘못되면 시스템이 잘못된 상태를 반복적으로 유지하려 해 전체에 영향을 줄 수 있습니다. 또한 외부 변화에 과도하게 반응하면서 불필요한 자원 소모가 발생할 수 있고, 대규모 환경에서는 성능 저하로 이어질 수 있습니다. 모든 구성이 선언에 의존하다 보니 수동 제어나 예외 처리도 어렵고, 운영자가 구조를 정확히 이해하지 못하면 문제 대응이 더 복잡해질 수 있습니다.
잘못된 선언 문제: 선언된 설정이 잘못되면 시스템이 잘못된 상태를 반복적으로 유지하려 해 전체에 영향을 줄 수 있음과도한 반응성: 외부 변화에 과도하게 반응하면서 불필요한 자원 소모가 발생할 수 있음대규모 환경 성능 저하: 대규모 환경에서는 성능 저하로 이어질 수 있음수동 제어 어려움: 모든 구성이 선언에 의존하다 보니 수동 제어나 예외 처리도 어렵고, 운영자가 구조를 정확히 이해하지 못하면 문제 대응이 더 복잡해질 수 있음
4. 정리
스케줄링에 어떤 종류가 존재하는지, 각 스케줄링 방식의 특징과 장단점은 무엇인지, 그리고 어떤 상황에서 어떤 스케줄링 방식을 선택해야 하는지에 대해 알아보았습니다. 개념 정리를 위해 분류를 했는데요, 사실 하나의 스케줄링에서는 여러 가지 방식의 장점을 혼합해 사용 합니다. 또한 분류한 내용 외에도 다른 기준으로 으로 스케줄링을 할 수도 있고요. 따라서 이 글을 맹목적으로 보기 보다 스케줄링의 기본 개념을 이해하고, 각 방식의 특징을 파악하는 데 중점을 두면 좋을 것 같습니다.
- Difference between Clock-driven and Event-driven Scheduling
- Difference between Table-driven and Cyclic Scheduling
- Scheduling Mechanisms in ETAS DMS
- Resource Management for Pods and Containers
- Apache Hadoop YARN
- Hadoop: YARN Resource Configuration
- Hadoop: Capacity Scheduler
- Slurm - Scheduling Configuration Guide
- Slurm - Generic Resource (GRES) Scheduling
- Finite State Machine
- BPMN(Business Process Model and Notation)