Ops Engineering & Production CLI Toolkit

Redis CLI Professional & Diagnostic Battlebook

Bare-Metal Diagnostics, Latency Spikes Troubleshooting, Cluster Sharding Ops & Lua Scripting directly from Terminal

1. Production-Grade Connection & CLI Execution Modes

วิศวกรระดับ Senior จะไม่ใช้แค่ redis-cli ธรรมดา แต่ต้องเชี่ยวชาญ Flags สำหรับงาน Automation, Secure Remote Connection, และ Cluster Redirection

# 1. เชื่อมต่อไปยัง Production พร้อม Authenticate ผ่าน TLS และ Custom Database
redis-cli -h redis-prod.internal.bank -p 6379 -a "StrongVaultSecret" --tls --cacert /etc/ssl/redis/ca.crt -n 0

# 2. เชื่อมต่อ Redis Cluster (เปิด Auto-Redirect ตามคำตอบ -MOVED และ -ASK)
redis-cli -c -h 10.0.1.10 -p 6379

# 3. รันคำสั่งแบบ Non-Interactive Scripting (เหมาะกับ Bash / CI/CD)
# --raw: ตัด RESP Type formatting ออก คืนค่าดิบเพียวๆ นำไป grep/awk ได้ทันที
# --csv: แปลงผลลัพธ์เป็น CSV อัตโนมัติ
redis-cli -h 10.0.1.10 -p 6379 --raw GET config:feature_flags:instant_transfer
redis-cli -h 10.0.1.10 -p 6379 --csv MGET acc:101:bal acc:102:bal acc:103:bal

# 4. Continuous Command Execution (เฝ้าดูการเปลี่ยนแปลงแบบ Loop)
# -r 10 (รัน 10 รอบ) -i 0.5 (ทุกๆ 0.5 วินาที)
redis-cli -r 10 -i 0.5 INFO memory | grep used_memory_human

2. Production Diagnostics: Scanning without Blocking

กฎเหล็ก: SCAN vs KEYS *

คำสั่ง KEYS * ทำงานแบบ $O(N)$ จะบล็อก Event Loop และทำให้ทุกคำขอในระบบค้าง วิศวกรต้องใช้คำสั่งตระกูล SCAN เสมอ ซึ่งทำงานผ่าน Cursor-based Iteration:

Client Terminal Redis Event Loop (Non-blocking Batches) | | |--- SCAN 0 MATCH "user:token:*" COUNT 100 --------->| (Scans 100 buckets in hashtable) |<-- Return: Cursor "3421", [Key1, Key2, Key3] ------| (Yields back to other clients!) | | |--- SCAN 3421 MATCH "user:token:*" COUNT 100 ------>| (Resumes next batch) |<-- Return: Cursor "0", [Key4, Key5] ---------------| (Cursor 0 = Scan Finished)

# คำสั่ง SCAN ใน redis-cli
127.0.0.1:6379> SCAN 0 MATCH "session:usr_*" COUNT 100

# เทียบเท่าสำหรับ Data Structures อื่นๆ:
127.0.0.1:6379> HSCAN ledger:account_registry 0 MATCH "THB_*" COUNT 50
127.0.0.1:6379> SSCAN authorized_client_ids 0 COUNT 100
127.0.0.1:6379> ZSCAN leaderboard:daily_ranks 0 COUNT 100

การสแกนหา Big Keys & Hotkeys ผ่าน Terminal โดยตรง

# 1. สแกนหา Big Key (ปลอดภัยบน Production เพราะเบื้องหลังใช้ SCAN ทีละ Batch)
# รายงาน Key ที่มีขนาดไบต์ใหญ่สุด (String) และสมาชิกมากที่สุด (List, Hash, Set, ZSet)
redis-cli -h 10.0.1.10 -p 6379 --bigkeys

# 2. สแกนหา Hotkey (ต้องเปิด maxmemory-policy LFU ใน redis.conf ก่อน)
# ช่วยระบุว่า Key ไหนกำลังถูกถล่มยิงคำขอสูงสุดในคลัสเตอร์ ณ วินาทีนั้น
redis-cli -h 10.0.1.10 -p 6379 --hotkeys

# 3. ตรวจสอบ Memory Usage รายละเอียดระดับลึกของ Key ต้องสงสัย (หน่วยเป็น Bytes)
127.0.0.1:6379> MEMORY USAGE ledger:transactions:2026_09
127.0.0.1:6379> OBJECT ENCODING ledger:transactions:2026_09

3. Latency & Performance Diagnostics Toolkit

เมื่อผู้ใช้บ่นว่า API ตอบสนองช้า หรือเกิด Latency Spikes ขึ้นเป็นระยะ วิศวกรต้องทราบวิธีตรวจสอบ Latency ผ่าน CLI ให้ลึกถึงระดับ Kernel และ OS Sockets

1. SLOWLOG Analysis

SLOWLOG จะบันทึกเฉพาะคำสั่งที่ Execution Time บน Single Thread เกินเกณฑ์ (ไม่รวมเวลา Network I/O):

# ดูเกณฑ์การบันทึกปัจจุบัน (หน่วยเป็น Microseconds, ค่าเริ่มต้นคือ 10,000 µs = 10ms)
127.0.0.1:6379> CONFIG GET slowlog-log-slower-than
# ปรับเกณฑ์ให้เข้มงวดขึ้นใน Production (เช่น เกิน 1,000 µs = 1ms ให้บันทึกทันที)
127.0.0.1:6379> CONFIG SET slowlog-log-slower-than 1000

# ดึง 10 รายการคำสั่งล่าสุดที่กินเวลา CPU เกินเกณฑ์
127.0.0.1:6379> SLOWLOG GET 10
# ผลลัพธ์: [ID, Timestamp, Execution Duration (µs), Command Arguments, Client IP:Port]

2. Real-time Latency Monitoring Flags

# 1. วัด Network + Event Loop Latency แบบ Real-time (ส่ง PING รัวๆ)
# วัดค่า Min, Max, Average Latency อย่างต่อเนื่อง (กด Ctrl+C เพื่อหยุด)
redis-cli -h 10.0.1.10 -p 6379 --latency

# 2. พล็อตกราฟ Latency Spikes ใน Terminal เป็นรหัสสี ASCII
redis-cli -h 10.0.1.10 -p 6379 --latency-dist

# 3. แยกแยะปัญหา: ทดสอบดูว่า OS หรือ Hardware Virtualization มี Latency หรือไม่
# --intrinsic-latency: รันลูปคำนวณใน CPU เพียวๆ 100 วินาที เพื่อดูว่า OS Kernel ขโมย Cycles หรือไม่
redis-cli --intrinsic-latency 100

การวิเคราะห์ผลลัพธ์ Intrinsic Latency: หากรัน --intrinsic-latency แล้วพบค่า Max latency เกิน 2-3 มิลลิวินาที แสดงว่าปัญหาไม่ได้อยู่ที่ Redis แต่เกิดจาก OS Kernel Throttling, Hypervisor Steal Time (ใน AWS/GCP), หรือ CPU Power Saving Frequency Scaling

4. Memory & Buffer Deep Diagnostics

คำสั่ง INFO memory คือหัวใจในการตรวจสอบความเสี่ยงต่อการโดน Linux Kernel OOM Killer สั่งฆ่าโปรเซส

127.0.0.1:6379> INFO memory
# -------------------------------------------------------------
# used_memory: 12582912000 (RAM ที่เก็บข้อมูลจริง ~11.7 GB)
# used_memory_rss: 18253611008 (RAM จริงที่ OS Kernel มองเห็น ~17.0 GB)
# mem_fragmentation_ratio: 1.45 (RSS / Used Memory)
# mem_allocator: jemalloc-5.3.0
# client_recent_max_output_buffer: 524288000 (Output Buffer สะสมสูง)
# -------------------------------------------------------------

การวิเคราะห์และแก้ไข Memory Fragmentation

Fragmentation Ratio > 1.5: มีการจอง RAM จาก OS แต่คืนไม่หมด เกิดช่องว่างใน Page แก้ไขได้ด้วยการสั่ง Defragment ในหน่วยความจำสดๆ โดยไม่ต้อง Restart:
```
127.0.0.1:6379> CONFIG SET activedefrag yes
127.0.0.1:6379> MEMORY PURGE # บังคับให้ jemalloc คืน Memory ที่ไม่ได้ใช้ให้ OS ทันที
```
Fragmentation Ratio < 1.0: สัญญาณอันตรายขั้นวิกฤต! แสดงว่า Physical RAM หมด และระบบกำลังทำ Paging / Swapping ลงดิสก์ Latency ของ Redis จะร่วงจาก Sub-millisecond ลงไปสู่หลักหลายสิบมิลลิวินาทีทันที

การตรวจสอบ Client Output Buffers (ป้องกัน Slack Scenario)

# ตรวจดูว่ามี Client หรือ Replica โหนดใดกำลังสะสม Buffer ใน RAM สูงผิดปกติหรือไม่
127.0.0.1:6379> CLIENT LIST
# สังเกตคอลัมน์ obl (Output Buffer Length), oll (Output List Length), omem (Output Memory)
# หากพบ Client ที่ omem พุ่งสูงผิดปกติ สามารถสั่งตัดการเชื่อมต่อได้ทันที:
127.0.0.1:6379> CLIENT KILL ID 84920

5. Redis Cluster & Lua Scripting CLI Operations

1. การรันและดีบัก Lua Script ผ่าน Terminal

# 1. รันไฟล์ Lua สดจาก Terminal ผ่านคำสั่ง --eval
# ไวยากรณ์: redis-cli --eval <script.lua> <key1> <key2> , <arg1> <arg2>
# สำคัญมาก: ต้องมี space คั่นหน้าและหลังเครื่องหมายจุลภาค ( , ) เพื่อแยก KEYS ออกจาก ARGV
redis-cli --eval atomic_withdraw.lua ledger:{acc_101}:balance , 500 "TXN_9981"

# 2. โหลด Script เข้าไปแคชไว้ใน RAM ของ Redis ล่วงหน้า (ได้ SHA1 Checksum กลับมา)
redis-cli SCRIPT LOAD "$(cat atomic_withdraw.lua)"
# ผลลัพธ์: "7a8b9c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b"

# 3. รันผ่าน EVALSHA โดยส่งเพียง SHA1 (ประหยัด Network Bandwidth)
127.0.0.1:6379> EVALSHA 7a8b9c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b 1 ledger:{acc_101}:balance 500 "TXN_9981"

# 4. หากมีสคริปต์รันวนลูปไม่หยุด (Infinite Loop) บล็อก Event Loop ให้สั่งหยุดฉุกเฉิน:
127.0.0.1:6379> SCRIPT KILL

2. Redis Cluster Topology & Sharding Administration

# 1. ตรวจสอบสถานะความสมบูรณ์ของ Cluster ทุกโหนด (เช็ค 16,384 Slots ว่าครบหรือไม่)
redis-cli --cluster check 10.0.1.10:6379

# 2. คำนวณดูว่า Key จะตกอยู่บน Hash Slot ใด
127.0.0.1:6379> CLUSTER KEYSLOT "ledger:{acc_99}:balance"
# ผลลัพธ์: (integer) 12450 (เพราะคำนวณ CRC16 จากเฉพาะ "acc_99")

# 3. Resharding: ย้าย Hash Slots จาก Node เก่าไปยัง Node ใหม่แบบ Online
redis-cli --cluster reshard 10.0.1.10:6379 --cluster-from <source-node-id> --cluster-to <target-node-id> --cluster-slots 1000

# 4. บังคับ Failover แมนนวลอย่างปลอดภัยบน Replica Node (Graceful Failover)
127.0.0.1:6379> CLUSTER FAILOVER # (สั่งบน Replica เพื่อขึ้นเป็น Master แทนโดยข้อมูลไม่หาย)

Redis CLI & Troubleshooting Assessment Bank (Interactive Knowledge Check)

แบบทดสอบวัดทักษะการใช้งาน Command-Line, การดีบักปัญหา Latency, การจัดการ Cluster, และการกู้วิกฤต Production 15 ข้อ

CLI Assessment Score: 0 / 15