Correlation ID คืออะไร แล้วทำไมเราถึงจำเป็นต้องใช้มัน

Correlation ID

Correlation ID เป็น technic อย่างนึงที่จะช่วยหาความสัมพันธ์ที่เกิดขึ้น เพื่อที่จะช่วยเราแยก transaction ที่เกิดขึ้น ให้มองเห็นเป็น single transaction
อ่านมานิดเดียว บางท่านอาจจะสงสัย เอ๊ะ มันจะแยกแยะ transaction ยังไง แล้วมันจำเป็นต้องใช้ตรงไหน เรามาดูกันครับ

เวลาที่เราทำระบบขึ้นมา ไม่ว่าจะเป็นแบบ monolith หรือ microservices ก็ตาม
การทำงานของมันจะแยกออกจากกัน โดยอาจจะแบ่งเป็น ฝั่ง client กับฝั่ง server โดยฝั่ง client อาจจะเป็น website หรือ mobile app ซึ่งเราก็อาจจะมี load balance, api gateway จากนั้นก็เข้าสู่ server ซึ่งก็จะมี service ต่าง ๆ ที่เราทำการ implement และ ใน service ต่าง ๆ ก็จะมีการทำงานที่แตกต่างกันออกไป ยกตัวอย่างเช่น service login, service member, service payment ที่เป็น microservice ซึ่งแต่ละ service ก็อาจจะเชื่อมกันกับ id ของ user ก็ได้ เวลามีปัญหาเราก็มักจะไปดูกันที่ id ของ user คนนั้น ว่ามี action ใดบ้างที่ user คนนี้ทำ จาก log ของเรา แต่… บางครั้ง log ของเราใน api นั้น ๆ ก็อาจจะไม่มี id ของ user โผล่มาก็ได้ เพราะว่าบาง service ที่เรายิง ๆ ส่งต่อกันไป นั้นบางอันมันไม่ได้ใช้ id ของ user ทำให้เราต้องใช้เวลาในการ investigate นาน เขียนเยอะไปอาจจะงงกัน เราลองมาดูภาพประกอบกันนะครับ

Example: Simple Architecture

จากภาพด้านบน จะเห็นว่า User มีการ Request something มาที่ server ของเรา (จริง ๆ ถ้ามองภาพนี้เป็นแบบ monolith ก็ได้ครับ ภายใน Application ของเรามี Service มากมายก่ายกองในนั้น) แต่ภาพนี้จะยังไม่เห็นอะไรมาก เรามาชมกันต่อ ภาพที่ 2 ครับ

Example: Architecture spread by load balance

จากภาพนี้เราจะเห็นว่า User มีการ Request แบบ Post ผ่านเข้ามายัง Context path /login ซึ่งตัว load balance จะทำการกระจายไปยัง service login ทำให้เราไม่ทราบอีกว่า request ที่เข้ามา เข้าไปที่ server ตัวไหน ต้องขอ log มานั่งไล่อีกว่าไปตกที่ตัวไหน ซึ่งการทำงานในชีวิตจริงหากเราทำงานแบบ microservice ก็เป็นไปได้ว่า Login Service อาจจะมีการยิงไปหา service อื่น ๆ ที่เกี่ยวข้องอีก ซึ่งจะได้ดูในภาพถัดไป

Example: Login service call Profile service and call to other stakeholder.

จากภาพนี้จะเห็นว่า ตัว Login Service มีการ Call service ต่าง ๆ อีกมากมาย ไม่ใช่แค่ Profile service เท่านั้น… หรือ ภายใน Service ของตัวเอง บางครั้งใน Log เราก็ไม่ได้เขียนให้ Log มีอะไรที่มันควรจะเชื่อมต่อกันได้ “ในการค้นหาเพียงครั้งเดียว” (อันนี้ต้องคุยกันให้ดี เพราะเป็นเรื่องของ Log pattern ซึ่งควรตกลงกันตั้งแต่ก่อนเริ่มทำ Service ขึ้นมาแล้ว ว่าเราจะใช้ Pattern กันในทิศทางไหน)

เวลาที่เกิดเคสบนโปรดักชั่น!!! “ลูกค้าไม่สามารถจ่ายเงินได้” หรือ “ลูกค้า login ไม่ได้” เราทำยังไงครับ ขอ log จาก infra… หรือ ถ้าระบบมีการดูด log ลง kibana ก็ดีหน่อย ดูง่ายขึ้น เราก็อาจจะมีการหา id ของลูกค้าก่อน แล้วค่อย ๆ ไล่ไปทีละ service
service นี้ไม่เจอ service นั้นไม่เจอ มาเจออีกที service สุดท้าย… กว่าจะหาเจอใช้เวลานานมาก และ ด้วยพฤติกรรมของลูกค้า เวลา login ไม่ได้ทำยังไงครับ login ซ้ำรัว ๆ เวลาในการหาเรายิ่งมากไปอีก เพราะที่เรา search ใน log เรา search จาก id ของลูกค้า แต่มันเกิดเคสซ้ำ ๆ กันตั้งหลายอัน เรา scope ได้เพียงแค่ช่วงเวลา และ ดูจาก id ของลูกค้า กับ api ต้นทาง เราต้องทำแบบนี้ไปเรื่อย ๆ จนกว่าจะเจอต้นตอ
บางครั้ง บาง service เขาไม่จำเป็นต้องเก็บ id user เรายิ่งต้องใช้สกิลมากขึ้นในการหาว่าอะไรที่มันสามารถเชื่อมกันได้เพื่อหาต่อไปอีก…
อันนี้เป็นแค่ตัวอย่างปัญหาที่ผมคิดว่าคนส่วนใหญ่น่าจะเคยเจอนะครับ อันที่จริงยังมีอีกหลายแบบมาก ที่กว่าจะหาเจอว่ามันไปตายที่ไหน

มันจะง่ายขึ้นครับ หากท่านมี correlation ID อย่างที่ได้กล่าวไปข้างต้น correlation ID จะช่วยท่านหาความสัมพันธ์ที่เกิดขึ้น… อย่างไรหละ ลองจินตนาการครับ หากทุก service ของท่าน มี id อะไรก็ได้ซักอันนึงที่ generate ทุกครั้งที่มี request เข้ามา เริ่มตั้งแต่ฝั่ง client เลย เช่น client เป็น website เราฝัง correlation ID ไว้ตั้งแต่เนิ่น ๆ เวลา request เราก็ให้ gen แล้วส่งเข้ามาเลยทาง header ก็ได้ หรือ request ก็ได้ แล้วพอมาถึง service ก็ให้ทำการรับเอาไว้ด้วย ทุก ๆ service ที่มีการติดต่อกัน ก็ให้ใช้ correlation ID มาดูภาพกันครับ

Example: User request login with correlation ID

เมื่อเรามี Correlation ID แล้ว เวลามีเคสเข้ามา เราก็เพียงแค่ขอ user ของลูกค้า พอได้มาเราเอามาหาพอหาเจอเราก็จะเห็น Correlation ID ทีนี้ เราก็จะได้เห็น flow ทั้งหมดที่เกิดขึ้นภายใต้ request นั้น ๆ ว่ามันไปจอดตรงไหน เพียงเท่านี้เราก็สามารถ investigate ปัญหาได้เร็วขึ้นอย่างมากโขแล้วครับ ที่เหลือก็แล้วแต่ process ของแต่ละท่านเลย ว่าจะเอายังไงต่อไปกับมัน

ข้อเสนอแนะ: หาก Service ที่ท่านทำ ไม่ได้เป็น Service เริ่มต้นที่จะมีการส่ง Correlation ID มา แล้วมีบาง Service เขาไม่ส่งมา ท่านก็สามารถทำตัวเป็นคนเริ่มก็ได้ครับ เช่น ถ้าส่งมาก็ส่งต่อไป ถ้าไม่ส่งมาก็เป็นคนสร้างให้ แล้วส่งต่อ

หวังว่าบทความนี้จะช่วยให้ผู้อ่านสามารถนำไปประยุกต์ใช้กับงานของท่านได้นะครับ