NGINX 릴리스 1.9.1의 소켓 샤딩

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

편집기 – NGINX Plus 사용자의 경우 이 기능은 NGINX Plus 릴리스 7(R7) 이상에서 지원됩니다. 해당 릴리스의 모든 새로운 기능에 대한 개요는 블로그의 NGINX Plus R7 발표를 참조하세요.

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

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

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

소켓 샤딩 구성

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

http { 서버 { 듣기 80  reuseport ; 서버 이름 로컬 호스트; # ... } } 스트림 { 서버 { 수신 12345  재사용포트 ; # ... } }

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

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가 켜진 상태 와 동일)에서는 일부 작업자가 더 높은 비율의 부하를 받았고, accept_mutex가 꺼진 상태에서는 모든 작업자가 높은 부하를 경험했습니다.

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

감사의 말

NGINX 프로젝트에 SO_REUSEPORT 소켓 옵션을 사용할 수 있는 솔루션을 제공해 준 Intel의 Yingqi Lu와 Sepherosa Ziehau에게 감사드립니다. NGINX 팀은 두 가지 기여에서 얻은 아이디어를 결합하여 이상적인 솔루션을 만들어냈습니다.