.png){kind=small}
운영 중인 EC2의 웹 서비스(Apache 등)가 모종의 이유로 프로세스만 죽었을 때, 굳이 운영자가 접속해서 systemctl restart를 칠 필요가 있을까요?
ALB가 "어? 얘 아프네(Unhealthy)"라고 감지하면, 즉시 SSM이 출동해서 "재시작 명령어"를 날려주는 구조를 만들어 봅시다.
1. 전체 흐름도
ALB (장애 감지) → CloudWatch (알람 발생) → EventBridge (이벤트 수신) → SSM Automation (재시작 명령 실행) → EC2 (서비스 복구)
2. 사전 준비 (Prerequisites)
시작하기 전, 딱 두 가지만 먼저 확인해 주세요.
EC2 권한 확인: 대상 EC2에 연결된 IAM Role에 AmazonSSMManagedInstanceCore 정책이 반드시 포함되어 있어야 합니다. (이게 없으면 SSM이 명령을 못 내립니다.)
ALB 헬스 체크 최적화 (빠른 감지):
EC2가 포함된 **대상 그룹(Target Group)**의 상태 검사(Health checks) 탭으로 이동합니다.
간격(Interval): 5초 (최소값)
비정상 임계값(Unhealthy threshold): 2
이렇게 설정해야 장애 발생 후 약 10~15초 만에 감지가 가능합니다.
3. 구축 가이드
Step 1. 재시작 '런북' 만들기 (SSM Document)
가장 먼저, "EC2에 들어가서 무슨 명령어를 칠 것인지" 정의하는 문서를 만듭니다.
[AWS Systems Manager] 콘솔 > 좌측 메뉴의 [문서(Documents)] 클릭.
[Create document] > **[Automation]**을 선택합니다.
이름(Name): Restart-Apache-Httpd
콘텐츠(Content): 'Editor' 탭을 누르고 YAML을 선택한 뒤, 아래 코드를 붙여넣습니다. (기존 내용은 다 지우세요)
설명: 이 문서는 InstanceId를 입력받아 해당 서버에서 systemctl restart httpd를 실행합니다.
**[Create document]**를 눌러 저장합니다.
Step 2. 감시자 설정 (CloudWatch Alarm)
ALB가 "서버 죽었다!"라고 외칠 조건을 설정합니다.
[CloudWatch] 콘솔 > [경보(Alarms)] > [경보 생성] 클릭.
지표 선택: ApplicationELB > TargetGroup/LoadBalancer > UnHealthyHostCount 지표를 찾아서 선택합니다. (현재 사용 중인 타겟 그룹인지 꼭 확인하세요!)
조건 설정:
통계: 최대값(Maximum)
기간: 1분 (중요)
임계값: 1 보다 크거나 같음 (>= 1)
경보 이름: ALB-Apache-Unhealthy-Alarm 으로 짓고 생성 완료.
Step 3. 권한 위임 (IAM Role)
EventBridge가 "SSM아, 일해라!"라고 시킬 수 있는 권한(Role)이 필요합니다.
[IAM] 콘솔 > [역할(Roles)] > [역할 생성] 클릭.
신뢰할 수 있는 엔터티: 일단 'AWS 서비스' 중 아무거나(예: EC2) 선택하고 넘어갑니다. (나중에 수정할 겁니다.)
권한 정책: AmazonSSMAutomationRole 검색 후 체크하거나, 인라인 정책으로 ssm:StartAutomationExecution 권한을 줍니다.
역할 이름: EventBridge-Invoke-SSM-Role (예시) 입력 후 생성.
신뢰 관계 수정 (중요): 방금 만든 역할을 클릭 > [신뢰 관계] 탭 > **[신뢰 정책 편집]**을 누르고 아래 내용으로 교체합니다. EventBridge와 SSM 모두를 신뢰해야 합니다.
Step 4. 연결 고리 만들기 (EventBridge Rule)
이제 알람이 울리면 SSM을 실행하도록 연결합니다.
[EventBridge] 콘솔 > [규칙(Rules)] > [규칙 생성] 클릭.
이름: Auto-Restart-Apache-Rule
이벤트 패턴: '이벤트 패턴이 있는 규칙'을 선택하고, CloudWatch Alarm State Change를 선택한 뒤, 앞서 만든 ALB-Apache-Unhealthy-Alarm이 ALARM 상태가 될 때를 잡도록 설정합니다.
대상(Target) 설정: (여기가 핵심입니다!)
대상 서비스: Systems Manager Automation 선택
문서(Document): Step 1에서 만든 Restart-Apache-Httpd 선택
실행 역할(Execution Role): Step 3에서 만든 IAM Role 선택
입력 구성(Input Configure): 이 부분이 중요합니다. **[상수(Constant)]**를 선택하고, 웹 서버의 Instance ID를 직접 입력해 줍니다. (예: {"InstanceId": ["i-0123456789abcdef0"]})
4. 테스트 (Chaos Engineering)
설정이 끝났으니 실제로 장애를 내봅시다.
장애 유발: EC2 터미널에 접속해서 Apache를 강제로 끕니다.
관제: 1~2분 정도 기다리면 CloudWatch 알람 상태가 OK → ALARM으로 바뀌는 것을 볼 수 있습니다.
복구 확인:
SSM 콘솔: [자동화(Automation)] > [실행] 탭에서 방금 작업이 Success로 떴는지 확인합니다.
EC2 터미널: 다시 접속해서 프로세스 상태를 확인합니다.
마치며
이제 여러분의 웹 서버는 24시간 감시를 받으며, 프로세스가 죽더라도 1~2분 안에 스스로 부활하는 능력을 갖추게 되었습니다.
이 구조를 응용하면 디스크 용량이 찼을 때 로그를 지우거나, 메모리가 부족할 때 임시 조치를 취하는 등 다양한 자동화 운영이 가능합니다. 지금 바로 적용해 보세요!
