I would like to understand more about regions

Questions / Help
1

Hi,

I deployed my site (Remix app) to 13 regions and I have 11 instances (fly scale count 11)

Region Pool: 
ams
cdg
dfw
ewr
fra
iad
jnb
lhr
nrt
sea
sin
syd
yyz

I expect it to deploy 1 app per region. However, here is the result where x is the instance

ams
cdg x x
dfw
ewr x x
fra x
iad
jnb
lhr x x
nrt x x
sea
sin x x
syd
yyz

Some regions have no instances while some have 2 instances.

I was wondering why so? I can see traffic coming from IAD but why it decides not to put an instance there but in YYZ instead?

image
image528×572 54.9 KB

I have traffics from AMS but no instance there even though I add it to the region list
image

How does the region pool work? Could you help me clarify it?

Can (and how) I decide which region I should deploy my app to? I add the region to the pool list but it seems not to “respect” it.

What difference between Edge and Instance? Does Edge mean that I have traffic that comes from that region?

image
image1240×778 61.2 KB

2

Though it would be a nice feature (and we hope to eventually support some kind of auto-scaling like this for Machines), the app scheduler doesn’t currently place instances based on an analysis of incoming traffic load. It simply places instances in any of your selected regions where there is sufficient capacity.

You can manually control instance placement by using the --max-per-region 1 argument to flyctl scale count to force your app to deploy only 1 instance per region.

Yes, Edge means you have incoming traffic from that region (it’s the region where our proxy first accepts the connection before routing the traffic to your nearest app instance).

3

Could you elaborate a bit on this?

So the behavior now is that I select the region pool and how many instances, and Fly just puts those instances randomly on regions? It could be 2 instances on one region while no instance in others. Or any logic behind how we place the instances?

4

Fly.io currently uses HashiCorp Nomad as its ‘application scheduler’, the part of the system responsible for deciding where to place instances based on allocating server resources (such as cpu/memory). In this system, under the hood we create a job specification based on your Fly app config. This specification includes a couple hard ‘constraints’, including your app’s selected regions and any ‘max per region’ setting if set. The Nomad scheduler will then place VMs on servers matching those constraints using a bin-packing algorithm, so the exact servers your VMs end up on will appear more or less ‘random’ to the application developer (because it depends on resources available on servers in selected regions at any given time).

If you need more low-level control over exact placement of instances, you can try using Machines which is a low-level VM provisioning API to launch individual instances in specific regions. We’re building the next iteration of our application scheduler on top of Machines, and it should be easier for us support more advanced configuration and scaling features once that work is ready.

1 Like