Wall of Text #10: Cloud

จากข่าว SCB Easy ล่มเพราะไปใช้ AWS ผมเดาไว้ใน Facebook ว่าเค้าน่าจะเอา ELB มาแล้ว load balance on premise แล้ว Link พัง น้องเค้าถามว่าเข้าใจว่าหมายถึงอะไร

ย้ำอีกทีว่าเรื่องที่เกี่ยวกับธนาคาร ผมก็เดามั่วไปเท่านั้นแหละ

On Premises

เพิ่งมารู้ว่าการเขียนว่า On Premise นี่ไม่ถูกต้อง ต้องเขียนว่า On Premises เสมอ เพราะ Premises แปลว่าที่ตั้งและมันไม่ใช่รูปพหูพจน์

สำหรับธนาคารแล้ว Server ต่างที่ให้บริการจะอยู่ในศูนย์ข้อมูลของธนาคารเอง เค้าก็เลยเรียกว่า On Premises ก็คือมันอยู่ในที่ตั้งของเรา

มาร์เก็ตติ้งของ Cloud มักจะใช้คำว่า On Premises หมายรวมไปถึงระบบที่ไม่ใช่ Cloud ทั้งหมดถึงมันจะไม่อยู่ที่ออฟฟิศของเราก็ตาม ซึ่งไม่ว่ามันจะถูกหรือผิดมันก็เห็นภาพชัดเจนดีเวลาเราบอกว่าย้ายระบบจาก On Premises ขึ้น Cloud ก็คือย้ายจาก server เดิมไปยังผู้ให้บริการ cloud

Cloud

ทีนี้ถามว่าทำไมธนาคารถึงจะอยากใช้ Cloud? Cloud คืออะไร…

มีตำนานเล่าว่านานมาแล้วมีอุกกาบาตตกลงทุ่งข้าวสาลี ในช่วง Black Friday มีคนเข้ามาซื้อของที่เว็บ Amazon.com เป็นจำนวนมาก Amazon ก็เลยจะต้องจัดซื้อ server มารองรับผู้ใช้งานมหาศาลไม่ให้ล่ม

ทีนี้พอนอกเทศกาล เครื่องมันก็ปล่อยว่างไว้ ทำยังไงดี? Amazon ก็เลยพัฒนา Amazon EC2 ขึ้นมาปล่อยเช่าเครื่อง

ในความเป็นจริงแล้วเรื่องข้างบนขี้โม้ทั้งเพ เพราะ Werner Vogels CTO ของ AWS ก็บอกว่าถ้าเอาเครื่องเหลือมาขายน่ะ 2 เดือนก็ได้ลูกค้ามาจนเครื่องไม่เหลือแล้ว และบริการตัวแรกของ AWS คือ S3 ไม่ใช่ EC2

ไม่ว่าจะจริงหรือไม่จริงแต่เรื่องมีคนเข้าเว็บเยอะบางเวลาเป็นเรื่องจริงที่ทุกคนมีปัญหา ไม่ใช่แค่ Amazon

ระบบลงทะเบียนมหาวิทยาลัยจะมีคนเข้าเยอะมากในช่วงเปิดลงทะเบียน กับเกรดออก

ธนาคารจะมีคนเข้าเยอะในช่วงปลายเดือนไปจนถึงต้นเดือนที่เงินเดือนออก

Startup จะมีคนเข้าเยอะในช่วงเปิดตัวผลิตภัณฑ์ใหม่

กรมสรรพากรจะมีคนเข้าเยอะในช่วงฤดูยื่นภาษี

การที่ระบบล่มส่งผลต่อการดำเนินธุรกิจของหน่วยงานเหล่านี้โดยตรง แล้วจะให้เค้าทำอย่างไร?

ถ้าสุดท้ายแล้วทุกคนซื้อ server มาเพื่อรองรับ spike load เหล่านี้คงจะสิ้นเปลืองมาก และไม่คุ้มทุนที่จะทำ

Cloud อนุญาตให้เราเช่าเครื่องได้เพียงยิง API เข้าไปสั่งเปิดเครื่อง แล้วรอ 2 นาทีให้เครื่องเปิดเสร็จ

Keyword สำคัญคือเช่า เราไม่ต้องมีเงินก้อนที่จะจัดซื้อเครื่องเซิร์ฟเวอร์ราคาแพงอีกต่อไปเพียงแค่จ่ายเงินค่าเช่าเท่านั้นก็สามารถมีเซิร์ฟเวอร์นับร้อยเครื่องได้

ยิ่งไปกว่านั้น สัญญาการเช่าปัจจุบันอยู่ที่ 1 วินาที (ขั้นต่ำ 10) นาที นั่นแปลว่าเซิร์ฟเวอร์นับร้อยเครื่องที่เปิดมารองรับผู้ใช้งานนั้น พอไม่ได้ใช้แล้วจะปิดเมื่อไรก็ได้ แล้วจะไม่เสียค่าอะไรอีกเลย

ไม่ว่าคิดบัญชียังไง Cloud ก็ดูจะคุ้มค่ากว่าเห็นๆ ใช้เท่าไหน จ่ายเท่านั้น เหมือนค่าไฟฟ้าที่ไม่เปิดไฟก็ไม่เสีย

แต่ราคาของ Cloud ไม่ถูก ราคาค่าเช่ามันแพงกว่าค่าเช่าซื้อเครื่องเซิร์ฟเวอร์ไว้เองด้วยซ้ำ แล้วทำไมมันถึงยังน่าสนใจ?

Scale

สิ่งที่ Cloud computing ต้องการเสนอขายไม่ใช่การให้เช่าระบบคอมพิวเตอร์ แต่เค้ากำลังจะขาย “ความสามารถที่จะ scale”

นอกเหนือไปจากการที่เราจะสามารถขยับจาก 0-100 server ได้ในเวลาไม่กี่นาทีแล้วนั้น ผู้ให้บริการ Cloud ยังมีบริการอื่นๆ อีกที่พร้อมจะโตไปกับโปรแกรมของเรา

ถ้าต้องการฐานข้อมูล AWS มีฐานข้อมูลระดับเดียวกับที่ Amazon ใช้ภายในให้บริการ หรือจะเป็น MySQL มาตรฐานก็ใช้ได้

ถ้าต้องการ Message queue AWS ก็มี API เปิดให้ใช้โดยไม่ต้องซื้อซอฟต์แวร์ Message queue ราคาแพง

ถ้าต้องการเก็บข้อมูล AWS มีระบบเก็บข้อมูลไว้ใช้ที่ขนาดแทบไม่จำกัด สามารถเปิดอ่านพร้อมกันได้ 5,500 ครั้งต่อวินาทีต่อโฟล์เดอร์

บริการเหล่านี้ Cloud มีให้เนื่องจากเป็นระบบที่ Application ส่วนมากจำเป็นต้องใช้ แล้วเราจะพัฒนาขึ้นเองทำไมในเมื่อ Cloud ทำให้แล้ว ในราคาที่ถูกกว่า รองรับผู้ใช้งานได้มหาศาล และไม่ต้องนั่งเฝ้าเซิร์ฟเวอร์เอง

Migrating to Cloud

นั่นคือเหตุผลที่ทุกคนกำลังย้ายไป Cloud ในขณะนี้ ถ้าบริษัทไม่ได้ใหญ่มากจนสามารถทำระบบแบบ Cloud ได้ในราคาที่คุ้มทุน และไม่ติดข้อกำหนดอะไรที่ต้องเอาข้อมูลไว้ On Premises การใช้ Cloud ทำให้ระบบมีเสถียรภาพได้ในราคาที่คุ้มค่า

ทีนี้จาก Diagram ของ SCB ซึ่งไม่มีบอกว่าระบบไหนอยู่ที่ไหน ผมเดาว่าสิ่งที่เกิดขึ้นคือ ด้านหน้าของ Experience API โดยปกติแล้วจะมีระบบ Load balancer ที่กระจาย load ให้กับ server ด้านหลังอีกที (Load balancer ทำแค่กระจายโหลดจึงใช้เครื่องน้อยกว่าเครื่องที่ประมวลผล)

ทีนี้ระบบบางส่วนน่าจะถูกย้ายขึ้นไปบน Cloud (ซึ่งเราไม่อาจจะเดาได้ว่ามีอะไรบ้าง) แต่ที่เห็นจากภายนอกคือ Load balancer ถูกย้ายไปด้วย

แต่ไม่ใช่ทั้งแอพที่ถูกย้ายไป ระบบที่อยู่บน Cloud ยังต้องเรียกข้อมูลจากระบบเดิมอยู่ ซึ่งการเชื่อมต่อระหว่าง Cloud กลับมาระบบ On Premises ก็มีอยู่สามวิธีคือ

  1. เรียกผ่านอินเทอร์เน็ตปกติ ข้อเสียคือไม่สามารถเรียกเครื่องที่ไม่มี IP จริงได้
  2. ติดตั้ง VPN แล้วเชื่อมทั้งสองระบบเข้าด้วยกัน
  3. ลากสายจาก Cloud มายังสถานที่เรา ซึ่งแน่นอนว่าแพงมาก

นอกเหนือจาก 1 แล้ว ปัญหาที่เกิดขึ้นได้คือการเชื่อมต่อจะเกิดคอขวดขึ้น เนื่องจากถ้าใช้ VPN การเชื่อมต่อทั้งหมดจะต้องวิ่งผ่าน VPN server ที่ต้องเข้ารหัสข้อมูลก่อนส่งไปปลายทาง หรือสายที่เชื่อมต่อไปยัง Cloud ก็อาจจะมีความเร็วจำกัด

ที่ยังเดาอะไรไม่ได้คือถ้าหากปัญหาอยู่ที่ตรงนี้จริงก็ควรจะสามารถตัดสินใจ Rollback ได้ไม่ยากเพียงแค่สลับไปใช้ Load balancer ชุดเดิม ก็เป็นไปได้ว่า Application อาจจะถูกย้ายไปแล้วทำให้สลับกลับไม่ได้ (เพราะต้องย้ายข้อมูลกลับมาด้วย)

#HugOps

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

ในช่วงเวลาที่แอพล่มแบบนี้ก็เช่นกัน เราอาจจะอารมณ์เสียที่เข้าแอพแล้วใช้งานไม่ได้

แต่ Operation ที่กำลังกู้ระบบ โปรแกรมเมอร์ที่นั่งจ้องหาบั๊ก Support ที่รับสายจนคอแห้ง ก็เป็นมนุษย์เหมือนกับเรา

โปรดใจดีกับ Operation

Under the Cloud #4: Network Encryption

จริงๆ ไม่ได้กะจะมีต่อภาค 4 แต่เห็น Thread นี้ แล้วเลยอยากจะแชร์กัน เพราะผมเองก็เพิ่งรู้เหมือนกัน

คำถามวันนี้ถามว่า Network บน Cloud Secure แค่ไหน?

ทั้ง Google Cloud และ AWS ต่างมีระบบ network “Virtual Private” Cloud (VPC) ซึ่งทำให้เราเหมือนมี VLAN ส่วนตัวที่มีเฉพาะเครื่องเราคนเดียว ไม่เห็นเครื่องลูกค้าอื่น (ถ้าแต่ก่อนผมจะแซะ DigitalOcean แต่ได้ยินว่าเดี๋ยวนี้ก็มี VPC แล้วเหมือนกัน) คำถามคือแล้ว VPC มัน Secure แค่ไหน?

Going Physical

สำหรับคนที่ใช้ AWS ในสิงคโปร์น่าจะทราบดีว่า AWS จะมี 3 availability zone ด้วยกันคือ ap-southeast-1a, b และ c แล้วมันจัดโซนอย่างไร? มันจะอยู่ตึกเดียวกันหรือเปล่า?

คนที่ให้คำตอบนี้ได้ดีที่สุดคือ WikiLeaks ซึ่งผมก็ไม่รู้ว่าเค้า Leak มาทำไม

Northern Virginia (Map Data (C) OpenStreetMap Contributors)

ในสิงคโปร์อาจจะไม่เห็นชัดเท่าไร แต่ฝั่ง US จะเห็นค่อนข้างชัดว่า Region หนึ่งก็ไม่ใช่ศูนย์ข้อมูลเดียวแต่เป็นหลายๆ ตึกที่เชื่อมต่อกันด้วยไฟเบอร์ความเร็วสูง

สำหรับของ Google Cloud นั้นหน้าแนะนำ Data Center ของ Google ก็บอกเพียงแต่ว่า Google มีศูนย์ข้อมูลเพียงแห่งเดียวที่ Jurong West

ซึ่งต่อมา Google ก็บอกว่าได้ขยายศูนย์ข้อมูลเป็น 2 ตึกติดกับตึกเดิมในปี 2015

ทางซ้ายคือตึกใหม่

และในปี 2018 Google ก็กำลังจะสร้างอีกตึกหนึ่งในบริเวณเดียวกัน

ผมก็ยังสงสัยเหมือนกันว่า Disaster Recovery ของ Google Cloud คืออะไร ถ้ามีภัยธรรมชาติในบริเวณนั้นน่าจะไปพร้อมกันทั้ง 3 ตึก

Link Layer Encryption

ในปี 2013 ข่าวใหญ่อันหนึ่งคือ Edwards Snowden ได้เปิดเผยว่า NSA และ GCHQ ได้ดักฟัง Fiber ใต้น้ำระหว่างศูนย์ข้อมูลของ Google และต่อมา Google ก็เร่งเข้ารหัสข้อมูลระหว่างศูนย์ข้อมูล

ข่าวเหล่านี้ยิ่งทำให้เราเห็นว่าการอยู่บน Cloud ยิ่งทำให้เราเป็นเป้าหมายในการดักฟัง เพราะถ้าหากดักฟัง Cloud ได้แล้วก็จะได้ข้อมูลของลูกค้าจำนวนมากไปด้วย

ปัจจุบัน Cloud ทั้งสองเจ้าจึงระบุว่ามีการเข้ารหัสข้อมูลบน Network แล้ว แต่จะเป็นอย่างไร?

AWS

AWS เพิ่งเปิดเผยระบบ VPC Encryption เมื่อเดือนที่แล้ว

VPC Encryption

Image

โดย Instance ประเภท C5n, I3en, P3dn มีการเข้ารหัสข้อมูลอยู่แล้ว โดยใช้ Hardware เพื่อให้มีประสิทธิภาพสูงสุด

ทั้งนี้ข้อจำกัดของระบบเข้ารหัสอัตโนมัติมีพอสมควรคือ

  1. Instance ทั้งสองฝั่งจะต้องเป็นประเภทที่รองรับเท่านั้น
  2. Instance ทั้งสองฝั่งจะต้องอยู่บน VPC เดียวกัน หรือมี VPC Peering หากันซึ่งไม่ข้าม region

โดยระบบจะเข้ารหัสทั้ง Packet รวมทั้ง Header ของ AWS ด้วย ทำให้เมื่อดักฟังแล้วจะไม่ทราบแม้แต่ว่าเป็นแพคเกจของลูกค้าคนใด

Lever

AWS ยังได้พัฒนาระบบ Lever ที่เข้ารหัสข้อมูลบน Network ขึ้นมาอีกด้วย ซึ่งตอนนี้ผมยังไม่ทราบว่าระบบนี้นำมาใช้ตั้งแต่เมื่อไร

Lever จะเข้ารหัสข้อมูลบน Network ทั้งหมดที่ออกจากที่ตั้งของ AWS (Physical Boundary) ทั้งหมด เช่นถ้าไฟเบอร์วิ่งข้ามถนนไปหรือข้ามน้ำข้ามทะเลก็ตาม ข้อมูลที่วิ่งผ่านจะเข้ารหัสทั้งหมด

แน่นอนว่าทั้งหมดนี้ผู้ใช้งานไม่ต้องทำอะไรเลย

Google Cloud

Google ออก Whitepaper ด้าน Security มาหลายอัน ซึ่งผมแนะนำให้อ่านเพราะสามารถนำมาปรับใช้กับงานของเราได้

  • Google Security เล่าถึงนโยบายการปฏิบัติงานของ Google
  • Encryption at Rest เล่าถึงข้อมูลของเราว่าถูกจัดเก็บไว้อย่างไร
  • Encryption in Transit ซึ่งจะมาเล่าให้ฟัง

ใน Whitepaper นี้ Google ระบุว่า Traffic จะถูกเข้ารหัสก็ต่อเมื่อ

  • Traffic วิ่งออกจากที่ตั้งของ Google (Physical Boundary)
  • Traffic นั้นเป็นการใช้ Private IP คุยกัน
  • ทั้งสองฝั่งอยู่บน VPC เดียวกัน หรือ VPC Peering กัน

นอกจากการเข้ารหัสแล้ว ระบบ SDN ของ Google ยังจะมีการ Authenticate traffic ด้วย ทำให้ไม่สามารถ spoof network traffic ได้

สรุป

จากที่เรารีวิวมาก็จะเห็นว่าทั้งสอง 2 cloud จะมีการเข้ารหัสข้อมูลให้อัตโนมัติเมื่อวิ่งออกจากศูนย์ข้อมูลแห่งหนึ่งไปอีกแห่งหนึ่ง แต่ภายในศูนย์ข้อมูลเดียวกันนั้นก็ยังไม่มีการเข้ารหัสเพื่อลด overhead ลง จะมีแต่เฉพาะ AWS เท่านั้นที่มีการเข้ารหัสภายในศูนย์ข้อมูล แต่ก็จำกัดเฉพาะ instance type บางประเภทเท่านั้น