1. 왜 ‘시끄러운 이웃’은 필연적으로 발생하는가?

쿠버네티스 운영의 핵심은 자원 공유(Resource Sharing)입니다. 하지만 공유는 필연적으로 경합(Contention)을 부릅니다.

• 발생의 인과관계: 1. 물리 노드 하나에 여러 파드를 배치(Bin Packing)하여 비용을 절감한다.

2. 특정 파드(A)의 트래픽이 급증하거나 로직상의 루프가 발생한다.
3. 파드(A)가 노드의 공유 자원(CPU, Memory 등)을 한계치까지 점유한다.
4. 동일 노드의 파드(B)가 사용할 자원이 부족해져 성능 저하 또는 중단이 발생한다.

이러한 ‘원인(자원 공유) - 과정(특정 파드의 폭주) - 결과(타 서비스 피해)‘의 고리를 끊기 위해 쿠버네티스는 크게 두 가지 통제 장치를 제공합니다. 바로 **QoS(Quality of Service)**와 PriorityClass입니다.

---

2. 자원 성격에 따른 피해

자원의 종류에 따라 ‘시끄러운 이웃’이 끼치는 영향이 다릅니다. 이를 이해해야 적절한 대응책을 세울 수 있습니다.

자원 유형	성격	자원 부족 시 발생하는 인과관계	결과
CPU	압축 가능 (Compressible)	공유 CPU 사이클을 특정 파드가 독점 → 타 파드에 할당될 CPU 시간 부족	Throttling(스로틀링): 서비스 연산 속도 저하 및 응답 지연
Memory	압축 불가능 (Incompressible)	물리 메모리 고갈 → 커널이 시스템 생존을 위해 우선순위 낮은 프로세스 강제 종료	OOM Kill: 파드 비정상 종료 및 재시작 (Liveness Probe 실패)
Disk I/O	공유 대역폭 (Shared BW)	대량의 로그/파일 쓰기로 I/O 채널 점유 → 타 파드의 커널 레벨 입출력 대기	I/O Wait: 시스템 전체 프리징 및 앱 타임아웃 발생
Network	공유 대역폭 (Shared BW)	특정 파드가 대용량 데이터 전송(Backup, 배포 등)으로 NIC 대역폭 점유 → 패킷 전송 대기	Latency & Packet Loss: 네트워크 응답 지연 및 데이터 유실로 인한 재전송 증가

---

3. QoS Classes (자원 사용 패턴)

쿠버네티스는 파드가 선언한 requests와 limits를 보고 자동으로 계급을 매깁니다. 이 계급은 노드 자원이 부족할 때 “누가 먼저 쫓겨날 것인가(Eviction)“를 결정한다.

① Guaranteed (최상위: 확실한 보장)

• 설정: requests == limits (CPU/Memory 모두 설정 시)
• 인과관계: 스케줄러가 해당 자원을 전용으로 예약함 → 이웃 파드가 아무리 시끄러워도 자원을 뺏기지 않음.
• 용도: 데이터베이스, 결제 엔진 등 절대 죽으면 안 되는 핵심 서비스.

② Burstable (중간층: 유동적 효율성)

• 설정: requests < limits (혹은 둘 중 하나만 설정 시)
• 인과관계: 평소엔 적게 먹다가 필요할 때만 더 씀 → 노드 자원이 부족해지면 Guaranteed를 살리기 위해 1순위 퇴거 후보가 됨.
• 용도: 일반적인 API 서버, 웹 프론트엔드 등 대부분의 마이크로서비스.

③ BestEffort (최하위: 남는 자원 활용)

• 설정: requests, limits 모두 없음.
• 인과관계: 자원 예약이 전혀 없음 → 노드에 아주 작은 압박만 와도 즉시 쫓겨남.
• 용도: 로그 수집기, 임시 배치 작업 등 중요도가 낮은 보조 작업.

---

4. PriorityClass (비즈니스 중요도의 서열화)

QoS가 자원 사용의 ‘기술적 등급’이라면, PriorityClass는 “이 서비스가 우리 비즈니스에 얼마나 중요한가?”를 나타내는 ‘정책적 서열’입니다.

• Preemption(선점)의 인과관계

1. 클러스터 자원이 가득 찬 상태에서 High-Priority 파드가 배포 요청됨.
2. 스케줄러가 노드를 탐색하지만 자리가 없음.
3. 현재 실행 중인 파드 중 Low-Priority인 파드를 찾아 강제로 종료(Preempt) 시킴.
4. 확보된 자리에 중요한 파드를 배치함.

요소	QoS Class	PriorityClass
결정 주체	자원 설정값에 의해 시스템이 자동 부여	관리자가 직접 이름과 점수를 부여
주요 역할	노드 압박 시 누구를 먼저 죽일지 결정	자원 부족 시 누구를 먼저 배포할지 결정
핵심 지표	자원 할당 효율성 (Efficiency)	서비스 중요도 (Criticality)

---

5. 시끄러운 이웃 해결을 위한 실무 아키텍처 가이드

단순히 이론을 아는 것을 넘어, 실제 환경에서 인과관계를 통제하기 위한 전략입니다.

1. LimitRange 도입 (강제성 부여): 개발자가 자원 설정을 누락하면 BestEffort 파드가 양산되어 클러스터가 불안정해집니다. 네임스페이스 단위로 LimitRange를 설정하면, 설정을 누락한 파드에 자동으로 기본값을 부여하여 ‘무법자 파드’의 발생을 원천 차단합니다.
2. ResourceQuota 설정 (영역 격리): 특정 팀이나 서비스가 클러스터 전체 자원을 독점하지 못하도록 네임스페이스별 총합 자원을 제한합니다. 이는 “한 팀의 실수로 회사 전체 서비스가 마비되는 인과관계”를 차단합니다.
3. Taints & Tolerations (물리적 격리): I/O 부하가 극심한 파드나 CPU 점유율이 높은 특정 배치 작업은 아예 특정 노드(Tainted Node)에만 배치되도록 격리합니다. “위험한 이웃과 일반 이웃이 같은 아파트에 살지 못하게” 분리하는 전략입니다.
4. TerminationGracePeriodSeconds 최적화:PriorityClass에 의해 파드가 쫓겨날 때, 종료되는 파드가 데이터를 안전하게 저장하고 죽을 수 있도록 유예 시간을 적절히 설정해야 합니다.

---

6. 결론

쿠버네티스 운영에서 발생하는 모든 문제는 인과관계가 명확합니다.

• *‘시끄러운 이웃’**은 시스템의 결함이 아니라, 공유 자원 환경에서 발생하는 자연스러운 물리 현상입니다.
• 이를 해결하는 것은 수동적인 모니터링이 아니라, QoS와 PriorityClass라는 규칙을 통해 예측 가능한 시스템을 설계하는 것입니다.

이 리포트를 통해 복습하며 강조하고 싶은 점은, **“모든 파드에는 반드시 최소한의 requests를 설정해야 한다”**는 것입니다. 이것이 스케줄러가 ‘옆집’의 소음 수치를 미리 계산하고 배치할 수 있게 만드는 첫 단추이기 때문입니다.