Nginx 블루그린 배포: WebSocket·세션·DB 변경까지 고려한 전환 절차
AI Editter
Nginx의 upstream 주소를 바꾸고 reload하면 새 요청을 다른 앱으로 보낼 수 있습니다. 그러나 기존 WebSocket 연결, 앱 메모리의 세션, DB 변경까지 자동으로 전환되는 것은 아닙니다.
블루그린 배포는 두 버전을 준비한 뒤 요청의 진입점을 바꾸는 방식입니다. 성공 기준을 설정 변경 완료가 아니라 대표 업무의 연속성으로 잡아야 합니다.
Blue와 Green이 공유하는 상태를 먼저 적는다
| 상태 | 전환 때 생길 수 있는 문제 |
|---|---|
| DB | 새 스키마를 구버전이 읽지 못함 |
| 세션 | 새 서버에서 로그인 상태가 사라짐 |
| 업로드 | 버전별 로컬 파일이 달라짐 |
| 큐·배치 | 두 버전이 같은 작업을 중복 처리 |
| WebSocket | 기존 연결은 이전 프로세스에 남음 |
정적 파일과 앱 코드만 두 벌로 만들고 나머지 상태를 확인하지 않으면 되돌리기가 어려워집니다. 배포 전에 구·신 버전의 공존 조건을 정합니다.
Green을 직접 시험한 뒤 진입점을 바꾼다
Green은 별도 포트나 주소에서 기동하고 초기화·설정·의존성 준비를 확인합니다. 외부에 불필요하게 공개하지 않은 시험 경로로 대표 조회와 쓰기 시험을 수행합니다.
Nginx 설정에는 실제 배포 구조에 맞는 upstream을 둡니다. 아래는 설명용 예시이며 TLS와 전체 서버 설정은 생략했습니다.
upstream app_active {
server 127.0.0.1:9002;
}
location / {
proxy_pass http://app_active;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
}전환할 설정 파일의 이전 버전을 보관하고 nginx -t로 문법을 확인한 뒤 관리 환경에 맞는 reload를 수행합니다. Nginx 제어 문서는 설정 재로드와 워커 처리 방식을 설명합니다.
reload와 이전 앱 종료를 같은 순간에 하지 않는다
Nginx가 새 설정을 읽었다고 기존 요청이 모두 Green으로 이동한 것은 아닙니다. 진행 중 요청과 긴 연결이 이전 경로에 남을 수 있습니다. 이전 앱의 연결·요청 상태를 확인하고 종료 유예를 둡니다.
특히 WebSocket은 일반 짧은 HTTP 요청과 수명이 다릅니다. Nginx의 WebSocket 프록시 안내에 따라 Upgrade 관련 헤더와 연결 정책을 확인하고, 애플리케이션의 재연결·재구독·메시지 중복 처리도 시험합니다.
강제 종료 제한시간을 정한다면 그때 연결이 끊길 수 있다는 운영 조건을 반영합니다. 연결을 영원히 기다리는 것과 즉시 종료하는 것 사이에서 서비스가 허용하는 동작을 정해야 합니다.
세션과 배치를 별도 시험
Blue에서 로그인한 사용자가 전환 후 Green에서 계속 작업할 수 있는지 확인합니다. 서명키·세션 저장소·쿠키 설정이 다른 경우 로그인 문제가 생길 수 있습니다. 모든 사용자가 로그아웃돼도 된다는 요구가 없다면 이를 배포 성공으로 보지 않습니다.
배치와 큐 워커는 웹 트래픽 전환과 독립적으로 실행될 수 있습니다. 두 환경을 동시에 올렸을 때 같은 예약 작업이 두 번 실행되지 않도록 활성 주체를 정합니다. 고유 작업 ID와 처리 이력으로 중복을 방지합니다.
DB 변경은 확장과 정리를 나눠 계획
새 열을 추가하고 구·신 코드가 함께 읽을 수 있도록 한 뒤 데이터를 전환하고, 구버전이 더 이상 필요 없을 때 이전 구조를 정리하는 방식 등을 검토합니다. 구버전이 사용하는 열을 먼저 삭제하면 upstream을 되돌려도 앱이 실패합니다.
마이그레이션을 별도 실행한다면 두 앱이 시작하면서 동시에 같은 변경을 수행하지 않는지 확인합니다. 데이터 변환의 재실행 가능성과 실패 후 재개 기준도 필요합니다.
전환 시험과 롤백 판단
| 시험 | 통과 기준 |
|---|---|
| 연속 조회 | 전환 중 오류·긴 지연이 기준 이내 |
| 로그인 유지 | 승인된 세션 동작 |
| 긴 요청·업로드 | 누락·부분 저장 없음 |
| WebSocket | 정한 재연결과 메시지 처리 |
| 쓰기 요청 | 중복·누락 없음 |
| 이전 코드 복귀 | 현재 DB와 호환 |
Green에 업무 쓰기가 발생한 뒤 Blue로 돌아간다면 데이터 호환과 새로운 거래를 함께 확인합니다. 주소만 원복하면 되겠다는 계획은 데이터가 변하지 않는 경우에만 제한적으로 성립합니다.
롤백이 필요하면 새 요청 경로를 되돌리고 Green의 진행 중 작업을 어떻게 마칠지 결정합니다. 두 환경의 로그와 배포 시각, 요청 ID를 보관해 전환 중 거래를 대조합니다.
이전 환경을 제거할 시점
정상 피크와 예약 작업까지 확인한 뒤 Blue를 정리합니다. 파일·설정·이미지 버전과 복구 절차는 별도 보관합니다. 이전 환경이 남아 있는 동안에도 비용과 보안 업데이트 책임이 있으므로 보관 기한을 정합니다.
다음 배포에서 재사용할 것은 설정 교체 명령만이 아닙니다. 준비 상태, 연결 종료, 상태 공유, 데이터 호환성, 전환 시험을 함께 기록한 절차가 있어야 같은 결과를 반복할 수 있습니다.