WildFly 및 JBoss 애플리케이션 서버 NGINX로 로드 밸런싱

단계별 설정 지침에 따라 NGINX 오픈소스 또는 NGINX Plus의 고급 기능을 사용하여 Wildfly (JBoss) 애플리케이션 서버의 부하를 분산합니다.

이 배포 가이드는 NGINX 오픈소스와 NGINX Plus를 사용하여 Wildfly (JBoss) 애플리케이션 서버 영역에 HTTP 및 HTTPS 트래픽을 로드 밸런싱하는 방법을 설명합니다. NGINX 오픈소스 또는 NGINX Plus를 필요에 따라 구성하는 데 필요한 완전한 지침을 제공합니다.

목차
1. NGINX 오픈소스 및 NGINX Plus 정보
2. Wildfly 및 JBoss 정보
3. 전제 조건 및 시스템 요구 사항
3-1. 샘플 값 및 텍스트 복사 정보
4. 클라이언트 트래픽에 대한 Wildfly SSL/TLS 인증서 구성
4-1. 자체 서명된 인증서 생성
4-2. 인증서 요청 생성
5. Wildfly 에 대한 NGINX 구성 파일 생성 및 수정
5-1. 업데이트 된 구성 Reload
6. NGINX 오픈소스 또는 NGINX Plus를 사용하여 Wildfly 기본 로드 밸런싱 구성
6-1. HTTP 및 HTTPS 트래픽을 위한 가상 서버 구성
6-2. Wildfly 기본 로드 밸런싱 구성
6-3. Wildfly 기본 세션 지속성 구성
6-4. WebSocket 트래픽의 프록시 구성
6-5. Wildfly 콘텐츠 캐싱 구성
6-6. HTTP/2 지원 구성
6-7. 기본 로드 밸런싱을 위한 전체 구성

1. NGINX 오픈소스 및 NGINX Plus 정보

NGINX 오픈소스는 확장성, 우수한 성능 및 작은 풋프린트로 인해 최근 몇 년간 인기를 얻은 오픈 소스 웹 서버 및 리버스 프록시입니다. NGINX 오픈소스는 처음에는 C10K 문제(단일 웹 서버에서 10,000개의 동시 연결 제공)를 해결하기 위해 만들어졌습니다. NGINX 오픈소스의 기능과 성능은 고성능 사이트의 필수 요소로서, 웹 사이트에서 1위 웹 서버입니다.

NGINX Plus는 NGINX 오픈소스의 상용 지원 버전입니다. NGINX Plus는 NGINX 오픈소스의 기능을 확장하여 JBoss 애플리케이션 서버 배포를 향상시키고 대규모 웹 애플리케이션 구축에 필수적인 기능을 제공하는 완전한 애플리케이션 전달 플랫폼입니다.

2. Wildfly 및 JBoss 정보

Wildfly는 2013년 이전에 JBoss Application Server 또는 간단히 JBoss로 불렸던 애플리케이션 서버입니다. Wildfly는 기업용 Java 애플리케이션, 포털 및 웹 애플리케이션 및 서비스를 개발하고 배포하기 위해 Java Enterprise Edition 7 플랫폼 (Java EE, 이전에는 J2EE로 알려져 있음)을 구현합니다. Java EE는 표준화된 모듈식 구성 요소의 사용을 허용하며, Java 플랫폼이 프로그래밍의 여러 측면을 자동으로 처리할 수 있도록 합니다. WildFly는 자유 및 오픈 소스 소프트웨어로, GNU Lesser General Public License (LGPL) 2.1 버전에 따라 배포됩니다. 이 가이드는 Wildfly 9에서 개발 및 테스트되었습니다.

Wildfly 소프트웨어의 상용 지원 버전은 Red Hat JBoss Enterprise Application Platform이며, 이 가이드는 이를 비롯한 상용 JBoss 애플리케이션 서버에도 적용됩니다.

3. 전제 조건 및 시스템 요구 사항

물리적 또는 가상 시스템에 설치 및 구성된 Wildfly 또는 JBoss 애플리케이션 서버
NGINX 오픈소스 또는 NGINX Plus를 호스팅하기 위한 Linux 시스템. 다른 애플리케이션과의 잠재적인 충돌을 피하기 위해 NGINX Plus는 새로운 물리적 또는 가상 시스템에 설치하는 것이 좋습니다. NGINX Plus가 지원하는 Linux 배포판 목록은 NGINX Plus 기술 사양을 참조하십시오.
NGINX 오픈소스 1.9.5 이상 또는 NGINX Plus R7 이상.

이 지침은 다음을 포함한 기본적인 Linux 시스템 관리 기술을 가지고 있다고 가정합니다. 이러한 작업에 대한 자세한 지침은 제공되지 않습니다.

Wildfly 애플리케이션의 구성 및 배포
공급업체에서 제공하는 패키지를 사용하여 Linux 소프트웨어 설치
구성 파일 편집
중앙 관리 시스템과 Linux 서버 간에 파일 복사
서비스 시작 및 중지를 위한 기본 명령 실행
로그 파일 읽기

3-1. 샘플 값 및 텍스트 복사 정보

example.com은 샘플 조직 이름으로 사용됩니다(키 이름 및 구성 블록에서). 이를 귀사의 조직 이름으로 대체하세요.
이 가이드의 많은 NGINX 오픈소스 및 NGINX Plus 구성 블록은 192.168.33.11 및 192.168.33.12와 같은 두 개의 샘플 Wildfly 애플리케이션 서버의 IP 주소를 나열합니다. 이 주소를 귀사의 Wildfly 서버의 IP 주소로 대체하세요. 서버가 두 개보다 많거나 적은 경우 각 서버에 대해 구성 블록에 한 줄을 추가하세요.
가독성을 위해 일부 명령은 여러 줄에 걸쳐 표시됩니다. 이를 터미널 창에 복사하여 붙여넣으려면 먼저 텍스트 편집기로 복사하여 배포에 적합한 개체 이름으로 대체하고 브라우저가 삽입할 수 있는 잡다한 서식 문자를 제거하는 것이 좋습니다.
이 가이드의 구성 스니펫에서 텍스트를 구성 파일로 복사하지 않는 것을 권장합니다. 구성 파일을 생성하는 권장 방법에 대해서는 “구성 파일 생성 및 수정”을 참조하십시오.

4. 클라이언트 트래픽에 대한 Wildfly SSL/TLS 인증서 구성

NGINX 오픈소스 또는 NGINX Plus와 Wildfly 애플리케이션의 클라이언트 간의 트래픽을 SSL/TLS 암호화로 보호하려는 경우, NGINX 오픈소스 또는 NGINX Plus를 위해 서버 인증서를 구성해야 합니다.

SSL/TLS 지원은 NGINX에서 제공하는 모든 NGINX Plus 패키지와 NGINX 오픈소스 이진 파일에서 기본적으로 활성화되어 있습니다.
NGINX 오픈소스를 소스에서 컴파일하는 경우, –with-http_ssl_module 매개변수를 포함하여 HTTP 트래픽에 대한 SSL/TLS 지원을 활성화하세요(TCP의 경우 –with-stream_ssl_module, 이메일의 경우 –with-mail_ssl_module이 해당 프로토콜 유형을 다루지만, 이 가이드에서는 해당 프로토콜 유형을 다루지 않습니다).
다른 공급업체에서 제공하는 이진 파일을 사용하는 경우, 해당 공급업체 문서를 참조하여 SSL/TLS를 지원하는지 확인하세요.
서버 인증서를 얻는 여러 가지 방법이 있습니다. 두 번째와 세 번째 옵션에 대한 단계별 지침이 제공되므로 편의를 위해 해당 옵션에 대한 지침을 따르세요.

다른 UNIX 또는 Linux 시스템(아파치 HTTP 서버를 실행하는 시스템 포함)에 이미 NGINX 오픈소스 또는 NGINX Plus용 SSL/TLS 인증서가 설치되어 있는 경우, 해당 인증서를 NGINX 오픈소스 또는 NGINX Plus 서버의 /etc/nginx/ssl 디렉토리로 복사하세요.
아래의 “자체 서명 인증서 생성”에 설명된 대로 자체 서명 인증서를 생성하세요. 이는 테스트 시나리오에는 충분하지만, 프로덕션 배포의 클라이언트는 일반적으로 인증 기관(CA)에 의해 서명된 인증서를 요구합니다.
아래의 “인증서 요청 생성”에 설명된 대로 CA 또는 귀사의 보안 그룹에게 새 인증서를 요청하세요.

4-1. 자체 서명된 인증서 생성

Public-Private 키 쌍과 이를 기반으로 하는 자체 서명 서버 인증서를 PEM 형식으로 생성합니다.

1. openssl 소프트웨어가 설치된 컴퓨터에서 root 사용자로 로그인하세요.

2. PEM 형식(기본값)의 키 쌍을 생성하세요. 개인 키를 암호화하려면 -des3 매개변수를 포함하세요. (다른 암호화 알고리즘은 genrsa 명령의 man 페이지에 나열되어 있습니다.) 암호화의 기반이 되는 암호를 입력하라는 메시지가 표시됩니다.

root# openssl genrsa -des3 -out ~/private-key.pem 2048
Generating RSA private key
Enter pass phrase for private-key.pem:

3. 안전한 위치에 키 파일의 백업을 만듭니다. 키를 분실하면 인증서를 사용할 수 없게 됩니다.

root# cp ~/private-key.pem <SECURE-DIR>/private-key.pem.backup

4. 인증서를 생성하세요. 새로운 자체 서명 인증서를 만들려면 -new 및 -x509 매개변수를 포함하세요. 선택적으로 -days 매개변수를 포함하여 키의 유효 기간을 기본값인 30일에서 변경할 수 있습니다(10950일은 약 30년입니다). 테스트 배포에 적합한 값으로 프롬프트에 응답하세요.

root# openssl req -new -x509 -key ~/private-key.pem -out ~/self-cert.pem -days 10950

5. 인증서 파일과 관련된 키 파일을 NGINX Open Source 또는 NGINX Plus 서버의 /etc/nginx/ssl 디렉토리로 복사하거나 이동하세요.

4-2. 인증서 요청 생성

1. openssl 소프트웨어가 설치된 시스템에서 root 사용자로 로그인합니다.

2. 인증서에 포함될 개인 키를 생성하세요.

root# openssl genrsa -out ~/example.com.key 2048

3. 키 파일의 백업을 안전한 위치에 생성하세요. 키를 잃어버리면 인증서를 사용할 수 없게 됩니다.

root# cp ~/example.com.key secure-dir/example.com.key.backup

4. 인증서 서명 요청 (CSR) 파일을 생성하세요.

root# openssl req -new -sha256 -key ~/example.com.key -out ~/example.com.csr

5. CSR 파일 (example.com.csr)을 제공하여 CA 또는 내부 보안 그룹에게 인증서를 요청하세요. 개인 키 (.key 파일)를 직접 제3자와 공유하지 않도록 주의하세요
인증서는 Windows 호환 PFX 형식이 아닌 PEM 형식이어야 합니다. CA 웹 사이트에서 직접 인증서를 요청하는 경우, 인증서를 생성할 서버 플랫폼으로 NGINX 또는 Apache (사용 가능한 경우)를 선택하세요.

5. Wildfly 에 대한 NGINX 구성 파일 생성 및 수정

오류를 줄이기 위해 이 가이드에서는 직접 지시문을 입력하는 대신 NGINX에서 제공하는 파일에서 지시문을 복사하여 구성 파일에 붙여넣도록 안내합니다. 그런 다음 이 가이드의 섹션(특히 HTTP 및 HTTPS 트래픽을 위한 가상 서버 구성부터 시작)을 따라가며 배포에 필요한 대로 지시문을 수정하는 방법을 익히세요.

제공된 파일 중 하나는 기본 로드 밸런싱을 위한 것이며(NGINX 오픈소스 또는 NGINX Plus 사용), 다른 하나는 향상된 로드 밸런싱을 위한 것입니다(NGINX Plus 사용). 새로운 Linux 시스템에 NGINX 오픈소스 또는 NGINX Plus를 설치하고 구성하고 Wildfly 트래픽을 로드 밸런싱하는 용도로만 사용하는 경우, 제공된 파일을 주 구성 파일로 사용할 수 있습니다. 이 파일은 전통적으로 /etc/nginx/nginx.conf 로 불립니다.

그러나 기존의 NGINX 오픈소스 또는 NGINX Plus 배포가 이미 있거나 앞으로 NGINX 오픈소스 또는 NGINX Plus를 다른 목적으로 확장할 계획이 있는 경우, 단일 구성 파일 대신 NGINX Plus 패키지를 설치할 때 자동으로 설정되는 구성 방식을 사용하는 것이 좋습니다. 전통적인 방식에서는 주 구성 파일은 여전히 /etc/nginx/nginx.conf로 불리지만, 모든 지시문을 포함하는 대신 다른 HTTP 관련 기능에 대한 별도의 구성 파일을 생성하고 /etc/nginx/conf.d 디렉토리에 파일을 저장합니다. 그런 다음 주 파일의 http 컨텍스트에서 include 지시문을 사용하여 기능별 파일의 내용을 읽어옵니다.

기본 로드 밸런싱을 위해 전체 구성 파일을 다운로드하려면 다음과 같이 하세요.

root# cd /etc/nginx/conf.d
root# curl https://www.nginx.com/resource/conf/jboss-basic.conf > jboss-basic.con

향상된 로드 밸런싱을 위해 전체 구성 파일을 다운로드하려면 다음과 같이 하세요.

root# cd /etc/nginx/conf.d
root# curl https://www.nginx.com/resource/conf/jboss-enhanced.conf > jboss-enhanced.conf

(또는 브라우저에서 해당 URL에 액세스하여 파일을 다운로드할 수도 있습니다.)

전통적인 구성 방식을 설정하려면 주 nginx.conf 파일에 http 구성 블록을 추가하세요(전역 지시문 아래에 표준적으로 배치됩니다). 적절한 파일 이름으로 이 include 지시문을 추가하세요.

http {
    include conf.d/jboss-(basic|enhanced).conf;
}

특정 기능이나 트래픽 유형에 해당하는 모든 파일을 참조하기 위해 와일드카드 표기법을 사용할 수도 있습니다. 예를 들어, 모든 HTTP 구성 파일을 function-http.conf로 지정한 경우 다음과 같은 include 지시문을 사용할 수 있습니다.

http {
    include conf.d/*-http.conf;
}

5-1. 업데이트 된 구성 Reload

구성 업데이트를 완료할 때마다 구성 파일의 구문 유효성을 테스트하기 위해 nginx -t 명령을 실행하는 것을 권장합니다.

root# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

6. NGINX 오픈소스 또는 NGINX Plus 를 사용하여 Wildfly 기본 로드 밸런싱 구성

이 섹션에서는 두 개의 Wildfly 서버 앞에 로드 밸런서로 NGINX 오픈 소스 또는 NGINX Plus를 설정하는 방법을 설명합니다.

6-1. HTTP 및 HTTPS 트래픽을 위한 가상 서버 구성

이러한 지시문은 상위 http 구성 블록의 별도의 server 블록에서 HTTP 및 HTTPS 트래픽을 위한 가상 서버를 정의합니다. 모든 HTTP 요청은 HTTPS 서버로 리다이렉션됩니다.

1. 포트 443에서 수신된 https://example.com 요청을 수신하는 server 블록을 구성하세요.
ssl_certificate 및 ssl_certificate_key 지시문은 필수입니다.
4. 클라이언트 트래픽에 대한 Wildfly SSL/TLS 인증서 구성에서 선택한 인증서와 개인 키의 이름으로 대체하세요.

# In the 'http' block
server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate     /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;
    ssl_session_cache   shared:SSL:1m;
    ssl_prefer_server_ciphers on;
}

2. 포트 80에서 수신된 http://example.com 요청을 HTTPS 서버로 영구적으로 리다이렉션하는 server 블록을 구성하세요. 이 server 블록은 이전 단계에서 정의한 HTTPS 서버입니다.
클라이언트 연결에 SSL/TLS를 사용하지 않는 경우 return 지시문을 생략하세요. 이 가이드의 나머지 부분에서 HTTPS 트래픽을 위한 server 블록에 지시문을 추가하라는 지시가 있을 때, 이 블록에 추가하세요.

# In the 'http' block
server {
    listen 80;
    server_name example.com;

    # Redirect all HTTP requests to HTTPS
    location / {
        return 301 https://$server_name$request_uri;
    }
}

6-2. Wildfly 기본 로드 밸런싱 구성

로드 밸런싱을 구성하기 위해 먼저 클라이언트 요청이 분산되는 백엔드 서버 목록을 나열하는 이름이 지정된 upstream 그룹을 생성합니다. 그런 다음 하나 이상의 proxy_pass 지시문에서 upstream 그룹을 참조하여 NGINX Open Source 또는 NGINX Plus를 리버스 프록시 및 로드 밸런서로 설정합니다.

1. jboss라는 upstream 그룹을 구성하세요. 이 그룹에는 포트 8080에서 수신 대기하는 두 개의 Wildfly 애플리케이션 서버가 있으며, 하나는 IP 주소 192.168.33.11에, 다른 하나는 192.168.33.12에 있습니다.

# In the 'http' block
upstream jboss {
    server 192.168.33.11:8080;
    server 192.168.33.12:8080;
}

HTTP 및 HTTPS 트래픽을 위해 구성한 HTTPS 트래픽용 서버 블록에 다음 두 개의 location 블록을 포함하세요:

첫 번째 location 블록은 경로가 /webapp/로 시작하는 HTTPS 요청과 일치하며, 이를 이전 단계에서 생성한 jboss upstream 그룹으로 프록시합니다.
두 번째 location 블록은 http://example.com/에 대한 모든 요청을 일시적으로 리다이렉션하여 모든 트래픽을 첫 번째 location 블록으로 보냅니다.

# In the 'server' block for HTTPS traffic
location /webapp/ {
    proxy_pass http://jboss;
}

location = / {
    return 302 /webapp/;
}

NGINX 오픈소스 및 NGINX Plus는 기본적으로 Round Robin 알고리즘을 사용하여 서버 간 로드 밸런싱을 수행합니다. 로드 밸런서는 upstream 그룹의 서버 목록을 순서대로 실행하며, 각 새로운 요청을 다음 서버로 전달합니다. 예를 들어, 첫 번째 요청은 192.168.33.11로 전달되고, 두 번째 요청은 192.168.33.12로 전달되며, 세 번째 요청은 다시 192.168.33.11로 전달됩니다.

6-3. Wildfly 기본 세션 지속성 구성

애플리케이션이 기본 세션 지속성(스티키 세션으로도 알려짐)을 필요로 하는 경우, NGINX Open Source에서 IP Hash 로드 밸런싱 알고리즘을 사용하여 구현할 수 있습니다.

IP Hash 알고리즘을 사용하면 각 요청마다 클라이언트의 IP 주소를 기반으로 한 해시가 계산되고 해당 해시가 하나의 upstream 서버와 연결됩니다. 해당 해시를 가진 모든 요청은 해당 서버로 전송되어 세션 지속성이 확립됩니다.

클라이언트가 IPv6 주소를 가지고 있는 경우, 해시는 전체 주소를 기반으로 계산됩니다. IPv4 주소를 가지고 있는 경우, 해시는 주소의 첫 번째 세 개의 옥텟만을 기반으로 합니다. 이는 IP 주소를 동적으로 서브네트워크(/24) 범위에서 할당받는 ISP 클라이언트에 대해 최적화되어 있습니다. 그러나 다음과 같은 경우에는 효과적이지 않습니다:

사이트로의 대부분의 트래픽이 하나의 포워드 프록시에서 또는 동일한 /24 네트워크의 클라이언트에서 오는 경우, IP Hash는 모든 클라이언트를 동일한 서버로 매핑합니다.
클라이언트의 IP 주소가 세션 중에 변경될 수 있는 경우, 예를 들어 모바일 클라이언트가 WiFi 네트워크에서 셀룰러 네트워크로 전환하는 경우.

NGINX에서 세션 지속성을 구성하려면 6-2. Wildfly 기본 로드 밸런싱 구성에서 생성된 업스트림 블록에 ip_hash 지시문을 추가합니다.

# In the 'http' block
upstream jboss {
    ip_hash;
    server 192.168.33.11:8080;
    server 192.168.33.12:8080;
}

세션 지속성을 위해 Hash 로드 밸런싱 방법을 사용할 수도 있습니다. 이 경우 지정한 텍스트 및 NGINX 변수의 조합을 기반으로 해시를 생성할 수 있습니다. 예를 들어, 다음 구성을 사용하여 전체 (4 octet) 클라이언트 IP 주소를 기반으로 해시를 생성할 수 있습니다.

# In the 'http' block
upstream jboss {
    hash $remote_addr;
    server 192.168.33.11:8080;
    server 192.168.33.12:8080;
}

6-4. WebSocket 트래픽의 프록시 구성

WebSocket 프로토콜(RFC 6455에서 정의됨)은 클라이언트와 서버 간의 단일 TCP 연결을 통해 동시에 양방향 통신을 가능하게 합니다. 각 측면은 다른 측면과 독립적으로 데이터를 전송할 수 있습니다.
WebSocket 연결을 초기화하기 위해 클라이언트는 서버로 핸드쉐이크 요청을 보내어 요청을 표준 HTTP에서 WebSocket으로 업그레이드합니다.
핸드쉐이크 요청이 유효성 검사를 통과하고 서버가 요청을 수락하면 연결이 설정됩니다.
WebSocket 연결이 생성되면 브라우저 클라이언트는 서버로 데이터를 보낼 수 있으면서 동시에 해당 서버로부터 데이터를 수신할 수 있습니다.

WebSocket 프로토콜은 Wildfly 애플리케이션 서버에서 기본적으로 작동하므로 추가적인 Wildfly 구성은 필요하지 않습니다. NGINX Open Source 또는 NGINX Plus가 WebSocket 트래픽을 Wildfly 애플리케이션 서버로 프록시하려면 이 섹션에서 설명하는 지시문을 추가하세요.

NGINX Open Source 및 NGINX Plus는 기본적으로 업스트림 연결에 HTTP/1.0을 사용합니다. WebSocket 연결을 올바르게 프록시하려면 HTTP/1.1과 함께 일부 다른 구성 지시문이 필요합니다. 이 지시문은 HTTP 헤더를 설정합니다.

# In the 'http' block
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

# In the 'server' block for HTTPS traffic
location /wstunnel/ {
    proxy_pass http://jboss;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
}

첫 번째 proxy_set_header 지시문은 Upgrade 요청 헤더가 hop-by-hop이기 때문에 필요합니다. 즉, HTTP 사양에서 명시적으로 프록시가 해당 헤더를 전달하는 것을 금지하고 있습니다. 이 지시문은 이 금지를 무시합니다.

두 번째 proxy_set_header 지시문은 Connection 헤더를 map 블록의 테스트에 따라 설정합니다. 요청에 Upgrade 헤더가 있는 경우 Connection 헤더는 upgrade로 설정되고, 그렇지 않은 경우 close로 설정됩니다.

6-5. Wildfly 콘텐츠 캐싱 구성

Wildfly 애플리케이션 서버에서의 응답 캐싱은 클라이언트에 대한 응답 시간을 개선하고 서버의 부하를 줄일 수 있습니다.
캐시 가능한 응답은 서버에서 다시 생성하는 대신 캐시에서 즉시 제공되기 때문입니다. 캐싱 동작을 세밀하게 조정하기 위해 사용할 수 있는 다양한 유용한 지시문이 있습니다.

캐싱을 위한 선택 사항 중 하나는 Red Hat에서 개발한 오픈 소스 분산 캐시 및 Key-Value NoSQL 데이터 저장소인 Infinispan입니다. Java 애플리케이션 서버(Wildfly 및 JBoss 포함)는 라이브러리로서 내장하거나 TCP/IP를 통해 원격 서비스로 사용할 수 있습니다.

다른 대안은 NGINX 오픈소스 호스트에서 서버 응답을 캐시하는 것입니다. 다음 구성을 사용하여 이를 수행할 수 있습니다.

1. proxy_cache_path 지시문을 포함하여 캐시로 사용할 로컬 디스크 디렉토리 /tmp/NGINX_cache/를 생성합니다. keys_zone 매개변수는 backcache라는 캐시 키와 사용 시간 등의 메타데이터를 저장하는 데 사용되는 backcache라는 이름의 존에 10 메가바이트(MB)의 공유 메모리를 할당합니다. 1MB의 존은 약 8,000개의 키에 대한 데이터를 저장할 수 있습니다.

# In the 'http' block
proxy_cache_path /tmp/NGINX_cache/ keys_zone=backcache:10m;

2. 경로가 /webapp/로 시작하는 HTTPS 요청과 일치하는 location 블록에 이전 단계에서 생성한 캐시를 참조하기 위해 proxy_cache 지시문을 포함하세요.

# In the 'server' block for HTTPS traffic
location /webapp/ {
    proxy_pass http://jboss;
    proxy_cache backcache;
}

6-6. HTTP/2 지원 구성

NGINX Open Source 1.9.5 이상 및 NGINX Plus R7 이상에서는 HTTP/2가 완전히 지원됩니다.
항상 개선 사항과 버그 수정을 활용하기 위해 최신 버전의 소프트웨어를 실행하는 것을 권장합니다.

NGINX Open Source를 사용하는 경우, 버전 1.9.5 이상에서는 SPDY 모듈이 완전히 제거되고 HTTP/2 모듈로 대체되었음을 유의하세요. 버전 1.9.5 이상으로 업그레이드한 후에는 더 이상 NGINX Open Source를 SPDY로 구성할 수 없습니다. SPDY를 계속 사용하려면 NGINX Open Source를 NGINX 1.8.x 브랜치의 소스에서 컴파일해야 합니다.

NGINX Plus R8 이상에서는 NGINX Plus가 기본적으로 HTTP/2를 지원합니다. (SPDY 지원은 해당 릴리스부터 사용이 중지되었습니다). 구체적으로 다음과 같습니다:

NGINX Plus R11 이상에서는 nginx-plus 패키지가 기본적으로 HTTP/2를 지원하며, 이전 릴리스에서 사용 가능한 nginx-plus-extras 패키지는 동적 모듈에 의해 사용이 중지되었습니다.
NGINX Plus R8부터 R10까지, nginx-plus 및 nginx-plus-extras 패키지는 기본적으로 HTTP/2를 지원합니다.
NGINX Plus R7을 사용하는 경우, nginx-plus 또는 nginx-plus-extras 패키지 대신 nginx-plus-http2 패키지를 설치해야 합니다.

HTTP/2 지원을 활성화하려면 6-1. HTTP 및 HTTPS 트래픽을 위한 가상 서버 구성에서 생성한 HTTPS 트래픽용 server 블록의 listen 지시문에 http2 매개변수를 추가하여 다음과 같이 설정하세요.

# In the 'server' block for HTTPS traffic
listen 443 ssl http2;

6-7. 기본 로드 밸런싱을 위한 전체 구성

편의를 위해 기본 로드 밸런싱을 위한 전체 구성 파일이 여기에 나와 있습니다. 이 구성은 http 컨텍스트에 들어갑니다. 전체 파일은 NGINX 웹사이트에서 다운로드할 수 있습니다.

이 문서에서 텍스트를 직접 복사하지 않고, 대신 “구성 파일 생성 및 수정”에 설명된 방법을 사용하여 이러한 지시문을 구성에 포함하는 것을 권장합니다. /etc/nginx/conf.d/jboss-basic.conf의 내용을 읽어오기 위해 nginx.conf 파일의 http 컨텍스트에 include 지시문을 추가하세요.

proxy_cache_path /tmp/NGINX_cache/ keys_zone=backcache:10m;

map $http_upgrade $connection_upgrade {  
    default upgrade;  
    ''      close;  
}

upstream jboss {  
    # Use IP Hash for session persistence  
    ip_hash;

    # List of Wildfly application servers  
    server 192.168.33.11:8080;  
    server 192.168.33.12:8080;  
}

server {  
    listen 80;  
    server_name example.com;

    # Redirect all HTTP requests to HTTPS  
    location / { 
        return 301 https://$server_name$request_uri; 
    } 
}

server {  
    listen 443 ssl http2;  
    server_name example.com;
    
    ssl_certificate     /etc/nginx/ssl/<certificate-name>;  
    ssl_certificate_key /etc/nginx/ssl/<private-key>;
    ssl_session_cache   shared:SSL:1m;  
    ssl_prefer_server_ciphers on;

    # Load balance requests for '/webapp/' across Wildfly application servers  
    location /webapp/ {  
        proxy_pass http://jboss;  
        proxy_cache backcache;  
    }

    # Return a temporary redirect to '/webapp/' when user requests '/'  
    location = / {  
        return 302 /webapp/;  
    }

    # WebSocket configuration  
    location /wstunnel/ { 
        proxy_pass https://jboss;  
        proxy_http_version 1.1;  
        proxy_set_header Upgrade $http_upgrade; 
        proxy_set_header Connection $connection_upgrade;  
    }  
}

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

WildFly 및 JBoss 애플리케이션 서버 NGINX로 로드 밸런싱

1. NGINX 오픈소스 및 NGINX Plus 정보

2. Wildfly 및 JBoss 정보

3. 전제 조건 및 시스템 요구 사항

3-1. 샘플 값 및 텍스트 복사 정보

4. 클라이언트 트래픽에 대한 Wildfly SSL/TLS 인증서 구성

4-1. 자체 서명된 인증서 생성

4-2. 인증서 요청 생성

5. Wildfly 에 대한 NGINX 구성 파일 생성 및 수정

5-1. 업데이트 된 구성 Reload

6. NGINX 오픈소스 또는 NGINX Plus 를 사용하여 Wildfly 기본 로드 밸런싱 구성

6-1. HTTP 및 HTTPS 트래픽을 위한 가상 서버 구성

6-2. Wildfly 기본 로드 밸런싱 구성

6-3. Wildfly 기본 세션 지속성 구성

6-4. WebSocket 트래픽의 프록시 구성

6-5. Wildfly 콘텐츠 캐싱 구성

6-6. HTTP/2 지원 구성

6-7. 기본 로드 밸런싱을 위한 전체 구성

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

이것이 좋아요:

관련

Recent News

Istio Ambient Mesh 적용과 NGINX Plus…

NGINX One 으로 시작하는 F5 WAF…

NGINX Gateway Fabric Rate Limit 설정…

Category

Contact Us

Company

API Gateway

Contacts

WildFly 및 JBoss 애플리케이션 서버 NGINX로 로드 밸런싱

1. NGINX 오픈소스 및 NGINX Plus 정보

2. Wildfly 및 JBoss 정보

3. 전제 조건 및 시스템 요구 사항

3-1. 샘플 값 및 텍스트 복사 정보

4. 클라이언트 트래픽에 대한 Wildfly SSL/TLS 인증서 구성

4-1. 자체 서명된 인증서 생성

4-2. 인증서 요청 생성

5. Wildfly 에 대한 NGINX 구성 파일 생성 및 수정

5-1. 업데이트 된 구성 Reload

6. NGINX 오픈소스 또는 NGINX Plus 를 사용하여 Wildfly 기본 로드 밸런싱 구성

6-1. HTTP 및 HTTPS 트래픽을 위한 가상 서버 구성

6-2. Wildfly 기본 로드 밸런싱 구성

6-3. Wildfly 기본 세션 지속성 구성

6-4. WebSocket 트래픽의 프록시 구성

6-5. Wildfly 콘텐츠 캐싱 구성

6-6. HTTP/2 지원 구성

6-7. 기본 로드 밸런싱을 위한 전체 구성

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

이 글이 도움이 되셨다면 SNS 또는 mail로 공유하셔서 가치를 나누세요!

이것이 좋아요:

관련

Recent News

Istio Ambient Mesh 적용과 NGINX Plus…

NGINX One 으로 시작하는 F5 WAF…

NGINX Gateway Fabric Rate Limit 설정…

Category

Popular Tag

Contact Us

NGINX STORE에서 더 알아보기