CodeSook โค้ดสุข

🤖 เบื้องหลังการสเกล PostgreSQL ของ OpenAI เพื่อรองรับผู้ใช้ 800 ล้านคน และยอด query ระดับ 1M+ QPS โดยยังมี SLA ระดับ 99.999%
⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣
📉 การลดโหลดบนตัว primary database (OpenAI ใช้ single-primary และ replica มากกว่า 50+ ตัว)
- ย้ายงานเขียนหนักออกไป: เนื่องจากกลไก MVCC ของ Postgres ทำให้การ update ข้อมูลไม่ค่อยมีประสิทธิภาพ (มีการก๊อปปี้ทั้งแถวใหม่เป็นอีก version) ทีมจึงย้ายงานที่เขียนเยอะและทำ sharding ได้ ไปไว้บน Azure Cosmos DB แทน
- ตั้งกฎ No New Tables: ปัจจุบันไม่อนุญาตให้เพิ่ม table ใหม่ใน PostgreSQL ชุดนี้แล้ว งานใหม่ทั้งหมดต้องไปลงที่ระบบ sharded แทน
- ปรับจูนแอปพลิเคชัน: แก้ไข bug ที่ทำให้เกิดการเขียนซ้ำซ้อน และใช้เทคนิค lazy writes เพื่อกระจายโหลดช่วงที่ traffic สูงๆ
- การเติมข้อมูลย้อนหลัง (backfill) ต้องมีการทำ rate-limit เพื่อไม่ให้กระทบ performance เครื่องหลัก
⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣
🔍 การเพิ่มประสิทธิภาพ query
- หลีกเลี่ยง query ที่ซับซ้อน: เช่นการ join หลาย table พร้อมกันหลายๆ อัน (ซึ่งเคยมีเคสทำการ join มากกว่า 12 table จนทำให้ระบบล่ม) และย้าย logic การ join ไปทำที่ application layer แทน
- ตรวจสอบ query ของ ORM: เนื่องจาก ORM มักสร้าง SQL ที่แย่ ทีมจึงต้องรีวิว SQL ที่ถูกสร้างออกมาอย่างละเอียดเพื่อให้มั่นใจว่าทำงานได้ตามที่คาด
- จัดการ Idle Sessions: ตั้งค่า idle_in_transaction_session_timeout เพื่อป้องกัน query ที่ค้างอยู่ไปบล็อคการทำงานของ autovacuum (ซึ่งทำหน้าที่เก็บกวาดพวก row/tuple เวอร์ชั่นเก่าๆ ออกไป)
⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣
🛡️ การจัดการความเสี่ยงจาก Single Point of Failure
- ย้ายการอ่านเกือบทั้งหมดไปที่ replicas เพื่อให้ระบบยัง "อ่าน" ได้ (read-only) แม้ primary จะล่ม
- High Availability (HA): ใช้โหมด HA พร้อม hot standby ที่ซิงค์ข้อมูลตลอดเวลา เพื่อให้พร้อมรับงานแทน primary ได้ทันทีที่มีปัญหา
⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣
🏗️ การแยกส่วนงาน (Workload Isolation)
- แยก request ตามความสำคัญเป็น high-priority และ low-priority แล้วส่งไปลง database Instance คนละตัว เพื่อแก้ปัญหา "noisy neighbor" การที่มี "query ที่มีปัญหา" จาก feature A มาดึง CPU จนเครื่องอืด และไปกระทบ feature หรือ product อื่นๆ ที่รันอยู่บนเครื่องเดียวกัน
⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣
🔌 Connection pooling
- ใช้เป็น PgBouncer เป็น proxy layer เพื่อทำ connection pooling ช่วยลด latency ในการเชื่อมต่อจาก 50ms เหลือเพียง 5ms และแก้ปัญหา connection limit ที่ปกติจำกัดไว้แค่ 5,000 ต่อ instance (ที่ OpenAI ใช้)
- ทำการวาง proxy, client และ replicas ไว้ใน region เดียวกันเพื่อลด network latency แทนการเรียกแบบข้าม region (ซึ่งมี overhead/latency สูง)
⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣
📦 Caching
- ป้องกันปัญหา "Cache-miss storms" โดยอนุญาตให้มีเพียง request เดียว ที่ไปดึงข้อมูลจาก Postgres มาเติม cache ส่วน request อื่นๆ ที่ถามหา key เดียวกันจะต้อง "รอ" เพื่อลดโหลดของ database
⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣
📈 การสเกลตัว replicas (read)
- Global Distribution: ปัจจุบันมี read replicas เกือบ 50 ตัวกระจายอยู่ทั่วโลก
- ทาง OpenAI กำลังทดสอบการส่งข้อมูล (WAL) แบบเป็นทอดๆ (cascading) จาก replica สู่ replica เพื่อลดโหลดของ primary และขยายให้ถึง 100+ replicas ในอนาคต (แบบปกตินั้น ตัว primary ต้องส่ง WAL ไปยัง replicas ทุกตัว ทำให้เกิด overhead ในส่วนนี้)
⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣
🛑 Rate limit
- ทำ rate limit ทั้งในระดับ app, connection pooler และระดับ query
- พัฒนาให้ ORM สามารถบล็อค query แบบเจาะจงได้ เพื่อหยุด query ที่กำลังทำให้ระบบช้า (ใช้ query digest)
⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣
🛠️ Schema Management (พวก migration)
- อนุญาตเฉพาะการแก้ schema เช่น อนุญาตเฉพาะการเพิ่มหรือลบ column ที่ไม่ทำให้เกิดการ rewrite ทั้ง table
- การอัพเดท schema ต้องเสร็จภายใน 5 วินาที เท่านั้นเพื่อป้องกันการกระทบกับส่วนอื่น
- การสร้างหรือลบ index แบบ concurrent ยังอนุญาตตามปกติ
- ถ้าต้องการสร้าง table ใหม่ ให้ไปสร้างบน Azure CosmosDB ซึ่งรอบรับ sharding

📌 อธิบายการทำงานและ concept ต่างๆ ของ Terminal เช่น TTY vs PTY, Alternate Screen, ฯลฯ แบบ interactive (ทำมาดีมากๆ)
⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣⁣
(ลิงค์ใน comment)

สวัสดีครับเพื่อนๆ
ขออนุญาตแจ้งเรื่อง build AI Application workshop
ผมขอเลื่อนไปเดือนหน้านะ ยังไม่ได้กำหนดวัน แต่หลังเลือกตั้งละ

เพราะคนเราผิดพลาดกันได้ ระบบจึงสำคัญ
( : 🔵 )

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

แต่กลับทำให้ผมหยุดคิดอยู่แปปนึง เพราะสื่อถึงระบบความปลอดภัยที่พึ่งพามนุษย์นั่นเอง

ภาพนั้นไปเชื่อมกับเรื่องที่ผมเพิ่งพูดไปเมื่อวันเสาร์ที่ผ่านมา ในงาน Northern Tech on the Rock เรื่อง Secret และความปลอดภัยของระบบพอดี เลยคิดว่า นี่น่าจะเป็นโอกาสดีที่จะหยิบเรื่องนั้นมาเล่าต่อในรูปแบบ Blog ละกันนะ

อ่านต่อใน Blog ใน Comment นะ 😍

ใครอยู่เชียงใหม่จดมาแบ่งกันด้วยนะ

ใกล้ถึงงาน Northern Tech on the Rock แล้ว ตื่นเต้นมากๆ ที่ได้ไปพูดงานนี้ และเป็น Workshop ด้วย

"เล่าแนวคิดการออกแบบ จาก Secret สู่การ Deployment" (อนาคตไปถึง Infra ผ่านแนวคิดการออกแบบเดียวกัน

แม้เวลาไม่พอที่จะเล่าให้เห็นภาพโดยละเอียดทั้งหมด แต่อยากให้คนฟังทุกคน เข้าใจว่า เราสามารถจัดการของพวกนี้ด้วย Code ได้

ไม่ว่าจะเป็นภาษาอะไรก็แล้วแต่ ที่สำคัญกว่าก็คือ กระบวนการคิด การออกแบบที่อยากนำเสนอทุกคน

ว่าเราสามารถทำ type safe, secure deploy และจัดการ safe secret

ในงานนี้ ผมจะ Demo ด้วย TypeScript, Azure Container App, Azure KeyVault และ Github Actions แต่ๆๆ อย่าไปยึดติดมากนัก อันนี้ก็แค่ทางผ่านไปยังสิ่งที่ผมต้องการจะสื่อจริงๆ ยังไง ก็มาพบกันให้ได้นะครับ ถ้าใครอยู่ใกล้ๆ เชียงใหม่ เย้ แล้วเจอกันครับ 🤩🥰

รีวิวปีนี้ของน้องมายเพื่อนบ้านเรานี่เอง รีวิวชีวิต SRE ที่หนีจากบนฝั่งไปติดน้ำท่วมด้วยความตั้งใจ ฮ่าๆ หยอกๆนะ

ส่วนของผมคิดอยู่จะทำไหม ขี้เกียจอะ ฮ่าๆ

สวัสดีครับ ทุกคน ใกล้จะจบปีแล้ว ผมอยากจะเขียนรีวิวเกี่ยวกับตัวเองในปี 2025 และการบริหารทีม DevOps ที่มีการเปลี่ยนแปลงทั้งตัวผม และการทำงานภายในทีมเป็นอย่างมาก 🤩

เรียกได้ว่าเป็นการส่งท้ายปีได้ท้าทายมากๆ เพราะผมเองเจอวิกฤตน้ำท่วมครั้งใหญ่ในรอบ หลายสิบปีของหาดใหญ่ เกือบสัปดาห์ จึงทำให้ต้องย้ายที่อยู่ชั่วคราวออกจากหาดใหญ่ และเป็น 1 เดือนกว่าที่ไม่ค่อย Active ในเพจเท่าไหร่เลย กว่าอะไรจะลงตัวก็คงหลังปีใหม่แหละ งานแรกก็คือ Northern Tech on the Rock ที่จะ Fully Comeback จริงๆ ละนะ ส่วน Roadmap ของ เองก็ต้องขยับออกไปพอสมควร

แต่การเจอวิกฤตครั้งนี้ กลับกลายเป็นบทพิสูจน์หลายอย่างที่ผมไม่ได้วางแผนไว้ ไม่ว่าจะเป็นเรื่องระบบการบริหารจัดการ DevOps ที่เคยออกแบบไว้ เรื่อง soft skill และ hard skill ของทีม หรือแม้แต่การทำงานกับระบบ DevOps ที่สามารถส่งมอบ software legacy ไปถึงมือลูกค้าได้อย่างต่อเนื่อง หนึ่งในผลลัพธ์ของการเดินทางนี้ คือการที่บริษัทถูก acquired โดยองค์กรที่ใหญ่ขึ้นมาก policy เปลี่ยน โครงสร้างซับซ้อนขึ้น แต่ทีมยัง “เอาอยู่”

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

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

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

สำหรับปี 2026 น่าจะเป็นอีกบทหนึ่งที่ท้าทายไม่แพ้กัน ผมตั้งใจจะพาทีมไปเจอโจทย์ใหม่ๆ ที่ท้าทายขึ้นไปอีก และต่างจากเดิมพอสมควร ยังไงก็ฝากบทความนี้ไว้ด้วยครับ เผื่อจะเป็นประโยชน์กับใครสักคนในช่วงปลายปีนี้

บล็อกใน comment นะ

น้องนิลมาแชร์ประสบการณ์ชีวิต developer ในช่วงปีนี้ที่กำลังจะผ่านไป

2025 Year In Review | blog.ninprd จะจบปี 2025 แล้ว นิลทำอะไรไปมั่ง มาดูกัน

สวัสดีครับเพื่อนๆ
น้องในทีม Owen เขียน blog เกี่ยวกับการใช้ Tailwind Variants
น้องเขียน blog ครั้งแรก ยังไงติชมกันเข้ามาได้ ถ้าใครรู้ตัวจริงจะตามไปติกันตัวต่อตัวก็ได้ครับ ฮ่า หยอกๆนะ

Tailwind Variants คือ function ที่ช่วยจัดการ กลุ่ม css class ของ css ให้รวมกันเป็นกลุ่มๆ (ส่วนมากก็จะเป็น tailwindcss class อะนะ) เวลาเรียกใช้งานก็ระบุชื่อกลุ่มใน props ได้เลย ทำให้ component เรายืดหยุ่นมากขึ้น แก้ไขง่ายๆในที่เดียว ลดการใช้ conditional กับ css class ใน cn() function ลดการใช้ ternary expression กับ css class ได้ดีเลย

Tailwind Variants รู้จักกับ Tailwind Variants ที่จะช่วยให้เราสร้าง React component ได้ยืดหยุ่นมากขึ้น