호스트를 사용할 수 없을 때 앱 문제 해결하기

원문 보기 위키 갱신 2026.10.08

Fly.io에서 호스트(호스트 머신)에 장애가 생겼을 때 앱을 어떻게 복구하는지 알려드릴게요. 하드웨어 장애나 연결 문제로 인해 호스트 하나가 다운되면 그 위에서 돌던 앱에 영향을 줄 수 있어요. 특히 단일 머신으로 운영하는 상태 저장(stateful) 앱이라면 더 그렇습니다. 호스트 문제를 알림으로 확인하는 방법부터 머신과 볼륨을 새로 만드는 복구 절차까지 함께 살펴보아요.

출처: 문서

본문

Fly.io는 지원되는 모든 지역(region)마다 여러 호스트(물리 하드웨어)를 운영합니다. 때때로 하드웨어 장애, 연결 문제 또는 기타 요인으로 호스트를 사용할 수 없게 됩니다. 단일 호스트 문제는 지속적이거나 간헐적인 중단, 또는 전반적인 성능 저하를 일으킬 수 있으며, 이는 단일 머신에서 실행되는 앱에 더 크게 영향을 줍니다.

호스트가 1시간, 하루, 때로는 그 이상 다운될 수 있습니다.

프로덕션 앱이나 고가용성이 필요한 모든 앱에서는 단일 호스트 장애로부터 보호하기 위해 중복(redundancy) 구성을 강력히 권장합니다. 즉, 여러 머신을 실행하고, 상태 저장 앱의 경우에는 볼륨이 특정 호스트에 고정되기 때문에 여러 볼륨 간에 데이터를 복제하는 클러스터링 메커니즘(예: LiteFS와 Postgres에 내장된 것)을 갖추는 것을 뜻합니다.

**중요:** 이 문서의 복구 절차는 지속적인 문제가 있는 호스트에 단일 머신이 있는 경우 앱에 액세스할 수 있을 것이라고 보장하지 않습니다.

호스트 문제 알림

하나 이상의 앱에 영향을 주는 호스트 문제가 발생하면 대시보드의 Status 페이지에서 알림을 받게 됩니다. 호스트 문제는 보통 단일 지역의 소수 사용자에게만 영향을 주기 때문에 주요 상태 페이지에는 개별 호스트 문제를 게시하지 않습니다.

머신 1개와 볼륨이 없는 앱

머신 1개와 볼륨이 없는 앱은 보통 스케일을 줄였다가 다시 늘리거나, 앱의 새 버전을 배포하면 복구할 수 있습니다.

앱을 스케일링해 새 머신 얻기

볼륨이 없는 앱의 경우 0으로 스케일했다가 다시 올리면 새 머신을 만들 수 있습니다. 새 머신은 정상 호스트에 배치됩니다.

앱을 머신 0개로 스케일합니다:
```
fly scale count 0
```
다시 2개 이상의 머신으로 스케일합니다:
```
fly scale count 2
```

**참고:** 앱의 모든 머신을 0으로 스케일하면 머신 크기가 256MB RAM의 shared-cpu-1x로 초기화됩니다. `--vm-` 옵션 중 하나를 사용해 머신 크기를 지정하세요. 예: `fly scale count 2 --vm-size shared-cpu-4x`. 옵션에 대한 자세한 내용은 [fly scale count 문서](/flyctl/cmd/fly_scale_count)를 참조하세요.

앱을 배포해 새 머신 얻기

대부분의 경우 fly deploy로 앱의 새 버전을 배포해도 볼륨이 없는 앱은 잘 동작합니다. 새 머신이 정상 호스트에 배포되기 때문입니다.

**중요:** 호스트 중단 중에 `fly deploy`를 실행해도 일반적으로 기존 머신은 파괴되지 않습니다. 영향을 받은 호스트가 복귀하면 그 위에 있던 머신도 함께 돌아올 수 있어요. 중단 중에 배포한 경우, 이로 인해 한 머신이 이전 버전의 코드를 실행하게 될 수 있습니다. 그런 경우에는 오래된 머신이 돌아오면 파괴해야 합니다.

머신 1개와 연결된 볼륨이 있는 앱

볼륨은 물리적 호스트에 고정되므로 호스트 중단 시 볼륨에 접근할 수 없습니다. 대부분의 경우 스냅샷에서 새 볼륨으로 복원하면 앱을 다시 실행할 수 있을 것입니다.

**경고:** 스냅샷은 24시간마다 한 번씩 생성됩니다. 스냅샷이 촬영된 시점과 복원이 이루어지는 시점 사이에 저장된 모든 데이터는 포함되지 않습니다.

fly volumes list를 실행하고 볼륨 ID를 복사합니다.
fly volumes snapshots list <volume id>를 실행해 볼륨의 스냅샷을 나열하고 스냅샷 ID를 복사합니다.
fly volumes create <volume name> --snapshot-id <snapshot id> -s <volume size in GB>를 실행해 저장된 스냅샷에서 새 볼륨을 생성합니다.
fly scale count 1을 실행해 새 볼륨을 가져올 새 머신을 생성합니다.

Fly Postgres 데이터베이스 앱

여러 노드로 고가용성 Postgres 클러스터를 실행한다면, 노드 하나에 영향을 주는 호스트 문제는 문제를 일으키지 않아야 합니다. 기본적으로 각 노드를 별도의 호스트에서 실행하기 때문입니다. primary 노드가 있는 호스트가 다운되면 클러스터가 정상 노드로 페일오버합니다.

하지만 데이터베이스가 단일 머신에서 실행 중이고 페일오버할 복제본이 없다면 호스트 중단 중에는 연결할 수 없습니다. 위의 단일 볼륨 절차와 비슷하게, fly postgres create --snapshot-id <snapshot_id> --image-ref <image-version>를 사용해 가장 최근 볼륨 스냅샷에서 새 Postgres 앱을 만들 수 있습니다. 자세한 내용은 Backup, restores, & snapshots를 참조하세요.

단일 호스트 문제 시 다운타임 방지하기

Fly.io는 기본 지역에서 앱당 최소 2개의 머신을 실행할 것을 강력히 권장하며, 앱 가용성과 탄력성을 더 저렴하게 만들 수 있는 기능도 있습니다. 가능하면 기본 지역의 서로 다른 호스트에 볼륨을 배치합니다. 하나의 호스트가 다운되더라도 앱에는 정상 호스트에 머신과 볼륨이 남아 있게 됩니다.