KEYNOTE: Use Case: A Close Look at OpenStack Ocata as Public Cloud Part I

NIPA Technology สร้าง data center ตั้งแต่ปี ค.ศ. 2010 และเริ่มให้บริการคลาวด์ (cloud computing) ครั้งแรกเมื่อปี ค.ศ. 2017 โดยโฟกัสเกี่ยวกับคลาวด์ในช่วงปี ค.ศ. 2012 เป็นต้นมา งานเขียนฉบับนี้จะเป็นการเล่าถึงการเดินทางของ NIPA Cloud ว่าเหตุใดจึงวิจัยและพัฒนา (research & development: R&D) เป็นระยะเวลานาน ทำไมจึงใช้เงินทุนค่อนข้างสูง เพราะอะไรจึงสนใจเทคโนโลยีคลาวด์ และอะไรที่ทำให้ตัดสินใจเลือกซอฟต์แวร์ open source ในการพัฒนาโครงสร้างพื้นฐานคลาวด์ (cloud infrastructure) ที่ชื่อว่า OpenStack, Ceph และ Tungsten Fabric รวมถึงการติดตั้ง สภาพแวดล้อมที่ใช้ การทำ POC (proof of concept) ความยากลำบากในการทำก่อนจะเข้าสู่โพรเซส production การเปลี่ยนแปลงธุรกิจจากการเป็นผู้ให้บริการ colocation เป็นการให้บริการคลาวด์เต็มรูปแบบ การแก้ไขปัญหาและฝ่าฟันอุปสรรคต่าง ๆ มากมาย จนสามารถเปิดให้บริการ public & private cloud ได้สำเร็จ

NIPA เริ่มต้นจากการเปลี่ยนแปลงธุรกิจจากการเป็นผู้ให้บริการ colocation เป็นการให้บริการคลาวด์ ในช่วงปี ค.ศ. 2009 บริษัทฯ ได้วางแผนให้บริการเสิร์ชเอนจิน (search engine) ของประเทศไทย ประจวบกับภาครัฐ โดยคณะกรรมการกิจการกระจายเสียง กิจการโทรทัศน์ และกิจการโทรคมนาคมแห่งชาติ (กสทช.) ได้เปิดเสรีภาพให้กับบริการ data center บริษัทจึงตัดสินใจสร้าง data center ขึ้น พร้อมขอใบอนุญาตการให้บริการกิจการโทรคมนาคมประเภทที่ 1 แต่พอได้ลงมือทำจริงก็พบกับอุปสรรคมากมาย ทั้งด้านของต้นทุนที่บานปลาย เทคโนโลยีที่ต้องพัฒนาขึ้นมาเอง และคู่แข่งอย่าง Google ที่ประกาศเปิดตัวว่าจะเข้ามาเปิดบริการเสิร์ชเอนจินในประเทศไทย จนในที่สุดก็ต้องตัดสินใจล้มเลิกแผนไป เพราะข้อจำกัดด้านทรัพยากรที่ไม่สามารถรวบรวมข้อมูลจากทั่วโลกมาเก็บไว้ในเสิร์ชเอนจินของเราได้

จากเหตุการณ์ดังกล่าวที่ก่อเกิดเป็นความเสี่ยงในการลงทุนนวัตกรรม ดังนั้น data center จึงกลายเป็นการลงทุนที่ต้องหาทางออก เพราะแทบจะไม่มีการใช้งาน จึงไม่สามารถทำรายได้อย่างที่คาดหวังได้ ทำให้ในปีช่วงปี ค.ศ. 2009-2012 บริษัทพยายามเปลี่ยนธุรกิจ data center เป็นบริการ colocation หรือการให้เช่าวางเซิร์ฟเวอร์บนโลกอินเทอร์เน็ต แต่ด้วยธรรมชาติของรูปแบบธุรกิจ colocation คือมีลักษณะการบริการที่ง่าย เพียงมีเงินทุนก็สามารถสร้าง data center และให้บริการได้เลย ไม่ได้ต้องมีเทคโนโลยีสำคัญหรือนวัตกรรมใด ๆ ใหม่ จึงทำให้ธุรกิจนี้มีอุปสรรคในการเข้าสู่ตลาดน้อย (low entry barrier) มีการแข่งขันสูง ส่วนต่างของกำไร (margin) ต่ำมาก และไม่สามารถสู้ราคาคู่แข่งรายใหญ่ได้ อย่าง INET, KSC, CSL, True และ NT (CAT & ToT เดิม) เป็นต้น

ตั้งแต่ปี ค.ศ. 2012 เป็นต้นมา NIPA จึงได้เริ่มมองหาโอกาสของธุรกิจใหม่โดยการเพิ่มมูลค่า (value added) ให้กับ data center เพราะหากสถานการณ์ยังเป็นเช่นนี้อยู่ อีกไม่นานบริษัทก็คงต้องปิดตัวลง ณ ช่วงเวลานั้น เคยมีความคิดถึงขั้นที่จะขาย data center ทิ้งเลยทีเดียว

เมื่อเริ่มมองหาโอกาส เราก็ได้พบกับ เทคโนโลยีคลาวด์ ซึ่งในเวลานั้นมีผู้ให้บริการแล้วในระดับ global เพียงรายเดียวคือ Amazon Web Services (AWS) ทาง NIPA จึงได้เริ่มศึกษา ทำการวิจัยตลาด และได้ตัดสินใจว่าจะต้องทำธุรกิจเกี่ยวกับคลาวด์เทคโนโลยี เนื่องจากทีมงานประเมินว่าคลาวด์จะเป็นเทคโนโลยีในอนาคตที่มีความจำเป็นกับธุรกิจไอทีในทุกภาคส่วนอย่างแน่นอน แต่การจะเริ่มต้นสร้างนวัตกรรมและพัฒนาซอฟต์แวร์ขึ้นมาใหม่ทั้งหมดคงจะใช้เวลานานเกินไป NIPA จึงมองหาทางลัด และได้พบกับซอฟต์แวร์ open source ชื่อว่า OpenStack และเกิดความสนใจตั้งแต่นั้นเป็นต้นมา เพื่อให้เกิดความมั่นใจ ระหว่างปี ค.ศ. 2012-2015 NIPA จึงเดินทางไปร่วมงาน OpenStack Summit ทุกปี ปีละ 2 ครั้ง เช่น Vancouver, Canada (2018); Austin, Texas, USA (2016); Barcelona, Spain (2016); Boston, USA (2016); Tokyo, Japan (2015) เป็นต้น เพื่อศึกษาให้ลึกซึ้งและวางแผนว่าจะเดินไปในทิศทางใด และแนวทางการพัฒนาโครงสร้างพื้นฐานคลาวด์ด้วยซอฟต์แวร์ open source จะมีอุปสรรคอะไรบ้างที่เราคาดไม่ถึง

นอกเหนือจากปัญหาในการติดตั้ง OpenStack และ Ceph ที่มีโมดูล (module) จำนวนมากและมีความสลับซับซ้อนแล้ว อุปสรรคอีกประการที่เรามองเห็นความยากสำหรับการให้บริการ public cloud คือ วิธีการสร้างให้เกิดการใช้งานได้ง่าย เนื่องจากโมดูลของ OpenStack ที่ชื่อว่า Horizon นั้นไม่เหมาะในการเอามาให้บริการลูกค้าจำนวนมาก แต่เหมาะสำหรับการเป็น admin portal ทำให้เราต้องพัฒนาหน้า user portal ขึ้นมาใหม่ทั้งหมด เพราะไม่มี open source ให้ใช้ได้อย่างจริงจัง จึงต้องเริ่มต้นสร้างทีมนักพัฒนา (developer) ขึ้นมา เมื่อกลางปี ค.ศ. 2015 เรามั่นใจอย่างแน่วแน่แล้ว จึงเริ่มต้นลงมือซื้อเครื่องเซิร์ฟเวอร์มาทดลอง ลองผิดลองถูกจนกระทั่งสามารถเปิดให้บริการได้ในปี ค.ศ. 2017

เป็นที่ทราบกันดีว่า OpenStack ถูกสร้างและออกแบบมาเพื่อพัฒนา private cloud เป็นหลัก แต่สาเหตุที่ NIPA Cloud ตัดสินใจที่นำมาพัฒนา public cloud ก็เพราะได้พบกับ ผศ.ดร.ชาญวิทย์ แก้วกสิ ซึ่งเป็นอาจารย์ประจำสาขาวิชาวิศวกรรมคอมพิวเตอร์ สำนักวิชาวิศวกรรมศาสตร์ มหาวิทยาลัยเทคโนโลยีสุรนารี ซึ่งมีความรู้ความเข้าใจ OpenStack เป็นอย่างดี และเป็นที่ปรึกษาให้กับบริษัท ในช่วงนั้น และ ดร.อภิศักดิ์ จุลยา, CEO, NIPA Cloud ได้ดำริกับ ดร.ชาญวิทย์ว่า “ทำไมเมืองไทยไม่มี public cloud ให้บริการ และจะทำยังไงดีให้เรามี public cloud ให้บริการได้ในประเทศ” ซึ่งคำตอบที่ได้รับก็คือ ให้ทดลองนำ OpenStack มาติดตั้ง แต่อาจจะมีอุปสรรคใหญ่ 2 ประการ คือ การติดตั้ง OpenStack ที่ค่อนข้างยุ่งยาก และซอฟต์แวร์ที่ต้องเขียนขึ้นมาเพื่อให้ใช้งานง่าย ซึ่งทั้งสองอย่างก็สอดคล้องและยืนยันกับสิ่งที่เราพอทราบมา

อุปสรรคที่กล่าวมาทั้งสองประการถือเป็นงานที่ยากมาก ทำให้ใช้เวลาตัดสินใจอยู่นาน แต่นอกจากความต้องการให้คนไทยมี public cloud ใช้งานแล้ว ยังมีเหตุผลทางด้านธุรกิจอีก 3 ประการที่ช่วยในการตัดสินใจอีกด้วย ได้แก่

1. หากทำเฉพาะ private cloud ซึ่งเป็นบริการที่ทุกคนสามารถทำได้ ทำให้มีคู่แข่งในตลาดมากขึ้นในอนาคต แตกต่างจาก public cloud ที่หากทำได้สำเร็จนั้นจะมีคู่แข่งน้อยรายที่ตามทัน และสามารถให้บริการกับกลุ่มลูกค้าที่กว้างและหลากหลายได้มากกว่า หรือภาษาทางธุรกิจเรียกว่า public cloud มี entry barrier ที่สูงกว่ามาก ประกอบกับต้นแบบบริการคลาวด์ที่เห็นในตอนนั้นมีแค่ (AWS) เท่านั้น

2. หากบริษัทให้บริการเฉพาะ private cloud ความต้องการที่จะ utilize data center ที่สร้างขึ้นตั้งแต่ต้นก็จะไม่สามารถบรรลุจุดประสงค์ที่ต้องการเพิ่มมูลค่าให้กับ data center ได้

3. เนื่องจากเป็นผู้เล่นรายใหม่ในตลาด หากจะให้บริการ private cloud เพียงอย่างเดียวก็อาจจะมีความลำบาก เนื่องจากต้องมีชื่อเสียงและความน่าเชื่อถือพอสมควร จึงทำให้มี strategy ในการเริ่มทำ public cloud ให้มีชื่อเสียงก่อน

แม้จะเข้าใจดีว่า ณ ตอนนั้น public cloud เป็นโครงการระยะยาว (longterm project) ที่ต้องลงทุนและลงแรงอีกมาก ประกอบกับปัญหาที่เราไม่คาดว่าจะเกิด (pitfall) และยังมีความไม่แน่นอนที่ยังมองไม่เห็น แต่สุดท้ายก็ได้ตัดสินใจว่าจะลองทำ OpenStack public cloud ดู จึงได้เชิญ ผศ.ดร.ชาญวิทย์มาเป็นที่ปรึกษาในช่วง 6 เดือนแรก ซึ่งก็ได้คำแนะนำว่าให้เข้าไปศึกษา OpenStack และต้องเขียนขึ้นมาเท่านั้น ไม่มีทางเลือกอื่น แต่ถึงแม้ว่าจะได้เดินทางไปเข้าร่วมงานของ OpenStack เป็นเวลาหลายปีเพื่อหาทางลัดในการลดอุปสรรคที่กล่าวไปข้างต้น นั่นคือ การติดตั้ง OpenStack และการสร้างให้ใช้งานง่าย ซึ่งอุปสรรคข้อแรกคงจะไม่มีทางลัดนอกจากต้องเรียนรู้เอง แต่อุปสรรคในข้อสองนั้น หากเจอซอฟต์แวร์ open source หรือซอฟต์แวร์สำเร็จรูปก็น่าจะช่วยลดอุปสรรคและสำเร็จได้ไวขึ้น อย่างไรก็ตาม แม้ว่าไปร่วมงาน summit มาหลายปีติดต่อกันก็ยังไม่สามารถหาได้ จึงต้องทำการเรียนรู้และเขียนขึ้นมาใหม่ทั้งหมดเช่นกัน

ยิ่งไปกว่านั้น การมี data center เป็นของตัวเองก็ยังช่วยให้เราสามารถทดสอบจาก environment จริงได้ ซึ่งหากเราไปเช่าบริการที่ data center อื่น การจะทดสอบและเข้าไปแก้ไขทดลองก็จะไม่สามารถทำได้ง่ายนัก เราจึงใช้ data center ของตัวเองทดลองปรับแต่งซอฟต์แวร์จนรู้สึกมั่นใจ (ภายหลังใช้ชื่อว่า NIPA Innovation Lab) และเริ่มเปิดให้บริการ public cloud

ทั้งหมดนี้จึงเป็นคำตอบสำหรับคำถามว่าทำไม NIPA Cloud จึงเลือกพัฒนา public cloud ก่อน private cloud ด้วยความมุ่งมั่นที่จะเป็นผู้ให้บริการ public cloud อันดับหนึ่งในประเทศไทย ซึ่งขณะนั้น AWS เป็นผู้เล่นที่แข็งแกร่งที่สุดในตลาด ผู้ให้บริการคลาวด์ระดับ hyperscaler เจ้าอื่นอย่าง Google Cloud Platform, Microsoft Azure, Huawei Cloud, Alibaba Cloud หรือ Tencent Cloud ก็ยังไม่มีบทบาทในตลาดเลยสักราย

อย่างที่ทราบกันดีว่าข้อเสียของการใช้งานซอฟต์แวร์ open source ที่ใหญ่ที่สุด คือ การพัฒนาคนและการทำ R&D ซึ่งระหว่างที่เราติดตั้ง OpenStack และทดลองใช้งานก็เกิดปัญหาขึ้นมากมาย ปัญหาหลัก ๆ ที่พบเจอนั้นมี 4 ประการ ได้แก่

ในตอนแรก OpenStack ออกแบบมาเพื่อให้ทำ private cloud ไม่ได้ออกแบบมาให้ทำ public cloud เราจึงเจอปัญหาในการ scale หรือที่เราเรียกว่า performance scale ณ ตอนนั้นทุกคนลง OpenStack และมีการใช้งานเครื่องเสมือน (virtual machine: VM) จำนวนไม่มาก ประมาณ 1-2 VM ทำให้ยังไม่เกิดปัญหา แต่เมื่อลองทดสอบ VM จำนวนหลักร้อยขึ้นไปก็พบปัญหา ซึ่งส่วนใหญ่คือเรื่องของ network กล่าวคือ เมื่อใช้งาน VM จำนวนมากจะลดperformance network ลง ซึ่งขณะนั้นพบปัญหา 2 ประการ ปัญหาแรก คือ เมื่อ launch VM จำนวนมากจะมีโอกาสไม่สำเร็จ โดยการทดสอบใช้งาน VM จำนวนมากจะทดสอบ 2 แบบ แบบที่หนึ่ง คือ ทดสอบการจัดหาทรัพยากร (provisioning test) โดยจะเปิดใช้งานเครื่องเสมือน (launch instance) พร้อม ๆ กัน เปิด VM ทีละ 10 VM และตรวจสอบว่ามีปัญหาหรือไม่ และแบบที่สอง คือ เมื่อ run 100 VM แล้ว VM เหล่านี้มีปัญหา network หรือไม่ ซึ่งปัญหาส่วนใหญ่ที่พบคือปัญหาด้าน network นี้เอง

เมื่อทดสอบ local disk ก็พบว่ายังออกแบบการใช้งาน Ceph ได้ไม่ดีเท่าที่ควร แม้ว่าจะได้จัดเตรียมฮาร์ดแวร์ไว้เป็นอย่างดีแล้ว ก็ยังไม่สามารถใช้งาน Ceph Storage ได้ทั้งหมด ดังนั้น ปัญหาก็คือเมื่อจะออกแบบ Ceph ควรจะต้องเข้าใจซอฟต์แวร์เสียก่อนแล้วจึงค่อยออกแบบฮาร์ดแวร์ เพราะส่วนใหญ่แล้ว ความเร็วของ Ceph ขึ้นอยู่กับฮาร์ดแวร์ที่สอดคล้องกันด้วย ซึ่ง ณ ขณะนั้นทำ volume ได้แล้ว แต่เมื่อนำไปทดสอบ performance กลับไม่ผ่าน ซึ่งขณะนั้นมีปัญหาเพราะว่าซื้อฮาร์ดแวร์มาแล้ว แล้วค่อยมา tuning แต่หลักการที่ถูกต้องคือต้องเข้าใจซอฟต์แวร์ก่อน แล้วจึงออกแบบฮาร์ดแวร์ เพราะฉะนั้นการออกแบบ Ceph ให้ดีตั้งแต่ต้นจึงสำคัญมาก

ในช่วงแรกเราตัดสินใจว่าเราจะใช้รูปแบบ local disk อย่างไรก็ตาม ปัญหาของรูปแบบ local disk คือ หากเครื่องเกิดดาวน์หรือมีปัญหา เราจะไม่สามารถใช้งาน VM ได้ เราจึงแก้ไขปัญหาด้วยการใส่ card RAID เข้าไป ซึ่งรู้อยู่แล้วว่าหากใช้ local disk แล้วเครื่องดาวน์หรือฮาร์ดดิสก์มีปัญหาก็จะใช้งานไม่ได้ นับเป็นความเสี่ยงที่กังวลอยู่แล้วตั้งแต่ต้น

แต่ปัญหาจริง ๆ ที่เรามองข้าม คือ เรื่องของการ live migration ที่ใช้เวลานาน ซึ่งบางเครื่องใช้เวลาเป็นชั่วโมงจึงจะเสร็จ กล่าวคือ ปัญหาไม่ใช่เรื่องเครื่องดาวน์แล้วเราเอากลับมาไม่ได้ แต่ปัญหาก็คือเรื่อง live migration ที่นาน ตัวอย่างเช่น การ live migration ใน local disk ขนาด 3 TB บน network ขนาด 1 GB ที่กินเวลากว่า 1-2 ชั่วโมงถึงเสร็จต่อเครื่อง compute node นอกจากนี้ หากต้องการ maintenance เครื่องนั้น ๆ เราก็จะต้องนำ live migration ออกไป โดยต้อง transfer local disk จากเครื่องหนึ่งไปสู่อีกเครื่องหนึ่ง ซึ่งใช้เวลานาน เหล่านี้เป็นปัญหาที่เราเจอ ยิ่งไปกว่านั้น โอเปอเรชันก็ยาก และลูกค้าก็เริ่มใช้มากขึ้นเรื่อย ๆ เช่น วันนี้เริ่มเปิดคลาวด์ขนาด 40 GB ยังไม่มีปัญหา แต่เมื่อเปิดนานเข้า 2-3 ปี ข้อมูล (data) ก็เพิ่มมากขึ้นเรื่อยๆ หมายความว่าการใช้งานดิสก์ของ local disk ก็ยิ่งเพิ่มมากขึ้นเรื่อย ๆ ทำให้เมื่อ live migration ก็จะยิ่งใช้เวลานานเข้าไปใหญ่

การ take snapshot เพื่อ backup data ก็เป็นอีกปัญหาที่ใช้ระยะเวลานาน เนื่องจากมีการ take snapshot compress และ upload เปลี่ยนเป็น image แล้ว ในวันแรกที่เปิดให้บริการเราไม่ได้คิดถึงปัญหานี้ แต่เมื่อเริ่มขายการใช้งานไปเรื่อย ๆ การ backup กลายเป็น requirement หลักของลูกค้า เพราะฉะนั้น ลูกค้าเกือบทุกรายจะใช้ฟีเจอร์นี้ นั่นจึงทำให้การทำ snapshot บางทีใช้เวลาถึง 6-7 ชั่วโมงจึงจะเสร็จ ปัญหาคือ เมื่อทำ backup หรือ auto backup นั้น memory จะถูกใช้ตอน backup ถ้า resource มีเมมโมรีน้อยเกินไปก็จะทำให้เกิดอาการค้างขณะ backup และไม่สามารถแก้ได้ เนื่องจากหากเมมโมรีเครื่องใช้ไป 80% แล้ว แต่เมื่อ backup ก็จะทำทุก VM ซึ่งใช้เมมโมรีเพิ่มขึ้น มันก็เลยทำให้เครื่องดาวน์นั่นเอง

NIPA Cloud ได้วิจัยและพัฒนาซอฟต์แวร์ที่ใช้ควบคุม OpenStack อีกชั้นหนึ่งเรียกว่า Portal เป็นซอฟต์แวร์ที่ถูกออกแบบมาเพื่อให้คนภายนอกเข้ามาใช้งาน OpenStack cloud ชื่อว่า NCP (NIPA Cloud Platform) นับเป็นความพยายามครั้งแรกในการตั้งทีมนักพัฒนา หลังจากที่เรา implement คลาวด์ได้สำเร็จแล้ว ก็เริ่มเขียนโค้ดสำหรับ portal เพราะต้องการออกแบบให้ยูสเซอร์สามารถใช้งานได้ง่ายขึ้น

ส่วนที่สำคัญ คือ การเชื่อมต่อกับ API ของ OpenStack ซึ่ง ณ ขณะนั้นเรารู้อยู่ก่อนแล้วว่า OpenStack คือ API engine นั่นคือ เราสามารถเขียนโค้ดเพื่อเข้าไปควบคุมทุก ๆ อย่างของ OpenStack ได้ ดังนั้น การเขียนโค้ดส่วนนี้ถือเป็นความท้าทายหนึ่งของการเขียนซอฟต์แวร์เพื่อควบคุม OpenStack

แม้ว่า OpenStack จะมีโมดูลที่ใช้พัฒนาเว็บไซต์แบบ front-end ชื่อว่า Horizon ซึ่งเป็นโค้ดที่ทางคอมมิวนิตี้เขียนขึ้นมา โดยมีจุดประสงค์ คือ เพื่อนำไปใช้งานสำหรับแอดมิน โดยให้ Horizon เป็นหน้าด่านก่อนที่จะเข้าไปใช้งาน OpenStack แต่ Horizon มีข้อเสีย คือ ไม่เหมาะกับการเปิดให้คนทั่วไปเข้ามาใช้งาน เพราะไม่ได้ออกแบบโค้ดมาเพื่อรองรับผู้ใช้งานจำนวนมาก หากมีผู้ใช้จำนวนมากเข้ามาพร้อมกันก็จะเกิดปัญหาค่า latency ที่สูง เมื่อมีผู้ใช้งานจำนวนมาก ทุกอย่างจะดีเลย์

ดังที่เรากล่าวไปตอนต้นว่า OpenStack เหมาะสำหรับการทำ private cloud และ Horizon ก็เป็นโมดูลหนึ่งของ OpenStack จึงไม่น่าแปลกใจในเรื่องของโค้ดที่ไม่ได้ถูกออกแบบมาเพื่อรองรับผู้ใช้งานจำนวนมากอย่าง public cloud เนื่องจากลักษณะการใช้งาน private cloud จะเป็นการสั่งการผ่านแอดมิน ทำให้สามารถจัดการได้เฉพาะเว็บไซต์ front-end หรือ portal ที่มี traffic จำนวนไม่มาก

นอกจากนี้ การใช้งานของ Horizon นั้นค่อนข้างยาก ต้องใช้เวลาและ learning curve สูง อีกทั้งไม่สามารถตอบโจทย์การเปิด public cloud ได้ เพื่อที่จะแก้ไขปัญหาดังกล่าว จึงเป็นเหตุผลว่าทำไมจึงต้องเขียน portal NCP ขึ้นให้เกิดการใช้งานที่ง่าย ซึ่งนอกจากจะออกแบบเพื่อควบคุม OpenStack แล้ว ยังมีส่วนประกอบหลัก 3 ส่วน ได้แก่

เราต้องสามารถรับรู้ได้ว่าใครเข้ามาใช้งาน หากมีการติดต่อขอความช่วยเหลือก็จะสามารถช่วยเหลือผู้ใช้งานนั้น ๆ ได้ตรงจุดมากขึ้น

คุณสมบัติการให้บริการคลาวด์ คือ ผู้ใช้งานจะสามารถยกเลิกเมื่อไหร่ก็ได้ และทำได้เองตามต้องการ

การให้บริการคลาวด์จะต้องมีการคิดค่าบริการแบบ pay-as-you-go pricing หรือใช้งานเท่าไหร่ก็จ่ายเท่านั้น การคิดค่าบริการเช่นนี้จึงกลายเป็นโจทย์ว่าต้องมีซอฟต์แวร์ข้างใน OpenStack ซึ่งก็คือ metering ที่ทำหน้าที่วัดปริมาณการใช้งาน เมื่อมีการใช้งานและมีปริมาณงานที่เกิดขึ้น metering ก็จะดึงข้อมูลออกมาและเรียกเก็บเงิน (payment gateway) ซึ่งเป็นส่วนที่สำคัญที่สุด

เหล่านี้คือองค์ประกอบ 3 ส่วนที่เขียนขึ้นมาโดยทีมนักพัฒนาทั้งหมดและอยู่ในส่วนที่มีความท้าทาย เนื่องจากเป็นการตั้งทีมนักพัฒนาครั้งแรก หลังจากนั้นคือการพัฒนาให้ดีขึ้นอย่างต่อเนื่อง