Elasticsearch は、構造化データと非構造化データの全文検索とリアルタイム分析を提供する、高度で高性能、スケーラブルなオープンソース検索エンジンです。
その特徴は、HTTP経由でRESTful APIを使用できることであり、既存のWebアーキテクチャに簡単に統合できます。したがって、同時実行性が高い場合は、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 設定は次のとおりです:
長時間の接続、ロード バランシング、10 分間の有効なリクエストのキャッシュ、アクティブなヘルス モニタリング、およびステータスの収集。====セキュリティ検証構成の境界線は私です====
セキュリティ検証を伴う構成は次のとおりです:
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; } }
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; } } }
$ printf "john:$(openssl passwd -crypt s3cr3t)n" > passwords
$ curl -i localhost:8080 # HTTP/1.1 401 Unauthorized # ...
====アクセス制限設定の境界線は私です====
$ curl -i john:s3cr3t@localhost:8080 # HTTP/1.1 200 OK # ...
この設定を行った後は、_shutdown への直接アクセスが拒否されます:
location / { if ($request_filename ~ _shutdown) { return 403; break; } proxy_pass http://elasticsearch; proxy_redirect off; }
現在のプロジェクトでは、上位層アプリケーションに必要なのはES 内のデータにアクセスするため、クラスターやノードなどの API インターフェイスは上位層アプリケーションへのアクセスを拒否する必要があります。同時に、削除すべきではないリソースに対する -DELETE も禁止する必要があります。これは ES クラスターのセキュリティを保証するものであり、そうでない場合、クラスター構成が簡単に変更されたり、大量のデータが削除されたりする可能性があります。
====私はマルチロール構成の境界線です====
$ curl -i -X POST john:s3cr3t@localhost:8080/_cluster/nodes/_shutdown # HTTP/1.1 403 Forbidden # ....
マルチロールのアクセス制限のコストは、各ロールが異なるポート番号を使用してクラスターにアクセスすることですが、これはアーキテクチャ的に合理的です。クライアントは 1 つのロールを持ち、1 つのアクセス ポートに対応するだけで済みます。
lua を使用すると、より詳細な URL 権限制御を実行できます。nginx は lua の埋め込みも非常に適切かつ簡潔にサポートします。ここではこれ以上詳しく説明しません。興味があれば調べることができます。
参考ドキュメント:
http://www.ttlsa.com/nginx/nginx-elasticsearch/
https://www.elastic.co/blog/playing-http-tricks-nginx
著作権表示: この記事はブロガーによるオリジナル記事であり、ブロガーの許可なしに転載することを禁じます。
上記は ElasticSearch の紹介です。Nginx は ElasticSearch クラスターにどのようなメリットをもたらしますか? 、関連コンテンツも含めて、PHP チュートリアルに興味のある友人に役立つことを願っています。