파이썬 Flask 무중단 배포 가이드 드레인 커넥션 유지 롤링 업데이트로 서비스 중단 없이 운영하기

🚦 무중단 배포의 개념과 목표

무중단 배포란 서비스가 운영되는 동안 사용자가 요청을 보내더라도 끊김 없이 새로운 버전의 애플리케이션을 배포하는 방식을 말합니다.
특히 Flask 같은 웹 프레임워크는 서버가 재시작되면 기존 연결이 끊기기 때문에 이를 보완하지 않으면 배포 순간마다 오류가 발생할 수 있습니다.
이 때문에 요청을 안전하게 처리하면서 배포를 완료하는 구조가 필요합니다.

무중단 배포의 핵심 목표는 크게 세 가지로 요약할 수 있습니다.
첫째, 사용자 경험의 연속성입니다.
서비스가 업데이트되는 순간에도 페이지 로딩이나 API 호출이 중단 없이 이어져야 합니다.
둘째, 운영 안정성 확보입니다.
장애 상황에서도 배포 과정을 제어할 수 있어야 하고, 문제가 생기면 즉시 롤백할 수 있어야 합니다.
셋째, 배포 자동화와 반복 가능성입니다.
수작업이 아닌 표준화된 절차로 실행할 수 있어야 예측 가능한 운영이 가능해집니다.

📌 무중단 배포가 필요한 이유

일반적인 재배포 과정에서는 서버가 잠시 내려갔다가 올라오면서 연결이 끊깁니다.
사용자 입장에서는 요청 실패, 페이지 에러, 결제 중단 등 치명적인 문제로 이어질 수 있습니다.
특히 쇼핑몰, 금융 서비스, 예약 시스템처럼 거래가 중요한 서비스는 잠깐의 다운타임조차 큰 손실을 초래합니다.

무중단 배포를 적용하면 기존 인스턴스가 정상적으로 요청을 처리하는 동안 새로운 인스턴스가 준비됩니다.
로드밸런서는 점진적으로 트래픽을 새로운 인스턴스로 분산시키고, 기존 인스턴스의 요청이 모두 종료된 시점에서 안전하게 제거됩니다.
이 과정을 통해 사용자는 배포 사실조차 눈치채지 못하게 됩니다.

• 🚦사용자 요청이 끊기지 않는 환경을 유지해야 합니다
• 🛡️안정적인 롤백 절차가 준비되어야 합니다
• ⚙️자동화된 배포 파이프라인이 있어야 합니다

💬 무중단 배포는 고급 기술이 아니라, 서비스 품질을 유지하기 위한 기본 운영 전략으로 자리 잡아야 합니다.

🛢️ 드레인 모드 설정과 요청 처리

드레인(Drain)은 인스턴스를 즉시 종료하지 않고, 새로운 요청 유입은 차단하되 진행 중 요청은 끝까지 처리하도록 만드는 운영 절차입니다.
핵심은 로드밸런서, 리버스 프록시, 애플리케이션 서버의 상태 신호를 일치시키는 것입니다.
읽기 전용 트래픽이든 긴 스트리밍이든, 드레인 윈도우 동안은 연결이 끊기지 않아야 하며 타임아웃과 Keep-Alive 정책이 이를 뒷받침해야 합니다.

🧭 드레인 플로우의 표준 단계

🔌 Nginx와 Gunicorn에서의 드레인 구현

Flask는 보통 Nginx(프록시) + Gunicorn(WSGI) 조합으로 운영합니다.
드레인 신호를 받으면 Nginx는 새 연결을 최소화하고, Gunicorn은 워커가 처리 중인 요청을 마치는 동안 정상 종료를 진행합니다.
이때 proxy_read_timeout, keepalive_timeout, graceful_timeout이 서로 충돌하지 않도록 맞춰야 합니다.

# nginx.conf (예시)
http {
    keepalive_timeout 65s;            # 클라이언트 Keep-Alive
    send_timeout 60s;

    upstream flask_app {
        server 127.0.0.1:8000;
        # 드레인 대상은 weight 0 또는 일시적으로 down
        # server 127.0.0.1:8001 weight=0; 
    }

    server {
        location / {
            proxy_pass http://flask_app;
            proxy_http_version 1.1;
            proxy_set_header Connection "";
            proxy_read_timeout 60s;   # Gunicorn timeout과 호환되게 설정
        }
    }
}
# systemd로 드레인 시, nginx -s quit 로 그레이스풀 종료

# gunicorn.conf.py (예시)
workers = 4
timeout = 60                 # 워커가 응답 없을 때 강제 종료 전 대기
graceful_timeout = 30        # 드레인 중 현재 요청 마무리 허용 시간
keepalive = 5                # 프록시와의 Keep-Alive
preload_app = True

def on_exit(server):
    # 종료 후 메트릭 플러시 등
    pass

🧪 헬스체크와 드레인 신호 연동

로드밸런서는 인스턴스를 드레인 상태로 전환하면 헬스체크는 실패하도록, 혹은 트래픽 라우팅에서 제외되도록 설계합니다.
Flask 앱은 /health 같은 엔드포인트에서 readiness와 liveness를 분리해 노출하는 것이 좋습니다.
드레인 시에는 readiness만 실패로 응답해 새 요청 유입을 차단하고, liveness는 성공으로 유지해 진행 중 요청은 정상 처리합니다.

📌 Flask 예시 Readiness 플래그

from flask import Flask, jsonify
app = Flask(__name__)

is_ready = True  # 드레인 시작 시 False로 전환

@app.get("/health/ready")
def ready():
    return ("ok", 200) if is_ready else ("draining", 503)

@app.get("/health/live")
def live():
    return ("ok", 200)

# 드레인 엔드포인트 (배포 파이프라인에서 호출)
@app.post("/ops/drain")
def drain():
    global is_ready
    is_ready = False
    return jsonify(status="draining")

☸️ 컨테이너·오케스트레이션 환경의 드레인

Kubernetes에서는 readinessProbe가 실패하면 새 요청이 들어오지 않습니다.
Pod 종료 시 preStop 훅에서 드레인 플래그를 내리고, terminationGracePeriodSeconds 동안 그레이스풀 종료를 보장합니다.
동시에 PodDisruptionBudget으로 최소 가용 수를 강제해 과도한 동시 드레인을 방지합니다.

# Deployment 일부 (예시)
readinessProbe:
  httpGet: { path: /health/ready, port: 8000 }
  periodSeconds: 5
preStop:
  exec:
    command: ["curl", "-s", "-X", "POST", "http://127.0.0.1:8000/ops/drain"]
terminationGracePeriodSeconds: 60

• 🛢️로드밸런서 등록 해제 후 지연 시간을 둔다
• 🔗Keep-Alive와 타임아웃을 상호 호환되게 맞춘다
• 🧪readiness/liveness 분리, 드레인 시 readiness만 실패 처리
• 🔐운영용 드레인 엔드포인트는 인증으로 보호

🔗 커넥션 유지 전략 Keep-Alive와 타임아웃

무중단 배포에서 드레인과 함께 반드시 고려해야 하는 요소가 바로 커넥션 유지입니다.
클라이언트와 서버, 프록시와 WSGI 워커 간의 연결이 중간에 잘못 끊기면 여전히 요청 실패가 발생할 수 있기 때문입니다.
이때 Keep-Alive와 타임아웃 설정이 핵심 역할을 합니다.

⚖️ Keep-Alive와 성능 균형

Keep-Alive는 동일한 연결을 재사용하여 TCP 핸드셰이크 비용을 줄이고 지연을 완화합니다.
하지만 무한정 길게 유지하면 드레인 시 종료가 지연될 수 있습니다.
따라서 Flask 운영에서는 보통 30~75초 사이의 적절한 Keep-Alive 시간을 권장합니다.

💬 짧으면 연결 효율이 떨어지고, 길면 배포 지연이 길어집니다. 서비스 패턴에 맞는 중간값을 찾는 것이 핵심입니다.

⏳ 타임아웃 설정 원칙

타임아웃은 프록시 ≥ WSGI 서버 ≥ 애플리케이션 순으로 점차 짧아야 안전합니다.
예를 들어 Flask가 처리할 수 있는 최대 요청 시간이 50초라면, Gunicorn timeout은 60초, Nginx proxy_read_timeout은 65초 정도로 설정해야 합니다.
이렇게 하면 중간 레이어에서 잘못된 조기 종료가 발생하지 않습니다.

# Nginx와 Gunicorn 타임아웃 예시
# nginx.conf
proxy_read_timeout 65s;
keepalive_timeout 60s;

# gunicorn.conf.py
timeout = 60
graceful_timeout = 30
keepalive = 5

📡 커넥션 풀 관리

내부 서비스 간 통신이나 DB 연결 역시 커넥션 풀로 관리해야 합니다.
Flask의 SQLAlchemy 같은 ORM은 풀 크기와 연결 만료 시간을 명시적으로 지정하는 것이 좋습니다.
풀에 오래된 연결이 남아 있으면 배포 후에도 장애가 이어질 수 있습니다.

📌 SQLAlchemy 예시

from sqlalchemy import create_engine

engine = create_engine(
    "postgresql://user:pass@localhost/db",
    pool_size=10,            # 최대 풀 크기
    max_overflow=5,          # 초과 허용 연결
    pool_timeout=30,         # 대기 시간
    pool_recycle=1800        # 만료 주기 (초)
)

• 🔗Keep-Alive는 30~75초 범위에서 조정
• ⏳프록시 ≥ WSGI ≥ 앱 순으로 타임아웃 계층 설정
• 📡DB 커넥션 풀은 만료 주기와 풀 크기 명시

♻️ 롤링 업데이트 설계와 배포 순서

롤링 업데이트는 여러 개의 인스턴스를 운영하는 환경에서 순차적으로 새로운 버전을 배포하는 방식입니다.
한 번에 모든 서버를 교체하지 않고, 일부만 교체하면서 전체 서비스는 계속 유지됩니다.
Flask 애플리케이션도 로드밸런서 뒤에서 여러 인스턴스로 운영된다면 이 방식을 적용할 수 있습니다.

🌀 롤링 업데이트의 핵심 원칙

롤링 업데이트가 안정적으로 동작하려면 몇 가지 원칙을 지켜야 합니다.
첫째, 드레인 모드와 결합해야 합니다.
기존 인스턴스를 종료하기 전에 새로운 요청 유입을 막고, 진행 중 요청을 모두 처리해야 합니다.
둘째, 동시 교체 수를 제한해야 합니다.
한 번에 여러 인스턴스를 교체하면 가용성이 떨어질 수 있습니다.
셋째, 헬스체크를 통해 새 인스턴스가 정상적으로 기동되었는지 확인해야 합니다.

📋 롤링 업데이트 배포 순서

1. 로드밸런서에서 특정 인스턴스를 드레인 상태로 전환합니다.
2. 해당 인스턴스의 요청이 모두 종료될 때까지 대기합니다.
3. 애플리케이션을 새 버전으로 교체하고 서버를 재시작합니다.
4. 헬스체크를 통과하면 다시 로드밸런서에 등록합니다.
5. 다음 인스턴스로 넘어가 같은 절차를 반복합니다.

# AWS ECS 배포 전략 예시
deploymentConfiguration:
  maximumPercent: 200   # 최대 동시 실행 가능 퍼센트
  minimumHealthyPercent: 50  # 최소 가용 인스턴스 비율

🛠️ 배포 전략의 변형

롤링 업데이트는 안정적이지만 경우에 따라 다른 전략을 선택할 수도 있습니다.
예를 들어 블루-그린 배포는 두 개의 환경을 두고 트래픽을 전환하는 방식으로, 배포 속도는 빠르지만 리소스를 더 많이 요구합니다.
반면 카나리 배포는 일부 트래픽만 새 버전으로 보내어 안정성을 검증할 수 있습니다.
Flask 서비스 규모와 중요도에 따라 전략을 조합해 사용하는 것이 좋습니다.

• ♻️드레인 모드와 롤링 업데이트를 반드시 결합
• 🧪헬스체크를 통과한 인스턴스만 로드밸런서에 등록
• 🔍배포 중 에러율, 지연 시간, 자원 사용량 모니터링

🧰 Flask 환경별 구현 Nginx Gunicorn Kubernetes

Flask 애플리케이션을 운영 환경에 맞게 배포하려면 웹 서버, WSGI 서버, 오케스트레이션 플랫폼 각각에 적합한 무중단 배포 전략을 적용해야 합니다.
구성 요소들이 따로 노는 것이 아니라, Nginx, Gunicorn, Kubernetes가 한 팀처럼 움직여야 안정적인 결과를 얻을 수 있습니다.

🌐 Nginx 설정 포인트

Nginx는 외부 요청을 받아 Gunicorn에 전달하는 리버스 프록시 역할을 합니다.
무중단 배포를 위해서는 다음과 같은 설정이 필요합니다.

• 🔗keepalive_timeout과 proxy_read_timeout을 Gunicorn과 일치
• 🛢️인스턴스 드레인 시 server weight=0으로 설정
• 🧪헬스체크 URL을 설정해 비정상 인스턴스는 자동 제외

⚙️ Gunicorn 운영 팁

Gunicorn은 Flask 앱을 실행하는 WSGI 서버입니다.
무중단 배포를 위해서는 그레이스풀 셧다운과 워커 관리가 필수입니다.

# Gunicorn 실행 예시
gunicorn -w 4 -b 0.0.0.0:8000 \
  --timeout 60 \
  --graceful-timeout 30 \
  --keep-alive 5 \
  myapp:app

운영 환경에서는 systemd를 사용해 Gunicorn을 실행하면서 ExecStop 명령으로 SIGTERM을 보내 정상 종료를 유도해야 합니다.

☸️ Kubernetes 배포 전략

Kubernetes는 무중단 배포를 자동화할 수 있는 대표적인 환경입니다.
롤링 업데이트 전략을 지원하고, readinessProbe와 livenessProbe를 통해 드레인을 쉽게 구현할 수 있습니다.

# Deployment 일부 예시
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxUnavailable: 1
    maxSurge: 1

readinessProbe:
  httpGet:
    path: /health/ready
    port: 8000
  initialDelaySeconds: 5
  periodSeconds: 10

livenessProbe:
  httpGet:
    path: /health/live
    port: 8000
  initialDelaySeconds: 15
  periodSeconds: 20

📊 통합 모니터링 포인트

환경별 설정이 달라도 결국 무중단 배포는 모니터링 없이는 완성되지 않습니다.
로그와 메트릭을 통해 요청 지연, 에러율, CPU·메모리 사용량을 추적해야 합니다.
특히 배포 직후 5분은 집중 관찰 구간으로 두는 것이 좋습니다.

• 🌐Nginx 타임아웃은 Gunicorn과 일치
• ⚙️Gunicorn은 SIGTERM 기반 그레이스풀 셧다운
• ☸️Kubernetes 롤링 업데이트 전략 활용
• 📊에러율, 지연 시간, 자원 사용률 모니터링

❓ 자주 묻는 질문 FAQ