- การรับรู้ปัญหา
- เกิดความล่าช้าในการตอบสนองเป็นช่วง ๆ บนเซิร์ฟเวอร์ยืนยันตัวตนของ Airbridge
- เนื่องจากมีการยืนยันตัวตน/ตรวจสอบสิทธิ์ก่อนส่งคำขอ API ความล่าช้าของเซิร์ฟเวอร์ยืนยันตัวตนจึงส่งผลโดยตรงต่อเสถียรภาพของบริการทั้งหมด
- จากผลการมอนิเตอร์ พบว่าการแจ้งเตือนความล่าช้าในการตอบสนองเกิน 1 วินาทีเกิดถี่ขึ้นเรื่อย ๆ → จึงเริ่มวิเคราะห์สาเหตุและดำเนินการปรับแต่งประสิทธิภาพ
- การวิเคราะห์สาเหตุ
- (1) DB Query มากเกินไป: ในกระบวนการตรวจสอบสิทธิ์ มีการเรียก DB Query มากเกินจำเป็นในทุกคำขอ ส่งผลให้ DB Connection Pool ถูกใช้จนหมดอย่างรวดเร็ว → เกิดความล่าช้าในการตอบสนอง
- (2) HikariCP Connection Pool อิ่มตัว: เมื่อมีการรัน DB Query จำนวนมาก HikariCP pool จะอิ่มตัว → พบอาการที่เธรดต้องรอนานเกิน 30 วินาที
- (3) ประสิทธิภาพแคชต่ำ: ตั้งค่า TTL ไว้สั้นเพียง 30 วินาที + ตรรกะแคชที่ไม่มีประสิทธิภาพ → ทำให้มีโอกาสเกิด DB Query ซ้ำสูง
- กลยุทธ์การปรับปรุง
- (1) ปรับปรุงโครงสร้างการตรวจสอบสิทธิ์และการแคช
- นำวิธีดึงข้อมูลจาก DB แบบชุดเดียว (
findAllBy~) มาใช้ → DB Query ลดจาก 134 ครั้งเหลือ 4 ครั้ง (-97%)
- ใช้การแคชด้วย
mutableMap บนหน่วยความจำของแอปพลิเคชัน
- ใช้หลักการความรับผิดชอบเดียว (SRP) → แยกเมธอดและกำหนดกลยุทธ์แคชตามตรรกะย่อยแต่ละส่วน
- (2) นำโครงสร้างแคชแบบ 2 ชั้นมาใช้
- ใช้โครงสร้างผสม Local Cache (Caffeine, L1) + Remote Cache (Redis, L2)
- แยกกลยุทธ์แคชเป็น L1-Only, L2-Only และ Hybrid เพื่อเพิ่มประสิทธิภาพในการปฏิบัติการ
- วิเคราะห์การใช้หน่วยความจำของแคช → คาดว่า Redis จะมี 500,000 คีย์ ต้องการหน่วยความจำประมาณ 190MB และมีการเผื่อ buffer ด้านความปลอดภัย
- (3) การทำให้แคชเป็นโมฆะแบบอิง Redis Pub/Sub
- เลิกพึ่งพา TTL อย่างเดียว และซิงก์แคชแบบเรียลไทม์เมื่อข้อมูลสิทธิ์มีการเปลี่ยนแปลง
- เมื่อมีการเปลี่ยนแปลงบนเซิร์ฟเวอร์หนึ่ง จะใช้ Redis channel เพื่อทำให้ Local Cache ของทุกเซิร์ฟเวอร์เป็นโมฆะพร้อมกัน
- (4) ปรับจูน HikariCP connection pool
- ขยาย
maximum-pool-size จาก 10 → 30
- ปรับแต่งตัวเลือกละเอียด เช่น Connection Timeout, Idle Timeout, Max Lifetime → ลดการแย่งใช้งาน DB I/O
- การทดสอบประสิทธิภาพและผลลัพธ์: รักษาประสิทธิภาพที่เสถียรได้แม้มีทราฟฟิกขนาดใหญ่
- ผลของการปรับปรุงในสภาพแวดล้อมจริง
- หลังดีพลอย การแจ้งเตือนความล่าช้าในการตอบสนองหายไป และเวลาตอบสนองโดยรวมมีเสถียรภาพมากขึ้น
- ความน่าเชื่อถือของบริการและเสถียรภาพในการปฏิบัติการดีขึ้นอย่างมาก
- การปรับแต่งเพิ่มเติม: JVM Warm-Up
- พบปัญหาความล่าช้าในการตอบสนองของคำขอช่วงแรก อันเกิดจากการหน่วงของ JIT compilation ทันทีหลังดีพลอย
- นำ Warm-Up Runner มาใช้:
- รันคำขอจำลองล่วงหน้าเมื่อแอปพลิเคชันเริ่มทำงาน
- เมื่อมีการสลับ K8s Pod จะเริ่มรับทราฟฟิกหลัง JIT เสร็จสิ้น → เวลาตอบสนองช่วงต้นลดจาก 1.07s เหลือ 94ms
- บทสรุปและผลลัพธ์
- แก้ปัญหาความล่าช้าในการตอบสนองได้ พร้อมมีโครงสร้างรองรับการพุ่งขึ้นของทราฟฟิก
- เพิ่มเสถียรภาพและความน่าเชื่อถือของบริการ Airbridge โดยรวม
- เพิ่มการใช้ประโยชน์จากเซิร์ฟเวอร์ยืนยันตัวตน ส่งผลให้ประสิทธิภาพการพัฒนาบริการโดเมนดีขึ้น
2 ความคิดเห็น
ช่วงนี้ดูเหมือนว่าบริษัทที่ใช้บริการนี้น่าจะเพิ่มขึ้น หลังจากที่ Google ยุติบริการ Deep Link ไปเมื่อไม่นานมานี้
หวังว่าจะได้เห็นบริการที่เสถียรครับ!
โอ้...บริษัทของพวกเราก็เพิ่งทำสัญญาที่นี่เหมือนกันเมื่อไม่นานมานี้ กำลังทุ่มเททำงานอย่างหนักเพื่อปรับปรุงประสิทธิภาพสินะครับ!!!