대상 OS: Ubuntu Server 24.04 LTS

보안 사고는 반드시 “침입”으로만 시작하지 않습니다.
한 번의 버그, 한 번의 잘못된 요청, 혹은 한 번의 악성 트래픽이 서비스 프로세스를 폭주시켜 서버를 멎게 만들기도 합니다.
CPU 100%로 붙거나, 메모리가 바닥나 OOM이 터지면, 그 순간부터는 장애가 곧 보안 이슈가 됩니다(모니터링 공백, 자동 복구 루틴 오작동, 데이터 손상 등).
Ubuntu 24.04에서는 systemd의 cgroup 제어를 이용해 서비스별로 CPU/메모리/프로세스 수를 제한하고, systemd-oomd로 메모리 압박 상황에서 “무작위가 아닌 정책적 종료”를 만들 수 있습니다.

이 글은 systemd 리소스 제한을 이용해 서비스 폭주(DoS, 버그, 무한 스폰)를 완화하는 실전 구성과, 적용 시 실수/장애를 줄이는 롤아웃 방법을 정리합니다.

---

1) 왜 ‘리소스 제한’이 보안 하드닝인가

1) 애플리케이션 폭주로 인한 서비스 거부(DoS) 위험을 낮춘다

2) 한 서비스가 전체 노드를 먹어 다른 중요한 데몬(SSH, 로깅, 모니터링)을 죽이는 걸 막는다

3) 공격자가 fork bomb/무한 스레드로 노드를 마비시키는 비용을 올린다

4) 장애를 “전체 다운”이 아니라 “부분 영향”으로 격리한다

방화벽과 인증이 “들어오는 것”을 줄인다면, 리소스 제한은 “들어온 뒤(또는 내부에서) 폭주하는 것”을 줄입니다.

---

2) 변경 전 점검: 서비스가 무엇을 얼마나 쓰는지

1) 현재 시스템 부하 빠르게 확인

uptime
free -h
vmstat 1 5

2) systemd 관점에서 상위 자원 사용 유닛 확인

systemd-cgtop -b -n 1 | head -n 40

3) 특정 서비스(예: nginx) 상태/유닛명 확인

systemctl status nginx --no-pager || true
systemctl status ssh --no-pager

4) 유닛의 현재 제한값 확인

systemctl show nginx -p CPUQuota -p MemoryMax -p TasksMax -p LimitNOFILE -p Slice -p OOMPolicy 2>/dev/null || true

적용 전에는 “정상 시 얼마나 쓰는지”를 최소 하루 정도 관찰하는 게 안전합니다.

---

3) 기본 전략: drop-in override로만 조정하기

배포 패키지의 유닛 파일을 직접 수정하면, 업데이트 때 덮어써집니다.
Ubuntu에서는 drop-in override(`/etc/systemd/system/.d/override.conf`)로 제한을 거는 것이 정석입니다.

1) override 편집(대화형)

sudo systemctl edit nginx

편집기를 열기 어렵다면 아래처럼 파일을 직접 생성해도 됩니다.

---

4) CPU 폭주 완화: CPUQuota로 상한선 두기

CPUQuota는 “이 유닛이 쓸 수 있는 CPU 시간의 비율”을 제한합니다.
예를 들어 2 vCPU에서 100%는 1 vCPU를 온전히 쓰는 수준이고, 200%는 2 vCPU를 다 쓰는 수준입니다.

1) 예시: nginx에 CPU 80% 상한

sudo mkdir -p /etc/systemd/system/nginx.service.d
sudo tee /etc/systemd/system/nginx.service.d/10-resource-limits.conf >/dev/null