앱 가용성과 복원력 (App Availability and Resiliency)
복원력 있는 앱은 하드웨어 장애나 장애 상황 같은 사건에 잘 견디는 앱을 말해요. 모니터링과 확장이 뒷받침하는 중복(redundancy)이 앱을 더 복원력 있게 만드는 방법 중 하나이며, 우리는 이를 더 쉽게 만들어 주는 내장 기능 몇 가지를 제공해요. 이 문서에서는 앱이 스스로 처리해야 할 부분과 Fly.io가 제공하는 복원력 기능에 대해 알아봐요.
출처: 문서
본문
앱이 처리해야 할 것
먼저 앱이 직접 처리해야 할 일이 무엇인지 이해하는 게 중요해요.
Fly Proxy가 기본적으로 로드 밸런싱을 하기 때문에, 앱이 다음을 어떻게 처리하는지 고민해야 해요:
- 세션 저장 - 사용자의 세션이 다른 서버로 이동할 때 로그인이 유지되도록 하는 것
- 영구 파일 스토리지와 복제 - 다음 문단에서 설명할 내용이에요
데이터베이스의 경우, 사용 중인 데이터베이스에 대한 특정 권장 사항을 따라야 해요. 여기에는 복제와 장애 조치를 위한 클러스터 설정 방법이 포함돼요.
관리되지 않는 데이터베이스 앱인 Fly Postgres를 배포한다면 백업, 복구, 복제, 확장을 직접 관리해야 해요. Fly Postgres의 고가용성에 대한 자세한 내용은 고가용성 & 글로벌 복제를 참고하세요.
앱에서 Fly Volumes를 사용한다면, 앱이 복제와 백업을 구현해야 해요. 볼륨은 단일 디스크 배열에 존재하며 Machine이 직접 마운트하는 블록 디바이스예요. 여기에는 마법이 없어요. 볼륨 간 내장 복제도 없어요. 대부분의 데이터베이스처럼 데이터 복제 기능을 제공하는 클러스터링 메커니즘이 앱에 있다면, 이를 활용해서 여러 인스턴스를 볼륨과 함께 실행하는 것을 권장해요. 가능할 때 하드웨어 장애를 줄이기 위해 앱의 볼륨을 리전 내 서로 다른 하드웨어 존에 배치해요.
이제 재해 복구와 대비에 대한 이야기입니다. 데이터 백업을 보유하고 필요할 때 해당 데이터를 복구하는 방법을 이해해야 해요. Fly.io는 볼륨의 일일 스냅샷을 기본적으로 5일 동안 저장해요. 이 일일 스냅샷 중 하나에서 볼륨 데이터를 복원할 수 있어요. 더 자주 백업해야 하는 경우라면 요구되는 일정에 맞춰 볼륨을 백업하는 도구와 프로세스를 직접 구축해야 해요.
앱 복원력을 위한 Fly.io 기능
Fly 플랫폼에는 장애나 하드웨어 장애 발생 시 앱을 더 복원력 있게 만들어 주는 기능이 있어요.
중복과 가용성을 위한 기능은 다음과 같아요:
이 기능들은 `fly.toml` 파일의 앱 구성(프로세스 그룹 포함)을 요구하거나 그것에 의존해요. 모든 Fly 앱은 최소한 하나의 프로세스 그룹을 가져요. `fly.toml`에 추가 프로세스 그룹이 정의되지 않은 앱도 기본적으로 `app` 프로세스 그룹을 사용해요. [앱 구성에 대해 자세히 알아보기](/reference/configuration).첫 배포 시 기본 중복
첫 배포 시와 머신을 0대로 축소한 후 다시 배포할 때 기본적으로 중복을 얻게 돼요. 이 기능은 생각할 필요 없이 권장 설정으로 배포할 수 있게 도와줘요. 다음 섹션의 기본값이 마음에 들지 않는다면 앱과 프로세스를 원하는 방식으로 직접 구성할 수도 있어요. 복원력 있는 앱과 여러 Machine, Machine CPU와 RAM 확장, Machine 수 확장에 대해 자세히 알아보세요.
앱 구성에 따라 Fly Launch(fly launch 또는 fly deploy 명령)가 수행하는 작업은 다음과 같아요:
- 서비스가 있는 프로세스 그룹에 대해 두 개의 Machine을 만들고 시작하며, 자동 시작/정지를 true로, 최소 실행 머신 수를 0으로 설정해요
- 서비스가 없는 프로세스 그룹에 대해 하나의 Machine을 만들고 시작하며, 하나의 정지된 대기 Machine(standby Machine)을 만들어요
- 프로세스 그룹에 볼륨이 마운트되어 있으면 Machine 하나만 만들고 시작해요. 볼륨 간 내장 복제가 없기 때문이에요
서비스가 있는 프로세스 그룹의 두 Machine
복원력을 높이는 가장 기본적인 방법은 프로세스 그룹당 두 개 이상의 Machine을 만드는 것이며, fly launch와 fly deploy 명령은 서비스가 있는 프로세스 그룹에 대해 기본적으로 이렇게 해요. 서비스가 있는 프로세스 그룹은 외부 인터넷 또는 사설(Flycast) 네트워크에 매핑되어 있어서 Fly Proxy가 그 연결과 운영을 관리할 수 있어요.
프로세스 그룹에 서비스가 정의되어 있으면 다음과 같은 경우 두 개의 Machine이 자동으로 생성되고 시작돼요:
fly launch또는fly deploy를 사용해 앱을 처음 배포할 때,- 0으로 축소한 후
fly deploy로 앱을 다시 배포할 때, fly.toml파일에 서비스가 있는 새 프로세스 그룹을 추가한 후fly deploy를 실행할 때
서비스가 없는 프로세스 그룹의 대기 Machine
대기 Machine(Standby Machine)은 서비스가 정의되지 않은 프로세스 그룹을 위한 간편한 중복을 제공해요. 서비스가 없는 프로세스 그룹은 외부 인터넷 또는 사설(Flycast) 네트워크에 매핑이 없어서 Fly Proxy가 그 연결과 운영을 관리할 수 없어요.
대기 Machine은 기본적으로 실행 중인 Machine과 짝을 이루어 그것을 지켜보는 정지된 Machine이에요. 대기 Machine은 짝이 된 Machine을 사용할 수 없게 됐을 때만 시작돼요.
프로세스 그룹에 서비스가 정의되어 있지 않으면 다음과 같은 경우 실행 중인 Machine과 함께 대기 Machine이 자동으로 생성돼요:
fly launch또는fly deploy를 사용해 앱을 처음 배포할 때,- 0으로 축소한 후
fly deploy로 앱을 다시 배포할 때, - fly.toml에 새 프로세스 그룹을 추가한 후
fly deploy를 실행할 때
대기 Machine은 필요해지기 전까지 리소스를 소비하거나 시작되지 않아요.
대기 Machine 제거하기
대기 Machine을 제거하려면 fly status를 실행하고 프로세스 그룹 이름 옆에 † 기호가 표시된 Machine의 ID를 복사하세요. 예를 들어:
PROCESS ID VERSION REGION STATE ROLE CHECKS LAST UPDATED
task† 784e469a443e38 43 yul stopped 2024-08-06T20:48:10Z
그런 다음 fly machine destroy <machine id>로 대기 Machine을 파괴하세요.
대기 Machine을 파괴해도 fly scale count로 확장하거나 축소할 때 다시 생성되지는 않아요.
fly.toml에서 이전에 서비스가 없던 프로세스 그룹에 서비스를 추가하면, 다음 배포 시 대기 Machine의 대기 지정이 제거돼요.
대기 Machine 만들기
0으로 축소한 후 fly deploy를 실행하면 대기 Machine을 다시 만들 수 있어요. 그러면 Machine 하나와 대기 Machine 하나가 다시 생성돼요.
더 낮은 수준에서는 --standby-for 옵션과 함께 fly machines update 명령을 사용해서 기존 Machine 두 대로 대기 구성을 만들 수도 있어요.
배포 시 중복 끄기
작거나 변동이 큰 워크로드를 가진 앱이라면 Machine을 계속 실행해 두고 싶지 않을 수도 있어요. 자동 시작/정지 기능은 Machine에 기본적으로 활성화되어 있으며, 리소스를 낭비하지 않고 최소 두 대의 Machine을 실행할 수 있게 해줘요.
그래도 fly launch나 fly deploy가 두 대의 Machine을 만들지 않게 하려면 --ha 옵션으로 이 기능을 끌 수 있어요.
새 앱에 Machine 한 대 만들기:
fly launch --ha=false
첫 배포 시 또는 앱을 0대로 축소했을 때 Machine 한 대 만들기:
fly deploy --ha=false
앱을 Machine 한 대로 축소하기:
fly scale count 1
프로세스가 둘 이상인 앱은 프로세스 그룹을 수평으로 확장하기를 참고하세요.
Machine 자동 시작 및 정지
자동 시작/정지는 서비스가 정의된 프로세스 그룹에서 동작해요. 이 기능을 사용하면 필요할 때만 실행되는 여러 Machine을 가질 수 있어요.
Fly Proxy는 들어오는 요청에 따라 기존 Machine을 시작하고 멈출 수 있어요. 그래서 앱이 여분의 Machine을 계속 실행하지 않으면서도 수요 폭증을 처리할 수 있어요. 그리고 앱이 주요 리전에서 한 대 이상의 Machine을 항상 실행해야 한다면, 유지할 최소 머신 수를 설정할 수 있어요. Fly Proxy는 또한 로드 밸런싱을 담당해요.
fly launch 명령으로 만든 새 앱의 기본 설정: Fly Machine 자동 시작 및 자동 정지, 최소 실행 머신 수 0.
기존 앱 일부(fly.toml에 이 설정이 없는 모든 앱 포함)의 기본 설정: Machine 자동 시작은 하되 자동 정지는 안 함.
Fly Proxy의 autostop/autostart가 어떻게 동작하는지와 그것을 구성하는 방법에 대해 자세히 알아보세요.
헬스 체크 기반 라우팅
Fly Proxy는 헬스 체크에 실패하는 Machine에서 네트워크 연결을 라우팅하지 않아요.
헬스 체크 기반 라우팅은 서비스가 정의된 프로세스 그룹에서 동작하며, 앱의 fly.toml 파일에 있는 services.tcp_checks 또는 services.http_checks 구성에 기반해요.
어떤 Machine에 대해 구성된 헬스 체크가 실패하면 프록시는 해당 Machine으로 네트워크 연결을 라우팅하지 않아요. 대신 프록시는 연결을 정상(healthy) Machine으로 라우팅해요. 정상 Machine이 없다면 연결은 Machine이 정상이 될 때까지 대기(block)하게 돼요.
헬스 체크 기반 라우팅은 fly.toml의 `checks` 섹션에 정의된 최상위 헬스 체크에는 동작하지 않아요. 최상위 체크는 특정 서비스에 적용되지 않기 때문이에요.