자세히 설명해주셔서 감사합니다. 그런데 약간 제 상식과 충돌하는 지점이 있습니다.
예를 들어, 우리가 Serverless Edge function 을 deploy 한다고 하면, 모든 Edge 에 일일이 배포하지 않아야 합니다. 한 번만 배포한다면 알아서 각 엣지로 Function 코드와 빌드환경이 전파되어야 하죠. 그리고 실제로도 그런 식으로 배포된다고 알고 있습니다.
그러나, Fly.io 가 제공하는 방식은 하나의 리전을 선택해서 배포하도록 되어있습니다. 제가 한 번의 Deploy 를 한다면 하나의 Server, 하나의 물리공간에 Function 혹은 Server 가 배포됩니다. 따라서 말씀하신 부분과 제가 실제로 써봤을 때의 사용감 사이에 괴리가 있는 것 같은데요,
"엣지 컴퓨팅이라 함은 한 번의 배포로 엣지마다 코드가 배포되어야 한다"라는 전제에 대해서 어떻게 생각하십니까?
그리고 그러면 그냥 EC2 각 region 에 만들어 놓고 띄우는 거랑 무슨 차이냐 라고 하신다면
- Edge Computing 이 됩니다. 즉, 요청을 가까운 region 이 처리하도록 수 있도록 하는 시스템이 갖춰져있습니다.
- clustering 이 되지 않는 다른 framework 에서는 느끼기 힘든 장점이라 아마 Fly.io 의 컨셉에 대해 많은 분들이 의아해하시는 것 같은데, Phoenix 에서는 Fly.io 에서 제공하는 network 시스템을 기반으로 clustering 이 쉽게 가능합니다. 예를 들면, 서버가 여러 region 에 나뉘어 5개가 떠있어도 각 서버에 접속해있는 유저의 정보를 서버 간에 쉽게 동기화할 수 있습니다(facebook 에서 내가 접속한 region 에 따라 친구들의 online 표시가 영향을 받지는 않죠). 따라서 Fly.io 에서는 Edge Computing 에서의 여러 technical challenge 가 쉽게 해결됩니다.
이제야 무슨 말씀이신지 조금 이해가 된 것 같습니다. 제가 식견이 짧아서 따라잡는 데 좀 오래 걸렸네요. 친절한 설명 거듭 감사드립니다.
해당 전제의 어떤 근거가 있으신가요? 그냥 많은 경우 그렇다라고 한다면 그것이 전제인 이유가 없는 것 같습니다.
Fly.io 에서 region 선택은 사용자에게 제어 권한이 있는 부분이지 제약이 있는 부분은 아닙니다.
모든 곳에 한 번에 배포되고 싶다면 모든 region 을 region pool 에 추가하고 scale 값만 늘려놓으면 됩니다.
Edge function 은 어느 region 에 띄워주든 제공자나 사용자 다 딱히 고려해야할 사항이 없지만
Edge server 를 띄우는 것은 비용 때문에 얘기가 달라집니다. 예를 들어, 나는 서버 2개를 띄울 비용을 지불할 용의가 있는데 사용자가 아시아 전역에 분포되어있다면, 이 서버를 한국, 도쿄, 싱가폴, 인도 등의 region 중에 2군데를 골라서 띄워야 합니다. 전세계 모든 region 에 띄우는 것은 비용면에서 비합리적입니다.
기존 곳들은 직접 Edge 를 '구현' 합니다.
Fly.io 는 Edge 를 서비스로 '제공' 합니다.
Cloudflare Edge 를 제공하는 것이 맞고 Edge 로 불립니다.
다만 성격들이 좀 다른데, 요즘 Edge 'fucntion' 을 제공하는 곳들은 Serverless Edge 를 제공해주는 것이죠.이는 상대적으로 쉽지만 모든 요구사항을 충족시켜주지 못합니다.
Fly.io 는 Server Edge 를 제공합니다. 기존에 Server 를 이용하면서 단일 region 에만 적합한 구조를 사용하는 곳들이 많았다면 (global 에 적합한 구조를 가져가기가 쉽지 않았기 때문에), Fly.io 를 이용하면 상대적으로 손쉽게 Server Edge 를 구성해서 global 서비스를 만들 수 있습니다.