머리말

2016 년 업데이트. 상황이 발전하고 모든 서버가 개선되고 있으며 모두 SSL을 지원하며 웹이 그 어느 때보 다 놀랍습니다.

언급되지 않은 한, 다음은 비즈니스 및 신생 전문가를 대상으로하며 수천에서 수백만 명의 사용자를 지원합니다.

이러한 도구와 아키텍처에는 많은 사용자 / 하드웨어 / 돈이 필요합니다. 홈 랩에서 시도하거나 블로그를 운영 할 수는 있지만 그다지 의미가 없습니다.

일반적으로 간단하게 유지하고 싶다는 것을 기억하십시오 . 추가 된 모든 미들웨어는 유지해야 할 또 다른 중요한 미들웨어입니다. 추가 할 것이없고 제거 할 것이없는 경우에는 완벽이 달성되지 않습니다.

일반적이고 흥미로운 배포

HAProxy (밸런싱) + nginx (php 애플리케이션 + 캐싱)

웹 서버는 PHP를 실행하는 nginx입니다. nginx가 이미 있으면 캐싱 및 리디렉션을 처리 할 수도 있습니다.

HAProxy ---> nginx-php
A       ---> nginx-php
P       ---> nginx-php
r       ---> nginx-php
o       ---> nginx-php
x       ---> nginx-php
y       ---> nginx-php

---

HAProxy (밸런싱) + Varnish (캐싱) + Tomcat (Java 애플리케이션)

HAProxy는 요청 URI (*. jpg * .css * .js)를 기반으로 니스로 리디렉션 할 수 있습니다.

HAProxy ---> tomcat
A       ---> tomcat
        ---> tomcat
P       ---> tomcat <----+
r       ---> tomcat <---+|
o                       ||
x       ---> varnish <--+|
y       ---> varnish <---+

---

HAProxy (밸런싱) + nginx (호스트에 대한 SSL 및 캐싱) + 웹 서버 (애플리케이션)

모두가 SSL을 말해야하지만 웹 서버는 SSL을 사용하지 않습니다 ( 특히 EC2를 통해 진행되는 개인 사용자 정보와의 HAProxy-WebServer 링크 ). 로컬 nginx를 추가하면 SSL을 호스트로 가져올 수 있습니다. nginx가 있으면 캐싱 및 URL 재 작성도 수행 할 수 있습니다.

참고 : 포트 리디렉션 443 : 8080이 발생하지만 기능의 일부는 아닙니다. 포트 리디렉션을 수행 할 필요가 없습니다. 로드 밸런서는 웹 서버 : 8080과 직접 통신 할 수 있습니다.

          (nginx + webserver on same host)
HAProxy ---> nginx:443 -> webserver:8080
A       ---> nginx:443 -> webserver:8080
P       ---> nginx:443 -> webserver:8080
r       ---> nginx:443 -> webserver:8080
o       ---> nginx:443 -> webserver:8080
x       ---> nginx:443 -> webserver:8080
y       ---> nginx:443 -> webserver:8080

미들웨어

HAProxy : 로드 밸런서

주요 특징 :

• 로드 밸런싱 (TCP, HTTP, HTTPS)
• 다중 알고리즘 (라운드 로빈, 소스 IP, 헤더)
• 세션 지속성
• SSL 종료

비슷한 대안 : nginx를 (로드 밸런서로 구성 다목적 웹 서버)
다른 대안 : 클라우드 (아마존의 ELB, 구글 부하 분산), 하드웨어 (F5, 포티넷, 시트릭스 넷 스케일러), 기타 및 전세계 (DNS, 애니, CloudFlare)

HAProxy는 무엇을하고 언제 사용합니까?
로드 밸런싱이 필요할 때마다. HAProxy는 솔루션으로 이동합니다.

를 제외하고 당신이 사용할 수있는 능력이 없거나 아주 싼 또는 빠른 & 더러운 할 때, 당신은 ELB를 사용할 수 있습니다 : D를

은행 / 정부 / 유사에서 까다로운 요구 사항 (전용 인프라, 신뢰할 수있는 장애 조치, 방화벽 2 계층, 감사 항목, SLA 1 분당 중단 시간 x %를 모두 지불해야하는 SLA)이있는 자체 데이터 센터를 사용해야하는 경우를 제외하고 30 대의 응용 프로그램 서버가있는 랙 위에 2 F5를 넣을 수 있습니다.

100k HTTP (S) [및 다중 사이트]를 지나고 싶은 경우를 제외하고 는 (전역)로드 밸런싱 계층 (cloudflare, DNS, 애니 캐스트) 이있는 다중 HAProxy가 있어야 합니다. 이론적으로, 글로벌 밸런서는 웹 서버와 직접 통신하여 HAProxy를 버릴 수 있습니다. 그러나 일반적으로 HAProxy를 데이터 센터의 공개 진입 점으로 유지하고 호스트간에 균형을 맞추고 분산을 최소화하도록 고급 옵션을 조정해야합니다.

개인적 의견 : 작고 포함 된 오픈 소스 프로젝트로서 전적으로 하나의 진정한 목적에 전념합니다. 가장 쉬운 구성 (ONE 파일) 중에서 가장 유용하고 신뢰할 수있는 오픈 소스 소프트웨어는 제 인생에서 찾아 왔습니다.

Nginx : 아파치하지 않는 Apache

주요 특징 :

• 웹 서버 HTTP 또는 HTTPS
• CGI / PHP / 다른 응용 프로그램에서 응용 프로그램 실행
• URL 리디렉션 / 다시 쓰기
• 액세스 제어
• HTTP 헤더 조작
• 캐싱
• 리버스 프록시

비슷한 대안 : Apache, Lighttpd, Tomcat, Gunicorn …

Apache는 사실상 요청 된 웹 서버 httpd.conf아키텍처 위에 수십 개의 모듈과 수천 줄의 거대한 클러스터로 알려진 사실상의 웹 서버 였습니다. nginx는 더 적은 모듈로 (약간) 더 간단한 구성과 더 나은 코어 아키텍처로 모든 것을 다시 실행합니다.

nginx는 무엇을하며 언제 사용해야합니까?
웹 서버는 응용 프로그램을 실행하기위한 것입니다. 응용 프로그램이 nginx에서 실행되도록 개발되면 이미 nginx가 있으며 모든 기능을 사용할 수도 있습니다.

응용 프로그램이 nginx에서 실행되도록 설계되지 않았고 nginx가 스택 (Java shop 누구?)에서 찾을 수없는 경우를 제외하고 는 nginx에 작은 점이 있습니다. 웹 서버 기능은 현재 웹 서버에있을 가능성이 높으며 다른 작업은 적절한 전용 도구 (HAProxy / Varnish / CDN)로 처리하는 것이 좋습니다.

제외 웹 서버 / 응용 프로그램 기능을 결여 될 때, 하드 구성 및 / 또는 당신이 오히려 (사람을 Gunicorn?) 그것을보고보다 일을 죽을 것, 당신은 URL을 수행 할 (즉, 로컬로 각 노드에서) 앞에서 nginx를 넣을 수 있습니다 다시 쓰기, 301 리디렉션 전송, 액세스 제어 시행, SSL 암호화 제공 및 HTTP 헤더 편집 기능 [이것은 웹 서버에서 예상되는 기능입니다]

바니시 : 캐싱 서버

주요 특징 :

• 캐싱
• 고급 캐싱
• 세밀한 캐싱
• 캐싱

비슷한 대안 : nginx (캐싱 서버로 구성 가능한 다목적 웹 서버)
다른 대안 : CDN (Akamai, Amazon CloudFront, CloudFlare), 하드웨어 (F5, Fortinet, Citrix Netscaler)

바니시는 무엇을하고 언제 사용해야합니까?
캐싱 만 수행하고 캐싱 만 수행합니다. 일반적으로 노력할 가치가 없으며 시간 낭비입니다. 대신 CDN을 사용해보십시오. 캐싱은 웹 사이트를 실행할 때 마지막으로주의해야합니다.

사진이나 비디오에 대한 웹 사이트를 독점적으로 운영하는 경우를 제외하고 는 CDN을 철저히 조사하고 캐싱에 대해 진지하게 고려해야합니다.

를 제외하고 당신이 당신의 자신의 데이터 센터에서 자신의 하드웨어를 사용하도록 강요하고 (CDN이 옵션을 선택하지 않습니다)와 웹 서버가 정적 파일 (도움이되지 않는 많은 웹 서버를 추가) 제공에 끔찍한 때 다음 니스는 최후의 수단이다.

정적이면서도 복잡한 동적으로 생성 된 콘텐츠가있는 사이트를 제외하고 (다음 단락 참조) Varnish는 웹 서버에서 많은 처리 능력을 절약 할 수 있습니다.

2016 년 정적 캐싱이 과대 평가되었습니다

캐싱은 거의 구성이 필요없고 돈이 없으며 시간이 없습니다. CloudFlare 또는 CloudFront 또는 Akamai 또는 MaxCDN을 구독하십시오. 이 라인을 작성하는 데 걸리는 시간은 캐싱을 설정하는 데 걸리는 시간보다 길고, 보유중인 맥주는 CloudFlare 중앙값 구독보다 비쌉니다.

이러한 모든 서비스는 정적 * .css * .js * .png 이상에서 즉시 작동합니다. 실제로, 이들은 주로 Cache-ControlHTTP 헤더 의 지시문을 준수합니다. 캐싱의 첫 번째 단계는 웹 서버가 올바른 캐시 지시문을 보내도록 구성하는 것입니다. 어떤 CDN, 어떤 바니시, 어떤 브라우저가 중간에 있는지는 중요하지 않습니다.

성능 고려 사항

바니시는 일반 웹 서버가 블로그에서 고양이 그림을 제공하기 위해 질식했을 때 만들어졌습니다. 오늘날 현대적인 멀티 스레드 비동기식 버즈 워드 기반 웹 서버의 단일 인스턴스는 새끼 고양이를 전국에 안정적으로 제공 할 수 있습니다. 의례 sendfile().

내가 작업 한 마지막 프로젝트에 대한 빠른 성능 테스트를 수행했습니다. 단일 Tomcat 인스턴스는 HTTP를 통해 초당 12,000-35,000 개의 정적 파일을 제공 할 수 있습니다 (다양한 HTTP / 클라이언트 연결 수로 20B에서 12kB까지 파일 테스트). 지속적 아웃 바운드 트래픽은 2.4Gb / s를 초과합니다. 프로덕션에는 1Gb / s 인터페이스 만 있습니다. 하드웨어보다 더 잘할 수 없으며 바니시를 시도해도 아무런 의미가 없습니다.

복잡한 동적 컨텐츠 변경 캐싱

CDN 및 캐싱 서버는 일반적으로와 같은 매개 변수를 사용하여 URL을 ?article=1843무시하고 세션 쿠키 또는 인증 된 사용자의 요청을 무시하며 application/jsonfrom을 포함한 대부분의 MIME 유형을 무시합니다 /api/article/1843/info. 사용 가능한 구성 옵션이 있지만 일반적으로 “모두”또는 “아무 것도 아닌”세분화되지는 않습니다.

니스는 캐싱 ​​가능한 것과 그렇지 않은 것을 정의하기 위해 사용자 지정 복잡한 규칙 (VCL 참조)을 가질 수 있습니다. 이 규칙은 URI, 헤더 및 현재 사용자 세션 쿠키 및 MIME 유형 및 컨텐츠를 모두 기준으로 특정 컨텐츠를 캐시 할 수 있습니다. 이는 매우 특정한로드 패턴에 대해 웹 서버에서 많은 처리 능력을 절약 할 수 있습니다. 그때는 니스가 편리하고 굉장합니다.

결론

이 모든 조각을 언제, 언제 사용해야하는지, 어떻게 함께 맞추는 지 이해하는 데 시간이 걸렸습니다. 이것이 당신을 도울 수 있기를 바랍니다.

꽤 길다 (6 시간 쓰기. OMG! : O). 어쩌면 나는 그것에 관한 블로그 나 책을 시작해야 할 것입니다. 재미있는 사실 : 답의 길이에는 제한이없는 것 같습니다.

---

답변