InfrastructureObservabilityLinux Kernel

eBPF คืออะไร?
เทคโนโลยีที่กำลังเปลี่ยน
Infrastructure Engineering

eBPF ช่วยให้ run โค้ดใน Linux Kernel ได้โดยไม่ต้องแก้ kernel source — เปิดโอกาสใหม่ด้านการ observe, secure, และ optimize infrastructure อย่างที่ไม่เคยเป็นไปได้มาก่อน Netflix, Meta, Google, Cloudflare ใช้มันในระดับ production ที่ traffic หลักพันล้าน request ต่อวัน

ถ้าคุณใช้ Kubernetes, microservices, หรือดูแล Linux-based infrastructure — eBPF คือหนึ่งในเทคโนโลยีที่สำคัญที่สุดที่คุณควรรู้จักในทศวรรษนี้มันไม่ใช่ feature ของ tool ใดเป็นการเฉพาะ แต่เป็น primitive ใหม่ในระดับ OS ที่ทำให้ Observability, Security, และ Networking เปลี่ยนไปโดยสิ้นเชิง
<1%
CPU overhead ของ eBPF-based observability เทียบกับ traditional agent ที่ใช้ 5–15%
Meta Engineering Blog
10×
throughput สูงกว่า iptables ในการ filter network traffic ด้วย XDP บน eBPF
Cilium Benchmarks, 2023
72%
ของ Fortune 500 ใช้ eBPF-based tools ในการ monitor production อยู่แล้ว
eBPF Foundation Survey, 2024

eBPF คืออะไร? — จาก BPF สู่ eBPF

BPF ดั้งเดิม (1992)

Berkeley Packet Filter ถูกสร้างขึ้นในปี 1992 เพื่อ filter network packet ใน Unix มีความสามารถจำกัด — แค่ filter ว่า packet ไหนควรส่งให้ userspace หรือ drop เครื่องมืออย่าง tcpdump ใช้ BPF ตั้งแต่ยุคนั้น

Packet FiltertcpdumpLimited registers

eBPF — Extended BPF (2014–ปัจจุบัน)

Linux 3.18 เพิ่ม eBPF เข้าสู่ kernel อย่างเป็นทางการ โดย extend BPF ให้เป็น general-purpose virtual machine ใน kernel ที่รัน bytecode ผ่าน JIT compiler, มี verifier ตรวจสอบความปลอดภัย, และ maps สำหรับแชร์ข้อมูลกับ userspace

JIT CompilerVerifierMapsMultiple Hook Points

eBPF ทำงานอย่างไร? — ปลอดภัย รวดเร็ว ไม่ต้องแก้ Kernel

สิ่งที่ทำให้ eBPF พิเศษคือสามารถ inject โค้ดเข้า kernel ได้ในแบบ sandboxedโดยมีกลไก 3 ชั้นที่รับประกันว่าจะไม่ทำให้ระบบ crash หรือเปิดช่องโหว่ด้านความปลอดภัย
STEP 1

เขียน eBPF Program

เขียนใน C (หรือผ่าน Go/Rust bindings) แล้ว compile เป็น eBPF bytecode ด้วย LLVM/Clang โปรแกรมจะถูก attach เข้ากับ hook point ต่างๆ ใน kernel เช่น system call, network event, หรือ tracepoint

C / Rust / GoLLVM/Clanglibbpf
STEP 2

Verifier ตรวจสอบความปลอดภัย

ก่อน load เข้า kernel ทุกครั้ง kernel verifier จะตรวจสอบว่าโปรแกรม: ไม่มี infinite loop, ไม่เข้าถึง memory ที่ไม่ได้รับอนุญาต, และไม่สามารถทำให้ kernel crash ได้ — ถ้าผ่านไม่ได้จะ reject ทันที

No infinite loopsMemory safetyBounded execution
STEP 3

JIT Compile & Execute

หลังผ่าน verifier bytecode จะถูก JIT compile เป็น native machine code ทำให้รันได้เร็วเทียบเท่า native kernel code ผลลัพธ์สามารถส่งกลับไปยัง userspace ผ่าน eBPF Maps หรือ perf events

Native performanceeBPF MapsRing buffers
ทำไมถึงปลอดภัย? eBPF program ไม่สามารถเรียก arbitrary kernel function ได้โดยตรง มันเรียกได้เฉพาะ "helper functions" ที่ kernel กำหนดไว้เท่านั้น และ verifier จะ static-analyze ทุก execution path ก่อนอนุญาตให้ run — ต่างจาก kernel module ที่อาจ crash ระบบได้ทันที

4 กลุ่มการใช้งานหลักในโลก Production จริง

Observability
Zero-instrumentation Profiling & Tracing
ใช้งานสูงสุด

แทนที่จะต้องแก้โค้ด application เพื่อเพิ่ม telemetry (instrumentation) eBPF สามารถ observe ทุก system call, function call, memory allocation, และ network connection โดยไม่แตะโค้ด application เลยทำให้ได้ visibility เต็มรูปแบบใน microservices ที่เขียนด้วยหลายภาษาโดยไม่ต้องแก้แต่ละ service

เครื่องมือที่ใช้
Pixie, Parca, Pyroscope, Grafana Beyla, OpenTelemetry eBPF
ใครใช้
Netflix (CPU profiling ทุก host), Shopify (distributed tracing), Datadog (agent)
CPU ProfilingDistributed TracingMemory AnalysisLatency Tracking
Networking
High-performance Load Balancing & Service Mesh
Kubernetes Native

Cilium — CNI plugin ที่ใช้ eBPF แทน kube-proxy และ iptables ใน Kubernetes ทำให้ network policy enforcement เกิดขึ้นในระดับ kernel โดยตรง ลด latency และเพิ่ม throughput อย่างมีนัยสำคัญ Cloudflare ใช้ XDP (eBPF-based) รับ traffic DDoS หลายร้อย Gbps โดยไม่ต้องส่งขึ้น TCP/IP stack เลย

เครื่องมือหลัก
Cilium, Hubble (network visibility), XDP, Katran (Meta LB)
ประโยชน์
ลด iptables rules จากหมื่นบรรทัดเหลือ eBPF map, service mesh ไม่ต้องใช้ sidecar proxy
Cilium CNIXDP / DPDKSidecarless MeshDDoS Mitigation
Security
Runtime Security & Threat Detection
Cloud Native

eBPF สามารถ monitor ทุก system call ใน kernel ได้แบบ real-time ทำให้สามารถตรวจจับ behavior ที่ผิดปกติ เช่น container ที่พยายาม escape, process ที่ open unexpected network connection, หรือ privilege escalationโดยไม่ต้องพึ่ง signature-based detection — ตรวจจับ zero-day ได้

เครื่องมือหลัก
Falco, Tetragon (Cilium), KubeArmor, Tracee (Aqua)
ความสามารถ
Container escape detection, Cryptomining detection, Lateral movement tracking, Policy enforcement
Runtime SecuritySyscall AuditingZero-day DetectionCNAPP
Performance Engineering
CPU & Memory Profiling ระดับ Production
Always-on

Continuous profiling ด้วย eBPF ทำให้สามารถเก็บ performance data ตลอดเวลาใน production โดยมี overhead ต่ำมาก (น้อยกว่า 1%) ต่างจาก traditional profiler ที่ต้องเปิดตอน debug เท่านั้น Google Borg ใช้ eBPF profiling ทั้ง fleet และประหยัดค่า compute ได้ หลายร้อยล้านดอลลาร์ต่อปีจากการระบุ hot code path ที่ optimize ได้

เครื่องมือหลัก
Parca, Pyroscope, Polar Signals, bpftrace, perf
ผลลัพธ์จริง
Google ประหยัด compute 6% fleet-wide, Intel ลด latency 40% ใน storage stack
Flame GraphsContinuous ProfilingCPU EfficiencyMemory Leak Detection

eBPF Ecosystem — เครื่องมือที่ใช้งานได้จริงวันนี้

เครื่องมือ
หมวดหมู่
เหมาะกับ
Cilium
cncf.io/projects/cilium
Networking / Security
Kubernetes CNI, ต้องการ high-performance network policy
Pixie
px.dev
Observability
Kubernetes, auto-instrument ทุก service โดยไม่แก้โค้ด
Falco
falco.org
Security
Runtime threat detection, Kubernetes + container security
bpftrace
bpftrace.org
Tracing / Debugging
SRE / Platform team ที่ต้องการ ad-hoc kernel tracing
Pyroscope
grafana.com/oss/pyroscope
Profiling
Continuous profiling, ใช้คู่กับ Grafana stack
Tetragon
tetragon.io
Security
eBPF-based enforcement, ไม่ใช่แค่ detect แต่ block ได้เลย

eBPF เหมาะกับองค์กรแบบไหน?

ใช้ Kubernetes หรือ container-based infrastructure

eBPF ถูกออกแบบมาให้ทำงานได้ดีที่สุดบน Linux kernel สมัยใหม่ ถ้า workload ของคุณรันบน K8s นี่คือ use case ที่ชัดเจนที่สุด — ทั้ง network policy, observability, และ security enforcement

✓ เหมาะมาก
มี microservices หลายภาษาที่ต้องการ observability

แทนที่จะต้อง instrument แต่ละ service ด้วย SDK ที่ต่างกัน eBPF-based tool เช่น Pixie หรือ Grafana Beyla สามารถ auto-detect L7 traffic ทุก protocol โดยไม่ต้องแก้โค้ดสักบรรทัด

✓ เหมาะมาก
ทีมที่ยังไม่ได้ใช้ Kubernetes

eBPF ใช้ได้บน bare metal Linux และ VM เช่นกัน แต่ความซับซ้อนในการ setup สูงกว่า และ ecosystem ส่วนใหญ่ออกแบบมาสำหรับ Kubernetes ถ้ายังไม่ได้ใช้ K8s อาจเริ่มจาก tool ที่ใช้ง่ายกว่าก่อน

→ ประเมินก่อน
มี performance problem ที่หาต้นตอไม่ได้

ถ้ามี latency spike, memory leak, หรือ CPU contention ที่ application-level tracing ไม่สามารถ pinpoint ได้ eBPF profiling เช่น bpftrace หรือ Pyroscope จะช่วยให้เห็น kernel-level behavior ที่ซ่อนอยู่

✓ ตัวเลือกที่ดีมาก
ข้อควรระวัง: eBPF ต้องการ Linux kernel version 4.4+ (บางฟีเจอร์ต้องการ 5.x+) และ root หรือ CAP_BPF privilege ในการ load program บน Windows หรือ macOS ยังไม่รองรับโดยตรง (แม้ Microsoft จะมี Windows eBPF roadmap) สำหรับ Production deployment ควร test บน staging ก่อนเสมอ

eBPF ไม่ใช่ระดับ Advanced — มันคือ Infrastructure Standard ใหม่

สิ่งที่ทำให้ eBPF น่าสนใจไม่ใช่แค่ performance ที่ดีกว่า แต่คือ มันเปลี่ยน paradigm ของการ observe และ secure system จาก "ต้องแก้โค้ด application" มาเป็น "kernel รู้ทุกอย่างและบอกเราได้" โดยไม่เพิ่ม complexity ให้ application layer

สำหรับองค์กรไทยที่กำลัง modernize infrastructure หรือ migrate สู่ Kubernetes eBPF คือการลงทุนที่คุ้มค่า — ไม่ใช่เพราะมันเป็นเทคโนโลยีใหม่ แต่เพราะ ปัญหาที่มันแก้ (observability, security, performance) เป็นปัญหาจริงที่ทุกองค์กรเจอ

Tensora ใช้ eBPF-based tooling ในการ monitor และ optimize infrastructure ของลูกค้า ถ้าคุณกำลังเผชิญกับ performance bottleneck หรือต้องการ observability ที่ลึกกว่านี้ เราพร้อมช่วยประเมินว่า eBPF เหมาะกับ stack ของคุณหรือไม่

สนใจ modernize infrastructure ด้วย eBPF-based observability?

พูดคุยกับทีม Tensora →