NGINX로 PHP 7 성능 극대화하기, 1부: 웹 서비스 및 캐싱

PHP 기반 애플리케이션에서는 상대적으로 간단한 변경으로 성능을 향상시킬 수 있습니다. 이러한 변경 사항에는 memcached와 같은 캐싱 도구를 사용한 캐싱, 데이터베이스 튜닝, 그리고 NGINX 오픈 소스와 NGINX Plus를 사용한 리버스 프록시와 로드 밸런싱 등이 포함됩니다. NGINX는 애플리케이션의 응답성을 크게 향상시키며, 사용자 및 트래픽 수를 수십 배 증가시키는 것을 지원합니다.

PHP universe에는 다양한 PHP 프레임워크가 포함되어 있습니다. 가장 인기 있는 것은 Laravel, Phalcon 및 Symfony 2입니다. PHP는 WordPress 및 Drupal과 같은 인기 있는 콘텐츠 관리 시스템(CMS)의 기반이기도 합니다.

PHP팀은 PHP 5 도입 이후 약 10년이 지난 지금, 새로운 버전인 PHP 7을 출시하고 있습니다. 이 기간 동안 웹 사용량과 웹사이트에 대한 요구사항이 모두 기하급수적으로 증가하였습니다. PHP는 이러한 빠른 성장에 기여했지만, 동시에 그것이 가능케 한 성장으로 인해 PHP의 한계도 강조되고 있습니다.

PHP는 일반적으로 강력하고 유연하다고 여겨지지만, 성능 문제에 취약한 경우가 있습니다. PHP 기반의 웹 사이트는 트래픽 수가 몇 배 증가하면 쉽게 “벽에 부딪힐” 수 있습니다. 비즈니스 또는 운영 목표를 달성하기 시작하는 순간, 트래픽 양이 증가하면 사이트가 충돌하기 시작할 수 있습니다.

이 포스트는 PHP 7을 사용하는 웹 사이트의 성능을 극대화하는 데 관한 두 개의 시리즈 중 첫 번째 포스트입니다. 여기서는 PHP 7로 업그레이드하고, 웹 서버 소프트웨어로 NGINX 오픈 소스 또는 NGINX Plus를 구현하며, URL을 다시 작성(Rewrite)하여 요청을 올바르게 처리하도록 하고, 정적 파일을 캐싱 하며, 동적 파일도 캐싱하는 방법에 초점을 맞추고 있습니다. (동적 파일 캐싱은 어플리케이션 캐싱 또는 마이크로캐싱이라고도 합니다.)

다음 포스트에서는 추가 서버를 활용할 수 있는 단계에 초점을 맞춥니다. 이 단계에는 리버스 프록시 서버 추가, 여러 애플리케이션 서버로 이동, 여러 서버 사이의 로드 밸런싱, 로드 밸런싱 시 세션 지속성 지원, SSL/TLS 및 관련 HTTP/2 프로토콜과 같은 보안 프로토콜 종료 등이 포함됩니다.

목차

1. PHP가 벽에 부딪히는 이유
2. 성능 문제 해결
3. 팁 1 – PHP 7로 업그레이드
4. 팁 2 – NGINX 오픈 소스 또는 NGINX Plus 선택
5. 팁 3 – Apache 구성을 NGINX 구문으로 변환
6. 팁 4 – 정적 파일 캐싱 구현
7. 팁 5 – 마이크로캐싱 구현
8. 1부 결론

1. PHP 가 벽에 부딪히는 이유

PHP 애플리케이션이 한계에 부딪히는 이유는 다른 어떤 애플리케이션 서버 소프트웨어가 한계에 부딪히는 이유와 동일합니다. 사용자 요청이 들어오면 PHP와 그 위에서 실행되는 웹 서버 소프트웨어는 여러 가지 작업을 수행해야 합니다:

  • 요청을 해독하십시오. 먼저 웹 서버 소프트웨어와 PHP가 프로세스를 가동하여 요청을 수신하고 해독하고 조치를 취해야 합니다. 예를 들어 Apache HTTP Server는 단순(JPEG 파일 검색) 또는 복잡한(중첩된 CSS 요청 처리) 각 데이터 요청을 처리할 리소스를 할당합니다. 이 모든 작업에는 시간, 시스템 리소스 및 메모리 할당이 필요합니다. OS, PHP 또는 둘 다 요청 처리를 시작하기도 전에 여러 라이브러리를 로드해야 하는 경우 이는 상당히 클 수 있습니다.
  • 지원 프로토콜을 처리합니다. SSL/TLS 및/또는 HTTP/2를 실행하는 경우 웹 서버 소프트웨어는 잠재적으로 시간이 많이 걸리는 프로세스인 요청을 디코딩해야 합니다.
  • 요청에 따라 행동하십시오. PHP는 요청을 처리하기 위해 자원을 모아야 합니다. 이를 위해서는 여러 데이터베이스 호출, 인터넷을 통한 외부 서비스 호출, 복잡한 내부 처리가 필요할 수 있습니다.
  • 요청에 응답합니다. PHP는 HTTP 응답으로 요청자에게 다시 전송하기 위해 웹 서버 소프트웨어에 결과를 return해야 합니다. 웹 서버 소프트웨어와 PHP는 초기 수신에서 최종 확인까지 각 요청에 대해 활성 전용 스레드를 실행하고 있음을 기억하십시오.


물리적 서버, 가상 머신 또는 클라우드 서버 인스턴스에게는 매 요청마다 많은 작업들을 처리해야 합니다. 성능은 서버 기계의 물리적 또는 가상화된 메모리가 고갈되면 저하될 수 있습니다. 이러한 상황에서 서버는 새로운 요청이 들어올 때 현재 세션을 디스크로 페이지 아웃하는 등의 작업을 수행하게 됩니다. 파일 요청이 충족되기를 기다리는 것도 대기 상태를 도입하여 페이지 아웃을 유발할 수 있습니다. 제한된 지점을 지나면 페이지 아웃 작업과 데이터 요청이 처리 작업을 압도하여 성능이 점차 저하되며, 사용자들에게 오랜 대기 시간이나 세션 중단과 같은 불편한 경험을 제공하는 “death spiral”이 발생할 수 있습니다.

2. 성능 문제 해결

PHP의 성능 장벽을 극복하는 것은 확실히 가능하며 몇 가지 보완적인 단계가 필요합니다. 각 단계는 다른 단계와 결합될 수 있습니다. 대략 다음이 포함됩니다.

  • 문제에 하드웨어를 던지십시오. 더 많은 메모리, 더 많은 메모리, 더 빠른 디스크, 별도의 데이터베이스 서버, 콘텐츠 전송 네트워크, 증가된 처리 용량 및 기타 기계적 솔루션은 성능 문제에 대한 빠르고 더러운 솔루션입니다. 이러한 솔루션은 가동 시간을 유지하거나 선형적으로 성능을 확장할 수 있습니다.
  • PHP 및 애플리케이션 코드 개선. 새로운 버전의 PHP, 새로운 프레임워크 및 개선된 애플리케이션 코드는 많은 도움이 될 수 있습니다. 다시 말하지만, 새 하드웨어에 대한 추가 비용 없이 성능을 두 배 또는 네 배로 늘릴 수 있습니다.
  • 향상된 서버 소프트웨어. 대부분의 웹 서버와 PHP는 진행 중인 각 열린 요청에 전용 리소스를 할당합니다. NGINX 서버 소프트웨어는 리소스를 묶지 않고 들어오는 요청을 처리하여 서버 공간을 최소화합니다.
  • 다중 서버 구현. 리버스 프록시 서버를 구현하여 인터넷 요청을 처리하고 하나 이상의 애플리케이션 서버 간에 공유(부하 분산)할 수 있습니다. 리버스 프록시 서버는 또한 파일 캐싱, SSL/TLS 및 HTTP/2와 같은 프로토콜 종료 및 여러 애플리케이션 서버 관리를 처리할 수 있습니다. 하나의 애플리케이션 서버만 있어도 워크로드의 상당 부분을 offload합니다. 로드 밸런싱은 더 많은 서버가 추가됨에 따라 어떤 서버도 자신의 로드 공유 이상으로 정체되지 않도록 보장합니다.

이러한 단계들을 특정한 순서로 구현할 필요는 없습니다. 예를 들어, Apache를 웹 서버로 유지하고 앱 서버를 PHP 7로 업그레이드하지 않더라도, 기존 서버들 앞에 NGINX를 리버스 프록시로 구현함으로써 성능을 향상시킬 수 있으며 여러 개의 앱 서버를 병렬로 구현할 수도 있습니다.

어떻게 진행하든지 중요한 사실은, 현재 애플리케이션 코드를 거의 또는 전혀 변경하지 않고도 여러 가지 성능 향상 요인과 수십 배 이상의 용량 향상을 얻을 수 있다는 것입니다. 계속 읽어보면, 이미 이러한 놀라운 성능 향상을 달성한 사례나 현재 그러한 성과를 이뤄내기 위해 노력하고 있는 사례들을 확인할 수 있을 것입니다.

참고: 이 포스트에서는 다소 무시할 것이지만, 별도의 데이터베이스 서버와 콘텐츠 전송 네트워크(CDN)를 사용하여 애플리케이션 서버의 작업을 분산시키고 성능을 크게 향상시킬 수 있습니다. 이러한 변경 사항은 여기에서 설명하는 애플리케이션 및 구현 개선과 별개이며, 병렬로 구현할 수 있습니다.

3. 팁 1 – PHP 7로 업그레이드

빠른 PHP 7 업그레이드가 중요한 이유는 간단합니다: 애플리케이션 속도의 큰 향상 (메모리 절약으로 크게 도움). PHP 7은 이전 버전의 PHP보다 두 배 빠르고 훨씬 적은 메모리를 사용한다고 합니다. (두 가지 측면 모두 사용자마다 차이가 있을 수 있습니다.)

응답 시간은 웹 애플리케이션에서 극히 중요합니다. 더 빠른 웹 앱은 더 적은 메모리를 사용하여 페이지 스와핑과 관련된 성능 문제를 줄이므로 세 가지 기능을 달성합니다:

  1. 사용자를 더 행복하게 만들고 기사 읽기, 제품 정보 얻기, 전화 걸기, 여분의 방 임대 또는 물건 구매와 같은 사이트 방문 및 작업 완료 가능성을 높입니다. 즉, 처음에 사이트나 앱을 만든 이유입니다.
  2. 속도가 느려지거나 추가 사용자로 인해 중단되는 위험 없이 더 많은 사용자를 지원할 수 있는 지정된 서버를 활성화합니다. 파멸을 미루는 것은 언제나 좋은 일입니다.
  3. 프로덕션 중단을 위해 서버에 과부하를 일으키는 해커 공격에 서버가 덜 취약해집니다. 오늘날 모든 사람이 공격을 받지만 약자는 더 공격적으로, 더 공격적으로 공격을 받습니다. 따라서 취약성이 적을수록 많을 때보다 기하급수적으로 더 나을 수 있습니다.

이것들은 모두 업그레이드해야 하는 훌륭한 이유입니다. 종합하면 업그레이드 사례는 거의 압도적인 것 같습니다. 그리고 “최신 버전으로 업그레이드”는 성능상의 명확한 이점이 없는 경우에도 많은 문제를 해결하기 위한 첫 번째 권장 사항입니다. 그렇다면 왜 모두가 즉시 업그레이드하지 않습니까?

NGINX로 PHP 7 성능 극대화

xkcd에 따른 업데이트

간단하게 말하면, 사람들은 오래된 코드를 건드리기를 꺼리며, 이는 옳은 판단일 수 있습니다. 만약 오래된 애플리케이션이 잘 작동하고, 개발자들이 새로운 앱을 개발하는 것으로부터 오래된 앱을 업그레이드하는 것보다 더 나은 결과를 얻는다면, 오래된 앱은 변경 없이 오랫동안 사용될 수 있습니다. (현재의 웹 서버와 앱에 아무런 변경 없이도 NGINX를 사용하여 앱의 성능을 개선하는 방법에 대한 정보는 이 시리즈의 Part 2 글을 참조하시기 바랍니다.)

하지만 가능하다면, 성능을 향상시키기 위해 가장 효율적인 방법은 PHP 7로 업그레이드하는 것입니다. 그러나 테스트를 소홀히하지 않고, 특히 충분한 시간을 가지고 시작하기 전에 완료할 수 있는 만큼의 시간을 확보하세요.

PHP 7로 업그레이드하는 데 필요한 사항을 살펴보겠습니다.

  • 표현식 평가 변경. 일부 표현식이 PHP 7에서 올바르게 평가되도록 작성하는 방식을 변경해야 할 수도 있습니다. PHP 7.) 변수 변수 또는 변수 속성이 있는 경우 두 PHP 버전에서 동일한 방식으로 평가되도록 코드를 수정해야 합니다.
  • 구문 변경. PHP 7은 ASP 또는 스크립트 태그를 지원하지 않습니다. 스위치에 대한 기본 사례는 여러 개일 수 없습니다. (스위치 대 if-then-else에 대한 논쟁은 제쳐두겠습니다.)
  • 더 이상 사용되지 않는 기능 제거. 다양한 5.x 버전의 PHP에서 더 이상 사용되지 않는 모든 종류의 것들이 이제 죽은 앵무새보다 더 죽었습니다. PHP 7에서는 작동하지 않습니다. 코드에 있는 경우 모두 제거하려고 시도하고 실패하면 쇼핑 카트 코드 기능이 사이버 먼데이 전날 밤 11시 59분에 사라집니다.
  • 새로운 기능. PHP 7은 이전 코드를 업그레이드하는 사람을 유혹하는 여러 가지 새로운 기능을 추가하지만 코드 정리에서 새 기능을 추가하는 데 주의해야 합니다. 새로운 기능은 종종 훌륭하거나 추가되지 않았을 수도 있지만, PHP가 더 업그레이드됨에 따라 버그(귀하 및 다른 사람의) 및 향후 개정을 위한 자석이기도 합니다.
  • 일반적인 코드 검토. 코드를 만질 때마다(젠장, 코드 파일을 열고 변경했는지 여부가 확실하지 않을 때마다) 그 안의 모든 것, 특히 무엇을 변경했는지 검토해야 합니다.
  • 테스트. 모든 것은 항상 테스트되어야 합니다. 변경 사항이 있으면 모든 것을 다시 테스트해야 하지만 그렇다고 해서 모든 버그를 잡아낼 수 있는 것은 아닙니다. 잘 구현된 DevOps 환경은 이 테스트를 비교적 쉽게 만들 수 있지만 현재 우리 중 소수만이 약속된 땅에 살고 있습니다.

만약 PHP 7로 업그레이드하기로 결정한다면, 코드의 전체적인 성능 검토와 수정을 고려해보거나 적어도 핵심 기능들을 검토하여 PHP 7의 새로운 기능을 활용해보시기 바랍니다. 이렇게 함으로써 여러분과 여러분의 팀은 능력을 향상시킬 수 있으며, 오늘 수행하는 변경사항은 여러 해 동안 유용하게 사용될 수 있습니다. 또한 최적화된 코드는 최적화된 환경에서 실행될 때 가장 큰 이점을 얻을 수 있습니다.

따라서 애플리케이션 코드를 건드리지 않고도 성능을 향상시키기 위해 사이트에서 종종 NGINX를 배포한다고 하더라도, 여러분이 용기를 내어 전진하길 권장합니다. 이러한 변경 작업에 대해 도움이 많이 제공되며, 직접 해결하실 수도 있습니다. 공식 PHP 사이트에는 PHP 7 마이그레이션 가이드가 있으며, O’Reilly 출판사에서 PHP 7 업그레이드 방법에 대한 책도 있습니다.

4. 팁 2 – NGINX 오픈 소스 또는 NGINX Plus 선택

NGINX는 1억 4천만개 이상의 웹사이트를 운영하는 소프트웨어로, 이 중에서 가장 바쁜 10,000개의 웹사이트의 절반 이상에서 사용됩니다. (이러한 측정은 단일 서버 사이트에서 웹 서버를 감지하고, 다중 서버 사이트에서는 리버스 프록시 서버를 감지합니다.) 웹 서버로서, 양쪽 모두 즉각적인 성능 향상을 제공하며, 경우에 따라서는 다른 소프트웨어를 실행 중인 서버가 과부하 상태에서 과다하게 작동하는 경우에 최대 10배까지 성능 향상이 있습니다. 리버스 프록시 서버로서, 둘 다 여러 전용 서버의 사용을 가능하게하여 필요에 따라 배포를 확장할 수 있도록 합니다.

PHP와 Apache 모두 모든 오픈된 요청에 리소스를 할당합니다. 어느 한 쪽 또는 둘 다 많은 라이브러리를 로드해야 하는 경우, 각 요청당 시작 시간과 메모리 사용량이 상당히 증가할 수 있습니다. 웹 서버 소프트웨어로 NGINX로 전환함으로써 이러한 문제를 서버 수준에서 제거할 수 있습니다. NGINX의 기능을 사용하여 웹 서버(정적 파일 서비스와 같은) 또는 리버스 프록시 서버(캐싱, 프로토콜 종료, 부하 분산 등)로 작업을 offload하는 것은 PHP가 수행해야 하는 작업을 최소화하고 애플리케이션 처리를 간소화하며 빠르게 만들어줍니다.

NGINX를 사용하기로 결정하면 NGINX 오픈 소스와 NGINX Plus 중에서 선택할 수 있습니다. NGINX 오픈 소스에 대한 NGINX Plus의 가장 눈에 띄는 기능 중 일부는 다음과 같습니다.

  • 미리 컴파일된 코드. NGINX Plus는 즉시 추가 및 제거할 수 있는 인기 있는 라이브러리 및 동적 모듈을 포함하여 컴파일된 형태로 배포됩니다. (NGINX 오픈 소스는 컴파일된 코드와 컴파일되지 않은 코드로 모두 사용할 수 있습니다.) 서버를 다시 시작하지 않고도 광범위한 구성 변경을 수행할 수 있습니다.
  • 지원. NGINX Plus에는 NGINX 엔지니어에게 직접 액세스할 수 있는 지원 패키지가 포함되어 있습니다.
  • 모니터링 및 관리. DevOps 친화적인 도구는 서비스 수준 계약(SLA)을 충족하기 위해 서버를 가동 및 실행하는 데 도움이 됩니다.

리버스 프록시 서버로서 NGINX Plus에는 다음과 같은 추가 이점이 있습니다.

  • 로드 밸런싱. NGINX의 두 버전 모두 기본 HTTP 로드 밸런싱을 지원하지만 NGINX Plus는 더 정교한 알고리즘과 TCP 로드 밸런싱을 추가합니다.
  • 세션 지속성. 로드 밸런싱과 함께 NGINX Plus는 종종 PHP 애플리케이션 서버와 매우 관련성이 높은 보다 정교한 세션 지속성을 제공합니다.
  • 모니터링 및 관리. NGINX Plus 모니터링 및 관리의 모든 기능은 다중 서버 배포에서 작동합니다. 미리 컴파일된 코드 및 지원의 가치는 더 복잡한 구현에서도 극대화됩니다.

NGINX 오픈 소스와 NGINX Plus 모두 콘텐츠 캐싱과 마이크로캐싱(또는 애플리케이션 캐싱)을 지원합니다. 캐싱은 웹 서버 환경에서 유용하며, 애플리케이션 서버를 offload시켜줍니다. 그러나 두 기능은 여전히 단일 기기 또는 가상 머신 인스턴스를 공유합니다. 리버스 프록시 서버에서 캐싱은 애플리케이션 서버 디바이스에서 작업을 상당 부분 offload하여 더 큰 성능 이점을 제공합니다.

5. 팁 3 – Apache 구성을 NGINX 구문으로 변환

웹 서버 소프트웨어로 Apache에서 NGINX로 이동할 때 몇 가지 변경해야 할 사항이 있습니다. sitepoint.com의 훌륭한 기사에 자세히 설명되어 있습니다.

  • 구성 파일을 생성하거나 변환합니다. NGINX(더 이상 Apache가 아님)가 구성에 사용해야 하는 파일을 지정하도록 구성 코드를 변경합니다.
  • 읽기/쓰기 권한을 변경합니다. 웹 사이트의 root 디렉터리에 있는 파일에 대해 CRUD 작업(만들기, 읽기, 업데이트, 삭제)을 수행할 수 있는 권한을 계정에 추가합니다.
  • 유효한 검색 패턴을 지정하십시오. 요청을 처리하는 동안 NGINX가 시도할 수 있는 패턴과 시도할 수 없는 패턴을 지정하는 location 블록을 추가합니다.
  • .htaccess 구성 코드를 교체하십시오. Apache의 구성 세부 정보는 .htaccess 파일이나 정적 구성 파일(예: mod_rewrite 지시문)에 있는 경향이 있습니다. 이를 NGINX 구성 파일의 관련 구성 사양으로 바꿉니다. 몇 가지 예는 포스트를 참조하세요.

이러한 변경 사항을 적용함으로써 NGINX에 익숙해지고 Part 2에서 설명하는 것처럼 더 복잡한 사이트를 최적화하는 데 도움이 될 것입니다. 그러나 이러한 구성 변경이 사이트 운영에 불허한 양의 작업이나 리스크를 가지고 올 경우 걱정하지 마세요. Part 2에서 설명한 다중 서버 아키텍처를 Apache의 핵심 웹 서버 소프트웨어를 업그레이드하지 않고도 구현할 수 있으며, 따라서 웹 서버 구성 파일을 변경할 필요가 없습니다.

6. 팁 4 – 정적 파일 캐싱 구현

정적 파일은 웹 서버 용어에서 적어도 자주 변경되지 않는 파일들을 말합니다. 일반적으로 정적 파일은 JPEG나 PNG와 같은 그래픽 파일 및 CSS 및 JavaScript와 같은 코드 파일들을 포함합니다. 이러한 파일들을 애플리케이션 서버나 별도의 데이터베이스 서버에 두게 되면, 이러한 파일들에 대한 요청은 애플리케이션 코드를 통해 처리되어야 합니다. 이때 요청을 처리하기 위해 필요한 모든 오버헤드가 발생합니다. 이렇게 되면 애플리케이션 서버는 더 중요한 작업으로부터 “주의력”이 분산되며, 물리적 메모리가 과부하 상태에 접근하고 새로운 요청이 현재 요청을 디스크로 페이징할 수 있게 됩니다.

정적 파일 캐싱은 NGINX의 핵심 기능입니다. 웹 서버 또는 리버스 프록시 서버에서 구현할 수 있습니다.

  • NGINX 웹 서버에서 정적 파일 캐싱은 애플리케이션 서버를 offload합니다. 파일이 훨씬 더 적은 메모리 오버헤드로 더 빠르게 검색됩니다. 그러나 파일 검색은 여전히 동일한 물리적 서버 또는 가상 서버 인스턴스에서 실행되므로 서버의 프로세서는 여전히 애플리케이션 실행 이외의 작업을 처리해야 합니다.
  • NGINX 리버스 프록시 서버는 웹 서버와 다른 시스템 또는 인스턴스에서 실행되므로 정적 파일 캐싱은 애플리케이션 서버에서 리소스를 사용하지 않습니다. 애플리케이션 서버는 애플리케이션 실행에만 집중할 수 있습니다.

NGINX에서 정적 파일 캐싱을 구현하는 데는 세 가지 전반적인 단계가 있습니다.

  • 검색을 위한 root 디렉토리 지정.
  • 요청을 처리 중입니다.
  • 응답 속도 최적화.

리버스 프록시 서버가 없는 NGINX 웹 서버에서는 일반적인 의미로 캐시하지 않습니다. X-Accel-Redirect 헤더를 사용하여 정적 파일에 대한 문의를 웹 서버로 리디렉션하기만 하면 됩니다. 애플리케이션 서버는 요청을 볼 수 없으며 모든 자원을 애플리케이션 요청에 바칠 수 있습니다. 리버스 프록시 서버를 사용하면 정적 파일 캐싱을 사용하고 애플리케이션을 실행하는 물리적 서버 또는 가상 서버 인스턴스는 정적 파일 요청에 응답하는 데 아무런 역할도 하지 않습니다.

응답 속도 최적화의 예로 다음 구성 스니펫을 사용하면 NGINX가 운영 체제의 sendfile 시스템 호출을 사용할 수 있습니다. 이 시스템 호출은 파일을 중간 버퍼에 복사하지 않음으로써 파일 전송 단계를 저장합니다.

location /mp3 {
    sendfile           on;
    sendfile_max_chunk 1m;
    # ...
}

정적 파일 캐싱을 위한 NGINX 구성에 대한 자세한 내용은 NGINX Plus 관리 가이드를 참조하십시오.

7. 팁 5 – 마이크로캐싱 구현

혼란스럽게도 마이크로 캐싱은 많은 이름으로 불리며 여기에는 애플리케이션 캐싱과 일반 캐싱도 포함됩니다. 여기 NGINX에서는 이러한 파일이 유효한 짧은 시간을 강조하기 위해 마이크로 캐싱이라는 용어를 사용합니다.

사용자 의견에 대한 메커니즘을 제공하는 블로그 게시물 페이지가 있다고 가정해 보겠습니다. 새 방문자가 페이지에 도착할 때마다 또는 기존 사용자가 자신 또는 다른 사람의 새 댓글을 보기 위해 페이지를 새로고침할 때마다 최신 댓글을 포함하고 싶을 것입니다. 이 경우 누군가가 페이지를 방문할 때마다 페이지를 새로 생성하는 것이 좋습니다.

하지만 ‘매번’은 부담스러울 수 있다. 페이지가 초당 한 번 방문하는 경우 방문할 때마다 새로 생성하는 것이 좋습니다. 그러나 페이지가 사이트의 다른 모든 페이지와 함께 초당 10회, 100회 또는 1000회 방문하는 경우 애플리케이션 서버에 과부하가 걸릴 수 있습니다. 사람들에게 신선한 콘텐츠를 제공한다는 목표를 달성한다는 것은 아무도 콘텐츠를 빨리 얻지 못한다는 것을 의미합니다.

마이크로 캐싱은 캐시된 버전을 짧은 시간(예: 1초 또는 몇 초) 동안 유효한 것으로 표시한 페이지를 생성하는 것을 의미합니다. 캐시된 버전이 만료되면 다음 요청에서 새 페이지 생성을 요청하고 캐시된 버전을 가져온 직후에 요청합니다. 이는 정적 파일과 동일한 동작이지만 훨씬 더 짧은 기간에 적용됩니다.

이 이미지는 사이트에서 마이크로캐시할 수 있는 콘텐츠를 찾을 위치를 나타냅니다. 우리 자신의 Owen Garrett이 작성한 마이크로 캐싱 포스트에서 가져온 것입니다.

캐시 가능성-범위-정적-동적-개인화

많은 동적 콘텐츠가 마이크로 캐싱에 적합합니다.

마이크로 캐싱은 가장 필요할 때 애플리케이션 서버에서 작업을 제거하고 사용자에게 거의 또는 전혀 피해를 주지 않기 때문에 굉장합니다. 일부 시스템에 내장되어 있다는 것은 정말 대단합니다. Drupal은 강력한 내장형 마이크로 캐싱 기능이 매우 중요하므로 Drupal 세계에서는 마이크로 캐싱을 단순히 “캐싱”이라고 합니다.

그러나 Drupal 솔루션은 약간 부족하며 유사한 솔루션도 마찬가지입니다. 애플리케이션 서버는 작업을 덜 수행하지만 구성, 구현 및 파일 제공을 관리해야 하는 것은 여전히 Drupal(또는 더 일반적으로 PHP)입니다. 마이크로캐싱에 NGINX를 사용하면 애플리케이션 서버는 마이크로캐시에서 지정한 빈도로 새로운 페이지를 생성하는 것 외에는 모든 작업에서 완전히 offload됩니다. 캐시 적중을 위해 아무것도 저장하거나 검색해야 하는 것은 고사하고 다른 요청도 보지 않습니다.

NGINX Plus 또는 기타 도구를 사용하여 사이트를 모니터링하고 마이크로 캐싱의 이점을 얻을 수 있는 페이지를 확인할 수 있습니다. 다음 구성 조각은 200 OK 상태 코드가 있는 응답에 대해 1초 캐싱 기간을 구현합니다.

proxy_cache_path /tmp/cache keys_zone=cache:10m levels=1:2 inactive=600s max_size=100m;
server {
    proxy_cache cache;
    proxy_cache_valid 200 1s;
    # ...
}

8. 1부 PHP 결론

PHP 포스트의 이 첫 번째 부분은 단일 서버 솔루션과 단일 서버 구현에 효과적인 캐싱에 초점을 맞추고 있지만 리버스 프록시 서버가 혼합되어 있는 경우에는 더욱 그렇습니다. 2부에서는 리버스 프록시 서버, PHP 애플리케이션에 대한 다중 서버 구현의 이점에 대해 설명합니다.

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

아래 뉴스레터를 구독하고 NGINX의 최신 정보들을 빠르게 전달받아보세요.