웹 애플리케이션은 이제 모든 곳에서 사용되고 있으며, 모든 전송 프로토콜 중에서 HTTP가 가장 큰 비중을 차지하고 있습니다. 웹 애플리케이션 개발의 미묘한 차이를 연구할 때 대부분의 사람들은 이러한 애플리케이션이 실제로 실행되는 운영 체제에는 거의 관심을 기울이지 않습니다. 개발(Dev)과 운영(Ops)이 분리되면서 상황은 더욱 악화되었습니다. 그러나 DevOps 문화가 증가함에 따라 개발자는 클라우드에서 애플리케이션을 실행하는 책임을 갖게 되므로 운영 체제의 백엔드에 완전히 익숙해지는 것이 매우 유용합니다. 이는 수천 또는 수만 개의 동시 연결을 위해 시스템을 배포하려는 경우 특히 유용합니다.

웹 서비스의 제한 사항은 다른 응용 프로그램의 제한 사항과 매우 유사합니다. 로드 밸런서이든 데이터베이스 서버이든 이러한 모든 애플리케이션은 고성능 환경에서 비슷한 문제를 안고 있습니다. 이러한 근본적인 한계와 일반적인 극복 방법을 이해하면 웹 애플리케이션의 성능과 확장성을 평가하는 데 도움이 됩니다.

나는 박식한 시스템 설계자가 되기를 원하는 젊은 개발자들의 질문에 응답하여 이 기사 시리즈를 쓰고 있습니다. 운영 체제 수준에서 작동 방식에 대한 기본 사항을 자세히 살펴보지 않고 Linux 애플리케이션 최적화 기술을 명확하게 이해하는 것은 불가능합니다. 다양한 유형의 애플리케이션이 있지만 이 시리즈에서는 브라우저나 텍스트 편집기와 같은 데스크톱 애플리케이션보다는 웹 기반 애플리케이션을 살펴보고 싶습니다. 이 자료는 Linux 또는 Unix 프로그램의 작동 방식과 고성능을 위해 구성하는 방법을 이해하려는 개발자 및 설계자를 대상으로 합니다.

리눅스는 서버 룸 운영 체제이며 대부분의 응용 프로그램은 이 OS에서 실행됩니다. 내가 "Linux"라고 말했지만 대부분의 경우 일반적으로 모든 Unix 계열 운영 체제를 의미한다고 가정할 수 있습니다. 그러나 다른 시스템에서는 함께 제공되는 코드를 테스트하지 않았습니다. 따라서 FreeBSD나 OpenBSD에 관심이 있다면 결과가 달라질 수 있습니다. 나는 Linux와 관련된 것을 시도할 때 그것을 지적합니다.

이 지식을 사용하여 처음부터 앱을 구축하면 완벽하게 최적화될 수 있지만 그렇게 하지 않는 것이 가장 좋습니다. 조직의 비즈니스 애플리케이션을 위해 C 또는 C++로 새 웹 서버를 작성한다면 오늘이 작업의 마지막 날일 수 있습니다. 그러나 이러한 응용 프로그램의 구조를 아는 것은 기존 프로그램을 선택하는 데 도움이 됩니다. 프로세스 기반 시스템을 스레드 기반 시스템 및 이벤트 기반 시스템과 비교할 수 있습니다. Nginx가 Apache httpd보다 더 나은 성능을 발휘하는 이유와 Tornado 기반 Python 애플리케이션이 Django 기반 Python 애플리케이션에 비해 더 많은 사용자에게 서비스를 제공할 수 있는 이유를 이해하고 감사하게 될 것입니다.

ZeroHTTPd: 학습 도구

제로HTTPd 는 교육 도구로 처음부터 C로 작성한 웹 서버입니다. Redis에 대한 액세스를 포함하여 외부 종속성이 없습니다. 우리는 자체 Redis 절차를 실행합니다. 자세한 내용은 아래를 참조하세요.

이론을 길게 논의할 수는 있지만 코드를 작성하고 실행하고 모든 서버 아키텍처를 서로 비교하는 것보다 더 좋은 것은 없습니다. 이것이 가장 확실한 방법이다. 따라서 우리는 프로세스 기반, 스레드 기반, 이벤트 기반의 각 모델을 사용하여 간단한 ZeroHTTPd 웹 서버를 작성하겠습니다. 각 서버를 확인하고 서로 비교하여 성능이 어떤지 살펴보겠습니다. ZeroHTTPd는 단일 C 파일로 구현되며 이벤트 기반 서버에는 다음이 포함됩니다. 우타쉬, 단일 헤더 파일로 제공되는 훌륭한 해시 테이블 구현입니다. 다른 경우에는 프로젝트를 복잡하게 하지 않기 위해 종속성이 없습니다.

코드에는 이해를 돕기 위한 많은 주석이 있습니다. 몇 줄의 코드로 구성된 간단한 웹 서버인 ZeroHTTPd는 웹 개발을 위한 최소한의 프레임워크이기도 합니다. 기능이 제한되어 있지만 정적 파일과 매우 간단한 "동적" 페이지를 제공할 수 있습니다. ZeroHTTPd는 고성능 Linux 애플리케이션을 만드는 방법을 배우는 데 좋다고 말하고 싶습니다. 대체로 대부분의 웹 서비스는 요청을 기다리고 확인하고 처리합니다. 이것이 바로 ZeroHTTPd가 수행하는 작업입니다. 이는 생산을 위한 도구가 아닌 학습을 위한 도구입니다. 오류 처리 능력이 뛰어나지 않으며 최고의 보안 사례를 자랑하지도 않습니다. strcpy) 또는 C 언어의 영리한 트릭이지만 그것이 잘 작동하기를 바랍니다.

ZeroHTTPd 홈페이지. 이미지를 포함한 다양한 파일 형식을 출력할 수 있습니다.

방명록 신청

최신 웹 애플리케이션은 일반적으로 정적 파일에만 국한되지 않습니다. 그들은 다양한 데이터베이스, 캐시 등과 복잡한 상호 작용을 합니다. 따라서 우리는 방문자가 자신의 이름 아래에 항목을 남기는 "Guest Book"이라는 간단한 웹 애플리케이션을 만들 것입니다. 방명록에는 이전에 남겨진 항목이 저장됩니다. 페이지 하단에도 방문자 카운터가 있습니다.

웹 애플리케이션 "Guest Book" ZeroHTTPd

방문자 카운터와 방명록 항목은 Redis에 저장됩니다. Redis와의 통신을 위해 자체 절차가 구현되며 외부 라이브러리에 의존하지 않습니다. 나는 공개적으로 사용 가능하고 잘 테스트된 솔루션이 있을 때 홈브류 코드를 출시하는 것을 좋아하지 않습니다. 그러나 ZeroHTTPd의 목적은 Linux 성능과 외부 서비스에 대한 액세스를 연구하는 반면, HTTP 요청을 처리하는 것은 성능에 심각한 영향을 미칩니다. 우리는 각 서버 아키텍처에서 Redis와의 통신을 완전히 제어해야 합니다. 일부 아키텍처에서는 차단 호출을 사용하고 다른 아키텍처에서는 이벤트 기반 절차를 사용합니다. 외부 Redis 클라이언트 라이브러리를 사용하면 이 제어 기능이 제공되지 않습니다. 또한 우리의 작은 Redis 클라이언트는 몇 가지 기능(키 가져오기, 설정 및 증가, 배열 가져오기 및 추가)만 수행합니다. 게다가 Redis 프로토콜은 매우 우아하고 단순합니다. 특별히 가르칠 필요도 없습니다. 프로토콜이 약 XNUMX줄의 코드로 모든 작업을 수행한다는 사실은 프로토콜이 얼마나 잘 고안되었는지를 보여줍니다.

다음 그림은 클라이언트(브라우저)가 요청할 때 애플리케이션이 수행하는 작업을 보여줍니다. /guestbookURL.

방명록 애플리케이션 작동 방식

방명록 페이지를 발행해야 하는 경우 템플릿을 메모리로 읽어들이기 위해 파일 시스템을 한 번 호출하고 Redis를 세 번 네트워크 호출합니다. 템플릿 파일에는 위 스크린샷에 있는 페이지에 대한 대부분의 HTML 콘텐츠가 포함되어 있습니다. 콘텐츠의 동적 부분(게시물 및 방문자 카운터)을 위한 특별한 자리 표시자도 있습니다. Redis에서 이를 받아 페이지에 삽입하고 클라이언트에게 완전한 콘텐츠를 제공합니다. Redis가 증가하면 새 키 값을 반환하므로 Redis에 대한 세 번째 호출을 피할 수 있습니다. 그러나 비동기 이벤트 기반 아키텍처를 갖춘 우리 서버의 경우 많은 네트워크 호출은 학습 목적으로 좋은 테스트입니다. 그래서 우리는 방문자 수의 Redis 반환 값을 버리고 별도의 호출로 쿼리합니다.

서버 아키텍처 ZeroHTTPd

우리는 기능은 동일하지만 아키텍처가 다른 XNUMX가지 버전의 ZeroHTTPd를 구축하고 있습니다.

• 반복적 인
• 포크 서버(요청당 하나의 하위 프로세스)
• 프리포크 서버(프로세스 프리포크)
• 실행 스레드가 있는 서버(요청당 스레드 XNUMX개)
• 사전 스레드 생성 기능이 있는 서버
• 아키텍처 기반 poll()
• 아키텍처 기반 epoll

우리는 HTTP 요청으로 서버를 로드하여 각 아키텍처의 성능을 측정합니다. 그러나 고도로 병렬화된 아키텍처를 비교할 때는 쿼리 수가 증가합니다. 세 번 테스트하고 평균을 계산합니다.

테스트 방법론

ZeroHTTPd 로드 테스트 설정

테스트를 실행할 때 모든 구성 요소가 동일한 시스템에서 실행되지 않는 것이 중요합니다. 이 경우 구성 요소가 CPU를 놓고 경쟁하므로 OS에 추가 스케줄링 오버헤드가 발생합니다. 선택한 각 서버 아키텍처의 운영 체제 오버헤드를 측정하는 것은 이 연습의 가장 중요한 목표 중 하나입니다. 더 많은 변수를 추가하면 프로세스에 해로울 수 있습니다. 따라서 위 그림의 설정이 가장 잘 작동합니다.

각 서버는 어떤 역할을 합니까?

• load.unixism.net: 여기가 우리가 실행하는 곳입니다. ab, Apache 벤치마크 유틸리티. 서버 아키텍처를 테스트하는 데 필요한 로드를 생성합니다.
• nginx.unixism.net: 때로는 서버 프로그램의 인스턴스를 두 개 이상 실행하고 싶을 때가 있습니다. 이를 위해 적절한 설정을 갖춘 Nginx 서버는 다음에서 오는 로드 밸런서로 작동합니다. ab 우리 서버 프로세스에.
• zerohttpd.unixism.net: 여기에서는 한 번에 하나씩 XNUMX개의 서로 다른 아키텍처에서 서버 프로그램을 실행합니다.
• redis.unixism.net: 이 서버는 방명록 항목과 방문자 카운터가 저장되는 Redis 데몬을 실행합니다.

모든 서버는 동일한 프로세서 코어에서 실행됩니다. 아이디어는 각 아키텍처의 최대 성능을 평가하는 것입니다. 모든 서버 프로그램은 동일한 하드웨어에서 테스트되므로 이는 비교를 위한 기준이 됩니다. 내 테스트 설정은 Digital Ocean에서 임대한 가상 서버로 구성되어 있습니다.

우리는 무엇을 측정하고 있나요?

다양한 지표를 측정할 수 있습니다. 우리는 다양한 병렬 처리 수준의 요청으로 서버를 로드하여 특정 구성에서 각 아키텍처의 성능을 평가합니다. 로드는 동시 사용자 20명에서 15명으로 증가합니다.

시험 결과

다음 차트는 다양한 수준의 병렬 처리에서 다양한 아키텍처의 서버 성능을 보여줍니다. y축은 초당 요청 수이고 x축은 병렬 연결입니다.

아래는 결과를 담은 표입니다.

초당 요청

동시성
반복적 인
포크
프리포크
스트리밍
사전 스트리밍
투표
Epoll

20
7
112
2100
1800
2250
1900
2050

50
7
190
2200
1700
2200
2000
2000

100
7
245
2200
1700
2200
2150
2100

200
7
330
2300
1750
2300
2200
2100

300
-
380
2200
1800
2400
2250
2150

400
-
410
2200
1750
2600
2000
2000

500
-
440
2300
1850
2700
1900
2212

600
-
460
2400
1800
2500
1700
2519

700
-
460
2400
1600
2490
1550
2607

800
-
460
2400
1600
2540
1400
2553

900
-
460
2300
1600
2472
1200
2567

1000
-
475
2300
1700
2485
1150
2439

1500
-
490
2400
1550
2620
900
2479

2000
-
350
2400
1400
2396
550
2200

2500
-
280
2100
1300
2453
490
2262

3000
-
280
1900
1250
2502
큰 확산
2138

5000
-
큰 확산
1600
1100
2519
-
2235

8000
-
-
1200
큰 확산
2451
-
2100

10
-
-
큰 확산
-
2200
-
2200

11
-
-
-
-
2200
-
2122

12
-
-
-
-
970
-
1958

13
-
-
-
-
730
-
1897

14
-
-
-
-
590
-
1466

15
-
-
-
-
532
-
1281

그래프와 표를 보면 동시 요청이 8000개를 넘으면 프리포크와 epoll이라는 두 명의 플레이어만 남아 있음을 알 수 있습니다. 로드가 증가하면 폴링 기반 서버는 스트리밍 서버보다 성능이 저하됩니다. 스레드 사전 생성 아키텍처는 Linux 커널이 많은 수의 스레드를 얼마나 잘 예약하는지에 대한 증거인 epoll의 가치 있는 경쟁자입니다.

ZeroHTTPd 소스 코드

ZeroHTTPd 소스 코드 여기에. 각 아키텍처마다 별도의 디렉터리가 있습니다.

ZeroHTTPd │ ├── 01_iterative │ ├── main.c ├── 02_forking │ ├── main.c ├── 03_preforking │ ├── main.c ├── 04_ 스레딩 │ ├── main.c ├── 05_prethreading │ ├── main.c ├── 06_poll │ ├── main.c ├── 07_epoll │ └── main.c ├── Makefile ├── public │ ├── index .html │ └── tux .png └── 템플릿 └── 방명록 └── index.html

모든 아키텍처에 대한 XNUMX개의 디렉터리 외에도 최상위 디렉터리에는 public과 template이라는 두 개의 디렉터리가 더 있습니다. 첫 번째에는 index.html 파일과 첫 번째 스크린샷의 이미지가 포함되어 있습니다. 여기에 다른 파일과 폴더를 넣을 수 있으며 ZeroHTTPd는 문제 없이 이러한 정적 파일을 제공해야 합니다. 브라우저의 경로가 공용 폴더의 경로와 일치하면 ZeroHTTPd는 이 디렉터리에서 index.html 파일을 찾습니다. 방명록의 콘텐츠는 동적으로 생성됩니다. 여기에는 홈 페이지만 있고 해당 콘텐츠는 'templates/guestbook/index.html' 파일을 기반으로 합니다. ZeroHTTPd는 확장을 위한 동적 페이지를 쉽게 추가합니다. 아이디어는 사용자가 이 디렉터리에 템플릿을 추가하고 필요에 따라 ZeroHTTPd를 확장할 수 있다는 것입니다.

XNUMX개의 서버를 모두 구축하려면 다음을 실행하세요. make all 최상위 디렉터리에서 - 모든 빌드가 이 디렉터리에 나타납니다. 실행 파일은 실행된 디렉터리에서 공용 및 템플릿 디렉터리를 찾습니다.

리눅스 API

이 기사 시리즈의 정보를 이해하기 위해 Linux API에 정통할 필요는 없습니다. 그러나 인터넷에 많은 참고 자료가 있으므로 이 주제에 대해 더 자세히 읽어 보시기 바랍니다. Linux API의 여러 범주를 다루겠지만 주로 프로세스, 스레드, 이벤트 및 네트워크 스택에 중점을 둘 것입니다. Linux API에 관한 책과 기사 외에도 시스템 호출과 사용되는 라이브러리 함수에 대한 마나(mana)도 읽어볼 것을 권장합니다.

성능 및 확장성

성능 및 확장성에 대한 참고 사항입니다. 이론적으로 그들 사이에는 연관성이 없습니다. 몇 밀리초의 응답 시간으로 매우 잘 작동하지만 전혀 확장되지 않는 웹 서비스를 가질 수 있습니다. 마찬가지로, 응답하는 데 몇 초가 걸리지만 수만 명의 동시 사용자를 처리하기 위해 수만 배로 확장되는 성능이 낮은 웹 애플리케이션이 있을 수 있습니다. 그러나 고성능과 확장성의 조합은 매우 강력한 조합입니다. 고성능 응용 프로그램은 일반적으로 리소스를 적게 사용하므로 서버에서 더 많은 동시 사용자에게 효율적으로 서비스를 제공하여 비용을 절감합니다.

CPU 및 I/O 작업

마지막으로, 컴퓨팅에는 I/O와 CPU라는 두 가지 가능한 작업 유형이 있습니다. 인터넷을 통한 요청 수신(네트워크 I/O), 파일 제공(네트워크 및 디스크 I/O), 데이터베이스와의 통신(네트워크 및 디스크 I/O)은 모두 I/O 활동입니다. 일부 데이터베이스 쿼리는 약간 CPU 집약적일 수 있습니다(정렬, 백만 개의 결과 평균화 등). 대부분의 웹 애플리케이션은 가능한 최대 I/O로 제한되며 프로세서가 전체 용량으로 사용되는 경우는 거의 없습니다. 일부 I/O 작업이 많은 CPU를 사용하고 있다는 것을 알게 되면 이는 애플리케이션 아키텍처가 좋지 않다는 신호일 가능성이 높습니다. 이는 프로세스 관리 및 컨텍스트 전환에 CPU 리소스가 낭비된다는 의미일 수 있으며 이는 완전히 유용하지는 않습니다. 이미지 처리, 오디오 파일 변환 또는 기계 학습과 같은 작업을 수행하는 경우 해당 애플리케이션에는 강력한 CPU 리소스가 필요합니다. 그러나 대부분의 응용 프로그램에서는 그렇지 않습니다.

서버 아키텍처에 대해 자세히 알아보기

1. XNUMX부: 반복적 아키텍처
2. 파트 II. 포크 서버
3. 파트 III. 프리포크 서버
4. 파트 IV. 실행 스레드가 있는 서버
5. 파트 V. 사전 스레드 서버
6. 파트 VI. Pol 기반 아키텍처
7. 파트 VII. epoll 기반 아키텍처

출처 : habr.com