Cloud ล่มได้ และการทำให้ล่มยากนั้นมีต้นทุนสูง

ต่อเนื่องจากเอนทรีก่อนหน้าที่ผมกล่าวถึง ลักษณะ 3 ประการของ cloud computing  อันได้แก่ อนิจจัง ทุกขัง และอนัตตา เรื่องดังกล่าวสามารถเขียนได้ยาวเหยียดจริงๆนะ และเราจะเห็นว่าข่าวค(ล)าว(ด์)ล่มจะร้อนต่อเนื่องไปอีกช่วงหนึ่ง ดั่งที่ผมเห็นหลายคอมเมนต์ใน blognone หรือแม้แต่ twitter ที่สรุปได้ใจความว่า “cloud computing ล่มได้” ซึ่งมันเป็นความจริงครับว่า cloud ล่มได้ และเป็นการโฆษณาเกินจริงหากกล่าวว่า “cloud เทพ cloud สุดยอด cloud ไม่มีวันล่ม”

ผมเองไปค้นหาข้อความเก่าๆของผมใน blognone ว่าผมเคยพูดอะไรเกี่ยวกับ “การล่มของ cloud computing หรือเปล่า?” ก็ไปเจอ ข่าวชื่อ อเมซอนเตรียมขยายฐานบริการ AWS ไปยังภูมิภาคเอเชีย โดยผมได้กล่าวว่า อเมซอนเขามีบริการกลุ่มเมฆที่ชื่อ Amazon EC2 และเขาก็มีศูนย์ข้อมูล (datacentre) ตั้งในสถานที่ต่างๆ โดยปัจจุบัน อเมซอนแบ่งสถานที่ตั้งของศูนย์ข้อมูลออกเป็น 5 ภูมิภาค (region) ด้วยกัน คือ US-West, US-East, Europe (Ireland), Singapore, และก็ Japan นอกจากนี้ในแต่ละภูมิภาคก็ยังแบ่งได้หลายโซนหรือที่เรียกว่า availability zone โดยแต่ละโซนก็เปรียบเสมือนศูนย์ข้อมูล 1 แห่ง โดยย่อหน้าเต็มที่เกี่ยวข้องที่ผมเขียนในข่าวนั้นกล่าวไว้ดังนี้

Availability Zone เปรียบเสมือนศูนย์ข้อมูลที่ให้บริการทรัพยากรคอมพิวเตอร์ ถ้าหากว่า Availability Zone แห่งหนึ่งมีปัญหา (เช่น โดนอุกกาบาตถล่ม) จะไม่ส่งผลให้ Availability Zone อื่นๆมีปัญหาตามไปด้วย ทั้งนี้ ในแต่ละทวีป (หรือ Region) ประกอบไปด้วย Availability Zone หลายแห่ง โดยราคาของบริการ AWS ในทวีปอเมริกาถูกกว่าทวีปยุโรปเพียงเล็กน้อย แต่ว่าอเมซอนยังไม่เปิดเผยราคาของบริการ AWS ในทวีปเอเชีย

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

อย่างไรก็ดี cloud computing มันล่มได้ และ EC2 ก็ล่มได้แน่นอน! จากตัวอย่างข้างต้น แม้โซน A มันล่มที่เดียวแต่โซนอื่นๆยังรอดก็แปลว่ามันล่มแล้ว เพราะเซิร์ฟเวอร์(เสมือน)หรือ EC2 instance ที่โฮสต์ที่โซน A ย่อมทำงานอย่างปกติไม่ได้นั่นเอง หรือกล่าวได้ว่าลูกค้าจำนวนหนึ่งที่ใช้บริการที่โซน A กำลังประสบปัญหา แม้จะมีโซนอื่นๆที่ให้บริการได้ตามปกติ (เช่น โซน B) แต่หากว่า ลูกค้าที่กำลังเจอปัญหาที่โซน A ไม่เคยมีแผนสำรองในการทำสำเนาการโฮสต์เซิร์ฟเวอร์ไว้ในโซนอื่นๆหรือภูมิภาคอื่นๆเลย จะพบได้ว่า availability zone ของ EC2 ไม่ได้แก้ปัญหาให้กับลูกค้ากลุ่มนี้ได้เลย … โอเค ผมขอสารยายถึงอดีตที่เกี่ยวข้องกับ availability zone หน่อยนะ (แต่อาจจะไม่นิดหน่อย)

ระบบที่ทนต่อสงครามนิวเคลียร์?

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

โรงไฟฟ้าเขาทำ high availability นะ

แม้เรื่องระบบที่ทนทานต่อนิวเคลียร์จะเป็นที่เข้าใจผิด แต่เรื่อง high availability เป็นหัวข้อวิจัยและพัฒนากันมาต่อเนื่องในหลายๆฟิลด์ เช่น การสร้างเครือข่ายของโรงงานไฟฟ้าหรือ power grid เครือข่ายดังกล่าวมีการเชื่อมโรงงานไฟฟ้าหลายๆโรงงานเข้าด้วยกันด้วยสายไฟหลายเส้น ประโยชน์ที่ได้มีมากมาย โดยรวมคือ เกือบทุกท้องถิ่นทุกพื้นที่มีไฟฟ้าใช้ตลอดเวลา บางพื้นที่อาจจะใช้ไฟเยอะแตกต่างกันไปจนกระทั่งโรงไฟฟ้าใกล้เคียงผลิตไฟให้ไม่ทัน แต่ระบบ power grid จะสามารถขนส่งไฟฟ้าไปเติมเต็มให้พื้นที่ที่ขาดแคลนได้ และในประเทศที่มี power grid ที่มีประสิทธิภาพ เขาสามารถแก้ปัญหาโรงไฟฟ้าทำงานขัดข้องหรือล่มได้ (เช่น โรงไฟฟ้าระเบิด) ดังนั้น โรงไฟฟ้าอื่นๆก็ยังจ่ายไฟไปให้พื้นที่ที่ประสบปัญหาได้ (ถ้ายังเหลือสายไฟดีๆและหม้อไฟเพียงพออยู่) โอเค แม้ไฟฟ้าจะจ่ายไปให้ไม่ทันที มีไฟกระพริบหรือดับบ้างครั้งคราว (นอกจากนี้ การจ่ายไฟจากสถานที่ห่างไกลมากๆจะมีการสูญเสียของไฟฟ้าหรือ loss rate) แต่โดยรวมแล้ว ระบบดังกล่าวก็มีความคงทนสูงกว่าระบบที่ไม่ได้เชื่อมโยงเป็นเครือข่ายแบบ power grid

เราจึงกล่าวได้ว่า ระบบที่มี high availability ไม่ได้หมายถึง ระบบที่ไม่มีวันล่ม หากแต่ล่มได้แต่ล่มอย่างพองาม (คือ ล่มไม่นานมากเกินไป)

High Availability ใน EC2 กับต้นทุนที่เพิ่มขึ้น

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

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

SLA คือสิ่งที่ลูกค้าต้องตระหนัก และต้องรับผิดชอบในส่วนที่ล่มด้วยตนเอง อาทิเช่น ถ้า 8.8 ชั่วโมงหรือน้อยกว่านั้นที่กล่าวไว้ก่อนหน้านี้ เป็นสิ่งที่ลูกค้ายอมไม่ได้ ลูกค้าก็ต้องหาวิธีอื่นๆมาป้องกันความเสียหายด้วยตนเอง เป็นต้น

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

การที่ระบบล่มแบบนานๆหากเป็นความเสี่ยงต่อลูกค้า (เช่น เป็นระบบไอทีที่กำหนดความเป็นความตายของบริษัท) ลูกค้าจะต้องเพิ่มสำเนาหรือเพิ่มค่าใช้จ่ายเพื่อความอยู่รอดของระบบ หรือไม่ก็ใช้ in-house system อย่าง private cloud นั่นคือ พัฒนา cloud สำหรับใช้สอยในบริษัทของตนเอง บริษัทได้ประโยชน์หลายอย่างจาก private cloud เช่น ควบคุมระบบได้ แบ่งสัดส่วนการใช้งานระบบได้ตามต้องการ และได้ระบบเครือข่ายคอมพิวเตอร์ภายในบริษัทที่ปลอดภัยสูงและไม่ต้องแย่งแบนด์วิธกับองค์กรอื่น เป็นต้น โดยต้องลงทุนดูแลระบบด้วยวิธีของตนเอง ซึ่งความเครียดและความเสี่ยงในเรื่องการรักษาความอยู่รอดของระบบมีไม่มากก็น้อยกว่า cloud แบบ public (เช่น EC2) และบอกได้เลยว่าจะ public หรือ private cloud ก็ล่มได้นะ เพียงแต่ private cloud นั้น ถ้าล่มขึ้นมา ก็ล่มเอง มีอิสระในการแก้ไข แก้เอง รับผิดชอบเอง (อาจจะรวมถึง โทษตัวเองฝ่ายเดียว) และ(อาจจะ)ชดใช้ค่าเสียหายด้วยตนเองฝ่ายเดียว

ผมขอสรุปด้วยคอมเมนต์ของสมาชิก blognone นั่นคือ คุณ  bongikairu เป็นคอมเมนต์ที่สั้นได้ใจความ คือ คุณ bongikairu ได้ตอบไว้ในข่าวเกี่ยวกับระบบ cloud ของไมโครซอฟท์ล่มไว้ว่า ราคาของความเสี่ยงที่ลดลงมันเพิ่มขึ้นเป็นกราฟ exponential (ต้นฉบับของคอมเมนต์) หรือพูดง่ายๆ คือ ยิ่งต้องการให้ความเสี่ยงลดลง หรือต้องการความอยู่รอดของระบบที่เพิ่มขึ้น เราจะต้องจ่ายเงินมากขึ้นตามไปด้วยนั่นเอง

3 thoughts on “Cloud ล่มได้ และการทำให้ล่มยากนั้นมีต้นทุนสูง

  1. poper says:

    สวัสดีครับ ผมเป็นคนนึงที่สนใจศึกษาเรื่อง cloud ครับ และอยากพัฒนาระบบขึ้นมาใช้แบบ Saas ไม่ทราบว่าผมสามารถขอคำแนะนำจากคุณ javaboom ได้หรือไม่ครับ รบกวน reply email address ผมด้วยนะครับ หากสามารถให้คำปรึกษาได้

    ขอบคุณล่วงหน้าครับ

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s