NGINX로 PHP 7 성능 극대화하기, 2부: 다중 서버 및 로드 밸런싱

PHP는 널리 사용되는 많은 프레임워크 및 콘텐츠 관리 시스템(CMS)에 사용되는 프로그래밍 언어입니다. 가장 인기 있는 두 가지 PHP 기반 CMS인 WordPress 및 Drupal에 대한 특정 기사가 있습니다.

목차

1. 여러 서버를 사용해야 하는 경우
2. 1단계 – 업그레이드 전략 결정
3. 2단계 – 리버스 프록시 서버 선택
4. 3단계 – 리버스 프록시 서버 구현 <-> PHP Servers
5. 4단계 – URL rewrite
6. 5단계 – 로드 밸런싱 및 세션 지속성 구현
7. 보너스 섹션 – NGINX PHP 모니터링 및 관리
8. PHP 2부 결론

1. 여러 서버를 사용해야 하는 경우

이 블로그 포스트의 첫 번째 파트는 웹 서버와 PHP 애플리케이션이 단일 서버 또는 가상 머신 인스턴스를 공유하는 단일 서버 구현에서 PHP 웹 서버 성능을 최대화하는 방법을 다룹니다. 또한 단일 서버 또는 다중 서버 환경에서 구현할 수 있는 NGINX 캐싱에 대해서도 다룹니다.

제1부에서 설명한 대로, 단일 서버 시스템의 경우 PHP 7로 업그레이드하고 Apache에서 NGINX로 이동하는 것이 모두 성능을 최대화하는 데 도움이 됩니다. 정적 파일 캐싱과 마이크로캐싱은 여기에서 설명한 대로 단일 서버 설정이나 멀티 서버 설정 모두에서 성능을 최대화하는 데 도움이 됩니다. 매우 대략적인 추정으로 단일 서버 최적화는 단일 서버에서 성능을 몇 배 향상시킬 수 있습니다. 두 배, 네 배, 혹은 어쩌면 한 숫자 차이로 성능을 향상시켜 트래픽 부하 증가로 인한 과부하를 방지할 수 있습니다.

하지만 이보다 더 많은 성장이 필요할 수도 있습니다. 또한 기존 설정을 변경하지 않고 해결할 수 있는 방법이 필요할 수도 있습니다. 이러한 설명 중 하나라도 해당된다면, 여러 서버를 사용하는 구현으로 전환해야 합니다. 단일 서버 최적화와는 달리 기존 설정의 구성 변경과 구현에 대해 특별히 신경 쓰지 않으며, 대신 하나의 애플리케이션 서버를 전력 발전소의 한 동력 발전기로 취급하여 전 세계 수준의 요구를 처리할 수 있도록 확장하는 것에 집중합니다. 이 작업은 상상력이 더 필요하며, 구현의 세부 사항과 함께 디자인에 관한 것입니다.

여러 서버 구성으로 전환하는 것은 NGINX Open Source 대신 NGINX Plus를 고려하는 좋은 시기이기도 합니다. 각각의 중요한 특징은 다음과 같습니다:

  • NGINX Open Source는 커뮤니티 지원, 널리 사용되는 오픈 소스 코드와 빌드된 배포판, 시스템 관리자들에게 잘 이해되고 있으며 (전체적으로는 아니지만) 무료로 사용할 수 있는 장점들을 가지고 있습니다.
  • NGINX Plus는 NGINX Open Source의 모든 장점에 더하여 이진 배포, 전문적인 지원, NGINX 엔지니어 접근, 고급 로드 밸런싱 (HTTP, TCP, UDP), 세션 유지, 어플리케이션 상태 확인, 스트리밍 미디어 배포, 실시간 활동 모니터링 등을 포함한 추가 기능들이 있습니다. 또한 유료 구독 제품으로, 인스턴스 단위 또는 규모/사용자 정의 가격으로 이용할 수 있습니다.

NGINX Plus의 기능 이점은 단일 서버 설정에 확실히 바람직하지만 여러 서버에 거의 필수 불가결합니다.

  • 전문적인 지원. NGINX Plus 구독자에게만 제공되는 전문적인 지원은 더 복잡한 구성과 대규모 사용자 기반에서 더욱 중요해집니다.
  • NGINX 컨설팅 지원. NGINX Plus 구독으로 컨설팅 지원을 받을 수 있습니다. 이는 두 버전 모두에 사용 가능하지만, NGINX Plus의 안정적인 배포판과 더 고급 기능과 함께 적용될 때 더욱 효과적입니다.
  • 미리 컴파일된 소프트웨어 배포판. 사용 준비가 된 배포판은 지원을 용이하게 하며, 문제를 줄이고 문제가 발생할 경우 조사해야 할 위치를 줄여줍니다.
  • 추가 로드 밸런싱 방법과 세션 유지. 이러한 기능들은 대규모, 활발한 사이트의 효과적인 운영에 꼭 필요한 기능입니다.
  • 모니터링과 관리. NGINX Plus의 시스템 관리 기능은 수십만, 수백만 또는 수백만 명의 사용자를 지원하는 다중 서버 구성에서 명백히 필수적입니다.
  • 상태 확인. 내장된 서버의 활성 질의로 문제를 식별하고 사용자에게 영향을 미치기 전에 해커 공격을 경고하여 충돌, 사용자 세션 손실 및 다운타임을 원활하게 예방할 수 있습니다.

마지막으로, 가장 크고 효율적인 사이트들은 비교적 급진적인 방법을 사용하여 사전에 다운타임을 예방하고 있습니다. 예를 들어, Netflix는 자체 웹 사이트 서버를 무작위로 개별적으로 또는 조합하여 고의로 공격하는 봇(Bot)을 사용하여 사이트 아키텍처의 자가 치유 능력을 테스트합니다. 이러한 유형의 복구력과 견고성은 귀하의 사이트가 추구해야 할 방향입니다.

미리 컴파일된 배포판, 전문적인 지원 및 추가 기능으로 인한 시간 절약은 사이트 개발 및 지원 직원들이 높은 수준의 문제를 해결하고 성장을 계획하는 데 자유로워지도록 도와줍니다.

여기 2부에서는 다중 서버 구현으로 이동하여 처리량에서 최대 10배 이상의 큰 성능 변화를 구현하기 위해 취할 수 있는 단계를 설명합니다.

2. 1단계 – 업그레이드 전략 결정

1단계는 사이트 성능을 향상시키기 위해 어떤 단계를 어떤 순서로 진행할지 결정하는 것입니다. 불편하게 느껴질 수 있지만, 기존 단일 서버 구성 업그레이드와 여러 서버 구현으로의 전환은 별개이고 독립적인 결정입니다. 또한 각 그룹의 변경 사항 내에서의 단계들도 크게 독립적인 결정입니다.

  • 컴퓨팅 전반적으로 “최신과 최고”와 함께 작업하는 강력한 동기가 있습니다. 이는 사용하는 PHP 버전, 애플리케이션을 지원하기 위해 선택한 웹 서버, 고성능 캐싱 구현 등에 해당할 수 있습니다. 이러한 최적화를 위한 동기는 Part 1에서 소개한 단계들을 먼저 구현하는 것을 주장합니다. 이들 단계를 모두 실행하는 것이 가장 바람직하다고 할 수 있습니다.
  • 하지만 때로는 애플리케이션, NGINX PHP 구성, 중요한 모듈 등을 rewrite, 테스트 및 (재)배포하는 데 드는 시간과 노력이 그다지 가치가 없는 경우도 있습니다. 이러한 경우에는 기존 단일 서버 구성을 거의 또는 전혀 변경하지 않고 여러 서버 구성으로 전환할 수 있습니다. 여러 개의 애플리케이션 서버가 필요한 경우 Part 2에서 설명한 대로 현재의 단일 서버 구성을 복제하기만 하면 되며, 필요하다면 최적화를 적용할 때까지 해당 구성을 유지할 수 있습니다.

만약 새로운 “greenfield” 애플리케이션을 시작하는 경우, Part 1에서 설명한 단일 서버 및 캐싱 최적화와 Part 2에서 설명한 여러 서버 및 로드 밸런싱 기술을 하나의 종합적인 할 일 목록으로 사용해야 합니다. 그러나 기존의 애플리케이션을 수정하는 경우, 특히 성능 압력 아래에서 작업하는 경우 – 트래픽 증가, 제한된 시간, 예산 및 인력 등으로 인해 – 단일 서버 및 여러 서버 구현 기법에서 필요한 것들을 선택하여 성능 요구사항과 기능 요구사항을 항상 한 발 앞서 나갈 수 있습니다.

정확히 어떻게 선택해야 하는지를 정확히 알려드릴 수 없습니다. 각 상황은 “sui generis”이며 (라틴어로 “유일한”을 의미합니다), 독특한 특성을 가지고 있습니다. 여러분의 사이트가 직면한 특정 성능적 도전과 여러분이 갖고 있는 지식, 시간, 자원 등과 비교하여 여기에서 설명한 각 최적화 기법을 신중하게 고려함으로써 상당히 좋은 아이디어를 얻을 수 있습니다. 또한 이러한 결정을 내리고 구현하는 데 도움을 받는 것이 가치가 있는지도 결정하실 수 있습니다. 그렇다면, 앞서 언급한 대로 NGINX는 컨설팅 패키지를 제공하며, 단기적으로는 시간 대 비용 균형을 잘 맞추는 좋은 선택일 수 있으며 장기적으로는 가치 있는 프레임워크, 지식 및 기술 스킬을 제공할 수 있습니다.

1부 이하의 단계를 나열된 순서대로 또는 요구 사항에 가장 잘 맞는 순서대로 사용하십시오.

3. 2단계 – 리버스 프록시 서버 선택

리버스 프록시 서버는 웹 클라이언트(예: Safari 또는 Chrome와 같은 브라우저)로부터 요청을 받아들이고, 이후 처리를 위해 NGINX PHP 서버, Apache PHP 서버 또는 기타 서버 등 하나 이상의 애플리케이션 서버로 배포하는 서버입니다. 리버스 프록시 서버는 다른 서버로부터 응답을 받아와 해당 응답을 클라이언트에게 다시 전송합니다. (NGINX 웹 사이트에서 더 자세한 리버스 프록시 서버의 정의를 찾아볼 수 있습니다.)

클라이언트는 리버스 프록시 서버만 “보이게” 됩니다. 그들에게는 리버스 프록시 서버가 해당 사이트인 것처럼 보입니다. 그러나 뒷단에서는 다양한 마법같은 일들이 발생할 수 있습니다. 리버스 프록시 서버를 사용하는 것은 컴퓨터 과학에서 가장 유명한 말들 중 하나인 David Wheeler의 말처럼 “모든 컴퓨터 과학 문제는 또 다른 간접성의 수준으로 해결될 수 있다”는 말의 또 다른 예시입니다.

리버스 프록시 서버를 사용하는 이유는 무엇입니까? 두 가지 주요 이유가 있습니다.

  • 성능. 단일 애플리케이션 서버에 하나의 리버스 프록시 서버를 추가함으로써 일반적으로 성능이 향상됩니다. 리버스 프록시 서버와 애플리케이션 서버 사이에서 요청과 응답이 흐를 때 추가적인 지연이 발생하지만, 이러한 통신은 대개 LAN에서 서로 인접한 두 기기 간에 매우 낮은 지연(latency)을 가지고 진행됩니다. 동시에 애플리케이션 서버는 피크 시간에 훨씬 빠르게 실행되므로 과부하가 걸리기 어려워져 사이트 성능이 뚜렷하게 향상됩니다.
  • 확장성. 리버스 프록시 서버를 사용하면 여러 애플리케이션 서버를 추가할 수 있으며, 캐싱을 리버스 프록시 서버로 이동하여 애플리케이션 서버의 부담을 줄일 수 있으며, 저장소 배열이나 콘텐츠 전송 네트워크와 쉽게 통합할 수 있습니다. 이러한 방식으로 사이트는 거의 임의로 확장 가능하며, 확장 시 예측 가능한 성능을 유지할 수 있습니다.

추가적인 이점들이 있습니다. 보안이 향상됩니다. 인터넷 트래픽만 처리하는 단일 기기에 보안 노력을 집중할 수 있기 때문입니다. 또한 NGINX는 리버스 프록시 서버로 구현하든지, 애플리케이션 서버에서 Apache를 대체하든지, 또는 둘 다로 구현하든지에 상관없이 여러 보안 장점을 가지고 있습니다. 더불어 시스템 가동 시간(uptime)이 향상될 가능성이 있습니다. 보안 향상으로 얻는 이점 외에도 필요에 따라 유연하게 서버를 추가하거나 교체할 수 있고, 어떠한 리소스도 중단 없이 “핫-스왑(hot-swappable)”으로 복제할 수 있기 때문입니다. 심지어 리버스 프록시 서버 자체도 이러한 방법으로 구성할 수 있습니다.

물론, 두 번째 서버를 사용하거나 추가적인 서버를 사용하는 데는 비용이 발생합니다. 그러나 물리적 서버나 클라우드 인스턴스 접근 비용은 종종 성능 요구를 충족하지 못하는 단일 서버 구성을 최적화하고 관리하는 데 소요되는 시간 비용에 비해 미비합니다. 또한 단일 서버를 사용하여 하드웨어 비용을 최소화하는 동안 성능이나 트래픽과 같은 기회 비용과 평판적 비용이 발생할 수 있습니다. 즉, 고객 요청, 거래 시도 등이 처리되지 않을 수 있습니다. 오늘날 대부분의 조직은 성공을 위한 주요 요소로 하드웨어 비용이나 인스턴스 당 비용이 아닌 소프트웨어 및 인력 비용을 인식하고 있습니다.

NGINX는 여러 서버 모델리티들을 건너서 도구로서 사용할 수도 있습니다. 즉, NGINX를 내부 서버, 개별적인 개인 클라우드 인스턴스(다른 개인 클라우드), 공용 클라우드 인스턴스(다른 공용 클라우드) 및 원하는 모든 혼합 환경과 연결하고 웹 서버로서 사용할 수 있습니다. 민첩한 NGINX 시스템 관리자는 필요에 따라 구현을 쉽게 조정하여 완전히 다른 모습과 기능으로 작동할 수 있으며, 락인(lock-in) 우려가 줄어듭니다.

4. 3단계 – 리버스 프록시 서버 구현 <-> PHP Servers

PHP 애플리케이션 서버용 NGINX Plus 리버스 프록시 서버를 실행하면 로드 밸런싱을 통해 PHP 7 성능이 향상됩니다.

다른 NGINX 서버와 같은 HTTP 서버 또는 PHP를 실행하는 서버와 같은 HTTP가 아닌 서버로 요청을 프록시할 수 있습니다. FastCGI, Memcached, SCGI 및 uWSGI는 가장 널리 사용되는 지원 프로토콜 중 일부입니다.

NGINX 구성의 핵심은 server 블록 내부에서 지정하는 listen 지시문입니다.

upstream backend {
    server php-app1.example.com;
    server php-app2.example.com;
}

server {
  listen 80;
  server_name www.example.com;
  # enforce HTTPS
  return 301 https://$server_name$request_uri;
}

server {
  listen 443 ssl;
  server_name www.example.com;

   location /some/path/ {
      proxy_pass http://backend;
}

아파치(Apache)에 경험이 있다면, NGINX 서버 구성은 단지 새로운 시스템이기 때문에 처음에는 어려울 수 있습니다. 하지만 서버 구성에 익숙한 사람들은 NGINX 구성을 배운 후에는 빠르고 쉽고 합리적이라고 설명하는 경우가 많습니다. 그러나 처음 해보는 것은 항상 학습 곡선이 있습니다.

NGINX 웹사이트에서는 NGINX 오픈 소스 및 NGINX Plus에 대한 자세한 구성 지침을 찾을 수 있으며, 특히 NGINX Plus의 경우 구체적인 구성도 제공됩니다. 또한 “PHP NGINX 구성”과 같은 검색어로 검색하면 시작하는 데 유용한 제3자 리소스 세트를 찾을 수 있습니다. 또한 NGINX 커뮤니티를 방문하거나, NGINX Plus 고객의 경우 NGINX Plus 지원을 받을 수도 있습니다.

5. 4단계 – URL rewrite

모든 웹사이트에서 URL을 다시 작성(Rewrite)하는 것이 바람직하므로 다음과 같은 몇 가지 목표를 달성할 수 있습니다.

  • 더 짧게. 짧은 URL은 읽기 쉬우므로 사이트 사용은 물론 개발도 더 쉬워집니다. URL을 단축하면 입력 필드의 길이 제한, 버퍼 오버플로 등을 방지할 수도 있습니다.
  • 읽기 가능. 사용자가 쉽게 읽고 이해할 수 있는 URL은 사용자를 안심시키고 쉽게 공유할 수 있지만 일부 사이트에서는 노력하지 않습니다.
  • 예측 가능. 사용자는 사이트의 정신적 모델을 구축하고 URL에 반영될 것으로 기대합니다. 사이트 섹션은 URL 내의 하위 디렉토리로 표시되고 웹 페이지 및 자산(예: PDF 파일)에 대한 합리적인 파일 이름입니다.
  • 안정적인. 개별 웹 페이지 및 사이트 자산에 대한 기존 하이퍼링크를 끊지 않고 사이트 아키텍처 또는 사이트 자산의 위치를 변경할 수 있습니다.

아파치에서는 mod_rewrite 모듈을 사용하여 URL을 rewrite할 수 있습니다. 이 작업은 .htaccess(하이퍼텍스트 액세스) 파일에서 이루어집니다. .htaccess 파일은 디렉토리 수준에서 동작하는 설정 파일로, 하위 파일은 상위 파일을 보완하거나 덮어쓸 수 있습니다. 이러한 특성은 강력하면서도 혼동스러울 수 있습니다. 많은 아파치 사용자는 다른 서버 설정에서 기존 구성을 상속받으며, 변경 사항을 가할 때 운이나 기술 능력에 의존하기도 합니다.

NGINX에서는 rewrite 지시문을 대신 사용합니다. Rewrite 지시어는 Apache 접근 방식보다 더 간단하고 강력하며 유지 관리하기 쉽지만 새로운 것과 마찬가지로 (짧은) 학습 곡선이 있습니다. NGINX에서 새 rewrite 규칙 생성에 대한 이 블로그 포스트와 Apache 재작성 규칙을 NGINX로 변환하는 방법에 대한 이 포스트을 참조하세요.

다음은 rewrite 지시문을 사용하는 샘플 NGINX rewrite 규칙입니다. 문자열 /download로 시작하고 경로의 뒷부분에 /media/ 또는 /audio/ 디렉토리를 포함하는 URL과 일치합니다. 해당 요소를 /mp3/로 바꾸고 적절한 파일 확장자 .mp3 또는 .ra를 추가합니다. $1 및 $2 변수는 변경되지 않는 경로 요소를 캡처합니다. 예를 들어 /download/cdn-west/media/file1은 /download/cdn–west/mp3/file1.mp3이 됩니다. 파일 이름에 확장자가 있는 경우(예: .flv) 표현식은 확장자를 제거하고 .mp3로 바꿉니다.

server {
    # ...
    rewrite ^(/download/.*)/media/(\w+)\.?.*$ $1/mp3/$2.mp3 last;
    rewrite ^(/download/.*)/audio/(\w+)\.?.*$ $1/mp3/$2.ra  last;
    return  403;
    # ...
}

6. 5단계 – 로드 밸런싱 및 세션 지속성 구현

웹 사이트의 확장성은 2차원으로 나눌 수 있습니다. 첫째는 수직적 확장성(vertical scalability)으로, 이는 소프트웨어 변경(1부에서 설명한 내용과 같이)이나 더 빠른 서버 또는 서버 인스턴스 구매로 하나의 서버에서 더 많은 성능을 얻는 것을 의미합니다. 둘째는 수평적 확장성(horizontal scalability)으로, 이는 여러 대의 서버(특히 여러 애플리케이션 서버)를 추가하는 것을 의미합니다.

3단계에서 설명한 대로 리버스 프록시 서버를 구현하면 여러 애플리케이션 서버를 사용할 수 있어 수평적 확장성을 얻을 수 있습니다. 성능을 높이기 위해 단순히 서버를 추가하면 됩니다. 또한 리버스 프록시 서버에서 스토리지 요청을 집중화하거나 서버 풀이나 콘텐츠 전송 네트워크를 사용하여 SSL/TLS 및 HTTP/2를 리버스 프록시 서버에서 termination할 수 있습니다. NGINX Plus와 같은 적절한 소프트웨어 도구를 사용하면 서버를 추가하거나 제거하는 작업을 전혀 다운타임 없이 수행할 수 있습니다.

PHP 7 성능 향상을 위해 NGINX로 PHP 서버 로드 밸런싱

이제 여러 애플리케이션 서버를 추가하자마자 두 가지 기능이 매우 중요해집니다.

  • 로드 밸런싱. 각각의 새 요청이 가장 적게 사용되는 서버로 이동하여 더 빨리 처리되기를 원합니다. 어떤 서버도 전체 사이트에 장애가 되지 않습니다. NGINX Plus는 NGINX 오픈 소스보다 더 복잡한 로드 밸런싱 알고리즘을 가지고 있으며 둘 다 서버 가중치에 대한 지원을 포함합니다. NGINX Plus를 사용하면 다운타임 없이 동적으로 재구성할 수도 있습니다.
  • 세션 지속성. 로그인 또는 구매 데이터와 같은 애플리케이션 서버에서 사용자의 상태를 유지하는 경우 – 이 라이브 데이터를 중앙에서 보유할 수도 있습니다. 사용자 세션 전체에서 동일한 애플리케이션 서버로 다시 전송됩니다. 세션 지속성은 NGINX Plus에만 포함됩니다.

서버 가중치는 여러 가지 로드 밸런싱 방법과 함께 작동하는 기능입니다. 서버의 가중치(기본 가중치는 1)를 늘려 해당 서버로 이동하는 요청 수를 늘릴 수 있습니다.

다음 코드는 backend1.example.com에 대한 server 지시문의 가중치 매개변수를 보여줍니다.

upstream backend {
    server backend1.example.com weight=5;
    server backend2.example.com;
    server 192.0.0.1 backup;
}

NGINX Plus는 세션 지속성을 수행하는 몇 가지 방법을 지원하며 이를 수행하는 쉬운 방법 중 하나는 “sticky learn” 방법입니다. 이 방법은 PHP 앱에서 일반적으로 설정하는 PHPSESSIONID 쿠키를 활용합니다. 이 방법을 사용하면 NGINX가 응답에서 서버에 의해 설정된 이 쿠키를 확인하면 이 동일한 쿠키를 사용하는 후속 요청이 동일한 PHP 서버로 다시 전송됩니다.

upstream backend {
   server webserver1;
   server webserver2;

   sticky learn create=$upstream_cookie_phpsessionid
       lookup=$cookie_phpsessionid
       zone=client_sessions:1m
       timeout=1h;
}

이 방법을 사용하면 PHPSESSIONID를 사용할 필요가 없습니다. 원하는 쿠키를 제거할 수 있습니다.

7. 보너스 섹션 – NGINX PHP 모니터링 및 관리

여러 애플리케이션 서버, 로드 밸런싱, 세션 지속성을 설정한 후에는 관리와 모니터링이 중요해집니다. NGINX Plus를 사용하면 액티브 헬스 체크(active health checks)를 통해 서버의 문제를 미리 경고 받을 수 있습니다. 단순히 서버가 작동 중인지 아닌지를 확인하는 것 이상으로, 만약 서버가 잘못된 내용을 출력하고 있다면, NGINX Plus는 이를 감지하고 이상한 서버로 트래픽을 배포하지 않습니다.

NGINX Plus에는 시스템의 상태를 모니터링하는 내장 대시보드가 있습니다. 이 대시보드는 전체 트래픽 흐름을 모니터링하고, 개별 서버의 성능을 자세히 확인할 수 있는 다양한 데이터를 제공합니다. 이를 통해 전반적인 애플리케이션의 트래픽 상태를 파악하고, 각 개별 서버의 동작 상태를 확인할 수 있습니다.

PHP 7 성능이 향상된 NGINX Plus를 사용하여 PHP 애플리케이션 서버에 대한 모니터링 및 로드 밸런싱 관리

NGINX Plus는 Python 애플리케이션 서버에 대한 모니터링 및 관리를 제공합니다.

NGINX Plus 통계는 JSON 형식으로도 내보낼 수 있습니다. 이 데이터를 Data Dog 또는 New Relic과 같은 모니터링 도구 또는 사용자 지정 모니터링 도구로 내보낼 수 있습니다.

8. PHP 2부 결론

PHP는 사용하기 쉽고 매우 능력이 있는 언어로서, 웹 사이트와 웹 애플리케이션의 증가로 인해 디지털 혁명을 촉진하는 주요 요소입니다. 높은 성능을 제공하는 PHP 7은 웹 사이트의 속도, 성능, 보안, 관리 기능에 대한 새로운 기대를 불러일으킬 것입니다.

PHP 7로 사이트의 코드를 단순히 전환하는 것 외에도, 사이트의 성능을 향상시키기 위해 가장 강력하고 널리 사용되는 전략은 대부분 NGINX의 사용을 포함합니다. 두 개의 블로그 포스트에서는 단일 서버 환경에서 사용 가능한 기능과 캐싱 기술, 그리고 다중 서버 환경에서 사용 가능한 기능을 설명합니다.

어디서 시작할지는 여러분에 달려있지만, 점점 더 많은 트래픽을 처리하는 사이트는 아마도 PHP 7로 rewrite하거나 새로 작성한 앱을 NGINX를 사용하여 서버 수준과 리버스 프록시 서버에서 실행하고, 여러 애플리케이션 서버와 로드 밸런싱, 콘텐츠 전송 네트워크, 관리 및 모니터링을 도입할 것입니다. 이는 PHP로 쉽게 만들고 시작할 수 있는 단일 서버 구현보다 복잡성과 기능면에서 큰 발전을 이뤄낼 것입니다.

NGINX Plus를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 문의하십시오.

NGINX에 대한 최신 정보들을 빠르게 전달받고 싶으시다면, 아래의 뉴스레터를 구독하세요.