롤백 가이드 (Rollback Guide)

원문 보기 위키 갱신 2026.10.08

출처: 문서

본문

개요: 왜 롤백인가?

Fly.io는 여러분의 앱을 사용자와 가까운 곳에서 실행해요. 몇 초 안에 만들고 내릴 수 있는 VM 안에서 말이죠. 하지만 깨진 것을 띄우면 어떻게 될까요? 배포가 잘못되면 롤백은 쉬워요. Fly에게 이전 이미지를 재배포하라고 말하기만 하면 돼요. 특별한 rollback 명령은 없어요. 필요 없기 때문이에요. 롤백은 이미 알고 있는 것과 같은 배포 메커니즘을 사용해요.

이전에 잘 돌아가던 이미지가 무엇인지 안다면 그것을 다시 배포할 수 있어요. 이미지를 어디서 찾는지, 그리고 Fly에게 그것을 사용하라고 어떻게 말하는지만 알면 돼요. 핵심은 이거예요. 여러분이 롤백하는 것은 VM 이미지이지 데이터베이스가 아니에요. 그 잘못된 배포에서 마이그레이션을 실행했다면, 앱이나 마이그레이션 코드에서 그것을 별도로 되돌려야 해요. Fly가 여러분의 데이터를 시간 여행 시켜 주지는 않아요.

롤백하는 방법

Step 1: 배포한 것을 확인하기

Fly는 릴리스 히스토리를 유지해요. 각 릴리스가 사용한 정확한 컨테이너 이미지까지 포함해서요. 실행해 보세요:

fly releases --app myapp --image

타임스탬프와 이미지 태그가 붙은 과거 릴리스 목록이 보일 거예요:

v42   2025-08-12T16:21Z   registry.fly.io/myapp:deployment-01HXXXXX
v41   2025-08-10T09:14Z   registry.fly.io/myapp:deployment-01HYYYYY

문제가 생기기 전의 것을 고르세요.

Step 2: 그 정확한 이미지를 배포하기

v41이 괜찮았다고 해 볼게요. 그 이미지를 직접 재배포할 수 있어요:

fly deploy --image registry.fly.io/myapp:deployment-01HYYYYY

그것뿐이에요 — 재빌드도, 코드 체크아웃도 없고, 그냥 Fly에게 이전 VM 이미지를 부팅하라고 말하는 거예요. 이미지가 여전히 Fly 레지스트리에 있는 한 작동해요.

팁: `deployment-01HXXXXX` 지옥에서 벗어나기: 사람이 읽을 수 있는 태그 사용

기본 자동 생성 태그는 Machine에는 잘 맞지만 사람에게는 안 맞아요. 나중에 알아볼 수 있는 것으로 빌드에 태그를 달면 삶이 편해져요 — git 커밋 해시, 버전 번호, 아니면 그냥 before-i-broke-prod라도 말이죠.

배포할 때 --image-label을 넘겨 태그를 설정하세요:

fly deploy --image-label v1.2.3

그 명령은:

앱을 빌드하고
이미지에 v1.2.3 태그를 달고
배포해요

나중에 롤백은 이렇게 됩니다:

fly deploy --image registry.fly.io/myapp:v1.2.3

Fly가 이미지를 얼마나 오래 보관하나요?

지금으로서는 Fly가 앱 이미지를 영원히 저장하겠다고 약속하지 않아요. 이미지가 한동안 배포되지 않으면 공간을 확보하기 위해 레지스트리에서 정리(prune)될 수 있어요. "영원히 보장되는" 롤백 대상을 원한다면, 이미지를 공개 컨테이너 레지스트리(예: Docker Hub, GHCR, ECR)에 푸시하고 거기서 배포하세요. 자세한 내용은 Fly Docker Registry 사용하기를 참조하세요.

주의할 점들

Fly에서 롤백은 단순하지만 마법은 아니에요. 몇 가지 세부사항을 기억해 둘 가치가 있어요:

데이터베이스 스키마 드리프트 → 배포가 파괴적인 마이그레이션(컬럼 삭제, 테이블 이름 변경)을 실행했다면, 앱 이미지를 롤백해도 도움이 되지 않을 수 있어요. 전진과 후진 모두 안전하도록 마이그레이션을 설계하세요.
이미지 보존 → 이미지는 Fly 레지스트리에서 영원히 살지 않아요. 장기 롤백 보험을 위해 빌드를 자신의 컨테이너 레지스트리로 푸시하세요.
Config, Secrets, fly.toml → 롤백은 구성 변경을 되돌리지 않아요. 이전 이미지를 배포해도 Fly는 현재 fly.toml과 지금 설정된 모든 env var, 시크릿을 계속 사용해요. 과거 배포가 이전 구성에 의존했다면, 롤백할 때 그 설정을 수동으로 업데이트해야 해요.
자동 확장 → 잘못된 릴리스 동안 앱이 확장됐다면(예: 트래픽이 치솟아 Fly가 Machine을 더 추가), 그 추가 Machine들은 롤백 즉시 사라지지 않아요. 자동 확장이 축소하기로 결정할 때까지 남아 있어요. 이는 예상된 동작이고 롤백은 여전히 작동했어요. 다만 평소보다 Machine이 많을 뿐이죠. 메트릭 기반 자동 확장에 대해 자세히 읽어 보세요.
모니터링 → 롤백이 상황을 안정시켰는지 항상 로그, 프로브(fly logs, fly status, Grafana 메트릭)로 확인하세요. fly deploy의 성공 메시지만 믿지 마세요.
Regions → 기본적으로 롤백은 전역으로 재배포해요. 여러 region(예: iad, lhr, syd)에서 실행한다면, 모든 곳에 롤백하기 전에 한 region에서만 테스트해 볼 수 있어요. --region 플래그로 할 수 있어요:

fly deploy --image registry.fly.io/myapp:v1.2.3 --region iad

팁: 배포 전략으로 더 빠른 롤백

기본적으로 Fly는 rolling 배포를 사용해요. 새 Machine이 이전 Machine이 꺼지기 전에 올라오는 방식이죠. 업그레이드에는 안전하지만, 현재 릴리스가 나쁘다는 걸 안다면 더 빠른 전환을 원하게 돼요.

한 번에 모두 롤백:

fly deploy --image registry.fly.io/myapp:v1.2.3 --strategy immediate

이것은 이전 Machine을 멈추고 롤백 이미지를 최대한 빨리 부팅해요.

통제된 가속:

fly deploy --image registry.fly.io/myapp:v1.2.3 --max-unavailable 0.5

이것은 Machine의 절반까지 한 번에 내리게 해줘요. 신중한 rolling 배포보다 빠르면서도 완전한 중단을 피할 수 있어요.

속도가 다운타임보다 중요할 때 --strategy immediate를, 안전과 속도 사이에서 절충을 원할 때 --max-unavailable를 사용하세요.

요약

Fly에서 롤백은 기본적으로 이전 이미지를 배포하는 것뿐이에요. fly releases --image와 fly deploy --image에 손에 익으면, 잘못된 배포에서 회복하는 빠르고 예측 가능한 방법이 돼요. 그리고 이미지에 사람이 읽을 수 있는 태그를 달기 시작하면, 프로덕션이 불타고 있을 때 어떤 것을 신뢰해야 할지 기억하기 쉬워져요.

더 알아보기 (Learn more)

Fly.io 공식 문서