Fly.io에서 앱 미세 조정하기
이 가이드는 Fly.io에서 실행되는 앱을 미세 조정(fine-tune)하고 최적화할 때 참고할 지침을 담고 있어요. Fly.io는 초당 수천 개의 요청이나 연결을 처리할 수 있고, 언제든지 수십만 개를 유지할 수 있다고 가정해도 안전해요. 하지만 실제로 최적화하려면 메트릭·라우팅·설정·분산 시스템 등 여러 측면을 함께 점검해야 해요.
출처: 문서
본문
Fly.io가 초당 수천 개의 요청 또는 연결을 지원하고, 어느 순간에도 수십만 개를 유지할 수 있다고 가정하는 것이 안전해요. 클라이언트가 여러 지리적 위치에서 연결할 때는 더욱 그렇죠.
이제 여러분은 다음 지침을 사용해 Fly.io에서 실행할 앱과 구성(configuration)을 미세 조정하고 최적화하기 위한 데이터를 모을 수 있어요.
Fly.io 메트릭
Fly Proxy, 앱, Fly Machines에 대한 메트릭에 접근하는 방법은 다양해요. Fly Metrics에서 자세히 알아보아요.
- 엣지(Edge) HTTP 응답 시간은 첫 번째 HTTP 응답 헤더로 응답하는 데 걸리는 총 시간이에요.
- 앱 HTTP 응답 시간도 마찬가지지만, 라우팅·로드 밸런싱·재시도 등의 오버헤드는 빼고 앱의 응답 시간만 고려해요.
CPU와 메모리 리소스 사용량은 흥미롭지만, 벤치마크의 다른 모든 요소가 제대로 되어 있지 않으면 원인이 되기보다는 오히려 곁다리인 경우가 많아요. 과도한 CPU와 메모리 사용량의 문제는 대부분 애플리케이션 로직에서 오는 경우가 많아요.
라우팅
어떤 Fly.io 리전(region)에 연결되고 있는지 확인해 보아요.
도달하는 리전은 여러분에게 가장 빠른 리전이어야 해요. 지리적으로 가장 가까운 곳이 아닐 수도 있어요. debug.fly.dev 서버를 사용해 자신의 리전을 확인할 수 있어요:
curl debug.fly.dev
traceroute나 mtr을 사용해 Fly.io까지의 라우팅을 확인해 보아요.
예를 들면:
traceroute debug.fly.dev
연결되는 리전의 기본 지연 시간을 확인해 보아요:
ping debug.fly.dev
애플리케이션 로직과 성능
과도한 CPU와 메모리 사용량을 유발하는 흔한 원인은 다음과 같아요:
- 단일 스레드 사용
- 블로킹(blocking)
- 다양한 잘못된 구성. 예를 들어 잘못되거나 누락된 환경 변수 등이 있어요.
HTTP 응답 시간
Fly.io HTTP 응답 시간 메트릭은 앱이 헤더로 응답하기 시작하는 데 걸리는 시간을 측정해요. 응답 본문이 아니라요.
멀티스레딩
앱에 여러 개의 스레드가 있다면 경합(contention) 문제가 없는지 확인해 보아요. 필요에 따라 CPU 리소스를 확장할 수도 있어요.
Fly.io 구성
앱 성능과 벤치마킹에 영향을 줄 가능성이 높은 몇 가지 구성 설정이 있어요.
Machine 크기 조정
더 많은 병렬 처리를 사용하도록 Machine 크기를 알맞게 조정해 보아요. Machine 크기 조정에 대해 자세히 알아보아요.
연결 또는 요청에 대한 동시성(concurrency) 설정
동시성 설정에 대한 가이드라인을 참고해 보아요.
자동 중지 및 시작 기능
자동 중지 및 시작(autostop/autostart)은 변수를 제거하고 앱 성능을 테스트하고 싶다면 끌 수 있어요.
자동 중지 및 시작을 끄지 않으면, Machine이 시작되기를 기다리는 동안 Fly Proxy가 연결을 대기열에 넣는 초기 비용 때문에 p99 값이 꽤 높아질 가능성이 커요.
분산 시스템
Fly.io에는 각 앱의 통제 밖에 있는 요율 제한(rate limit)과 하드 제한(hard limit)이 있어요. 이러한 제한은 엣지별·서비스별로 적용돼요. 단일 위치에서 테스트하면 여러 위치에서 테스트할 때보다 훨씬 빨리 요율 제한에 걸리게 돼요.
벤치마킹 노드가 어떻게 라우팅되는지 주의 깊게 살펴보아요. 비효율적인 라우팅은 지연 시간을 늘리고 결과를 왜곡해요. 잘못된 라우팅이 앱 테스트 또는 운영 앱에 문제를 일으킨다면 커뮤니티에 글을 올리거나(플랜에 따라) 지원팀에 연락해 주세요. 네트워크 제공자와 함께 살펴볼게요.
벤치마킹의 어려움
아마 현실적으로 앱을 벤치마킹하기 어려울 텐데, 그 이유는 여러 가지가 결합되어 있어요:
- 사용자마다 ISP가 매우 다양하고, 임시(ad hoc) 피어링 계약에 따라 때로는 비최적의 방식으로 다르게 라우팅돼요.
- 벤치마킹에서 Anycast 라우팅 요소를 제거하기 어려워요. 그냥 감수해야 하죠.
어떤 경우에는 실사용 트래픽의 일부를 Fly.io로 보내고 메트릭을 비교하는 것이 더 나은 선택일 수도 있어요.