Drupal 8 성능 향상을 위한 8가지 팁
Drupal 은 오픈 소스 콘텐츠 관리 시스템(CMS)으로, 애플리케이션 개발 분야에서 큰 존재감을 가지고 있습니다. Drupal은 개인 블로그부터 거대한 기업 및 정부 프로젝트까지 모든 것에 사용되며, 진정으로 집중적인 앱 개발, API 개발 및 기타 복잡한 작업에 대한 클래스를 형성합니다.
Drupal 은 PHP를 기반으로 하며, 빠른 프로토타이핑을 위해 배우기 쉽고 사용하기 쉬운 스크립팅 언어입니다.
그러나 PHP의 기본 동작은 사이트가 단기간 사용량의 급증이나 장기적인 성장으로 인해 신속하게 확장해야 할 때 성능 문제에 기여할 수 있습니다.
또한, 대부분의 Drupal 사이트는 자체적인 성능 제한을 가진 Apache HTTP Server 웹 서버를 사용합니다.
이 블로그 포스트에서는 Drupal과 Apache의 제한을 극복하는 몇 가지 방법을 설명하여 Drupal 기반 사이트를 필요한 만큼 고성능으로 만들 수 있습니다.
Drupal 8은 대형 프로젝트에 대해 더욱 강력한 기능을 제공합니다. 이에는 갑작스럽게 큰 프로젝트가 되는 작은 프로젝트도 포함됩니다. 새로운 추가 기능은 다음과 같습니다:
- 모바일 개선. 모바일 사이트 템플릿의 완전한 지원 및 모바일 기기에서의 쉬운 백엔드 관리
- 데이터 및 프레젠테이션 계층 분리. Drupal API는 이제 완전히 RESTful하며, Angular.js, Ember.js 및 기타 클라이언트 측 콘텐츠 추출 및 표시 도구와 함께 사용하기 쉬워졌습니다.
- Symfony 2 지원. Symfony 2는 최신의 객체지향 PHP 프레임워크로, 고객 관계 관리(CRM) 통합으로 잘 알려져 있습니다.
- Twig 지원. Twig는 순수 PHP의 일부 단점을 제거하면서 최신 PHP 표준을 수용하는 프론트엔드 라이브러리 및 템플릿 엔진입니다.
- 보안 개선. 새로운 기능을 통해 시스템을 더욱 안전하게 만드는 추가 방법을 제공합니다.
이러한 개선 사항 중 많은 것들은 성능 문제에 취약한 대형 복잡한 사이트를 지원합니다. 트래픽 성장의 주도 역할은 “North-South” 트래픽(클라이언트에서 서버로)이지만, 현대의 사이트는 일반적으로 “East-West” 트래픽(백엔드 서버 간)의 양도 증가합니다.
이 포스트에서는 Drupal 기반 사이트가 직면하는 일반적인 성능 문제를 해결하는 방법을 안내합니다. 상상력과 노력을 가지고 사이트를 빠르게 재구성하여 성능 병목 현상을 제거하고 현재 트래픽 양의 여러 배에 이르는 성장을 위한 기반을 마련할 수 있습니다.
목차
1. Tip 1 – Drupal 8 사이트 아키텍처 계획
1-1. Tip 1-1. 해결 방법
2. Tip 2 – Drupal 8 웹 서버 교체
3. Tip 3 – URL Rewrite
3-1. Tip 3-1. Rewrite 작성 방법
4. Tip 4 – Drupal 8 Reverse Proxy 배포
4-1. Tip 4-1. Drupal 8에 Reverse Proxy를 사용하는 이점
4-2. Tip 4-2. Reverse Proxy 기능
5. Tip 5 – 정적 파일 캐시
6. Tip 6 – 동적 파일 캐시
7. Tip 7 – 여러 애플리케이션 서버 및 로드 밸런서 사용
8. Tip 8 – 세션 지원 가속
9. 보너스 Tip – Drupal 8용 NGINX 구성
10. 결론
1. Tip 1 – Drupal 8 사이트 아키텍처 계획
대부분의 Drupal 사이트는 초기에 Apache HTTP Server를 웹 서버로 사용합니다. Apache는 다양한 종류의 웹사이트에서 사용되며, 구성에 대한 지침이 널리 제공됩니다. 그러나 성능이 향상되면 많은 사이트가 NGINX로 전환합니다. NGINX는 세계에서 가장 바쁜 사이트(상위 100,000개 사이트, 상위 10,000개 사이트 및 상위 1,000개 사이트)에서 선두를 달리고 있습니다.
Apache와 Drupal은 사이트가 바쁜 경우 유사한 문제를 겪습니다:
- Apache는 C10K 문제라고 불리는 문제에 직면합니다. 엄밀히 말하면 한 번에 10,000개 이상의 연결을 지원하는 것이 어렵습니다. (Apache는 이 목표에 크게 미치지 못합니다.) Apache는 추가 연결마다 메모리를 할당하므로 동시 연결이 증가함에 따라 디스크 스왑(Swap)을 시작합니다. 이로 인해 사이트 성능이 하락하고 전체 서버가 충돌하거나 멈추는 문제가 발생할 수 있습니다.
- Drupal은 받은 각 요청을 처리하기 위해 상당한 작업을 수행하며, 각 요청은 메모리와 CPU 시간을 소비합니다. Apache와 유사하지만 연결 수는 훨씬 적지만, Drupal 사이트의 성능은 하락할 수 있습니다.
- 또한, 애플리케이션 서버가 인터넷 트래픽 및 기타 기능을 처리하는 경우 여러 가지 문제가 발생할 수 있습니다.
웹사이트가 가질 수 있는 다양한 종류의 문제에 취약하며, 단일 장애 지점(SPOF, Single Point Of Failure)이 되며, 인터넷 요청에 대한 빠른 응답성, 빠른 애플리케이션 처리 및 빠른 디스크 액세스와 같이 호환되지 않는 작업에 대해 최적화되어야 합니다.
1-1. Tip 1-1. 해결 방법
따라서 사이트가 성장함에 따라 성능 병목 현상을 해결하기 위해 다음과 같은 여러 단계를 수행할 수 있습니다.
- Drupal 사이트의 웹 서버로 Apache 대신 NGINX를 사용합니다. 이렇게 하면 많은 수의 연결이 동시에 실행될 때 성능이 향상되고 메모리 사용량이 크게 감소합니다.
- 리버스 프록시 서버를 구현합니다. NGINX는 Drupal 사이트 및 다양한 종류의 사이트에 대한 매우 인기있는 리버스 프록시 서버입니다. 리버스 프록시 서버를 구현하면 인터넷 트래픽 처리 부담을 애플리케이션 서버에서 제거하고 정적 파일 캐싱 및 여러 로드 밸런스된 애플리케이션 서버 사용을 통한 성능 향상 단계를 수행할 수 있습니다.
- 리버스 프록시 서버를 구현한 후 성장 전략을 고려합니다. 물리적 서버를 추가하거나 클라우드에 서버를 추가하거나, 전체적인 성장 및 수요 증가에 대한 리소스의 혼합 사용을 고려할 수 있습니다.
- 서버 간 트래픽을 모니터링합니다. 여러 서버를 실행하는 경우 서버 간 성능을 모니터링할 수 있는 기능이 필요합니다. 이를 통해 사용자에게 최적의 성능을 유지할 수 있습니다.
이러한 단계를 미리 계획하고, 예상되는 또는 가능한 미래 성장과 기술적 리소스에 기반하여 수행할 수 있습니다.
참고: 웹 서버로 Apache 또는 NGINX를 사용하여 리버스 프록시 서버를 구현할 수 있습니다. 이 두 기능을 분리함으로써 구현을 간소화할 수 있습니다.
2. Tip 2 – Drupal 8 웹 서버 교체
웹 사이트의 성능을 “빠르게 해결”하고 동시에 보안, 유연성 및 성능을 위한 사이트 아키텍처링에 가치 있는 단계로 이동하려면 Apache에서 NGINX로 웹 서버를 전환하는 것을 고려해보세요.
NGINX는 C10K 문제를 해결하기 위해 설계되었습니다. 이는 대부분의 웹 서버가 한 번에 10,000개 이상의 동시 연결(즉, 많은 수의 동시 연결)을 지원하는 데 어려움을 겪는 문제입니다.
여러 연결을 지원하는 가장 쉬운 방법은 각 새 연결마다 새로운 프로세스를 포크하는 것입니다. 이렇게 하면 각 새 연결에 대해 Apache의 모든 기능에 액세스할 수 있습니다. 그러나 결과적으로 연결은 “무거워”집니다. 각 연결은 중요한 시작 시간, 디버깅 복잡성 및 가장 중요한 메모리 요구 사항을 가지고 있습니다.
NGINX는 이러한 단순한 접근 방식으로 인해 발생하는 오버헤드를 제거하기 위해 개발되었습니다. NGINX는 지속적인 이벤트 루프를 실행하여 요청이 발생할 때마다 리소스를 할당하지 않고 요청을 처리합니다.
따라서 Apache를 NGINX로 간단히 대체하는 것은 성능 문제에 대한 “빠른 해결”입니다. 이 변경을 통해 실제 애플리케이션 코드를 변경하지 않고도 가능합니다.
그러나 주목할 점은 실제로 “로컬” 웹 서버를 NGINX로 변경하지 않아도 된다는 것입니다. 이 블로그 포스트의 나머지 부분에서 설명한대로 NGINX를 원격 프록시 서버, 로드 밸런서 등으로 사용할 수 있으며, Apache를 계속 사용하거나 Drupal 코드와 직접 작동하는 웹 서버로 NGINX로 전환하더라도 가능합니다.
3. Tip 3 – URL Rewrite
Apache를 NGINX로 대체할 때 발생하는 구성 문제가 있습니다. 사이트 레이아웃이 복잡한 경우, 단순화된 사용자 친화적인 URL을 표시하는 것이 바람직합니다. 짧은 URL은 보안, 유연성 및 웹 사용성에 중요한 구성 요소입니다.
그러나 조금 복잡하기 때문에 여기에서 약간의 깊이 있는 설명을 제공하겠습니다.
웹 서버 컨텍스트에서 짧은 URL의 목적은 실제로 가능한 한 짧은 URL을 사용하는 것이 아닙니다. (Bitly와 같은 URL 단축 서비스를 사용하는 경우, 가능한 한 짧은 URL이 목표이지만, 여기에서는 그렇지 않습니다.) “짧은 URL”이라는 용어는 사실상 “더 짧고 예측 가능하며 안정적이며 사용자가 이해할 수 있는 PHP 코드가 없는 URL”을 의미합니다. 각 부분을 살펴보겠습니다:
- 짧은 URL: 사용자가 보기, 복사 및 붙여넣기, 기억 또는 기타 처리를 할 필요가 없도록, 알 수 없는 디렉토리 이름, 여러 수준의 디렉토리 및 사용자에게 이상한 것으로 보일 수 있는 요소를 제거합니다.
- 예측 가능한 URL: URL은 사용자의 기대에 부합해야 합니다. (사용자가 혼란스러운 URL에 집중하는 대신 콘텐츠와 작업 완료에 집중하길 원합니다.) URL에는 도메인 이름(예: http://www.nginx.com)과 /news 또는 /blog와 같은 합리적인 하위 디렉토리 이름이 포함됩니다. 두 번째 페이지는 /page2와 같은 합리적인 경로 요소로 표시될 수 있습니다.
- 안정적인 URL: 페이지의 URL은 시간이 지나도 변경되지 않습니다. 페이지 자체와 해당 페이지의 자산을 편의를 위해 다른 위치로 이동하더라도 마찬가지입니다. 이는 사용자, 당신을 링크하는 사이트 및 (관련성이 있는) SEO에 중요합니다.
- 사용자 이해 가능한 URL: 콘텐츠의 이름은 사용자가 이해할 수 있어야 합니다. 이는 drupal-8-performance 및 게시 날짜와 같은 구성 요소를 포함합니다. 필요한 경우 사용자는 URL을 기억하고 다른 브라우저 창에 다시 입력할 수 있습니다. 이 특성은 사용성 및 SEO에도 가치가 있습니다.
- PHP 코드 없음: 실제 URL에는 PHP 파일 확장자와 매개변수가 포함되는 경우가 일반적입니다. 예를 들어 …/index.php?title=page_title과 같이 말이죠. 이를 제거하고 콘텐츠의 사용자 이해 가능한 이름으로 대체하는 것은 매우 바람직한 모범 사례입니다. 그러나 많은 사이트에서는 이러한 노력을 기울이지 않습니다.
3-1. Tip 3-1. Rewrite 작성 방법
대부분의 웹 서버에서 URL Rewriting은 .htaccess (하이퍼텍스트 액세스) 파일에서 mod_rewrite 모듈을 사용하여 수행됩니다. NGINX에서는 통합된 HTTP Rewrite 모듈을 사용합니다. 이는 mod_rewrite보다 간단하고 강력하며 유지 관리하기 쉽습니다. 그러나 이전에 mod_rewrite를 사용한 경험이 있는 경우 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로 대체합니다.
4. Tip 4 – Drupal 8 Reverse Proxy 배포
리버스 프록시 서버를 배포하는 것은 유연하고 적응 가능한 사이트 아키텍처를 만드는 첫 번째 단계이며, 특히 병렬로 실행되는 여러 애플리케이션 서버를 지원할 수 있는 “Scale OUt”을 할 수 있는 사이트 아키텍처를 구축하는 데 필요합니다.
리버스 프록시 서버는 브라우저로부터 요청을 받은 후 즉시 처리하지 않습니다. 대신, 리버스 프록시 서버는 각 요청을 검토하고, 솔로몬과 같이 해당 요청에 대해 어떻게 처리할지 결정합니다. 요청을 직접 처리하거나 다른 서버로 전달하여 처리할지를 결정합니다.
리버스 프록시 서버는 로컬 영역 네트워크를 통해 빠르게 애플리케이션 서버와 통신합니다.
애플리케이션 서버가 요청을 완료하고 결과를 리버스 프록시 서버에 반환하면, 실제 클라이언트와의 인터넷 통신을 기다릴 필요가 없습니다.
대신, 애플리케이션 서버는 다음 애플리케이션 관련 요청을 처리하기 위해 바로 돌아갈 수 있습니다. 그런 다음 리버스 프록시 서버는 응답을 클라이언트에게 다시 보냅니다.
이 접근 방식은 유연성, 중복성, 향상된 보안 및 기타 여러 가지 이점을 제공합니다.
아이러니한 점은 간접 참조를 추가하는 것이 일반적으로 성능을 저하시키는데, 이는 특정 프로세스에 추가적인 호출 또는 조회를 추가하기 때문입니다.
그러나 리버스 프록시 서버를 추가하는 것은 성능을 향상시킬 가능성이 높습니다. 이에는 두 가지 이유가 있습니다:
- 웹 서버 간의 통신은 인터넷을 통한 통신보다 훨씬 빠릅니다. 리버스 프록시 서빙의 “다른 웹 서버와 통신” 부분은 사실상 무료입니다.
- 서버를 특화시키면 각 서버가 너무 다양한 작업을 수행하는 단일 서버보다 훨씬 빠르게 실행될 수 있습니다.
특히 애플리케이션 서빙(페이지의 핵심 요소를 구성하고 요청자에게 다시 보내는 작업)이 포함된 경우에는 더욱 그렇습니다.
특히 초당 수천 개 또는 수십만 개의 요청을 처리할 때 애플리케이션 서버는 다른 작업을 수행하지 않아도 되는 것이 실제로 큰 이점을 제공합니다.
4-1. Tip 4-1. Drupal 8에 Reverse Proxy를 사용하는 이점
리버스 프록시 서버를 추가하면 Drupal 서버가 인터넷 트래픽을 직접 처리하지 않아도 됩니다. Drupal 서버는 Apache 또는 NGINX에서 실행될 수 있습니다. (처음부터 구축하는 경우 모두 NGINX를 사용하는 것이 좋을 수 있지만, 이미 Apache 웹 서버를 사용하고 있는 많은 사이트는 변경되지 않은 Apache-Drupal 설정 앞에 NGINX 웹 서버를 배치하여 시작합니다. NGINX는 편리한 때에 Drupal을 위한 웹 서버로 삽입할 수 있습니다.)
리버스 프록시 서버를 삽입하면 과도한 트래픽, 보안 문제(애플리케이션 처리와는 별도로 해결할 수 있게 됨) 또는 기타 문제로 인해 문제가 발생하는 사이트를 즉시 “구조적으로 구조화”할 수 있습니다.
리버스 프록시 서버는 사이트 아키텍처에 새로운 유연성을 도입합니다. 새로운 기능은 다음과 같습니다.
4-2. Tip 4-2. Reverse Proxy 기능
- 정적 파일 캐싱: 사이트 운영에서 애플리케이션 처리가 일반적으로 병목 현상이므로, 이미지, CSS 파일, JavaScript 파일 등의 정적 파일을 동적 페이지와 별도로 제공하면 사이트 성능이 향상됩니다.
- 동적 파일 캐싱 / 마이크로캐싱: 애플리케이션 서버의 목적은 각 새 요청에 대해 사용자 정의 응답을 보내는 것입니다.
그러나 바쁜 사이트의 경우, 애플리케이션 서버 응답을 매우 짧은 시간(1~10초) 동안 캐싱하여 대부분의 응답이 캐시에서 제공되도록 하면 신선도에 큰 손실이 없습니다. - 확장성: 하나 이상의 추가 애플리케이션 서버를 추가하면 트래픽 급증 및 시간이 지남에 따른 유연한 응답이 가능합니다.
온프레미스 서버로 처리할 수 없는 급증에 대해서는 클라우드 처리를 사용할 수도 있습니다. - 로드 밸런싱: 하나의 애플리케이션 서버가 병목 현상이 되는 것을 방지하기 위해 부하를 합리적으로 분산해야 합니다.
다양한 로드 밸런싱 기법(NGINX Plus에 특화된 기법도 포함)과 필요한 경우 세션 지속성을 지원하여 원활한 사용자 상호작용을 지원합니다. - 보안 관리: 인터넷에 노출되는 유일한 서버인 리버스 프록시 서버를 엄격하게 제한하고 보안 문제를 밀접하게 모니터링할 수 있습니다. 이는 애플리케이션 처리 및 기타 사이트 기능에 영향을 주지 않습니다.
- 보안 프로토콜 종료: 사이트의 보안 또는 성능 향상을 위해 사용되는 프로토콜(TLS/SSL 및 HTTP/2 등)을 리버스 프록시 서버에서 처리하고 종료할 수 있습니다.
애플리케이션 서버는 암호화되지 않은 트래픽을 보고 서비스합니다. - 모니터링 및 관리: 단일 서버 사이트의 모니터링은 간단합니다. 작동하거나 실패합니다.
여러 서버를 실행하는 경우 NGINX Plus에 특화된 모니터링 및 관리 기능을 통해 지속적인 서비스 제공과 높은 성능을 유지할 수 있습니다. - 기능별 유연성 및 중복성: 다중 서버 설정에서 각 서버는 다른 서버로 백업될 수 있으므로 높은 가용성을 제공할 수 있습니다. 심지어 리버스 프록시 기능조차도 여러 서버로 지원될 수 있습니다.
5. Tip 5 – 정적 파일 캐시
“캐싱”이라는 용어는 Drupal에서 동적 캐싱 또는 마이크로캐싱이라고도 하는 애플리케이션 서버 페이지의 잠시 동안 캐싱을 의미하는 경우가 많습니다.
이에 대해서는 다음 팁에서 설명하겠습니다.
NGINX를 리버스 프록시 서버로 사용하는 가장 일반적이고 거의 모든 사이트에서 사용하는 방법은 정적 파일 캐싱입니다.
그래픽 및 코드 파일인 JPEG, PNG, CSS 파일, JavaScript 파일 등을 캐싱하는 것입니다.
이 작업은 매우 간단합니다. 캐시된 파일을 사용자에게 더 빠르게 제공하고 Drupal 서버에서 페이지당 처리하는 트랜잭션 수를 줄일 수 있습니다.
다음 구성 블록은 NGINX 캐싱을 설정합니다. proxy_cache_path는 캐시된 콘텐츠가 로컬 파일 시스템에 저장되는 위치를 지정하고 공유 메모리에 이름이 지정된 존을 할당합니다.proxy_cache 지시문은 캐싱할 컨텍스트에 배치되며 공유 메모리 존을 참조합니다.
http {
# ...
proxy_cache_path /data/nginx/cache keys_zone=one:10m;
server {
proxy_cache one;
location / {
proxy_pass http://localhost:8000;
}
}
}정적 파일의 캐싱 효율성을 더욱 높이기 위해 콘텐츠 전송 네트워크(CDN)를 고려해보세요. CloudFlare와 같이 널리 사용되는 CDN의 Core로 NGINX를 사용합니다.
6. Tip 6 – 동적 파일 캐시
Drupal은 PHP로 생성된 웹 페이지의 캐싱을 자동으로 처리하여 사이트 성능을 크게 향상시킬 수 있습니다.
다른 플랫폼의 마이크로캐싱과 마찬가지로, 사용자들은 새로 생성된 웹 페이지의 복사본을 받지 않고, 1초 또는 10초 정도 오래된 복사본을 받게 됩니다.
이는 일반적으로 문제가 되지 않으며, 트래픽이 증가함에 따라 전체 사이트 성능이 느려지는 것보다는 선호됩니다. (이 경우 사용자들은 다른, 더 나쁜 이유로 신선한 콘텐츠를 받지 못하게 됩니다.)
Drupal의 캐싱에는 두 가지 문제가 있습니다.
첫째, Drupal은 캐싱을 효율적으로 처리하지 못합니다.
둘째, Drupal이 과부하 상태가 되면 캐시된 페이지를 검색하는 데 필요한 작업조차도 상당합니다.
그러나 NGINX를 사용하면 강력하고 유용한 옵션을 사용할 수 있습니다: Drupal 캐싱을 완전히 우회하는 것입니다.
NGINX는 정적 파일 캐싱과 PHP 페이지 캐싱을 모두 처리합니다. 이에는 여러 가지 이점이 있습니다.
- 더 큰 간소화. Drupal 애플리케이션은 개발(작성할 코드가 적음), 유지보수(변경 시 업데이트할 코드가 적음) 및 디버깅(문제 발생 시 찾아야 할 위치가 적음)에서 상당히 간단해집니다.
- 더 높은 성능. NGINX 수준의 캐싱을 사용하면 캐시 히트 시 Drupal 앱은 작업을 수행하지 않으며, 실제로 요청조차 앱에 전달되지 않습니다. Drupal 앱이 최대치에 가까워질 때 작업을 수행하지 않는 것이 매우 효과적입니다.
- 개발이 쉬워집니다. NGINX 캐싱을 사용하면 개발 중에 Drupal 캐싱을 끄고 실행 중에 다시 켜고 각 상태에 대해 별도의 테스트를 수행할 필요가 없습니다. NGINX 수준에서 캐싱이 작동하면 Drupal 앱 작업 중에는 무시할 수 있습니다.
NGINX 수준에서 모든 캐싱이 발생하므로 Drupal 앱은 호출될 때마다 신선한 콘텐츠를 생성합니다.
예를 들어, Drupal 앱은 매 초마다 신선한 페이지를 생성해야 할 수 있으며, 수백 개 또는 수천 개의 동시 요청에 대해 캐시에 액세스하거나 페이지를 생성해야 하는 대신에요. 이는 엄청난 성능 이점을 제공합니다.
다음 구성 코드는 유효한 페이지를 1초 동안 캐시합니다.
초당 10개에서 수천 개의 요청을 받는 서버의 경우, 요청의 90%에서 99% 이상이 캐시에서 제공됩니다.
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;
# ...
}7. Tip 7 – 여러 애플리케이션 서버 및 로드 밸런서 사용
더 크고 빠른 서버는 잠재적으로 비용이 많이 들 수 있습니다. 가장 크고 빠른 서버는 상대적으로 비싸기 때문입니다.
또한, 단일 장치는 항상 성능 한계가 있기 때문에 본질적으로 제한됩니다.
더 많은 성능이 필요한 경우 현재 장치를 업그레이드하거나 교체해야 하므로 중단이 발생합니다.
위의 Tip 2에서 설명한대로 리버스 프록시 서버를 구현하면 여러 애플리케이션 서버를 사용할 수 있으므로 가로 확장성을 제공합니다.
성능을 더 높이려면 서버를 추가하기만 하면 됩니다. NGINX Plus와 같은 적절한 소프트웨어 도구를 사용하면 서버를 추가하거나 제거하는 작업을 전혀 중단 없이 수행할 수 있습니다.
그러나 여러 애플리케이션 서버가 있는 경우 다음 요청을 어떤 서버에 보낼지 결정하는 기술이 필요합니다.
이를 로드 밸런싱이라고 하며, 기법은 간단한 라운드 로빈 방식(다음 요청은 목록에서 다음 서버로 이동)부터 가장 바쁘지 않은 서버(가장 사용 가능한 서버)를 확인한 후 요청을 전달하는 고급 기법까지 다양합니다.
로드 밸런싱은 하드웨어 장치나 표준 하드웨어에서 실행되는 소프트웨어 로드 밸런서와 같은 소프트웨어 기반 접근 방식으로 수행될 수 있습니다.
소프트웨어 기반 접근 방식은 더 유연하며, 고객 소유 서버, 개인 클라우드 및 공용 클라우드에서 쉽게 사용할 수 있습니다.
NGINX와 NGINX Plus는 다섯 가지 로드 밸런싱 방법과 서버 가중치를 지원합니다.
네 가지 방법은 오픈 소스 NGINX와 NGINX Plus에서 모두 지원되며, 최소 연결 방법은 NGINX Plus에서만 지원됩니다.
- 라운드 로빈(Round Robin): 각 새 요청은 목록에서 다음 서버로 이동합니다. 각 서버의 바쁨 여부에 관계없이 순서대로 요청이 전달됩니다.
- 최소 연결(Least Connection): 다음 요청은 가장 적은 활성 연결을 가진 서버로 전달됩니다.
- 해시(Hash): 사용자 정의 키(일반 해시) 또는 IP 주소(IP 해시)를 기반으로 다음 요청이 할당됩니다.
- IP 해시(IP Hash): 클라이언트 IP 주소를 기반으로 다음 요청이 할당됩니다.
- 최소 시간(NGINX Plus 전용): NGINX Plus는 전달된 클라이언트 요청의 응답 시간을 추적한 다음 “최소 연결” 정보와 결합하여 새 요청을 보낼 위치를 결정합니다.
서버 가중치는 여러 로드 밸런싱 방법과 함께 사용할 수 있는 기능입니다. 서버의 가중치를 증가시키면 해당 서버로 전송되는 요청 수가 증가합니다.
다음 코드는 backend1.example.com에 대한 server 지시문에서 weight 매개변수를 설정하는 예시입니다.
upstream backend {
server backend1.example.com weight=5;
server backend2.example.com;
server 192.0.0.1 backup;
}8. Tip 8 – 세션 지원 가속
여러 애플리케이션 서버를 추가하면 다음과 같은 문제가 발생할 수 있습니다.
구매 세션과 같은 상호 작용 기능을 지원하는 앱의 경우, 동일한 사용자에 대한 모든 요청을 동일한 서버가 브라우저 세션 동안 처리한다고 가정합니다.
많은 앱은 사용자의 상태를 앱이 실행되는 서버에 유지합니다. 전자 상거래 앱이나 라이드 공유 서비스의 여정과 같은 것을 생각해보세요. 상태가 서버 측에 유지되는 경우, 사용자 세션 동안 동일한 서버를 사용해야 합니다.
드 밸런싱과 마찬가지로 이를 보장하기 위한 여러 기술이 있습니다.
참고: 세션 지속성을 사용하는 경우에도 부하는 여전히 균형 조정되지만, 개별 사용자 요청이 아닌 사용자 세션이 애플리케이션 서버에 할당됩니다. 바쁜 시스템의 경우, 세분화 수준의 차이는 큰 영향을 미치지 않습니다.
세션 지속성은 특정 클라이언트를 세션 동안 동일한 서버에 할당하여 유지합니다. 세션 지속성은 NGINX Plus에서만 제공되며, 세 가지 방법을 사용합니다:
- 쿠키 삽입: 클라이언트가 첫 번째 요청을 보내면 NGINX Plus는 세션 쿠키를 생성하여 클라이언트에 반환합니다.
클라이언트는 이를 향후 요청에 포함시키고, NGINX Plus는 이를 사용하여 해당 요청을 처리한 서버로 라우팅합니다. - 학습: NGINX Plus는 요청 및 응답을 모니터링하여 세션 식별자를 찾고, 이를 사용하여 트래픽을 동일한 서버로 라우팅합니다. 라우팅을 지원하기 위한 정보는 공유 메모리 영역에 유지됩니다.
- Sticky Route: Sticky Route를 사용하면 애플리케이션 서버가 응답을 표시하여 이후 요청이 동일한 표시자를 사용하고 동일한 서버로 이동하도록 설정할 수 있습니다.
9. 보너스 Tip – Drupal 8용 NGINX 구성
NGINX 문서에는 Drupal 구성 레시피가 포함되어 있으며, 이는 Drupal 8로 업데이트되었습니다.
레시피의 주석에는 Drupal 8에 대한 특정 변경 사항을 보여주며, 현재 사용 중인 이전 버전의 Drupal을 사용하려는 경우에도 안내를 제공합니다. 따라서 Drupal 8을 사용하기 위해 NGINX를 새로 구성하는 경우, Drupal 구성 레시피가 시작점이 될 것입니다.
이미 Drupal 7을 사용 중인 경우에는 Drupal 7에 맞는 구성을 환경에 맞게 조정했을 수 있습니다. 그렇다면 Drupal 8로 업그레이드할 때 선택할 수 있는 방법이 있습니다:
- Drupal 8에 맞는 Drupal 구성 레시피를 시작점으로 삼고 환경에 맞게 조정합니다.
- 현재 Drupal 7에 맞는 NGINX 구성을 시작점으로 삼고 Drupal 8에 맞게 조정합니다.
첫 번째 옵션을 선택하는 경우, 필요한 변경 사항은 환경에 따라 다를 수 있으며, 여기에서는 안내를 제공할 수 없습니다.
그러나 두 번째 옵션을 선택하는 경우, 몇 가지 구체적인 사항을 안내해 드릴 수 있습니다.
Drupal 8로 업그레이드할 때 발생할 수 있는 세 가지 문제가 있습니다. 다음은 이러한 문제와 간단한 해결 방법에 대한 간략한 설명입니다.
- update.php가 실행되지 않는 문제: 위치 지시문을 업데이트해야 합니다. URL 끝에 .php를 요구하는 대신, .php가 없는 방식으로 작성하세요. 이를 위한 한 가지 방법은 다음과 같이 변경하는 것입니다.
location ~ .php$ {->
location ~ .php$|^/update.php {- 관리 인터페이스에서는 모듈을 설치할 수 없는 경우: Drupal에는 잘못된 하위 디렉터리에서
Authorize.php라는 필요한 스크립트를 찾는 버그가 있습니다 . NGINX가 있는 위치를 찾으려면 업데이트해야 합니다. 파일을 찾는 정규식을 변경하십시오.
fastcgi_split_path_info ^(.+.php)(.*)$;->
fastcgi_split_path_info ^(.+?.php)(|/.*)$;- 내비게이션 요소에 CSS 스타일이 적용되지 않는 문제가 발생하는 경우: Drupal 8의 관리 인터페이스는 인터페이스 요소의 모양을 제어하기 위해 CSS를 사용합니다. NGINX가 도움을 받을 수 있도록, 최상위 디렉토리 / (즉,
location /{…})에 대한 위치 블록을 찾으세요.try_files지시문을 다음과 같이 변경하세요.
try_files $uri @rewrite;->
try_files $uri /index.php?$query_string;10. 결론
Drupal 8의 강력함과 기능은 다양한 웹 애플리케이션과 웹 사이트를 만드는 데 도움이 됩니다.
그러나 이러한 사이트가 널리 사용되면 성능은 중요한 문제가 될 수 있습니다.
오픈 소스 NGINX와 NGINX Plus는 웹 서버 대체로 사용되거나 리버스 프록시 서버, 캐싱 및 마이크로캐싱 엔진, API Gateway, Load Balancer으로 사용되며, 로드 밸런싱과 세션 지속성을 사용하여 여러 애플리케이션 서버를 사용할 수 있도록 지원하여 이러한 문제를 해결하는 데 도움이 됩니다.
NGINX Plus를 사용해 보려면 30일 무료 평가판을 시작하거나 사용 사례에 대해 문의하십시오.
아래 뉴스레터를 구독하고 NGINX와 NGINX STORE의 최신 정보들을 빠르게 전달 받아보세요.
댓글을 달려면 로그인해야 합니다.