블루·그린, 카나리와 롤링 배포를 모두 설명해도 서버 한 대에서 실제로 무엇을 실행할지 정해지지 않으면 도움이 되기 어렵다. 이 글은 Nginx와 PHP-FPM이 있는 단일 EC2를 기준으로 작은 서비스의 배포 단계를 하나의 런북으로 연결한다.
명령과 경로는 예시다. 실제 서비스 계정, 릴리스 경로와 프로세스 관리 방식에 맞춰 별도 환경에서 검증한다.
1. 배포 전 계약
배포 대상: commit SHA 또는 고정된 artifact
사전 검사: composer validate, audit, unit test
준비 경로: /var/www/releases/{release-id}
현재 링크: /var/www/current
헬스체크: GET /healthz
성공 조건: HTTP 200 + DB 연결 확인
롤백 대상: 직전 release-id
DB 변경: 별도 승인 및 호환성 확인latest 같은 움직이는 대상을 배포하지 않는다. 어떤 소스와 의존성이 배포됐는지 다시 찾을 수 있어야 한다.
2. CI에서 실패를 먼저 차단
composer validate --strict
composer audit --locked
composer install --no-dev --prefer-dist --no-interaction
find src public -name '*.php' -print0 | xargs -0 -n1 php -l
vendor/bin/phpunit프로젝트 구성에 없는 명령은 그대로 복사하지 않는다. 검사를 건너뛴 경우 성공으로 표시하지 말고 배포 기록에 남긴다.
3. 새 릴리스를 별도 경로에 준비
운영 중인 디렉터리에 파일을 하나씩 덮어쓰면 배포 도중 신·구 파일이 섞일 수 있다. 새 디렉터리를 완성한 다음 심볼릭 링크처럼 짧은 전환 단계로 교체한다. 공유 업로드와 비밀 설정은 릴리스 코드와 분리한다.
4. 헬스체크는 프로세스 존재보다 깊게
{
"status": "ok",
"release": "20260811-7f8a2c1",
"database": "ok"
}HTTP 200만 반환하는 정적 파일은 PHP-FPM과 DB 장애를 놓칠 수 있다. 반대로 외부 서비스 전부를 검사하면 일시 장애로 인스턴스가 반복 제거될 수 있다. 트래픽을 받을 최소 조건과 상세 진단용 체크를 분리한다.
5. 전환 후 확인
- 내부 주소와 외부 주소에서 헬스체크를 호출한다.
- 릴리스 식별자가 배포 대상과 같은지 확인한다.
- Nginx·PHP 오류 로그의 새 오류를 확인한다.
- 핵심 읽기·쓰기 기능을 제한된 테스트 계정으로 점검한다.
- 응답 시간과 오류율을 배포 전 기준과 비교한다.
6. 롤백 경계
코드는 이전 릴리스 링크로 되돌릴 수 있지만 DB 스키마는 그렇지 않을 수 있다. 먼저 nullable 컬럼 추가, 구·신 코드가 함께 읽을 수 있는 단계, 데이터 이관, 오래된 컬럼 제거 순으로 나누면 코드 롤백 가능 시간을 확보할 수 있다.
배포 실패 조건:
- healthcheck 연속 실패
- 오류율 기준 초과
- 핵심 기능 smoke test 실패
롤백:
1. current 링크를 직전 release로 전환
2. PHP-FPM opcode cache 처리
3. healthcheck와 smoke test 재실행
4. 실패 시각·로그·배포 ID 기록7. 단일 서버의 한계를 명시
이 절차는 파일 혼합과 잘못된 릴리스 위험을 줄이지만 서버 자체 장애와 배포 중 프로세스 재시작을 없애지는 못한다. 실제 무중단 요구가 생기면 두 번째 인스턴스와 로드 밸런서를 도입하고 같은 헬스체크·롤백 계약을 확장한다.
정리: 작은 서비스의 배포는 전략 이름보다 고정된 배포물, 분리된 릴리스 경로, 판정 가능한 헬스체크와 실제로 연습한 롤백을 먼저 갖춰야 한다.
댓글 0