Demystify Event-driven Processing with Apache Kafka
สวัสดีค้าบบบบ.. จบไปแล้วกับงาน ‘OPEN SOURCE IN ENTERPRISE’ ที่จัดขึ้นที่ SCB Academy นะครับ สำหรับหัวข้อของผมที่ได้พูดไปคือเรื่อง ‘DEMYSTIFY EVENT-DRIVEN PROCESSING WITH KAFKA’ ใน Blog นี้ผมจะมาขอ Recap ให้ทุกท่านอีกครั้งเผื่อผมพูดตกหล่นอะไรไปหรือใครฟังแล้วไม่เข้าใจจะได้มาอ่านย้อนกันได้อีกครั้งนึงนะครับ
เริ่มต้นรู้จักกับ Kafka
‘Kafka’ ผมได้ยินคำนี้มาซักระยะหนึ่งแล้ว ฟังแล้วเป็นคำที่ติดหูคำนึงเลยสำหรับผมทำไมไม่รู้เหมือนกัน เริ่มแรกเดิมทีเลยผมคิดมาตลอดว่า Kafka ก็คงเป็น Message Queue อีกเจ้านึงเท่านั้นแหละ คงไม่ต่างไปจาก ActiveMQ, RabbitMQ มากนักหรอกกก.. จนมีอยู่ช่วงนึงที่ผมมีปัญหากับการเขียน Logs ที่เยอะมากขึ้นเรื่อยๆจนทำให้ Logs ขาดบ้างหายบ้าง จนผมต้องหาอะไรมาช่วยซักอย่างแล้ว ผมเริ่ม Challenge ตัวเองให้รู้จัก Kafka มากขึ้นโดยเริ่มเอามาช่วยเป็น Buffer ก่อนส่ง Logs เข้า ELK (Elasticsearch,Logstash, Kibana) หรือ Stack มาตารฐานที่คนส่วนใหญ่ใช้ Centralize Logs กัน ผมและทีมช่วยกันจนสำเร็จสามารถส่ง Applications Logs เข้า ELK ด้วย Kafka ได้อย่างสมบูรณ์แบบ ไม่ขาดไม่หาย สวยงามตามท้องเรื่องจากที่ไม่รู้อะไรเกี่ยวกับ Kafka เลย จนได้เริ่มใช้งานจริงจังอยู่กันมันทุกวันๆ ค่อยๆซึมซับ Concept ต่างๆของ Kafka ความคิดต่างๆเริ่มเข้าที่ เริ่มรู้ตัวเองแล้วว่าสิ่งที่ตัวเองเคยคิดมาตลอดนั้น มันไม่ใช่หนิหน่า Kafka ไม่ใช่ Message Queue ซักหน่อย มาถึงเวลาแล้วที่ผมจะค่อยๆเล่าให้ฟังว่าเจ้า Kafka นั้นมันคืออะยัย ..
เมื่อ Data Stream เริ่มเข้ามามีบทบาทสำคัญ
ในทุกวันนี้เทคโนโลยีเข้ามามีบทบาทสำคัญ ธุรกิจแทบทุกจะ Industry ถูกเทคโนโลยีเข้ามา Disrupt ธุรกิจรูปแบบเดิมๆ Data ถือเป็นน้ำหล่อเลี้ยงสำคัญสำหรับการทำธุรกิจในยุคปัจจุบัน ใครที่มีข้อมูลมากย่อมได้เปรียบธุรกิจอื่นๆเลยก็ว่าได้ ความรวดเร็วของ Internet ในยุคปัจจุบัน 5G ที่กำลังจะเข้ามาถึงเรา รวมไปถึง Iot ที่ทำให้สิ่งของต่างๆรอบตัวเราสื่อสารหากันได้ สิ่งต่างๆเหล่านี้ล้วนอยู่บนพื้นฐานของการส่งข้อมูลหากันตลอดเวลา ผู้ที่สามารถจัดการข้อมูลเหล่านั้นได้รวดเร็วและมีประสิทธิภาพย่อมมีชัยไปกว่าครึ่งในการนำข้อมูลเหล่านั้นไปต่อยอดทางธุรกิจในอนาคต ผมเกริ่มมาซะยาวเพียงเพื่อจะบอกว่าเราควรจะต้องมี Solution ในการจัดการข้อมูลเหล่านี้ที่ดีได้ ที่ไม่ใช่การ Query มา Analyst มาเป็นครั้งๆได้แล้วเราต้องเริ่มจัดการกับ Data Stream ได้อย่างมาประสิทธิภาพและนั้น Kafka ก็เป็นเทคโนโลยีนึงที่จะเข้ามาช่วยเติมเต็มสิ่งเหล่านี้ได้
หลายคนคนเริ่มสงสัยแล้วสิครับว่า เอ้.. อย่างงี้ Kafka มันเป็นแค่ Tool นึงที่นำมาใช้ในงาน Data Analytics นำเข้า Data เข้า Data Warehouse / Data Lake แค่นั้นละม้างง ช้าก่อนครับ.. หากเราลองนึกดูดีๆเจ้า Kafka นี่ยังสามารถตกแต่ง Architecture ของ Software ที่เราพัฒนาให้สวยงามยิ่งขึ้นอีกด้วยครับ
ยกตัวอย่างง่ายๆอย่าเช่น Chatbot ที่ผมกับทีมพัฒนากันขึ้นมานั้นมันมีข้อมูลมากมายที่วิ่งไหลผ่าน ไม่ใช้เพียงแค่ข้อความที่ผู้ใช้งานต้องการจะส่งหาเราเท่านั้น แต่มันยังมีสิ่งอื่นๆตามมาด้วยเช่น มีคน Follow Chatbot เราเพิ่มนะ / มีคน Block Chatbot เรานะ, มีคนเข้ามาอยู่รอบๆรัศมีของ Beacon เรานะ / มีคนออกจากรัศมีของ Beacon เรานะ, หรืออื่นๆอีกมากมายตามแต่ละ Platform ที่เค้าจะใจดีส่งให้เรา ข้อมูลเหล่านี้ยิ่งเราเก็บมาประมวลผลได้เร็วเท่าไรก็ทำให้เรารู้ในทุกๆความเคลื่อนไหวที่เกิดขึ้นกับระบบของเรา รู้จักผู้ใช้งานของเรามากขึ้น กลับมามองที่ระบบของเราการออกแบบของแต่ละ Microservices จะมีเรื่องที่ Microservice หนึ่งๆดูแลอยู่ มี Domain ของแต่ตัวมันเอง และเจ้า Kafka นี่เองที่จะเข้ามาช่วย decoupling ความซับซ้อนของแต่ละ Microservices ..
หลายคนอาจสงสัยว่า .. อ่าวแล้วทำไมไม่ใช้ REST ส่งข้อมูลหากันระหว่าง Microservics หล่ะ สำหรับผมแล้ว REST มันมีลักษณะงานของมันเองครับ REST มันเหมาะกับการเป็น Standards ให้กับ External Services ภายนอกเพื่อติดต่อกัน มีความ Synchronous กัน และอีกอย่างมันทำให้ต้องรู้จัก Services ที่จะคุยกันด้วยเยอะแยะไปหมดเลย เวลาแก้ไขอะไรก็อาจเกิด Domino Effect ตามมาได้ มันจะดีกว่าไหมถ้ามีคนกลาง (Broker) ที่เข้ามาคอยช่วยจัดการปัญหาเหล่านี้
รูปแบบการสื่อสารกันระหว่าง Microservices ผมจะแบ่งเป็นสามประเภทให้รู้จักกันนะครับ
- Request / Reply เป็นรูปแบบการสื่อสารระหว่างกันของ คนส่ง (Publisher) และคนรับ (Subscriber) โดยที่ส่งข้อมูลหากันเอง Publisher ต้องรู้จัก Subscriber เป็นการส่วนตัว จะเพิ่ม Subscriber ใหม่ก็ต้องไปแก้ไขโปรแกรมหรือ Config เพื่อให้รู้จักกันที
- Publish / Subscribe (นิ๊กเนม PubSub) รูปแบบนี้จะเห็นว่ามีคนกลางเข้ามาช่วยละ ถ้ามีหลายคนต้องการข้อมูลก็มารับไปจาก Broker ซ่ะ แต่จะเห็นว่า ถ้ามาทีหลังอดนะจ๊ะ
- Streaming อันนี้เหมือน PubSub เลยครับ แต่ตัว Streaming Broker จะมีความสามารถเพิ่มขึ้นมาในการเก็บของที่ Publisher ส่งมาด้วยครับ ตามระยะเวลา (Retention) ที่กำหนดไว้ ซึ่งจะเห็นว่า ถ้า Subscriber ตามมาทีหลังก็สามารถขอข้อมูลที่มาไม่ทันได้ด้วย จะเห็นว่าอันนี้เหมือน Youtube เลยม่ะ อยากดูตอนไหนก็ได้ดู ดีจริมๆ ซึ่งสำหรับ Apache Kafka เองนั้นจัดอยู่ในรูปแบบ Streaming นี่แหละครับ :)
มาถึงจุดนี้เริ่มคงยังสงสัยอยู่ว่าเจ้า Kafka มันไม่ใช่ Message Queue ยังไง ต้องตอบไว้ก่อนเลยครับว่า Kafka เป็น Distributed Streaming Platform ซึ่งข้อมูลจะถูกกระจายออกไปตาม Broker ตาม Topic ตาม Partition ที่มันอยู่ แต่ละอันถูกแยกจากกันอย่างสิ้นเชิ้งเพื่อให้ง่ายต่อการ Scale และทำงานได้เร็วที่สุด
จริงอยู่ที่เราพอจะใช้ Kafka เข้ามากล่อมแกล่ม ถูๆไถ่แทน Message Queue อยู่ได้บ้าง แต่ถ้าคุณแคร์ในเรื่องของ Message Order มากๆ ผมว่า Kafka อาจจะไม่เหมาะกันงานในลักษณะนี้ Kafka สามารถ Order ได้ตราบเท่าที่มันอยู่ใน Partitions เดียวกันเท่านั้นแหละครับ ผมน่าจะใส่ภาษามนุษต่างดาว (Tech Jargon) ไปจำนวนมากสำหรับผู้ที่เริ่มเข้ามาศึกษา Kafka งั้นผมจะพาไปรู้จัก Kafka ให้มากขึ้นหน่อยดีกว่าครับ ..
รู้จักภาษาถิ่นของเจ้า Kafka กันไว้หน่อย
สำหรับ Kafka แล้วจะมี Tech Jargon อยู่จำนวนนึงเลยฮ่ะ ผมจะพาไปรู้จักกันหน่อยก่อนที่จะลงลึกไปเรื่อยๆ ตามนี้ครับ
Broker
อย่างที่บอกครับ Kafka ก็คือคนกลางที่จะเข้ามาช่วยให้การสื่อสารของผู้ส่งและผู้รับมีความสะดวกมากขึ้น แต่การทำงานของ Kafka นั้นจะทำงานเป็น Cluster ครับ ดังนั้นมันจะมี Broker อยู่หลายตัวด้วยกัน และจะมี Zookeeper ที่คอยจัดการว่าตัวไหนตายตัวไหนอยู่รอด
Topic
เราสามารถที่จะแยกประเภทของข้อมูลที่จะส่งไหลผ่าน Broker เป็น Topic ได้ครับ เช่นคุณครูสอนวิชาคณิตศาสตร์คนที่สนใจในเรื่องของคณิตศาสตร์ก็สามารถที่จะมาเลือกรับข้อมูลจาก Topic นี้ได้
Partition
เป็นการแบ่งชั้นย่อยภายใน Topic ครับ โดยที่การแบ่ง Partition นั้นจะเป็นช่วยในเรื่องของการ Parallel data stream เหล่านั้นให้ผู้ที่จะรับข้อมูลนำไปใช้งาน
Producer
ตามตัวเลยครับ คือผู้ที่จะส่งข้อมูลครับ Producer สามารถมีได้หลายตัวนะครับ จะส่งเข้า Topic เดียวกันก็ได้ Topic ต่างกันก็ได้
Consumer
และนี่ก็คือผู้ที่จะรับข้อมูลครับ Consumer สามารถมีได้หลายตัวเฉกเช่นเดียวกันครับ แต่แต่แต่ Consumer ที่ดีจะต้องมีเท่าจำนวน Partitions นะครับ ถ้ามีมากไปจะมี Consumer ที่ไม่ได้ทำงาน ถ้ามีน้อยไปก็จะต้องมีคนทำงานแทนกันครับ
Consumer Group
เป็น Concept การจับกลุ่มของ Consumer เข้าด้วยกันเพื่อป้องกันการรับข้อมูลที่ซ้ำซ้อนกัน เช่นถ้าเรามี Consumer อยู่ 2ตัวใน Group เดียวกัน สองตัวนี้จะมีการแบ่งกันไปรับข้อมูลตาม Partitions ซึ่งมันจะไม่ไปแย่งกันรับข้อมูลอันเป็นสาเหตุของการรับข้อมูลซ้ำซ้อนกันครับ
ทั้งหกตัวนี้เป็น Jargon สำคัญๆที่ทำให้เริ่มไปคุยเรื่อง Kafka กับคนอื่นๆรู้เรื่องแล้วหล่ะครับ ซึ่งจริงๆแล้วจะมีเยอะมากกว่านี้เลยครับ แต่ผมคงพูดถึงไม่ได้หมดถ้าใครอยากรู้มากกว่านี้แนะนำให้ลองไปศึกษาเพิ่มเติมนะครับ มี Blog มากมายที่อธิบาย Concept ของ Kafka ไว้อยู่ครับ
รู้จักครอบครับของ Kafka
ต่อจากนี้ผมจะพาไปรู้จักกับครอบครัวของ Kafka กันครับ สำหรับผู้ที่พัฒนาครอบครัวของ Kafka ขึ้นมาก็ไม่ใช่คนอื่นคนไกลที่ไหนครับ เค้าคือผู้ที่สร้าง Kafka ขึ้นมานี่แหละครับ และครอบครัวนี้มีชื่อว่า Confluent Platform ฮ่ะ
Confluent Platform มีหลายชิ้นหลายส่วนด้วยกันครับ มีทั้งแบบฟรีและไม่ฟรี สำหรับตัวที่ Opensource ออกมาเลยจะมีพวก Connector ต่างๆไม่ว่าจะเป็นแบบ REST APIs หรือว่าเป็น JDBC / MQ / File Connector ก็ตามจะเข้าจะออกจาก Kafka มีให้เลือกใช้งานหลายรูปแบบ
แต่ตัวที่ผมสนใจและขอหยิบมาพูดถึงนิดนึงเลยคือ Kafka Stream เลยครับ สำหรับการ Processing Data ที่ไหลเข้ามาในระบบเรื่อยๆถ้ามีตัวที่มาจัดการที่ดีย่อมทำให้เราสามารถทำงานได้ง่ายขึ้น ตัว Kafka Stream ก็ได้เข้ามาช่วยตรงนี้แต่ทั้งนี้ทั้งนั้น Kafka Stream นั้นเป็นเพียง Libary ที่ช่วยสำหรับ Java/Scala Dev เท่านั้นครับ แต่อย่างไรก็ดียังมี Opensource อีกตัวที่เข้ามาช่วยสำหรับ Dev ภาษาอื่น หรือแม้แต่ Data Engineer หรือ DevOps ก็ยังใช้งานได้ ยังไงไปดูกัน
ตัว KSQL นั้น ใช้งานได้ง่ายประหนึ่งเราเขียน SQL Query ของจาก Database เลยหล่ะครับ แต่มันมีความทรงพลังมากไปกว่านั้นคือมันสามาถทำได้กับ Stream ของ Data กันแบบ Realtime เลยทีเดียว พูดอย่างงี้ไม่เห็นภาพขอยกตัวอย่างเลยละกันนะครับ เช่น ผมมีการ Write Logs ของ Application เข้า Topic อันนึงโดยมีทั้งระดับ INFO และ ERROR แต่วันนึง DevOps อยากที่จะแสดงจำนวน Exception ที่เกิดขึ้นในระบบมาแสดงบน Dashboard ซักหน่อย DevOps ก็สามารถที่จะเขียน KSQL ขึ้นมาเพื่อ Query หาประเภทของข้อมูล Exception ที่เกิดขึ้นนับเป็นจำนวนมาแสดงได้โดยไม่ต้องเขียนโปรแกรมใดใดเลยแม้แต่นิดเดียว อย่างงี้ต้องปรบมือสิฮ่ะ :)
ด้วยความทรงพลังของ KSQL ทำให้เราสามารถที่จะ Filter / Transform หรือ Aggregation Stream ของ Data ได้อย่างง่ายดายประหนึ่งเล่นกับ Data บน Database
และหากพูดไปถึงพี่น้องครอบครัวของ Kafka อีกคนนึงเลยคงหนีคนนี้ไปไม่ได้ เค้ามีชื่อว่า Schema Registry ครับ พี่น้องคนนี้ของ Kafka เข้ามาช่วย คุมรูปแบบของ Data ที่ไหลผ่าน Kafka รวมไปถึงทำ Versioning ของ Schema อีกด้วย ซึ่งจริงๆแล้วเราสามารถที่จะเอา Data ประเภทไหนก็ได้ส่งผ่าน Kafka แหละครับ ไม่ว่าจะเป็น JSON, CSV หรือ Text ธรรมดาก็ได้ แต่มันไม่ Cool ใช่ไหมหล่ะครับ ที่เค้านิยมกันเลยก็จะมี Protocal Buffer ของ Google และ Apache Avro แต่ไม่ต้องเลือกกันนะครับ ถ้าคุณจะใช้ Schema Registry ของ Conflunet Plaform แล้ว คุณต้องใช้ Avro แบบไม่มีทางเลือกครับ
การทำงานของ Schema Registry นั้นไม่ได้ยากเย็นซักเท่าไรครับ อันดับแรกคือทั้งสองฝ่ายทั้งผู้ส่งและผู้รับต้องตกลงเรื่อง Schema ของ Data ที่จะส่งกันโดยสามารถ Define กันขึ้นมาจาก Standard ของ Avro ครับ หลังจากนั้นทั้งสองฝ่ายก็ต้องไป สร้าง Model Class ของกันจะภาษาไหนก็ได้ขอให้สามารถที่จะ Serialize / Deserialize เป็น Avro ให้ได้ครับ ซึ่งมี Library มากมายที่ช่วยเรื่องนี้อยู่ครับ
จากนั้นการส่งข้อมูลจาก Producer จะเริ่มส่ง Schema ไปเก็บไว้ใน Schema Registry ก่อนครับ พอ Consumer ได้รับข้อมูลก็จะไปถามหา Version ของ Schema นั้นๆจาก Schema Registry ซึ่งถ้าสามารถถอดได้หรือพูดจากันรู้เรื่องก็เป็นอันเสร็จพิธี
ข้อมูลในรูปแบบของ Apache Avro นั้นถ้ามองด้วยตาเปล่าแล้วมันไม่เห็น JSON ซักทีเดียวนะครับ มันจะพออ่านด้วยตาเปล่าได้บ้าง แต่มันจะติดๆกันไปหมด ข้อดีของมันที่ผมพอเลยคือมัน Lightweight มากๆครับ ทำให้เวลาส่งข้อมูลผ่าน Kafka นั้นมีจำนวน Bytes Per Message ที่ค่อนข้างน้อยมากเมื่อเทียบกับ JSON
ตรวจสุขภาพของ Kafka กันหน่อย
ทีนี้ผมจะมาเล่าถึงอาวุธที่ใช้สำหรับตรวจสุขภาพของ Kafka กันหน่อย ซึ่งถ้าเราจะพูดถึง Open Source ดีๆที่เค้าใช้เป็น Stack ในการ Monitor กันก็คงหนีไม่พ้น Prometheus แล้วนำไปแสดงผ่าน Gafana ชื่อพวกนี้คนติดหูกันอยู่ทุกคนอยู่แล้วใช่ไหมหล่าครับ จะบอกว่า Kafka ก็สามารถนำ Stats ต่างๆที่จำเป็นไปใช้ได้ด้วยเช่นกัน โดยผมจะขอแบ่งเป็น 3 Layer ดังนี้ครับ
- Node Level : Metrics ในระดับนี้เป็น Metrics ในระดับเครื่องระดับ VM เลยครับ เราสามารถที่จะใช้พวก node-exporter หรือ cadvisor ทั่วๆไปมาติดตั้งเป็น Agent ในเครื่องเพื่อส่ง Metrics ออกให้กับ Prometheus ได้อย่างสบายๆ
- Middleware Level : Metrics ระดับนี้เริ่มเข้ามาอยู่ในส่วนของ Kafka มากขึ้นละครับ โดยที่เราสามารถที่จะนำ Logs ของ Kafka ส่งไปยัง ELK ของเราผ่าน Filebeat เพื่อที่จะเห็น Logs ที่เกิดขึ้นบน Broker ต่างๆใน Kafka Cluster ของเราได้
- Application Level : Metrics ในระดับนี้เริ่มมีความสำคัญกับการทำงานของ Application เรามากขึ้นละครับ มี Open Source หลายหลายเจ้าที่สร้างกันขึ้นมาอำนวยความสะดวกให้เราช่วยเก็บ Metrics ตรงนี้เช่น Burrow, Kafdrop ซึ่งสามารถแสดงค่าที่จำเป็นๆให้กับเราได้ แต่ถ้าคุณต้องการ Metrics แบบ Hardcode มากขึ้นผมแนะนำเจ้า JMX-Exporter ครับ โดยใน Kafka จะมีสิ่งที่เรียกว่า JMX (Java Management eXtensions) ครับ เจ้าสิ่งๆนี้มันจะคอยส่ง Stats ออกมาให้เรามากมายกายกองและอันที่ผมใช้เป็นประจำและคิดว่าจำเป็นให้อยู่เป็นสุขในชีวิตประจำวันของพวกเรามีตามนี้เลยครับ ..
ใช้ Kafka แล้วปลอดภัยไหม
สำหรับ Kafka แล้วผมว่ามันเป็น Tools นึงที่ใช้ภายในอยู่ในส่วนนึงของ Architecture เราเท่านั้น คงไม่มีใคร Expose ให้คนภายนอกมา Subscribe Kafka กันผ่าน Internet ใช่ไหมหล่าครับ ซึ่งถ้าใช้กันภายในแค่มี Firewall คุมผมก็ว่าเพียงพอในระดับนึงแล้ว แต่นั้นไม่ใช่ที่ธนาคารครับ ฮ่าๆ
ความปลอดภัยของข้อมูลถือเป็นสิ่งสำคัญในอันดับต้นๆของ Application ที่ใช้ในระบบของธนาคาร หลักๆเลยคือเราต้องมี Secure Transportation ของข้อมูล (Encryption) และต้องมี Access Control สำหรับผู้ที่ต้องการรับส่งข้อมูลกัน (Authentication) ซึ่งเจ้า Kafka นั้นก็มีสิ่งเหล่านี้เตรียมไว้ให้ทุกท่านเรียบร้อยแล้ว
เรื่องแรกที่ผมจะขอพูดถึงเลยคือเรื่อง SSL Encrytion บน Kafka ครับ หากมองย้อนกลับไปเรื่อง HTTP/HTTPS ที่ทุกวันนี้เราใช้กันอยู่ การใช้ HTTP ก็เหมือนกับการส่งข้อมูลเปลือยๆผ่าน Hop ต่างๆ การใช้ HTTPS ก็จะมีการ Encrption ก่อนด้วย Public Key แล้วค่อยส่งผ่าน Hop ต่างๆจนไปถึงผู้รับก็จะค่อยถอดออกด้วย Private Key ใช่ไหมครับ ผมจะบอกว่า SSL Encryption บน Kafka ไม่ต่างกันเลยครับ
การทำงานของ SSL Encryption บน Kafka คือก่อนปฎิสัมพันธ์กับ Kafka นั้นไม่ว่าจะเป็น Producer/Consumer นั้นจะทำการขอ Certificate (Public Key) จาก Kafka ก่อนจากนั้นจะมาตรวนสอบกับ Truststore ที่ Config ไว้ภายใน Application ของเรา ซึ่งถ้าตรงกันทุกอย่างก็จะใช้ Key นั้นในการ Encrypt ก่อนรับส่งภายใน Kafka ครับ
ปล.แต่การทำ SSL Encryption บน Kafka ตามการทดลองที่เค้าบ่นๆกันใน Internet ทั้งจะทำให้ Latency ลดลงประมาณ 20–30% เทียบกับแบบเปลือยๆนะครับ ดังนั้นอย่าลืมที่จะทำ Performance Test กันด้วยนะครับ
เรื่องต่อไปที่ผมจะพูดถึงคือ Access Control บน Kafka ครับ ซึ่งก็คือการความคุมให้คนที่มีสิทธิที่จะเข้าถึงข้อมูล เข้าถึงได้เท่านั้น
ซึ่งมีหลายหลายวิธีด้วยกันนะครับ แต่ผมจะยกตัวอย่างเรื่อง Mutual SSL Authentication ละกันครับ ซึ่งเป็น Concept ที่สามารถเข้าใจได้ง่ายดี สำหรับการทำ Access Control ในรูปแบบนี้ไม่ต่างไปจากการทำ SSL Encryption เลยครับ เพียงแต่เราทำทั้งสองด้านเลยครับ ถ้าเราทำเรื่อง SSL Encryption อยู่แล้วเราเพียงแต่เพิ่มให้ฝั่ง Producer/Consumer มี Keystore อีกชุดนึงครับ แล้วเวลาจะคุยกับ Kafka กันก็แลก Certificate กันครับ ซึ่งถ้า Verify ผ่านหมดทั้งสองขาเราก็สามารถที่จะสื่อสารหากันบน Kafka ได้อย่างราบรื่นไปเลยฮ่ะ จริงๆแล้วการทำ Authentication บน Kafka มีวิธีอื่นๆอีก เช่น SASL Authentication ใครสนใจอาจไปศึกษาหาข้อมูลเพิ่มเติมกันนะครับ
สนุกไหมครับ ที่ผมเล่ามาทั้งหมดนี้เป็นเพียงแค่ Overview ของเจ้า Kafka นะครับ ทั้งหมดมีรายละเอียดปลีกย่อยอีกเยอะแยะไปหมดเลย แต่มาถึงจุดนี้ผมคิดว่าทุกคนคงเริ่มเต็มอิ่มกับ Kafka พอสมควรแล้ว ผมจะขอพักไว้เพียงเท่านี้ก่อนละกันครับ แล้วเจอกันใหม่ตอนหน้าครัชช
