Strapi 도입 배경 및 운영 전략
사내에서 비개발자가 직접 게시글을 작성하고 서비스에 배포할 수 있는 기능을 구현할 필요가 있었다.
이를 위해 어드민을 직접 개발하는 대신, Strapi라는 오픈소스를 도입하기로 결정했다.
Strapi는 Node.js 기반의 Headless CMS로, 기본적인 설치와 몇 가지 설정만으로 관리 대시보드와 백엔드 API를 자동으로 구축할 수 있는 강력한 오픈소스 솔루션이다.
배포 및 운영 아키텍처
서비스가 극초기 단계인 만큼, 운영 규모와 배포 빈도를 고려하여 가장 가볍고
유지보수가 용이한 배포 방식을 설계하는 데 중점을 두었다.
운영 데이터베이스: RDS Aurora MySQL과 연동하여 안정적인 데이터 관리 보장
배포 방식: 가볍고 효율적인 인프라 운영을 위해 AWS 기반으로 구성
Route 53: 도메인 네임 시스템(DNS) 관리
Application Load Balancer (ALB): 트래픽 분산 및 SSL/TLS 지원
EC2 (Strapi 배포): PM2를 이용한 프로세스 관리 및 자동 복구 설정
PM2를 활용한 자동화: Strapi 프로세스 상태 모니터링 및 장애 발생 시 자동 재시작
1.아키텍처 다이어그램
┌──────────────────────────┐
│ User Request │
│ (Browser) │
└──────────┬───────────────┘
│
▼
┌──────────────────────────┐
│ Route 53 (DNS) │
│ - https://strapi.xxxx.xx/ │
└──────────┬───────────────┘
│
▼
┌──────────────────────────┐
│ Application Load Balancer (ALB) │
│ - HTTP 80 / HTTPS 443 │
│ - Target Group (EC2 연결) │
└──────────┬───────────────┘
│
▼
┌──────────────────────────┐
│ EC2 Instance │
│ - Strapi (Node.js) │
│ - Port: 1337 │
└──────────────────────────┘
2. 구성 요소 설명
- 3.1 Route 53 (DNS)
- AWS의 DNS 서비스로, strapi.xxx.xx/을 ALB의 DNS 주소에 매핑
- 트래픽이 최적의 경로로 ALB에 전달되도록 설정 가능
- 라우팅 정책: 단순 라우팅 또는 지연 시간 기반 라우팅 가능
- 3.2 Application Load Balancer (ALB)
-
역할: 사용자 요청을 EC2 인스턴스에 분산
-
포트: HTTP(80) / HTTPS(443) 리스너 설정
-
Target Group: EC2를 대상으로 설정하여 트래픽 전달
✅ ALB의 주요 기능
-
로드 밸런싱: 다수의 EC2 인스턴스를 관리할 경우 자동 분산
-
SSL/TLS 적용: AWS Certificate Manager(ACM)와 연동하여 HTTPS 지원
-
Auto Scaling 지원: 트래픽 증가 시 EC2 인스턴스 추가 가능
-
- 3.3 EC2 (Strapi)
- Strapi는 EC2에서 실행
- PM2를 사용하여 프로세스 상태 관리 및 자동 재시작 설정
- 기본적으로 1337번 포트에서 실행되며, ALB를 통해 접근 가능
인바운드 규칙>1337 포트 가 alb에서 요청 받을 수 있도록 허용
Strapi 유지보수
📌 주요 목표
- 배포 방법
- Strapi 상태 확인 방법
- Strapi 프로세스의 자동 실행 및 복구
- 로그 관리 및 모니터링 방안
- 배포 전략 및 운영 가이드
배포방법
- EC2 내부에서 직접 코드 업데이트 & PM2 재시작
-
비주기적 사용, ec2내부에서 pm2로 간단하게 유지보수 가능
-
사용해보면서 추후 Auto Recovery 등 고도화 필요할 경우 추가 대응
-
2. Strapi 서비스 실행 및 상태 확인
2.1 Strapi 실행 방식
Strapi는 EC2에서 PM2 프로세스 관리 도구를 사용하여 실행됨
Strapi가 실행 중인지 확인하려면 다음 명령어를 사용
pm2 status
출력 예시:
bash
복사편집
┌──────┬────────┬──────┬──────┬───────────┬────────┬─────────┬───────────┐
│ id │ name │ mode │ status │ cpu │ memory │ uptime │ restart │
├──────┼────────┼──────┼──────┼───────────┼────────┼─────────┼───────────┤
│ 0 │ strapi │ fork │ online │ 0.1% │ 25.4mb │ 1h │ 0 │
└──────┴────────┴──────┴──────┴───────────┴────────┴─────────┴───────────┘
2.2 Strapi 자동 실행 설정 (PM2 사용)
EC2가 재부팅되거나 Strapi 프로세스가 중단될 경우 자동으로 다시 실행하도록 PM2 영구 실행을 설정
-
Strapi를 PM2로 실행
pm2 start npm --name "strapi" -- start -
서버 재부팅 시 자동 실행 설정
pm2 startup명령어 실행 후 출력되는 명령을 복사하여 실행
-
PM2 상태 저장 (영구화)
pm2 save
2.3 Strapi 상태 확인
다음 명령어를 활용하여 Strapi 상태를 확인
curl -I http://localhost:1337/admin
출력 예시:
HTTP/1.1 200
200 OK: 정상 실행 중500,404,503: 서비스 장애 가능성 있음
3. 장애 발생 시 대응 방안
3.1 Strapi 프로세스가 중단되었을 경우
아래 명령어를 실행하여 즉시 복구 가능
pm2 restart strapi
또는 실행되지 않은 경우:
pm2 start npm --name "strapi" -- start
3.2 로그 분석 및 원인 파악
Strapi의 실행 로그는 PM2 로그를 통해 확인
pm2 logs strapi
- 오류 발생 시 로그 파일에서 원인을 분석
- 특정 에러 메시지가 반복될 경우 알림 설정 고려
5. 배포 및 유지보수 전략
5.1 배포 프로세스
- ec2 내부에서 직접 pm2로 배포
5.2 업데이트 및 패치 관리
- Strapi 버전 업그레이드 전 백업 필수( 소스코드, DB)
- 필요시
npm update를 실행하여 최신 버전 유지
결론
이번 설계에서는 운영의 단순성과 유지보수 편의성을 최우선으로 고려했다.
Kubernetes나 복잡한 CI/CD 파이프라인을 도입하지 않고,
EC2와 PM2 기반의 최소한의 인프라 구성을 통해 빠르게 배포하는것에 중점을 두었다.
향후 서비스가 성장함에 따라 배포 자동화 및 확장성 확보를 위한 추가적인 개선을 고려할 예정이다.
