เมื่อ Cloud ล่ม อย่าลืมนึกถึง SLA

ผมได้เล่าถึงคุณลักษณะ 3 ประการของ cloud computing ไปแล้วว่า cloud computing นั้นล่มได้ และการจะทำให้ cloud นั้นล่มยากนั้นมีต้นทุนสูง ถึงแม้ว่าโดยพื้นฐานแล้ว cloud  นั้นออกแบบมาให้รองรับกับโหลดของระบบมีที่มหาศาลได้อย่างยืดหยุ่นก็ตามแต่ cloud ก็สามารถล่มได้เป็นครั้งคราว

cloud ล่มนั้นเป็นเรื่องจริงและเป็นที่ตระหนักของผู้ให้บริการ รวมไปถึงลูกค้าด้วย (แม้จะไม่ทุกคนก็ตาม) ท่านจะเห็นได้ว่า ผู้ให้บริการส่วนใหญ่ไม่ได้รับประกันว่า ผู้ให้บริการสามารถบริการ cloud ให้ทำงานได้ปกติ 100% ตลอดเวลา (ถึงแม้จะประกันไว้ 100% ก็ใช่ว่าจะไม่ล่ม!) โดยตัวเลข % นี้ บางทีเราก็เรียกแบบบ้านๆว่าเป็น “ร้อยละของเวลา uptime ที่ระบบทำงานปกติ” (หรือ % uptime)  ส่วนใหญ่ผู้ให้บริการ cloud จะกำหนด% uptime ที่รับประกันอย่างน้อยประกอบไปด้วยเลข 9 สามตัว หรือ 99.9% โดย % uptime บ่งบอกถึงระดับคุณภาพการให้บริการ และสามารถสร้างความไว้วางใจให้กับลูกค้าได้ โดยบอกเป็นนัยว่าผู้ให้บริการจะรักษาคุณภาพบริการไว้ได้มากน้อยเพียงใด

ในเอนทรีนี้ ผมจะพูดถึง % uptime ซึ่งเป็นเรื่องสำคัญที่ลูกค้าบริการ cloud และบริการที่เกี่ยวข้องจำเป็นต้องทราบ โดย %uptime นี้จะถูกระบุไว้ในเอกสาร “ข้อตกลงระดับบริการ” (service level agreement) หรือเรียกสั้นๆว่า SLA ทั้งนี้เอกสาร SLA เป็นเอกสารที่กล่าวถึง รายละเอียดของการให้บริการ cloud ว่าผู้ให้บริการนั้นประกันบริการที่ครอบคลุมและไม่ครอบคลุมเรื่องอะไรบ้าง รวมถึงจะชดเชยค่าเสียหายให้ลูกค้าอย่างไรหากรักษาคุณภาพของบริการไม่ได้

โครงสร้างของเอกสาร SLA

ถ้าท่านได้อ่านเนื้อหาในเอกสาร SLA  ท่านจะพบว่า ผู้ให้บริการได้ยอมรับเป็นนัยแล้วว่า ระบบ cloud ของตนไม่ได้สมบูรณ์ 100% อย่างไรก็ดี ผู้ให้บริการ cloud ต้องสร้างความมั่นใจกับลูกค้าให้ได้ว่า ผู้ให้บริการสามารถให้บริการ cloud แก่ลูกค้าได้ท่ามกลาง “ความไม่สมบูรณ์” นั้นอย่างไร

เพื่อความง่ายในการอธิบายเรื่อง SLA ผมแนะนำให้ท่านผู้อ่านเปิดเอกสาร SLA ของ Amazon EC2 ประกอบ ซึ่งเป็นเอกสาร SLA ที่ออกเมื่อวันที่ 23 ตุลาคม ค.ศ. 2008

หมายเหตุ เอกสาร SLA อาจมีการเปลี่ยนแปลงได้โดยผู้ให้บริการ (ในที่นี้คือ Amazon) แต่ผมคิดว่าโครงสร้างของเอกสารไม่น่าจะเปลี่ยนไปมาก

ปกติในธุรกิจ cloud computing เอกสาร SLA ของผู้ให้บริการมีส่วนที่สำคัญ ได้แก่ คำมั่นสัญญาว่ารับประกันบริการตัวไหนบ้าง และประกันระดับไหน  (ส่วนใหญ่ระดับบริการระบุเป็น % uptime ของทั้งปี),  นิยามของคำศัพท์ที่ใช้ในเอกสาร SLA, การชดเชยค่าเสียหายแก่ลูกค้า, วิธีชดเชยค่าเสียหาย, และข้อยกเว้น เป็นต้น

ยกตัวอย่างโครงสร้างที่ปรากฎในเอกสาร SLA ของ EC2 อย่างคร่าวๆ นั่นคือ

• บริการที่ Amazon สัญญาว่าจะดูแลคุณภาพบริการ ในที่นี้ คือ Amazon EC2 และประกัน %uptime ที่ 99.95% ของระยะเวลาบริการในรอบ 1  ปี หรือกล่าวได้ว่า บริการ Amazon EC2 จะถูกดูแลโดย Amazon ให้ทำงานเป็นปกติ(หรือไม่ล่ม)ได้ไม่ต่ำกว่า 99.95% ของระยะเวลาบริการในรอบ 1 ปี  หรือล่มได้น้อยกว่า 0.05%​ ของระยะเวลาบริการในรอบ 1 ปี  (คิดจาก 100% – 99.95% = 0.05%) ซึ่งเราเรียกเวลาล่มว่า downtime
• คำศัพท์ที่เอกสารนิยามไว้ ได้แก่ Service Year คือ ช่วงเวลา 365 วันที่เกิดขึ้นก่อนวันที่ลูกค้าเคลมประกัน, Region Unavailable คือ การกล่าวว่า Amazon EC2 ล่ม หมายถึง การมีโซนที่ลูกค้าได้เข้าไปใช้บริการให้บริการไม่ได้หรือโซนดังกล่าวล่ม (นั่นคือ Amazon EC2 ในโซนนั้นเกิด downtime เกิน 0.05%), และ Service Credit หมายถึง เครดิตที่นับเป็นหน่วยดอลลาร์ที่จะชดเชยให้ลูกค้าที่สามารถเคลมได้เมื่อเจอปัญหา Region Unavailable เป็นต้น
• การชดเชยค่าเสียหายของ Amazon EC2 คือ เมื่อลูกค้าประสบ uptime ต่ำกว่า 99.95% หรือ downtime สูงกว่า 0.05% แล้วล่ะก็ ลูกค้าสามารถเคลม Service Credit ได้จำนวน 10% ของค่าบริการของบิลในเดือนรอบที่ประสบปัญหา
• Amazon EC2 ระบุถึงขั้นตอนการเคลม Service Credit เมื่อประสบปัญหาว่า ลูกค้าต้องเขียนอีเมลไปที่  aws-sla-request@amazon.com (คงเป็นแผนกรับเรื่องเคลม) พร้อมทั้งระบุข้อมูลที่สำคัญ ได้แก่ หมายเลขบัญชี (นั่นคือ บัญชีของบริการ AWS), วันเวลาที่เจอ Region Unavailable, บันทึก (log) ของปัญหาที่พบเจอ, และต้องส่งเมลดังกล่าวภายใน 30 วันทำการนับจากวันที่เจอปัญหา เป็นต้น หลังจากนั้น Amazon จะใช้เวลาในการตรวจสอบ และถ้าข้อมูลที่ส่งมาถูกต้อง ลูกค้าก็จะได้รับการชดเชยเป็น Service Credit ในรอบบิลเดือนถัดไป
• Amazon EC2 ระบุข้อยกเว้นหรือการเคลมเป็นโมฆะไว้ด้วย เช่น ลูกค้าละเมิดข้อตกลงในเอกสาร AWS Agreement ข้อ 6.1 หรือฝ่าฝืนกฎหมายรัฐ เป็นต้น

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

เวลาล่มของประกัน 99.9% uptime นี่เยอะไหม?

เรามาทำความเข้าใจกันเถอะว่า “ประกัน 99.9% uptime” คำนวณออกมาเป็นเวลาในรอบหนึ่งปีได้อย่างไร ผมขอเขียนออกมาเป็นสูตรง่ายๆ คือ

ระยะเวลา uptime ต่อปีที่ผู้ให้บริการรับประกัน (หน่วยชั่วโมง)

เวลา uptime ในรอบปี = %uptime x 365 วัน x 24 ชั่วโมง

ระยะเวลา donwtime ต่อปีที่ผู้ให้บริการรับประกัน  (หน่วยชั่วโมง)

เวลา downtime ในรอบปี = (100 – %uptime) x 365 วัน x 24 ชั่วโมง

ดังนั้น 99.9% uptime จึงคำนวณได้ระยะเวลาประกันตามนี้

• มีเวลา uptime เท่ากับ (99.9/100) x 365 x 24 = 8,751.24 ชั่วโมง (หมายเหตุ: ที่ 99.9 หาร 100 เพราะมันเป็น %)
• หรือมีเวลา downtime เท่ากับ [(100-99.9)/100] x 365 x 24 = 8.76 ชั่วโมง หรือคิดจากจำนวนชั่วโมงทั้งหมดในหนึ่งปี (คิดเป็น 365 x 24 = 8,760 ชั่วโมง) แล้วเอาไปลบกับเวลา uptime แล้วได้ 8,760 – 8,751.24 = 8.76 ชั่วโมง

จากเวลาที่ผู้ให้บริการประกันที่ 99.9% uptime หมายความว่า ในมุมของผู้ให้บริการนั้น ผู้ให้บริการจะดูแลระบบให้ทำงานเป็นปกติ(หรือไม่ล่ม)อย่างน้อยที่สุดคือ 8,751.24 ชั่วโมงในหนึ่งปี (= มากกว่า 8,751.24) หรืออีกนัยหนึ่งคือ ระบบล่มได้สูงสุด 8.76 ชั่วโมงต่อปี (= น้อยกว่า 8.76) อย่างไรก็ดี ตัวเลขดังกล่าวไม่ได้บ่งบอกว่า ผู้ให้บริการจะทำให้ระบบอยู่ได้เพียง 8,751.24 ชั่วโมงในหนึ่งปี หรือในหนึ่งปีระบบจะล่ม 8.76 ชั่วโมง หากแต่หมายความว่า ถ้าระบบล่มเกินกว่า 8.76 ชั่งโมง ผู้ให้บริการจะต้องชดเชยค่าเสียหาย หรืออย่างน้อยก็สามารถบ่งบอกถึงคุณภาพของระบบได้ว่าอยู่รอดได้ยาวนานเท่าไหร่

ยิ่งถ้า %uptime มีค่าเข้าใกล้ 100% เท่าไหร่ ก็เหมือนบอกเป็นนัยว่าระบบจะถูกดูแลโดยผู้ให้บริการได้มากขึ้นเท่านั้น โดยเฉพาะถ้ามีเลข 9 ใน %uptime มากๆก็ยิ่งน่าเชื่อถือ เช่น 9 ห้าตัว (five nines) หรือ 99.999% uptime หมายถึง ในหนึ่งปี ระบบล่มได้สูงสุดเพียง 0.0876 ชั่วโมงหรือ 5.256 นาที (คิดจาก 0.0876 ชั่วโมง x 60 นาที = 5.256 นาที)

ปกติผู้ให้บริการชดเชยค่าเสียหายให้กับลูกค้าในกรณีที่ระบบเกิด downtime  เกินกว่าเวลาที่สัญญาไว้ เช่น SLA ของ Amazon EC2 กำหนด %uptime ไว้ที่ 99.95% หรือในหนึ่งปีล่มได้สูงสุด 4.38 ชั่วโมง หากล่มเกินกว่านี้ Amazon ต้องชดเชย Service Credit คิดเป็น 10% ของค่าบริการในรอบบิลเดือนที่เกิดเหตุ  เป็นต้น

ผู้ให้บริการ cloud บางเจ้าก็ไม่ได้ใช้ %uptime ของเวลาหนึ่งปี หากเป็นรายเดือน อย่างเช่น บริการ Google App Engine ของอากู๋ Google  เป็นต้น ผมยึด SLA ปัจจุบันของ App Engine ซึ่งยังเป็นฉบับร่าง (ผมยึดตามวันที่เขียนเอนทรี คือ 27 พ.ค. นี้)  อากู๋รับประกัน %uptime ที่ 99.95% ของระยะเวลารอบบิลรายเดือน ดังนั้น การคำนวณจะแตกต่างไปจากสูตรด้านบนนิดหน่อย โดย downtime ต่อเดือน (หน่วยนาที) คำนวณจาก

เวลา downtime ในรอบเดือน = (100 – %uptime) x 30 วัน x 24 ชั่วโมง x 60 นาที

กรณีของ App Engine ที่มี 99.95% จึงรับประกัน downtime สูงสุดที่ 21.6 นาทีในหนึ่งเดือน นอกจากนี้ อากู๋ยังใจกว้างตรงที่ อากู๋ชดเชย Service Credit เริ่มต้นที่ 10% ของค่าบริการรอบบิลในเดือนที่เกิดเหตุ แต่ชดเชยให้มากขึ้นถ้า downtime เพิ่มขึ้นจาก 21.6 นาทีจนถึงช่วงหนึ่ง เช่น ถ้าอากู๋ประกัน uptime ได้ไม่ถึง 90% แล้วล่ะก็ อากู๋ให้ลูกค้าใช้ App Engine ฟรีสำหรับเดือนนั้นเลย เป็นต้น แต่!!!! ท่านผู้อ่านอย่าเพิ่งดีใจซูฮกไป เพราะอากู๋ระบุใน SLA ของ App Engine ว่า นี่เป็นแค่ฉบับร่าง และไม่ได้ถูกนำไปใช้กับบริการใดๆ ดังนั้น App Engine ที่ใช้กันจึงมีแค่ SLA แบบคาดหวัง แต่ยังไม่ได้เริ่มใช้จริง

อย่างไรก็ดี อากู๋เขาประกัน %uptime ของ Google Apps (ไม่ใช่ App Engine นะ) เริ่มต้นที่ 99.9% uptime ของรอบบิลรายเดือน หรือในหนึ่งเดือนล่มได้สูงสุด 43.2 นาที โดย Service Credit ของ Google Apps จะชดเชยเป็นจำนวนวันที่ให้ลูกค้าใช้ Google Apps ฟรี ซึ่งชดเชยเริ่มต้นที่ 3 วัน

ใน wikipedia ได้คำนวณเวลา downtime ของ %uptime แบบต่างๆไว้ด้วย

ประกัน 100% uptime ไม่ใช่ “ไม่มีวันล่ม”

แม้ว่าเอกสาร SLA ระบุว่าประกัน 100% uptime ก็ไม่ได้หมายถึง cloud ไม่มีวันล่มนะ ย้ำอีกครั้งว่า ประกัน uptime คือ ผู้ให้บริการเขาพยายามรักษาคุณภาพบริการ cloud ให้เป็นปกติให้ได้สูงสุดตามที่สัญญาไว้ (เพราะเขาก็คงไม่อยากชดเชยค่าเสียหายบ่อยๆและเสียฐานลูกค้า) ดังนั้น 100% uptime เป็นการประกันที่สูงมาก ถ้าผมเป็นผู้ให้บริการ ผมก็ไม่กล้าประกัน 100% uptime หรอกนะ แต่!!! … ใช่ว่าในโลกนี้ไม่มีใครกล้ารับประกัน 100% uptime ดูตัวอย่างได้จากผู้ให้บริการ cloud ในนามว่า GOGRID

พี่โก๋ GOGRID เขาจ๊าบมาก เขาจดทะเบียนเครื่องหมายการค้าคำว่า 10,000% Guaranteed(TM) SLA แค่ผมได้ยินก็ขนลุกซู่แล้ว โดยความหมายของประกันดังกล่าว จริงๆแล้วคือ ประกัน 100% uptime ในรอบเดือน และคืน Service Credit ให้เลย 100 เท่า (ป๊าด!!) ตัวอย่างเช่น ถ้าระบบล่มไป 7 ชั่วโมง ก็จะคืน Service Credit ให้ 700 ชั่วโมงเลยแหละ แต่ถ้าล่ม 15 นาที ก็คืนให้ 1,500 นาที หรือ 25 ชั่วโมง เป็นต้น

สรุป

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