엔드포인트를 제공하기 위한 부하 테스트

이 문서에서는 프로덕션 워크로드를 효과적으로 처리할 수 있도록 Mosaic AI 모델 서비스 엔드포인트를 테스트하는 필수 프로세스를 안내합니다. 또한 Locust 부하 테스트 프레임워크를 사용하여 실용적인 예제, 실제 비유 및 단계별 지침을 제공하여 초당 요청 및 동시성 제한과 같은 주요 성능 메트릭을 측정하는 방법을 보여 줍니다. 따라서 엔드포인트 크기를 올바르게 조정하고 비즈니스 요구에 맞게 모델을 자신 있게 배포할 수 있습니다.

부하 테스트란?

부하 테스트는 대기 시간 또는 초당 요청과 같은 프로덕션 요구 사항을 충족하도록 엔드포인트를 제공하는 Mosaic AI 모델의 실제 사용을 시뮬레이션하는 테스트입니다. 부하 테스트는 다양한 트래픽 수준에서 엔드포인트의 성능을 측정하여 지연을 일으키지 않도록 엔드포인트 크기를 올바르게 조정하는 데 도움이 됩니다.

사진: 평일 오전 8:00이며, 도시의 중심부에 인기있는 카페가 막 열립니다. 신선한 커피의 향기가 공기를 채웁니다. 바리스타는 준비를 마치고, 기계는 예열되었으며, 카페인이 부족한 고객들의 줄이 이미 형성되고 있습니다.

처음에는 일이 원활하게 진행됩니다. 몇 명의 고객이 한 걸음 더 나아가 주문을 하고 바리스타가 음료를 준비하기 시작합니다. 일부 음료는 30초가 걸리고, 복잡성에 따라 1분 정도 걸리는 음료도 있습니다. 바리스타는 연습된 효율성으로 여러 주문을 저글링합니다.

그러나 곧 더 많은 사람들이 도착합니다. 5명의 고객이 10명, 20명으로 바뀝니다. 각자 주문을 하고, 음료를 기다리며, 어쩌면 카운터에서 조금 대화를 나눌 수도 있다. 바리스타는 이제 압박을 받고 있습니다. 두 번째 바리스타가 들어와도 시스템이 긴장하기 시작합니다. 즉, 선이 늘어나고 주문이 쌓이고 고객이 더 오래 기다리기 시작합니다.

이제 고객이 좌절하기 시작하기 전에 카페가 분당 얼마나 많은 음료를 제공 할 수 있는지 측정하려고 한다고 상상해보십시오. 이것이 부하 테스트입니다.

이 비유에서:

• 각 고객은 요청을 보내는 클라이언트 입니다.
• 이 바리스타(들)는 모델 추론을 하나씩 또는 병렬로 처리하는 서버를 나타냅니다.
• 주문을 받고 음료를 제공하는 시간은 모델 구현 시간입니다.
• 통신, 지불 또는 주문 찾기 지연은 네트워크 오버헤드입니다.
• 한 번에 도착하는 고객이 더 많을수록 클라이언트 동시성이 있습니다.
• baristas 또는 더 많은 컴퓨터를 추가하는 것은 서버 동시성을 높이는 것과 같습니다.

좋은 카페와 마찬가지로, 직원들이 한 번에 처리 할 수있는 양에 제한이 있습니다. 피크 시간대에 더 많은 바리스타를 데려와서 미리 계획하지 않으면 사람들은 불행해지게 됩니다. 부하가 있는 시스템에서도 마찬가지입니다. 부하 테스트를 통해 병목 현상이 있는 위치, 시스템에서 처리할 수 있는 트래픽 양 및 더 원활한 서비스를 위해 수행해야 하는 변경 내용을 식별할 수 있습니다.

엔드포인트에서 부하 테스트를 실행하기 전에 다음을 수행해야 합니다.

• 부하 테스트와 관련된 구성 요소 및 개념을 이해합니다.
• 프로덕션 요구 사항을 결정하고 정의합니다.
• 엔드포인트를 벤치마킹할 때 사용할 부하 테스트 프레임워크에 대한 대표적인 페이로드를 찾습니다.

부하 테스트 개념 및 정의

다음 표에서는 부하 테스트 관련 개념을 정의합니다.

대기 시간 요구 사항

비즈니스 및 고객 요구 사항에 따라 시스템의 이상적인 성능을 정의합니다. 엔드포인트를 제공하는 모델에서 대기 시간에는 유추를 위해 데이터를 보낼 때 클라이언트가 경험하는 왕복 시간이 포함됩니다. 여기에는 네트워킹 대기 시간 및 유추 시간이 포함됩니다. 요구 사항이 현실적인지 확인하는 것이 중요합니다. 예를 들어 모델이 메모리에 로드될 때 유추를 수행하는 데 15ms가 걸리는 경우 엔드포인트를 제공하는 모델에서 제공될 때 네트워킹 대기 시간에 대한 추가 시간을 허용해야 합니다.

RPS, 대기 시간 및 동시성은 어떻게 관련되어 있나요?

비즈니스에는 시스템의 성공에 대한 몇 가지 정의된 기준이 있습니다. ML 시스템의 경우 비즈니스 조건은 일반적으로 고품질 결과, 짧은 대기 시간 및 높은 처리량입니다. 결과의 품질은 특히 모델 자체와 관련이 있지만 엔드투엔드 대기 시간 및 처리량은 서비스 시스템의 특성입니다. 종단 간 대기 시간은 모델 실행 시간과 네트워크 오버헤드로 구성됩니다. 처리량(또는 초당 요청 또는 쿼리)은 대기 시간과 반비례하며 동시성과 직접 관련이 있습니다.

• 동시성이 높을수록 처리량이 높아질 수 있습니다.
• 지연 시간이 높을수록 처리량이 낮아집니다.

일반적으로 지정된 애플리케이션에 대한 서버 쪽 동시성에 대한 클라이언트 쪽 동시성의 최적 비율이 있습니다. 예를 들어 "라인 셰프가 동시에 작업할 수 있는 햄버거의 수"는 무엇일까요? 요리 과정에서 공유 단계가 많을 수 있기 때문에 라인 셰프는 한 번에 하나씩만 요리하기보다는 햄버거 4개를 동시에 최적으로 요리할 수 있습니다. 이 병렬화에는 한계가 있으며, 어떤 시점에서는 요리사가 1000개의 햄버거에 치즈를 추가해야 하는 경우처럼 많은 병렬 작업을 수행하는 행위가 너무 많은 대기 시간을 추가합니다.

부하 테스트의 핵심 목표 중 하나는 애플리케이션의 최적 비율을 결정하는 것입니다. 최적 비율은 RPS를 최대화하고 대기 시간 요구 사항을 충족하며 큐를 방지합니다. 이 비율은 가장 까다로운 부하에 맞게 엔드포인트의 크기를 정확하게 조정하는 데 사용할 수 있습니다.

엔드포인트가 요청을 충분히 빠르게 처리할 수 없는 경우 줄이 형성되기 시작합니다. 이를 큐라고합니다. 큐를 구성하면 일반적으로 각 요청이 처리되기 전에 대기하는 데 소요되는 추가 시간이 있으므로 종단 간 대기 시간이 훨씬 더 길어집니다. 요청이 처리할 수 있는 것보다 더 빠르게 도착하는 경우 큐가 증가하여 대기 시간이 더 늘어나게 됩니다. 이러한 이유로 엔드포인트에서 발생할 수 있는 최대 수요 종류를 이해하고 부하 테스트를 통해 올바르게 크기가 조정되었는지 확인하는 것이 중요합니다.

부하 테스트 시나리오 예제

부하 테스트와 실제 시스템에서는 클라이언트 동시성, 서버 동시성 및 대기 시간 간의 관계가 동적이며 상호 의존합니다. 간단한 예제를 사용하여 이 관계를 살펴보겠습니다.

시나리오 1: 간단한 설정

이 설정에서는 단일 클라이언트가 순차적으로 요청을 보내며, 다음 요청을 실행하기 전에 응답을 기다립니다. 요청당 총 시간은 모델 실행 및 오버헤드 대기 시간(40ms + 10ms)의 합계이므로 측정된 종단 간 대기 시간은 50ms입니다.

• 클라이언트 수: 1
• 프로비전된 동시성: 1
• 오버헤드 대기 시간: 10ms
• 모델 실행 시간 40ms

결과적으로 클라이언트는 초당 20개 요청 또는 초당 쿼리와 같은 50ms마다 하나의 요청을 완료합니다.

시나리오 2: 프로비전된 동시성 증가

이 경우 프로비전된 동시성을 두 배로 늘리며 단일 클라이언트가 순차적으로 요청을 수행합니다. 즉, 총 대기 시간은 여전히 50ms(40ms + 10ms)이고 시스템에는 초당 20개의 요청만 표시됩니다(QPS).

• 클라이언트 수: 1
• 프로비전된 동시성: 1 -> 2
• 오버헤드 대기 시간: 10ms
• 모델 실행 시간 40ms

시나리오 3: 시스템에 다른 클라이언트를 추가합니다.

이제 두 개의 클라이언트가 프로비전된 동시성을 사용하여 엔드포인트에 요청합니다. 이 경우 각 클라이언트의 요청은 엔드포인트에서 동시에 독립적으로 처리될 수 있습니다(완벽한 부하 분산을 가정). 따라서 총 대기 시간은 여전히 50ms(40ms + 10ms)이지만 각 클라이언트가 20 qps를 보내기 때문에 시스템은 초당 40개의 요청을 관찰합니다.

• 클라이언트 수: 1 -> 2
• 프로비전된 동시성: 2
• 오버헤드 대기 시간: 10ms
• 모델 실행 시간 40ms

프로비전된 동시성 및 요청을 하는 클라이언트 수를 늘리면 대기 시간에 대한 페널티 없이 시스템에서 관찰된 총 QPS가 증가합니다.

시나리오 4: 프로비전된 동시성을 줄일 수 있습니다.

이 마지막 시나리오에서 클라이언트 수는 프로비전된 동시성보다 큽니다. 이 설정은 시스템에 또 다른 변수인 큐를 도입하고 QPS 및 대기 시간에 미치는 영향을 소개합니다.

• 클라이언트 수: 2
• 프로비전된 동시성: 2 -> 1
• 오버헤드 대기 시간: 10ms
• 모델 실행 시간: 40ms

여기서는 두 개의 클라이언트가 동시에 요청을 만듭니다. 그러나 엔드포인트는 한 번에 하나의 요청만 처리할 수 있습니다. 이렇게 하면 첫 번째 요청이 처리되기 전에 두 번째 요청이 대기합니다. 두 번째 요청의 대기, 또는 더 정확히 말하면 큐잉,이 시스템 지연 시간에 부정적인 영향을 줄 수 있습니다. 서버에서 큐를 허용한다고 가정하면(Databricks 모델 제공에서 기본적으로 사용) 두 번째 클라이언트는 90ms의 대기 시간을 확인합니다. 10ms(네트워크 오버헤드) + 40ms(큐 대기 시간) + 40ms(모델 실행 시간). 이것은 전에 본 50 ms보다 훨씬 더 나쁩다.