NGINX Socket Sharding

NGINX 는 DragonFly BSD 및 Linux를 포함한 많은 운영 체제의 최신 버전에서 사용할 수 있는 SO_REUSEPORT 소켓 옵션을 사용할 수 있는 기능이 있습니다. 이 Socket Sharding 을 사용하면 여러 소켓이 동일한 IP 주소와 포트 조합에서 수신 대기할 수 있습니다. 그러면 커널이 소켓에서 들어오는 연결의 부하를 분산합니다.

SO_REUSEPORT 소켓 옵션은 많은 잠재적인 실제 애플리케이션이 있습니다. 다른 서비스에서 실행 파일의 간편한 롤링 업그레이드를 위해 이 옵션을 사용할 수 있습니다(NGINX는 이미 다른 수단을 통해 업그레이드를 지원합니다). NGINX의 경우 이 소켓 옵션을 활성화하면 특정 시나리오에서 잠금 경합을 줄여 성능을 향상시킬 수 있습니다.

그림에 표시된 것처럼 SO_REUSEPORT 옵션이 활성화되지 않은 경우 단일 수신 소켓이 들어오는 연결을 worker에게 알리고 각 worker가 연결을 받으려고 시도합니다.

SO_REUSEPORT 옵션을 활성화하면 각 IP 주소와 포트 조합에 대해 각 worker process마다 하나씩 여러 개의 소켓 리스너가 있습니다. 커널은 사용 가능한 소켓 리스너(그리고 암시적으로 어떤 worker가 연결을 받을지)를 결정합니다. 이렇게 하면 새 연결을 수락하는 worker 간의 잠금 경합이 줄어들고 멀티코어 시스템에서 성능이 향상될 수 있습니다. 그러나 차단 작업으로 인해 worker가 정지되면 차단이 worker가 이미 수락한 연결뿐만 아니라 커널이 차단된 이후 worker에 할당된 연결 요청에도 영향을 미칠 수 있습니다.

목차

1. Socket Sharding 구성
2. reuseport를 통한 성능 벤치마킹
3. 감사 인사

1. Socket Sharding 구성

SO_REUSEPORT 소켓 옵션을 활성화하려면 이 예제에서와 같이 HTTP 또는 TCP(stream 모듈) 트래픽에 대한 listen 지시문에 새로운 reuseport 매개변수를 추가합니다:

http {
     server {
          listen 80 reuseport;
          server_name  localhost;
          # ...
     }
}

stream {
     server {
          listen 12345 reuseport;
          # ...
     }
}

reuseport 매개변수를 포함하면 뮤텍스가 reuse port와 중복되므로 소켓에 대한 accept_mutex 지시문도 비활성화됩니다. 재사용보고를 설정하지 않은 포트가 있는 경우에도 accept_mutex를 설정할 사치가 있습니다.

2. reuseport를 통한 성능 벤치마킹

36코어 AWS 인스턴스에서 4개의 NGINX worker로 wrk 벤치마크를 실행했습니다. 네트워크 효과를 제거하기 위해 로컬 호스트에서 클라이언트와 NGINX를 모두 실행하고 NGINX가 파일 대신 OK 문자열을 반환하도록 했습니다. 기본값(accept_mutex 켜짐에 해당), accept_mutex 꺼짐, reuseport의 세 가지 NGINX 구성을 비교했습니다. 그림에서 볼 수 있듯이 reuseport를 사용하면 초당 요청이 2~3배 증가하고 지연 시간과 지연 시간의 표준 편차가 모두 감소합니다.

또한 별도의 호스트에서 클라이언트와 NGINX를 사용하여 관련 벤치마크를 실행하고 NGINX가 HTML 파일을 반환하도록 했습니다. 다음 표에서 볼 수 있듯이 재사용 보고서의 지연 시간 감소는 이전 벤치마크와 비슷했으며 표준 편차는 훨씬 더 크게 감소했습니다(거의 10배). 표에 표시되지 않은 다른 결과도 고무적이었습니다. reuseport를 사용하면 worker process 전체에 부하가 고르게 분산되었습니다. 기본 조건(accept_mutex 켜짐과 동일)에서는 일부 worker가 더 높은 비율의 부하를 받으며, accept_mutex가 꺼진 상태에서는 모든 worker 가 높은 부하를 경험했습니다.

이 벤치마크에서는 연결 요청의 비율은 높지만 요청에 광범위한 처리가 필요하지 않습니다. 다른 예비 테스트에서도 트래픽이 이 프로필과 일치할 때 reuseport가 성능을 가장 크게 향상시키는 것으로 나타났습니다. (예를 들어 이메일 트래픽이 이 프로파일과 확실히 일치하지 않기 때문에 메일 컨텍스트의 listen 지시문에서는 reuseport 매개변수를 사용할 수 없습니다.) reuseport를 일괄 적용하기 보다는 테스트하여 NGINX 배포에서 성능이 개선되는지 확인하는 것이 좋습니다. NGINX 성능 테스트에 대한 몇 가지 팁은 nginx.conf 2014에서 Konstantin Pavlov의 강연을 확인하세요.

3. 감사 인사

SO_REUSEPORT 소켓 옵션을 사용할 수 있는 솔루션을 NGINX 프로젝트에 각각 기여해 주신 Intel의 Yingqu Lu와 Sepherosa Ziehau에게 감사드립니다. NGINX팀은 두 분의 기여에서 얻은 아이디어를 결합하여 이상적인 솔루션이라고 생각되는 것을 만들었습니다.

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

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