Amazon Linux 2023을 사용하다 보면 이전과 다른 점이 눈에 띄기 시작합니다.
특히 tuned-adm 기반 성능 프로파일링이 사라지고,
대신 systemd와 cgroup 기반의 자원 제어 방식으로 전환된 부분이 인상 깊습니다.
그렇다면 Amazon Linux 2023과 유사한 구조를 가진 OS는 무엇일까요? 그리고 왜 이런 변화가 생겼을까요?
1. Amazon Linux 2023의 핵심 구조 특징
먼저 Amazon Linux 2023(AL2023)의 핵심을 정리하면 다음과 같습니다:
- systemd 기반
- cgroup v2 기본 적용
- 커널 5.x 계열
- cloud-native workload 가정
- Hypervisor가 CPU/Power/Scaling 제어
- tuned 패키지 미제공
- OS 전체가 아니라 서비스 단위 resource control 모델
즉 성능 관리 방식이 기존과 다르게:
OS 최적화 → Workload 최적화로 이동한 구조입니다.
2. 그러면 어떤 OS가 Amazon Linux 2023과 유사할까?
비슷한 구조와 운영 모델을 가진 OS들은 다음과 같습니다:
- RHEL 9 / Rocky 9 / AlmaLinux 9
- Fedora 34+
- Ubuntu 22.04+ (특히 container환경)
- SUSE MicroOS / SLE Micro
- Bottlerocket (AWS가 만든 container OS)
- Flatcar Container Linux
이 OS들은 공통적으로:
- cgroup v2
- systemd 기반
- resource slicing / quota
- workload 단위 isolation
- kernel 5.x 기반
즉 Amazon Linux 2023과 같은 철학을 공유합니다.
3. 반대로 “예전 tuning 모델”을 가진 OS들
다음 운영체제는 Amazon Linux 2023과 결이 다릅니다:
- RHEL 6/7 계열
- CentOS 6/7
- Oracle Linux 6/7/8 일부
- Amazon Linux 2
- Ubuntu 18.04 이하
이 OS들은 다음과 같은 특징이 있습니다:
- 성능 프로파일링 = OS가 담당
tuned-adm사용- OS 전체를 throughput/performance mode로 변경
- THP / CPU governor / scheduler / power mode를 OS가 직접 관리
즉 이들은 “시스템 전체 최적화” 시대의 모델이었습니다.
4. 변화의 본질 — 왜 이런 전환이 일어났을까?
큰 이유는 두 가지입니다:
① Cloud & Container 시대 도래
컨테이너가 등장하고 microservice가 늘어나며 “서버 전체”를 성능 프로파일링하는 방법이 맞지 않게 되었습니다.
대신 서비스 단위로 자원을 분배해야 했습니다:
CPUQuota=
MemoryMax=
TasksMax=
IOWeight=
② Hypervisor가 CPU/Power 기능을 가져감
AWS에서 VM을 실행할 때, CPU scaling, power saving, P-state 관리 등은 이미 AWS hypervisor가 맡습니다.
따라서 tuned-adm profile throughput-performance 같은 명령이 더 이상 OS 차원에서 유효하지 않습니다.
5. Splunk, Kafka, DB 관점에서 의미
Splunk, Kafka, ES, DB를 운영하는 입장에서는 이 변화가 중요합니다.
왜냐하면 이전에는 성능 튜닝 가이드에서 다음을 요구했었기 때문입니다:
- tuned profile 적용
- THP disable
- CPU governor performance
- scheduler tuning
그러나 Amazon Linux 2023에서는 다음 형태로 재해석됩니다:
- THP는 systemd로 disable
- 자원은 cgroup으로 control
- I/O는 EBS QoS로 해결
- CPU scaling은 hypervisor가 담당
즉 Splunk용 커스텀 tuned profile은 더 이상 의미가 없습니다.
7. 그럼 기존처럼 커스텀 프로파일을 만들어서 설정하면 되지 않나?
많은 운영자들이 예전 RHEL7/CentOS7/Amazon Linux2 시절에 아래 같은 형태로 Splunk나 DB용 프로파일을 따로 만들어서 사용했습니다:
/etc/tuned/splunk/tuned.conf
여기에는 throughput-performance를 include 하고 THP를 끄는 옵션을 추가하는 방식이었죠.
이 방식은 당시에는 아주 합리적이었습니다.
하지만 Amazon Linux 2023에서는 구조적으로 비효율적인 방식이 되어버렸습니다.
7-1. 시스템 전체를 대상으로 튜닝하는 모델의 한계
커스텀 프로파일 방식의 가장 큰 문제는 "서버 전체를 대상으로 튜닝"한다는 점입니다.
즉 모든 서비스가 동일한 성능 프로파일을 강제로 공유하게 됩니다.
하지만 현대 클라우드 환경에서는 하나의 VM/노드 내부에 다음과 같은 다양한 workload가 공존합니다:
- Search / Query / Latency workload
- Indexing / Batch workload
- DB / KV / Broker workload
- Sidecar / Agent workload
- Logging / Monitoring workload
각 workload는 서로 다른 특성을 가지므로, 시스템 전체에 동일한 튜닝값을 적용하는 방식은 더 이상 최적이 아닙니다.
현대 성능 튜닝은 “서버 단위”가 아니라 “서비스 단위”로 이동했다.
7-2. 리소스 공유 경쟁(Resource Contention)을 제어할 수 없음
커스텀 프로파일 방식은 OS 단위에서 최소한의 스위치를 켜고 끄는 수준이었기 때문에 다음 문제가 있었습니다:
- CPU를 누가 얼마나 쓰는지 모름
- Memory를 누가 잠식하는지 모름
- Thread 수를 workload별로 제한할 수 없음
- I/O Weight를 서비스 단위로 조절할 수 없음
결국 서버 전체가 성능 최적화 되었더라도, 서비스끼리 서로 자원을 뺏어가는 문제는 해결되지 않았습니다.
7-3. cgroup 및 systemd 시대에서는 더 강력한 제어가 가능
반면에 현재 Amazon Linux 2023은 다음과 같이 서비스별로 자원을 제어할 수 있습니다:
CPUQuota=
MemoryMax=
TasksMax=
IOWeight=
이 방식은 Splunk와 같은 고성능 애플리케이션에 특히 유리합니다. 예를 들어:
- Indexer는 IO Weight를 높게
- Search Head는 CPU Quota를 넉넉하게
- Agent/Sidecar는 Thread 제한
- Monitoring/Logging은 저우선순위
즉 서비스 단위로 자원을 “분리”하고 “보장”하는 것이 가능합니다.
커스텀 프로파일은 성능을 올렸지만, cgroup은 성능을 “보장”한다.
7-4. Hypervisor가 Power/CPU Scaling을 가져간 이후의 비효율
AWS 환경에서는 성능과 전력 관리를 Hypervisor가 담당합니다. 따라서 OS에서 performance governor를 설정하거나 energy mode를 조정해도 효과가 제한적입니다.
즉 아래 명령은 이미 의미가 떨어졌습니다:
$ tuned-adm profile throughput-performance
커스텀 프로파일은 여전히 이 모델에 의존하기 때문에 AWS 환경에서는 실질적인 효율이 떨어집니다.
7-5. 최종 결론
요약하면, 다음 이유들로 인해 커스텀 프로파일 방식은 현대 클라우드 환경에서 구조적으로 비효율적입니다:
- 서버 전체 대상 → 개별 서비스별 자원 제어가 불가능
- workload의 다양성과 경쟁 문제 해결 불가
- Hypervisor 제어 모델과 충돌
- cgroup/systemd 기반 quota/limit 모델로 이동
- Splunk/DB/Broker 계열은 latency와 자원 분리를 요구함
따라서 Amazon Linux 2023에서는 커스텀 tuned 프로파일 대신:
- THP는 systemd 방식으로 disable
- 자원은 cgroup으로 제한/보장
- I/O는 EBS QoS로 관리
- 스케일링은 AWS Hypervisor가 담당
이 방식이 더 자연스럽고 현대적입니다.
7-6. 한 줄 요약
커스텀 프로파일은 “서버 전체 튜닝” 시대의 도구였고,
Amazon Linux 2023은 “서비스 단위 자원 제어” 시대의 OS이기 때문에
이제는 구조적으로 비효율적인 방식이 되었다.
'Linux' 카테고리의 다른 글
| Linux 개념 | AWS Linux 2023에서 THP Disable 방법 (0) | 2026.01.25 |
|---|---|
| Linux 개념 | ulimit의 역사 : nproc 값을 왜 제한했었고, 왜 이제는 unlimited인가? (0) | 2026.01.25 |
| Linux 개념 | ulimit 사용 가이드: soft/hard, nofile, nproc 쉽게 정리 (0) | 2026.01.25 |
| Linux 개념 | 파일 디스크립터(File Descriptor, FD) 확인 법 (0) | 2026.01.25 |
| Linux 개념 | 파일 디스크립터(File Descriptor, FD)란? (0) | 2026.01.25 |