การเฝ้าระวัง การส่งข้อมูล
สืบเนื่องจากการทำโปรเจคหนึ่ง เกี่ยวกับให้รถส่งตำแหน่งมายัง server ตามช่วงเวลาที่กำหนด ก็คล้ายๆ กับ IoT นี่แหละ ตามสมัยนิยม ทั่วไป ส่งมาแล้ว ก็มาวาดเส้นตำแหน่งบนแผนที่ ซึ่งก็ไม่ได้มีอะไรยาก
ดังคำที่บอกว่า การเป็นที่หนึ่ง นั้นไม่ยาก แต่ที่ยากกว่าคือรักษาตำแหน่งเอาไว้ ยากยิ่งกว่า ตำแหน่งนี้เอง ที่มีปัญหา เมื่อเราเป็นดูแผนที่ เพื่อดูเส้นทางเดินรถ ปรากฏว่า เส้นขาด พอถามคุณลุงคนขับรถ ก็บอกว่า ไม่ได้ปิดนะ ก็เปิดส่งปกติ บลาๆ แล้วสักพัก เส้นก็กลับมา (ผมคิดว่า คุณลุงอาจจะปิดโดยไม่ตั้งใจ) ปัญหามีสองประเด็น ประเด็นแรก ทำไมถึงไม่ส่งตำแหน่ง อันนี้มันสุดที่จะหาคำตอบได้ เนื่องจากคุณลุงยืนยันอย่างนั้น ประเด็นที่สอง คือ เราจะรู้ได้ไหม ว่าตำแหน่งหายไป จะได้โทรถามคุณลุง ได้เร็วขึ้น เพราะกว่าเราจะรู้ก็หลายชั่วโมง
ประเด็นที่สองนี้เอง ที่น่าจะพอทำได้ แต่เท้าความก่อนว่า ระบบที่เราทำนี้ ก็ทำแบบง่ายๆ คือมี Web API ตัวหนึ่ง แล้วให้อุปกรณ์ส่ง POST ตำแหน่งมาเรื่อยๆ ไม่ได้ใช้ Protocol หรูหราที่จะสามารถดูการมีอยู่ของอุปกรณ์ได้ หลักการที่เราจะทำในการหาว่ารถยังอยู่หรือเปล่า ก็คือการดู last updated แต่วิธีการนี้ทำได้สองแบบคือ หนึ่ง คอยไป query database เพื่อหา last updated ของรถทั้งหมด ที่ last updated มากกว่าเวลาที่กำหนด (สมมุติ ห้านาที) ซึ่งวิธีนี้ง่าย แต่ไม่ดีเลย ที่เราต้อง query database ตลอดเวลา เพื่อตอบคำถาม ที่นานๆ ทีจะเกิดเหตุการณ์เท่ากับว่า เราเสียพลังเปล่าๆ ซึ่งยิ่งถ้าเราใช้ บริการคิดตังค์แบบ pay as you go แล้วด้วย ไม่ดีแน่
ดังนั้น วิธีที่คิดออกคือ TTL (time to live) เป็นแนวคิดที่ว่า ข้อมูลจะคงอยู่ช่วงระยะเวลาหนึ่งแล้วหายไปเอง แล้วเราค่อยไปดักจับเหตุการณ์ที่ข้อมูลถูกลบ พอเกิดเหตุการณ์ดังกล่าว ก็แจ้งเตือน อย่างแรกสุดที่ทำแบบนี้ได้คือ redis เป็นฐานข้อมูลที่มีฟีเจอร์นี้ แต่ด้วยความที่ไม่อยากจะเพิ่มส่วนประกอบเข้าไปในระบบอีก เลยพยายามหาอะไรที่ใกล้เคียงกัน บน AWS ที่ใช้อยู่
นั่นก็คือ SQS (Simple Queue Service) เป็นบริการ message queue บน AWS แต่ว่า ความสามารถที่เราจะใช้นั้นไม่ได้ใช้รับส่ง message แต่เป็นความสามารถที่สามารถตั้งเวลาการมีชีวิตอยู่ของข้อความได้ ทางนั้นเรียกว่า message duration time ซึ่งให้เราตั้งได้ตั้งแต่ 1 นาทีจนถึง สิบกว่าวัน ซึ่งก็เพียงพอ ไอเดียคือว่าทุกครั้งที่รถส่งตำแหน่งเข้ามา ค่าตำแหน่งนั้นจะถูกส่งเข้า SQS ตาม Topic ที่เป็นหมายเลขงาน (เราจะเฝ้าระวังเฉพาะตอนวิ่งงาน) ซึ่งข้อความจะ ถูกเก็บไว้ใน queue เรื่อยๆ แต่กรณีนี้ queue จะไม่ถูกอ่าน แต่ข้อความที่กองไว้ จะทยอยหมดอายุซึ่งเราจะตั้งตามเวลาที่เราอยากรู้ว่ารถส่งตำแหน่งล่าสุดนานเท่าไหรแล้ว สมมุติว่าห้านาที ซึ่งถ้ารถไม่ส่งตำแหน่งนานกว่าห้านาที ใน queue ก็จะว่างเปล่า
แล้วใครละจะเป็นคน trigger เราเมื่อ queue ว่างเปล่า แน่นอนใน AWS การ monitor ต่างๆ คงไม่พ้น CloudWatch เราสามารถ add matric ของส่วนต่างๆ ใน AWS แล้วตั้ง alarm ได้ ซึ่งในที่นี้เราต้องการให้ ถ้า จำนวนข้อความใน queue น้อยกว่า 1 เป็นเวลาห้านาทีให้ส่งเมล์ เลยต้องให้ alarm ไปออก SNS (Simple Notification Service) อีกทีในการส่งเมล์ เหอๆ หลายชั้นมาก แต่จุดนี้ อนาคต SNS สามารถส่ง trigger ไปยัง Lambda ได้ ถ้าต้องการอะไรที่ขั้นสูงกว่านี้
แต่เนื่องจากว่า queue ของเรามีความ เกิดดับ ตามงานที่เกิดขึ้น คือพอรถบรรทุกเริ่มงานค่อยมาสร้าง queue เลยจำเป็นจะต้องสร้างทุกอย่างผ่าน API ของ AWS แต่เหมือนเดิมคือเราต้องซ้อมจากทาง web interface ให้คล่องก่อน แล้วค่อยมาทำผ่าน API มีขั้นตอนประมาณนี้
- คนขับกดเริ่มงาน เราส่ง API ไปสร้าง queue สำหรับงานนั้นไว้รอ โดยรถแต่ละคันมีหมายเลขงานไม่เหมือนกัน ซึ่งตอนสร้าง queue เขาจะให้เรากำหนด message duration ได้
- ทันทีที่ส่งตำแหน่งเราก็สร้าง message ให้เข้าไปไว้ตาม queue หมายเลขงาน
- หลังจากที่สร้าง queue แล้ว ก็ทำการสร้าง CloudWatch Alarm โดยผูกชื่อ queue ใน SQS กับเงือนไขว่า Minimum message visible < 1 for 5 period
- เสร็จแล้ว ก็ผูก alarm กับ SNS Topic ซึ่ง topic เราสร้างไว้ก่อนแล้ว แค่เอาหมายเลข ARN มาใส่ ซึ่ง topic นี้ มันก็จะถูกตั้งให้ส่งเมล์ได้ ซึ่งก่อนจะส่งออก ต้อง verify mail ก่อน
เราก็จะได้รับอีเมล์ตามต้องการ ด้วยเนื้อความที่อลังการ เนื่องจากปกติเขาจะส่ง alarm พวกที่เกิดความผิดปกติของระบบ ซะมากกว่า แต่เอาละ พอรู้ว่ามาจาก SQS queue ชื่ออะไร ก็จบละ ตรงนี้ก็เป็นแบบใช้พอได้แหละ ถ้าให้ดีที่สุดคงต้องมี db ช่วย แล้วถ้ามี alarm เยอะๆ เหมือนจะคิดตังค์เพิ่มรายละเอียดจำไม่ได้ แต่ไม่ได้แพงอะไรมาก
