top of page

The Four Golden Signal : Chapter 1

* เนื้อหานี้ อ้างอิงจากบทที่ 6 ของ Google’s Site Reliability Engineering e-book

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

1ST SIGNAL: เวลาในการตอบสนอง (LATENCY)

ในช่องทางออนไลน์ที่ผู้ให้บริการไม่ได้เจอผู้ใช้งานตัวเป็นๆ เราไม่สามารถรู้ได้เลยว่าผู้ใช้ได้รับประสบการณ์การใช้งานที่ดีหรือไม่ มีงานวิจัยหลายงานที่สรุปผลว่า การตอบสนองที่รวดเร็วจะนำมาซึ่งประสบการณ์การใช้งานที่ดี เวลาในการตอบสนอง (Latency แต่บางทีใช้ว่า Response time) จึงมีความสำคัญอย่างมาก และผู้ให้บริการควรจะปรับปรุงเวลาในการตอบสนองให้ดีอยู่เสมอ


แต่วิธีการวัดค่าเวลาในการตอบสนองควรจะทำอย่างไร?


ขอยกตัวอย่างจากร้านฟาสต์ฟู้ดแห่งหนึ่ง ที่เคยมีโปรโมชั่นจับเวลาในการเสิร์ฟอาหาร ถ้าใช้เวลาเกิน 60 วินาทีจะชดเชยลูกค้าด้วยการแถมไอศกรีม!


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


วิธีวัดผลที่ได้รับการยอมรับในวงการ Web Performance Optimization ได้แก่ Visually ready, Large Contentful Page, DOM Interactive เป็นต้น ซึ่งเครื่องมือ Observability ที่มีความสามารถในเรื่อง Real-User Monitoring (RUM) จะช่วยวัดค่าในส่วนนี้ได้

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

ในกรณีการกระจายปรกติ ค่าเฉลี่ย (Average หรือ Mean) ทำหน้าที่ตัวแทนของกลุ่มได้ดี แต่ในข้อมูลที่มีความเบี่ยงเบน (Standard Deviation) สูงๆ หรือมีพวกค่าวิปลาส (Outlier) แนะนำให้ใช้ค่ามัธยฐาน (Median) แทน


อย่าลืมสนใจชนกลุ่มน้อย

ในกราฟนี้ แสดงเวลาในการตอบสนอง (ในที่นี้ใช้คำว่า Response time) ของบริการ easyTravel Customer Frontend โดยกรองเฉพาะรายการที่สำคัญ ชื่อว่า “/orange.jsf” ซึ่งค่า Median ที่เราดูอยู่ (เส้นกราฟเตี้ยๆ) นั้นค่อนข้างเสมอต้นเสมอปลาย และอยู่แค่ 573ms ซึ่งก็ดูดี แปลว่าจำนวนรายการครึ่งนึง (ตามนิยามของ Median) ใช้เวลาไม่เกินนี้


แต่ลองดูค่า Slowest 10% ซึ่งเราอาจจะเรียกอีกอย่างในทางสถิติว่า Percentile ที่ 90 จะเห็นว่าค่อนข้างแย่ ถ้ามีการใช้งานรายการ “/orange.jsf” อยู่ 10,000 รายการ ก็จะมีถึง 1,000 รายการที่ใช้เวลาทำงานเกิน 9.5 วินาที ซึ่งไม่น่าจะดีเท่าไหร่


ถ้าวัดผลแล้ว พบว่าเวลาในการตอบสนองไม่ดีล่ะ?

เครื่องมือ Observability ที่ดี จะแจ้งเตือนเวลาที่มี Latency สูงผิดปรกติโดยไม่ต้องให้ผู้ดูแลระบบคอยตั้งค่า Threshold เองอีกทั้งช่วยในการวิเคราะห์หาจุดที่เป็นสาเหตุได้ เช่นในตัวอย่างด้านล่างที่สามารถระบุได้ว่า บริการชื่อ easyTravel Customer Frontend มีรายการหนึ่งคือ /orange.jsf ใช้เวลาทำงาน 4.43 วินาที แล้วพบว่าเวลาส่วนใหญ่ใช้ไปกับการเรียกบริการ findJourneys จำนวน 5 ครั้ง ครั้งละ 733ms


ซึ่งเครื่องมืออาจจะช่วยให้เราเจาะลึกไปยังส่วนถัดไปจนถึงจุดที่เป็นต้นเหตุ เช่นในที่นี้ จุดที่ช้าคือ การทำงานของโปรแกรม (Code Execution) ในบริการชื่อ CheckDestination


เครื่องมือแสดงให้เห็นได้ว่าจริงๆ แล้วส่วนของโปรแกรมที่ล่าช้าที่สุด (99.1% ของเวลาทั้งหมด) อยู่ที่คลาส LocationParser ในคำสั่งชื่อ calculateSectionIndex โดยที่เมื่อย้อนดู Call Stack จะพบว่าน่าจะมีการวนลูปเรียกคำสั่งนี้หลายๆ ครั้ง ซึ่งนักพัฒนาสามารถใช้ข้อมูลนี้ไปแก้ไขปรับปรุงให้เวลาในการตอบสนองดีขึ้นได้


จะเห็นว่าเราสามารถใช้ Signal นี้ในการปรับปรุงประสิทธิภาพระบบได้ แต่ทีนี้ อยากให้ลองดูตัวอย่างหนึ่ง เป็นบริการ EasyTravelService ในรายการ storeBooking ซึ่งปรกติมีเวลาในการตอบสนองประมาณ 1.3 - 1.5 วินาที แต่อยู่ดีๆ ใช้เวลาลดลงเหลือแค่ 10ms ซึ่งควรจะเป็นเรื่องดีใช่หรือไม่? เราจะมาหาคำตอบในตอนต่อไป



สรุป 1st Signal: เวลาในการตอบสนอง (Latency)


  • การวัดระยะเวลาตอบสนองของระบบงานมีความซับซ้อน แต่ก็มีเครื่องมือ Observability ประเภท Real-User Monitoring (RUM) ที่จะช่วยวัดผลได้

  • ตัวแทนของกลุ่มสำหรับระยะเวลาตอบสนอง ควรจะเลือก Median ควบคู่กับ Slowest 10% หรือ Slowest 5%

  • เมื่อพบปัญหาเวลาในการตอบสนอง ควรใช้เครื่องมือเฉพาะทางในการเจาะหาส่วนประกอบที่ใช้เวลามากที่สุด (Bottleneck root cause) แต่ก็ต้องอาศัยความคุ้นเคยเช่นกัน



Comments


bottom of page