LAMP 스택에서 NGINX 사용하여 LEMP로 전환한 이유

오늘 포스트에서는 미국 클라우드 컴퓨팅 및 호스팅 서비스 제공업체인 Atlantic.net이 LAMP 스택 대신 NGINX를 사용한 LEAMP를 선택한 이유에 대해 이야기 할 것입니다.

이 포스트의 버전은 Atlantic.Net에 있는 웹 사이트에도 나타납니다. 방문하려면 여기를 클릭하십시오.

전통적으로 웹 개발 및 호스팅은 주로 LAMP 스택을 사용하여 수행되었습니다. LAMP는 Linux(운영체제), Apache(웹 서버), MySQL (데이터베이스) 및 PHP(프로그래밍 언어) 의 줄임말입니다. 이는 엔터프라이즈 사이트를 실행하는 데 사용되었습니다.

웹 스택과 로드 밸런서가 더욱 민첩해지고 비즈니스의 요구 사항이 더 나은 성능과 안정성을 요구함에 따라 Apache HTTP Server를 가볍고 확장성이 뛰어난 대안인 NGINX로 대체하는 것이 점차 보편화되고 있습니다. NGINX를 사용하면 스택이 LEMP – Linux, ( E )NGINX, MySQL , PHP로 알려지게 됩니다.

Atlantic.net은 스토리지, 호스팅 및 관리 서비스를 포함하는 다양한 솔루션을 제공합니다. 당사의 클라우드 호스팅 플랫폼 에는 30초 이내에 스택을 만들고 실행할 수 있는 원클릭 LEMP 옵션이 있습니다. Docker에서 NGINX를 실행하는 것을 선호하는 사용자를 위해 Docker가 포함된 Linux 및 Windows 클라우드 서버가 모두 있습니다. 또한 NGINX 설정에 대한 도움이 필요하거나 필요한 사람들을 위해 관리형 서비스를 제공합니다.

웹 서버뿐만 아니라 리버스 프록시 및 로드 밸런서로도 NGINX를 자주 사용합니다. 중앙 집중식 로깅 클러스터를 위한 로드 밸런싱 솔루션 또한 NGINX가 최적화 되었다고 생각합니다. NGINX를 다양한 용량으로 사용함으로써 프론트엔드 및 백엔드 서버 모두에 대해 고가용성을 달성하는 동시에 매우 적은 설치 공간을 유지합니다. 이는 NGINX의 RAM 및 CPU 사용 효율성 덕분입니다.

NGINX의 특정 기능이 가장 유용한 측면에서 특히 강력하다고 생각하는 기능은 TCP/UDP 프록시 및 로드 밸런싱, Access Control, 3-Way SSL Handshake 입니다. 이 블로그에서는 이러한 각 기능을 사용하는 방법이 있습니다.

목차

1. NGINX Streams를 사용한 로드 밸런싱으로 중앙 집중식 로깅하기
2. Access Control
3. 3-Way SSL Handshake
4. NGINX 의 관점과 테스트
5. NGINX 로 Atlantic.Net을 사용하기

1. NGINX Streams를 사용한 로드 밸런싱으로 중앙 집중식 로깅하기 (LAMP > LEMP)

감사 및 보안을 위한 로깅 제공의 필요성이 더 커짐에 따라 Atlantic.Net은 HTTP 트래픽뿐만 아니라 syslog에 대해서도 올바른 프록시 및 로드 밸런싱 솔루션을 찾고 있었습니다. Syslog는 일반적으로 UDP(User Datagram Protocol) 형식으로 전송되므로 UDP와 HTTP를 처리하는 것이 필요했습니다.

UDP 트래픽의 로드 밸런싱을 가능하게 하는 NGINX Streams 모듈이 등장했습니다. 로드 밸런싱은 네트워크 트래픽의 효율적인 분산을 위해 여러 백엔드 서버를 사용합니다. 용어에서 알 수 있듯이 목적은 워크로드를 고르게 분산시키는 것입니다.

다음은 네트워킹 인프라에서 로깅 백엔드로 syslog 메시지를 보냅니다.

# ...
stream {
    upstream networking_udp {
       least_conn;
       server 198.51.100.100:5910;
       server 198.51.100.101:5910;
       server 198.51.100.102:5910;
  }

    server {
       listen 5910 udp;
       proxy_timeout 0s;
       proxy_bind $remote_addr transparent;
       proxy_pass networking_udp;
    }
}
# ...

다음 예제는 Filebeat 로그를 안전하게 전송하는 방법입니다. stream은 TCP를 통한 SSL에서도 잘 작동합니다.

# ...
upstream filebeat_tcp {
    least_conn;
    server 198.51.100.100:5910;
    server 198.51.100.101:5910;
    server 198.51.100.102:5910;
}

server {
    listen 5910 ssl;
    ssl_certificate /etc/nginx/ssl/certs/cert.pem;
    ssl_certificate_key /etc/nginx/ssl/private/priv-key.pem;
    ssl_protocols TLSv1.2;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_session_cache shared:SSL:20m;
    ssl_session_timeout 4h;
    ssl_handshake_timeout 30s;
    proxy_pass filebeat_tcp;
    proxy_ssl on;
    proxy_ssl_certificate /etc/nginx/ssl/certs/cert.pem;
    proxy_ssl_certificate_key /etc/nginx/ssl/private/priv-key.pem;
    proxy_ssl_protocols TLSv1.2;
    proxy_ssl_session_reuse on;
    proxy_ssl_ciphers HIGH:!aNULL:!MD5;
    proxy_ssl_trusted_certificate /etc/nginx/ssl/certs/ca.pem;
}
# ...

보시다시피 NGINX는 UDP 및 전송 제어 프로토콜(TCP) 트래픽을 프록시하고 로드 밸런싱할 수 있습니다.

UDP 또는 TCP를 통해 통신하는 서비스, 데이터베이스 또는 프로그램이 있는 경우 리버스 프록시 및 로드 밸런싱을 사용하면 유용합니다. 기본적으로 이러한 방법은 NGINX에서 관리하는 것과 같이 여러 Upstream 서버에서 실행 중인 동일한 서비스, 데이터베이스 또는 프로그램 인스턴스가 있는 경우에 적합합니다. Atlantic.Net에서는 오버헤드가 거의 없이 중요한 백엔드 서비스에 추가 난독화를 사용하기 때문에 NGINX의 리버스 프록시도 활용합니다.

2. Access Control (LAMP > LEMP)

중앙 집중식 로깅을 보호하는 또 다른 중요한 단계는 데이터 삭제를 방지하는 것입니다. 또한 액세스 제어 목록(ACL)은 IP 주소를 기반으로 트래픽을 제한하는 데 매우 유용합니다. 우리의 목적을 위해 내부 관리 네트워크에서만 로그 데이터에 대한 액세스를 허용하고자 했습니다.

NGINX는 여기에서 볼 수 있듯이 어떤 종류의 HTTP 작업을 어디에서 수행할 수 있는지 매우 정확하게 알 수 있는 방법을 제공합니다.

# ...
server {
    listen 9200;
    client_max_body_size 20M;
    location / {
        limit_except GET POST PUT OPTIONS {
            deny all;
        }
        allow 198.51.100.0/24;
        deny all;
        proxy_pass http://elasticsearch_backend;
    }
   
    location ~* ^(/_cluster|/_nodes|/_shutdown) {
        allow 198.51.100.0/24;
        deny all;
        proxy_pass http://elasticsearch_backend;
    } 
}
# ...

NGINX는 요청이 프록시를 통과한 후 원래 IP 주소를 볼 수 있는 Transparent IP 기능 도 지원합니다. 이 기능은 로그의 출처를 추적하는 데 도움이 됩니다. NGINX는 이 작업을 매우 쉽게 만듭니다.

# ...
server {
    listen 5915 udp;
    proxy_timeout 0s;
    proxy_bind $remote_addr transparent;
    proxy_pass vmware_udp; 
}
# ...

3. 3-way SSL Handshake

NGINX는 중앙 집중식 로깅을 위해 SSL Handoff의 양쪽을 깔끔하게 처리합니다. 이 구현은 내부 및 고객 서버 모두 NGINX와 안전하게 통신할 수 있음을 의미하므로 매우 중요합니다. 기록되는 각 서버에는 양방향 SSL 통신을 위한 자체 인증서가 있으므로 보안성이 높아지고, NGINX는 SSL을 통해 데이터를 내부 네트워크에서 로깅 서버로 안전하게 전송합니다. 보안 전송을 지원하는 모든 End-to-End 통신 즉 통신의 시작부터 끝까지 총 3개의 SSL 인증서가 필요하게 됩니다. ( Atlantic.net 측에서 선호하는 3-way SSL 설정에 대해서는 NGINX Streams를 사용한 중앙 집중식 로깅 로드 밸런싱 의 두 번째 구성을 참조하십시오. )

4. NGINX 의 관점과 테스트

다양한 개인과 조직이 수년 동안 NGINX를 칭찬해 왔으며 그들이 언급한 이점들을 경험할 수 있습니다.

NodeSource의 소프트웨어 엔지니어 Chris Lea는 Apache와 Microsoft Word를 비교하면서 두 애플리케이션 모두 터무니없이 많은 기능을 가지고 있지만 일반적으로 몇 가지만 필요하다는 점을 지적합니다. Lea는 NGINX를 선호합니다. NGINX는 사용자가 필요로 하는 기능을 갖추고 있지만 대량이 없고 훨씬 더 나은 성능을 제공하기 때문입니다.

벤처 캐피탈 회사 인 BV Capital의 Thomas Gieselman에 따르면, 일부 조직은 서버를 NGINX로 변경하여 스케일링과 관련된 고정 문제에 자금을 지원했습니다. Gieselman은 NGINX를 더 많은 조직에서 빠른 성장을 더 간단하고 접근 할 수 있다고 생각합니다.

Linux Journal은 Apache 벤치 마크 소프트웨어 A/B를 사용하여 Apache를 NGINX(각각 2.2.8 및 0.5.22 버전)와 비교하여 간단한 테스트를 수행했습니다. top과 vmstat 명령어로 서버가 동시에 실행되는 동안 시스템의 성능을 확인하였습니다.

테스트는 NGINX가 정적 콘텐츠 서버로서 Apache보다 빠른 것으로 나타났습니다. 두 개의 서버는 각각 최적으로 실행되었으며 동시성은 100으로 설정되었습니다. 초당 6500개의 요청을 위해 Apache는 17MB의 메모리, 30% CPU 및 4개의 Worker 프로세스 (Thread 모드)를 사용했습니다. 초당 11,500 개의 요청의 훨씬 빠른 클립을 제공하기 위해 NGINX는 1MB의 메모리, 15% CPU 및 1개의 Worker만 필요했습니다.

Bob Ippolito는 한 달에 1억 4천만 명의 고유한 사용자를 보유한 게임 플랫폼 Mochi Media를 설립하여 고성능에 대한 수요를 잘 이해하고 있습니다. Ippolito는 2006년에 한 서버에서 하루에 수천만 건의 HTTP 요청(즉, 초당 수백 건)에 대한 리버스 프록시로 NGINX를 사용하는 테스트를 실행했다고 말했습니다.

NGINX 서버가 최대 용량에 도달했을 때 FreeBSD (UNIX 기반 Open Source OS) 설정에서 약 10%의 CPU와 15MB의 메모리를 사용했습니다. 동일한 매개변수를 사용하여 Apache는 1000개의 프로세스를 생성하고 엄청난 양의 RAM을 사용했습니다. Pound는 과도한 스레드를 생성하고 다양한 스레드 스택에 400MB 이상을 사용했습니다. 약간 더 많은 CPU가 필요했고 시간당 20MB 이상 낭비되었습니다.

5. NGINX 로 Atlantic.Net을 사용해 보세요.

Atlantic.Net에서는 이러한 다양한 당사자가 설명한 대로 NGINX를 사용하여 성능 향상을 이루어냈습니다. 우리는 또한 위에서 설명한 특정 기능에 대해 이점을 얻었습니다. 현재 Apache 또는 다른 웹 서버를 사용하고 있다면 NGINX를 사용하여 확장성과 계속 요구되는 확장성과 속도에 대한 요청을 더 잘 처리하는 데 도움이 되는 유사한 개선 사항을 확인할 수 있습니다. 오늘 클라우드 서버로 NGINX를 테스트하십시오.

NGINX에 대한 정보 또는 직접 사용해 보거나 테스트해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.

NGINX STORE를 통한 솔루션 도입 및 기술지원 무료 상담 신청

* indicates required