KEYNOTE: Performance Tuning and Resource Management for Variant Dedicated and Shared-core Flavors

ในเปเปอร์สุดท้ายนี้จะเล่าถึงเทคนิคการทำ shared-core flavor และ dedicated-core flavor ซึ่งปัจจุบัน public cloud ของ NIPA Cloud มี resource type ให้เลือกทั้งหมด 2 แบบ ซึ่งในเปเปอร์นี้จะมาแบ่งปันวิธีการสร้าง machine type ทั้ง 2 แบบว่าเราทำอย่างไร

พื้นฐาน architecture ของ NIPA Cloud คือ OpenStack Victoria, Ceph Octopus และใช้ Tungsten Fabric เป็น network deploy เป็น multi availability zone (AZ) โดยที่มี DWDM วิ่งข้ามแต่ละ AZ หรือแต่ละ data center โดยออกแบบเป็น multi AZ ผ่านการโฟกัสไปที่ฟีเจอร์ที่เป็น instance, volume image และ network คือ Nova, Cinder, Glance และ Tungsten Fabric

NIPA Cloud ได้สำรวจว่า ปัจจัยที่ทำให้ผู้ที่เข้ามาใช้งานมีอะไรบ้าง โดยเรียงลำดับได้ ดังนี้ ปัจจัยแรก คือ การทำ high availability (HA) หรือการทำให้แอปพลิเคชันของผู้ที่เข้ามาใช้งานมี HA มากขึ้น ปัจจัยที่ 2 คือ ต้นทุนและความคุ้มค่าของการใช้งานคลาวด์ ปัจจัยที่ 3 คือ เรื่องความสะดวกสบายในแง่ของการ scale up/ down ปัจจัยที่ 4 คือ self-service หากวันใดที่ลูกค้าต้องการบริหารจัดการ ก็สามารถ login และทำเองได้เลย ไม่ควรจะต้องเปิด ticket หรือส่งอีเมลไปหาฝ่ายซัพพอร์ตแล้วต้องรอหลายชั่วโมง และปัจจัยสุดท้าย คือ เรื่อง pay-as-you-go pricing เนื่องจากการคิดค่าบริการรูปแบบนี้กลายเป็นองค์ประกอบทั่วไปของการใช้งานคลาวด์

หลังจากที่ NIPA Cloud มีผู้ใช้บริการ public cloud เพิ่มมากขึ้นเรื่อย ๆ ทำให้พบกับความต้องการที่หลากหลาย มีแอปพลิเคชันมากมายเข้ามาใช้งาน ยกตัวอย่างเช่น low-to-medium traffic ของ web server, CMS/blog, test/dev server, ฐานข้อมูล (database) ขนาดเล็ก, ไมโครเซอร์วิส และที่เก็บ repository รวมไปถึงโปรเจกต์ที่ไม่ว่าจะเป็น Kubernetes on production, high performance SQL, database video encoding, CI/CD หรือ batch processing

หลังจากเปิดบริการ NIPA Cloud Space ทำให้รู้ว่า ผู้ที่เข้ามาใช้บริการนั้นมีความต้องการหลากหลาย โดยโจทย์ใหญ่ คือ จะทำอย่างไรให้มี flavor หรือสเปกมาก ๆ เพื่อให้ผู้ที่เข้ามาใช้งานเลือกใช้ได้ตามความต้องการ

จุดประสงค์ของผู้เข้ามาใช้งาน คือ การมีแอปพลิเคชันที่หลากหลายติดตั้งอยู่บนระบบคลาวด์ของเรา requirement ส่วนใหญ่ คือ จะ optimize cost อย่างไรให้มีประสิทธิภาพมากที่สุด และต่อมาคือ จะทำอย่างไรให้ performance สำหรับแอปพลิเคชันที่เป็น mission critical ของลูกค้ารันได้อย่างมีประสิทธิภาพสูงที่สุด NIPA Cloud จึงได้ออกแบบ flavor 2 ส่วน ส่วนแรก คือ shared-core flavor สำหรับนักพัฒนาโครงสร้างพื้นฐาน (infrastructure) และส่วนที่สอง คือ dedicated-core flavor สำหรับกลุ่มที่ทำ production, high performance, database และ NAT gateway หรือกลุ่มที่ทำ network VPN site-to-site หรือ NFV

ในความเป็นจริงแล้ว สามารถออกแบบ flavor และ compute node ออกได้เป็น 2 เซกชัน โดย dedicated core จะเน้นไปทาง high performance ส่วน shared core จะเน้นความคุ้มค่าของต้นทุน นั่นหมายความว่า ผู้ใช้งานไม่จำเป็นที่จะต้องเอาปริมาณงาน (workload) ที่สำคัญมาก โดยอาจจะเป็น low-to-medium workload เข้ามารันอยู่ในกลุ่มเหล่านี้ หรือเป็น burstable low cost วิธีการนี้เราจะสามารถทำ over commit CPU และ RAM ได้ ส่วนฝั่ง dedicated-core flavor เราจะเน้นเรื่องความเสถียร โดยจะให้แอปพลิเคชันของลูกค้าที่เป็น medium-to-high workload เข้ามารันในนี้ โดยที่มี CPU ที่มีความเสถียรและสามารถลดค่า latency ของการเข้าถึง CPU และการเข้าถึงเมมโมรีให้ได้มากที่สุด

บริการ flavor ทั้งสองแบบที่ได้กล่าวมาข้างต้น NIPA Cloud ได้แนวคิดมาจากประสบการณ์บวกกับการวิเคราะห์ public cloud ของ hyperscaler

หากเราไปใช้งาน hyperscaler ถึงแม้ว่าสเปกของ resource จะเหมือนกันก็จริง แต่ในแง่ของ price per performance จะได้ผลลัพธ์ที่แตกต่างกันเมื่อคำนวณ รูปด้านบนเป็นตัวอย่างของ AWS ซึ่งแนวทางนี้ เราได้นำมาพัฒนา public cloud ของเราเอง

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

ตัวอย่างอย่างเช่น 4 core 16 GB ของ AWS มี flavor หรือ product line เยอะมาก เมื่อใช้งาน Geekbench ทำให้เราสามารถทดสอบของทุก flavor ได้ จากนั้นก็นำราคาบน list price ของหน้าเว็บไซต์มาคำนวณอัตราส่วน สังเกตดูว่าในความเป็นจริง การที่เราได้ 4 core อัตราส่วนของ performance และราคาไม่เท่ากัน ซึ่งเป็นปัจจัยอีกประการหนึ่งที่ส่วนใหญ่ลูกค้ามักจะมองข้ามและไม่ให้ความสำคัญ

Public cloud ของ NIPA Cloud ทำให้ผู้ใช้งานสามารถปรับเปลี่ยน resource type ได้ เพื่อใช้งาน optimize cost ที่เป็น shared-core flavor โดยจะเน้นไปทาง performance โดยเลือก dedicated เป็น core ได้

Public cloud ของ NIPA Cloud สามารถปรับเปลี่ยน resource type ได้ โดยสามารถปรับเปลี่ยนไป optimize รูปแบบที่เป็น shared-core หรือจะเน้นไปทาง performance โดยเลือกเป็น dedicated-core ก็ได้

โดยหลัก ๆ แล้ว การทำ shared-core flavor จะมีการ overcommit resource โดย overcommit คือ กรณีที่ physical server ของเรามีทั้งหมด 16 core และ leverage resource ของเราได้เพิ่มอีก 8 เท่า ซึ่งโดย default ของ OpenStack จะเป็น 8 นั่นหมายความว่า การที่เราใช้งานจริงสำหรับ VM ของเรา หลังจากที่เรา leverage แล้ว เราก็จะใช้งานได้ทั้งหมด 128 vCPU (16x8)

ตัวอย่างของการสร้าง shared-core flavor โดยการระบุพารามิเตอร์ที่เรียกว่า hw: cpu_policy=shared ซึ่งหากระบุตรงนี้เข้าไป VM ที่เราสร้างด้วย flavor นี้ก็จะเป็นประเภท shared-core

สิ่งสำคัญสิ่งหนึ่งสำหรับการทำ shared-core คือ การกำหนดโควตา CPU ถ้าหากว่าเราไม่ได้กำหนดส่วนนี้ ก็จะทำให้ VM ตัวใดตัวหนึ่งใช้งานมากเกินไป อาจกระทบกับ VM ตัวอื่นในคลัสเตอร์ด้วย นี่เป็นตัวอย่างของการกำหนดโควตา CPU ของ shared-core เราต้องทำความเข้าใจก่อนว่า shared-core คือ VM ทุกตัวที่ใช้ CPU ร่วมกัน

ต่อมาเป็นเรื่องของการทำ dedicated-core ซึ่งการทำ dedicated-core เราต้องสร้างพารามิเตอร์ และระบุพารามิเตอร์ให้กับ flavor ที่เราสร้างสองตัวหลัก ๆ คือ hw:cpu_policy=dedicated และ hw:cpu_thread_policy=require

สิ่งที่แตกต่างกันระหว่าง shared-core กับ dedicated-core ก็คือ การที่ VM ถูกสร้างขึ้นและไม่ได้แชร์กับ resource อื่น ๆ ใน compute node ซึ่ง VM แต่ละตัวก็จะถูกแยกออกจากกัน

ตรงนี้เอง ถ้าเราลงลึกเข้าไปใน libvirt ที่เป็น SML จะเห็นว่ามีค่าพารามิเตอร์ที่ map กันระหว่าง CPU ของ VM และ CPU ของ computer node กันแบบ 1:1 ส่วนนี้จะเป็นการการันตีได้ว่า VM ของเราจะไม่ได้ใช้ resource แบ่งกับเครื่องอื่น ๆ

ต่อมาเราก็มาดูในส่วนของการ configure Nova Drop เนื่องจาก Nova เป็นส่วนที่ดูแลเรื่องของ compute resource ของ OpenStack ในส่วน shared-core จะมีพารามิเตอร์ที่สำคัญอยู่ 2 ตัว คือ CPU allocation ratio ซึ่งเป็นการกำหนด overcommit โดย default OpenStack ก็จะมีการกำหนดไว้เป็นค่า 8 และพารามิเตอร์อีกตัวหนึ่ง คือ CPU shared set นั่นคือ เราสามารถกำหนดขอบเขต (range) CPU ว่าใช้ CPU ช่วงไหนบ้างที่เป็นแชร์

Dedicated-core ค่าที่มีความสำคัญสำหรับการ configuration ใน Nova คือพารามิเตอร์ที่เรียกว่า dedicated set ซึ่งความพิเศษของการทำ resource แบบนี้ คือ เราสามารถให้ shared-core และ dedicated-core อยู่ใน compute node เครื่องเดียวกันได้

ต่อมา คำถามก็คือ เมื่อกำหนดการจัดการ resource แล้วเข้าไปใช้เซอร์วิสหรือดูข้อมูลของ placement เราจะเห็นได้ว่าไอเท็ม ที่เรียกระหว่างตัว shared-core กับ dedicated-core ก็จะมีการเรียกที่แตกต่างกัน ถ้าเป็นฝั่ง dedicated-core CPU จะเรียกว่า pCPU ส่วนถ้าเป็น shared-core CPU จะเรียก vCPU

ส่วนสำคัญในการทำ shared-core และ dedicated-core นั้น จะต้องทำความเข้าใจ Huge Page ด้วย เพราะการทำ Huge Page มีส่วนสำคัญมากสำหรับการทำ dedicated-core

รูปที่เห็นด้านขวามือ คือ เมมโมรีหรือ RAM ที่เราซื้อมา (physical memory) ด้านซ้ายมือ คือ โพรเซส โดยในความเป็นจริงแล้ว การที่จะนำ RAM ที่เป็น physical RAM ใช้กับแอปพลิเคชันได้ ต้องมี operating system (OS) เป็นตัวเชื่อมตรงกลาง ซึ่ง OS มีหน้าที่ map เมมโมรีของแอปพลิเคชันที่ต้องการใช้งานไปสู่ physical memory ที่อยู่ด้านขวามือ กระบวนการนี้จะเกิด page table หรือตารางที่ใช้เก็บโพรเซสนี้ว่าต้องการใช้ memory address ไหนบน physical memory โดยปกติของ Linux หรือ OS page หนึ่งจะมีการกำหนดไซซ์อยู่ที่ 4 KB นั่นหมายความว่า ถ้าแอปพลิเคชันหรือ VM ที่เราต้องการ มีเมมโมรี 2 GB นั่นหมายความว่า เราต้องสร้าง page ทั้งหมด 2 GB หารด้วย 4 KB หรือประมาณ 500,000 page นั่นหมายความว่า page table ที่ทำแบบนี้มีถึง 500,000 page การที่เราจะค้นหาก็ใช้เวลานาน การที่เราจะเข้าไปตรวจสอบเพื่อหาว่ามีเมมโมรีนี้อยู่บน physical core ไหนก็ใช้ระยะเวลานาน เทคนิค Huge Page เป็นเทคนิคของ Linux ที่กำหนดให้ page จากเดิม 4 KB มันใหญ่ขึ้น โดยที่มี 2 ขนาด คือ 2 MB และ 1 GB ยกตัวอย่างเช่น ภาพขวามือ page จะใหญ่ขึ้น นั่นหมายความว่า ถ้า VM หรือโพรเซสต้องการเมมโมรี 2 GB เท่ากับว่า จาก 500,000 page จะเหลืออยู่แค่ 1,000 page นั่นหมายความว่าประโยชน์ของการทำ page table คือ ทำให้ page ใหญ่ขึ้น และจำนวน page ลดลง การที่จะช่วยลด page table walking คือ การสแกนหา page ก็จะลดลง เพราะว่าจำนวน page น้อยลง การทำ overhead และ memory operation ก็จะยิ่งน้อยลงไปอีก เพราะว่าจำนวน page น้อย และไม่มีการทำ swap เลย โพรเซสที่อยู่ใน Linux ที่เรียกว่า kswapd ไม่มีการทำงานส่วนนี้ ดังนั้น การทำงานของเมมโมรีโดยรวมจะมีประสิทธิภาพมากขึ้น ซึ่งใน OpenStack มันต้อง setting ก่อน ตอน boot Linux ขึ้นมา เราจำเป็นต้องเซ็ตกลับ กำหนดเลยว่าเมมโมรีของเราจะใช้ Huge Page เท่าไร ตัวอย่างคือ ใช้ page 1 GB และมีทั้งหมด 470 pages นั่นหมายความว่า เรามี page ทั้งหมด 470 page เท่านั้น แล้วถ้าสมมติว่า VM ต้องการ 4 GB ก็จะต้องการแค่ 4 page ก็คือ page ละ 1 GB 4 page นั่นหมายความว่า การทำงานของเมมโมรีของ VM ก็จะไวขึ้นจากเดิมหลายเท่าตัว โดยที่ OpenStack ก็จะต้องสร้าง flavor ที่สื่อสารกับ page ด้วย ก็คือ OpenStack flavor set แล้วกำหนด property ที่เรียกว่าฮาร์ดแวร์ mem_page_size=large

คีย์สำคัญของการลด overhead หรือ memory operation ของตัว large เวลาที่เอาไปเซ็ตจริง ๆ ซึ่งเราไม่ได้เซ็ตเป็น large ต้องเซ็ตเป็นของไซซ์ของ Huge Page ตรง large ก็คือ ถ้านำ command ที่เป็น large ไปเซ็ตก็จะใช้งานไม่ได้ เพราะว่าไซซ์ต้องเป็นไซซ์ของ Huge Page ซึ่งทาง NIPA Cloud ได้เซ็ตเอาไว้ที่ 1 GB

ต่อมา เป็นจุดที่สำคัญสำหรับการทำ dedicated-core โดย dedicated-core flavor ที่ NIPA Cloud สร้างบน public cloud จะ config โดยการเซ็ตคู่กันระหว่าง Huge Page กับ dedicated-core นั่นหมายความว่า สามารถการันตีได้เลยว่า VM ที่สร้างบน public cloud ของเราจะได้ทั้ง performance ของเมมโมรีและ CPU

ส่วนสุดท้ายจะพูดถึงการจัดการ inventory resource ซึ่งมีความสำคัญมากในการทำ capacity planning สมมติว่าเป็นตัว dedicated-core ก็จะเรียกไอเท็ม CPU ที่เข้ามาว่าเป็น pCPU ที่เราจะใช้ในการคำนวณ เมื่อคำนวณค่า capacity planning ก็จะใช้อัตราส่วน 1:1 เพราะว่า pCPU ไม่สามารถ overcommit ได้ ส่วนถ้าเป็นกรณีของ shared-core ก็จะเรียกไอเท็มที่อิงกลับมาว่าเป็น vCPU ซึ่งการคำนวณ capacity planning จะคำนวณคูณกับ overcommit ไปด้วย

ในรูปตัวอย่าง เราจะเห็นว่า vCPU มี overcommit นับเป็น 8 และ unit ใน compute node นั่นหมายความว่า ถ้าเราคำนวณ capacity planning เราก็ต้องเอา 6 คูณ 8 เพราะฉะนั้น ใน compute สามารถใช้ shared-core CPU ได้ 48 core ส่วนถ้าเป็น dedicated-core pCPU เป็น 1:1 ก็จะใช้ได้แค่ 16 core

ส่วนใหญ่แล้ว requirement จากผู้ใช้งานตั้งต้นมักถามว่ามีกี่ core แต่ไม่ได้สนใจ performance ของ core ว่าได้เท่าไหร่ อยากให้ลูกค้าเข้าใจว่าในความเป็นจริง ลูกค้าควรสนใจ performance กับราคาที่จ่ายเป็นอัตราส่วน วิธีการนี้จะสามารถช่วย optimize cost ได้ เพราะผู้ใช้งานสามารถเลือก shared core ที่เป็นการประหยัดต้นทุน และสามารถเลือก dedicated core ที่ให้ performance สูงได้ ที่สำคัญคือ ความเป็น on-demand self-service หากปริมาณการใช้งานน้อย ลูกค้าจะสามารถใช้ shared-core ได้ แต่วันหนึ่ง หากต้องมีการขึ้น production และต้องการความเสถียร ก็สามารถรีไซซ์ขึ้นไปเป็น dedicated-core ได้ในเวลาอันสั้น นั่นหมายความว่า เราสามารถใช้ OpenStack ออกแบบแพลตฟอร์มที่มีความหลากหลาย และมีความยืดหยุ่นในการทำงานได้

ส่วนต่อมา เนื่องจาก shared-core จะมีการใช้งานร่วมกัน เพราะฉะนั้น CPU utilization ของ compute node โดยรวมจะสูงกว่า dedicated-core เพราะมีการเบียดเสียดกัน นั่นหมายความว่า การใช้พลังงานไฟฟ้า (power consumption) ต่อ core ของ shared-core จะสูงกว่าเสมอ ยกตัวอย่างเช่น ถ้าเป็น shared-core นั้น CPU utilization จะอยู่ที่ 60-70% แต่ถ้าเป็น dedicated-core อาจจะอยู่ที่ 10% นั่นหมายความว่า ถ้าวัดต่อ 1 core นั้น power consumption ของ shared-core จะสูงกว่า อัตราการกินไฟก็จะสูงกว่า พัดลมของเซิร์ฟเวอร์ก็จะทำงานมากกว่าด้วย

ในอนาคต NIPA Cloud มีแผนอัปเกรด Nova ให้เป็น busted version และลดการใช้พลังงานของ CPU ด้วยเช่นกัน

กล่าวโดยสรุป public cloud ของ NIPA Cloud ถ้าเราสร้างเป็น dedicated-core ก็มั่นใจได้เลยว่า resource หรือแอปพลิเคชันที่รันอยู่บน VM ก็จะไม่แบ่ง resource กับใคร หัวข้อนี้ตั้งขึ้นมาเพื่อพิสูจน์ว่าเป็นตามที่อธิบายจริง ๆ

ผู้บรรยาย

ชาญศิลป์ ชิ้นประเสริฐ, Chief Innovation Officer

คมกฤช เวียงวิเศษ, Principle OpenStack Engineer

วันและเวลา

15 มิถุนายน 2566

เวลา 16:00 น. (ตามเวลาท้องถิ่น PDT)

สถานที่

Vancouver Convention Centre