บันทึกบทความไว้อ่านภายหลังเรียบร้อย

Pantip Notification ฉบับบ้านๆ

KonG
เผยแพร่แล้ว เมื่อวันที่ 8 ตุลาคม 2560 - 15:47 น.
1318

สวัสดีครับ ก่อนอื่นต้องขอออกตัวก่อนเลยว่า ส่วนตัวผมเป็นเพียงนักเขียนมือสมัครเล่น ความจำครั้งล่าสุดที่เขียนบทความอะไรยาวแบบนี้น่าจะประมาณช่วงเรียนมหาวิทยาลัยที่ต้องทำ paper เพื่อจบการศึกษาครับ วันๆ พิมพ์แต่ chat กับ coding ครับ อาจมีเล่าเรื่องบางส่วนไม่เคลียร์ต้องขออภัย บทความนี้จะอธิบายรายละเอียดขั้นตอน


อยู่มาวันหนึ่งมี social network ขนาดใหญ่ 2–3 เจ้าในโลกจำปี ค.ศ ที่แม่นๆ ไม่ได้น่าจะประมาณ 2009–2011 ได้พัฒนาระบบ Notification หรือการแสดงผลข้อมูลแบบ Realtime ขึ้นมาและเป็นจุดเด่นสำคัญให้เหล่าผู้ใช้ใน platform นั้นกลับมายัง content ที่ตัวเองสนใจและติดตาม โดยส่วนผมก็ตื่นเต้นที่ได้ใช้งานมันเหมือนกันและในฐานะที่เป็น developer มาก็เริ่มเกิดความสงสัยว่า “เห้ยมันทำได้อย่างไร และเราก็อยากทำแบบนั้นได้จัง” แล้วก็ ปี 2011 ทาง Pantip ก็มีโครงการปรับปรุงเปลี่ยนโฉมใหม่และผมก็โชคดีที่ได้มีโอกาสได้เป็นส่วนร่วมที่จะปรับปรุงมันให้ดีขึ้น และเปิดให้ใช้งาน ในปี 2013 ซึ่งก็ตามมาด้วยปัญหามากมาย ส่วนนึงเป็นเพราะองค์ความรู้มีไม่เพียงพอ แต่ก็ก้าวผ่านมันมาได้จากการลองถูกลองผิดและมีทีม Infra สนับสนุนที่ดีอย่าง บริษัทอินโนเวทีฟ เอ็กซ์ตรีมิสต์ จำกัด หรือ INOX https://www.blognone.com/node/70944


ลักษณะงานของ developer จะออกแนวค้นคว้าและพัฒนา อาจใช้ระยะยาวหรือสั้นขึ้นอยู่กับโจทย์ที่ได้รับ รวมถึงเทคโนโลยีในยุคนั้นมันสามารถทำได้แค่ไหน ซึ่งยุคนี้ต้อง (AI : Artificial Intelligence) ครับ อย่าไปเทียบกับระดับโลกเลยครับว่าเค้าก็ทำได้
(เทพของทั้งโลกเค้าไปรวมตัวกันอยู่ที่นั้น) เราเป็นเพียงจุดเล็กๆบนแผนที่โลกเท่านั้นเองต้องเรียนรู้อีกเยอะ และในช่วงที่มีการปรับปรุงเปลี่ยนโฉม Pantip ก็ได้ไปค้นพบ เจ้า Node.js ซึ่งตอนนั้น เพิ่งจะ version 0.4 ครับถ้าจำไม่ผิด และความสามารถก็ตอบโจทย์เลยครับ แต่ในช่วงปี 2011–2013 การพัฒนาระบบใหม่เราเจอโจทย์มากมายในการพัฒนา ทั้ง MVC patten , jquery ,mongodb scaling sharding replica แน่นอนครับ ณ ตอนนั้นทุกอย่างเป็นเรื่องที่ต้องปรับตัวและเรียนรู้ (สั้นๆเลย สมองเต็ม) แต่ที่กล่าวมาทั้งหมดปี 2017 เรื่องพวกนั้นเป็นเรื่องพื้นฐานไปหมดแล้ว


แต่ในปี 2017 เจ้า Node.js มัน version 8 ……….. อย่าตกใจไปครับ version 8 ซึ่งแน่นอนครับ ความสามารถของมันทำให้ชีวิตเราง่ายขึ้นรวมถึงตัวอย่างในการพัฒนาจากคนที่เค้าลองถูกลองผิดมาก่อนหน้าเราครับ และในช่วง 2–3 ปีที่ผ่านมาปฎิเสธไม่ได้เลยว่ามันเป็นยุคของ Mobile application ซึ่งก็มีผู้ให้บริการ Push Notification เกิดขึ้นมามากมายทำให้ลดระยะเวลาในการพัฒนา Push Notification บน Mobile application ขึ้นมากเลย ไม่ว่าจะเป็น 
  •  Parse Push notifications (ตอนนี้เป็น open-source ไปแล้ว) 
  • Amazon Simple Notification Service (SNS : มีค่าใช้จ่ายพอตัว)
  • Firebase Cloud Messaging (กำลังเป็นที่นิยม : ฟรี)


แน่นอนครับ ปี 2017 ทาง Pantip ได้เปิดให้ใช้งาน Mobile application ทั้ง IOS และ Android ซึ่งในอนาคตอันใกล้ เรากำลังจะใช้ Firebase ในการส่ง Push Notification เพราะมันมี Software Development Kit (SDK) ให้ครบสบายขึ้นเยอะ แต่มันอาจยังไม่ถูกใจและอาจมีข้อบกพร่องรวมถึง User experience ก็ต้องปรับปรุงกัน ,พักชมสิ่งที่น่าสนใจตัดมาประกาศรับสมัครนิดนึงครับ

https://pantip.com/about/job/senior-ux-designer และผมขอทิ้งท้ายประโยคสั้นๆ


“คุณอยากจะใช้เวลาที่เหลือตลอดชีวิตสร้างสรรค์งานที่มีคนเห็นเพียงจำนวนนึงหรืออยากมีโอกาสเปลี่ยนแปลง Pantip ให้ดีขึ้น” 


แน่นอนครับ Steve Jobs ไม่ได้กล่าวไว้ ปัจจุบัน Pantip มีผู้เข้ามาใช้งาน 40ล้าน per/month
อ้างอิงจาก https://goo.gl/3ccR2W


กลับมาเข้าเรื่องครับเมื่อไม่นานมานี้ Pantip ได้เปิดให้ใช้งาน Notification บน Desktop ครับ เวลา 10.10.10 น. ตามเวลาประเทศไทย
อ้างอิงจาก 

https://pantip.com/topic/36891994

https://www.marketingoops.com/media-ads/social-media/pantip-notification/


แต่ยังไม่มีใน Mobile Site และ Mobile application กำลังอยู่ในช่วงพัฒนาและทดสอบอะไรหลายๆอย่างครับ แต่ ณ ตอนนี้ เมื่อผู้ใช้งานตอบความเห็น Mobile Site และ Mobile application(official) รวมถึง Desktop ด้วย จะส่ง Notification มาที่ Desktop เพียงทางเดียวเท่านั้น


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


  • ปุ่มติดตามส่วนของกระทู้ เฉพาะความเห็น(comment)และตอบกลับ(reply) ทั้งหมดที่เพิ่มเข้ามาในกระทู้นั้น อธิบายเพิ่มเติม มันจะแจ้งเตือนเยอะมากเมื่อกระทู้มีการเคลื่อนไหวเหมาะกับติดตามดราม่ายิ่งนัก
  • ปุ่มติดตามส่วนของกระทู้ เฉพาะ จขกท มาตอบ อธิบายเพิ่มเติม ลองนึกภาพกระทู้ รีวิวหรือเล่าเรื่องอะไรบางอย่าง และเมื่อ จขกท มาเขียนต่อ part 1–20 อะไรประมาณนั้น ที่ ความเห็น(comment) มันจะทำการแจ้งเตือนให้เราทราบเพื่อกลับเข้ามาสู่ content ที่เราสนใจ
  • ปุ่มติดตามส่วนของกระทู้ เฉพาะความเห็น(comment) ทั้งหมดที่เพิ่มเข้ามาในกระทู้นั้น อธิบายเพิ่มเติม ลองนึกภาพว่าเราอยากจะอ่านแค่ ความเห็น(comment) เท่านั้น
  • ปุ่มติดตามส่วนของความเห็นนั้นๆ ซึ่งใน 1 กระทู้มีหลายความเห็นใช่ไหม นั้นแหละครับ กดติดตามได้ตามอัธยาศัย อธิบายเพิ่มเติม ลองนึกภาพว่ามีใครสักคนมาตอบกลับ(reply) ที่ความเห็นที่เรากำลังสนใจ หรือเป็นความเห็นของเราเอง


มาถึงส่วนทางเทคนิคกันบ้าง ทีมพัฒนาได้ใช้ mongodb ในการเก็บข้อมูลและ Redis Pub/Sub ที่ทำงานแบบ Cluster เรียกได้ว่าพระเอกชัดๆ และ coding nodejs เสริมเข้าไปในการเชื่อมต่อ websocket นั้นเอง สาเหตุที่ใช้ nodejs เพราะว่ามันง่ายในการพัฒนามากกว่าใช้ php ที่เป็น core ของระบบซะอีก ซึ่ง nodejs นั้นเป็น javascript ฝั่ง server นั้นเอง ก็ต้องขอบคุณมันที่ มันทำให้ ฝั่ง server กับ client รวมกันง่ายขึ้น


ปัญหาแรกที่เจอเลยครับ Redis ที่ทีมใช้งานอยู่บน Production ยังไม่ถูกอัพเกรดให้รองรับการทำงานแบบ cluster และสิ่งที่เจอทำไมมันไม่เหมืิอนที่อ่านมาจาก stackoverflow เพื่อนรัก หรือแม้กระทั่ง https://redis.io/topics/cluster-tutorial
ผลที่ออกมาก็คือ error พังเป็นส่วนๆบน Production นั้นแหละครับ ใครโชคดีได้เห็น error Redis cluster กันไป


ปัญหาถัดมาที่เจอครับ php ที่เป็น core ของระบบนั้นเองมีการเรียกใช้งาน libary redis ตัวนึง ซึ่งก็พบปัญหาตามหลังเปลี่ยนเป็น Cluster ก็แก้วนๆกันอยู่พักนึงเจ็บตัวกันไป ตอนนี้ก็ดีขึ้นแล้ว มากระโดดไปปัญหาใหม่ต่อดีกว่า


ปัญหาถัดมา ที่นี้ nodejs และ Server Realtime ที่ setup ขึ้นเองไม่ได้ไปใช้ service นอกครับ ทำ Load balance/Failover เพื่อรองรับปริมาณการเข้าใช้งานในปริมาณมากๆ ตัวเลขโดยประมาณแบบคร่าวๆที่มีการ query ที่ mongodb อยู่ 10-20k per/sec ผมเองไม่ได้ดูส่วนนี้ถามเค้ามาอีกที อาจมีผิดพลาด ซึ่งทีมพัฒนาได้มีการนำโปรแกรม nodejs และ Server Realtime ขึ้นไปทดสอบแบบง่ายๆ บน Production ว่าล่มไหมอะไรประมาณนั้น ผลคือ ล่ม error ไม่เป็นท่า และพยามให้กระทบกับผู้ใช้งานหลักน้อยที่สุด ต้องขอบคุณ INOX ที่ช่วยสนับสนุนหาทางออกในเรื่องนี้ครับ


ปัญหาถัดมา ที่นี้ mongodb ครับ ทีมพัฒนาได้ออกแบบ ให้เป็น Application Program Interface (API) ด้วย php ที่เป็น core ของระบบ เพื่อให้สามารถเรียกใช้งานใน Mobile application ได้สะดวก และเจ้า mongodb นี่แหละมีความสามารถ upsert อธิบายเพิ่มเติม คือ ถ้ามีข้อมูลอยู่แล้วจะทำการ update แต่ถ้าไม่มีก็จะทำการ insert ลองนึกภาพตาม แทนที่เราจะมานั่งเขียน if else ก็ใช้คำสั่ง upsert แทนครับ และทีมพัฒนาได้ออกแบบ where ที่ติด index ทุก query เพื่อการเข้าถึงข้อมูลที่รวดเร็วที่ใช้คำสั่ง upsert ใน server dev ที่ไม่มี shard key นั่นเอง

แต่พอไปบน production มันต้องมี shard key เพื่อทำหน้าที่ในการ กระจายข้อมูลนั้นแหละครับ โปรแกรมเกิดทำงานผิดพลาดขึ้นมา ทันทีไม่มีการ update ข้อมูลอะไรทั้งสิ้นก็เลย งงว่าผิดตรงไหนหว่า

อธิบายเพิ่มเติมครับ การทำ shard key ที่ collection นั้น เวลาที่เราจะ update ข้อมูล จะต้องมีการ where field ที่คุณเลือกไว้ทำ shard key เสมอ (shard key มักสร้างมาจาก index ที่คุณใช้งานบ่อยสุดใน collection นั้น) ไม่งั้นจะไม่ยอมให้ update ข้อมูลให้ 

ซึ่งในอดีต สมมุติ name เป็น shard key ของ collection ก็จะถูก where เพื่อ update {name : ‘test123’} พร้อมกับ field อื่นๆ มันเป็นเรื่องที่ทีมพัฒนา where กันอยู่ประจำเวลาจะพัฒนาอะไรเพิ่มก็จะมาดู index shard key ของ collection นั้นก่อน

แต่ทีนี้ ทีมพัฒนาได้มีการออกแบบ collection ประมาณว่า เก็บ member_id กับ topic_id และ status เพื่อใช้ในการคำนวนตัวเลขที่จะแจ้งเตือน (FB สีแดง,Pantip สีเหลือง) ว่ากระทู้นี้ ใครอ่านแล้ว ใครยังไม่อ่าน แล้วคำนวณเป็นตัวเลขดิบๆ เก็บไว้แสดงผล ในอีก collection นึง แล้วทีนี้ล่ะ เรา where ด้วยการ เพิ่ม $in เข้าไปแล้วตามด้วย upsert(อธิบายไว้บนๆ) และ mutiple(อนุญาติให้updateได้หลาย documents โดย Default มันจะ update แค่ 1 document เท่านั้นถ้าไม่มี mutiple) 

ซึ่งในความเข้าใจมันก็ต้องได้สิ แค่เพิ่ม $in เข้าไปเอง สรุปว่าไม่ได้ครับ งงเลยสิ่งที่ทีมเข้าใจมาตลอดมันผิดตรงไหนหว่า เลยหันไปปรึกษา stackoverflow เพื่อนรักตามเคย และในทีมก็ลอง where ดูแบบง่ายๆใน collection สมมุติ และทางออกก็คือ เอาคำสั่ง upsert ที่ใช้งานร่วมกับ mutiple ที่มี $in ออก และเปลี่ยน logic ในการเขียน php นิดหน่อย ส่วนตัวตกใจเหมือนกันเพราะว่าเขียนส่วนนี้เอง ทีมเค้าทดสอบระบบกันจนผ่านหมดแล้วมาติดตรงนี้ซะเอง แต่ก็ผ่านมาได้เพราะได้ความช่วยเหลือจากทีมนั่นแหละครับ


สาเหตุที่ทำไมถึง Setup Server Realtime ขึ้นเองทำไมไม่ไปใช้ Service ที่มีอยู่มากมายบนโลกใบนี้ สามารถอธิบายรายละเอียดได้ตามนี้ครับ

  • เวลามีปัญหาเนื่องจาก ไปใช้ Service ตัวอื่นที่มีการเปิดให้บริการทั่วไป เราไม่สามารถควบคุมได้เลยครับถ้ามันเกิดปัญหา เคยเจอไหมครับ AWS ล่มซึ่งเกิดไม่บ่อยหรอกครับ แปปเดียวก็กลับมา
  • Service ตัวอื่น ก็มีที่เราใช้ แต่เป็นส่วนของ Mobile application ที่จะใช้ Push Notification อย่าง Firebase ครับ มันลดเวลาในการพัฒนาได้ดีเยี่ยม
  • ถ้าเกิดตัวไหนล่มไป ก็ยังมีอีกส่วนที่ยังสามารถใช้งานได้ นั้นหมายความว่าไม่ได้หายไปทั้งระบบ อาจมีเอ๋อๆบ้างนิดหน่อย


และ ณ ตอนนี้ทีมกำลังทดสอบ Mobile application ที่จะใช้ Push Notification อย่าง Firebase โดยอาจมีระบบ queue มาคั่น ก่อนส่งไปที่ firebase คาดว่านะ เพราะว่าอนาคต Notification ทั้งระบบจะถูกส่งถี่มากๆ จากปุ่มติดตามตามลักษณะการใช้งาน และกำลังมองหาไปที่ rabbitmq หรือ redis queue อะไรประมาณนั้นและอาจมีการปรับปรุงให้ดียิ่งขึ้นครับ


สุดท้ายเลยมีเรื่องอยากจะฝากให้ช่วยกันสนับสนุนหรือแนะนำครับ

  • ทาง Pantip ได้มีการพัฒนา Platform Blog ที่ชื่อว่า https://maggang.com (สร้างบล็อกฟรี มีรายได้ ดีไซน์สวย) ช่วยกันเข้ามาเขียน บทความกันเยอะๆนะครับ
  • เรายังขาด Senior Ux Designer ที่ประกาศรับสมัครไปครับ งานท้าทายแน่นอน มีโจทย์เยอะเลย อย่างน้อยๆ ถ้าเพื่อนๆคนไหนสนใจมาร่วมทีมด้วยกัน อนาคตก็ต่อยอดได้อีกเยอะครับ (เชื่อผมสิผมเรียนมา) https://pantip.com/about/job/senior-ux-designer
  • กรณีตัวอย่างในอดีต Pantipได้สร้างความร่วมมือกับภาควิชาวิศวกรรมคอมพิวเตอร์ คณะวิศวกรรมศาสตร์ มหาวิทยาลัยเกษตรศาสตร์ ในการร่วมกันพัฒนา Auto Tag ( Machine Learning ) ถ้าเกิดหน่วยงาน/องค์กร/มหาวิทยาลัย/อื่นๆ มี Solution อื่นๆที่จะลดเวลาในการค้นคว้าและพัฒนา มันก็เป็นเรื่องที่ดีครับ อนาคตเราอาจร่วมกันทำสิ่งที่มีประโยชน์ได้เร็วขึ้นครับ
    อ้างอิงจาก https://pantip.com/topic/34918174
  • สามารถติดต่อ Co-Founder & CTO : Apisilp Trunganont เผื่อใครมีไอเดียดีๆ อยากนำเสนอครับ
    https://goo.gl/V9npWP


ความคิดเห็นต่อบทความ

  • ความเห็นบน MagGang(1)

  • ความเห็นบน Facebook()

default avatar
  • sticker1
  • sticker2
  • sticker3
  • sticker4
  • sticker5
  • sticker6
  • sticker7
  • sticker8
  • sticker9
  • sticker10
  • sticker11
  • sticker12
  • sticker13
  • sticker14
  • sticker15
  • sticker16
  • sticker17
  • sticker18
  • sticker19
  • sticker20
ความเห็นล่าสุด
  •  

Pantip Notification ฉบับบ้านๆ

    • รายงานความไม่เหมาะสม