Назад | Перейти на главную страницу

Все запросы попадают в очередь всплесков ELB

Проблема: кажется, что каждый отдельный запрос к нашему приложению попадает в очередь всплесков ELB.

Пример диаграммы очереди на выбросы:

У нас есть классический ELB на AWS с несколькими блоками EC2 за ним. Настройка слушателей ELB следующим образом

LB Protocol  LB Port  Instance Protocol  Instance Port  Cipher SSL  Certificate 
TCP          80       TCP                80              N/A        N/A

На экземпляре EC2 у нас есть сервер nginx со следующим nginx.conf:

user nginx;
worker_processes 3;
pid /var/run/nginx.pid;
worker_rlimit_nofile 8192;
worker_rlimit_sigpending 32768;

events {
  worker_connections 2048;
  multi_accept on;
  use epoll;
  accept_mutex off;
}

http {
  sendfile on;
  tcp_nopush on;
  tcp_nodelay on;
  keepalive_timeout 65;
  types_hash_max_size 2048;
  map_hash_bucket_size 128;
  server_tokens off;
  client_max_body_size 0;
  server_names_hash_bucket_size 256;

  include /etc/nginx/mime.types;
  default_type application/octet-stream;

  log_format  main  '$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;
  }

и 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;
  }
}

Я ограничиваю возможных подозреваемых в проблеме ELB и nginx, а не самую очевидную - фактические запросы обработки веб-сервера, потому что в одном из моих тестов я полностью удалил java-приложение и заменил его фиктивным сервером node.js, который был отвечая «привет, мир» на каждый запрос, и все эти запросы все еще регистрировались в очереди всплесков.

Я также пробовал отрегулировать worker_processes и keepalive_timeout чтобы увидеть, влияет ли это на что-нибудь, а это не так.

Что меня беспокоит, так это то, что эта пиковая очередь из 1 не влияет на производительность службы, так как кажется, что запросы, как правило, остаются там доли секунды, но я не понимаю, почему даже один запрос в конечном итоге проходит очередь всплесков.

У вас установлен ELB на TCP?

Если это так, ваш ELB будет регистрировать каждое соединение, сделанное в очереди всплесков. Боюсь, что никуда не денешься. Вы должны использовать http или https, чтобы очередь всплесков работала правильно.

-

Обновление с OP

Я создал крошечный экземпляр EC2 с простым TCP-сервером, который просто отвечает «картошка» на каждый запрос. Я поставил его за классический ELB с TCP-прослушивателем, сделал один запрос к моему свежему ELB и проверил диаграмму очереди всплесков.

Просмотр документации AWS Слушатели для вашего классического балансировщика нагрузки

Когда вы используете TCP (уровень 4) как для интерфейсных, так и для внутренних соединений, ваш балансировщик нагрузки перенаправляет запрос внутренним экземплярам без изменения заголовков. После того, как ваш балансировщик нагрузки получает запрос, он пытается открыть TCP-соединение с внутренним экземпляром на порту, указанном в конфигурации прослушивателя.

и это:

Для каждого зарегистрированного и исправного экземпляра за балансировщиком нагрузки HTTP / HTTPS открывается и поддерживается одно или несколько TCP-подключений. Эти соединения гарантируют, что всегда существует установленное соединение, готовое для получения запросов HTTP / HTTPS.

Что, насколько я понимаю, означает, что каждый раз, когда мы вызываем ELB, настроенный для TCP, он откладывает наш запрос, чтобы иметь возможность открыть соединение с нашим EC2, и только затем передает запрос машине.