Amazon EC2 RHEL에서 User Data로 SSM Agent 설치했더니 OOM이 발생했다
안녕하세요 클래스메소드 김재욱(Kim Jaewook) 입니다. 이번에는 Amazon EC2 RHEL에서 User Data로 SSM Agent를 설치했더니 OOM이 발생했기 때문에 해결 방법을 정리해 봤습니다.
문제 발생
RHEL에서는 SSM Agent가 기본으로 설치되어 있지 않으므로 직접 설치해야 합니다.
이에 따라 아래와 같이 EC2 생성 시 User Data에 설치 스크립트를 추가하면, 인스턴스가 생성되는 동시에 SSM Agent를 사용할 수 있습니다.
#!/bin/bash
cd /tmp
REGION_NAME=$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone | sed -e 's/.$//')
dnf install -y https://s3.${REGION_NAME}.amazonaws.com/amazon-ssm-${REGION_NAME}/latest/linux_amd64/amazon-ssm-agent.rpm
systemctl enable amazon-ssm-agent
systemctl start amazon-ssm-agent
하지만 EC2 생성 후 Systems Manager에서 확인해 보니 SSM Agent가 연결되지 않은 상태였습니다.
EC2 콘솔에서 작업 → 모니터링 및 문제 해결 → 시스템 로그 가져오기 를 통해 로그를 확인해 보니 다음과 같은 오류가 발생했습니다.
SSM 실행에 실패한 것을 확인할 수 있습니다.
[ 181.142819] cloud-init[1622]: SystemExit: 1
[ 181.142876] cloud-init[1622]: ------------------------------------------------------------
[ 181.232391] cloud-init[1622]: Failed to enable unit: Unit file amazon-ssm-agent.service does not exist.
[ 181.276643] cloud-init[1622]: Failed to start amazon-ssm-agent.service: Unit amazon-ssm-agent.service not found.
amazon-ssm-agent.service가 존재하지 않는다는 것은 SSM Agent 패키지 설치 자체가 완료되지 않았다는 의미입니다.
처음에는 RPM 다운로드나 User Data 스크립트에 문제가 있다고 생각했지만, 시스템 로그를 조금 더 살펴보니 원인은 OOM(Out Of Memory)이었습니다.
[ 180.292679] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/cloud-final.service,task=dnf,pid=1672,uid=0
[ 180.293397] Out of memory: Killed process 1672 (dnf) total-vm:761572kB, anon-rss:482632kB, file-rss:32kB, shmem-rss:0kB, UID:0 pgtables:1128kB oom_score_adj:0
[ 180.829663] cloud-init[1622]: /var/lib/cloud/instance/scripts/part-001: line 4: 1672 Killed dnf install -y https://s3.${REGION_NAME}.amazonaws.com/amazon-ssm-${REGION_NAME}/latest/linux_amd64/amazon-ssm-agent.rpm
로그를 보면 dnf 프로세스가 OOM Killer에 의해 강제 종료된 것을 확인할 수 있습니다.
SSM Agent RPM 파일의 크기는 약 25MB에 불과하지만, dnf는 패키지의 의존성을 확인하고 메타데이터를 처리하는 과정에서 RPM 파일 크기보다 훨씬 많은 메모리를 사용합니다.
이번 테스트에서는 메모리 1GB인 t3.micro 인스턴스를 사용하고 있었는데, cloud-init이 실행되는 초기 부팅 과정과 dnf의 메모리 사용량이 겹치면서 결국 OOM이 발생했고, SSM Agent 설치가 중간에 종료되었습니다.
그 결과 패키지가 정상적으로 설치되지 않았고, amazon-ssm-agent.service도 생성되지 않아 이후 systemctl enable과 systemctl start가 모두 실패했던 것입니다.
문제 해결
가장 간단한 해결 방법은 EC2 인스턴스의 메모리를 늘리는 것입니다.
방법 1. 인스턴스 유형을 변경
이번 테스트에서는 t3.micro(1GiB) 대신 t3.small(2GiB)로 인스턴스 유형을 변경하여 동일한 User Data를 실행했습니다.
인스턴스 생성 후 확인해 보니 SSM Agent가 정상적으로 설치되고, Systems Manager에도 관리형 노드로 등록되었습니다.
시스템 로그를 확인해 봐도 amazon-ssm-agent가 정상적으로 설치되고 서비스가 시작된 것을 확인할 수 있습니다.
[OK] Started amazon-ssm-agent.
amazon-ssm-agent-3.3.4793.0-1.x86_64 → Complete!
2026/07/13 05:48:31Z: Amazon SSM Agent v3.3.4793.0 is running
2026/07/13 05:48:31Z: OsProductName: Red Hat Enterprise Linux
2026/07/13 05:48:31Z: OsVersion: 9.6
Cloud-init v. 24.4-4.el9_6.5 finished
[OK] Reached target Cloud-init target.
dnf가 설치 과정에서 사용할 수 있는 메모리가 충분해지면서 OOM이 발생하지 않았고, SSM Agent 설치와 서비스 등록이 모두 정상적으로 완료되었습니다.
방법 2. Swap 메모리 추가
두 번째 방법은 t3.micro 인스턴스를 그대로 사용하면서 Swap 메모리를 추가하는 것입니다.
물리 메모리(RAM)는 그대로지만, 디스크 일부를 Swap 영역으로 사용해 일시적인 메모리 부족을 완화할 수 있습니다.
User Data는 다음과 같이 Swap을 생성한 후 SSM Agent를 설치하도록 구성했습니다.
#!/bin/bash
dd if=/dev/zero of=/swapfile bs=128M count=8
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
cd /tmp
REGION_NAME=$(curl -s http://169.254.169.254/latest/meta-data/placement/availability-zone | sed -e 's/.$//')
dnf install -y https://s3.${REGION_NAME}.amazonaws.com/amazon-ssm-${REGION_NAME}/latest/linux_amd64/amazon-ssm-agent.rpm
systemctl enable amazon-ssm-agent
systemctl start amazon-ssm-agent
생성 후 시스템 로그를 확인해 보니 Swap이 정상적으로 활성화되었고, dnf가 OOM으로 종료되지 않고 SSM Agent 설치를 완료했습니다.
8+0 records in
8+0 records out
Setting up swapspace version 1, size = 1023.9 MiB
Adding 1048572k swap on /swapfile
...
amazon-ssm-agent.rpm
...
Transaction test succeeded
...
Amazon SSM Agent v3.3.4793.0 is running
메모리가 부족한 환경에서는 Swap을 추가하는 것만으로도 dnf가 필요한 메모리를 확보할 수 있으므로, t3.micro에서도 SSM Agent를 정상적으로 설치할 수 있었습니다.
선택지
이번 사례에서는 두 가지 방법으로 문제를 해결할 수 있었습니다.
첫 번째는 인스턴스 유형을 상향하여 물리 메모리를 늘리는 방법이고, 두 번째는 기존 인스턴스에 Swap 메모리를 추가하여 일시적인 메모리 부족을 보완하는 방법입니다.
Swap을 추가하면 메모리 부족 문제를 해결할 수 있지만, 프로덕션 환경에서는 인스턴스의 메모리를 늘리는 방법을 우선 고려하는 것을 권장합니다.
Swap은 디스크를 메모리처럼 사용하는 방식이기 때문에 RAM보다 접근 속도가 느리며, 메모리 부족이 자주 발생하는 환경에서는 디스크 I/O 증가로 인해 애플리케이션 성능이 저하될 수 있습니다. 또한 Swap에 의존하는 상태는 현재 워크로드에 비해 메모리가 부족하다는 신호이므로, 부하가 증가하면 동일한 문제가 다시 발생할 가능성도 있습니다.
반면 인스턴스 유형을 상향하면 충분한 물리 메모리를 확보할 수 있어 OOM 발생 가능성을 근본적으로 줄일 수 있으며, 애플리케이션과 운영체제가 보다 안정적으로 동작합니다.
따라서 개발·테스트 환경에서는 Swap 추가가 간단하고 효과적인 해결 방법이 될 수 있지만, 프로덕션 환경에서는 메모리를 충분히 확보할 수 있도록 인스턴스 유형을 상향하는 것을 권장합니다.
마무리
이번에는 Amazon EC2 RHEL에서 User Data를 사용해 SSM Agent를 설치하는 과정에서 OOM이 발생한 사례를 살펴봤습니다.
처음에는 SSM Agent 설치 스크립트나 다운로드 URL에 문제가 있는 것으로 생각했지만, 실제 원인은 dnf가 설치 과정에서 예상보다 많은 메모리를 사용하면서 OOM Killer에 의해 종료된 것이었습니다.
이번 사례에서는 인스턴스 메모리를 늘리거나 Swap을 추가하는 두 가지 방법으로 문제를 해결할 수 있었습니다. 다만 프로덕션 환경에서는 Swap에 의존하기보다는 워크로드에 맞는 인스턴스 유형을 선택해 충분한 메모리를 확보하는 것이 보다 안정적인 방법입니다.
RHEL 기반 EC2에서 User Data를 이용해 SSM Agent를 자동 설치하는 경우, 특히 t3.micro와 같이 메모리가 제한된 인스턴스를 사용하고 있다면 OOM 발생 가능성도 함께 고려해 보시기 바랍니다.
