[과거자료 발굴] 라이브 스트리밍 서비스 개발 전 HTTP 버전별 성능 차이 분석 및 워크로드별 웹 서버 및 웹 프레임워크 성능 실험 #100

ej31 · 2024-09-19T08:28:18Z

ej31
Sep 19, 2024
Maintainer

Important

Jeff: 해당 자료는 2017~18년도에 작성한 자료입니다.
실험 과정과 결과에 미흡한 점이 많아 공개하기 꺼려집니다만 여러분의 가이드를 위해 수치심을 내려놓고 공개합니다. 🫨

개요

기술자라면 서비스를 개발 및 운영 할 때 서비스의 워크로드 수준에 따라 어떤 상황이 주어져도 기술을 통해 유연하게 대응할 수 있어야 한다고 생각합니다.
관련해서 워크로드의 크기가 작은 상태일때 부터 점점 커지는 상태를 상정해서 다음과 같은 실증을 진행해보고자 합니다.
- 어떤 웹 서버(or 웹프레임워크)를 쓰는 것이 합당한지 비교 분석해보고자합니다.
- 웹 서버에서 응답을 할 때 HTTP 버전은 무조건 높은게 좋은 것인지, 각 버전별로 장점과 단점은 무엇이 있는지 조사하고자 합니다.

목표 설정 및 예측

웹서버가 동일한 환경에서 사용자의 요청을 받고 응답을 할 때

목적 1) 그 사이의 시간은 얼마나 걸리며(Latency)
- 단위 시간 별(1s 간격 1H) 사용자의 동시 다수 요청에 처리 시간이 얼만큼 나오는지
- 사용자가 작은 이미지부터 큰 이미지를 요청했을 때
- 사용자가 간단한 텍스트부터 큰 텍스트까지 요청했을 때
- 지연시간이 커지는 구간이 있을 것으로 예측합니다.
목적 2) 위와 같이 요청 했을 때에 잘못 반환 되는 양은? (Error Rate)
- Latency / Error Rate 측면에서 오류가 많이 발생하는 임계점과 비슷한 구간이 존재 하지 않을까?

결과 사전 추론

단위 시간 대비 요청 수 혹은 용량이 크면 느려지는 구간이 있을 것으로 예측하며 이 부분에 대한 실증을 진행

Latency 및 Error Rate 가 왜 중요한가?

User Preference and Search Engine Latency 에 따르면 사용자 경험을 최적화하기 위해서는 3초 이내의 응답 시간을 목표로 해야 하며, 특히 4초 이상의 지연은 사용자 이탈로 이어질 수 있음을 보여줍니다
또한 위와 같이 응답속도에 따른 사용자 이탈 관련 자료는 주변에 아주 많습니다.
- Google/SOASTA Research: "The State of Online Retail Performance"
  - 이 연구는 페이지 로드 시간과 이탈률 간의 관계를 분석하여, 모바일 사이트의 속도가 사용자 경험과 비즈니스 성과에 미치는 영향을 보여줍니다.
- Akamai: "Online Retail Performance Report"
  - - Akamai: "The State of Online Retail Performance" (pdf)
  - 이 보고서는 웹 성능이 전환율과 고객 충성도에 미치는 영향을 분석합니다.
  - 특히 모바일 사용자의 기대치에 대해 중요한 인사이트를 제공하는 포스팅입니다.
- Nielsen Norman Group: "Response Times: The 3 Important Limits"
  - 이 글은 사용자 인터페이스 응답 시간의 세 가지 중요한 한계를 설명하며, 웹 성능 최적화의 기본적인 지침을 제공합니다.
이와 같이 웹 서버의 응답속도는 워크로드 수준에 따라 얼마나 차이가 나는지 사전에 분석해 둘 필요가 있음을 시사합니다.
이에 웹 서버에서 최종 응답속도와 가장 밀접한 관계가 있는 Latency 및 Error Rate 를 기준으로 개발 중인 프로젝트에서 어떤 웹서버를 쓰는 것이 합당한지에 대해 실증을 해보고자 합니다.

Note

Jeff: 사실.. Latency 및 Error Rate 만 기준으로 잡은거 좀 실수한거 같습니다.. 🤔
P99, P95 와 같은 메트릭을 기준으로 잡고 왜 이런 차이가 나는지까지 분석했어야 하는데.. 이 점은 많이 아쉽습니다.

개발 예정인 프로젝트 내 웹 서버 사용 사례를 통한 실험 시나리오 설정

Note

이 부분은 가지고 있는 PPT 자료를 그대로 인용할께요 👴

프로젝트 내 어떤 부분에서 웹 서버 (+웹 프레임워크)를 사용하는지 들여다봤습니다.
아래와 같은 작업을 기본적으로 수행하게 됩니다.
아직 코드가 나오지 않은 상태이므로 아주 기본적인 Request <-> Response 요청을 기준으로 웹 서버 및 웹 프레임워크 성능을 실험해보고자 합니다.

Note

이 때는 헬스체크라는게 있는지도 몰랐습니다. 허허.. 👴

HTTP 버전별 성능 비교 및 특이사항 분석

Important

실제로 HTTP 1.1s 라는 용어는 없습니다.
여기서 1.1s 가 의미하는건 SSL을 지원하는 HTTP 1.1 을 의미합니다!

이 내용을 실험하기 위해 Client 측 요청부분은 h2load 를 사용했습니다.
- h2load는 HTTP Performance benchmark tool 입니다. 이 도구를 통해 Request 를 보내고 요청 및 응답 과정에 포함 된 각종 메트릭을 수집할 수 있습니다.
웹 서버는 nginx 를 사용했습니다.
- 이 실험의 경우 HTTP 버전의 버전별 특이점을 찾는 실험입니다.
- 따라서 nginx, apache 등 다양한 웹 서버를 고려하지 않아도 된다고 판단하여 백엔드 서버는 간단하게 nginx를 사용하여 실험을 진행했습니다.

실험 결론

단일 Browser HTTP Download Test - 1회차
단일 Browser HTTP Download Test - 2회차
결론 - HTTP 1.1 / 1.1s / 2

HTTP 버전별 실험결과 요약

HTTP 1.1
- 무선 저용량 다수
- 유선 저용량 다수
HTTP 1.1s
- 무선 저용량 다수
- 유선 저용량 다수
HTTP 2
- 무선 저용량 다수
- 유선 저용량 다수

Note

이거 실험한 영상 데이터도 있는데 사이즈가 워낙커서 안올라가네유..
시간될 때 ffmpeg으로 압축한번 해서 올려볼께요;;

실험 방법

nginx 의 config 설정을 통해 http 버전을 강제하는 방식을 사용했습니다.

server {
    # 아래 `http1.1` 부분을 수정해서 http 버전을 강제할 수 있습니다. 
    listen 80 default_server http1.1;
    server_name _;

    # 기타 설정들...
    ...
}

대상이 되는 파일 다운로드 설정
- nginx 서버를 통해 static file을 내려주는 방식을 사용했습니다.
- GIF, JPG, PNG 등의 파일을 약 1,000개 정도 준비해서 하나의 HTML 파일 내에 태그를 통해 모두 설정해두었습니다.
HTML 파일은 대략 아래와 같은 방식으로 작성했습니다.

Note

Jeff: 이 부분 코드가 없어져서 기억나는대로 적었습니다.. 🤡;;;

<head>
<!-- head 태그 설정 -->
<head>

<body>

<img src="/1.jpg">
<img src="/2.jpg">
...
<img src="/1000.jpg">

<img src="/1.png">
<img src="/2.png">
...
<img src="/1000.png">


<img src="/1.gif">
<img src="/2.gif">
...
<img src="/1000.gif">

</body>

위와 같이 설정한 뒤 크롬 브라우저의 개발자 도구를 직접 모니터링 했습니다.,

분석

Caution

작성예정

총평

HTTP/1.1 은 데이터를 가져올 때 한 번에 하나의 데이터만 가져올 수 있습니다.
HTTP/2 의 경우 여러가지 개선점이 있으나 그 중 가장 성능부분에서 큰 차이를 내는 기능은 multiplexing 기능입니다.
- 실험 결과 데이터에서 볼 수 있듯이 한 번에 여러개의 데이터를 가져올 수 있습니다.

[계속 작성 예정]

웹서버별 성능 측정 및 분석

Caution

작성 예정

어떤 웹 서버를 기준으로 테스트 할 것인가?

Caution

작성 중..

Web Framework 에 대해 성능 비교 자료를 게시한 사이트인 TechemPower 의 자료를 통해 어떤 웹 서버를 비교할 것인지 참고했습니다.
- 각 카테고리 별로 상위 항목에 포함되어 있는 웹 서버를 비교 대상으로 선정했습니다.
- Single Query
- Multiple Queries
- Data Updates
- Plaintext
Netcraft 사의 January 2018 Web Server Survey 자료를 추가로 참고했습니다.

용어 설명

워크로드

워크로드는 컴퓨터가 수행해야 하는 일의 양을 의미합니다. 학교 급식실을 예로 들어보겠습니다.
급식실에서 일하는 요리사와 주방 직원들을 컴퓨터 시스템이라고 생각해봅시다. 그리고 학생들이 먹어야 할 점심 식사를 준비하는 것이 워크로드입니다.

작은 워크로드: 20명의 학생을 위한 간식 준비하기

중간 워크로드: 100명의 학생을 위한 일반적인 점심 식사 준비하기

큰 워크로드: 전교생 500명을 위한 특별한 축제 날 뷔페 준비하기

각각의 경우, 필요한 재료(데이터), 조리 도구(컴퓨팅 파워), 요리사의 수(메모리), 주방 공간(저장 공간), 그리고 배식 시간(네트워크 자원)이 다릅니다.

워크로드의 특성

크기와 복잡성 측면으로 봤을때 간식 준비는 간단하지만, 축제 뷔페는 매우 복잡하고 많은 자원이 필요합니다.
시간에 따른 변화 측면으로 봤을때 평소에는 일반 점심이지만, 특별한 날에는 더 많은 준비가 필요합니다.
자원 관리 측면으로 봤을때 효율적으로 일하려면 재료, 도구, 인력을 잘 분배해야 합니다.
우선순위 측면으로 봤을때 알레르기가 있는 학생의 식사를 먼저 준비하는 것처럼, 중요한 작업을 먼저 처리해야 합니다.

DevOps 를 지망한다면 워크로드 수준에 따라서 기술을 유연하게 설계할 수 있어야 합니다.

ej31 · 2024-09-19T16:07:00Z

ej31
Sep 19, 2024
Maintainer Author

작성중입니데이..

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

100-hours-a-week

[과거자료 발굴] 라이브 스트리밍 서비스 개발 전 HTTP 버전별 성능 차이 분석 및 워크로드별 웹 서버 및 웹 프레임워크 성능 실험 #100

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

워크로드

워크로드의 특성

Replies: 1 comment

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

100-hours-a-week

[과거자료 발굴] 라이브 스트리밍 서비스 개발 전 HTTP 버전별 성능 차이 분석 및 워크로드별 웹 서버 및 웹 프레임워크 성능 실험 #100

Uh oh!

Uh oh!

ej31 Sep 19, 2024 Maintainer

개요

목표 설정 및 예측

웹서버가 동일한 환경에서 사용자의 요청을 받고 응답을 할 때

결과 사전 추론

Latency 및 Error Rate 가 왜 중요한가?

개발 예정인 프로젝트 내 웹 서버 사용 사례를 통한 실험 시나리오 설정

HTTP 버전별 성능 비교 및 특이사항 분석

실험 결론

HTTP 버전별 실험결과 요약

실험 방법

분석

총평

웹서버별 성능 측정 및 분석

어떤 웹 서버를 기준으로 테스트 할 것인가?

용어 설명

워크로드

워크로드의 특성

Replies: 1 comment

Uh oh!

ej31 Sep 19, 2024 Maintainer Author

ej31
Sep 19, 2024
Maintainer

ej31
Sep 19, 2024
Maintainer Author