Linux 개념 | ulimit의 역사 : nproc 값을 왜 제한했었고, 왜 이제는 unlimited인가?

리눅스 서버 운영 가이드나 보안 설정 문서를 보면 예전부터 다음과 같은 설정을 자주 볼 수 있습니다:

 

hard nproc 100000
soft nproc 100000

 

그런데 최근 배포판을 보면 ulimit -u 결과가 아래처럼 나옵니다:

 

$ ulimit -u
unlimited

 

이 글에서는 "왜 과거에는 nproc를 제한했는지" 그리고 "언제부터 unlimited가 일반화되었는지"를 운영 환경과 커널 변화 측면에서 정리해봅니다.

---

1. nproc란 무엇인가?

nproc은 하나의 사용자 또는 프로세스가 생성할 수 있는 프로세스 및 스레드 수의 최대치를 의미합니다.

확인 명령:

 

$ ulimit -u

---

2. 예전에는 왜 nproc를 제한했을까?

과거 리눅스 운영 환경에서는 다음 조건들이 매우 흔했습니다:

• 다수 사용자가 동일 서버에 SSH 접속
• 서버가 공용 자원 형태로 운영 (대학/HPC/연구소)
• Shell 제공 기반 시스템 (multi-user environment)
• DoS 위험을 대비한 프로세스 남용 방지

이런 환경에서 누군가 악의적이거나 실수로 다음을 실행하면 큰일이 납니다:

$ :(){:|:&};:

 

이른바 fork bomb이고, 시스템은 프로세스/스레드가 폭발적으로 생성되며 사실상 다운됩니다.

이런 데미지를 막기 위해 nproc 제한이 가장 단순하고 무식한 보호막이었습니다.

즉, 과거 nproc 제한 = 멀티유저 서버 환경에서의 보안/격리 목적.

---

3. 왜 최근에는 unlimited가 됐을까?

최근 리눅스 커널, 운영 환경, 서버 아키텍처가 크게 바뀌었기 때문입니다. 핵심 이유는 다음과 같습니다:

3-1. 서버가 더 이상 multi-user shell을 제공하지 않음

현대 서버는 대부분 다음 형태입니다:

• 단일 서비스 서버 (ex. Splunk, Kafka, DB, Web)
• 컨테이너 기반
• Pod/Service 단위 리소스 격리
• IaaS/PaaS 기반

즉 사용자 경쟁이 아니라 서비스 단위 경쟁이 됨.

 

3-2. 리소스 제어 방식이 kernel → cgroups/systemd로 이동

커널 개발자들은 더 세밀하게 제어 가능한 도구를 도입했습니다:

• cgroups (CPU/Memory/PID/IO 제어)
• systemd (서비스 단위 PID/Tasks 제한 지원)
• Namespaces (격리)

특히 systemd에는 다음 값이 있습니다:

 

TasksMax=

 

사실상 nproc을 대체하는 역할입니다.

 

3-3. PID 공간이 32bit → 64bit 확장

PID와 Thread 관리 범위가 확장되며 nproc 제한 필요성이 줄었습니다.

 

3-4. JVM 기반 서비스 증가

현대 서비스는 스레드를 많이 씁니다:

• Java (JVM)
• Spark
• Kafka
• Elasticsearch
• Splunk 일부 컴포넌트

여기서 nproc을 낮게 걸면 서비스가 오히려 죽습니다.

---

 

4. 그래서 언제부터 unlimited가 적용되었나?

배포판 기준으로 보면 대략 아래 흐름입니다:

• RHEL 6 / CentOS 6 → 기본 제한 존재
• RHEL 7 / CentOS 7 → 완화, systemd 일부 도입
• RHEL 8 / Rocky / Alma / Amazon Linux 2 → 사실상 unlimited
• RHEL 9 / Amazon Linux 2023 → 완전 unlimited + cgroup 기반 제어

즉 커널 개발자들이 “기본 제한 방식 → 격리/조절 방식”으로 전환한 흐름입니다.

---

 

5. 요즘은 어떻게 설정하는 게 맞을까?

운영 관점에서는 다음 접근이 가장 적절합니다:

• nofile (FD 개수): 튜닝 필수
• nproc: unlimited 또는 systemd/cgroup로 조절

이유:

• nofile은 실제 서비스 처리량에 직접 영향
• nproc은 service-level isolation이 더 적합

---

6. nproc을 제한해야 하는 유일한 경우

아래 상황에서는 nproc 제한이 여전히 의미 있습니다:

• 공용 Shell 서버
• HPC Cluster
• 대학/연구용 시스템
• Multi-user 환경
• 보안 정책(Hardening 요구)

---

7. 중간 정리

과거에는 fork bomb 등 DoS 방어를 위해 nproc을 제한했지만,
현대 환경에서는 단일 서비스 기반 + cgroup/systemd 제어로 인해 nproc 제한이 사실상 필요 없어졌고,
커널도 이를 반영해 기본값을 unlimited로 전환했다.

따라서 운영 가이드에서 이제는 nofile만 명확히 설정하고, nproc은 unlimited 유지하는 방향이 더 적합합니다.

---

 

8. Splunk 환경에서는 nproc을 굳이 제한할 필요가 있을까?

Splunk 환경에서는 nproc을 커널 레벨에서 제한할 필요가 없다.
사용자 검색 과다나 자원 독식 위험은 존재하지만, 그 위험은 Splunk 내부에서 제어하는 것이 더 적절한 방식

---

8-1. Splunk에서 문제가 되는 상황

Splunk에서 과도한 자원을 소비하는 경우는 주로 아래 두 가지입니다:

• 사용자 검색이 과도하게 복잡하거나 비효율적일 때
• 동시에 너무 많은 검색이 실행될 때 (concurrency 폭주)

이 문제는 서비스 레이어의 워크로드 문제임

따라서 해결도 서비스 레이어에서 하는 것이 자연스럽다.

---

8-2. Splunk가 제공하는 제어 기능

다행히 Splunk는 이미 이 문제를 다루기 위한 다양한 제어 기능을 제공합니다:

• Role 기반 제어
  쿼리 동시 실행 개수 제한, RT Search 제한, 검색 시간창 제한
• Workload Management
  Priority 기반 자원 할당, Resource Pool 구성
• Indexing vs Search 자원 분리
  Search Head / Indexer 분리 아키텍처
• Systemd/cgroup 기반 Control
  CPUQuota, MemoryMax 등을 통한 서비스 단위 자원 제한

즉 문제를 “검색 단위”에서 정확하게 조절할 수 있습니다.

---

8-3. 왜 커널 nproc 제한은 적절하지 않을까?

커널 레벨에서 nproc을 제한하면 아래 문제가 발생하게 됩니다:

• 스레드가 누구 소유인지 구분하지 못함
• 검색 스레드뿐 아니라 JVM, Pipeline, Scheduler 등까지 같이 제한됨
• Search 하나가 아니라 Splunk 전체가 튕길 위험

즉 커널 레벨에서 nproc 제한은 너무 둔탁한(blunt) 도구입니다.

“Kernel-level nproc limiting is a blunt instrument for a Splunk workload problem.”

문제는 Splunk 레이어인데 칼을 커널 레벨에서 휘두르는 셈입니다.

---

8-4. 그렇다면 nproc 제한은 언제 쓰는가?

nproc 제한 자체가 나쁜 것이 아니며, 아래 환경에서는 여전히 유효합니다:

• 공용 Shell 서버
• Multi-user UNIX 환경
• 대학/HPC cluster
• 연구용 서버
• 보안 정책 기반 하드닝 필요 시
• DoS 공격 대비 (fork bomb 등)

즉 문제의 성격이 사용자 경쟁 환경일 때 의미가 있습니다.

---

8-5. Splunk 환경에 대한 결론

Splunk는 검색이 사용자 단위로 실행되지만 자원 배분은 Splunk 내부에서 제어하는 것이 더 자연스럽다.

 

따라서 Splunk 운영 환경에서는:

• nofile ⇒ 반드시 조정
• nproc ⇒ 커널 제한보다는 Splunk Workload 제어가 더 적합

그리고 커널이 이미 nproc = unlimited로 설계된 최신 환경에서는 이 방향이 더 잘 맞습니다.