top of page

The Four Golden Signal : Chapter 3

ตอนนี้จะเป็นตอนสุดท้ายของบทความเรื่อง Golden Signal ซึ่งจะกล่าวถึงอีก 2 Signal ที่เหลือ โดยผู้อ่านสามารถชมเนื้อหาใน ตอนที่ 1 และ ตอนที่ 2 เพื่อทำความเข้าใจใน 2 Signal ก่อนหน้า

3rd Signal: ปริมาณการใช้งาน (Traffic) 📊


ในฐานะผู้ให้บริการออนไลน์ เราก็ย่อมอยากให้บริการของเราเป็นที่นิยม มีผู้ใช้งานจำนวนมากๆ แต่ก็มีบ่อยครั้งที่จำนวนผู้ใช้งานมากเกินความสามารถของระบบที่จะรองรับได้ Traffic จึงเป็น Signal หนึ่งที่มีความสำคัญ

Signal ที่จำเป็นต้องเปรียบเทียบกับค่าในอดีต


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

เทียบกับค่าในอดีต

คาดการณ์ได้ว่า

​ใกล้เคียงของเดิม

​ไม่น่ามีปัญหา

​สูงกว่าเดิมมาก

​อาจมีปัญหา (โดนแฮค) หรือไม่มีก็ได้ (เยอะขึ้นเพราะมีกิจกรรมพิเศษ)

​น้อยกว่าเดิมมาก

มีปัญหาไปแล้ว เช่นระบบไม่ตอบสนอง

​ลดลงเหลือศูนย์

​มักจะมีปัญหา ที่ระบบเครือข่ายในฝั่งขาเข้า (F5, Firewall, ISP)

ในเครื่องมือ Observability บางตัวจะมีตัวช่วยให้เราเปรียบเทียบกับค่าในอดีตได้ง่าย เช่นเครื่องมือในรูปจะมีปุ่ม Compare



Figure 18: Compare traffic with historical data


เมื่อกดปุ่ม Compare จะช่วยเปรียบเทียบกับช่วงเวลาที่เราต้องการได้ ในตัวอย่างด้านล่างจะเปรียบเทียบกับช่วงเวลาเดียวกันของเมื่อวาน (ของเมื่อวานอยู่ฝั่งซ้าย) ซึ่งจะเห็นว่าเมื่อวานดูจะมีปริมาณการใช้งานมากกว่าวันนี้ ทั้งในรายการ /orange.jsf และอื่นๆ แต่ก็ยังเรียกได้ว่าใกล้เคียงกับของเดิม จึงไม่น่าจะมีปัญหาใดๆ



Figure 19: Comparison of request traffic


อย่างไรก็ดี เอาจจะให้เครื่องมือ Observability ช่วยเราตรวจสอบได้ว่าปัจจุบันมีปริมาณการใช้งานสูงหรือต่ำผิดปรกติหรือไม่ เช่นในรูปด้านล่าง จะมีตัวเลือกให้ตรวจจับและแจ้งเตือนได้


Figure 20: Traffic anomaly detection with AI


สรุป 3rd Signal: ปริมาณการใช้งาน (Traffic)


  • ไม่ค่อยมีประโยชน์ที่จะคอยมอนิเตอร์ใน Dashboard เพราะแปลความหมายได้ยากว่าดีหรือไม่ดี

  • การใช้งานจะต้องมีการเปรียบเทียบกับค่าในอดีตเพื่อให้ตีความหมายได้

  • ควรปล่อยให้ AI ช่วยตรวจความผิดปรกติ


4th Signal: ขีดจำกัดของระบบ (Saturation) 🧨


คำถามง่ายๆ ที่ผู้บริหารมักจะถามทีมงานที่ดูแลระบบคือ ตอนนี้ระบบเรายังรับไหวอยู่มั้ย รับได้ไหวถึงแค่ไหน

คำตอบของคำถามนี้ไม่ง่ายเลย เพราะมีแปลว่าเราต้องทราบขีดจำกัดของระบบ และมีการวัดสัญญาณที่บอกว่าถึงขีดจำกัดหรือยัง รวมถึงต้องรู้อีกว่าขีดจำกัดใดที่จะถึงก่อนอันอื่น


ขีดจำกัดของระบบคืออะไรบ้าง?


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

เช่นเดียวกัน ระบบออนไลน์ก็มีจำกัดเชิงลึกอีกมาก ที่คนภายนอกอาจจะไม่ทราบ ขอยกตัวอย่างเช่น CPU Usage, Mem Usage, Java Heap, Thread Pool, Connection Pool, Network IO, Free Disk Space, Free Worker etc.

ซึ่งก็ยากที่จะแสดงค่าเหล่านี้พร้อมๆ กัน นอกจากจะทำให้กลายเป็นหน้าจอแบบตัวอย่างด้านล่าง


Figure 21: Monitoring complexity


แล้วทำอย่างไรดีล่ะ?


ตัวอย่างด้านบนคือห้องสำหรับคนขับเครื่องบิน ซึ่งต้องใช้ความเชี่ยวชาญและการฝึกฝนสูงมากถึงจะสามารถใช้งานเครื่องมือและหน้าจอต่างๆ ได้ แต่ในองค์กรทั่วไป ผู้ใช้งานหน้าจอจะเป็นทีม Operation, Monitoring, HelpDesk หรือ Network Operating Center (NOC) ซึ่งมักเป็นบุคลากรที่ความเชี่ยวชาญไม่สูงมากนัก

ในการจับ Signal ด้านขีดจำกัด เราจึงควรเลือกเฉพาะที่สำคัญและต้องใช้จริงๆ โดยจะสามารถหาได้จาก

- คาดการณ์ไว้ก่อน ว่าจะมีคนมาใช้ระบบช่วงเวลาปรกติเท่าใด ช่วงพีคจะไปถึงเท่าไหร่

- ใช้เครื่องมือ Load Test / Stress Test จำลองดูว่าจะเกิดอะไรขึ้นถ้าจำนวนผู้ใช้งานมาถึงจุดพีค หรือถ้าเกินความคาดหมายไป 10% หรือเท่าตัว

- สังเกตดูว่าถ้าระบบรับไม่ไหว ส่วนไหนที่ถึงขีดจำกัดก่อน


เมื่อได้ขีดจำกัดที่ต้องคอยดูแล้ว ถึงจะมีการสร้าง dashboard และระบบแจ้งเตือน แต่ก็ควรจะแบ่งตามส่วนงาน ที่แต่ละทีมรับผิดชอบ เช่น

- ทีม Infrastructure สนใจขีดจำกัดประเภท CPU/MEM/Disk เป็นต้น

- ทีม Infrastructure สนใจขีดจำกัดประเภท Bandwidth usage, Connection Drop rate เป็นต้น

- ทีม Middleware สนใจขีดจำกัดพวก Heap, Thread pool, Connection pool เป็นต้น

แถมท้ายคือ การสร้าง Dashboard เพื่อแสดงผลขีดจำกัดต่างๆ ควรจะเลือกกราฟที่ช่วยในการตีความ เช่น กรณี Disk Usage ด้านล่าง ที่เอาไว้ตรวจสอบว่า Disk ใกล้เต็มหรือยัง

จะเห็นได้ว่า การเอา Donut chart มาใช้ไม่ได้ช่วยบอกอะไร แต่เมื่อเอา Top list มาแสดง ประกอบกับมีการใส่สีเพื่อเรียกความสนใจ จะช่วยลดเวลาในการคิด ทำให้บุคลากรที่ต้องใช้หน้าจอ ทำงานได้ง่ายขึ้นมาก


Figure 22: Disk Usage monitoring done differently


สรุป 4th Signal: ขีดจำกัดของระบบ (Saturation)

  • Load Test / Stress Test เพื่อหาขีดจำกัดที่มีนัยสำคัญในภาพรวม

  • ควรมีการสร้าง dashboard และแจ้งเตือนเมื่อระบบถึงขีดจำกัดเฉพาะในส่วนที่แต่ละทีมรับผิดชอบ


สำหรับบทความเรื่อง The Golden Signal ก็มีเนื้อหาเท่านี้ หวังว่าจะเป็นประโยชน์ให้กับท่านที่มีระบบบริการออนไลน์ที่ต้องดูแล แล้วถ้าต้องการตัวช่วยในด้าน Observability ก็สามารถติดต่อทีมงานของพวกเราได้ตามช่องทางด้านล่าง ไว้เจอกันใหม่ในบทความถัดไป




コメント


bottom of page