Architecture Design บน AWS: ใช้กี่ Availability Zone (AZ) ดี?

พูดถึงการ design architecture ว่า workload ของเราบน AWS ควรจะใช้กี่ availability zone (AZ) ดี? ใช้แค่ 1 AZ ได้มั้ย? หรือถ้าใช้ 2 AZs พอมั้ย? หรือควรไป 3, 4 AZs ดีกว่า

Table of Contents

• สร้าง Baseline กันก่อน
• คำถามคือใช้ 2 AZs พอมั้ย? หรือไป 3, 4 AZs ?
• งั้นยิ่งใช้ AZ เยอะก็ยิ่งดี?
• งั้นใช้ 2 AZs ดีกว่า?
• สรุป

สร้าง Baseline กันก่อน

• Non-critical environment เช่น test, dev หรืออื่น ๆ จะใช้ AZ เดียวก็ได้ (เพื่อเรื่อง cost-effective)
• แต่ production ควรมี 2 AZs ขึ้นไปเพื่อ high availability (HA)

คำถามคือใช้ 2 AZs พอมั้ย? หรือไป 3, 4 AZs?

ถ้าสมมุติ workload เรา run อยู่บน EC2 และต้องใช้ทั้งหมด 4 instances เพื่อ handle workload (ไม่ยอมให้ degraded ด้วย)

ถ้าใช้ 2 Availability Zones (AZs)

การใช้ 2 AZs เรื่อง cost ก็น่าจะดูดี แถม manage ง่าย ดังนั้นถ้า app เรามี minimum ที่ 4 instances แปลว่าเราควรจะต้องมี EC2 ทั้งหมด 4+4 = 8 instances

• AZ A = 4 instances
• AZ B = 4 instances

เพราะเมื่อ AZ ใด ๆ down (สมมุติว่ามีโอกาสไม่เยอะที่จะเกิด outage พร้อมกันมากกว่า 1 AZ) เราก็ยังจะเหลือ 4 instances ไว้ handle workload

แต่ประเด็นคือ cost ครับ เพราะเราต้อง overprovision ไปถึง 2 เท่า!

ถ้าใช้ 3 Availability Zones (AZs)

เอาใหม่ ใน requirement เดียวกันถ้าเราใช้ 3 AZs ก็จะเป็น 2+2+2 = 6 instances

• AZ A = 2 instances
• AZ B = 2 instances
• AZ C = 2 instances

และเมื่อเกิด down ไปหนึ่ง AZ เราก็ยังจะเหลือ EC2 instance ไว้ handle workload ได้โดยที่เรา overprovision น้อยกว่าตอนใช้ 2 AZs (จาก 2 เหลือ 1.5 เท่า)

งั้นยิ่งใช้ AZ เยอะก็ยิ่งดี?

ก็ไม่เชิงเพราะมันขึ้นอยู่กับหลายปัจจัย เพราะการมี AZ เยอะก็จะ…

• Cost สำหรับ VPC endpoint, transit gateway attachment หรือการ run service บางตัว (เช่น AD) จะเพิ่มขึ้นหาก architecture เรามีการใช้สิ่งเหล่านี้
• Cost สำหรับ data transfer ระหว่าง AZ เพิ่มขึ้น ยิ่งถ้า architecture ของเรามี traffic ระหว่าง system to system หลายกลุ่มก้อนด้วยแล้ว
• เพิ่ม admin overhead ในการดูแลหรือจัดการกับ AZ ที่เพิ่มขึ้น

ยกตัวอย่างเรื่อง Data Transfer

จะเห็นว่าระหว่างการใช้ 2 AZs กับ 3 AZs มี data transfer ข้าม AZ ต่างกันพอควร ทีนี้ cost จะต่างมากหรือน้อยขึ้นกับปริมาณ data ระหว่าง service แล้วแหละ

แต่ถ้า zoom in ไปดูระดับ instance และ service B ไม่จำเป็นต้องมี instance เท่า A ก็อาจจะเป็นอัตราส่วนที่น้อยกว่านี้ครับ

งั้นใช้ 2 AZs ดีกว่า?

ก็ไม่แน่เสมอไปอีกครับ เพราะมันขึ้นอยู่กับ requirement อื่นด้วย เช่น บาง workload ที่ critical มาก การมี 3 AZs ขึ้นไปก็เป็นการเพิ่ม fault tolerance เพราะก็ไม่ใช่ว่าจะไม่มีโอกาสที่จะเกิด outage ทีเดียว 2 AZs พร้อมกัน แต่สุดท้ายก็ต้องแลกมาด้วย cost อีกนั่นแหละ

สรุป

ส่วนตัวผมคิดว่าไม่ว่าเรื่องใดก็ไม่มีสิ่งที่ดีที่สุดสำหรับทุกอย่าง

“Engineering is a job of balancing constraints”

ซึ่งข้อจำกัดที่ว่าก็เช่น performance, reliability, cost รวมถึง budget หรือข้อจำกัดอื่น ๆ ซึ่งหน้าที่ของเราคือการ balance สิ่งเหล่านี้โดยการ trade-off หรือยอม compromise บางเรื่องเพื่อให้ได้ผลลัพธ์สุดท้ายที่ตรงกับความต้องการที่สุด

ดังนั้นสรุปไม่ได้ครับผม 555 แต่ผมเชื่อว่าหลายท่านที่อ่านจนถึงตรงนี้ก็คงจะพอเห็นภาพแล้วแหละว่าเราต้องไปดูอะไรบ้างเพื่อตัดสินใจ เช่น ความ critical ของ workload, ดู architecture ว่ามันมี traffic ระหว่าง AZs แค่ไหน, มี resource ที่ต้องใช้เยอะแค่ไหนหากมี AZ ที่มากขึ้น เช่น service ต่าง ๆ, VPC endpoint หรือ transit gateway attachment