Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

Nginx Reverse Proxy with Kafka.pptx

Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Próximo SlideShare
Kafka Rest.pptx
Kafka Rest.pptx
Cargando en…3
×

Eche un vistazo a continuación

1 de 14 Anuncio

Más Contenido Relacionado

Similares a Nginx Reverse Proxy with Kafka.pptx (20)

Anuncio

Más reciente (20)

Nginx Reverse Proxy with Kafka.pptx

  1. 1. Intro Kafka Cluster incoming message - without kafka client library support (e.g. Android or IOS app, IOT devices, …) - send message using Rest APIs
  2. 2. why we use nginx? source : https://www.nginx.com/resources/wiki/community/why_use_it/
  3. 3. Sample architecture Kafka Cluster upstream testme{ server backendAddr:8090 server backendAddr:8091 server backendAddr:8092 } incoming message http://[nignx server address]:8070/api backendAddr:8090 backendAddr:8091 backendAddr:8092 Load Balancing … (can be added)
  4. 4. Install Nginx • vi /etc/yum.repos.d/nginx.repo • yum install nginx • firewall-cmd --permanent --zone=public --add-port=80/tcp • firewall-cmd --reload [nginx] name=nginx repo baseurl=https://nginx.org/packages/centos/$releasever/$basearch/ gpgcheck=0 enabled=1
  5. 5. Install Nginx • Configuration Directory : /etc/nginx • Configuration Reload : nginx -s reload • Service Stop : systemctl stop nginx • Service Start : systemctl start nginx http://your server address
  6. 6. [Port] Setting Permission and Open • semanage port -l | grep http_port_t • semanage port -a -t http_port_t -p tcp 8090 • semanage port -a -t http_port_t -p tcp 8091 • semanage port -a -t http_port_t -p tcp 8092 • semanage port -a -t http_port_t -p tcp 8070
  7. 7. Log • access log tail -f /var/log/nginx/access.log • error log tail -f /var/log/nginx/error.log
  8. 8. Configuration reference : https://www.sobyte.net/post/2021-09/nginx-proxy-remove-prefixes/ upstream testme { server 127.0.0.1:8090; server 127.0.0.1:8091; server 127.0.0.1:8092; } server { listen 8070; listen [::]:8070; location /api { proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_connect_timeout 300; proxy_send_timeout 300; proxy_read_timeout 300; send_timeout 3000; proxy_pass http://testme/api; } } # pwd /etc/nginx/conf.d # vi test.conf firewall-cmd --permanent --zone=public --add-port=8070/tcp firewall-cmd --reload nginx -s reload systemctl stop nginx systemctl start nginx
  9. 9. Backend Application • python3 testBackend.py 8090 & • python3 testBackend.py 8091 & • python3 testBackend.py 8092 & testBackend.py source : https://github.com/wonyongHwang/KopoBlockchain/tree/master/ref
  10. 10. Test • curl --location --request POST 'http://192.168.56.30:8070/api' --header 'Content- Type: application/json;encode=utf-8' --data-raw '{"key":"value"}' request response application log nginx access log
  11. 11. Backend Application as a Producer (1/2) prerequisite : kafka-python (https://kafka-python.readthedocs.io/en/master/install.html) testKafka.py source : https://github.com/wonyongHwang/KopoBlockchain/tree/master/ref
  12. 12. Backend Application as a Producer (2/2) request response application log kafka-console-consumer.sh --bootstrap-server master:9092,slave1:9092,slave2:9092 --topic kopo- topic --from-beginning kafka consumer
  13. 13. Reference • https://docs.nginx.com/nginx/admin-guide/web-server/reverse-proxy/

Notas del editor

  • https://www.newiki.net/wiki/NGINX

    아파치 웹 서버는 접속 요청이 들어올 때마다, 즉 네트워크 소켓이 필요할 때마다 프로세스 또는 스레드를 새로 만들어서 배당하는 구조인데, 이 때문에 소켓이 10,000개 이상 열리면 아무리 하드웨어의 성능이 좋아도 웹 서버의 성능이 급격하게 저하되는 현상이 일어나며 이를 이른바 C10K 문제라고 부른다. 사실 이 문제는 정확히는 아파치 웹 서버가 잘못되었다기보다는 UNIX 계열 운영체제의 입출력(I/O) 시스템에 한계가 있기 때문이다. 지금 주류를 이루는 UNIX 계열 운영체제들을 설계할 당시에는 동시에 열리는 소켓 수가 10,000개나 된다는 건 상상도 못할 일이었고, 따라서 소켓이 필요할 때마다 프로세스나 스레드를 새로 만드는 게 별 문제가 안 되었다. 그러나 인터넷 시대가 열리고 서버가 처리해야 하는 동시 접속 수가 급격하게 불어나면서 문제가 제기 되기 시작했다. 이를 극복하기 위한 방안 중 하나가 비동기 이벤트 기반의 싱글 스레드 방식으로, 즉 소켓이 필요할 때 프로세스나 스레드를 새로 만들지 않고 하나의 스레드가 모든 요청을 처리하되, 이벤트가 발생할 때에만 해당 소켓의 요청을 처리하는 방식이다. Node.js도 이러한 방식을 사용하고 있으며, C10K 문제를 극복하기 위해 NGINX가 채택한 해결책도 역시 비동기 이벤트 기반의 싱글 스레드다. 따라서 10,000개 이상의 동시 소켓도 잘 처리하는 것은 물론이고 새로운 요청이 발생했을 때 자원 소모가 아파치에 비해 확실히 적다. 아파치도 문제를 극복해 보려고 멀티스레드를 적극 활용하는 쪽으로 개발을 하고 있지만 '1소켓 = 1프로세스 또는 스레드'인 한은 근본적인 한계를 벗어나지 못한다.
    NGINX의 또 한 가지 주요한 특징으로는 리버스 프록시(reverse proxy)가 있다. 리버스 프록시란 클라이언트와 내부 서버 사이에 NGINX가 있으면서 클라이언트로부터 요청이 들어왔을 때 내부 서버로 전달해서 처리를 하게 한 다음, 응답을 받아서 클라이언트로 전달하는 기능이다. 즉 NGINX는 양쪽 사이에서 오로지 '전달자' 구실만 한다.
    . NGINX의 특징인 리버스 프록시 기능을 활용해서 정적 파일 처리는 NGINX가 직접 하고, 아파치 쪽 기능이 필요한 부분은 아파치에 넘겨서 처리할 수도 있다.
  • default load balancing method : round-robin
    least_conn
    ip_hash
  • # 리버스 프록시 설정시 URL rewrite
    - https://serverfault.com/questions/379675/nginx-reverse-proxy-url-re

×