- เนื่องจากปัญหา อธิปไตยของข้อมูล และ การปฏิบัติตาม GDPR ที่เกิดจาก บริการคลาวด์ของสหรัฐฯ จึงเกิดความจำเป็นต้องย้ายไปใช้คลาวด์ยุโรป
- แม้จะต้องยอมสละ ความสะดวกและบริการแบบบูรณาการ ของ AWS แต่ก็ได้ทั้งการลดต้นทุนทันทีและความชัดเจนด้านข้อมูลจาก โฮสติ้งในยุโรป อย่าง Hetzner
- เพื่อเพิ่มประสิทธิภาพการดำเนินงานโครงสร้างพื้นฐาน จึงสร้าง ระบบอัตโนมัติบน Ansible และระบบมอนิเตอร์ที่ดูแลเอง
- การสร้างระบบขึ้นมาเองทำให้ได้ทั้ง ความเข้มงวดด้านการออกแบบความปลอดภัย และ โครงสร้างที่เอื้อต่อการตรวจสอบอย่างโปร่งใส
- ยังได้ประโยชน์เชิงกลยุทธ์ทางธุรกิจ เช่น ลดต้นทุน 90% และ ลดความเสี่ยงจากการสอดส่องของสหรัฐฯ
กระบวนการย้ายจาก AWS ไปยังคลาวด์ยุโรป (Hetzner) และกลยุทธ์รักษา ISO 27001
ความกังวลของ CTO ในยุโรป: ปัญหาด้านการปฏิบัติตามข้อกำหนดเมื่อต้องออกจาก AWS
- หนึ่งในความกังวลหลักที่ผู้นำสายเทคโนโลยีจำนวนมากต้องเผชิญ มาจาก ข้อจำกัดของผู้ให้บริการคลาวด์สหรัฐฯ
- แม้จะพึงพอใจกับบริการที่ได้รับการรับรอง ISO 27001 อันแข็งแกร่งของ AWS แต่ก็หลีกเลี่ยงไม่ได้ที่ข้อมูลลูกค้าในยุโรปจะถูกเปิดให้ เขตอำนาจศาลสหรัฐฯ เข้าถึงได้ เนื่องจากกฎหมาย CLOUD Act และ FISA ของสหรัฐฯ
- ทำให้เกิดสถานการณ์ที่ ยากต่อการรักษาคำมั่นตาม GDPR โดยไม่ขึ้นกับตำแหน่งจริงของเซิร์ฟเวอร์
- ตระหนักว่าค่าใช้จ่ายคลาวด์ปีละ $24,000 นั้น สูงเกินความต้องการใช้งานจริง
- และเห็นชัดว่าการฝากอนาคตของบริษัทไว้กับ ผู้ให้บริการสหรัฐฯ เพียงรายเดียว เป็นความเสี่ยงเชิงกลยุทธ์
กรณีศึกษาจริงของ Datapult
- Datapult เป็น บริษัทซอฟต์แวร์บริหารจัดการแรงงานจากเดนมาร์ก ที่ต้องการความน่าเชื่อถือระดับงานการเงิน สำหรับการจัดตารางพนักงาน การปรับค่าล่วงเวลา และการจัดการข้อมูลการเข้างาน
- แม้จะปรับข้อกำหนดทางกฎหมายให้สอดคล้องกับ เวิร์กโฟลว์บน AWS มาแล้ว แต่การย้ายไปยังระบบ on-premise หรือบริการทางเลือกแบบอิสระยังต้องมีการทบทวนด้านกฎหมายเพิ่มเติม
ความกังวลเมื่อออกจาก AWS และสิ่งที่สูญเสียจริง
- การต้องสละ ความสะดวกแบบบูรณาการของ AWS เป็นอุปสรรคทางจิตวิทยาที่ไม่น้อย
- จะสูญเสียทั้งความง่ายและระบบอัตโนมัติ เช่น Lambda, One-click RDS และเครื่องมือด้าน compliance ที่มีมาให้ในตัว
- จากเดิมที่พึ่งพา managed service ก็ต้องเปลี่ยนมาเป็น การควบคุมและรับผิดชอบด้วยตัวเองมากขึ้น
ผลที่คาดหวังและประโยชน์ที่เกิดขึ้นจริงจากคลาวด์ยุโรป
- การ ย้ายไปยังผู้ให้บริการยุโรป (Hetzner, OVHcloud) ให้ประโยชน์ทันทีในด้านอธิปไตยของข้อมูล GDPR และ ISO 27001
- สื่อสารกับลูกค้าและรองรับการตรวจสอบได้อย่างโปร่งใส ผ่าน การพิสูจน์ data residency ที่แท้จริง
- บรรลุทั้ง การลดต้นทุนที่เกินคาด (90%) และความโปร่งใสด้านงบประมาณ
- แม้จะสละความสะดวกของ AWS แต่กลับได้กระบวนการอัตโนมัติที่ แข็งแกร่งยิ่งขึ้นทางเทคนิค (การตั้งค่าด้วย Ansible) และความปลอดภัยที่ดีขึ้น
- เมื่อเทียบกับเดิม ยังได้ทั้ง อิสระ นวัตกรรม และโครงสร้างพื้นฐานที่ตรวจสอบยืนยันได้
กลยุทธ์การย้ายที่เป็นรูปธรรมและบทเรียนสำคัญ
- ทำระบบอัตโนมัติด้าน compliance ด้วย Ansible
- ทำให้เกิด การจัดการโครงสร้างพื้นฐานแบบ self-documenting โดยผูกการตั้งค่าเซิร์ฟเวอร์ทั้งหมดเข้ากับการควบคุมตาม ISO 27001 Annex A โดยตรง
- สร้างระบบมอนิเตอร์ทดแทน AWS
- ใช้ชุด Prometheus, Grafana, Loki เพื่อให้ได้ความสามารถด้านมอนิเตอร์ระดับองค์กรใกล้เคียง AWS CloudWatch และตอบสนองต่อ incident ได้อย่างรวดเร็ว
- นำ security-by-design มาใช้เพื่อยกระดับการออกแบบความปลอดภัย
- ในสภาพแวดล้อมที่ไม่มี managed security tool ก็ยังเสริมความแข็งแกร่งให้ ISMS และช่วยให้นักพัฒนาปฏิบัติตามข้อกำหนดได้ง่ายขึ้นด้วย ระบบอัตโนมัติผ่าน Ansible
ผลเชิงกลยุทธ์ที่ไปไกลกว่าเรื่องเทคนิค
- ลดความเสี่ยงด้าน compliance จากกฎหมายสอดส่องของสหรัฐฯ
- ใช้ โครงสร้างพื้นฐานโฮสติ้งในยุโรป เป็นจุดขายเพื่อสร้างความแตกต่าง เพิ่มความน่าเชื่อถือและมูลค่าแบรนด์
- นำต้นทุนคลาวด์ที่ประหยัดได้ (90%) กลับไปลงทุนในธุรกิจหลัก
แนวทางประยุกต์ใช้กลยุทธ์การย้าย
- จากประสบการณ์การ ย้ายจากโครงสร้างพื้นฐาน AWS ไปยังคลาวด์ยุโรปที่มีอธิปไตยของข้อมูล พร้อมรักษา ISO 27001 ไว้ได้ จึงสามารถนำเสนอ แนวทางที่ทำซ้ำได้
- ให้คำปรึกษาแบบเฉพาะกรณีสำหรับ CTO และผู้ก่อตั้งที่กำลังพิจารณาย้ายจาก AWS ไปยังคลาวด์ยุโรป โดยครอบคลุม การวิเคราะห์ต้นทุน ความเสี่ยงด้าน compliance และแผนเวลาการย้ายระบบ
- ภายในหนึ่งชั่วโมงสามารถสรุปความต่างของต้นทุน ความเสี่ยงทางกฎหมายหลัก และขั้นตอนเริ่มต้นของการย้ายระบบได้
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
เราประหยัดค่าใช้จ่ายได้ด้วยการสร้างฟังก์ชันหลักของ AWS ขึ้นมาเองใหม่ แต่หลายคนมักมองข้ามต้นทุนที่แท้จริงของการโฮสต์แบบ DIY โดยเฉพาะเรื่องอย่างการซัพพอร์ตตลอด 24 ชั่วโมง ถ้าจะทำระบบสนับสนุนแบบนั้นใช้เองในบริษัท ค่าใช้จ่ายอาจสูงพอสมควร ค่าบริการ AWS ปีละ $24,000 เทียบได้กับค่าจ้าง DevOps ฟรีแลนซ์ฝีมือดี 1–2 เดือน หรือประมาณ 1/3 FTE ของนักพัฒนาค่าแรงต่ำ ซึ่งงบระดับนี้ยากจะคาดหวังการซัพพอร์ตแบบตอบสนองได้ตลอด 24 ชั่วโมง แน่นอนว่าการเลือกแบบนี้อาจสมเหตุสมผล แต่ก็น่าเสียดายที่ไม่ได้เปิดเผยต้นทุนทั้งหมดอย่างตรงไปตรงมา เช่น เวลาในการพัฒนาและค่าบริหารจัดการต่าง ๆ ฉันเองก็กำลังพิจารณาทางเลือกคล้ายกัน แต่เหตุผลหลักไม่ใช่การลดต้นทุน แต่อยู่ที่ความต้องการทางธุรกิจ เช่น ลูกค้าในเยอรมนี อย่างไรก็ตามมันจะซับซ้อนขึ้นและต้องเพิ่มคนในทีมด้วย ในฐานะ CTO เวลาของฉันมีจำกัดมาก การลงมาทำงานลักษณะนี้เองถือเป็นการใช้เวลาที่แย่ที่สุด ควรเอาเวลาไปโฟกัสกับการเติบโตของบริษัทและผลิตภัณฑ์มากกว่า ส่วนตัวมองว่า Terraform ดูเกินความจำเป็นสำหรับสเกลเล็กแบบนี้ และ Ansible เหมาะกับเคส YAGNI (You Ain’t Gonna Need It) มากกว่า
หลายคนเข้าใจผิดว่าผู้ให้บริการคลาวด์รายใหญ่อย่าง AWS, Azure, GCP ให้การซัพพอร์ตแอปพลิเคชันแบบ 24/7 ทั้งที่จริงไม่ใช่ สิ่งที่ได้คือโครงสร้างพื้นฐานที่ "ส่วนใหญ่" ทำงานได้ดี แต่สุดท้ายถ้าจะใช้งานให้ถูกต้องก็ยังต้องมีผู้เชี่ยวชาญคอยตรวจสอบเรื่องค่าบริการที่บานปลายหรือปัญหาการเชื่อมต่อเองอยู่ดี แนวคิดที่ว่าค่าคลาวด์จริง ๆ แล้วคือ TCO (ต้นทุนรวมในการเป็นเจ้าของ) เป็นมายาคติที่ผิดอย่างสิ้นเชิง
ถ้าจะทำซ้ำความสามารถของ AWS แบบ 100% ก็อาจแพงมาก แต่ถ้าต้องการแค่ 80% สถานการณ์ก็เปลี่ยนไป อีกทั้งความพยายามในการตั้งค่า AWS และการฝึกฝนทักษะอย่างต่อเนื่องก็ไม่ใช่เรื่องเล็ก ตัวอย่างเช่น แทนที่จะใช้ AWS dashboard ก็อาจใช้เครื่องมือที่ดีกว่าอย่าง grafana ได้ สุดท้ายแล้วมันขึ้นอยู่กับขนาดและความหลากหลายของความต้องการ ไม่ใช่ว่าค้อนที่แพงที่สุดจะเป็นคำตอบเสมอไป
ถ้ามองแค่ตัวเลขการประหยัด ก็เท่ากับลดค่าใช้จ่ายได้ปีละ $21,600 ซึ่งคือ 90% ของ $24,000 เดิม แต่ด้วยงบระดับนี้ ในยุโรปก็ยังจ้าง SRE/DevOps engineer ไม่ได้อยู่ดี แถมเมื่อเวลาผ่านไป การต้องดูแลอินฟราทั้งหมดเองจะยิ่งทำให้ต้นทุนรวมในการเป็นเจ้าของสูงขึ้นในระยะยาว ถึงอย่างนั้นก็ยังขอเอาใจช่วยกับความพยายามนี้
หากพิจารณาความเสี่ยงที่รัฐบาลสหรัฐอาจบังคับให้ Amazon ระงับบัญชี การใช้ AWS ก็อาจเป็นความเสี่ยงได้ โดยเฉพาะในสถานการณ์ที่ช่วงนี้มีการพูดถึงสงครามระหว่างสหรัฐกับยุโรป (กรีนแลนด์)
คิดว่าวิธีคำนวณแบบง่าย ๆ ว่าปีละ $24,000 นั้นดูไร้เดียงสาเกินไป เพราะไม่ได้รวมการประเมินต้นทุนบุคลากรอย่างเป็นรูปธรรม เช่น ต้องใช้คนกี่คนในการสร้างบริการเหล่านี้บน AWS หรือถ้าจะลดจากเดิม $48,000~$100,000 ให้เหลือ $24,000 ต้องใช้กำลังคนเท่าไร
คิดว่าแค่ชุด Prometheus, Grafana, Loki ก็สามารถจำลองหรือแม้แต่ทำได้ดีกว่าระดับการมอนิเตอร์ที่เคยได้จาก AWS เสียอีก น่าประหลาดใจเสมอที่ทั้ง ๆ ที่เครื่องมือเหล่านี้ยอดเยี่ยมมาก แต่บริการมอนิเตอร์ของ AWS กลับแพง ช้า และ UX ก็น่าผิดหวัง สำหรับฉัน ค่าใช้จ่ายด้านมอนิเตอร์เป็นส่วนที่ทำให้ประสบการณ์กับ AWS แย่และน่าหงุดหงิดที่สุดอย่างรวดเร็ว
ข้อเสียหลักของ Hetzner คือปัญหา IP ปนเปื้อนจากผู้ใช้ที่เป็นอันตราย และเรื่องฮาร์ดแวร์เสียหรือจำเป็นต้องอัปเกรด เลยสงสัยว่าไม่กังวลเรื่องนี้หรือ อีกอย่างคือแก้ปัญหาการใช้หน่วยความจำพุ่งของ Loki อย่างไร มีทางเลือกอื่นไหม
ปัญหา IP ปนเปื้อนแก้โดยพร็อกซีการเข้าถึงของผู้ใช้ผ่าน Cloudflare และตั้งค่าไฟร์วอลล์ (ufw) ให้รับการเชื่อมต่อได้เฉพาะจากแหล่งที่มาที่อนุญาตและ Cloudflare IP เท่านั้น ทำให้ปิดการเข้าถึงจากภายนอกโดยตรงไปเลย ส่วนฮาร์ดแวร์เสีย/การอัปเกรดก็เปลี่ยนเครื่องและขยายความจุได้อย่างรวดเร็วด้วย Terraform setup ใช้ Prometheus และ node exporter มอนิเตอร์ฮาร์ดแวร์เพื่อรับสัญญาณเตือนล่วงหน้า และในช่วง 9 เดือนที่ผ่านมาไม่มีเหตุขัดข้อง แอปแทบไม่มีข้อมูล ขณะที่ฐานข้อมูลมีการทดสอบกู้คืนบ่อย ๆ สำหรับปัญหา memory ของ Loki ก็แก้ด้วยการผสมหลายวิธี เช่น ปรับนโยบายการเก็บข้อมูลและการแยก index, tuning concurrency ของ query และ memory limit, ใช้ label แบบ promtail และ structured logging รวมถึงเก็บข้อมูลเก่าไว้ใน object storage backup หรือใช้ grep แทน
ปัญหา Loki ที่เราเจอมาจากการตั้งค่าดีพลอยเริ่มต้น เช่น helm default ที่ยังไม่ได้ปรับแต่งให้เหมาะพอ หลังจากทำตามเคล็ดลับด้านประสิทธิภาพที่พูดถึงในบล็อก เช่น รีเซ็ต index, เพิ่ม read-only instance และใช้คำแนะนำอื่น ๆ ก็เห็นการปรับปรุงประสิทธิภาพอย่างชัดเจน คิดว่ามีความตั้งใจจะผลักผู้ใช้ไปใช้บริการคลาวด์ของตัวเองมากกว่าโอเพนซอร์ส ดังนั้นช่วงแรกจึงต้องลองผิดลองถูกพอสมควร
ทางเลือกแทน Loki ขอแนะนำ Victoria เร็วกว่ามากและชื่อเสียงก็ดี แต่เราเลือก Loki เพราะคำนึงถึงความหลากหลายของผู้ดูแลรักษาโปรเจกต์ และใช้วิธีที่กล่าวไปข้างต้นมาชดเชยข้อเสีย
แชร์ลิงก์ https://en.wikipedia.org/wiki/Sybil_attack ข้อดีอย่างหนึ่งของผู้ให้บริการคลาวด์ราคาแพงคือมีชื่อเสียงด้าน IP ที่สร้างขึ้นคล้ายแนวทาง PoW (Proof of Work)
ISO 27001 เป็นมาตรฐานการจัดการความปลอดภัยสากลและเป็นแนวทางที่นิยมในยุโรป ในสหรัฐแทบไม่ได้ใช้ และหลายบริษัทในยุโรปมักยอมรับความต่างนี้ได้ไม่ดีนัก มาตรฐานความปลอดภัยพื้นฐานในสหรัฐคือ SOC 2 ซึ่งเข้มงวดน้อยกว่า ISO 27001 และคุ้นเคยกับตลาดอเมริกามากกว่า
ISO 27001 จริง ๆ แล้วไม่ได้เป็นมาตรฐานที่แข็งหรือละเอียดเกินไปนัก โดยทั่วไปมันแค่กำหนดสิ่งพื้นฐานที่ควรทำเมื่อใช้ซอฟต์แวร์ แต่ส่วนที่ยากคือการต้องมีเอกสารหลักฐานรองรับ ขณะที่ SOC 2 มีภาระเรื่องการเขียนเอกสารน้อยกว่ามาก
ในฐานะคนที่เคยผ่านทั้ง SOC 2 และ ISO 27001 รู้สึกว่างานตรวจ SOC 2 ขึ้นอยู่กับความสามารถและดุลยพินิจของผู้ตรวจมากเกินไป มากกว่าการดูการควบคุมการปฏิบัติงานจริง ส่วน ISO 27001 รู้สึกว่าชัดเจนและยุติธรรมกว่ามากในฐานะการตรวจสอบ
ลองยกตัวอย่างผู้ให้บริการคลาวด์รายใหญ่ของสหรัฐที่ไม่ได้รับการรับรอง ISO 27001 มาสักรายสิ
ฉันก็ทำโครงสร้างคล้ายกันบน Azure แล้วลดต้นทุนได้ 90% เหมือนกัน รู้สึกว่าบริษัทใหญ่ ๆ ตั้งใจบังคับให้คนต้องเจอกับประสบการณ์ abstraction ของบริการที่ซับซ้อน ทำให้การปฏิบัติการแบบง่าย ๆ ยิ่งทำได้ยากขึ้นเรื่อย ๆ
เหตุผลหนึ่งที่ยอมจ่าย AWS คือช่วยลดภาระด้านปฏิบัติการ และพอใช้ managed DB ของ AWS แล้ว ก็ไม่ต้องเครียดเรื่องอัปเกรด mysql cluster เหมือนสมัยก่อน แน่นอนว่าแค่เรื่องนี้อย่างเดียวคงอธิบายต้นทุนสูงไม่ได้ แต่ก็ถือว่ามีคุณค่ามากพอสมควร
ตัวเลขดูไม่สมเหตุสมผล จากปีละ $24,000 ลดไป 90% จะเหลือเดือนละ $200 ซึ่งแทบเท่าราคาเซิร์ฟเวอร์ Hetzner แค่เครื่องเดียว ถ้าเป็นแบบนั้นก็น่าจะใช้แค่ single server โดยไม่ต้องมี distributed system ก็พอ เลยอยากรู้ว่าปริมาณ request ต่อวินาทีหรือจำนวนผู้ใช้จริงเป็นเท่าไร
ถ้าจะให้สอดคล้องกับ ISO 27001 จะใช้ single server อย่างเดียวไม่ได้ และต้องมีเซิร์ฟเวอร์แยกสำหรับ log กับ monitoring ด้วย ความซับซ้อนจึงเกิดขึ้นไม่ว่าภาระโหลดจะมากหรือน้อย พนักงานไม่ได้ล็อกอินทุกวัน และด้วยลักษณะของแอปจัดตารางงาน หลายคนจะเข้ามาดูเพียงสัปดาห์ละ 1–2 ครั้ง DAU อยู่ที่ 10,000–20,000 คน ช่วงพีคมีผู้ใช้พร้อมกัน 1,500–2,000 คน และค่าเฉลี่ย concurrent user อยู่ที่ 50–150 คน สาเหตุที่ค่าใช้จ่ายคลาวด์สูงคือแอปมีภาระประมวลผลข้อมูลมากจากฟีเจอร์เรียลไทม์และกฎแรงงานที่ซับซ้อน ตัวอย่างเช่น การจัดกะทำงานมีความต่างของกฎการคำนวณโบนัส และการ optimize ตารางก็ใช้การคำนวณสูง
แก้ให้ถูกว่าไม่ใช่ $2,400 แต่เป็น $200
สงสัยว่าใช้ disk encryption อย่างไร บน AWS มันเป็นอัตโนมัติ แต่กับผู้ให้บริการโฮสต์ทั่วไปยังไม่ค่อยเห็นวิธีที่ทำได้ดี และถ้าเก็บ encryption key ไว้ใน boot partition มันก็แทบไม่มีความหมาย
ฉันชอบ Hetzner มากจนรัน search engine ของตัวเองอยู่ที่นั่นเลย คิดว่าการใช้ physical server นี่แหละดีที่สุด
นอกจาก OVH และ Hetzner แล้ว อยากแนะนำ UpCloud ในฐานะคลาวด์ยุโรปอีกเจ้า ข้อดีคือ CPU core ดูเหมือนจะเป็น core จริงทั้งหมด ไม่ใช่ vCPU (อิง thread) แม้จะเสียดายที่เอกสารอ้างอิงทางการยังมีไม่มาก การเทียบ OVH, Hetzner กับ HyperScaler นั้นไม่ง่าย เพราะในกรณีของ Hetzner ส่วนใหญ่ใช้ชิ้นส่วนเกรดผู้บริโภคจึงมีความต่างอยู่ แนะนำ UpCloud