Spreading Your Risk (การกระจายความเสี่ยงของคุณ)

วิธีหนึ่งในการ scale เพื่อความยืดหยุ่นทนทานคือการมั่นใจว่าคุณไม่ได้ใส่ไข่ทั้งหมดไว้ในตะกร้าใบเดียว ตัวอย่างง่ายๆ ของสิ่งนี้คือการมั่นใจว่าคุณไม่ได้มีบริการหลายตัวอยู่บน host เดียว ที่ซึ่ง outage หนึ่งครั้งจะส่งผลกระทบต่อบริการหลายตัว แต่มาลองพิจารณาว่า host หมายถึงอะไร ในสถานการณ์ส่วนใหญ่ทุกวันนี้ "host" จริงๆ แล้วเป็นแนวคิดเสมือน (virtual) ดังนั้นถ้าผมมีบริการทั้งหมดของผมอยู่บน host ต่างกัน แต่ host เหล่านั้นทั้งหมดเป็น virtual host ที่รันบนกล่องกายภาพเดียวกันล่ะ? ถ้ากล่องนั้นล่ม ผมอาจสูญเสียบริการหลายตัว แพลตฟอร์ม virtualization บางตัวช่วยให้คุณมั่นใจได้ว่า host ของคุณกระจายอยู่บนกล่องกายภาพที่แตกต่างกันหลายกล่อง เพื่อลดโอกาสที่สิ่งนี้จะเกิดขึ้น

สำหรับแพลตฟอร์ม virtualization ภายใน เป็นเรื่องปกติที่ root partition ของ virtual machine จะถูก map ไปยัง SAN (storage area network) เดียว ถ้า SAN นั้นล่ม มันสามารถทำให้ VM ที่เชื่อมต่ออยู่ทั้งหมดล่มไปด้วย SAN นั้นใหญ่ แพง และถูกออกแบบมาไม่ให้ล้มเหลว ถึงอย่างนั้น ผมก็เคยเจอ SAN ขนาดใหญ่ราคาแพงล้มเหลวกับผมอย่างน้อยสองครั้งในสิบปีที่ผ่านมา และแต่ละครั้งผลลัพธ์ก็ค่อนข้างร้ายแรง

รูปแบบทั่วไปอีกอย่างของการแยกเพื่อลดความล้มเหลวคือการมั่นใจว่าบริการทั้งหมดของคุณไม่ได้รันอยู่ใน rack เดียวใน data center หรือบริการของคุณกระจายอยู่มากกว่าหนึ่ง data center ถ้าคุณใช้ผู้ให้บริการพื้นฐาน สิ่งสำคัญคือต้องรู้ว่ามีการเสนอ SLA หรือไม่ และวางแผนตามนั้น ถ้าคุณต้องมั่นใจว่าบริการของคุณจะล่มได้ไม่เกินสี่ชั่วโมงต่อไตรมาส แต่ผู้ให้บริการ hosting ของคุณรับประกันได้แค่ downtime สูงสุดแปดชั่วโมงต่อไตรมาส คุณต้องเปลี่ยน SLA หรือหาทางออกอื่น

AWS ตัวอย่าง ถูกแบ่งออกเป็น region ซึ่งคุณสามารถคิดว่าเป็นคลาวด์ที่แยกจากกัน แต่ละ region ถูกแบ่งย่อยเป็น availability zone สองแห่งขึ้นไป ตามที่เราพูดถึงก่อนหน้านี้ availability zone เหล่านี้เทียบเท่ากับ data center ของ AWS สิ่งสำคัญคือต้องมีบริการกระจายอยู่หลาย availability zone เพราะ AWS ไม่ได้เสนอการรับประกันใดๆ เกี่ยวกับความพร้อมใช้งานของ node เดี่ยว หรือแม้แต่ทั้ง availability zone สำหรับบริการ compute AWS เสนอ uptime แค่ 99.95% ในช่วงเวลารายเดือนของ region โดยรวมเท่านั้น ดังนั้นคุณจะต้องกระจาย workload ของคุณข้าม availability zone หลายแห่งภายใน region เดียว สำหรับบางคน สิ่งนี้ยังไม่เพียงพอ พวกเขาจึงรันบริการของตัวเองข้ามหลาย region ด้วย

ควรสังเกตด้วยว่า เนื่องจากผู้ให้บริการมอบ SLA "รับประกัน" มาให้ พวกเขามักจำกัดความรับผิดชอบของตัวเอง! ถ้าการที่พวกเขาพลาดเป้าหมายทำให้คุณสูญเสียลูกค้าและเงินจำนวนมาก คุณอาจต้องค้นหาในสัญญาว่าคุณสามารถเรียกร้องอะไรกลับคืนมาได้บ้าง ดังนั้น ผมขอแนะนำอย่างยิ่งให้คุณเข้าใจผลกระทบจากการที่ผู้ให้บริการทำผิดพันธะสัญญาต่อคุณ และหาทางออกว่าคุณต้องมีแผน B (หรือ C) สำรองไว้หรือไม่ ลูกค้าหลายรายที่ผมเคยทำงานด้วยมีแพลตฟอร์ม disaster recovery hosting กับผู้ให้บริการที่แตกต่างกัน เพื่อให้แน่ใจว่าพวกเขาไม่เปราะบางเกินไปกับความผิดพลาดของบริษัทเดียว