Distribuindo a carga do Django App

1

Atualmente, estou abordando os estágios para remover meu primeiro aplicativo em grande escala do desenvolvimento.

Conversei com alguns CTOs que sabem do que estão falando e fui aconselhado a fazer o seguinte:

Break up launching phases into a 4 step process

I. Launch the single structured app. assets/ and db.sqlite3 inside of the application, all on one server.

II. Move the database onto its own server, use a CDN (like aws-s3) to hold the assets/

III. Set up load balancing

IV. Use a NoSQL solution rather than a rdbms.

Então! A questão principal que tenho diz respeito ao item 2:

Eu tenho que configurar um ambiente para executar o sqlite3, criar um usuário e, em seguida, dar essa autenticação especificamente para o meu aplicativo django?

Estou familiarizado com os ativos armazenados externamente, mas nunca tive que mover o banco de dados, excluindo as soluções não-django que implementaram a análise.

tldr; Eu sou um desenvolvedor profissional amador e nunca construí nada que se destinava a ter mais de 1.000 usuários, e estou curioso para saber como é o fluxo do processo para criar um aplicativo django que consegue reduzir com sucesso a carga do servidor usando outro servidor .

Onde meu raciocínio pode ser falho: Eu não entendo como isso distribui a carga, já que para mim parece que o aplicativo teria que fazer solicitações mais distantes para se comunicar com o banco de dados. Na verdade, ele está apenas agindo como um intermediário que passa mensagens entre o cliente e o servidor?

Planejando usar o apache para hospedagem, provavelmente em uma instância do ec2 ubuntu 14.04 (vários?).

Obrigado.

    
por jdero 22.05.2014 / 12:27

1 resposta

2

Estou muito, muito confuso com a lista que você recebeu.

Primeiro, ele diz para você usar o sqlite3 em um único servidor. Então ele diz para mover este banco de dados sqlite para um host diferente? Em seguida, ele diz para você configurar o balanceamento de carga (em um único servidor da Web?) E diz para você usar uma solução NoSQL quando não houver motivo algum para que um rdms seja um gargalo do que você descreveu aqui.

De qualquer forma, a configuração geral de um projeto que você deseja hospedar amplamente como este (e de maneira fácil) é colocar o banco de dados em um host separado (seja mysql, seja postgresql, o que você gosta) e implantar código para um número de servidores de aplicativos.

Você usaria ferramentas de implantação ou um nfs para garantir que o código em todos os servidores de aplicativos seja o mesmo.

Na frente, você geralmente posiciona um balanceador de carga e / ou um proxy HTTP reverso para descarregar o tráfego que normalmente atingiria seus servidores de back-end.

Uma boa solução seria ir com a Amazon e usar o Elastic Loadbalancer, fazendo com que seu esquema se pareça com isso:

  • 1 instância de um balanceador de carga.
  • 2 (ou mais) instâncias de um aplicativo servidores.
  • 1 (ou mais) instâncias do seu servidor de banco de dados favorito.

Você pode estender / implodir isso executando o servidor de banco de dados em um dos seus servidores de aplicativos. Você pode estendê-lo adicionando failovers para seus servidores de banco de dados, provisionamento automático, ferramentas de provisionamento, etc.

    
por 22.05.2014 / 13:45