ElasticSearch: Nginx가 ElasticSearch 클러스터에 어떤 이점을 가져올 수 있나요?

Elasticsearch는 정형 및 비정형 데이터에 대한 전체 텍스트 검색과 실시간 분석을 제공하는 확장 가능한 고성능 고성능 오픈 소스 검색 엔진입니다.

HTTP를 통해 RESTful API를 사용할 수 있다는 점이 특징이며, 이는 기존 웹 아키텍처에 쉽게 통합될 수 있습니다. 따라서 동시성이 높은 경우 nginx 역방향 프록시를 사용하여 여러 Elasticsearch 서버에 부하를 분산할 수 있습니다.

아키텍처 다이어그램:

그렇다면 nginx를 사용하면 어떤 이점이 있을까요?

1. 각 API 액세스 요청에 대한 로그를 기록합니다. (ElasticSearch 자체에서는 이 기능을 지원하지 않으며, SlowLog 및 서비스 로그만 지원합니다.)

2. 다수의 클라이언트 연결을 지원합니다. 공식 ES 블로그에서는 연결 유지를 사용하고 nginx와 ES 간의 긴 연결을 사용할 것을 권장합니다. 제가 이해한 바에 따르면 일반적인 상황에서는 ES가 아키텍처의 최하위 계층이고 이에 대한 액세스는 일반적으로 고정된 상위 계층 서비스입니다. 이러한 상황은 연결 유지를 사용하는 데 적합합니다. (실제로 nginx는 연결 유지 여부에 관계없이 더 많은 수의 클라이언트 연결을 지원할 수 있습니다.)

3. Elasticsearch 서버에 대한 로드 밸런싱 요청.

4. 동일한 콘텐츠에 대해 Elasticsearch 서버에 대한 요청을 다시 줄이기 위해 데이터를 캐시합니다.

5. 활성 상태 감지(nginx plus만 해당)를 제공하고 백엔드 Elasticsearch 서버가 정상인지 지속적으로 감지하고 적극적으로 전환합니다. (ES가 중단되면 nginx는 이 노드에 요청을 분배하지 않습니다. 노드가 정상으로 돌아오면 자동으로 원래 위치로 돌아갑니다.)

6. 풍부한 모니터링 지표 보고(nginx plus에만 해당), 모니터링 및 관리를 제공합니다.

7. 보안 검증. 계정 이름과 비밀번호가 있는 클라이언트만 ES 클러스터에 액세스할 수 있습니다.

8. "_shutdown"과 같은 특수 인터페이스에 대한 액세스를 제한합니다. (이 기능은 매우 실용적입니다.)

9. 역할에 따른 접근 제어(예: 사용자 역할에는 데이터 접근 권한이 있고, 관리자 역할에는 클러스터 관리 및 제어 권한이 있습니다)

== ==예제 분할 라인을 구성 중입니다====

간단한 nginx 구성은 다음과 같습니다.

upstream elasticsearch_servers {
    zone elasticsearch_servers 64K;
    server 192.168.187.132:9200;
    server 192.168.187.133:9200;
    keepalive 40 ;
}
match statusok {
    status 200;
    header Content-Type ~ "application/json";
    body ~ '"status" : 200';
}
server {
    listen 9200;
    status_zone elasticsearch;
    location / {
        proxy_pass http://elasticsearch_servers;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_cache elasticsearch;
        proxy_cache_valid 200 302 10m;
        proxy_cache_valid 404 1m;
        proxy_connect_timeout 5s;
        proxy_read_timeout 10s;
        proxy_set_header Connection "Keep-Alive";
        proxy_set_header Proxy-Connection "Keep-Alive";
        health_check interval=5s fails=1 passes=1 uri=/ match=statusok;

    } 
    # redirect server error pages to the static page /50x.html
    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        root /usr/share/nginx/html;
    }
    access_log logs/es_access.log combined;
}
server {
    listen 8080;
    root /usr/share/nginx/html;
    location / {
        index status.html;
    }
    location =/status {
        status;
    }
}

긴 연결, 로드 밸런싱, 10분간 유효한 요청 캐싱, 활성 상태 모니터링 및 상태 수집.

====보안 검증 구성의 구분선====

보안 검증 구성은 다음과 같습니다.

events {
  worker_connections  1024;
}

http {

  upstream elasticsearch {
    server 127.0.0.1:9200;
  }

  server {
    listen 8080;

    auth_basic "Protected Elasticsearch";
    auth_basic_user_file passwords;

    location / {
      proxy_pass http://elasticsearch;
      proxy_redirect off;
    }
  }
}

암호 파일은 동일한 디렉터리에 있습니다. 내부의 nginx.conf 형식은 "사용자 이름: crypt(3) 암호화된 비밀번호 문자열"입니다.

$ printf "john:$(openssl passwd -crypt s3cr3t)n" > passwords

위 구성을 완료하고 nginx를 다시 시작하면 서비스에 대한 직접 액세스가 금지됩니다.

$ curl -i localhost:8080
# HTTP/1.1 401 Unauthorized
# ...

올바른 사용자 이름과 비밀번호를 사용하면 원활하게 액세스할 수 있습니다.

$ curl -i john:s3cr3t@localhost:8080
# HTTP/1.1 200 OK
# ...

====접근 제한 구성의 구분선====

location / {
  if ($request_filename ~ _shutdown) {
    return 403;
    break;
  }

  proxy_pass http://elasticsearch;
  proxy_redirect off;
}

이 구성을 수행하면 _shutdown에 대한 직접 액세스가 거부됩니다:

$ curl -i -X POST john:s3cr3t@localhost:8080/_cluster/nodes/_shutdown
# HTTP/1.1 403 Forbidden
# ....

현재 프로젝트의 경우 상위 계층 애플리케이션은 ES의 데이터에만 액세스하면 되므로 클러스터, 노드와 같은 API 인터페이스는 상위 계층 애플리케이션에 대한 액세스를 거부해야 합니다. 동시에 삭제하면 안 되는 리소스에 대한 -DELETE도 금지되어야 합니다. 이는 ES 클러스터에 대한 보안 보장입니다. 그렇지 않으면 클러스터 구성이 쉽게 수정되거나 대량의 데이터가 삭제될 수 있습니다.

====다중 역할 구성의 구분선====

events {
  worker_connections  1024;
}

http {

  upstream elasticsearch {
      server 127.0.0.1:9200;
  }

  # Allow access to /_search and /_analyze for authenticated "users"
  #
  server {
      listen 8081;

      auth_basic           "Elasticsearch Users";
      auth_basic_user_file users;

      location / {
        return 403;
      }

      location ~* ^(/_search|/_analyze) {
        proxy_pass http://elasticsearch;
        proxy_redirect off;
      }
  }

  # Allow access to anything for authenticated "admins"
  #
  server {
      listen 8082;

      auth_basic           "Elasticsearch Admins";
      auth_basic_user_file admins;

      location / {
        proxy_pass http://elasticsearch;
        proxy_redirect off;
      }
  }

}

관리자는 모든 API에 액세스할 수 있고 사용자만 허용됩니다. _search 및 _analyze 인터페이스에 액세스합니다.

다중 역할 액세스 제한의 비용은 각 역할이 서로 다른 포트 번호를 사용하여 클러스터에 액세스한다는 것입니다. 이는 구조적으로 합리적입니다. 클라이언트는 하나의 역할과 하나의 액세스 포트만 있으면 됩니다.

lua를 사용하면 더 자세한 URL 권한 제어를 수행할 수 있습니다. nginx는 lua 임베딩도 매우 잘 지원하며 여기서는 더 이상 심층적인 탐색을 수행하지 않습니다. 관심이 있으시면 알아보실 수 있습니다.

참조 문서:

http://www.ttlsa.com/nginx/nginx-elasticsearch/

https://www.elastic.co/blog/playing -http-tricks-nginx

저작권: 이 글은 해당 블로거의 원본 글이므로 블로거의 허락 없이 복제할 수 없습니다.

위에서는 ElasticSearch를 소개합니다. Nginx가 ElasticSearch 클러스터에 어떤 이점을 가져올 수 있습니까? , 관련 내용을 포함하여 PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.