จากงาน 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 สุด ๆ ไหม 24x7 เช่น 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 ด้วย
สามารถดูข้อมูลเพิ่มเติมได้ที่
- Apache Kafka Performance
- Optimize Apache Kafka Deployment
- Benchmarking Apache Kafka: 2 Million Writes Per Second (On Three Cheap Machines)
- Monitoring Kafka performance metrics
- How to Choose the Number of Topics/Partitions in a Kafka Cluster ?
- Using Apache Kafka as a Scalable, Event-Driven Backbone for Service Architectures
- Replication tools