Failure, Deployment and Observation

1Latency, Packet Loss และ Partial Failure

2Connection Refused เทียบกับ Timeout

สอง error ที่หน้าตาคล้ายกันแต่ความหมายต่างกันโดยสิ้นเชิง — ต้องแยกให้ออกเพื่อออกแบบ retry logic ให้ถูกต้อง:

3Timeout และ Retry

Retry คือการส่ง request ซ้ำเมื่อล้มเหลว — ฟังดูตรงไปตรงมา แต่มีอันตรายซ่อนอยู่ในหัวข้อถัดไป

4อันตรายจากการ Retry: Duplicate Request และ Idempotency

POST /orders
Idempotency-Key: 8f14e45f-...   (client สุ่มสร้างครั้งเดียวต่อ "เจตนา" การสั่งซื้อหนึ่งครั้ง)
{"item": "laptop", "qty": 1}

5Exponential Backoff

import time, random, requests

def call_with_retry(url, max_retries=5, base=0.1, max_delay=10):
    for attempt in range(max_retries):
        try:
            resp = requests.get(url, timeout=3)
            if resp.status_code < 500:
                return resp                  # สำเร็จ หรือ 4xx ที่ retry ไปก็ไม่ช่วย
        except requests.exceptions.RequestException:
            pass                              # timeout / connection refused → ลอง retry

        delay = min(base * (2 ** attempt), max_delay)
        time.sleep(random.uniform(0, delay))  # jitter
    raise TimeoutError("all retries exhausted")

6Health Check

Health check ทำงานร่วมกับ retry/backoff ของ caller: caller ที่ฉลาดจะเช็ค health ก่อนส่ง request จริง หรือใช้ผล health check ของ orchestrator เพื่อไม่ส่ง traffic ไปยัง instance ที่รู้อยู่แล้วว่าไม่พร้อม

7Log และ Correlation / Request ID

import uuid, requests
from flask import Flask, request, g

app = Flask(__name__)

@app.before_request
def assign_request_id():
    g.request_id = request.headers.get("X-Request-ID", str(uuid.uuid4()))

@app.post("/orders")
def create_order():
    print(f"[{g.request_id}] received order request")
    # ส่งต่อ ID เดิมไปยัง service ถัดไปในสาย
    resp = requests.get(
        "http://service-b:5001/inventory/laptop",
        headers={"X-Request-ID": g.request_id},
        timeout=3,
    )
    print(f"[{g.request_id}] inventory check → {resp.status_code}")
    ...

8Docker Networking และ Service Name

Docker (ผ่าน Docker Compose) แก้ปัญหานี้ด้วย service discovery ผ่านชื่อ: container ที่อยู่ใน network เดียวกันเรียกหากันได้ด้วยชื่อ service (ตามที่ตั้งไว้ใน docker-compose.yml) ราวกับเป็น hostname — Docker มี DNS ภายในที่ resolve ชื่อ service ไปเป็น IP ของ container นั้นให้อัตโนมัติ (สอดคล้องกับ DNS ที่เรียนไปแล้วใน Application Layer แต่ทำงานในสโคปแคบแค่ภายใน Docker network)

version: "3.9"
services:
  service-a:
    build: ./service_a
    ports:
      - "5000:5000"
    depends_on:
      - service-b
    environment:
      - INVENTORY_URL=http://service-b:5001   # ใช้ "service-b" แทน IP/localhost

  service-b:
    build: ./service_b
    ports:
      - "5001:5001"

  client:
    build: ./client
    depends_on:
      - service-a

9Reverse Proxy และ Load Balancing (เบื้องต้น)

10Lab: Docker Compose + จำลอง Failure

ใช้ระบบสองบริการจากหัวข้อที่ 2 เป็นฐาน แล้วทำตามลำดับ:

1. รัน client และสอง service ด้วย Docker Compose — docker compose up ยืนยันว่า Service A เรียก Service B ผ่านชื่อ service-b สำเร็จตามปกติ
2. ใส่ delay ให้ service หนึ่ง — เพิ่ม time.sleep(5) ใน Service B แล้วสังเกตว่า Service A ค้างรอ (ถ้าตั้ง timeout ไว้ 3 วินาที ควรเห็น timeout error ที่ Service A)
3. ปิด service ระหว่างรับคำขอ — docker compose stop service-b ขณะ Service A กำลังส่ง request สังเกตว่าได้ connection refused/reset แทน timeout (เทียบหัวข้อ 2)
4. เพิ่ม timeout และ retry — ใช้โค้ด exponential backoff จากหัวข้อ 5 ใน Service A แล้วรัน Service B แบบ intermittent (ล่มๆ หายๆ) ดูว่า retry ช่วยให้ request สำเร็จในที่สุดได้จริงหรือไม่
5. สังเกตว่า retry ทำให้รายการซ้ำหรือไม่ — เปลี่ยน endpoint ที่ retry จาก GET /inventory (idempotent โดยธรรมชาติ) เป็น POST /orders (ไม่ idempotent) แล้วนับจำนวน order ที่ถูกสร้างจริงเทียบกับจำนวนครั้งที่ user ตั้งใจสั่งซื้อ
6. ปรับ operation ให้เป็น idempotent — เพิ่ม idempotency key ตามหัวข้อ 4 แล้วทดสอบซ้ำขั้นตอนที่ 5 ยืนยันว่าจำนวน order ที่สร้างจริงตรงกับจำนวนความตั้งใจของ user แล้ว ไม่ว่าจะ retry กี่ครั้งก็ตาม

11ชุดการทดลอง Failure และ Deployment

การทดลองที่ 1 — สร้าง Baseline ก่อนทำให้พัง

1. รันระบบสองบริการด้วย Docker Compose ตรวจ docker compose ps และเรียก happy path 20 ครั้ง
2. บันทึก response time ต่ำสุด ค่ากลาง สูงสุด อัตราสำเร็จ และ request ID ถ้ายังไม่มี baseline จะบอกไม่ได้ว่าระบบช้าลงจริงหรือเพียงรู้สึกว่าช้า
3. ตรวจว่า container คุยกันด้วย service name ไม่ใช่ localhost เพราะ localhost ภายใน container หมายถึง container ตัวนั้นเอง
4. เก็บ config และ image tag ที่ใช้ เพื่อให้เพื่อนทำการทดลองซ้ำได้

docker compose up --build
docker compose ps
docker compose logs --tail=50 service-a service-b
curl -w "\nstatus=%{http_code} time=%{time_total}\n" \
  http://localhost:5000/orders/1

การทดลองที่ 2 — แผนที่อาการของ Failure

ให้ทำทุกแถวจริงและเขียน “ชั้นที่เกิดปัญหา” กำกับ การแยก DNS, TCP, TLS, HTTP และ application ออกจากกันช่วยไม่ให้เราแก้ผิดชั้น เช่น เพิ่ม retry ไม่ช่วยกรณี URL สะกดผิด

การทดลองที่ 3 — Timeout Budget ไม่ใช่ตัวเลขที่เดาเอา

1. สร้างสาย Client → A → B ให้ client รอ 3 s, A รอ B 5 s แล้วสังเกตว่า A ยังทำงานต่อหลัง client เลิกรอหรือไม่
2. ปรับให้ timeout ด้านในสั้นกว่าด้านนอก เผื่อเวลา serialize ส่งคำตอบ และ cleanup เช่น client 3 s, A→B 2 s
3. ทดลอง B มี latency แกว่ง วาด histogram อย่างง่าย และเลือก timeout จากความต้องการของผู้ใช้กับ percentile ไม่ใช่ค่าเฉลี่ยอย่างเดียว
4. แยก connect timeout กับ read timeout เพราะ “ต่อไม่ติด” และ “ต่อแล้วตอบช้า” บอกคนละปัญหา

การทดลองที่ 4 — Retry ที่ช่วยได้และ Retry ที่ทำร้ายระบบ

จำลอง B ล้มเหลว 50% แล้วเปรียบเทียบ 4 แบบ: ไม่ retry, retry ทันที 3 ครั้ง, exponential backoff, และ backoff พร้อม jitter เปิด client 20 ตัวพร้อมกันแล้วนับ request จริงที่ B ได้รับ

# แนวคิด ไม่ใช่สูตรตายตัว
delay = min(cap, base * (2 ** attempt))
sleep(random.uniform(0, delay))   # full jitter ลดการตื่นพร้อมกัน

การทดลองที่ 5 — คำตอบหาย แต่ธุรกรรมอาจสำเร็จแล้ว

1. ให้ B บันทึก order สำเร็จแล้วหน่วง/ตัด connection ก่อนตอบ A จากมุม A จะเหมือนล้มเหลว แต่ข้อมูลถูกเขียนแล้ว
2. ให้ A retry และนับจำนวน order ที่เกิดซ้ำ จากนั้นเพิ่ม idempotency key กับ unique constraint
3. ทดสอบ concurrent request ด้วย key เดียวกัน ถ้า check-then-insert แยกกันอาจยังแข่งกัน ต้องให้ฐานข้อมูลช่วยรับประกัน atomicity
4. สรุปว่า exactly-once ที่ผู้ใช้เห็นมักสร้างจาก at-least-once delivery บวกการ deduplicate ไม่ได้เกิดจากการหวังว่าเครือข่ายจะไม่ทำคำตอบหาย

การทดลองที่ 6 — Liveness, Readiness และ Startup

สร้าง endpoint แยกกันสามตัว: liveness ตอบว่า process ยังเดิน, readiness ตรวจ dependency ที่จำเป็นต่อการรับงาน, startup บอกว่าการเริ่มต้นเสร็จหรือยัง จากนั้นตัด database แล้วตอบคำถามว่า orchestrator ควร restart process หรือเพียงหยุดส่ง traffic

การทดลองที่ 7 — Correlation ID และ Structured Log

1. ให้ gateway รับหรือสร้าง request ID แล้วส่งต่อผ่าน header ทุก hop
2. เขียน log แบบ JSON ที่มี timestamp, level, service, request_id, operation, duration_ms, status และ error_type
3. ยิงคำขอพร้อมกัน 50 รายการ แล้วดึงเรื่องราวของคำขอหนึ่งรายการจากหลาย service ด้วย request ID เดียว
4. ห้าม log password, token หรือข้อมูลส่วนตัวเต็ม ๆ และแยกข้อความสำหรับคนออกจาก field ที่เครื่องค้นได้

การทดลองที่ 8 — Deployment โดยผู้ใช้ไม่รู้สึก

รัน service สองรุ่นหลัง reverse proxy ให้ v1 ตอบชื่อรุ่นและ v2 มีการเปลี่ยนแปลงเล็กน้อย ยิง traffic ต่อเนื่องระหว่าง rolling update บันทึก error และ distribution ของ version จากนั้นทำให้ v2 readiness fail แล้วตรวจว่า traffic ยังไปถึงหรือไม่

• Rolling: ต้องรองรับช่วงที่ v1/v2 อยู่พร้อมกัน โดยเฉพาะ schema และ message format
• Blue–green: สลับเร็วและย้อนกลับง่าย แต่ใช้ทรัพยากรสองชุด
• Canary: จำกัดผู้ใช้ที่เสี่ยง แต่ต้องมี metric และเกณฑ์หยุดที่ชัดเจน
• Graceful shutdown: หยุดรับงานใหม่ รอ in-flight request ตามเพดาน แล้วจึงปิด connection

สมุดบันทึกเหตุขัดข้องฉบับย่อ

รายงานที่ดีต้องแยก timeline, impact, root cause, contributing factors และ action item การเขียนว่า “network มีปัญหา” กว้างเกินไป เพราะยังบอกไม่ได้ว่าผิดที่ DNS เส้นทาง TCP service หรือทรัพยากรของเครื่อง

ชิ้นงานที่ส่ง

• Compose project ที่รันซ้ำได้ พร้อม health check และ config ผ่าน environment
• failure matrix อย่างน้อย 8 กรณี มีคำสั่งสร้างอาการและหลักฐานยืนยัน
• กราฟหรือตารางก่อน–หลัง retry/backoff และคำอธิบาย load amplification
• log ข้าม service ที่ตาม request เดียวได้ และตัวอย่างข้อมูลที่ตั้งใจไม่บันทึก
• deployment experiment พร้อมเกณฑ์ตัดสินว่าจะไปต่อหรือ rollback

12สรุปและขั้นตอนถัดไป

เป้าหมายไม่ใช่ทำให้ระบบ “ไม่ล้มเลย” เพราะทำไม่ได้ แต่คือทำให้ล้มในขอบเขตที่ควบคุมได้ รู้เร็ว อธิบายได้ และฟื้นได้โดยไม่สร้างความเสียหายซ้ำ ขั้นถัดไปคือเลือก pattern ให้ตรงกับแรงกดดันที่พบ ไม่ใช่ใส่ทุก pattern เพียงเพราะชื่อดูทันสมัย