고객당 앱 하나 (One App Per Customer) - 왜?
Fly.io에서는 고객마다 하나의 앱, 그리고 하나 이상의 Machine을 만들 것을 권장해요. 그러면 많은 이점을 얻을 수 있어요. 단일 애플리케이션이 모든 고객을 위한 Machine을 갖는 패턴도 기술적으로는 가능하지만, 로드 밸런싱의 이점을 잃고 안정성을 확보하기 어려워집니다.
출처: 문서
본문
고객마다 하나의 앱, 그 앱에 하나 이상의 Machine을 만들 것을 권장합니다. 이로부터 많은 것을 얻을 수 있어요:
- Fly.io 프록시의 로드 밸런싱을 활용할 수 있습니다
fly.toml구성은 앱 수준이므로, 같은 앱 안에서 다른 리전/다른 크기의 Machine을 실행할 수 있어요- 시크릿(secrets)은 앱 수준에 있습니다. 손상된 사용자 앱은 다른 사용자 앱의 시크릿을 볼 수 없어요. 반면 모든 사용자 프로젝트가 하나의 메가 앱에 섞여 있다면, 모두가 서로의 시크릿에 접근할 수 있게 됩니다(게다가
env가 엄청나게 커지고 다루기 힘들어져요) - 자동 시작 / 자동 중지는 앱 수준에서 실행됩니다
- 앱은 필요할 때 조직 간에 이동하기가 더 쉽습니다
- 로그에서 관심사의 분리가 더 깔끔합니다
- 앱은 격리된 네트워크를 얻습니다(네트워크 이름을 전달하면). 그리고 같은 앱의 Machine은 사설 네트워크를 공유합니다. 이에 대해서는 아래에서 더 자세히!
- 각 앱은 여전히 독립적으로 확장할 수 있어요. 그래서 더 강력한 머신이 필요한 매우 성공적인 사용자가 있다면, 다른 사용자에게 영향을 주지 않고 그들을 확장할 수 있습니다
단일 애플리케이션이 모든 고객의 Machine을 갖는 패턴은 기술적으로는 가능하지만, 로드 밸런싱의 이점을 잃고 안정적으로 만들기 어려울 거예요. 게다가 저희 도구는 앱당 수천 개의 Machine을 나열하도록 설계되지 않아서, 어떤 곳에서는 이상한 API 동작을 겪게 될 수 있습니다.
격리된 네트워크
각 Fly.io 조직은 Wireguard를 사용해 조직의 모든 Machine을 연결하는 격리된 네트워크를 얻습니다. 이는 사설 네트워킹 문서에서 더 자세히 설명되어 있어요. 일반적으로 말하면, 예를 들어 각 서비스에 하나의 앱을 배포할 수 있고, 문서에서 설명하는 대로 적절한 호스트 이름(.internal 또는 .flycast)을 사용해 서로 연결할 수 있습니다.
하지만 애플리케이션 생성 시 --network 매개변수를 전달하면 해당 애플리케이션을 위한 사용자 지정 사설 네트워크를 만들 수 있어요. 이 서브넷은 조직의 것과 연결되지 않으므로, 이 애플리케이션은 다른 것들과 격리됩니다(fly.toml에서 구성한 대로 공개 인터넷을 향한 서비스는 여전히 제공할 수 있음).
사용자 지정 사설 네트워크 문서는 격리된 앱이 다른 애플리케이션과 통제된 방식으로 통신할 수 있는 몇 가지 방법을 자세히 설명합니다:
- 애플리케이션 A(비격리)는 애플리케이션 B(격리)의 서브넷에
.flycastIP 주소를 가질 수 있으므로, 그 IP 주소를 통해 서로 통신할 수 있어요.fly ips allocate-v6 --private -a APP_A --network APP_B_NETWORK를 사용해 이 작업을 할 수 있습니다. 그러면 앱 A는 "app-b.flycast"에 직접 접촉할 수 있어요. - fly-replay 헤더를 사용하면 애플리케이션이 프라이빗 서브넷에 있더라도 다른 애플리케이션의 Machine으로 요청을 보낼 수 있습니다.
- 애플리케이션 B(격리)가 공개 서비스를 노출한다면, 다른 애플리케이션(격리 여부와 무관)은 공개 이름을 통해 인터넷으로 접근할 수 있어요.