เบื้องหลัง LINE OpenChat (LINE Dev Day 2019 ตอน 2)

LINE OpenChat หรือบางคนอาจจะคุ้นกับชื่อเดิม LINE Square เป็นการพูดคุยกันแบบกลุ่มขนาดใหญ่โดยมีสมาชิกได้สูงสุดถึง 5,000 คน โดยทาง LINE วางไว้ให้เป็นการสื่อสารสำหรับกลุ่มคนที่มีความสนใจเดียวกัน โดยไม่จำเป็นต้องรู้จัก หรือสนิทกัน

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

ในส่วนของการ scale การจัดเก็บข้อมูลนั้นโจทย์คือต้องมีฐานข้อมูลที่จัดเก็บข้อมูลที่ scalable โดยทาง LINE นั้นเลือกใช้ MySQL พร้อมกับ feature การทำ sharding

สาเหตุที่เลือก MySQL เพราะว่า compatible กับระบบเดิมของ LINE ส่วนโจทย์เรื่อง scalability ก็มีการทำ sharding ที่เข้ามาแก้เรื่องนี้

การทำ sharding นั้นเป็นการทำให้เก็บข้อมูลที่แตกต่างกันไว้ใน server หลายตัวได้ โดยจะใช้ shard ID เป็นตัวระบุว่าข้อมูลจัดเก็บไว้ที่ logical shard ไหน ส่วน logical shard นี้อยู่ที่ physical host ไหน ก็จะมีตัว mapping table คอยเก็บข้อมูลอีกที ข้อดีของการแยก logical shard กับ physical host ก็คือเราสามารถ scale ระบบได้โดยไม่จำเป็นต้อง rebuild shard ID ใหม่ทั้งหมด แค่แก้ไข mapping table ก็สามารถ scale เพิ่ม server ได้แล้ว

สำหรับโจทย์ถัดไปคือการส่งข้อความจำนวนมาก ด้วยความที่ OpenChat จะมีคนอยู่ใน chat room มากถึง 5,000 คน ถ้ามีกี่ message ก็คูณเข้าไป ทำให้ระบบต้อง optimize ขั้นตอนการส่งข้อความให้ได้มากที่สุด

สำหรับการ optimize message delivery นั้นมี 3 แนวทางดังนี้

• ส่งเฉพาะเมื่อจำเป็น
• ลดจำนวนข้อความที่ต้องส่ง
• ปรับความถี่ในการส่ง

สำหรับข้อแรกนั้น ทางทีมได้ทำการจำแนกข้อมูลเป็นสองแบบคือ chat event กับ user event

สำหรับ chat event ก็ทำการส่งให้ device เฉพาะเมื่ออยู่ในหน้า chat นั้นเท่านั้น ส่วน user event ก็ส่งตอนที่ user อยู่ในหน้ารวม chat เท่านี้ก็สามารถ optimize ข้อความที่จะต้องส่งได้ระดับนึงแล้ว

ขั้นตอนถัดมาคือการลดจำนวนข้อความ โดยข้อความไหนที่เป็นการ update ของข้อความเดิม ก็ให้เอาข้อความเดิมออกไปเลย ไม่ต้องส่ง เพียงเท่านี้ก็จะลดจำนวนข้อความที่ต้องส่งได้ถึง 50%

สำหรับการปรับความถี่ในการส่ง ก็จะมีเรื่องของ throttle event โดยต้องปรับเวลาในการ throttle ให้เหมาะสม ซึ่งเมื่อรวมกับข้อด้านบนจะได้ผลที่ดียิ่งขึ้นไปอีก

สำหรับการ scale ในส่วนของ server นั้นทางทีมก็นำ Armeria มาใช้ ซึ่งเป็น open source ที่ริเริ่มโดย LINE ใช้ควบคู่กับ RxJava

Armeria เป็น asynchronous Java server ซึ่งพอเป็น async แล้วทำให้ serve concurrent request ได้เยอะขึ้นมาก ทีม LINE เล่าว่า ถ้า codebase เป็น synchronous เวลาเกิดปัญหาที่ database shard ใด มันจะ cascade ไปยัง application server ด้วย

เมื่อปี 2017 ทางทีมเจอว่ามี bug ใน MySQL ส่งผลให้ db ไม่ตาย แต่ไม่ยอมตอบ query โดยกระทบ 2 เครื่องในบรรดาเครื่องทั้งหมด ซึ่งถ้าตอนนั้นใช้ synchronous codebase น่าจะเกิดการล่มเป็นวงกว้างอย่างแน่นอน

นี่ก็เป็นเนื้อหาใน session Inside OpenChat ซึ่งสิ่งที่ผมชอบที่ทาง LINE เล่าลึกในระดับ technical ดีมาก และเป็นอะไรที่เราอาจจะไม่ค่อยได้เจอในชีวิตประจำวัน ถ้าไม่ได้จับ project ใน scale ขนาดนี้

สำหรับตอนต่อไป จะมาเล่าเรื่อง infrastructure ของ LINE สามารถติดตามได้ในบล็อกนี้เลยคร้าบบบ