แนวทางปฏิบัติที่ดีที่สุดสำหรับการทดสอบการโหลดจุดสิ้นสุดการอนุมานแบบเรียลไทม์ของ Amazon SageMaker

อเมซอน SageMaker เป็นบริการแมชชีนเลิร์นนิง (ML) ที่มีการจัดการเต็มรูปแบบ ด้วย SageMaker นักวิทยาศาสตร์ข้อมูลและนักพัฒนาสามารถสร้างและฝึกโมเดล ML ได้อย่างรวดเร็วและง่ายดาย จากนั้นปรับใช้โดยตรงในสภาพแวดล้อมที่โฮสต์พร้อมสำหรับการผลิต มีอินสแตนซ์สมุดบันทึกการเขียน Jupyter แบบบูรณาการเพื่อให้เข้าถึงแหล่งข้อมูลของคุณได้ง่ายสำหรับการสำรวจและวิเคราะห์ คุณจึงไม่ต้องจัดการเซิร์ฟเวอร์ อีกทั้งยังให้บริการทั่วไป อัลกอริทึม ML ที่ได้รับการปรับให้ทำงานอย่างมีประสิทธิภาพกับข้อมูลขนาดใหญ่มากในสภาพแวดล้อมแบบกระจาย

การอนุมานตามเวลาจริงของ SageMaker เหมาะอย่างยิ่งสำหรับปริมาณงานที่มีข้อกำหนดตามเวลาจริง แบบโต้ตอบ และมีเวลาแฝงต่ำ ด้วยการอนุมานตามเวลาจริงของ SageMaker คุณสามารถปรับใช้ตำแหน่งข้อมูล REST ที่ได้รับการสำรองโดยประเภทอินสแตนซ์เฉพาะด้วยการประมวลผลและหน่วยความจำจำนวนหนึ่ง การปรับใช้ตำแหน่งข้อมูลแบบเรียลไทม์ของ SageMaker เป็นเพียงขั้นตอนแรกในเส้นทางสู่การผลิตสำหรับลูกค้าจำนวนมาก เราต้องการเพิ่มประสิทธิภาพของอุปกรณ์ปลายทางเพื่อให้ได้ธุรกรรมเป้าหมายต่อวินาที (TPS) ในขณะที่ปฏิบัติตามข้อกำหนดด้านเวลาแฝง ส่วนใหญ่ของการเพิ่มประสิทธิภาพสำหรับการอนุมานคือการทำให้แน่ใจว่าคุณเลือกประเภทอินสแตนซ์ที่เหมาะสมและนับถอยหลังไปยังจุดสิ้นสุด

โพสต์นี้อธิบายแนวทางปฏิบัติที่ดีที่สุดสำหรับการทดสอบโหลดตำแหน่งข้อมูล SageMaker เพื่อค้นหาการกำหนดค่าที่ถูกต้องสำหรับจำนวนอินสแตนซ์และขนาด สิ่งนี้สามารถช่วยให้เราเข้าใจข้อกำหนดขั้นต่ำของอินสแตนซ์ที่จัดเตรียมเพื่อให้ตรงตามข้อกำหนดด้านเวลาแฝงและ TPS จากนั้น เราจะเจาะลึกวิธีที่คุณสามารถติดตามและทำความเข้าใจเมตริกและประสิทธิภาพของตำแหน่งข้อมูล SageMaker โดยใช้ อเมซอน คลาวด์วอตช์ ตัวชี้วัด

ขั้นแรก เราทำการเปรียบเทียบประสิทธิภาพของโมเดลของเราในอินสแตนซ์เดียวเพื่อระบุ TPS ที่สามารถจัดการได้ตามข้อกำหนดด้านเวลาแฝงที่ยอมรับได้ของเรา จากนั้นเราจะคาดการณ์ผลการวิจัยเพื่อตัดสินใจเกี่ยวกับจำนวนอินสแตนซ์ที่เราต้องการเพื่อจัดการกับทราฟฟิกการผลิตของเรา สุดท้าย เราจำลองการรับส่งข้อมูลระดับการผลิตและตั้งค่าการทดสอบโหลดสำหรับตำแหน่งข้อมูล SageMaker แบบเรียลไทม์เพื่อยืนยันว่าตำแหน่งข้อมูลของเราสามารถจัดการกับภาระงานระดับการผลิตได้ โค้ดทั้งชุดสำหรับตัวอย่างมีดังต่อไปนี้ พื้นที่เก็บข้อมูล GitHub.

ภาพรวมของโซลูชัน

สำหรับโพสต์นี้ เราปรับใช้การฝึกอบรมล่วงหน้า Hugging Face รุ่น DitilBERT จาก กอดใบหน้าฮับ. โมเดลนี้สามารถทำงานได้หลายอย่าง แต่เราส่งเพย์โหลดสำหรับการวิเคราะห์ความรู้สึกและการจัดประเภทข้อความโดยเฉพาะ ด้วยเพย์โหลดตัวอย่างนี้ เรามุ่งมั่นที่จะบรรลุ 1000 TPS

ปรับใช้ปลายทางแบบเรียลไทม์

โพสต์นี้ถือว่าคุณคุ้นเคยกับวิธีการปรับใช้โมเดล อ้างถึง สร้างปลายทางของคุณและปรับใช้โมเดลของคุณ เพื่อทำความเข้าใจภายในที่อยู่เบื้องหลังการโฮสต์จุดสิ้นสุด สำหรับตอนนี้ เราสามารถชี้ไปที่โมเดลนี้ได้อย่างรวดเร็วใน Hugging Face Hub และปรับใช้จุดสิ้นสุดแบบเรียลไทม์ด้วยส่วนย่อยของโค้ดต่อไปนี้:

# Hub Model configuration. https://huggingface.co/models
hub = { 'HF_MODEL_ID':'distilbert-base-uncased', 'HF_TASK':'text-classification'
} # create Hugging Face Model Class
huggingface_model = HuggingFaceModel(
transformers_version='4.17.0',
pytorch_version='1.10.2',
py_version='py38',
env=hub,
role=role,
) # deploy model to SageMaker Inference
predictor = huggingface_model.deploy(
initial_instance_count=1, # number of instances
instance_type='ml.m5.12xlarge' # ec2 instance type
)

มาทดสอบจุดสิ้นสุดของเราอย่างรวดเร็วด้วยเพย์โหลดตัวอย่างที่เราต้องการใช้สำหรับการทดสอบโหลด:

import boto3
import json
client = boto3.client('sagemaker-runtime')
content_type = "application/json"
request_body = {'inputs': "I am super happy right now."}
data = json.loads(json.dumps(request_body))
payload = json.dumps(data)
response = client.invoke_endpoint(
EndpointName=predictor.endpoint_name,
ContentType=content_type,
Body=payload)
result = response['Body'].read()
result

โปรดทราบว่าเรากำลังสำรองข้อมูลปลายทางโดยใช้จุดเดียว อเมซอน อีลาสติก คอมพิวท์ คลาวด์ (Amazon EC2) อินสแตนซ์ประเภท ml.m5.12xlarge ซึ่งมี 48 vCPU และหน่วยความจำ 192 GiB จำนวน vCPU เป็นตัวบ่งชี้ที่ดีของการทำงานพร้อมกันที่อินสแตนซ์สามารถจัดการได้ โดยทั่วไป ขอแนะนำให้ทดสอบอินสแตนซ์ประเภทต่างๆ เพื่อให้แน่ใจว่าเรามีอินสแตนซ์ที่มีทรัพยากรที่ใช้อย่างเหมาะสม หากต้องการดูรายการอินสแตนซ์ SageMaker ทั้งหมดและพลังการประมวลผลที่สอดคล้องกันสำหรับการอนุมานแบบเรียลไทม์ โปรดดูที่ ราคา Amazon SageMaker.

เมตริกที่จะติดตาม

ก่อนที่เราจะเข้าสู่การทดสอบการโหลด สิ่งสำคัญคือต้องเข้าใจว่าเมตริกใดที่จะติดตามเพื่อทำความเข้าใจการแจกแจงประสิทธิภาพของตำแหน่งข้อมูล SageMaker ของคุณ CloudWatch เป็นเครื่องมือบันทึกหลักที่ SageMaker ใช้เพื่อช่วยให้คุณเข้าใจเมตริกต่างๆ ที่อธิบายประสิทธิภาพของจุดสิ้นสุดของคุณ คุณสามารถใช้บันทึกของ CloudWatch เพื่อดีบักการเรียกตำแหน่งข้อมูลของคุณ คำสั่งการบันทึกและการพิมพ์ทั้งหมดที่คุณมีในรหัสอนุมานจะถูกรวบรวมไว้ที่นี่ สำหรับข้อมูลเพิ่มเติม โปรดดูที่ Amazon CloudWatch ทำงานอย่างไร.

มีเมตริกสองประเภทที่ CloudWatch ครอบคลุมสำหรับ SageMaker: ระดับอินสแตนซ์และเมตริกการเรียก

เมตริกระดับอินสแตนซ์

พารามิเตอร์ชุดแรกที่ต้องพิจารณาคือเมตริกระดับอินสแตนซ์: CPUUtilization และ MemoryUtilization (สำหรับอินสแตนซ์ที่ใช้ GPU GPUUtilization) สำหรับ CPUUtilizationคุณอาจเห็นเปอร์เซ็นต์ที่สูงกว่า 100% ในตอนแรกใน CloudWatch เป็นสิ่งสำคัญที่ต้องตระหนักสำหรับ CPUUtilizationกำลังแสดงผลรวมของคอร์ CPU ทั้งหมด ตัวอย่างเช่น หากอินสแตนซ์ที่อยู่เบื้องหลังตำแหน่งข้อมูลของคุณมี vCPU 4 ตัว แสดงว่าช่วงการใช้งานมีมากถึง 400% MemoryUtilizationในทางกลับกัน อยู่ในช่วง 0–100%

โดยเฉพาะคุณสามารถใช้ CPUUtilization เพื่อทำความเข้าใจอย่างลึกซึ้งยิ่งขึ้นว่าคุณมีฮาร์ดแวร์เพียงพอหรือเกินจำนวนหรือไม่ หากคุณมีอินสแตนซ์ที่ใช้งานน้อย (น้อยกว่า 30%) คุณอาจลดขนาดประเภทอินสแตนซ์ของคุณได้ ในทางกลับกัน หากคุณใช้ประโยชน์ได้ประมาณ 80–90% การเลือกอินสแตนซ์ที่มีการประมวลผล/หน่วยความจำดีกว่าจะเป็นประโยชน์ จากการทดสอบของเรา เราแนะนำให้ใช้ฮาร์ดแวร์ของคุณประมาณ 60–70%

เมตริกการร้องขอ

ตามที่ชื่อแนะนำ เมตริกการร้องขอเป็นที่ที่เราสามารถติดตามเวลาแฝงตั้งแต่ต้นทางถึงปลายทางของการเรียกใช้ใดๆ ไปยังจุดสิ้นสุดของคุณ คุณสามารถใช้เมตริกการเรียกเพื่อบันทึกจำนวนข้อผิดพลาดและประเภทของข้อผิดพลาด (5xx, 4xx และอื่นๆ) ที่ปลายทางของคุณอาจประสบ ที่สำคัญกว่านั้น คุณสามารถเข้าใจการแบ่งเวลาแฝงของการโทรปลายทางของคุณ สิ่งเหล่านี้สามารถจับภาพได้มากมาย ModelLatency และ OverheadLatency เมตริกตามที่แสดงในแผนภาพต่อไปนี้

พื้นที่ ModelLatency เมตริกจะบันทึกเวลาที่การอนุมานใช้ภายในคอนเทนเนอร์แบบจำลองที่อยู่ด้านหลังตำแหน่งข้อมูล SageMaker โปรดทราบว่าโมเดลคอนเทนเนอร์ยังมีโค้ดหรือสคริปต์การอนุมานแบบกำหนดเองที่คุณผ่านการอนุมาน หน่วยนี้บันทึกเป็นไมโครวินาทีเป็นเมตริกการเรียก และโดยทั่วไป คุณสามารถสร้างกราฟเปอร์เซ็นไทล์ทั่วทั้ง CloudWatch (p99, p90 และอื่นๆ) เพื่อดูว่าคุณบรรลุเป้าหมายเวลาแฝงหรือไม่ โปรดทราบว่าปัจจัยหลายอย่างอาจส่งผลต่อเวลาแฝงของโมเดลและคอนเทนเนอร์ เช่น ปัจจัยต่อไปนี้:

• สคริปต์การอนุมานแบบกำหนดเอง – ไม่ว่าคุณจะติดตั้งคอนเทนเนอร์ของคุณเองหรือใช้คอนเทนเนอร์ที่ใช้ SageMaker พร้อมตัวจัดการการอนุมานแบบกำหนดเอง แนวปฏิบัติที่ดีที่สุดคือทำโปรไฟล์สคริปต์ของคุณเพื่อตรวจจับการดำเนินการใดๆ ก็ตามที่เพิ่มเวลาแฝงให้กับเวลาแฝงของคุณโดยเฉพาะ
• โปรโตคอลการสื่อสาร – พิจารณาการเชื่อมต่อ REST กับ gRPC กับเซิร์ฟเวอร์โมเดลภายในคอนเทนเนอร์โมเดล
• การเพิ่มประสิทธิภาพกรอบโมเดล – นี่คือเฟรมเวิร์กเฉพาะ เช่น กับ TensorFlowมีตัวแปรสภาพแวดล้อมจำนวนหนึ่งที่คุณสามารถปรับแต่งได้ซึ่งเฉพาะกับ TF Serving ตรวจสอบให้แน่ใจว่าได้ตรวจสอบคอนเทนเนอร์ที่คุณใช้อยู่ และหากมีการเพิ่มประสิทธิภาพเฉพาะเฟรมเวิร์กใดๆ คุณสามารถเพิ่มภายในสคริปต์หรือเป็นตัวแปรสภาพแวดล้อมเพื่อแทรกลงในคอนเทนเนอร์

OverheadLatency วัดจากเวลาที่ SageMaker ได้รับคำขอจนกระทั่งตอบกลับไปยังไคลเอ็นต์ ลบด้วยเวลาแฝงของโมเดล ส่วนนี้อยู่นอกเหนือการควบคุมของคุณเป็นส่วนใหญ่และอยู่ภายใต้เวลาที่ค่าโสหุ้ยของ SageMaker ใช้ไป

เวลาแฝงจากต้นทางถึงปลายทางโดยรวมขึ้นอยู่กับปัจจัยหลายอย่างและไม่จำเป็นต้องเป็นผลรวมของ ModelLatency บวก OverheadLatency. ตัวอย่างเช่น หากคุณลูกค้ากำลังสร้าง InvokeEndpoint การเรียก API ผ่านอินเทอร์เน็ต จากมุมมองของลูกค้า เวลาแฝงจากต้นทางถึงปลายทางจะเป็นอินเทอร์เน็ต + ModelLatency + OverheadLatency. ด้วยเหตุนี้ เมื่อโหลดทดสอบจุดสิ้นสุดของคุณเพื่อเปรียบเทียบจุดสิ้นสุดอย่างแม่นยำ ขอแนะนำให้เน้นที่เมตริกจุดสิ้นสุด (ModelLatency, OverheadLatencyและ InvocationsPerInstance) เพื่อเปรียบเทียบจุดสิ้นสุดของ SageMaker อย่างแม่นยำ ปัญหาใดๆ ที่เกี่ยวข้องกับเวลาแฝงจากต้นทางถึงปลายทางสามารถแยกออกต่างหากได้

คำถามสองสามข้อที่ควรพิจารณาเกี่ยวกับเวลาแฝงจากต้นทางถึงปลายทาง:

• ไคลเอนต์ที่เรียกใช้จุดสิ้นสุดของคุณอยู่ที่ไหน
• มีเลเยอร์ตัวกลางใดๆ ระหว่างไคลเอนต์ของคุณกับรันไทม์ SageMaker หรือไม่

ปรับขนาดอัตโนมัติ

เราไม่ได้กล่าวถึงการปรับขนาดอัตโนมัติในโพสต์นี้โดยเฉพาะ แต่เป็นการพิจารณาที่สำคัญเพื่อจัดเตรียมจำนวนอินสแตนซ์ที่ถูกต้องตามปริมาณงาน คุณสามารถแนบไฟล์ นโยบายการปรับขนาดอัตโนมัติ ไปยังตำแหน่งข้อมูล SageMaker ของคุณ มีตัวเลือกการปรับขนาดที่แตกต่างกัน เช่น TargetTrackingScaling, SimpleScalingและ StepScaling. สิ่งนี้ทำให้จุดสิ้นสุดของคุณสามารถปรับขนาดเข้าและออกโดยอัตโนมัติตามรูปแบบการรับส่งข้อมูลของคุณ

ตัวเลือกทั่วไปคือการติดตามเป้าหมาย ซึ่งคุณสามารถระบุเมตริก CloudWatch หรือเมตริกแบบกำหนดเองที่คุณกำหนดและปรับขนาดตามนั้น การใช้การปรับอัตโนมัติเป็นประจำกำลังติดตาม InvocationsPerInstance เมตริก หลังจากที่คุณระบุคอขวดที่ TPS หนึ่งๆ แล้ว คุณมักจะใช้สิ่งนั้นเป็นเมตริกเพื่อปรับขนาดอินสแตนซ์ให้มีจำนวนมากขึ้นเพื่อให้สามารถรองรับปริมาณการใช้งานสูงสุดได้ หากต้องการดูรายละเอียดเชิงลึกของตำแหน่งข้อมูล SageMaker ที่ปรับขนาดอัตโนมัติ โปรดดูที่ การกำหนดค่าปลายทางการอนุมานการปรับขนาดอัตโนมัติใน Amazon SageMaker.

โหลดการทดสอบ

แม้ว่าเราจะใช้ Locust เพื่อแสดงวิธีโหลดการทดสอบตามขนาด หากคุณพยายามปรับขนาดอินสแตนซ์หลังจุดสิ้นสุดของคุณให้เหมาะสม ผู้แนะนำการอนุมาน SageMaker เป็นทางเลือกที่มีประสิทธิภาพมากกว่า ด้วยเครื่องมือทดสอบโหลดของบุคคลที่สาม คุณต้องปรับใช้จุดสิ้นสุดด้วยตนเองในอินสแตนซ์ต่างๆ ด้วยโปรแกรมแนะนำการอนุมาน คุณสามารถส่งอาร์เรย์ของประเภทอินสแตนซ์ที่คุณต้องการโหลดการทดสอบ แล้ว SageMaker จะหมุน ตำแหน่งงาน สำหรับแต่ละกรณีเหล่านี้

ปาทังกา

สำหรับตัวอย่างนี้ เราใช้ ปาทังกาซึ่งเป็นเครื่องมือทดสอบโหลดแบบโอเพ่นซอร์สที่คุณสามารถนำไปใช้ได้โดยใช้ Python Locust คล้ายกับเครื่องมือทดสอบโหลดแบบโอเพ่นซอร์สอื่นๆ แต่มีประโยชน์บางประการ:

• ง่ายต่อการตั้งค่า – ดังที่เราสาธิตในโพสต์นี้ เราจะส่งสคริปต์ Python อย่างง่ายที่สามารถปรับโครงสร้างใหม่สำหรับตำแหน่งข้อมูลและเพย์โหลดเฉพาะของคุณได้อย่างง่ายดาย
• กระจายและปรับขนาดได้ – ตั๊กแตนเป็นไปตามเหตุการณ์และใช้ประโยชน์ เกเวนต์ ภายใต้ประทุน สิ่งนี้มีประโยชน์มากสำหรับการทดสอบปริมาณงานที่ทำงานพร้อมกันสูงและจำลองผู้ใช้พร้อมกันหลายพันคน คุณสามารถบรรลุ TPS ที่สูงได้ด้วยกระบวนการเดียวที่เรียกใช้ Locust แต่ก็มี การสร้างโหลดแบบกระจาย คุณลักษณะที่ช่วยให้คุณสามารถขยายไปยังหลายกระบวนการและเครื่องไคลเอ็นต์ ดังที่เราจะสำรวจในโพสต์นี้
• เมตริก Locust และ UI – ตั๊กแตนยังจับเวลาแฝงจากต้นทางถึงปลายทางเป็นเมตริก สิ่งนี้สามารถช่วยเสริมเมตริก CloudWatch ของคุณเพื่อวาดภาพการทดสอบทั้งหมดของคุณ ทั้งหมดนี้รวมอยู่ใน Locust UI ซึ่งคุณสามารถติดตามผู้ใช้ คนงาน และอื่นๆ ที่เกิดขึ้นพร้อมกันได้

เพื่อให้เข้าใจ Locust มากขึ้น ลองดูพวกเขา เอกสาร.

การตั้งค่า Amazon EC2

คุณสามารถตั้งค่า Locust ในทุกสภาพแวดล้อมที่เข้ากันได้กับคุณ สำหรับโพสต์นี้ เราตั้งค่าอินสแตนซ์ EC2 และติดตั้ง Locust ที่นั่นเพื่อดำเนินการทดสอบของเรา เราใช้อินสแตนซ์ EC5.18 ขนาด c2xlarge พลังการประมวลผลฝั่งไคลเอนต์ก็เป็นสิ่งที่ควรพิจารณาเช่นกัน ในบางครั้งเมื่อคุณหมดพลังการประมวลผลในฝั่งไคลเอ็นต์ สิ่งนี้มักจะไม่ถูกบันทึก และถูกเข้าใจผิดว่าเป็นข้อผิดพลาดจุดสิ้นสุดของ SageMaker การวางไคลเอนต์ของคุณไว้ในตำแหน่งที่มีกำลังการประมวลผลเพียงพอที่สามารถรองรับโหลดที่คุณกำลังทดสอบได้เป็นสิ่งสำคัญ สำหรับอินสแตนซ์ EC2 ของเรา เราใช้ Ubuntu Deep Learning AMI แต่คุณสามารถใช้ AMI ใดก็ได้ตราบเท่าที่คุณสามารถตั้งค่า Locust บนเครื่องได้อย่างเหมาะสม หากต้องการทำความเข้าใจวิธีเปิดใช้งานและเชื่อมต่อกับอินสแตนซ์ EC2 โปรดดูบทช่วยสอน เริ่มต้นใช้งานอินสแตนซ์ Amazon EC2 Linux.

Locust UI สามารถเข้าถึงได้ผ่านพอร์ต 8089 เราสามารถเปิดได้โดยปรับกฎกลุ่มความปลอดภัยขาเข้าสำหรับ EC2 Instance เรายังเปิดพอร์ต 22 เพื่อให้เราสามารถ SSH เข้าสู่อินสแตนซ์ EC2 พิจารณากำหนดขอบเขตแหล่งที่มาลงไปยังที่อยู่ IP เฉพาะที่คุณกำลังเข้าถึงอินสแตนซ์ EC2

หลังจากที่คุณเชื่อมต่อกับอินสแตนซ์ EC2 แล้ว เราจะตั้งค่าสภาพแวดล้อมเสมือนของ Python และติดตั้ง Locust API แบบโอเพนซอร์สผ่าน CLI:

virtualenv venv #venv is the virtual environment name, you can change as you desire
source venv/bin/activate #activate virtual environment
pip install locust

ตอนนี้เราพร้อมที่จะทำงานร่วมกับ Locust เพื่อทดสอบโหลดปลายทางของเราแล้ว

การทดสอบตั๊กแตน

การทดสอบโหลด Locust ทั้งหมดดำเนินการตามข้อ ไฟล์ตั๊กแตน ที่คุณให้ ไฟล์ Locust นี้กำหนดงานสำหรับการทดสอบโหลด นี่คือจุดที่เรากำหนด Boto3 ของเรา การเรียก API ของ invoke_endpoint. ดูรหัสต่อไปนี้:

config = Config(
retries = { 'max_attempts': 0, 'mode': 'standard'
}
) self.sagemaker_client = boto3.client('sagemaker-runtime',config=config)
self.endpoint_name = host.split('/')[-1]
self.region = region
self.content_type = content_type
self.payload = payload

ในโค้ดก่อนหน้า ให้ปรับพารามิเตอร์การเรียกปลายทางที่เรียกใช้เพื่อให้เหมาะกับการเรียกใช้รุ่นเฉพาะของคุณ เราใช้ InvokeEndpoint API โดยใช้โค้ดต่อไปนี้ในไฟล์ Locust นี่คือจุดรันทดสอบโหลดของเรา ไฟล์ Locust ที่เรากำลังใช้อยู่คือ locust_script.py.

def send(self): request_meta = { "request_type": "InvokeEndpoint", "name": "SageMaker", "start_time": time.time(), "response_length": 0, "response": None, "context": {}, "exception": None,
}
start_perf_counter = time.perf_counter() try:
response = self.sagemaker_client.invoke_endpoint(
EndpointName=self.endpoint_name,
Body=self.payload,
ContentType=self.content_type
)
response_body = response["Body"].read()

ตอนนี้เรามีสคริปต์ Locust พร้อมแล้ว เราต้องการรันการทดสอบ Locust แบบกระจายเพื่อเน้นการทดสอบอินสแตนซ์เดี่ยวของเราเพื่อดูว่าอินสแตนซ์ของเราสามารถรองรับทราฟฟิกได้มากน้อยเพียงใด

โหมดการกระจาย Locust นั้นเหมาะสมกว่าการทดสอบ Locust แบบกระบวนการเดียวเล็กน้อย ในโหมดกระจาย เรามีพนักงานหลักหนึ่งคนและหลายคน ผู้ปฏิบัติงานหลักแนะนำผู้ปฏิบัติงานเกี่ยวกับวิธีวางไข่และควบคุมผู้ใช้พร้อมกันที่กำลังส่งคำขอ ในของเรา กระจาย.sh สคริปต์ เราเห็นตามค่าเริ่มต้นว่าผู้ใช้ 240 คนจะถูกกระจายไปยังคนงาน 60 คน โปรดทราบว่า --headless ค่าสถานะใน Locust CLI จะลบคุณสมบัติ UI ของ Locust

#replace with your endpoint name in format https://<<endpoint-name>>
export ENDPOINT_NAME=https://$1 export REGION=us-east-1
export CONTENT_TYPE=application/json
export PAYLOAD='{"inputs": "I am super happy right now."}'
export USERS=240
export WORKERS=60
export RUN_TIME=1m
export LOCUST_UI=false # Use Locust UI .
.
. locust -f $SCRIPT -H $ENDPOINT_NAME --master --expect-workers $WORKERS -u $USERS -t $RUN_TIME --csv results &
.
.
. for (( c=1; c<=$WORKERS; c++ ))
do
locust -f $SCRIPT -H $ENDPOINT_NAME --worker --master-host=localhost &
done

./distributed.sh huggingface-pytorch-inference-2022-10-04-02-46-44-677 #to execute Distributed Locust test

ก่อนอื่น เราเรียกใช้การทดสอบแบบกระจายบนอินสแตนซ์เดียวที่สนับสนุนจุดสิ้นสุด แนวคิดในที่นี้คือเราต้องการเพิ่มอินสแตนซ์เดียวอย่างเต็มที่เพื่อทำความเข้าใจจำนวนอินสแตนซ์ที่เราต้องการเพื่อให้บรรลุ TPS เป้าหมายของเราในขณะที่ยังคงอยู่ภายใต้ข้อกำหนดด้านเวลาแฝงของเรา โปรดทราบว่าหากคุณต้องการเข้าถึง UI ให้เปลี่ยน Locust_UI ตัวแปรสภาพแวดล้อมเป็น True และนำ IP สาธารณะของอินสแตนซ์ EC2 ของคุณและแมปพอร์ต 8089 กับ URL

ภาพหน้าจอต่อไปนี้แสดงเมตริก CloudWatch ของเรา

ในที่สุด เราสังเกตเห็นว่าแม้ว่าเราจะบรรลุ TPS ที่ 200 ในตอนแรก แต่เราเริ่มสังเกตเห็นข้อผิดพลาด 5xx ในบันทึกฝั่งไคลเอ็นต์ EC2 ดังที่แสดงในภาพหน้าจอต่อไปนี้

เรายังสามารถตรวจสอบได้โดยดูที่เมตริกระดับอินสแตนซ์ของเราโดยเฉพาะ CPUUtilization.

ที่นี่เราสังเกตเห็น CPUUtilization เกือบ 4,800% อินสแตนซ์ ml.m5.12x.large ของเรามี 48 vCPU (48 * 100 = 4800~) สิ่งนี้ทำให้อินสแตนซ์ทั้งหมดอิ่มตัว ซึ่งช่วยอธิบายข้อผิดพลาด 5xx ของเราด้วย เรายังเห็นการเพิ่มขึ้นของ ModelLatency.

ดูเหมือนว่าอินสแตนซ์เดี่ยวของเรากำลังถูกโค่นล้ม และไม่มีคอมพิวเตอร์เพื่อรองรับโหลดเกิน 200 TPS ที่เรากำลังสังเกตอยู่ TPS เป้าหมายของเราคือ 1000 ดังนั้นลองเพิ่มจำนวนอินสแตนซ์เป็น 5 ซึ่งอาจต้องมีมากกว่านี้ในการตั้งค่าการผลิต เนื่องจากเราสังเกตเห็นข้อผิดพลาดที่ 200 TPS หลังจากถึงจุดหนึ่ง

เราเห็นทั้งในบันทึก Locust UI และ CloudWatch ว่าเรามี TPS เกือบ 1000 โดยมีอินสแตนซ์ XNUMX รายการสำรองข้อมูลปลายทาง

หากคุณเริ่มพบข้อผิดพลาดแม้กับการตั้งค่าฮาร์ดแวร์นี้ ตรวจสอบให้แน่ใจว่าได้ตรวจสอบ CPUUtilization เพื่อทำความเข้าใจภาพรวมเบื้องหลังการโฮสต์ปลายทางของคุณ สิ่งสำคัญคือต้องเข้าใจการใช้งานฮาร์ดแวร์ของคุณเพื่อดูว่าคุณจำเป็นต้องปรับขนาดเพิ่มหรือลดขนาดลงหรือไม่ บางครั้งปัญหาระดับคอนเทนเนอร์ทำให้เกิดข้อผิดพลาด 5xx แต่ถ้า CPUUtilization ต่ำ แสดงว่าไม่ใช่ฮาร์ดแวร์ของคุณ แต่เป็นบางสิ่งที่ระดับคอนเทนเนอร์หรือโมเดลที่อาจนำไปสู่ปัญหาเหล่านี้ (เช่น ตัวแปรสภาพแวดล้อมที่เหมาะสมสำหรับจำนวนผู้ปฏิบัติงานที่ไม่ได้ตั้งค่า เป็นต้น) ในทางกลับกัน หากคุณสังเกตเห็นว่าอินสแตนซ์ของคุณเริ่มอิ่มตัวแล้ว นั่นเป็นสัญญาณว่าคุณต้องเพิ่มฟลีตอินสแตนซ์ปัจจุบันหรือลองใช้อินสแตนซ์ที่ใหญ่ขึ้นด้วยฟลีตที่เล็กลง

แม้ว่าเราจะเพิ่มจำนวนอินสแตนซ์เป็น 5 เพื่อจัดการ 100 TPS เราจะเห็นได้ว่า ModelLatency เมตริกยังสูงอยู่ นี่เป็นเพราะอินสแตนซ์อิ่มตัว โดยทั่วไป เราแนะนำให้ตั้งเป้าหมายที่จะใช้ทรัพยากรของอินสแตนซ์ระหว่าง 60–70%

ทำความสะอาด

หลังจากการทดสอบการโหลด ตรวจสอบให้แน่ใจว่าได้ล้างทรัพยากรใดๆ ที่คุณไม่ได้ใช้ผ่านคอนโซล SageMaker หรือผ่าน ลบ_endpoint การเรียก API ของ Boto3 นอกจากนี้ ตรวจสอบให้แน่ใจว่าได้หยุดอินสแตนซ์ EC2 ของคุณหรือการตั้งค่าไคลเอนต์ใดๆ ก็ตามที่คุณต้องไม่ต้องเสียค่าใช้จ่ายเพิ่มเติมที่นั่นเช่นกัน

สรุป

ในโพสต์นี้ เราได้อธิบายวิธีโหลดการทดสอบตำแหน่งข้อมูลแบบเรียลไทม์ SageMaker ของคุณ เรายังกล่าวถึงเมตริกใดที่คุณควรประเมินเมื่อโหลดทดสอบปลายทางของคุณ เพื่อทำความเข้าใจรายละเอียดประสิทธิภาพของคุณ อย่าลืมเช็คเอาท์ ผู้แนะนำการอนุมาน SageMaker เพื่อทำความเข้าใจเพิ่มเติมเกี่ยวกับการปรับขนาดที่ถูกต้องของอินสแตนซ์และเทคนิคการเพิ่มประสิทธิภาพการทำงานเพิ่มเติม

เกี่ยวกับผู้เขียน

มาร์ค คาร์ป เป็นสถาปนิก ML กับทีมบริการ SageMaker เขามุ่งเน้นไปที่การช่วยลูกค้าออกแบบ ปรับใช้ และจัดการปริมาณงาน ML ตามขนาด ในเวลาว่างเขาชอบท่องเที่ยวและสำรวจสถานที่ใหม่ๆ

ราม เวจิราจุ เป็นสถาปนิก ML กับทีมบริการ SageMaker เขามุ่งเน้นที่การช่วยลูกค้าสร้างและเพิ่มประสิทธิภาพโซลูชัน AI/ML ของตนบน Amazon SageMaker ในเวลาว่าง เขาชอบท่องเที่ยวและเขียนหนังสือ

• เนื้อหาที่ขับเคลื่อนด้วย SEO และการเผยแพร่ประชาสัมพันธ์ รับการขยายวันนี้
• เพลโตบล็อคเชน Web3 Metaverse ข่าวกรอง ขยายความรู้. เข้าถึงได้ที่นี่.
• ที่มา: https://aws.amazon.com/blogs/machine-learning/best-practices-for-load-testing-amazon-sagemaker-real-time-inference-endpoints/