ทำไมแค่ใช้เครื่องมือเป็น ถึงยังไม่เรียกว่าเข้าใจมันจริงๆ
เวลาเราหัดเขียนโปรแกรม เรามักจะเริ่มจากใช้ Library (ชุดคำสั่งที่เขียนไว้สำเร็จรูป) หรือ Framework (โครงสร้างโปรแกรมสำเร็จรูป) เพื่อให้งานเสร็จเร็วขึ้น เหมือนเราขับรถเป็น แต่ไม่ได้แปลว่าเราซ่อมเครื่องยนต์เป็น ซึ่งในชีวิตประจำวันมันก็โอเคเพราะรถมันวิ่งได้ แต่ปัญหาจะเกิดเมื่อวันหนึ่งเครื่องยนต์พังกลางทางแล้วเราไปต่อไม่ถูก
Kafka (ระบบรับส่งข้อมูลขนาดใหญ่แบบเรียลไทม์) ก็เช่นกัน หลายคนใช้แค่คำสั่งพื้นฐานอย่างการส่งข้อมูลหรือรับข้อมูลผ่าน Topic (ช่องทางสำหรับแยกหมวดหมู่ข้อมูล) พอเจอเหตุการณ์แปลกๆ เช่น ข้อมูลค้างหรือระบบช้าผิดปกติ เรามักจะแก้ปัญหาไม่ได้เพราะเรามองเห็นแค่เปลือกนอก ไม่เห็นกลไกข้างใน
การลอง Rebuild (สร้างระบบขึ้นมาใหม่ด้วยตัวเอง) คือการถอดรหัสว่าเครื่องมือที่เก่งกาจเหล่านี้ทำงานอย่างไร มันช่วยให้เราเปลี่ยนจาก "ผู้ใช้" กลายเป็น "ผู้เข้าใจระบบ" อย่างแท้จริง ซึ่งเป็นทักษะที่แยกความต่างระหว่างโปรแกรมเมอร์ที่แก้บั๊กได้ กับโปรแกรมเมอร์ที่สร้างระบบที่เสถียรได้ครับ
ภาษีของความสะดวกสบาย (Abstraction Tax)
ทุกครั้งที่เราใช้เครื่องมือสำเร็จรูป เรากำลังจ่าย Abstraction Tax (ภาษีที่ต้องจ่ายจากการไม่รู้กลไกเบื้องหลัง) ยิ่งเครื่องมือช่วยเราเยอะ เรายิ่งต้องรับภาระหนี้ทางความคิดมากขึ้น เมื่อไหร่ที่ระบบมีปัญหา เราจะเดาไม่ถูกเลยว่าจุดที่เสียคือตรงไหน เพราะเรามองมันเป็นกล่องดำที่โยนข้อมูลเข้าไปแล้วได้ผลลัพธ์ออกมา
ความน่ากลัวของ Kafka คือมันดูเหมือนเข้าใจง่าย เช่น Partition (ส่วนย่อยของข้อมูลที่แบ่งไว้) ดูเหมือนเป็นถังเก็บข้อมูลธรรมดา แต่พอเราลองเขียนระบบจัดเก็บข้อมูลเอง เราจะพบว่ามันมีรายละเอียดเรื่องการจัดการไฟล์บนดิสก์ที่ซับซ้อนกว่าที่คิด การลองสร้างระบบจำลองขึ้นมาจะช่วยให้เราเห็นว่าทำไมต้องมีการตั้งค่าเหล่านั้น
ลองนึกภาพการสร้างระบบเก็บข้อมูลอย่างง่ายด้วยตัวเองดูครับ
# ตัวอย่างการเขียน Log แบบง่ายๆ ลงไฟล์
def append_to_log(filename, message):
with open(filename, "a") as f:
f.write(message + "\n") # เขียนข้อมูลต่อท้ายไฟล์เดิม
append_to_log("data.log", "Event 1")
append_to_log("data.log", "Event 2")
บรรทัดที่ 3 คือการเปิดไฟล์ในโหมด "a" หรือ append (การเขียนข้อมูลต่อท้าย) ซึ่งเป็นหัวใจสำคัญที่ Kafka ใช้เก็บข้อมูลลงในดิสก์จริงๆ ผลลัพธ์ที่ได้คือไฟล์ data.log ที่มีข้อความ Event 1 และ Event 2 เรียงกันอยู่ข้างในครับ
เมื่อ Offset ไม่ใช่แค่ตัวเลขแต่คือตำแหน่งในไฟล์
ใน Kafka เรามักได้ยินคำว่า Offset (ตำแหน่งของข้อมูลในลำดับ) ซึ่งมือใหม่มักมองว่ามันคือตัวเลขลำดับข้อมูลธรรมดา แต่ถ้าคุณลองเขียนระบบอ่านไฟล์เอง คุณจะรู้ว่ามันคือตำแหน่ง Byte (หน่วยความจำขนาดเล็กที่สุด) ที่แท้จริงในไฟล์นั้นๆ ทำให้เราเข้าใจว่าทำไมการจัดการตำแหน่งถึงสำคัญมาก
การลองเขียนโค้ดอ่านไฟล์จากตำแหน่งที่กำหนดจะช่วยให้เห็นภาพชัดเจนขึ้น
# การอ่านข้อมูลจากตำแหน่งที่ต้องการ
def read_at_offset(filename, position):
with open(filename, "r") as f:
f.seek(position) # เลื่อนหัวอ่านไปที่ตำแหน่งไบต์ที่ระบุ
return f.readline()
print(read_at_offset("data.log", 0))
คำสั่ง f.seek() คือการกระโดดไปยังตำแหน่งที่ต้องการในไฟล์โดยตรงโดยไม่ต้องไล่อ่านตั้งแต่ต้น ถ้าคุณเคยสงสัยว่าทำไม Kafka ถึงอ่านข้อมูลเร็วมาก คำตอบก็คือมันใช้เทคนิคการกระโดดไปที่ตำแหน่งไบต์แบบนี้แหละครับ ผลลัพธ์ที่ได้คือข้อความบรรทัดแรกที่เราเขียนลงไปก่อนหน้านี้
ความลับของการลบข้อมูลด้วยการจัดการไฟล์
หลายคนเข้าใจผิดว่า Kafka ลบข้อมูลทีละบรรทัดเหมือนฐานข้อมูลทั่วไป แต่ความจริงคือมันลบเป็น Segment (ไฟล์เก็บข้อมูลชุดใหญ่หนึ่งชุด) การที่คุณได้ลองเขียนระบบที่จัดการไฟล์เอง คุณจะเข้าใจว่าทำไม Kafka ถึงไม่ค่อยลบข้อมูลทีละนิด เพราะการลบไฟล์ทั้งไฟล์ทิ้งนั้นทำได้เร็วกว่าการแก้ไขไฟล์เดิมมาก
ความเข้าใจเรื่องการจัดการไฟล์นี้สำคัญมากสำหรับโปรแกรมเมอร์ที่ต้องดูแลระบบ เพราะถ้าคุณไม่เข้าใจว่ามันลบไฟล์ทั้งก้อน คุณอาจจะงงว่าทำไมพื้นที่ดิสก์ถึงไม่ลดลงทันทีที่คุณตั้งค่า Retention (นโยบายการเก็บข้อมูล) ให้สั้นลง การทดลองสร้างระบบจำลองจะทำให้คุณเห็นภาพว่าไฟล์ใหม่ถูกสร้างขึ้นเมื่อไฟล์เก่าเต็มอย่างไร
จุดที่มือใหม่มักพลาดคือการคิดว่าข้อมูลจะหายไปทันทีที่หมดอายุ จริงๆ แล้วระบบต้องรอให้ครบเงื่อนไขของไฟล์นั้นๆ ก่อนถึงจะเคลียร์พื้นที่ได้ครับ
ทำไมต้องมี Partition และห้ามเปลี่ยนบ่อยๆ
Partition คือวิธีที่ Kafka ใช้แบ่งงานเพื่อให้ระบบทำงานขนานกันได้ แต่ถ้าเราเปลี่ยนจำนวนมันในภายหลัง ข้อมูลที่เคยถูกจัดเรียงไว้จะรวนทันที เพราะ Hash (สูตรคำนวณตำแหน่งข้อมูล) ของเดิมจะใช้ไม่ได้อีกต่อไป การลองเขียนระบบแจกจ่ายงานเองจะทำให้คุณเข้าใจว่าทำไมจำนวนนี้ถึงเป็นเรื่องใหญ่
ลองคิดว่าคุณต้องแจกงานให้เพื่อน 3 คน ถ้าจู่ๆ เพิ่มเพื่อนเป็น 4 คน งานที่เคยแจกไปแล้วอาจจะสลับที่กันหมด การทำความเข้าใจเรื่องนี้ผ่านการเขียนโปรแกรมจะช่วยให้คุณออกแบบฐานข้อมูลได้ดีขึ้นตั้งแต่แรก
จงจำไว้ว่าการกำหนดจำนวนพาร์ทิชันคือการตัดสินใจครั้งสำคัญที่แก้คืนได้ยากในระบบจริงครับ
สรุป: เปลี่ยนจากผู้ใช้เป็นผู้สร้าง
การลองสร้างระบบจำลอง Kafka ไม่ได้แปลว่าคุณต้องเขียนโปรแกรมที่ซับซ้อนเท่าของจริง แต่เป็นการฝึกให้คุณคิดแบบวิศวกรที่มองเห็นกลไกเบื้องหลัง ความเข้าใจจะช่วยให้คุณแก้ปัญหาได้เร็วขึ้น เมื่อเกิดเหตุการณ์ไม่คาดฝันตอนตีสองแทนที่จะนั่งงมหาคำตอบจากเอกสารเพียงอย่างเดียว
ในอนาคต หากคุณต้องเลือกระหว่างการใช้เครื่องมือสำเร็จรูปกับการเข้าใจมัน ลองสละเวลาสักนิดมาดูว่าข้างในนั้นทำงานอย่างไร การลงทุนเวลาเพียงไม่กี่ชั่วโมงในการทำ Toy Project (โปรเจกต์ขนาดเล็กที่สร้างขึ้นเพื่อการเรียนรู้) จะเป็นทักษะติดตัวที่หาไม่ได้จากการอ่านคู่มือเพียงอย่างเดียว
ลองเริ่มจากสร้างระบบคิวข้อมูลอย่างง่ายโดยใช้ไฟล์ธรรมดาดูครับ แล้วคุณจะพบว่าหัวใจของระบบระดับโลกอย่าง Kafka นั้นไม่ได้มีอะไรลึกลับเกินกว่าความเข้าใจของโปรแกรมเมอร์อย่างคุณเลยครับ
ที่มา: Kafka internals via rebuild: what using a tool vs. understanding it teaches you — DEV Community
