สวัสดีครับ Blog นี้จะพามารู้จักกับ Kafbat ซึ่งเป็น Tools เพื่อเอามาใช้ในการจัดการ Kafka cluster กันครับ

Kafbat คือ Tool ที่เป็น Opensource ตัวนึงที่สามารถนำมาใช้ Monitor และ จัดการ Kafka Cluster หลายๆ cluster ในตัวเดียวได้ ซึ่งถ้าคุ้นเคยกับ Conduktor Tools ตัวนี้ก็มีความสามารถเบื้องต้นใกล้เคียงกันครับผม

วิธี Setup Kafbat เพื่อ run โดยใช้ Jar ไฟล์

สิ่งที่จำเป็นต้องมีเพื่อ run Kafbat ขึ้นมาที่เครื่องเรา

Kafbat

สำหรับ Kafbat ที่เป็น Jar ไฟล์ สามารถ download ได้จาก https://github.com/kafbat/kafka-ui/releases ซึ่งปัจจุบันวันที่เขียน blog นี้ จะเป็น version 1.4.2

JDK

เนื่องจากเรา download Jar มาเลยจำเป็นต้องมี JDK หรือ JRE เพื่อให้สามารถ run java ที่เครื่องได้ โดย Kafbat version 1.4.2 นั้น Minimum Java version คือ 21 สามารถ Download ได้จาก https://www.oracle.com/java/technologies/downloads/#jdk21-windows

Application properties

ตัว application properties เป็น configuration ไฟล์ ซึ่งสามารถดูตัวอย่างได้จาก https://github.com/kafbat/kafka-ui/blob/main/api/src/main/resources/application-local.yml

แต่สำหรับการทดลองใช้งานครั้งแรก แนะนำให้ลอง setup แบบง่าย ๆ เพื่อลองเชื่อมต่อกับ Kafka ที่ run อยู่ที่ localhost:9092 ดูก่อน โดย properties จะเหลือประมาณนี้

logging:
  level:
    root: INFO
    io.kafbat.ui: DEBUG
    #org.springframework.http.codec.json.Jackson2JsonEncoder: DEBUG
    #org.springframework.http.codec.json.Jackson2JsonDecoder: DEBUG
    reactor.netty.http.server.AccessLog: INFO
    org.springframework.security: DEBUG


kafka:
  clusters:
    - name: local
      bootstrapServers: localhost:9092

เมื่อเรา Download ทุกไฟล์เรียบร้อยแล้ว ให้เอามารวมกันไว้ที่ folder เดียวกันจะได้ประมาณนี้

ทดสอบการ run Kafbat ด้วยการเปิด terminal ไปที่ folder ที่เราเก็บไฟล์ไว้แล้ว ต่อด้วย command

<java_file> -Dspring.config.additional-location=<properties_file> --add-opens java.rmi/javax.rmi.ssl=ALL-UNNAMED -jar <kafbat_jar>

• <java_file> → แทนที่ด้วย java execution file เช่น ./jdk-21.0.9/bin/java.exe และสำหรับ Mac OS Path ก็จะประมาณนี้ ./jdk-21.0.9.jdk/Contents/Home/bin/java
• <properties_file> → แทนที่ด้วย properties file เช่น ./application.yaml
• <kafbat_jar> → แทนที่ด้วย kafbat jar file เช่น ./api-v1.4.2.jar

หลังจาก run command เรียบร้อยแล้วก็ให้เปิด web browser แล้วเข้าไปที่ localhost:8080 เพื่อไปยังหน้า UI ของ Kafbat

Apache Kafka is a distributed event streaming platform

Kafka คือ แพลตฟอร์มที่ถูกออกแบบมาเพื่อใช้ในงานในระบบที่ต้องจัดการกับข้อมูลที่ไหลเข้ามาแบบต่อเนื่อง (Event streaming) โดย Kafka จะทำหน้าที่เป็นตัวกลางที่คอยรับและเก็บข้อมูลเหล่านั้นชั่วคราว ก่อนที่ระบบปลายทางหลายๆ ระบบจะมาดึงข้อมูลจาก Kafka ไปใช้งานต่อ เช่น การรับข้อมูล log จากพฤติกรรมผู้ใช้งานบนเว็บไซต์มาเก็บไว้ที่ Kafka ก่อนแล้วระบบต่าง ๆ ที่เกี่ยวข้อง เช่น ระบบวิเคราะห์ข้อมูล ระบบแจ้งเตือน และระบบ Dashboard สามารถดึงข้อมูลเดียวกันนี้ไปใช้งานต่อได้พร้อมกันแบบ real-time โดยไม่รบกวนกัน

ในบทความนี้ เราจะมาทำความรู้จักกับองค์ประกอบหลักของ Kafka และทำความเข้าใจว่าทำไมมันถึงเป็นหัวใจสำคัญของ Event-Driven Architecture โดยส่วนประกอบหลักของ Kafka เพื่อความเข้าใจง่ายแล้วผมขอแบ่งออกเป็น 5 ส่วนหลัก ๆ อันได้แก่ Topic, Producer, Consumer, Broker และ Manager

เรามาทำความรู้จักกับแต่ละส่วนกันเลย

1. Topic

Topic ใน Kafka คือส่วนที่ไว้ใช้สำหรับเก็บข้อมูล โดยถ้าเปรียบเทียบกับ Relational Database ก็จะเปรียบเหมือนกับ Table แต่…

ข้อแตกต่างระหว่าง Kafka Topic และ Table

ไม่มี Query แบบ Traditional Database

• Kafka ตัวเองไม่มี query engine
• ไม่สามารถ random access หรือ index-based lookup
• แต่สามารถใช้ ksqlDB หรือ Kafka Streams เพื่อ query real-time ได้

Immutable (แก้ไขไม่ได้)

• เขียนลงไปแล้วไม่สามารถ Update หรือ Delete ได้
• เหมือนการบันทึกประวัติ เมื่อเกิดขึ้นแล้วข้อมูลที่เขียนลงไปใน Topic แล้วจะไม่สามารถแก้ไขได้

การลบใช้ Retention Policy

• ไม่ได้ลบทีละ Record แต่จะเป็นลบตามเวลาหรือขนาดที่ตั้งไว้ (Retention)
• ตั้ง Retention เช่น “เก็บ 7 วัน” หรือ “เก็บ 100GB”
• Kafka ลบข้อมูลเก่าอัตโนมัติตาม policy

ส่วนประกอบของ Topic

1.1 Partition

ภายใน Topic จะมี Partition ไว้สำหรับช่วยกระจายการทำงาน ทำให้ในหนึ่ง Topic สามารถรองรับ Service ที่เข้ามาเขียนและอ่านข้อมูลแบบคู่ขนานกัน โดยการกำหนดจำนวน Partition ให้เหมาะสมกับจำนวน Event ที่เข้ามาใน Topic จะช่วยเพิ่มความสามารถในการเขียนและอ่านข้อมูลจาก Topic ได้รวดเร็วมากยิ่งขึ้น

1.2 Offset

จะเป็นตัวแสดงถึงตำแหน่งปัจจุบันในแต่ละ Partition ว่าแต่ละ Consumer อ่านไปล่าสุดถึงตรงไหนแล้ว เพื่อป้องกันตอนที่ Consumer นั้น ๆ เกิดพังไป แล้วมี Consumer ใหม่มาแทนที่ ก็จะได้อ่านข้อมูลในลำดับถัดไปต่อได้เลย

1.3 Replication factor

เป็น Configuration ที่เอาไว้ เพื่อการเพิ่มความมั่นใจในการเก็บข้อมูลของแต่ละ Partition ว่าจะมีการทำสำเนาเก็บไว้กี่ชุด โดยถ้า set ไว้เท่ากับ 1 หมายความว่าจะมีข้อมูลของ Partition แค่ 1 ชุดเท่านั้น (ไม่มีสำเนา)

1.4 Retention

ตัวเลขที่ระบุถึงอายุที่จะเก็บข้อมูลไว้ใน Kafka มีไว้เพื่อช่วยในการจัดการการใช้พื้นที่บน Disk ของ Kafka เพื่อที่จะได้ลบข้อมูลที่ไม่มีคนใช้งานแล้วออกไป โดยเราสามารถตั้งเงื่อนไข ได้ 2 แบบคือ ตามอายุ (millisecond) กับ ตามขนาด (byte)

1.5 In-sync replicas

คือ List รายชื่อของ Kafka Server (Broker) ทั้งหมดที่กำลังทำหน้าที่เก็บสำเนาข้อมูลใน Partition นี้อยู่

• การ config min.insync.replicas เป็นอีกหนึ่งใน Configuration ที่ไม่ควรมองข้าม เพราะเป็นตัวกำหนดถึงจำนวน Kafka Server (Broker) ขึ้นต่ำที่ต้องทำสำเนาข้อมูลของแต่ละ Partition ไว้เพื่อช่วยป้องกันเวลาที่มี Server พังเราจะได้มีข้อมูลสำรองไว้ใช้งาน

2. Producer

Producer คือ Application หรือ Service ที่ส่งข้อมูลไปยัง Kafka Topic โดยในการที่จะสร้างข้อมูลเข้าไปยัง Topic ได้นั้น จะต้องมีการ Setup เบื้องต้นดังนี้

2.1 Producer Configuration

2.1.1) Bootstrap server เป็น Configuration ที่ระบุถึง Kafka Server (Broker) ซึ่ง จะใช้ตอนที่ Service ของ Producer กำลังเริ่มต้นเชื่อมต่อไปหา Kafka Server เพื่อดึงข้อมูลรายละเอียดของ Kafka Cluster (Metadata) เพื่อใช้ต่อในตอนที่จะส่ง Event ไปเก็บใน Kafka

2.1.2) Acknowledgement เป็น Configuration ที่บอกว่า Kafka Server (Broker) จะตอบกลับเมื่อไหร่ โดยมีทั้งหมด 3 แบบ คือ All, Wait leader และ No wait

• All (acks=all หรือ -1) : รอจนกว่า Brokers ทั้งหมดจะเขียนข้อมูลเสร็จค่อยตอบกลับ โดย default จะเป็นค่านี้
• Wait leader (acks=1) : รอเฉพาะ Broker ที่ทำหน้าที่เป็น partition leader ของ partition นั้น ๆ เขียนข้อมูลเสร็จ แล้วจึงตอบกลับ
• No wait (acks=0) : ตอบกลับทันที ไม่ต้องรอ

2.2 Producer Message

คือ ข้อมูลที่จะถูกส่งเข้ามาเพื่อเก็บใน Kafka โดยโครงสร้างคร่าว ๆ จะประกอบด้วย

2.2.1) Key คือ ข้อมูลที่จะใช้สำหรับการเลือก Partition โดยเราสามารถระบุ Key ให้กับ Event เพื่อให้ Event ที่มี Key เดียวกันได้ถูก Produce ไปลง Partition เดิมเสมอ แต่ถ้าหากเราไม่ได้ระบุ Message Key โดย default ตัว Event จะถูก Produce ไปยัง Partition โดยใช้วิธี Sticky partitioner ในการช่วยเลือก Partition ซึ่งถ้าใครสนใจเรื่อง Sticky partitioner สามารถอ่านรายละเอียดได้จาก ที่นี่

2.2.2) Value คือ ข้อมูลที่เราต้องการจะเก็บไว้ใน Kafka โดยอาจจะเป็นรูปแบบ Plain text, Photobuf, CSV และอื่น ๆ

2.2.3) Header คือ Key-Value pairs เพื่อใส่ข้อมูล additional ที่อาจจะต้องใช้งานในฝั่ง Consumer อย่างเช่น tracing, correlation-id เป็นต้น

อีกหนึ่งสิ่งที่สำคัญของ Producer Message คือ จะต้องมีการระบุ Serializer ให้กับ Key และ Value เสมอ เพื่อให้ Producer สามารถแปลงข้อมูลไปเป็น Binary ได้ถูกต้องตรง Format เพราะว่าข้อมูลที่เก็บไว้ภายใน Kafka จะเป็นรูปแบบ Binary

3. Consumer

Consumer คือ Application หรือ Service ที่เข้ามาดึงข้อมูลจาก Kafka ไปใช้งานต่อ โดยการที่จะเข้ามายัง Kafka Server เพื่อดึงข้อมูลไปใช้งานต่อได้ก็จะต้องมีการ Setup เบื้องต้นดังนี้

3.1 Consumer Configuration

3.1.1) Bootstrap server เป็น Configuration ที่ระบุถึง Kafka Server (Broker) เช่นเดียวกับ Bootstreap server ของฝั่ง Producer โดยฝั่งของ Consumer เองก็จะมีการเชื่อมต่อไปหา Kafka Server เพื่อดึงรายละเอียดของ Kafka Cluster (metadata) เพื่อใช้ต่อในการที่จะดึง Event มาใช้งานต่อ

3.1.2) Consumer group เป็น Configuration ที่จะช่วยเพิ่มความสามารถในการประมวลผลแบบขนานกันได้ โดยแทนที่จะมี Consumer คนเดียวมาดึงข้อมูลจาก Kafka Topic เราสามารถเพิ่ม Consumer หลายๆ ตัวมาช่วยกันได้ โดยจะมีกฏสำคัญข้อนึงคือ ภายใน Group

• 1 Partition จะถูกดึงข้อมูลโดย 1 Consumer เท่านั้น
• เมื่อ Consumer ตัวใดตัวหนึ่งล่มไป Kafka จะย้ายการดึงข้อมูลของ Partition ที่มันเคยดูแลอยู่ ไปให้ Consumer ตัวอื่น ๆ ที่ยังทำงานได้อยู่แทนโดยอัตโนมัติ

3.1.3) Delivery semantic เป็น Configuration ที่ไว้บอกว่าข้อมูลจะถูกประมวลผลจาก Consumer กี่ตัวก่อนที่จะ Commit เพื่อจะขยับ Offset ที่เก็บไว้ใน Kafka Server ไปยังเลขถัดไป โดยจะมีทั้งหมด 3 รูปแบบ คือ

• At lease once : ประมวลผลข้อมูลให้เสร็จก่อนแล้วค่อย Commit Offset
• At most once : Commit Offset ก่อนประมวลผล
• Exactly once : ใช้ Transaction หรือ Idempotent Consumer ในการจัดการ เพื่อให้มั่นใจว่าข้อมูลจะถูกประมวลผลแล้วค่อย Commit Offset

3.2 Consumer Message

คือ ข้อมูลที่ดึงออกมาจาก Kafka Topic โดยจะมีโครงสร้างเดียวกันกับ Producer Message แตกต่างกันเฉพาะฝั่ง Consumer จะเป็นฝั่งของการดึงข้อมูลมาใช้งาน ดังนั้น จะต้องมีการระบุ Deserializer ให้กับ Key และ Value ด้วยเพื่อให้สามารถแปลง Binary ที่อยู่ใน Kafka Topic กลับมาเป็นข้อมูลได้ถูกต้อง

4. Broker

Broker หรือ Kafka Server คือศูนย์กลางที่ทำหน้าที่ในการจัดเก็บและจัดการข้อมูลต่าง ๆ ภายใน Cluster โดยมีหน้าที่คร่าว ๆ ดังนี้

• เก็บและจัดการข้อมูล Event
• เป็นตัวกลางในการรับข้อมูลจาก Producer
• เปิดช่องทางให้ Consumer เข้ามาดึงข้อมูลไปใช้งานต่อ
• ทำการ Replication Data เพื่อเพิ่มความปลอดภัยของข้อมูล
• จัดการข้อมูลของ Topic, Partition และ Offset

โดย Broker ทุกตัวเราจะต้องมีการ Setup เบื้องต้นได้แก่

4.1 Role

ใน Kafka Cluster จะมีการกำหนด Role ให้กับ Broker โดยสามารถแบ่งออกได้เป็น สองแบบคือ Controller และ Broker

Role: Broker

คือ เครื่อง Broker ที่ทำหน้าที่ในการบันทึกและจัดการข้อมูลของแต่ละ Partition โดยแบ่งย่อยเป็น 2 แบบคือ

• Leader คือ Broker ที่คอยรับข้อมูลจาก Producer มาและบันทึกเข้าไปใน Kafka และเปิดให้ Consumer มาดึงข้อมูลไปใช้งานต่อได้
• Follower คือ Broker ที่ Repilcation ข้อมูลของ Partition ไว้ เผื่อ Leader พังไปจะมีโอกาสถูกเลือกขึ้นเป็นเครื่อง Leader ได้

Role: Controller

คือ เครื่อง Broker ที่ทำหน้าในการจัดการ Metadata ของ Cluster และคอย Monitor และเลือกว่าใครจะเป็น Leader ของแต่ละ Partition และเมื่อมีการเพิ่มลดจำนวน Broker ตัว Controller ก็จะเป็นคน Rebalance Partition ให้เหมาะกับจำนวน Broker ตัว Role ของฝั่ง Controller เองก็สามารถแบ่งเป็น 2 แบบคือ

• Active Controller คือ ตัวหลักที่ทำหน้าที่เป็น Controller อยู่ในปัจจุบัน ซึ่งมีได้แค่ 1 ตัวเท่านั้น
• Passive Controller คือ ตัวสำรองที่คอย Replication ข้อมูลของ Controller อยู่เพื่อตอนที่ Active Controller พังไป จะได้ขึ้นเป็น Active ตัวใหม่ได้ทันทีโดยคนที่ทำหน้าที่เป็นคนเลือก Controller คือ Manager

4.2 In-Sync replicas

คือ List รายชื่อของ Kafka Server (Broker) ทั้งหมดที่กำลังทำหน้าที่เก็บสำเนาข้อมูลใน Partition นี้อยู่ ซึ่งจะเหมือนกับที่อธิบายไปตอนต้นที่หัวข้อ Topic ซึ่งถ้ามีการ Setup ไว้ทั้งที่ Topic และ Broker ก็จะยึดจากที่ Topic เป็นหลัก เพราะ Priority ของ Topic สูงกว่า

5. Manager

มาถึงส่วนสุดท้ายกันแล้ว นั่นคือ Manager ซึ่งโดย Document ของ Kafka เองไม่ได้เรียกส่วนนี้ว่าเป็น Manager และก็ยังไม่เจอชื่อเรียกที่ชัดเจนนัก แต่ด้วยหน้าที่ที่เป็นคนคอยประสานงานให้การทำงานภายใน Cluster เป็นไปได้อย่างราบรื่นผมเลยเปรียบตัว Zookeeper และ KRaft เป็น Manager แทนนะครับ

5.1 Zookeeper

Zookeeper คือ Service ที่ไว้ใช้จัดการ Configuration และ Metadata ต่าง ๆ ของ Kafka และยังเป็นตัวที่คอยบอกทางให้กับ Client เพื่อตามหา Broker ที่ทำหน้าที่เป็น Leader ปัจจุบันของแต่ละ Partition ด้วย รวมทั้งคอยจัดการการ Broker คอย Monitor, เลือก Broker ที่จะทำหน้าที่เป็น Controller

5.2 KRaft

KRaft เป็นโหมดใหม่ของ Kafka ที่ถูกออกแบบมาแทนที่การใช้งาน Zookeeper ในการจัดการ Metadata ทั้งหมดของ Kafka ทำให้ไม่ต้องติดตั้งและดูแล Zookeeper Cluster แยกต่างหากอีกต่อไป ช่วยลดความซับซ้อน และปัญหา Latency ระหว่าง Kafka และ Zookeeper

ข้อจำกัด Zookeeper

• ต้องติดตั้งและดูแล Zookeeper Cluster แยกต่างหาก
• Metadata operation มี latency ที่สูงเพราะต้อง round-trip ไป Zookeeper
• การเลือก Controller จะทำผ่าน Zookeeper ทำให้ Failover ช้าขึ้น

KRaft มาแก้ปัญหาเหล่านี้โดยการเพิ่มการเก็บและจัดการ Metadata มากับ Kafka Broker เลยไม่ต้อง Setup หรือสร้าง Cluster แยกอีกต่อไป และเพิ่มการใช้ Kafka’s Raft ซึ่งเป็น Consensus Algorithm ที่พัฒนาต่อจาก Raft มาเป็นตัวช่วยในการตัดสินใจเลือกว่าจะให้ Broker ไหนรับ Role เป็น Active Controller ได้อย่างรวดเร็วและเสถียร

KRaft ได้รับการประกาศว่าเป็น Production ready ตั้งแต่ Apache Kafka 3.3 เป็นต้นไป โดยคาดว่า Zookeeper จะถูก deprecate (เลิกใช้) ทั้งหมดใน version 4.0 ขึ้นไป

Kafka in Advanced

นอกจากส่วนประกอบหลักที่กล่าวถึงไปแล้ว Kafka ยังมี Components เสริม ที่ออกแบบมาเพื่อตอบโจทย์ระบบ Always-On ซึ่งต้องทำงานต่อเนื่องและรองรับปริมาณข้อมูลขนาดใหญ่ ตัวอย่างที่น่าสนใจ ได้แก่

• Kafka Streams — Library สำหรับการประมวลผลข้อมูลแบบ real-time
• Kafka Connect —Framework สำหรับเชื่อมต่อ Kafka กับระบบภายนอก เช่น Databases, File systems, หรือ Messaging systems

Course

https://www.coursera.org/learn/packt-apache-kafka-series-learn-apache-kafka-for-beginners-v3-cjher

Reference

• Apache Kafka
• Home - Conduktor documentation
• Raft Consensus Algorithm
• Apache ZooKeeper
• KIP-833: Mark KRaft as Production Ready

Apache Kafka Components Explained in One Picture was originally published in odds.team on Medium, where people are continuing the conversation by highlighting and responding to this story.

สำหรับหน้าเว็บ เรามีวิธีง่าย ๆ ในการปรับเว็บเราให้เป็นโทนสีขาวดำ โดยใช้แค่ CSS บรรทัดเดียวเพื่อทำให้หน้าเว็บของเรากลายเป็นสีขาวดำแทนสีเดิมที่เราเคยใส่ไว้ โดย CSS ที่ต้องเพิ่มเข้าไปคือ filter: grayscale(1)

html,
body {
  /* Mourning grayscale filter */
  filter: grayscale(1);
}

ซึ่งโดยปกติแล้วเราใช้ filter ในการ blur หรือการปรับสีให้กับ element ของเราโดยปกติแล้วความสามารถของ filter หลัก ๆ ก็จะมี

• blur
• contrast
• grayscale
• hue-rotate
• drop-shadow
• opacity

ซึ่งถ้าอยากรู้ว่าแต่ละแบบต่างกันยังไง แนะนำให้เข้าไปลองเล่นจาก https://developer.mozilla.org/en-US/docs/Web/CSS/filter ซึ่งมีให้กดเล่นเพื่อให้เห็นภาพชัดเจนมาก ๆ

ด้วยความสามารถที่ filter ทำได้ บวกกับโครงสร้างของเว็บที่เรามี global.css เพื่อเอาไว้คุม theme หลักๆ ของ web เราไว้อยู่แล้ว เราก็แค่ add ตัว filter เข้าไปใน tag html หรือ html + body แบบในรูปตัวอย่างแรกได้เลย

JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.

สาเหตุที่เรามีการนำ JWT มาใช้ก็เพื่อการส่งข้อมูลระหว่างกันของ Service ไม่ว่าจะเป็น Frontend to Backend หรือ Backend to Another Backend ก็ดี ก็เพื่อให้มีความปลอดภัยมากขึ้น เพราะทุกอย่างถูกมัดรวมกันไว้เป็นก้อนเดียว และมี Signature ทับอีกชั้นเพื่อรับรองว่าข้อมูลด้านในไม่ได้ถูกปลอมแปลง และยังสามารถกำหนดอายุของ Token ไว้ได้ด้วย โดยเราจะพบ JWT ได้บ่อยในการใช้กับเรื่องของการส่งข้อมูลสิทธิ์การใช้งานของ User แปะไว้ใน Request Header ที่ชื่อ Authorization และมี value อยู่ในรูปแบบ Bearer <Token>

โครงสร้างของ JWT

ตัวอย่าง JWT

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

JWT จะประกอบไปด้วย 3 ส่วน ซึ่งคั่นกันตัวเครื่องหมาย “.” ซึ่งถ้าดูให้ง่ายขึ้น JWT จะอยู่ในรูปแบบนี้ คือ

hhhhhhhhh.ppppppppp.sssssssss

hhhhhhhhh => คือส่วนของ Header เอาไว้ใช้บอกประเภทของ Token และ algorithm ในการเข้ารหัสของ signature

pppppppp => คือส่วนของข้อมูล หรือที่เรียกว่า Payload หรือเรียกอีกชื่อว่า Claims

sssssssss => คือส่วนของ Signature

เรามาแกะ JWT เป็นส่วน ๆ กัน

ส่วนแรก คือ Header ซึ่งจาก JWT ตัวอย่าง เราจะได้ค่า base64 ของ Header คือ

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

เมื่อเรานำไป decode base64 จะได้ JSON หน้าตาแบบนี้

{"alg":"HS256","typ":"JWT"}

ส่วนที่สอง คือ Payload

eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ

เมื่อเรานำไป decode base64 จะได้ JSON หน้าตาแบบนี้

{"sub":"1234567890","name":"John Doe","iat":1516239022}

ส่วนสุดท้าย คือ Signature

SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

ซึ่งส่วนนี้เราจะไม่ได้นำไปเเกะเป็น base64 แต่เราจะเอาไปเปรียบเทียบ หรือ verify โดยขึ้นอยู่กับ algoritm ที่ใช้ซึ่งระบุอยู่ใน Header โดยถ้าเป็น Algorithm แบบ Symetric เราจะสร้าง Signature ด้วยท่าแบบด้านล่าง แล้วเอาไปเข้า Base64 และเปรียบเทียบกับ Signature เดิม ถ้าเท่ากันก็ผ่าน

HMACSHA256(
  base64UrlEncode(header) + "." + base64UrlEncode(payload),
  your-256-bit-secret
)

ส่วนถ้าเป็น Asymetric จะใช้เป็นการ verify signature แทน ซึ่งการ verify signature หากต้องการ ศึกษาเพิ่มเติมสามารถอ่านจากแหล่งเหล่านี้ได้เลย

• Validate JSON Web Tokens
• JSON Web Token Introduction - jwt.io

เพิ่มเติม ข้อสังเกตุของ JWT

เนื่องจากข้อมูลที่อยู่ใน Payload เป็นเพียงการเอา JSON ไป encode ด้วย base64 เท่านั้น ข้อมูลที่เป็น sensitive data ถ้าจะใส่เข้าไปควร encrypt ไว้ด้วย และขนาดของ Payload ไม่ควรเยอะเกินไปเพราะส่งผลให้ Token มีขนาดใหญ่ตามไปด้วย

เริ่มต้นจากการ initial project ด้วย npm กันก่อน

mkdir test-mock-server
cd test-mock-server
npm init

จากนั้นติดตั้ง express.js ซึ่งเป็น web application framework

npm install express

ต่อมาสร้าง file สำหรับ javascript application อย่างง่ายของเรากัน

// test-timeout.js
// Express Timeout Test Server
const express = require('express');
const app = express();
const PORT = 10443;

// Middleware to parse JSON body
app.use(express.json());

// Default route - responds immediately

// POST endpoint with timeout
app.post('/', (req, res) => {
  const delay = 120000;
  
  console.log(`POST request received, will respond after ${delay}ms`);
  
  setTimeout(() => {
    res.json({
      message: `POST response after ${delay}ms delay`,
      receivedData: req.body,
      timestamp: new Date().toISOString()
    });
  }, delay);
});

// Start the server
app.listen(PORT, () => {
  console.log(`Timeout test server running on port ${PORT}`);
});

อธิบาย code เพิ่มเติม

PORT คือ http server port ที่เราอยากให้ server เปิดขึ้นตอนที่ running

app.post('/' จะเป็นส่วนของการ config http method และ endpoint สามารถปรับแก้เป็น endpoint อื่น ๆ ตามที่เราต้องการได้ เผื่อว่าในฝั่ง client ที่เรียกมาที่ตัว mock http server ตัวนี้มี endpoint อื่น ๆ ที่กำหนดไว้อยู่แล้ว

const delay = 1200000; เป็นการตั้ง delay ให้กับการทำงานของ function นี้ โดยจากใน code ตัวอย่างจะ delay 2 นาที หรือก็คือ 120,000 วินาที

หลังจากนั้น save file js ของเรา โดยผมจะ save เป็น test-timeout.js

จากนั้น run js file ของเราด้วย node ผ่าน command

node test-timeout.js

เท่านี้ mock http server ของเราก็พร้อมใช้งานแล้ว

จากนั้นทดสอบด้วย curl

curl -X POST localhost:10443/

ผลลัพธ์จะออกกมาหน้าตาประมาณนี้ เป็นตาม log ที่เราตั้งไว้

เพียงเท่านี้เราก็จะมี mock http server เพื่อไว้ใช้ ทดสอบเราสำหรับ timeout แล้ว

ในบทนำของหนังสือ 7 Rules Positive Productive Change พูดถึงการตัดสินใจในการแก้ปัญหาบนสถานะการณ์ต่าง ๆ ที่มีความซับซ้อนต่างกัน โดยได้อ้างอิงถึง Cynefin Framework ขึ้นมาและน่าสนใจมากเลยอยากจะมาแชร์สิ่งนี้ต่อ

Cynefin Framework (คัน-นาฟ-อิน) คือ decision making framework ที่สร้างโดย Dave Snowden โดยใน framework ของเค้าได้แบ่งความซับซ้อนของปัญหาโดยดูจากความสัมพันธ์ของเหตุและผล ออกเป็น 5 แบบคือ

1.Obvious, Simple ⇒ ชัดแจ้ง คือมีวิธีการที่ดีในการแก้ปัญหาแบบนี้อยู่แล้วเเละสามารถนำไปใช้ได้เลย วิธีการคิดเมื่ออยู่ในปัญหาที่เป็น Simple คือ ใช้การตัดสินใจจากการแบ่ง Categorize ของปัญหาก่อนแล้วค่อยแล้วตัดสินใจตามวิธีการของ Categorize นั้น ๆ ที่เคยมีผลลัพธ์ที่แน่นอนปรากฏให้เห็นมาแล้ว

2. Complicated ⇒ คือ ยังไม่มีหลักฐานชัดเจนเกี่ยวกับวิธีการในการแก้ปัญหาต้องใช้การวิเคราห์เพิ่มเติมก่อนจะแก้ปัญหา หรือหาผู้เชี่ยวชาญมาช่วยคิด วิธีคิดเมื่ออยู่ในปัญหาแบบ Complicated คือ ใช้การตัดสินใจด้วยการ Analyze หาข้อมูลเพิ่มเติมให้เพียงพอ หรือหาคนที่เชี่ยวชาญมาช่วยหาทางออกที่เหมาะสม

3. Complex ⇒ สถานะการณ์ที่ต้องทดลองเสาะหาทางออกใหม่ ๆ เพื่อเเก้ปัญหานี้ วิธีคิดในเมื่ออยู่ในปัญหาแบบ Complex คือ คิดหาวิธีการขึ้นมาใหม่ๆ มาแล้วอาจจะทดสอบดูก่อนที่จะตัดสินใจว่าจะเลือกใช้วิธีการไหน

4. Chaotic ⇒ ทำยังไก็ได้ กำจัดความวุ่นวายออกไปก่อน วิธีการคิดเมื่ออยู่ในปัญหาแบบ Chaotic คือ การตัดสินใจหาการกระทำบางอย่างที่น่าจะทำให้ความวุ่นวายลดลง หรือควบคุมได้ง่ายขึ้นมาก่อนเป็นอันดับเเรก หลังจากที่ความวุ่นวายสงบลงแล้วบางที่ปัญหาของเราอาจจะกลายเป็น Simple ไปเลยก็ได้

5. Disorder ⇒ ไม่รู้ว่าสิ่งที่กำลังเจออยู่นี้คืออะไร สิ่งที่ต้องทำคือระบุให้ได้ก่อนว่าคืออะไร แล้วค่อยคิดถึงความซับซ้อนอีกที

สำหรับผู้ที่สนใจอยากได้ข้อมูลเพิ่มเติมสามารถดูได้จาก reference ด้านล่างต่อได้ครับ …

A Leader's Framework for Decision Making

ในการใช้งาน Node JS บางครั้งเราจะเจอปัญหาว่าในแต่ละ Project ที่นั้นใช้ Node version ที่แตกต่างกัน พอสลับ project ก็อาจจะ run ไม่ได้เนื่องจาก Node version ที่เครื่องใช้อยู่ใหม่กว่า version ที่ project ที่เราพึ่งสลับไป เลยอาจจะต้องมาคอยลบแล้วก็ติดตั้ง Node JS ใหม่ให้ตรงกับที่ project ใช้งานอยู่

ปัญหาเหล่านี้จะหมดไปถ้าเราใช้ Node manager

Node manager คือ เครื่องมือที่เกิดมาช่วยให้การจัดการ version ของ Node JS นั้นง่ายเเละรวดเร็วมากขึ้นเพียงไม่กี่ command ก็ได้ Node version ที่ต้องการ พร้อมสำหรับการ run Project เราอย่างง่ายดาย

เร็วกว่า NVM ยังไง

เครื่องมือที่มีการใช้งานแพร่หลายในการทำ Node manager ชื่อแรกที่จะขึ้นมาคือ NVM (Node Version Manager) ซึ่งถูกเขียนขึ้นด้วย Bash script ในขณะที่ FNM (Fast Node Manager) นั้นถูกเขียนขึ้นด้วย Rust จึงมีข้อได้เปรียบกว่า NVM หลายข้อตั้งแต่พื้นฐานของภาษาที่สามารถ compiled ไปเป็น machine code ก่อนได้ รวมไปจนถึงความสามารถในการ optimization ต่างๆ เช่น การทำ parallel เป็นต้น

การติดตั้ง

การติดตั้งสามารถทำได้หลายวิธีโดยอ้างอิงจาก document หลักได้เลย ส่วนผมจะใช้ brew ในการติดตั้งเพื่อความง่าย โดยเริ่มจาก

brew install fnm

จากนั้นก็ต้องเพิ่ม command ด้านล่างนี้เข้าไปใน .zshrc

eval "$(fnm env --use-on-cd --shell zsh)"

ทดสอบใช้งานด้วยการลอง fnm -V เพื่อตรวจสอบ version ของ fnm ถ้ามีการตอบกลับมาแสดงว่าใช้งานได้แล้ว

การใช้งาน

การค้นหาว่า Node version ปัจจุบันมี version ไหนอยู่บ้างสามารถทำได้โดยใช้

fnm list-remote
# ถ้าต้องการ version LTS สามารถใส่ --lts เพิ่มเข้าไป
fnm list-remote --lts

การติดตั้ง Node JS

fnm install v22.13.0
# ถ้าต้องการติดตั้ง version ที่เป็น latest LTS
fnm install --lts

หลังจากติดตั้ง เราสามารถเรียกดู Node version ที่ติดตั้งไว้ในเครื่องโดยใช้

fnm list

สั่งให้ fnm ตั้งค่า Node version เป็นตัวที่เราต้องการโดยใช้คำสั่ง

fnm use v22.13.0

จากนั้นลองเรียกดู version ของ Node โดยใช้ node -v เราก็จะได้ version เป็น v22.13.0 เป็นที่เรียบร้อย

สามารถดู Node version ปัจจุบันของ fnm ได้ด้วย command

fnm current

เท่านี้การปรับ Node version ก็เป็นเรื่องง่ายดายแล้ว แต่เดี๋ยวก่อน เราลองไปเปิด terminal ใหม่อีกสักตัวนึงแล้วลอง node -v ดูสิ๊ว่าจะได้ version อะไร ปรากฏว่าที่ terminal อื่น ๆ จะได้เป็น version ที่เป็น Node ที่มาจาก system หรืออาจจะไม่เจอเลย กรณีที่ไม่เคยลง Node มาก่อน สาเหตุที่เป็นแบบนี้เพราะว่า การเรียกใช้ fnm use … นั้นจะมีผมเฉพาะ session ของ terminal ที่เราเปิดอยู่เท่านั้น ถ้าปิด terminal ไปหรือเปิด terminal ใหม่ระบบจะไปหาตัว default มาแทน

ดังนั้นในเครื่องเราก็ควรตั้งค่า version ที่เป็น default ไว้ด้วย โดยใช้ command

fnm install v22.14.0
fnm default v22.14.0

เพียงเท่านี้ เราก็จะมีทั้ง version default (v22.14.0) และ version ที่เราตั้งค่าไว้ที่ terminal เรา (v22.13.0) ซึ่งถ้าเราเปิด terminal ใหม่ Node version ของ terminal นั้นก็จะเป็นค่า default (v22.14.0)

command อื่น ๆ สามารถดูได้จาก document หรือ fnm -h ก็ได้

เพียงเท่านี้ ชีวิตเราก็จะง่ายขึ้นเพียงเลือกใช้ tools ที่เหมาะสมกับการใช้งานของเรา

Reference

• GitHub - Schniz/fnm: 🚀 Fast and simple Node.js version manager, built in Rust
• GitHub - nvm-sh/nvm: Node Version Manager - POSIX-compliant bash script to manage multiple active node.js versions

ในการใช้งาน Kubernetes นั้นมักมีโจทย์ที่หลากหลายในเรื่องของการเก็บข้อมูลของ Pod บางครั้งเราอาจจำเป็นต้องเก็บข้อมูลที่ถูกสร้างด้วย Pod นั้นไว้ถาวรหรือบางครั้งก็จำเป็นที่จะต้องใช้ข้อมูลร่วมกับ Pod อื่น ๆ หรือในบางครั้งก็อยากให้ ทุก Pod ที่เกิดขึ้นมาใน Kubernetes นั้นสามารถเข้าถึงข้อมูลที่ path เดิมได้เสมอเเม้ Pod จะถูกสร้างใหม่ก็ตาม ในบทความนี้จะพาไปลงลึกในเรื่อง Mount Propagation ซึ่งเป็น Feature ที่อาจจะไม่ได้ถูกพูดถึงและไม่ค่อยเจอในการใช้งานปกติมากนัก แต่มันก็เป็นส่ิงที่มีอยู่ใน Kubernetes Volumes

Volumes ที่ได้ใช้งานหลักๆ ใน Kubernetes นั้นสามารถแบ่งย่อยได้เป็น 2 ประเภท

• Ephemeral Volume หรือ volume ชั่วคราวซึ่งจะมีอายุเท่ากับ Pod ตัวอย่างเช่น Configmaps, Secret, emptyDir.
• Persistent Volumes เป็น volume ที่อยู่ไปตลอด จนกว่าจะโดนทับ หรือมีรอบมาลบ volume นั้นๆ ออกไป ตัวอย่างเช่น hostPath, local (local storage device that mounted on nodes), nfs.

ทำไมถึงพูดถึงด้านบนก่อน ก็เพราะว่าในบางครั้งเราอาจจะจำเป็นต้องแชร์ Persistent Volume ที่เป็น hostPath หรือ local ร่วมกันกับ Pod อื่นที่อยู่ใน Host เดียวกัน ในจุดนี้เเหละที่เราอาจจะต้องการให้ Mount Propagation จะเข้ามาช่วยในการควบคุมการมองเห็นข้อมูลที่จะ mount จาก host เข้าไปยัง Pod

Mount Propagation Mode

• None ( default ) => โดย default mode จะเป็น private volume ที่สร้างมาและมองเห็นเฉพาะที่ pod ที่สร้างเท่านั้น
• HostToContainer => เป็นการ mount ข้อมูลจาก host ไปทับแทนที่ข้อมูลที่ path ของ container เลย (ถ้ามีอยู่ก่อนหน้า)
• Bidirectional => การ mount 2 ทาง ก็คือ merge รวม data ทั้งใน container และ host เข้าด้วยกัน แต่มีข้อจำกัดคือ ตัว container ต้องมีสิทธิ์ในการเข้าถึง host files ด้วย

ถ้าหากต้องการดูตัวอย่าง configuration สามารถอ้างอิงจากใน Document หลักของ Kubernetes ได้เลยครับ

https://kubernetes.io/docs/concepts/storage/volumes/#mount-propagation

Encoding

จุดประสงค์

• เพื่อเปลี่ยนรูปแบบข้อมูลไปเป็นอีกรูปแบบนึงที่เป็น เพื่อให้สามารถจัดเก็บหรือส่งต่อได้ง่ายขึ้น
• ไม่จำเป็นต้องมี secret key ในการ encoding
• ง่ายต้องการแปลงข้อมูลกลับ (ถ้ารู้ว่า Encoding ไปด้วยเทคนิคไหน)

ตัวอย่างการ Encoding

• URL Encoding เพื่อปรับเปลี่ยนอักษรพิเศษให้อยู่บน URL ได้
• Base64 Encoding เปลี่ยน Binary data ไปเป็น ASCII text
• UTF-8 ตัวอย่างที่เราคุ้นเคยก็คือเปลี่ยนการเปลี่ยนข้อมูลภาษาไทยของเราเป็น Unicode characters เพื่อบันทึกลง Database หรือ เพื่อการเเสดงผลภาษาไทยให้ไม่ผิดเพี้ยนไป

Encryption

จุดประสงค์

• เพื่อเปลี่ยนข้อมูลไปเป็นรูปแบบที่ไม่สามารถอ่านทำความเข้าใจได้
• ต้องมี Key ในการ encrypt และ decrypt
• เพื่อรักษาข้อมูลที่เป็นความลับ ให้ถูกเปิดอ่านได้เฉพาะคนที่กำหนดเท่านั้น
• คนที่สามารถเปิดอ่านข้อมูลได้จะต้องมี Key ที่ถูกต้องเท่านั้น

ตัวอย่างการ Encryption

• AES (symmetric encryption)
• RSA (asymmetric encryption)
• TLS/SSL ตัวนี้เราจะเห็นบ่อยในการทำ security สำหรับเว็บ browser

Hashing

จุดประสงค์

• เพื่อสร้าง “ตัวแทน” ของข้อมูล
• One-way ไม่สามารถแปลง “ตัวแทน” กลับมาเป็นข้อมูลเดิมได้
• เพื่อให้ได้ข้อมูลที่มีขนาดคงที่

ตัวอย่างการ Hashing

• SHA-256
• Bcrypt จะใช้บ่อยสำหรับการเก็บ password ลงใน database
• MD5 จะเจอในการทำ checksums เพื่อตรวจสอบความสมบูรณ์ของข้อมูลที่ส่งผ่าน internet

Reference

• Encoding, Encryption, and Hashing
• Hashing vs. Encryption vs. Encoding vs. Obfuscation | Codecademy
• The Difference Between Encoding, Encryption, and Hashing.
• Encryption vs Encoding vs Hashing - GeeksforGeeks

Prompt engineer is the systematic design and development of prompts for LLMs

Techniques

• Domain expertise
• Bias mitigation
• Framing
• Task specification

Approachs

• Interview pattern
• Cognitive building
• Tree-of-Thoughs
• Chain-of-Thoughs