NGINX 릴리스 1.9.1의 소켓 샤딩

NGINX  1.9.1은 DragonFly BSD 및 Linux(커널 버전 3.9 이상)를 포함한 많은 운영 체제의 최신 버전에서 사용할 수 있는 소켓 옵션을 사용할 수 있는 새로운 기능을 도입합니다 SO_REUSEPORT. 이 소켓 옵션을 사용하면 여러 소켓이 동일한 IP 주소 및 포트 조합에서 수신할 수 있습니다. 그런 다음 커널은 소켓에서 들어오는 연결을 로드 밸런싱합니다.

소켓 SO_REUSEPORT옵션은 많은 잠재적인 실제 세계 응용 프로그램을 가지고 있습니다. 다른 서비스는 실행 파일의 쉬운 롤링 업그레이드에 사용할 수 있습니다(NGINX는 이미 다양한 수단을 통해 롤링 업그레이드를 지원합니다 ). NGINX의 경우 이 소켓 옵션을 활성화하면 잠금 경합을 줄여 특정 시나리오에서 성능을 개선할 수 있습니다.

그림에서 보듯이, SO_REUSEPORT해당 옵션이 활성화되어 있지 않으면 단일 수신 소켓이 워커에게 들어오는 연결을 알리고, 각 워커는 연결을 시도합니다.

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

소켓 샤딩 구성

소켓 옵션을 활성화하려면 다음 예와 같이 HTTP 또는 TCP( 스트림 모듈) 트래픽에 대한 지시문 에 SO_REUSEPORT새 매개변수를 포함시킵니다 .

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

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

매개변수를 포함하면 소켓에 대한 지시문 reuseport도 비활성화됩니다 . 뮤텍스가 .와 중복되기 때문입니다 . .를 설정하지 않은 포트가 있는 경우 설정하는 것이 여전히 가치가 있습니다 

벤치마킹 성능 reuseport

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

또한 클라이언트와 NGINX를 별도의 호스트에 두고 NGINX에서 HTML 파일을 반환하는 관련 벤치마크를 실행했습니다.다음 표에서 볼 수 있듯이 reuseport지연 시간 감소는 이전 벤치마크와 유사했고 표준 편차는 훨씬 더 극적으로 감소했습니다(거의 10배).표에 표시되지 않은 다른 결과도 고무적 이었습니다. 에서 reuseport부하는 작업자 프로세스 전체에 고르게 분산되었습니다.기본 조건(와 동일 accept_mutex on)에서 일부 작업자는 부하의 더 높은 백분율을 얻었고 accept_mutex off모든 작업자는 높은 부하를 경험했습니다.

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