SuperApp Backend — สถาปัตยกรรมบน AKS

Runtime · request path

Service architecture

request เดินทางจาก client ผ่าน Azure APIM (ชั้นนอกสุด ทำหน้าที่ session façade) เข้าสู่ AKS cluster ที่มี nginx-internal ingress กระจายไป 16 microservices แต่ละ service เป็น ClusterIP, รัน Workload Identity เดียวกัน และเชื่อมออกไปยัง Azure backing services สามตัว: Key Vault, Service Bus, PostgreSQL

Request path ที่ต้องรู้

APIM = session façade: รับ session cookie .Exim.Auth* → side-call ไป Sentinel Gateway /sentinel/internal/resolve-session เพื่อแลก JWT, cache 120s, rate-limit 3 tier (session / bearer / anon)
nginx-internal: internal load balancer (azure-load-balancer-internal: "true") ไม่มี public TLS — host api.sua-az-dev.internal
Path rewrite: /api/{service}(/|$)(.*) → /api/{service}/$2 แล้วชี้ตรงไปที่ container port จริงของ service (เช่น user → 5111) ไม่ใช่ port 80

16 services (ยึดจาก ArgoCD ApplicationSet dev)

user5111

sentinel-gateway5100

notification5200

filemanagement5500

filter5201

log5300

thirdparty5000

consent5008

codex5202

redisinsight5540

workflow9009

centralized5009

thirdpartyfx5001

task5600

fxcontract5059

orchestratorsaga

fx-service8080 ⚠

fxorchestrator5060 ⚠

fx-service และ fxorchestrator-service มี manifest ครบและอยู่ใน port report แต่ ไม่ปรากฏใน dev appset — ต้อง verify ว่าตั้งใจ deploy แยกหรือยังไม่ผูก ArgoCD

Delivery · GitOps pipeline

Deployment flow

ไม่มีใคร kubectl apply ด้วยมือ — Git คือ source-of-truth ทั้งหมด CI สร้าง image แล้ว commit image tag ใหม่กลับเข้า repo, ArgoCD เฝ้าดู Git แล้ว sync ลง cluster อัตโนมัติ

ApplicationSet (list generator): สร้าง Application ต่อ service อัตโนมัติ ไม่ใช่ Application รายตัว — branch dev จริงคือ development
กัน infinite loop: commit manifest ใช้ [skip ci] + exclude path yamls/**, docs/, *.md
Image tag = commit SHA: เช่น dev-650ce0b ไม่ใช่ semver — rollback ต้องหา tag จาก SHA

⚠ rollback ที่ถูกต้อง

kubectl rollout undo เป็นแค่ชั่วคราว เพราะ selfHeal จะดึงกลับตาม Git ภายใน ~30s — ต้อง revert image tag ใน manifest แล้ว push ถึงจะถาวร

Secrets · Key Vault + CSI

Secret management flow

secret ทั้งหมดอยู่ใน Azure Key Vault ดึงเข้า pod ผ่าน CSI Secrets Store driver ด้วย Workload Identity แล้ว sync เป็น K8s Secret ก่อน inject เข้า .NET IConfiguration

KV เดียวทั้ง dev + sit: sua-azure-nonprd-kv แยกด้วย prefix dev-- / sit-- ใน naming {env}--{service}--{Section}--{Key}
objectAlias: แปลง -- → __ ให้ตรง .NET config key
Workload Identity: client-id 8bc68e37-1d90-49de-b85f-8a386502332f — ผูก ServiceAccount ผิดจะดึง secret ไม่ได้เลย

⚠ naming ที่พลาดบ่อย

SPC ชื่อ {svc}-service-kv-secrets แต่ K8s Secret ที่ sync ออกมาชื่อ {svc}-service-secrets — คนละ object คนละชื่อ เวลา debug ต้องเรียก kubectl get secretproviderclass กับ kubectl get secret ให้ถูกตัว

Ground truth · manifest vs stale docs

เอกสารเก่าขัดกับ manifest จริง

README.md และ STRUCTURE_OF_CODE.md เป็นเอกสารยุคแรก (อ้าง 8–10 service, identity/KV เดิม) ขณะที่ระบบโตเป็น 16 service และเปลี่ยน identity ไปแล้ว — ให้ยึด manifest จริงเสมอ

หัวข้อ	เอกสารเก่าบอก	manifest จริง (verified)
จำนวน service	8 – 10	16 services
ServiceAccount	bff-service-sa	centralize-aks-sa
Key Vault	sua-az-dev-kv	sua-azure-nonprd-kv
WI client-id	e79ca974…	8bc68e37…
Image tag	dev-0.0.29 (semver)	dev-650ce0b (SHA)
Ingress backend port	port 80	container port (user 5111)
branch ของ dev	develop	development