Netflix Zuul 과 Nginx 의 성능 비교

이것 은 번역 입 니 다. 여러분 이 자주 의심 하 는 문제 입 니 다. API 게 이 트 웨 이 Zuul 의 성능 입 니 다.NETFLIX ZUUL VS NGINX PERFORMANCE 저자: STANISLAV MIKLIK
지금 너 는 마이크로 서비스 에 관 한 많은 정 보 를 들 을 수 있다.Spring Boot 는 하나의 마이크로 서비스 응용 을 구축 하 는 이상 적 인 선택 이지 만 어떤 방식 으로 서로 연결 시 켜 야 합 니 다.스프링 클 라 우 드 가 해결 하려 는 문제, 특히 스프링 클 라 우 드 넷 플 릭 스 다.이 는 유레카 서비스 발견 과 Ribbon 클 라 이언 트 부하 균형 의 결합 을 통 해 내부 '마이크로 서비스' 에 통신 지원 을 제공 합 니 다.그러나 외부 와 통신 하고 싶 을 때 (외부 API 를 제공 하거나 페이지 에서 만 AJAX 를 사용 하 는 경우) 각종 서 비 스 를 하나의 에이전트 뒤에 숨 기 는 것 이 현명 한 선택 이다.
일반적인 선택 은 Nginx 를 대리 로 사용 합 니 다.그러나 넷 플 릭 스 는 자신의 해결 방안 인 스마트 루트 Zuul 을 가 져 왔 다.인증, 서비스 이전, 등급 별 마 운 트 해제 및 각종 동적 경로 옵션 에 사용 할 수 있 는 재 미 있 는 기능 이 많이 있 습 니 다.동시에 자바 로 작 성 했 습 니 다.만약 넷 플 릭 스 가 그것 을 사용한다 면, 그것 은 로 컬 역방향 에이전트 에 비해 충분히 빠 를 까요?또는 우리 가 유연성 (또는 다른 기능) 에 대한 요구 가 높 을 때 Nginx 와 공동으로 사용 하기에 적합 합 니까?
면책 성명: 엄숙 한 기준 이 라 고 생각 하지 마라.나 는 단지 Nginx 와 Zuul 의 차 이 를 느끼 고 싶 을 뿐이다. 왜냐하면 나 는 인터넷 에서 어떠한 기준 도 찾 지 못 했 기 때문이다.추천 하 는 기준 테스트 방법 (예열 시간, 테스트 횟수...) 을 따 르 지 않 습 니 다. 저 는 사용 가능 한 지역 에 있 는 EC2 인 스 턴 스 3 개 만 사용 합 니 다. (이것 은 최선 이 아 닙 니 다.)
테스트
그럼 저 는 뭐 했 죠?테스트 는 두 가지 해결 방안 의 원시 적 인 성능 을 비교 하 는 것 으로 다른 특별한 기능 이 없다.HTML 페이지 를 가 져 오 려 면 하나의 HTTP 요청 을 동시에 할 뿐 입 니 다 (크기 는 약 26KB).나 는 아파 치 벤 치 를 사용 하여 200 개의 병렬 스 레 드 테스트 를 시작 했다. (나 도 httpperf 를 시 도 했 지만 더 높 은 CPU 요구 가 필요 하기 때문에 더 낮은 ab 를 선택 했다.)
직접 연결
우선, 내 가 관심 있 는 것 은 어떤 역방향 프 록 시 를 통 해 HTTP 서버 의 성능 에 직접 접근 하지 않 는 것 이다.Ab 는 대상 서버 에 직접 접근 하 는 기계 에서 실 행 됩 니 다.

$ ab -n 10000 -c 200 http://target/sample.html

....

Document Path: /sample.html
Document Length: 26650 bytes

Total transferred: 268940000 bytes
HTML transferred: 266500000 bytes
Requests per second: 2928.45 [#/sec] (mean)
Time per request: 68.295 [ms] (mean)
Time per request: 0.341 [ms] (mean, across all concurrent requests)
Transfer rate: 76911.96 [Kbytes/sec] received

Connection Times (ms)
 min mean[+/-sd] median max
Connect: 4 33 6.0 32 66
Processing: 20 35 7.5 35 392
Waiting: 20 35 6.4 34 266
Total: 24 68 7.8 66 423

Percentage of the requests served within a certain time (ms)
 50% 66
 66% 67
 75% 69
 80% 70
 90% 74
 95% 81
 98% 91
 99% 92
 100% 423 (longest request)

좋 습 니 다. 몇 번 의 테스트 에서 비슷 한 값 을 보 여 주 었 습 니 다. 2928, 2725, 2834, 2648 req / s 입 니 다.약간의 편차 가 있 지만, 이 숫자 들 은 아직 중요 하지 않다.
Nginx 통과 하기
지금 나 는 Nginx 의 대리 서 비 스 를 사용 할 수 있다.Nginx 설정 을 대상 서버 에 프 록 시 로 업데이트 하기 만 하면 됩 니 다. 예 를 들 어:

server {
   listen 80 default_server;
   listen [::]:80 default_server ipv6only=on;

   # Make site accessible from http://localhost/
   server_name localhost;

   # allow file upload
   client_max_body_size 10M;

   location / {
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $remote_addr;
      proxy_set_header Host $host;
      proxy_pass http://target:80;
   }
}

이전 처럼 실행 유형의 테스트:

$ ab -n 50000 -c 200 http://proxy/sample.html
...
Server Software: nginx/1.4.6
Server Hostname: proxy
Server Port: 80

Document Path: /sample.html
Document Length: 26650 bytes

Concurrency Level: 200
Time taken for tests: 52.366 seconds
Complete requests: 50000
Failed requests: 0
Total transferred: 1344700000 bytes
HTML transferred: 1332500000 bytes
Requests per second: 954.81 [#/sec] (mean)
Time per request: 209.465 [ms] (mean)
Time per request: 1.047 [ms] (mean, across all concurrent requests)
Transfer rate: 25076.93 [Kbytes/sec] received

Connection Times (ms)
 min mean[+/-sd] median max
Connect: 3 50 11.7 48 114
Processing: 37 159 11.9 160 208
Waiting: 36 159 11.9 160 207
Total: 40 209 10.4 209 256

Percentage of the requests served within a certain time (ms)
 50% 209
 66% 212
 75% 214
 80% 216
 90% 220
 95% 224
 98% 232
 99% 238
 100% 256 (longest request)

테스트 결 과 는 954, 954, 941 req / s 이다.성능 과 지연 이 나 빠 졌 다.
Zuul 통과 하기
지금 우 리 는 같은 기계 에 Zuul 을 설치 하고 있다.그것 의 응용 자 체 는 매우 간단 하 다.

@SpringBootApplication
@Controller
@EnableZuulProxy
public class DemoApplication {
    public static void main(String[] args) {
        new SpringApplicationBuilder(DemoApplication.class)
            .web(true).run(args);
    }
}

우 리 는 application.yml 에서 고정된 경로 규칙 을 정의 해 야 한다.

zuul:
  routes:
    sodik:
      path: /sodik/**
      url: http://target

이제 테스트 를 실행 해 봅 시다.

$ ab -n 50000 -c 200 http://proxy:8080/sodik/sample.html

Server Software: Apache-Coyote/1.1
Server Hostname: proxy
Server Port: 8080

Document Path: /sodik/sample.html
Document Length: 26650 bytes

Concurrency Level: 200
Time taken for tests: 136.164 seconds
Complete requests: 50000
Failed requests: 2
(Connect: 0, Receive: 0, Length: 2, Exceptions: 0)
Non-2xx responses: 2
Total transferred: 1343497042 bytes
HTML transferred: 1332447082 bytes
Requests per second: 367.20 [#/sec] (mean)
Time per request: 544.657 [ms] (mean)
Time per request: 2.723 [ms] (mean, across all concurrent requests)
Transfer rate: 9635.48 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 12 92.3 2 1010
Processing: 15 532 321.6 461 10250
Waiting: 10 505 297.2 441 9851
Total: 17 544 333.1 467 10270

Percentage of the requests served within a certain time (ms)
50% 467
66% 553
75% 626
80% 684
90% 896
95% 1163
98% 1531
99% 1864
100% 10270 (longest request)

결 과 는 나의 추측 보다 더 나쁘다.또한 두 번 의 요청 실패 도 볼 수 있 습 니 다.기본적으로 시간 초과 시간 은 10 초 이다.
우 리 는 더 많은 결 과 를 얻 었 다.

Document Path: /sodik/sample.html
Document Length: 26650 bytes

Concurrency Level: 200
Time taken for tests: 50.080 seconds
Complete requests: 50000
Failed requests: 0
Total transferred: 1343550000 bytes
HTML transferred: 1332500000 bytes
Requests per second: 998.39 [#/sec] (mean)
Time per request: 200.322 [ms] (mean)
Time per request: 1.002 [ms] (mean, across all concurrent requests)
Transfer rate: 26199.09 [Kbytes/sec] received

Connection Times (ms)
min mean[+/-sd] median max
Connect: 2 16 7.9 16 126
Processing: 15 184 108.1 203 1943
Waiting: 13 183 105.9 202 1934
Total: 18 200 107.8 218 1983

Percentage of the requests served within a certain time (ms)
50% 218
66% 228
75% 235
80% 239
90% 254
95% 287
98% 405
99% 450
100% 1983 (longest request)

와, 좋 은 개선 이다.자바 JIT 컴 파일 은 성능 에 어느 정도 도움 이 된다 고 생각 합 니 다. 그러나 이것 이 우연 의 일치 인지 확인 하고 다시 시도 해 보 세 요: 1010 req / sec.최종 결 과 는 나 에 게 있어 서 놀 라 운 일이 다.
결론.
Zuul 의 원시 성능 은 Nginx 에 매우 가깝다.사실 예측 을 시작 한 후에 제 테스트 결 과 는 약간 좋 았 습 니 다.Nginx 는 더 많은 예측 가능 한 성능 (변화 가 적 음) 을 보 여 주 었 습 니 다. 슬 프 게 도 Zuul 예열 기간 에 우 리 는 작은 고장 (150000 개의 요청 중 2 개 를 겪 었 습 니 다. 그러나 귀하 의 마이크로 서 비 스 는 잘못 사용 되 었 을 것 입 니 다. 그 렇 죠?)
따라서 만약 에 귀하 가 Zuul 의 추가 기능 을 사용 하거나 이 를 통 해 다른 Netflix 서비스 와 통합 (예 를 들 어 Eureka) 하여 더 많은 서비스 능력 을 얻 기 를 원한 다 면 Zuul 은 간단 한 역방향 대리 의 대체 제품 으로 매우 희망 적 으로 보 입 니 다.이것 도 넷 플 릭 스 가 사용 하 는 이유 일 수도 있 으 니 한번 시도 해 보 세 요.
전재 할 때 출처 를 밝 혀 주 십시오. 원문 은 다음 과 같 습 니 다.http://blog.didispace.com/zuul-vs-nginx-performance/