SRE: 성능 분석. Go에서 간단한 웹서버를 이용한 설정방법

성능 분석 및 조정은 클라이언트의 성능 규정 준수를 확인하기 위한 강력한 도구입니다.

성능 분석은 튜닝 실험 테스트에 과학적인 접근 방식을 적용하여 프로그램의 병목 현상을 확인하는 데 사용할 수 있습니다. 이 문서에서는 Go 웹 서버를 예로 들어 성능 분석 및 튜닝에 대한 일반적인 접근 방식을 정의합니다.

Go에는 프로파일링 도구가 있기 때문에 특히 좋습니다. pprof 표준 라이브러리에 있습니다.

전략

구조 분석을 위한 요약 목록을 만들어 보겠습니다. 우리는 직관이나 추측에 기초하여 변경하는 대신 일부 데이터를 사용하여 결정을 내리려고 노력할 것입니다. 이를 위해 우리는 다음과 같이 할 것입니다:

• 우리는 최적화 경계(요구사항)를 결정합니다.
• 우리는 시스템의 트랜잭션 로드를 계산합니다.
• 우리는 테스트(데이터 생성)를 수행합니다.
• 우리는 관찰합니다.
• 우리는 분석합니다 - 모든 요구 사항이 충족됩니까?
• 우리는 그것을 과학적으로 설정하고 가설을 세웁니다.
• 우리는 이 가설을 검증하기 위해 실험을 수행합니다.

간단한 HTTP 서버 아키텍처

이 기사에서는 Golang의 작은 HTTP 서버를 사용합니다. 이 기사의 모든 코드를 찾을 수 있습니다 여기에.

분석 중인 애플리케이션은 각 요청에 대해 Postgresql을 폴링하는 HTTP 서버입니다. 또한 애플리케이션 및 시스템 메트릭을 수집하고 표시하기 위한 Prometheus, node_exporter 및 Grafana가 있습니다.

단순화하기 위해 수평 확장(및 계산 단순화)을 위해 각 서비스와 데이터베이스가 함께 배포되는 것을 고려합니다.

목표 정의

이 단계에서 우리는 목표를 결정합니다. 우리는 무엇을 분석하려고 하는가? 언제 끝날지 어떻게 알 수 있나요? 이 기사에서는 클라이언트가 있고 서비스가 초당 10개의 요청을 처리한다고 가정합니다.

В Google SRE 도서 선택 및 모델링 방법에 대해 자세히 설명합니다. 동일한 작업을 수행하고 모델을 구축해 보겠습니다.

• 지연 시간: 요청의 99%가 60ms 이내에 완료되어야 합니다.
• 비용: 서비스는 당사가 합리적으로 가능하다고 생각하는 최소 금액을 소비해야 합니다. 이를 위해 처리량을 최대화합니다.
• 용량 계획: 전체 확장 기능을 포함하여 실행해야 하는 애플리케이션 인스턴스 수, 초기 로드 및 프로비저닝 요구 사항을 충족하는 데 필요한 인스턴스 수를 이해하고 문서화해야 합니다. 중복성 n+1.

지연 시간은 분석 외에도 최적화가 필요할 수 있지만 처리량은 분명히 분석되어야 합니다. SRE SLO 프로세스를 사용할 때 지연 요청은 제품 소유자가 대표하는 고객이나 비즈니스로부터 나옵니다. 그리고 우리 서비스는 아무런 설정 없이 처음부터 이 의무를 이행할 것입니다!

테스트 환경 설정

테스트 환경의 도움으로 시스템에 측정된 로드를 배치할 수 있습니다. 분석을 위해 웹 서비스 성능에 대한 데이터가 생성됩니다.

거래 부하

이 환경에서는 단조로운 생활을하다 중지될 때까지 사용자 지정 HTTP 요청 속도를 생성하려면 다음을 수행하세요.

$ make load-test LOAD_TEST_RATE=50
echo "POST http://localhost:8080" | vegeta attack -body tests/fixtures/age_no_match.json -rate=50 -duration=0 | tee results.bin | vegeta report

관측

트랜잭션 로드는 런타임에 적용됩니다. 애플리케이션(요청 수, 응답 대기 시간) 및 운영 체제(메모리, CPU, IOPS) 지표 외에도 애플리케이션 프로파일링을 실행하여 문제가 있는 위치와 CPU 시간이 소비되는 방식을 파악합니다.

프로파일링

프로파일링은 애플리케이션이 실행 중일 때 CPU 시간이 어디로 가는지 확인할 수 있는 측정 유형입니다. 이를 통해 프로세서 시간이 소비되는 위치와 양을 정확하게 확인할 수 있습니다.

이 데이터는 분석 중에 낭비되는 CPU 시간과 불필요한 작업 수행에 대한 통찰력을 얻는 데 사용될 수 있습니다. Go(pprof)는 표준 도구 세트를 사용하여 프로필을 생성하고 이를 Flame 그래프로 시각화할 수 있습니다. 기사 뒷부분에서 사용 및 설정 가이드에 대해 설명하겠습니다.

실행, 관찰, 분석.

실험을 해보자. 성과에 만족할 때까지 수행, 관찰, 분석하겠습니다. 첫 번째 관찰 결과를 얻기 위해 임의로 낮은 하중 값을 선택하여 적용해 보겠습니다. 각 후속 단계에서는 약간의 변형을 통해 선택된 특정 배율 인수를 사용하여 로드를 증가시킵니다. 각 부하 테스트 실행은 조정된 요청 수를 사용하여 수행됩니다. make load-test LOAD_TEST_RATE=X.

초당 요청 50개

위쪽 두 그래프에 주목하세요. 왼쪽 상단에는 애플리케이션이 초당 50개의 요청을 처리하는 것으로 추정되며 오른쪽 상단에는 각 요청의 지속 시간이 표시됩니다. 두 매개변수 모두 성능 한계 내에 있는지 여부를 확인하고 분석하는 데 도움이 됩니다. 그래프의 빨간색 선 HTTP 요청 대기 시간 60ms에 SLO를 표시합니다. 이 선은 최대 응답 시간보다 훨씬 낮음을 나타냅니다.

비용 측면을 살펴보겠습니다.

초당 요청 10000개 / 서버당 요청 50개 = 서버 200개 + 1개

이 수치는 아직 개선할 수 있습니다.

초당 요청 500개

로드가 초당 500개의 요청에 도달하면 더 흥미로운 일이 발생하기 시작합니다.

다시 한 번 왼쪽 상단 그래프에서 애플리케이션이 정상 로드를 기록하고 있음을 확인할 수 있습니다. 그렇지 않은 경우 응용 프로그램이 실행되는 서버에 문제가 있는 것입니다. 응답 대기 시간 그래프는 오른쪽 상단에 있으며, 초당 500개의 요청으로 인해 25~40ms의 응답 지연이 발생한 것을 보여줍니다. 99번째 백분위수는 여전히 위에서 선택한 60ms SLO에 잘 들어맞습니다.

비용 측면에서:

초당 요청 10000개 / 서버당 요청 500개 = 서버 20개 + 1개

모든 것은 여전히 ​​개선될 수 있습니다.

초당 요청 1000개

훌륭한 출시! 애플리케이션은 초당 1000개의 요청을 처리했지만 SLO에 따라 지연 시간 제한이 위반되었음을 보여줍니다. 이는 오른쪽 상단 그래프의 p99 라인에서 볼 수 있습니다. p100 라인이 훨씬 높다는 사실에도 불구하고 실제 지연은 최대 60ms보다 높습니다. 애플리케이션이 실제로 무엇을 하는지 알아보기 위해 프로파일링을 살펴보겠습니다.

프로파일링

프로파일링을 위해 로드를 초당 1000개 요청으로 설정한 다음 pprof 애플리케이션이 CPU 시간을 소비하는 위치를 찾기 위해 데이터를 캡처합니다. 이는 HTTP 엔드포인트를 활성화하여 수행할 수 있습니다. pprof, 로드 시 컬을 사용하여 결과를 저장합니다.

$ curl http://localhost:8080/debug/pprof/profile?seconds=29 > cpu.1000_reqs_sec_no_optimizations.prof

결과는 다음과 같이 표시될 수 있습니다.

$ go tool pprof -http=:12345 cpu.1000_reqs_sec_no_optimizations.prof

그래프는 애플리케이션이 CPU 시간을 소비하는 위치와 양을 보여줍니다. 설명에서 브렌든 그레그:

X축은 알파벳순으로 정렬된 스택 프로필 모집단이며(시간 아님), Y축은 스택 깊이를 표시하며 [위쪽]에서 XNUMX부터 계산됩니다. 각 직사각형은 스택 프레임입니다. 프레임이 넓을수록 스택에 더 자주 나타납니다. 맨 위에 있는 것은 CPU에서 실행되고 아래에 있는 것은 하위 요소입니다. 색상은 일반적으로 아무 의미가 없으며 단순히 프레임을 구별하기 위해 무작위로 선택됩니다.

분석 - 가설

튜닝을 위해 낭비되는 CPU 시간을 찾는 데 중점을 둘 것입니다. 우리는 쓸모없는 지출의 가장 큰 원인을 찾아서 제거할 것입니다. 프로파일링을 통해 응용 프로그램이 정확히 어디에서 프로세서 시간을 소비하는지 매우 정확하게 알 수 있으므로 이 작업을 여러 번 수행해야 할 수도 있고 응용 프로그램 소스 코드를 변경하고 테스트를 다시 실행하여 성능이 목표에 근접하는지 확인해야 합니다.

Brendan Gregg의 권장 사항에 따라 차트를 위에서 아래로 읽겠습니다. 각 줄에는 스택 프레임(함수 호출)이 표시됩니다. 첫 번째 줄은 프로그램의 진입점으로, 다른 모든 호출의 상위 항목입니다(즉, 다른 모든 호출의 스택에 해당 항목이 포함됩니다). 다음 줄은 이미 다릅니다.

그래프의 함수 이름 위에 커서를 올리면 디버깅 중에 해당 함수가 스택에 있었던 총 시간이 표시됩니다. HTTPServe 기능은 65%의 시간 동안 존재했고, 다른 런타임 기능도 있었습니다. runtime.mcall, mstart и gc, 나머지 시간을 차지했습니다. 재미있는 사실: 총 시간의 5%가 DNS 쿼리에 소요됩니다.

프로그램이 찾는 주소는 Postgresql에 속합니다. 클릭 FindByAge:

흥미롭게도 이 프로그램은 원칙적으로 지연을 추가하는 세 가지 주요 원인, 즉 연결 열기 및 닫기, 데이터 요청, 데이터베이스 연결이 있음을 보여줍니다. 그래프는 DNS 요청, 연결 열기 및 닫기가 총 실행 시간의 약 13%를 차지하는 것을 보여줍니다.

가설: 풀링을 사용하여 연결을 재사용하면 단일 HTTP 요청 시간이 줄어들어 처리량이 늘어나고 대기 시간이 낮아집니다..

애플리케이션 설정 - 실험

소스 코드를 업데이트하고 각 요청에 대해 Postgresql에 대한 연결을 제거해 봅니다. 첫 번째 옵션은 다음을 사용하는 것입니다. 연결 풀 응용 프로그램 수준에서. 이 실험에서 우리는 설정하자 Go용 SQL 드라이버를 사용한 연결 풀링:

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)

if err != nil {
   return nil, err
}

실행, 관찰, 분석

초당 1000개의 요청으로 테스트를 다시 시작한 후 p99의 대기 시간 수준이 SLO 60ms로 정상으로 돌아온 것이 분명합니다!

비용은 얼마입니까?

초당 요청 10000개 / 서버당 요청 1000개 = 서버 10개 + 1개

더 잘해보자!

초당 요청 2000개

로드를 두 배로 늘리면 동일한 결과가 표시됩니다. 왼쪽 상단 그래프는 애플리케이션이 초당 2000개의 요청을 처리하고 p100이 60ms보다 낮으며 p99가 SLO를 충족한다는 것을 보여줍니다.

비용 측면에서:

초당 요청 10000개 / 서버당 요청 2000개 = 서버 5개 + 1개

초당 요청 3000개

여기서 애플리케이션은 3000ms 미만의 p99 대기 시간으로 60개의 요청을 처리할 수 있습니다. SLO를 위반하지 않으며 비용은 다음과 같이 허용됩니다.

초당 요청 10000개 / 서버당 요청 3000개 = 서버 4개 + 1개 (작가님이 정리하셨네요. 약. 역자)

또 다른 분석을 시도해 보겠습니다.

분석 - 가설

초당 3000개의 요청으로 애플리케이션 디버깅 결과를 수집하고 표시합니다.

여전히 6%의 시간이 연결을 설정하는 데 사용됩니다. 풀을 설정하면 성능이 향상되었지만 애플리케이션이 계속해서 데이터베이스에 대한 새 연결을 생성하는 작업을 수행하는 것을 볼 수 있습니다.

가설: 풀이 있음에도 불구하고 연결이 계속 삭제되고 지워지므로 애플리케이션에서 연결을 재설정해야 합니다. 보류 중인 연결 수를 풀 크기로 설정하면 애플리케이션이 연결을 생성하는 데 소요되는 시간을 최소화하여 대기 시간을 줄이는 데 도움이 됩니다..

애플리케이션 설정 - 실험

설치하는 중 MaxIdleConns 풀 크기와 동일(또한 설명됨) 여기에):

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)
db.SetMaxIdleConns(8)
if err != nil {
   return nil, err
}

실행, 관찰, 분석

초당 요청 3000개

p99는 60ms 미만이고 p100은 훨씬 적습니다!

Flame 그래프를 확인해보면 연결이 더 이상 눈에 띄지 않는 것을 알 수 있습니다! 좀 더 자세히 확인해 볼까요 pg(*conn).query — 여기서도 연결이 설정되는 것을 알 수 없습니다.

결론

성능 분석은 고객의 기대와 비기능적 요구 사항이 충족되고 있는지 이해하는 데 중요합니다. 관찰 내용과 고객 기대치를 비교하여 분석하면 허용 가능한 것과 허용되지 않는 것을 결정하는 데 도움이 될 수 있습니다. Go는 분석을 간단하고 접근 가능하게 만드는 표준 라이브러리에 내장된 강력한 도구를 제공합니다.

출처 : habr.com