Todos os pedidos entram na fila de surtos do ELB

Question

Um problema: parece que todas as solicitações ao nosso aplicativo acabam na fila de inicialização do ELB

Exemplo de um gráfico de fila de aumento:

TemosumELBclássiconaAWScomváriascaixasEC2atrásdele.ConfiguraçãodosouvintesdeELBemumpróximocaminho

LBProtocolLBPortInstanceProtocolInstancePortCipherSSLCertificateTCP80TCP80N/AN/A

EmumainstânciadoEC2,temosumservidornginxcomopróximonginx.conf:

usernginx;worker_processes3;pid/var/run/nginx.pid;worker_rlimit_nofile8192;worker_rlimit_sigpending32768;events{worker_connections2048;multi_accepton;useepoll;accept_mutexoff;}http{sendfileon;tcp_nopushon;tcp_nodelayon;keepalive_timeout65;types_hash_max_size2048;map_hash_bucket_size128;server_tokensoff;client_max_body_size0;server_names_hash_bucket_size256;include/etc/nginx/mime.types;default_typeapplication/octet-stream;log_formatmain'$remote_addr-$remote_user[$time_local]"$request" '
  '$status $body_bytes_sent "$http_referer" '
  '"$http_user_agent" "$http_x_forwarded_for" $request_time';

  access_log /app/log/nginx/access.log main;
  error_log /app/log/nginx/error.log;

  gzip on;
  gzip_disable "msie6";

  gzip_vary on;
  gzip_comp_level 4;
  gzip_buffers 16 8k;
  gzip_http_version 1.1;
  gzip_types text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript;

  client_body_temp_path /app/tmp/nginx;:q

  include /etc/nginx/sites-enabled/*;

  upstream tomcat {
    server localhost:8080;
  }

  upstream httpd {
    server localhost:9000;
  }

  upstream play {
    server localhost:9000;
  }

e vhost sites.conf

log_format  proxylog  '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$proxy_protocol_addr" $request_time';

server { 
  server_name     www.my-site.com;
  rewrite ^(.*)   http://my-site.com$1 permanent;
}

server {
  listen 80 proxy_protocol;

  listen 443 ssl proxy_protocol;
  ssl_certificate      /etc/nginx/my-certificate.crt;
  ssl_certificate_key  /etc/nginx/my-key.key;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers "SECRET";
  ssl_prefer_server_ciphers on;

  set_real_ip_from 10.0.0.0/8;
  root /app/websites/my-site.com/httpdocs;
  index index.html index.htm;
  real_ip_header proxy_protocol;

  server_name my-site.com;
  access_log /app/log/nginx/my-site.com.access.log proxylog buffer=16k flush=2s;
  error_log /app/log/nginx/my-site.com.error.log;

  charset utf-8;

  location /foo {
    proxy_pass http://play;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }

  location /bar {
    add_header Access-Control-Allow-Origin "*" always;
    add_header Access-Control-Allow-Methods "GET,POST,OPTIONS,DELETE,PUT" always;
    add_header 'Access-Control-Allow-Headers' 'Origin, X-Requested-With, Content-Type, Accept, User-Agent, Authorization, Referer, Timestamp' always;
    add_header Access-Control-Allow-Credentials true always;
    proxy_pass http://play;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }

  location / {
    add_header Access-Control-Allow-Origin "*" always;
    add_header Access-Control-Allow-Methods "GET,POST,OPTIONS,DELETE,PUT" always;
    add_header 'Access-Control-Allow-Headers' 'Origin, X-Requested-With, Content-Type, Accept, User-Agent, Authorization, Referer, Timestamp' always;
    add_header Access-Control-Allow-Credentials true always;

    real_ip_header proxy_protocol;
    set_real_ip_from 10.0.0.0/8;

    proxy_read_timeout 90s;
    proxy_set_header X-Real-IP $proxy_protocol_addr;
    proxy_set_header X-Forwarded-For $proxy_protocol_addr;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Server $host;
    proxy_pass  http://play;
    proxy_set_header Host $http_host;

  }

  location ~ ^/(images|css|js|html) {
    root /app/websites/my-site.com/httpdocs;
  }

  error_page  404              /404.html;

  error_page   500 502 503 504  /50x.html;
  location = /50x.html {
    root   html;
  }
}

Estou limitando possíveis suspeitos de um problema para o ELB e o nginx, e não o mais óbvio - solicitações reais de processamento de servidor web, porque em um dos meus testes eu removi completamente o aplicativo java e o substitui por um nó.js servidor que estava respondendo 'hello world' para todas as solicitações, e eu ainda estava recebendo todas as solicitações registradas na fila de aumento.

Eu também tentei ajustar worker_processes e keepalive_timeout para ver se isso afeta alguma coisa, e isso não acontece.

O que me incomoda é que essa fila de aumento de 1 não afeta o desempenho de um serviço, pois parece que as solicitações tendem a permanecer em frações de segundo, mas o que não entendo é por que uma única solicitação acaba passando pela fila de surtos.

    

Answer 1

Você tem o seu ELB configurado para TCP?

Nesse caso, o seu ELB registrará todas as conexões feitas na fila de surtos. Não há como fugir que tenho medo. Você precisa usar http ou https para que a fila de aumento funcione corretamente.

-

Atualização do OP

Eu criei uma minúscula instância do EC2, com um simples servidor TCP que apenas responde 'potato' a cada solicitação. Eu o coloquei atrás de um ELB clássico com o ouvinte TCP, e fiz uma única solicitação para o ELB novo e verifiquei o gráfico da fila de aumento.

OlhandoparaadocumentaçãodaAWS Ouvintes do seu balanceador de carga clássico

When you use TCP (layer 4) for both front-end and back-end connections, your load balancer forwards the request to the back-end instances without modifying the headers. After your load balancer receives the request, it attempts to open a TCP connection to the back-end instance on the port specified in the listener configuration.

e isso:

For every registered and healthy instance behind an HTTP/HTTPS load balancer, Elastic Load Balancing opens and maintains one or more TCP connections. These connections ensure that there is always an established connection ready to receive HTTP/HTTPS requests.

O que, a meu ver, implica que toda vez que fazemos uma chamada para o ELB configurado para TCP, ele deixa nossa solicitação de lado, para poder abrir uma conexão com nosso EC2 e só então passa a solicitação para a máquina.