Зачем нужен блок серверов перед Elasticsearch?

А, слушай, про балансировщики перед Elasticsearch! Ну это ж классика, ёпта. Без них в продакшене — как без штанов на морозе, сразу всё накрывается медным тазом.

Представь себе: у тебя кластер Elasticsearch, три ноды, пять, овердохуища. И туда со всех щелей лезут запросы — поиск, агрегации, индексация. Если пустить всех прямиком к нодам, будет пиздец. Одна нода сгорит, как спичка, а остальные будут смотреть, как она горит, и тихо бздеть. Поэтому умные люди ставят перед всем этим цирком шлюз. Nginx, HAProxy, что-то своё — не суть.

Зачем это, спросишь? Да похуй, спросишь или нет, я всё равно расскажу.

Во-первых, распределение нагрузки. Это чтобы не было так, что на одну ноду все навалились, а остальные хуй с горы стоят и пальцы гнут. Балансировщик раскидывает запросы по всем понемногу, чтобы работали как папа Карло — дружно. Скорость отклика вырастает, потому что очередь не копится на одном бедолаге.

Во-вторых, отказоустойчивость. Это когда одна нода взяла и накрылась. Без балансировщика клиенты начнут туда стучаться, получать таймауты, орать «всё упало!». А с ним — чих-пых тебя в сраку — он видит, что нода не отвечает, и тихо, без паники, перенаправляет трафик на тех, кто ещё дышит. Пользователь даже не заметит, что там внутри кто-то умер. Доверия к такой системе — ебать, выше крыши.

В-третьих, единая точка входа. Это вообще гениально. Клиентам (твоим приложениям, скриптам) похуй, сколько у тебя нод и как они зовутся. Они тыкают в один красивый URL — elasticsearch.example.com — и всё. Не нужно в каждом клиенте список нод хранить и логику перебора писать. Удобно, блядь, как в хорошем борделе — зашёл в одну дверь, а там уже разберутся, куда тебя направить.

В-четвёртых, и это главное, безопасность и контроль. Выставлять ноды Elasticsearch прямо в интернет — это как оставить квартиру открытой с табличкой «заходите, берите что хотите». Через балансировщик ты можешь:

• Поставить аутентификацию (логин-пароль, токены), чтобы не любой левый чувак мог твои данные посмотреть.
• Включить rate limiting — ограничить число запросов в секунду. А то какой-нибудь ебанько-разработчик накосячит в скрипте и начнёт слать 10 тысяч запросов в секунду, положив весь кластер. Балансировщик лишнее отрежет и скажет «иди на хуй, подожди».
• SSL накрутить, чтобы всё шифровалось.
• Опасные операции заблокировать. Например, DELETE /* — чтобы случайно или нарочно весь индекс не вынесли.

И вишенка на торте — кеширование. Nginx может запоминать результаты частых поисковых запросов (особенно которые GET). Следующий раз, когда придут за тем же самым, он отдаст ответ из своей памяти, даже не беспокоя Elasticsearch. Груз с плеч снимает — овердохуища.

Вот тебе пример, как это примерно в конфиге Nginx выглядит. Смотри, не запутайся:

upstream elasticsearch_cluster {
    # Балансируем по тому, у кого меньше всего соединений висит (least_conn) — справедливо, ёпта
    least_conn;
    server es-node-01.internal:9200 max_fails=3 fail_timeout=30s;
    server es-node-02.internal:9200 max_fails=3 fail_timeout=30s;
    server es-node-03.internal:9200 max_fails=3 fail_timeout=30s;
}

server {
    listen 9200;
    server_name elasticsearch.example.com;

    # Чтоб какой-нибудь умник огромный JSON не засунул
    client_max_body_size 50M;

    location / {
        proxy_pass http://elasticsearch_cluster;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # А вот и наш rate limiting для операций записи (POST/PUT). Больше 20 запросов разом — пошёл в жопу!
        limit_req zone=es_index burst=20 nodelay;
        limit_req_status 429;
    }
}

Короче, если коротко: без этого слоя ты ходишь по охуенно тонкому льду. Рано или поздно провалишься. С ним — спишь спокойно, даже если внутри кластера какая-то нода решила стать звездой и устроить истерику. Всем плевать, балансировщик её изолирует, как хитрая жопа в карантине.