안녕하세요, SK플래닛의 원준수입니다. 팀에서 블록체인 개발업무를 진행하다 보면 블록체인의 nonce, 서명 등의 고려사항으로 부하 테스트 시 어려움을 겪었는데 이를 Locust라는 오픈소스 툴을 이용하여 해결하였습니다. 간단한 예시를 이용하여 Locust의 기능과 장점에 대하여 공유하겠습니다.Locust는 사용자 정의 테스트 시나리오를 작성하는 데에 Python을 기반으로 하고 있습니다. Python은 많은 개발자들이 이미 익숙한 언어이며, 높은 유연성과 확장성을 제공합니다. 저의 경우에도 web3 python module 임포트하여 쉽게 테스트 코드를 작성할 수 있었습니다. 이외에도 사용자가 웹 기반 인터페이스를 통해 테스트를 모니터링하고 제어할 수 있는 기능을 제공하여 작업이 더 직관적이고 효율적으로 만들어줍니다. 또한, 마스터-워커 (Master-Worker) 구조를 지원하여 대규모 트래픽을 생성하고 관리하여 복잡한 성능 테스트 시나리오를 효율적으로 수행할 수 있습니다.본 포스팅에서는 Locust를 이용한 간단한 3가지 테스트 예시를 작성해보겠습니다.• 고유한 성질을 가진 유저의 테스트• 초당 100개의 요청을 처리하고 나머지 요청은 제한하는 로직을 작성하고 올바르게 작동하는지 테스트빠르고 간단하게 서버를 구성하기 위해 Golang을 사용하고 코드 작성은 ChatGPT의 힘을 빌렸습니다.• 'WebsiteUser' 클래스는 Locust에서 제공하는 기본 사용자 클래스 중 하나입니다. 이 클래스를 상속하면 Locust가 HTTP 요청을 쉽게 만들고 처리할 수 있는 여러 기능을 활용할 수 있습니다.• @task 데코레이터는 테스트 시나리오의 일부를 정의합니다. 작성된 test 메소드는 무한 루프로 실행되며, 웹 호스트의 루트 페이지에 GET 요청을 보냅니다.• self.client.get() 메서드는 Locust에서 제공하는 HTTP 클라이언트를 사용하여 GET 요청을 보내고, 응답을 받습니다. catch_response=True로 설정하면 Locust가 응답을 캐치하여 실패 여부를 확인할 수 있습니다.• wait_time 속성을 통해 각 사용자가 다음 작업을 수행하기 전에 1초의 시간을 대기하도록 설정해두었습니다.각 사용자는 1초에 한번의 요청을 진행하게 됩니다.브라우저에서 localhost:8089 접속 Number of users - 테스트를 수행하는 동안 생성될 가상 사용자의 총 수 Ramp-up - 부하를 점진적으로 증가시킬 사용자의 수100명의 유저가 초당 1개 요청사용자를 110으로 늘려보면?RateLimit이 발생하기 시작함 서버에서 정상적으로 RateLimit이 작동하고 있는 것 확인 (429 응답)하나의 노드에서만 트래픽을 발생시키는 경우에는 서버의 컴퓨팅 자원 한계로 인하여 대량의 트래픽을 생성하는 데 제약이 있습니다. 이러한 한계를 극복하기 위해 locust는 마스터-워커 구조를 제공하고 있습니다. 실습은 위에서 진행한 Rate Limiting 테스트를 여러 노드를 사용하여 부하를 넣는 방식으로 진행하겠

SK Planet에서 Web3기술을 이용하여 서비스 개발을 하고 있는 원준수입니다.각 wallet의 nonce 고려, 서명 등 고려사항으로 인하여 블록체인 부하테스트에서의 난항을 겪던 중Locust라는 오픈소스 툴을 사용하여 어려움을 해결할 수 있었습니다.간단하게 Locust의 간단한 기능과 장점에 대해서 공유하겠습니다.Locust는 사용자 정의 테스트 시나리오를 작성하는 데에 Python을 기반으로 하고 있습니다.Python은 많은 개발자들이 이미 익숙한 언어이며, 높은 유연성과 확장성을 제공합니다.저의 경우에도 web3 python module 임포트하여 쉽게 테스트 코드를 작성할 수 있었습니다.이외에도 사용자가 웹 기반 인터페이스를 통해 테스트를 모니터링하고 제어할 수 있는 기능을 제공하여 작업이 더 직관적이고 효율적으로 만들어줍니다.또한, 마스터-워커 (Master-Worker) 구조를 지원하여 대규모 트래픽을 생성하고 관리하여 복잡한 성능 테스트 시나리오를 효율적으로 수행할 수 있습니다.본 포스팅에서는 Locust를 이용한 간단한 테스트를 작성해보겠습니다.빠르고 간단하게 서버를 구성하기 위해 Golang을 사용하고 코드 작성은 ChatGPT의 힘을 빌렸습니다.초당 100개의 요청을 초과하면 429 응답코드를 내려주게 됩니다.• None 'WebsiteUser' 클래스는 Locust에서 제공하는 기본 사용자 클래스 중 하나입니다. 이 클래스를 상속하면 Locust가 HTTP 요청을 쉽게 만들고 처리할 수 있는 여러 기능을 활용할 수 있습니다.• None @task 데코레이터는 테스트 시나리오의 일부를 정의합니다. 작성된 test 메소드는 무한 루프로 실행되며, 웹 호스트의 루트 페이지에 GET 요청을 보냅니다.• None self.client.get() 메서드는 Locust에서 제공하는 HTTP 클라이언트를 사용하여 GET 요청을 보내고, 응답을 받습니다. catch_response=True로 설정하면 Locust가 응답을 캐치하여 실패 여부를 확인할 수 있습니다.• None wait_time 속성을 통해 각 사용자가 다음 작업을 수행하기 전에 1초의 시간을 대기하도록 설정해두었습니다.각 사용자는 1초에 한번의 요청을 진행하게 됩니다.브라우저에서 localhost:8089 접속Number of users - 테스트를 수행하는 동안 생성될 가상 사용자의 총 수Ramp-up - 부하를 점진적으로 증가시킬 사용자의 수가상 사용자 100까지는 rate limit이 발생하지 않는 것을 볼 수 있음 (초당 100번 미만 호출)사용자를 110으로 늘려보면?서버에서 정상적으로 RateLimit이 작동하고 있는 것 확인Locust의 기능을 간단하게 소개해보았습니다.공식 홈페이지를 확인해주시면 다양한 좋은 기능들을 확인해볼 수 있습니다.

함께 구매하면 좋은 상품이에요! - 장바구니 추천 개발기 2부안녕하세요. 컬리 데이터서비스개발팀에서 일하고 있는 백엔드 개발자 최재형, 김수지, 데이터 엔지니어 이상협, ML 엔지니어 구국원입니다. 이전 글에서는 장바구니 추천 모델을 개발하는 과정에서 고민한 내용을 설명드렸습니다. 그리고 이러한 고민 끝에 만들어진 모델의 부가가치를 실제 컬리의 엔드 유저에게 전달하기 위해서 실시간 서빙 아키텍처를 구축할 필요가 있있었습니다. 그 과정에서 역시나 많은 고민과 시행착오가 있었고, 현재 구축한 아키텍처에 기반하여 성공적으로 실시간 서빙을 수행하고 있습니다. 따라서 본 글에서는 컬리가 어떻게 실시간 서빙 아키텍처를 구축하고 운영하고 있는지를 공유 드리고자합니다. 추천 모델을 실시간으로 서빙하기 위한 아키텍처를 나타내 보았습니다. 이 아키텍쳐에 대해서 간단하게 말씀드리면, 추천 모델 API는 AWS와 GCP의 시스템을 활용하였고 그 중 AWS의 EKS 클러스터에서 대부분의 추천 모델 관련 작업이 이루어졌습니다. 학습과 분석에 필요한 데이터는 BigQuery에 적재되어 있고, 운영시 중요하게 모니터링 해야할 부분들은 Datadog과 Slack을 활용해 감지하고 알럿을 보냅니다. 이 아키텍쳐를 서비스 API, 모델 API, MLOps, 모니터링, 배포 과정 파트로 나눠서 각각의 구성 요소들의 세부사항들을 설명드리겠습니다. 서비스 API는 모델 API 앞단에서 컬리 백엔드의 트래픽을 받아 냅니다. 서비스 API는 유저에게 더 좋은 추천 서비스를 제공하고, 추후 서비스의 확장성을 확보하기 위해 구축하였으며 다음과 같은 기능을 수행합니다.특히 모든 분석과 모니터링은 정확한 로깅에서 시작하기 때문에 로깅은 서비스 API의 가장 중요한 요소라고 할 수 있습니다. 서비스 API에는 팀내에서 자체 구축한 로깅 모듈을 활용하고 있는데, 이 모듈을 통해서 API에서 발생한 로그들을 파일 형태로 내립니다. 그 후 생성된 로그 파일을 기 구축된 로깅시스템을 통해 Kafka 토픽으로 전송하고 카프카 토픽에 쌓인 메시지는 Nifi를 활용해 실시간으로 빅쿼리로 적재됩니다. 위 과정을 수행하기 위해 필요한 Kafka나 Nifi와 같은 데이터 연동 인프라는 기존에 저희 팀에서 구축해서 운영 중인 상황이었기 때문에 이를 그대로 활용할 수 있었습니다. 그 결과, 현재 빅쿼리에서 거의 실시간에 가까운 로그를 확인할 수 있습니다.모델 API를 구축하기 위해서는 먼저 서빙 프레임워크를 선정해야 했습니다. 서빙에 사용되는 오픈 소스들은 각자의 장단점이 명확하기 때문에 결국 저희 상황에 맞는 프레임워크를 선정하는 것이 중요했습니다. 여러 후보들을 비교 했는데, 최종적으로는 BentoML과 TorchServe를 후보로 두고 의사결정 하였습니다. 먼저, BentoML은 사용 편의성이 높아서 컬리의 다른 ML API를 서빙하는데 활용하고 있었고 운영 하면서 축적된 노하우가 있었기 때문에 후보로 선정하였습니다. 그리고 Torchserve는 Pytorch 모델을 서빙할 수 있는 프레임워크인데, 마침 개발된 모델이 Pytorch 기반이기도 하고 준수한 성능 보일 것으로 예상해서 후보로 선정하였습니다.그리고 최종 선택을 위해 각 서빙 프레임워크로 랩핑한 API를 띄워보고 성능 테스트를 진행하였습니다. 성능 테스트는 Locust를 활용하였고, 아래와 같은 그래프를 확인 할 수 있었습니다.대략적인 비교를 해보고자 세부적인 튜닝 없이 진행하였는데, 응답 시간 측면에서 torchserve가 더 좋은 지표를 보여주었습니다. 따라서 최종적으로 서빙 프레임워크로 Torchserve를 활용하기로 했고, 성능 최적화를 위한 세부적인 튜닝을 진행하였습니다.Torchserve를 튜닝하는 최종 목표는 낮은 응답시간(지연시간)을 달성하는 것이었습니다. 이를 위해 Torchserve 공식 문서나 관련 아티클을 참고하여 몇 가지의 속성들과 인프라적 튜닝 포인트를 확인 했습니다. 그 내용들은 다음과 같습니다.정리하면, 낮은 지연시간을 달성하기 위해선 부차적인 옵션 설정보다는 CPU Clock Speed가 중요한 특성이라는 것을 경험적으로 확인했습니다. 그 이유는 TorchServe는 요청을 들어온 순서대로 Queue에 넣고 FIFO 방식으로 처리하는 방식으로 구현되어 있으므로 선행하는 요청을 빠르게 처리하는 것이 전체 성능 향상에 가장 큰 영향을 미치기 때문입니다. 다시 말해, 높은 CPU Clock Speed를 확보하는 것이 결국 낮은 응답시간을 달성하는 핵심 요인이라는 것이므로 최종적으로는 CPU �Clock에 특화된 인스턴스 중에서 더 우수한 성능을 보이는 인스턴스를 선정하여 API를 배포하였습니다.ML 모델 API는 일반적인 애플리케이션과는 다르게 배포가 자주 일어날 수 있습니다. 왜냐하면 API가 운영되고 있는 중에 모델은 빈번하게 업데이트가 발생하기 마련이고, 이를 반영하여 새 모델로 API를 변경해줘야 하기 때문입니다. 이렇게 새 버전으로 배포하는 중에 다운타임이 발생하게 된다면 서비스 품질에 큰 영향을 줄 수 있기 때문에 무중단 배포가 필요합니다. 일반적으로 Kubernetes가 제공하는 Rolling Update, Blue/Green, Canary 등의 배포 전략을 활용하면 이론적으로는 무중단 배포가 되는게 맞지만, 실제로 배포 테스트를 해보았을 때 다운타임이 일부 발생하는 것을 확인되었습니다.이런 중단이 발생하는 주된 이유는 EKS외에 AWS의 다른 서비스들을 활용하는 것, 그리고 Gracefulshutdown이 적용되지 않았기 때문입니다. AWS EKS에서 애플리케이션이 트래픽을 받기 위해서는 Ingress를 생성하면서 AWS의 Application Load Balancer(이하 ALB)를 활용하게 되는데 이 때 ALB Ingress의 TargetGroup의 연결이 끊어지고 새로 연결되는 과정에서 다운타임이 발생할 수 있습니다.ALB가 생성된 후에 TargetGroup이 정상적으로 연결이 되면 그 시점부터 트래픽은 정상적으로 들어오게 됩니다. 하지만 모델의 업데이트로 새 버전의 pod가 생성되었고 이 pod로 트래픽을 보내려고 한다면, 기존의

AWS Inferentia를 이용한 모델 서빙 비용 최적화: 모델 서버 비용 2배 줄이기 2탄우당탕탕 Inferentia 배포하기지난 글에서는 AWS Inferentia 소개와 사용법, GPU와의 성능 비교 등을 설명해 드렸어요! 이번 글에서는 Inferentia를 실제 서비스에 도입하기 위해 핑퐁팀에서 어떤 과정들을 거쳤는지 소개해드릴게요.?정합성 검증AWS Inferentia는 모델의 정확도는 유지하면서 모델 추론 속도를 빠르게 하도록 BF16을 이용한 mixed precision을 지원하고 있어요. BF16은 부호 비트 1개, 지수 비트 8개, 가수 비트 7개로 구성된 16비트 부동 소수점 형식을 의미해요. 16 bits로 이루어져 있어 FP32에서 필요한 메모리의 절반만 필요하지만, 표현할 수 있는 범위는 FP32와 같아요. Overflow, Underflow, NaN 등을 맞추기 위해 loss scaling이 필요한 FP16과는 달리, 아무런 변경 없이 BF16을 이용해 FP32를 대체할 수 있어요. 하지만, 가수부가 더 적은 비트로 표현되기 때문에 정확도는 살짝 떨어질 수 있게 돼요. BF16에 대해 더 궁금하신 분들은 해당 논문을 참고해주세요.기본적으로 Neuron Hardware에서는 BF16 또는 FP16 값에 대해 행렬 곱셈 연산 후 FP32로 누적합니다. Compile 시에는 기본으로 FP32로 학습된 모델을 BF16으로 자동 캐스팅해서 FP16의 속도로 추론할 수 있게 해줘요. 그렇다면 자연스럽게 추론 속도와 모델 정확도 사이의 trade-off가 발생하게 되겠죠? 저희는 간단한 정합성 검증을 통해 GPU 위에서 FP32 포맷으로 모델을 추론했을 때와 Inferentia 위에서 추론했을 때의 모델의 정확성을 비교해보았어요.실험 세팅두 문장이 얼마나 유사한지를 측정하는 KLUE STS 태스크를 통해 정합성 검증을 진행했어요. KLUE STS는 두 문장을 주면 문장 사이의 의미적 유사성을 0에서 5 사이의 실숫값으로 예측하고, threshold인 3을 넘으면 유사하다, 넘지 않으면 유사하지 않다고 이진화해서 F1 Score를 계산해요. 저희는 간단하게 정합성을 테스트하기 위해 1) 0~5 사이의 모델 추론 값 비교, 2) 추론 값을 0, 1로 이진화했을 때 값이 달라지는 지를 확인했어요.KLUE 측에서 제공한 학습 데이터셋을 이용하여 사전 학습된 klue/roberta-base 모델을 Fine-Tuning 했어요. 학습이 완료된 모델을 GPU에서 추론하기 위해 SavedModel 형식으로 저장하고, Inferentia 위에서 추론하기 위해 Neuron Compile 후 SavedModel 형식으로 한 번 더 저장해주었습니다. Neuron Compile하는 법은 이전 포스트인 AWS Inferentia를 이용한 모델 서빙 비용 최적화: 모델 서버 비용 2배 줄이기 1탄에서 소개하고 있으니 참고해주세요.GPU 인스턴스로는 g5.xlarge를 사용하였고, Inferentia 인스턴스로는 inf1.xlarge를 사용했어요. 실