จากงาน meetup IN PERSON! Apache Kafka® Meetup Bangkok- June 2022
ซึ่งจัดที่ตึก True Digital Park นั้น มี 2 หัวข้อ ประกอบไปด้วย

  • Speedtest: Benchmark Your Apache Kafka®
  • How We Applied Apache Kafka® in Sunday

โดยทำการสรุปความรู้ที่ได้รับไว้ดังนี้

เรื่องแรก Speedtest: Benchmark Your Apache Kafka®

เป็นการทำ benchmark สำหรับ Apache Kafka ว่า
สามารถรองรับการใช้งานได้อย่างไร ทั้ง

  • Producer เรื่องของ ack (all, 0, 1), ขนาดของ data, การ compression data
  • Consumer, consumer group, multi-thread
  • Broker
  • Topic และ partition

ตัวอย่างของการทำ benchmark อยู่ที่ github

ประกอบไปด้วย

  • docker-compose.yml สำหรับสร้าง Apache Kafka cluster
  • produce_maxMBSec เป็น bash script สำหรับการทำ benchmark ผ่าน command tool เช่น kafka-producer-perf-test และ kafka-consumer-perf-test เป็นต้น

ในทำทำ benchmark หรือ performance นั้น
จะต้องดูความต้องการทาง business เป็นหลักว่าเป็นอย่างไร เช่น

  • Throughput เยอะเท่าไร เช่น logging และ IoT
  • Latency น้อย ๆ หรือไม่ เช่น offer/promotion/discount
  • Durability สำคัญสุดหรือไม่ เช่น payment
  • Availability สุด ๆ ไหม 24×7 เช่น centralized kafka

เรื่องที่สอง How We Applied Apache Kafka® in Sunday

เป็นการอธิบายที่การนำ Apache Kafka มาใช้ในระบบงาน
มีการปรับเปลี่ยน architecture ของระบบจาก monolith มายัง microservices อย่างไร
โดยเป็นการอธิบายจากความผิดพลาดหรือปัญหาที่พบเจอ
จากสิ่งที่ได้สร้างขึ้นมา หรือการลองผิดลองถูกนั่นเอง
ซึ่งทำให้เห็นมุมมองการออกแบบ การพัฒนา และ วิธีการแก้ไข

เริ่มตั้งแต่ monolith และนำ Apache Kafka มาใช้แบบ shared topic

แน่นอนว่าง่ายและสะดวก เพราะว่า message/event ต่าง ๆ จะอยู่ที่เดียว
consumer หรือ service ไหนที่สนใจก็สามารถกรองข้อมูลที่ต้องการไปได้เลย

ต่อมาในแต่ละ service ไม่ได้ต้องการ message ทั้งหมด ต้องการบางเรื่อง
จะต้องทำการกรอง ตรวจสอบ type ของ message ที่ต้องการ
ทำการ transform data อีก
จึงทำการสร้าง consumer/service X มาคั่นตรงกลาง
เพื่อทำหน้าที่ข้างต้น เป็นเหมือนการแก้ไขปัญหาเฉพาะหน้าไปก่อน

จะเห็นได้ว่าทุก ๆ message/event เข้าไปที่ share topic เลย
ส่งผลให้เมื่อมีจำนวน service เยอะ มีจำนวนหรือชนิดของ message เยอะ
การจัดการ format ของ message ก็ยากขึ้น
เมื่อมีปัญหาในบาง message อาจจะทำระบบโดยรวมช้าลงไป
การ monitoring ก็ยากขึ้นอีก
ดังนั้นจึงทำการแก้ไขด้วยการแยก topic ตามแต่ละ domain ให้ชัดเจน
รวมทั้งลดการสร้าง Service X หรือผมจะเรียกว่า ACL (Anti-Corruption Layer) ทิ้งไป
ช่วยทำให้การพัฒนา จัดการ และ ดูแลรักษาง่ายยิ่งขึ้น
แต่ต้องระมัดระวังเรื่องของ ความสัมพันธ์ระหว่าง topic ด้วย ว่าแยกกันชัดเจนหรือไม่ ?

ปัญหาต่อ ๆ มา ก็น่าสนใจมาก และมักจะผิดกันเยอะ เช่น

  • การกำหนด message key หรือ key สำหรับการ routing message ไปยัง partition ต่าง ๆ ใน topic ไม่ถูกต้องตามที่ต้องการ หรือ ตามการใช้งานจริง ๆ เช่น ใช้ชื่อ type หรือ event name มา ทำให้มีบาง consumer ทำงานหนักเกินไป ในกรณีที่มี event name นั้นเข้ามาใน topic เยอะ ๆ ดังนั้นต้อง monitoring อยู่อย่างเสมอ
  • การจัดการ message schema ตรงนี้สำคัญมาก ๆ เพราะว่า message ใช้สำหรับการติดต่อสื่อสาร เหมือนกับ REST API ก็ต้องมี API specification ที่สำคัญต้องตรวจสอบเรื่องของ backward/forward compatability ได้อีกด้วย โดยใน Apache Kafka จะใช้งานผ่าน Schema Registry หรือจะทำเองก็ได้ มีทั้ง JSON Schema, Avro และ Protobuf เป็นต้น
  • ในแต่ละ Topic ไม่ควรมี message/event ที่หลากหลาย format
  • อีกเรื่องที่น่าคิดคือ อย่าจัดการ Apache Kafka Cluster เอง ถ้าไม่ชำนาญ เพราะว่าแทนที่จะได้ประโยชน์ กลับต้องมานั่งแก้ไขปัญหา และไม่ดีต่อ business แน่ ๆ ดังนั้นต้องดูในแต่ละที่แล้วว่าสถานการณ์เป็นอย่างไร
  • การจัดการเรื่องการเข้าถึงข้อมูลใน topic จะมีเรื่องของการใช้ Token/API key ในการตรวจสอบสิทธิ์ว่า สามารถอ่านหรือเขียนข้อมูลได้ ดังนั้นจึงมีตัวกลางในการจัดการอีกที
  • รูปแบบข้อมูลที่ทาง Sunday ใช้งานคือ JSON เพราะว่าในการตรวจสอบยังง่าย ส่วนเรื่องของตรวจสอบ schema ยังทำหรือหาวิธีที่ดี แต่คิดว่าน่าจะใช้งาน JSON Schema สำหรับการเริ่มต้น
  • ถ้าในแต่ละ consumer มีปัญหาในการทำงาน เช่น ทำงานช้า ส่งผลให้ message ใน topic ค้าง สิ่งที่แนะนำคือ ใน consumer ให้ทำการแก thread การทำงานออกมา ทำให้ไม่ต้องรอกัน หรือ ส่ง ack กลับไปตั้งแต่ได้รับ message มาแล้ว จากนั้นจึงทำงาน ถ้าทำงานไม่ผ่านค่อยทำการ retry หรือส่งกลับไปเข้า topic ใหม่ (แนว ๆ dead letter แบบทำเอง) หรือ ทำการสั่งย้อนกลับไปยัง offset ก่อนหน้า
  • ถ้าต้องการเปลี่ยนแปลงจำนวน partition ของ topic แนะนำให้สร้าง topic ใหม่ไปเลย (Static over Dynamic)
  • ทางด้วยเรื่องของ security ก็มีการทำ authentication, authorization, SSL communication และ Data encryption ใครจะทำเยอะกว่านี้ก็ต้องดูถึงความคุ้ม และ performance ด้วย

สามารถดู VDO ของงานทั้งหมดได้

สามารถดูข้อมูลเพิ่มเติมได้ที่

Tags:,,,