ใน course Microservices ที่ Skooldio นั้นมีคำถามเรื่องเกี่ยวกับรูปแบบของการแลกเปลี่ยนข้อมูลระหว่าง serviceว่า CDC (Change Data Capture) และ Outbox pattern มันเป็นอย่างไรจึงทำการอธิบายพร้อมตัวอย่าง code และเครื่องมือที่ผมมีโอกาสใช้งานในงานมาบ้างเลยทำการสรุปและบันทึกแนวทางไว้นิดหน่อย
บันทึกการสอน และ แบ่งปันความรู้เรื่องของ Microservices ที่ Skooldioตั้งแต่การออกแบบ การพัฒนา การทดสอบ และ การ deployรวมไปถึงการ operate เรื่องต่าง ๆ เช่น monitoring และ observabilityจำนวน 4 วัน โดยครั้งนี้เขาบอกว่าเป็นรุ่นที่ 13 แล้วจึงทำการสรุปการแบ่งปันไว้นิดหน่อย
น่าสนใจดีกับ KIP-932: Queues for KafkaKIP (Kafka Improvement Proposal) นี้ทำการใช้งาน queue ใน Kafka นั่นเองโดยปกติถ้าต้องจัดการ message ที่เข้า Topic ให้ตามรูปแบบของ Queue คือ ที่สำคัญก็ยังต้อง scale ได้ง่าย
จากการแบ่งปันเรื่อง Architecture มานิดหน่อยหนึ่งในนั้นคือ การใช้งาน API Gateway ด้วยทำให้เกิดการแนะนำ Apache APISIX นิดหน่อย ดังนั้นเพื่อช่วยทำให้เข้าใจ ก็ลองเล่นใช้งานง่ายแบบง่าย ๆ หน่อยมาเริ่มกันเลย
จากบทความเรื่อง Scaling up the Prime Video audio/video monitoring service and reducing costs by 90% ทำการอธิบายสำหรับการย้ายระบบที่อยู่ในรูปแบบของ distributed Microservicesมาเป็น Monolith หรือถ้าพูดให้ตรง ๆ คือ ย้ายออกจาก AWS Lambda นั่นเอง ซึ่งผลที่ได้รับกลับมาคือ Scale ระบบได้สูงขึ้น ระบบมีความ Resilience คือ เมื่อมีปัญหาสามารถ recovery กลับมาทำงานปกติได้ดี ที่สำคัญลดค่าใช้จ่ายไปมากกว่า 90% ดังนั้นมาดูกันว่าทาง Prime Video ทำอย่างไรบ้าง ซึ่งน่าสนใจมาก ๆ
จากงานเดิมใช้งาน RediSearch เกี่ยวการค้นหาข้อมูล (Full text search) ไปแล้วต่อมามี use case ต้องทำการค้นหาข้อมูล Geolocation (lat,lng) นั่นเองโดยมีความต้องการดังนี้ ยังค้นหาแบบ full text search ในข้อมูลจาก property ต่าง ๆ ได้ หาข้อมูลที่อยู่ใกล้ เรียงลำดับจากใกล้ไปไกลได้ กำหนดจำนวนข้อมูลที่ต้องการ มาดูกันว่าทำอย่างไรได้บ้างใน Redis นั่นเอง
บันทึกการอ่านเรื่องของปรับปรุง architecture ของระบบ Twitchซึ่งทำการปรังปรุงระบบ Monolith มายัง Microserviceโดยมีขั้นตอนการปรับปรุงที่น่าสนใจทำการเขียนใน blog 2 ตัวคือ Breaking the Monolith at Twitch: Part One Breaking the Monolith at Twitch: Part Two
จากการแบ่งปันเรื่อง Observability ของระบบงานใน Course Microservices workshop ที่ Skooldio มานั้นโดย Observability นั่นประกอบไปด้วย 3 ส่วนหลัก ๆ คือ Application metric Distributed tracing Log aggregation ต่อจากนั้นก็เอาไปทำ dashboard และ alert system ได้อีกเพื่อช่วยให้เราสามารถดูได้ว่า application ทำงานอย่างไรมีปัญหาตรงไหนบ้าง ?หรือมีสัญญาณของปัญหาที่อาจจะเกิดขึ้นไหม ?ถ้าเจอแล้ว สามารถเข้าถึงจุดเกิดเหตุได้ง่ายและรวดเร็วมากยิ่งขึ้น
จากเหตุการณ์ที่ระบบ Reddit ล่มจากการ upgrade Kubernetes นั้นก็ไปเจอการอธิบายเรื่องการสร้าง platform ของระบบ Rankingหรือระบบแนะนำ post ต่าง ๆ ในหน้า feed นั่นเองซึ่งพัฒนามาจาก service จนกลายเป็น platform ที่ให้ใช้งานโดยทำการพัฒนาใหม่ด้วยภาษา Goมีแนวทางที่น่าสนใจดังนี้
เห็นว่ามีการ share บทความเรื่อง HOW DISCORD STORES TRILLIONS OF MESSAGES ? ซึ่งเป็นบันทึกการเปลี่ยนแปลง database ที่ใช้เก็บข้อมูลที่พูดคุยต่าง ๆ ในระบบ Discordจาก MongoDB -> Cassandra -> ScyllaDBทำให้เราเห็น use case และ เหตุผลในการเปลี่ยนแปลงนั่นคือการแก้ไขปัญหานั่นเองจึงทำการสรุปสิ่งที่สนใจเอาไว้ดังนี้