The Approach to Estimating Server Configuration for Data Warehouse (วิธีการโดยสังเขปในการประเมินสเปค Server สำหรับ Data Warehouse)


Share this article

องค์กรต่าง ๆ ในปัจจุบันที่ต้องทำงานกับข้อมูลปริมาณมาก โดยเฉพาะการจัดเก็บ และเรียกประมวลผลข้อมูลเหล่านั้นเพื่อการวิเคราะห์ จะต้องมีสถานที่เก็บจัดเก็บข้อมูล ซึ่งเรียกว่า Data Warehouse ที่สามารถรองรับความต้องการของผู้ใช้ได้เป็นอย่างดี ซึ่งปัจจัยสำคัญที่ส่งผลกับประสิทธิภาพของ Data Warehouse นั้น นอกจากตัว Software ที่เลือกใช้บริหารจัดการข้อมูลแล้ว Hardware ของตัว Server และการตั้งค่าโปรแกรมก็เป็นปัจจัยสำคัญไม่แพ้กัน หากผู้ออกแบบระบบเลือกใช้สเปคของ Hardware ที่ต่ำกว่าความต้องการงาน แน่นอนว่าจะทำให้ระบบไม่สามารถทำงานตามที่ผู้ใช้ร้องขอได้ แต่ถ้าเลือกใช้ Hardware ที่เกินกว่าความจำเป็น จะเป็นการสิ้นเปลืองงบประมาณโดยใช่เหตุ โดยเฉพาะในระบบ Cloud ที่มีการคิดค่าเช่า Virtual Machine ตามสเปคที่ผู้ใช้เลือก ดังนั้น การออกแบบ Data Warehouse ให้สามารถตอบโจทย์กับความต้องการจึงเป็นเรื่องที่สำคัญและท้าทาย

โดยทั่วไปแล้ว การออกแบบ Server configuration ของ Data Warehouse จะเริ่มต้นที่ Requirement ของระบบที่กำหนดโดยผู้ใช้หรือโปรแกรมอื่นที่ทำงานร่วมกัน ตัวอย่างเช่น ผู้ใช้มีการเรียกดูข้อมูล หรือนำข้อมูลที่ Data Warehouse ได้รับมาล่าสุดไปวิเคราะห์ทางสถิติ (data analytics) และต้องการให้ Server ส่งข้อมูลตามที่ร้องขอให้ทันภายในช่วงเวลาหนึ่ง(response time) หรือต้องการให้ระบบสามารถรับข้อมูลจำนวนหนึ่งได้ภายในหนึ่งวินาที (throughput) ผู้ออกแบบระบบจะต้องคำนึงถึงปัจจัยที่ส่งผลกระทบต่อผลลัพท์ที่สนใจ และทำการทดลองปรับส่วนต่าง ๆ ที่เกี่ยวข้องไม่ว่าจะเป็น Hardware และ Software เพื่อให้ระบบทำงานได้ตามต้องการ

บทความนี้จะกล่าวถึงแนวทางการอย่างกว้าง ๆ สำหรับผู้เริ่มต้น ในการออกแบบ server configuration ให้เหมาะสมกับ Requirement โดยจะยกตัวอย่างการใช้ Elasticsearch เป็น Data Warehouse สำหรับรับข้อมูลจากระบบภายนอกเข้ามาเก็บ และส่งข้อมูลออกไปยังหน้า Dashboard เพื่อแสดงภาพรวมข้อมูล

รูปที่ 1 ตัวอย่าง Kibana Dashboard ที่ Query ข้อมูลจาก Elasticsearch

อันดับแรก เราจะต้องมี Requirement หรือ SLA ที่ชัดเจนว่าต้องการเรียกข้อมูลแบบใด ระบบใดเป็นผู้ร้องขอข้อมูล และยอมรับช่วงเวลาตอบสนองของระบบ (response time) ได้เท่าไร ตัวอย่างของ Requirement ที่ควรคำนึงถึงคือ

  • ระยะเวลาการเก็บข้อมูลเอาไว้ในระบบ (Retention)
  • ลักษณะการใช้งาน (Use case) เช่น ใช้งานอย่างต่อเนื่อง หรือ ใช้งานหนักแค่ช่วงเวลาหนึ่ง
  • ประเภทของการ Query
  • Response time ที่ยอมรับได้ในแต่ละ Use case
  • งบประมาณ
  • ระดับของการทนต่อความล้มเหลว (Failure tolerance) และอื่นๆ

โดยทั่วไปแล้ว เป้าหมายหลักของการออกแบบคือ ทำให้ระบบสามารถตอบสนองต่อคำร้องขอข้อมูลให้ได้ทันตามที่ Requirement กำหนด เมื่อทราบถึง Requirement ที่ต้องการแล้ว ขั้นตอนต่อไปคือ ทำการศึกษาว่าปัจจัยใดบ้างที่มีผลต่อการทำงานของระบบ Data Warehouse ตัวอย่างเช่น Elasticsearch ที่เป็น NoSQL Search Engine และทำงานแบบ cluster หมายความสามารถใช้ Server หลายตัวช่วยกันทำงานได้ ดังนั้น นอกจากจำนวน vCPU, Memory และ Storage แล้ว จำนวน Node ก็ยังมีผลต่อ Performance เช่นกัน นอกจาก Hardware แล้วยังรวมถึงการตั้งค่าภายในของ Software ด้วยซึ่งขึ้นอยู่กับ Software ที่ใช้ที่มีลักษณะการทำงานที่ต่างกันออกไป ดังนั้นการปรับแต่งการตั้งค่าเหล่านี้จะมีวิธีเฉพาะของแต่ละ Software อยู่

เมื่อสามารถระบุตัวแปรที่เกี่ยวข้องทั้งหมดได้แล้ว ขั้นตอนต่อไปคือการทดลองเพื่อออกแบบ configuration ที่เหมาะสมที่สุดสำหรับ Requirement โดยเริ่มจากทำการเซ็ทระบบ Data Warehouse ขึ้นมาเบื้องต้นด้วยสเปคที่คิดว่าน่าจะทำงานได้ก่อน เช่น 4 vCPUs, 8GB Memory, 1TB HDD เพื่อใข้เป็นจุดเริ่มต้นในการทำการทดลองหา Response time อีกหนึ่งข้อสำคัญสำหรับการทดลองคือผลลัพธ์ที่ได้ต้องมาจาก Query และ Load จริงที่จะใช้ใน Production เพื่อให้ระบบที่ออกแบบพร้อมสำหรับทำงานจริง

สิ่งแรกที่ต้องทำการประเมินคือพื้นที่ Storage เพราะ Data Warehouse software ส่วนใหญ่จะมีกระบวนการ Compress หรือบีบอัดข้อมูลให้อยู่ในรูปที่ Search เร็วขึ้น หรือเหมาะกับการ Aggregate ข้อมูล ซึ่งจะทำให้ขนาดของข้อมูลเปลี่ยนไป โดยทำการส่งข้อมูลจริงขนาดพอประมาณ เช่น 1GB เข้าไปยัง Data Warehouse และเปรียบเทียบเพื่อหา Compression Ratio ของข้อมูล จากนั้นนำไปคำนวณกับปริมาณข้อมูลทั้งหมดที่รับเข้ามาต่อวันเพื่อหาขนาดข้อมูลจริงหลังจากจัดเก็บ คูณด้วยจำนวนวันที่ต้องการเก็บ (Retention) จะได้พื้นที่ Storage ที่จำเป็น จากนั้นเผื่อพื้นที่เอาไว้ 10-20% จากที่คำนวณ สำหรับ OS, Paging files และโปรแกรมอื่นๆ สุดท้ายต้องคำนวณให้พื้นที่ที่ใช้ทั้งหมดจะต้องเป็นสัดส่วนที่ไม่เกิน 85% ของ Storage จริง เมื่อคำนวณเสร็จสิ้นจะได้ขนาด Storage ที่ต้องการเพื่อเลือกขนาด Storage ที่ต้องซื้อหรือกำหนดในการตั้งค่า VMs ต่อไป

READ  การประมาณการทรัพยากรเครือข่ายและการสูญหายของข้อมูลในระบบบันทึกข้อมูล (Network Resource and Loss Estimation in Log Data Collection Systems)
รูปที่ 2 แสดงขนาดของข้อมูลที่เปลี่ยนไปตั้งแต่ข้อมูลดิบจนถึงเก็บไว้ใน Elasticsearch

สิ่งต่อมาที่ต้องประเมินคือ Resources อื่น ๆ เช่น CPU, Memory หรือชนิดของ Storage ที่ใช้ โดยในขั้นตอนนี้จะทำการส่งข้อมูลเข้ามาตามการใช้งานจริง และมีการ Query ข้อมูลตามความต้องการจริงกับตัวระบบ จากนั้นทำการ Monitor Resource ที่ระบบใช้และหาว่า Resource ใดถูกใช้มากที่สุดใน Query แต่ละประเภท ข้อมูลเหล่านี้จะช่วยชี้ให้เห็นว่าควรจะเพิ่ม Resource ตัวใดเข้าไปในระบบ

รูปที่ 3 ตัวอย่าง Resource Monitoring

จากรูปที่ 3 ตัวอย่าง Resource Monitoring นี้จะเห็นได้ว่า ภายใต้ Workload จะมีการใช้งาน CPU สูงมาก ดังนั้นอาจพิจารณาปรับเพิ่ม CPU เข้าไปใน Server สำหรับ Resource อื่นที่ยังไม่ถูกใช้จนเต็ม เช่น Memory ให้ใช้หลัก “เหลือดีกว่าขาด” หมายความว่า ไม่จำเป็นต้องปรับลดลงถ้าไม่เหลือมากจนเกินไป เพื่อรองรับ load ที่อาจเพิ่มขึ้นในอนาคต

ในระหว่างการปรับลด Resource ใน server ต้องสังเกตควบคู่ไปด้วยว่าระบบสามารถตอบสนองต่อ Query ได้ตาม Requirement หรือรับข้อมูลเข้าได้ Throughput ตามที่ต้องการหรือไม่ หาก Software รองรับในการทำงานแบบ Cluster หรือกระจายการทำงานบนหลาย ๆ Node เช่น Elasticsearch การเพิ่ม Node ขึ้นมาก็เป็นอีกทางเลือกหนึ่งในการเพิ่มประสิทธิภาพให้กับระบบ เช่นกระจายข้อมูลให้อยู่บนหลาย ๆ Node ซึ่งทำให้สามารถกระจายงาน Query ให้ช่วยกันทำงานได้ ทั้งยังเพิ่มการันตีว่าระบบจะยังสามารถทำงานได้แม้เกิดเหตุการณ์ Server ตัวใดตัวหนึ่งล่มลงไป (High Availability)

สำหรับการตั้งค่า Data Warehouse software นั้นจะมีความแตกต่างกันในแต่ละตัวที่เลือกใช้ ขึ้นอยู่กับวิธีการทำงานภายในของโปรแกรมนั้น ๆ ปัจจัยที่เกี่ยวข้องก็มีจำนวนมากเช่นกัน ตั้งแต่ Format ของข้อมูลแต่ละ field ไปจนถึงโครงสร้างของ Database/index ยกตัวอย่างเช่น สำหรับ Elasticsearch นั้นจะมีการเก็บข้อมูลในรูปแบบของ Shard ซึ่งภายในหนึ่ง Shard จะมี documents จำนวนหนึ่ง จำนวนของ Shard ใน Index จะส่งผลต่อความเร็วของการ Query เพราะระบบจะทำการค้นหาข้อมูลในแต่ละ Shard พร้อม ๆ กัน แต่ถ้าแบ่งแยกย่อย Shard มากเกินไป ก็จะทำให้เกิดการเสียเวลาในขั้นตอนรวมผลลัพธ์ได้ ดังนั้นวิธีการปรับแต่งโปรแกรม ให้อ้างอิงจากลักษณะการทำงานและคู่มือของโปรแกรมที่เลือกใช้

รูปที่ 4 ลักษณะการเก็บข้อมูลแบบ Shards ใน Elasticsearch

จะเห็นได้ว่าการออกแบบ Data Warehouse server ให้รองรับกับความต้องการได้นั้น มีปัจจัยมากมาย ไม่ว่าจะเริ่มต้นตั้งแต่ Requirement ปริมาณข้อมูล ความต้องการใช้งาน Software Hardware ยังไม่รวมถึง Network ที่ต้องสามารถรองรับ Traffic ที่สามารถเกิดขึ้นได้อีก และยังมีปัจจัยอื่น ๆ ที่ไม่สามารถกล่าวถึงได้หมดในที่นี้ ดังนั้นวิธีการออกแบบที่ดีที่สุดนั้นก็หนีไม่พ้นการทดลองกับ Use case ของงานที่ต้องการนำไปใช้ เพื่อให้ได้ configuration ที่ตอบโจทย์กับตัวงานมากที่สุด

Reference

Elastic Webinar – Quantitative Cluster Sizing

Elastic Webinar – Elasticsearch Sizing and Capacity Planning

Datacenters – How to Determine Your Cloud Server Requirements?

Helpsystems – Guide Capacity Planning Discipline for Data Center Decisions


ลงทะเบียนรับข่าวสาร

ไม่พลาดทุกการอัพเดทจาก Big Data Experience Center

Big Data Experience Center (BX)

ชั้น 14 อาคาร Knowledge Exchange Center (KX)
110/1 ถนนกรุงธนบุรี, แขวงบางลำภูล่าง เขตคลองสาน กรุงเทพฯ 10600
อีเมล์: [email protected]
Tel: 097-941-9889

ABOUT

SERVICES