Azure Cosmos DB Capacity Planning

โดย อ. บอมกิตติทัศน์เจริญพนาสิทธิ์ | อัปเดต 24 ก. พ. 2026 | อ่าน 15 นาที

Azure Cosmos DB คืออะไร — ทำไมต้องวางแผน Capacity

Azure Cosmos DB เป็น Fully Managed NoSQL Database ของ Microsoft Azure ที่ถูกออกแบบมาให้รองรับแอปพลิเคชันระดับ Global ด้วยคุณสมบัติเด่นคือ Global Distribution ที่สามารถ Replicate ข้อมูลไปยัง Azure Region ใดก็ได้ในโลกด้วยคลิกเดียว, Multi-model API รองรับทั้ง SQL (Core), MongoDB, Cassandra, Gremlin (Graph) และ Table API, การันตี Latency ต่ำกว่า 10 มิลลิวินาทีสำหรับทั้ง Read และ Write ที่ 99th percentile และ SLA 99.999% สำหรับ Multi-region

การวางแผน Capacity เป็นขั้นตอนที่สำคัญที่สุดก่อนนำ Cosmos DB ไปใช้จริงเพราะ Cosmos DB คิดค่าใช้จ่ายตาม Throughput (RU/s) และ Storage ที่ Provision ไว้ถ้าวางแผนต่ำเกินไปแอปพลิเคชันจะถูก Throttle (Rate Limit) ทำให้ช้าหรือ Error ถ้าวางแผนสูงเกินไปจะเสียค่าใช้จ่ายโดยไม่จำเป็นการ Capacity Planning ที่ดีจะช่วยให้ได้ Performance ที่ต้องการในงบประมาณที่เหมาะสม

Request Unit (RU) — หน่วยวัดหลักที่ต้องเข้าใจ

Request Unit (RU) เป็นหน่วยวัดเฉพาะของ Cosmos DB ที่รวมทรัพยากรทุกอย่าง (CPU, IOPS, Memory) เข้าไว้ในตัวเลขเดียวทำให้ง่ายต่อการวางแผนและเปรียบเทียบหน่วยอ้างอิงพื้นฐานคือ 1 RU = การอ่านเอกสาร 1 รายการขนาด 1 KB ด้วย Point Read (ระบุ ID + Partition Key)

การดำเนินการต่างๆใช้ RU ไม่เท่ากันขึ้นอยู่กับหลายปัจจัยได้แก่ขนาดเอกสารยิ่งใหญ่ยิ่งใช้ RU มาก, ประเภทการดำเนินการ Write ใช้มากกว่า Read ประมาณ 5-6 เท่า, ความซับซ้อนของ Query คำสั่ง Query ที่มี Filter, JOIN, Aggregation ใช้ RU มากกว่า Point Read, จำนวน Index Property ที่ถูก Index ยิ่งมากยิ่งใช้ RU มากตอน Write และ Consistency Level ระดับ Strong ใช้ RU มากกว่า Eventual ถึง 2 เท่า

ทุก Response จาก Cosmos DB จะมี Header x-ms-request-charge บอกจำนวน RU ที่ใช้จริงใช้ข้อมูลนี้ในการวัดและปรับแต่ง

Provisioned Throughput vs Serverless vs Autoscale

Cosmos DB มี 3 โหมดการจัดสรร Throughput ให้เลือกแต่ละโหมดเหมาะกับ Workload ต่างกัน

Provisioned Throughput (Manual)

กำหนด RU/s คงที่เช่น 10,000 RU/s ระบบจะรับประกันว่ามี Throughput พร้อมใช้ตลอดเวลาจ่ายรายชั่วโมงตาม RU/s ที่ตั้งไว้เหมาะกับ Workload ที่ Traffic สม่ำเสมอและคาดเดาได้เช่น Backend API ที่มี Request คงที่ข้อดีคือราคาถูกที่สุดต่อ RU เมื่อใช้งานเต็มที่ข้อเสียคือต้องปรับ RU/s ด้วยมือเมื่อ Traffic เปลี่ยน

Autoscale

กำหนด RU/s สูงสุด (เช่น 10,000 RU/s) ระบบจะ Scale ขึ้นลงอัตโนมัติระหว่าง 10% ของค่าสูงสุด (1,000 RU/s) ถึงค่าสูงสุดที่ตั้งจ่ายตาม RU/s สูงสุดที่ใช้จริงในแต่ละชั่วโมงเหมาะกับ Workload ที่มี Traffic ขึ้นลงไม่แน่นอนเช่น E-commerce ที่มี Peak ช่วงโปรโมชันราคาแพงกว่า Manual ประมาณ 50% ที่ RU/s เดียวกันแต่ไม่ต้องกังวลเรื่อง Throttling

Serverless

ไม่ต้องตั้ง RU/s เลยจ่ายตาม RU ที่ใช้จริงเป็นรายครั้งเหมาะกับ Workload ที่มี Traffic ต่ำหรือเป็นช่วงๆเช่น Dev/Test Environment, Batch Job ที่รันเป็นครั้งคราวมีข้อจำกัดคือ Throughput สูงสุด 5,000 RU/s, Storage สูงสุด 1 TB และไม่รองรับ Global Distribution

Partition Key — การตัดสินใจสำคัญที่สุด

Partition Key เป็นการตัดสินใจที่สำคัญที่สุดใน Cosmos DB เพราะเปลี่ยนภายหลังไม่ได้ (ต้อง Migrate ข้อมูลใหม่) Cosmos DB ใช้ Partition Key ในการกระจายข้อมูลไปยัง Physical Partition ต่างๆถ้าเลือก Partition Key ไม่ดีจะเกิด Hot Partition คือข้อมูลกระจุกตัวอยู่ใน Partition เดียวทำให้เกิด Throttling แม้ว่า RU/s รวมจะยังเหลือ

หลักการเลือก Partition Key ที่ดีมี 4 ข้อหลัก

• High Cardinality — ค่าของ Partition Key ต้องมีหลากหลายเช่น userId (ล้านค่า) ดีกว่า country (ไม่กี่ร้อยค่า) หรือ status (2-3 ค่า)
• Even Distribution — ข้อมูลควรกระจายสม่ำเสมอในแต่ละค่าถ้ามี User 1 ล้านคนแต่ User 1 คนมีข้อมูล 50% จะเกิด Hot Partition
• ใช้ใน Query บ่อย — Query ที่ระบุ Partition Key จะอ่านจาก Partition เดียว (Fan-out = 1) ประหยัด RU มากถ้าไม่ระบุ Cosmos DB ต้อง Query ทุก Partition (Cross-partition Query) ใช้ RU สูง
• ขนาด Logical Partition ไม่เกิน 20 GB — ข้อมูลทั้งหมดที่มี Partition Key ค่าเดียวกันต้องไม่เกิน 20 GB

// ตัวอย่าง Partition Key ที่ดีและไม่ดี

// ✅ ดี — สำหรับ E-commerce Orders
{
 "id": "order-001",
 "customerId": "cust-12345", // ← Partition Key
 "items": [...],
 "total": 1500
}

// ❌ ไม่ดี — Hot Partition
{
 "id": "order-001",
 "status": "pending", // ← มีแค่ 3-4 ค่า!
 "items": [...],
 "total": 1500
}

// ✅ ดีมาก — Hierarchical Partition Key (Cosmos DB 2024+)
// ใช้ Partition Key แบบ Composite
Partition Key: /tenantId + /userId
// กระจายดีมาก + Query ได้ทั้ง tenant-level และ user-level

Storage Planning — ประมาณขนาดข้อมูลและ Index

Cosmos DB คิดค่า Storage แยกจาก Throughput ดังนั้นต้องประมาณขนาดข้อมูลทั้งหมดที่จะเก็บ

สูตรคำนวณขนาด Storage คือจำนวนเอกสาร × ขนาดเฉลี่ยต่อเอกสาร × ตัวคูณ Index โดย Default Cosmos DB จะ Index ทุก Property อัตโนมัติซึ่งใช้พื้นที่เพิ่มประมาณ 30-100% ของขนาดข้อมูลจริงสามารถลดขนาด Index ได้โดยกำหนด Indexing Policy ให้ Index เฉพาะ Property ที่ใช้ใน Query

// ตัวอย่าง Indexing Policy ที่ Optimize แล้ว
{
 "indexingMode": "consistent",
 "includedPaths": [
 {"path": "/customerId/?"},
 {"path": "/orderDate/?"},
 {"path": "/status/?"}
 ],
 "excludedPaths": [
 {"path": "/items/*"},
 {"path": "/shippingAddress/*"},
 {"path": "/*"}
 ]
}

อย่าลืมคำนวณ Data Growth Rate ด้วยถ้าข้อมูลเพิ่มขึ้นวันละ 100 MB ภายใน 1 ปีจะเพิ่มขึ้น 36.5 GB ต้องวางแผน Storage ล่วงหน้าอย่างน้อย 1-2 ปีพร้อมกำหนด TTL (Time to Live) สำหรับข้อมูลที่ไม่ต้องเก็บถาวรเช่น Log, Session Data

Consistency Level — ผลกระทบต่อ RU และ Latency

Cosmos DB มี 5 ระดับ Consistency ให้เลือกเรียงจากเข้มงวดสุดไปผ่อนปรนสุด

Session Consistency เป็นค่า Default และเหมาะกับ 90% ของ Use Case เพราะรับประกันว่าผู้ใช้แต่ละคนจะเห็นข้อมูลที่ตัวเองเขียนทันที (Read Your Own Writes) ในขณะที่ใช้ RU เพียง 1x ถ้าเลือก Strong Consistency ค่า RU สำหรับ Read จะเพิ่มเป็น 2 เท่าซึ่งส่งผลต่อค่าใช้จ่ายอย่างมากในระบบที่ Read หนัก

วิธีคำนวณ RU/s ที่ต้องการ

ขั้นตอนการคำนวณ RU/s มีดังนี้

1. ระบุ Operation Pattern — จำนวน Read/Write ต่อวินาทีในช่วง Peak เช่น 1,000 Read/s + 200 Write/s
2. วัด RU ต่อ Operation — ใช้ Data Explorer ใน Azure Portal หรือดูจาก x-ms-request-charge Header
3. คูณ Operation × RU — เช่น (1,000 × 2 RU) + (200 × 10 RU) = 4,000 RU/s
4. บวก Safety Margin 20-30% — เช่น 4,000 × 1.3 = 5,200 RU/s
5. ปัดขึ้นเป็นตัวเลขกลมๆ — เช่น 6,000 RU/s

# Python Script คำนวณ RU/s
def calculate_ru(
 reads_per_sec: int,
 ru_per_read: float,
 writes_per_sec: int,
 ru_per_write: float,
 safety_margin: float = 0.3
) -> int:
 base_ru = (reads_per_sec * ru_per_read) + (writes_per_sec * ru_per_write)
 with_margin = base_ru * (1 + safety_margin)
 # ปัดขึ้นเป็นหลักร้อย
 return int(((with_margin + 99) // 100) * 100)

# ตัวอย่าง E-commerce
ru_needed = calculate_ru(
 reads_per_sec=1000, ru_per_read=3, # Product Page View
 writes_per_sec=200, ru_per_write=10, # Add to Cart / Order
 safety_margin=0.3
)
print(f"Recommended RU/s: {ru_needed}") # 6,500 RU/s

Azure Cosmos DB Capacity Calculator

Microsoft มี Capacity Calculator ออนไลน์ที่ cosmos.azure.com/capacitycalculator ช่วยประมาณ RU/s และค่าใช้จ่ายรายเดือนได้ง่ายโดยไม่ต้องคำนวณมือ

ขั้นตอนการใช้งานคืออัปโหลดตัวอย่างเอกสาร JSON (หรือระบุขนาดเฉลี่ย), กำหนดจำนวน Operation ต่อวินาทีแยกประเภท (Point Read, Query, Write, Delete), ระบุ Indexing Policy, เลือก Consistency Level และจำนวน Region ระบบจะคำนวณ RU/s ที่ต้องการและค่าใช้จ่ายรายเดือนโดยประมาณ

Global Distribution — วางแผน Multi-region

หนึ่งในจุดเด่นสำคัญของ Cosmos DB คือ Global Distribution ที่สามารถ Replicate ข้อมูลไปยัง Azure Region ใดก็ได้ในโลกเมื่อเพิ่ม Region ใหม่ต้องคำนึงถึง 3 เรื่อง

• RU/s เพิ่มตาม Region — ถ้าตั้ง 10,000 RU/s ใน 3 Region ค่าใช้จ่ายคือ 30,000 RU/s (3 เท่า) ยกเว้นใช้ Multi-region Write ที่ต้องเปิดใช้งานแยก
• Write Region vs Read Region — ใน Single-write Mode มี Write Region เดียวและ Read Region หลายตัว Write ถูกส่งไป Write Region เสมอส่วน Read อ่านจาก Region ที่ใกล้ที่สุดใน Multi-write Mode ทุก Region เขียนได้แต่ต้องจัดการ Conflict Resolution
• Conflict Resolution — ใน Multi-write ถ้า 2 Region เขียนเอกสารเดียวกันพร้อมกันจะเกิด Conflict ต้องเลือก Policy เช่น Last Writer Wins (LWW) หรือ Custom Merge Procedure

Monitoring และ Alert — ติดตาม Throughput จริง

หลัง Deploy แล้วต้อง Monitor อย่างสม่ำเสมอ Metrics สำคัญที่ต้องติดตามได้แก่

• Normalized RU Consumption (%) — ถ้าเกิน 70% ต่อเนื่องควรเพิ่ม RU/s ถ้าต่ำกว่า 20% ควรลด
• Throttled Requests (429 Status) — จำนวน Request ที่ถูก Rate Limit ต้องเป็น 0 ในสถานการณ์ปกติ
• Total Request Units — RU ที่ใช้จริงทั้งหมดเทียบกับที่ Provision
• Data Storage — ขนาดข้อมูลและ Index ที่ใช้จริง
• P99 Latency — ความเร็วที่ 99th percentile ควรต่ำกว่า 10ms สำหรับ Point Read
• Physical Partition Distribution — ดูว่า RU กระจายสม่ำเสมอหรือมี Hot Partition

ตั้ง Azure Monitor Alert เมื่อ Normalized RU > 80% หรือ Throttled Requests > 0 เพื่อแจ้งเตือนทันทีก่อนที่ User จะได้รับผลกระทบ

Cost Optimization — 10 วิธีลดค่าใช้จ่าย

1. Reserved Capacity — ซื้อ RU/s ล่วงหน้า 1 ปีลด 20% หรือ 3 ปีลด 65% เหมาะกับ Workload ที่มั่นคง
2. Autoscale แทน Manual — สำหรับ Workload ที่ขึ้นลง Autoscale จะลดค่าใช้จ่ายช่วงที่ Traffic ต่ำ
3. Optimize Partition Key — Partition Key ที่ดีลด Cross-partition Query ลด RU consumption อย่างมาก
4. Tune Indexing Policy — Index เฉพาะ Property ที่ใช้ใน Query ลดทั้ง Storage และ Write RU
5. ใช้ Session Consistency — แทน Strong Consistency ลด Read RU ได้ 50%
6. ใช้ TTL — ลบข้อมูลเก่าอัตโนมัติลด Storage Cost และ RU สำหรับ Index
7. Optimize Query — ใช้ Point Read แทน Query เมื่อรู้ ID, ใช้ Projection เลือกเฉพาะ Field ที่ต้องการ
8. Serverless สำหรับ Dev/Test — ไม่ต้อง Provision RU ประหยัดมากสำหรับ Environment ที่ใช้ไม่บ่อย
9. Composite Index — สร้าง Composite Index สำหรับ Query ที่มี ORDER BY หลาย Field ลด RU ได้หลายเท่า
10. Bulk Operations — ใช้ Bulk Executor Library สำหรับ Import/Export ข้อมูลจำนวนมากประหยัด RU กว่าทำทีละรายการ

ตัวอย่าง Capacity Plan สำหรับ E-commerce

สมมุติเรากำลังวางแผน Cosmos DB สำหรับ E-commerce ที่มี 500,000 สินค้า, 100,000 Active Users ต่อวัน, Peak Traffic 2,000 Request/s

แนะนำใช้ Autoscale Max 20,000 RU/s เพื่อรองรับ Flash Sale ที่ Traffic อาจพุ่ง 3-5 เท่าช่วงปกติระบบจะ Scale ลงมาที่ 2,000-5,000 RU/s ลดค่าใช้จ่ายช่วง Off-peak

Common Mistakes ที่ต้องหลีกเลี่ยง

• เลือก Partition Key ผิด — ใช้ /status หรือ /country ที่มี Cardinality ต่ำทำให้เกิด Hot Partition
• ไม่ตั้ง Indexing Policy — ใช้ Default Index ทุก Property ทำให้ Write แพงเกินจำเป็น
• ใช้ Strong Consistency ทุกที่ — ส่วนใหญ่ Session Consistency เพียงพอแล้ว Strong Consistency เพิ่มค่า RU 2 เท่า
• ไม่ Monitor Throttling — ปล่อยให้ 429 Error เกิดขึ้นโดยไม่รู้ตัวผู้ใช้ได้รับ Error แต่ไม่มีใคร Alert
• ไม่ใช้ TTL — ข้อมูลสะสมไม่หยุด Storage Cost เพิ่มขึ้นเรื่อยๆ
• ใช้ Cross-partition Query บ่อย — Query ที่ไม่ระบุ Partition Key ต้อง Fan-out ทุก Partition ใช้ RU สูงมาก

Best Practices สรุปรวม

• เริ่มจาก Capacity Calculator — ใช้เครื่องมือของ Microsoft คำนวณก่อน Deploy
• ทดสอบด้วย Load Test — ใช้ Azure Load Testing หรือ k6 จำลอง Traffic จริงก่อน Go-live
• Monitor ตั้งแต่วันแรก — ตั้ง Alert สำหรับ Throttling และ RU Consumption
• Review ทุกเดือน — วิเคราะห์ RU Usage จริงเทียบกับ Provisioned แล้วปรับให้เหมาะสม
• ใช้ Hierarchical Partition Key — ฟีเจอร์ใหม่ที่ช่วยลด Hot Partition สำหรับ Multi-tenant Application
• Design for Scale — คิดล่วงหน้าว่า Data Model จะ Scale อย่างไรเมื่อข้อมูลเพิ่ม 10x หรือ 100x

Q: Azure Cosmos DB คืออะไร

Fully Managed NoSQL Database ของ Microsoft Azure รองรับ Global Distribution, Multi-model API และการันตี Latency ต่ำกว่า 10ms ที่ 99th percentile