คลัสเตอร์ Postgres ของ Fly.io ล่มนาน 3 วัน และยังไม่มีความคืบหน้าใด ๆ
(community.fly.io)- ระหว่างการทำ emergency maintenance บนโฮสต์ของ Fly.io ในเดือนกรกฎาคม 2023 เกิดกรณีขัดข้องที่ทำให้เครื่องของผู้ใช้หลายรายค้างอยู่ในสถานะ "stopped"·zombie และไม่สามารถรีสตาร์ต ลบ หรือ deploy ใหม่ได้
- บนแดชบอร์ดมีเพียงแบนเนอร์ "Service Interruption" แต่ไม่มีข้อมูลที่เกี่ยวข้องบน status page ทำให้ไม่สามารถทราบสาเหตุหรือ ETA การกู้คืนได้
- คำสั่ง fly machine ล้มเหลวด้วยข้อผิดพลาด "could not get machine" และพบข้อมูลผิดปกติ เช่น machine list แสดงวันที่สร้างเป็น "1970-01-01"
- บางรายกู้คืนชั่วคราวด้วยการเปิด VM ใหม่ผ่าน fly scale แต่ VM ที่เสียยังลบไม่ได้ จึงกังวลว่าจะยังถูก เรียกเก็บเงิน ต่อไป
- ผ่านไปเกิน 12~15 ชั่วโมงก็ยังไม่มีการตอบกลับหรืออัปเดตสถานะอย่างเป็นทางการ ส่งผลให้ ความน่าเชื่อถือของแพลตฟอร์ม ลดลง
การเกิดเหตุขัดข้องและอาการเริ่มต้น
- ตอนเช้า health check ของแอปเริ่มล้มเหลว และพบว่าเครื่องอยู่ในสถานะ "stopped"
- บนแดชบอร์ดมีเพียงแบนเนอร์ Service Interruption ที่ระบุว่า "We are performing emergency maintenance on a host some of your apps instances are running on" โดยไม่มีข้อมูลอื่น
- บน status page ไม่แสดงเหตุขัดข้องนี้ จึงหาแนวทางแก้ไขหรือ ETA ไม่ได้
- เมื่อลองรีสตาร์ตหรือลบ machine instance ที่หยุดอยู่ จะเกิด timeout
- ตอน deploy ใหม่เกิดข้อผิดพลาดเกี่ยวกับ unmanaged machine
fly deployจะอัปเดตเฉพาะเครื่องที่มีfly_platform_version=v2อยู่ใน metadata เท่านั้น ดังนั้นจึงต้องอัปเดตแต่ละเครื่องด้วยตนเองผ่านfly machine update --metadata fly_platform_version=v2 <machine id>
สถานะ zombie machine และวิธีหลบเลี่ยงปัญหา
- บางเครื่องเข้าสู่ "zombie mode" และทุกคำสั่ง fly machine จะตอบกลับด้วย "Error: could not get machine"
- มีการเพิ่ม VM ผ่าน fly scale เพื่อกู้คืนความพร้อมใช้งานของแอป แต่ VM ที่เสียยังค้างอยู่ในสถานะไม่แน่นอน ทำให้ลบไม่ได้และแม้แต่ลบบัญชีก็ทำไม่ได้
fly machine listแสดงข้อมูลผิด เช่น วันที่สร้างเป็น "1970-01-01T00:00:00Z"- ผู้ใช้อีกรายก็ใช้วิธี scale up เพื่อสร้างเครื่องใหม่เช่นกัน แต่เครื่องเดิมยังลบไม่ได้เพราะเกิดข้อผิดพลาด "connection refused"
- จึงกังวลว่าจะถูก คิดค่าบริการ ทั้ง VM zombie ที่ยังไม่ถูกเก็บกวาดและ VM ใหม่ที่สร้างเพิ่ม
- สภาพแวดล้อม staging ก็มีอาการเดียวกัน
ผลกระทบต่อคอนเทนเนอร์ฐานข้อมูล
- ผู้ใช้รายหนึ่งระบุว่าพบปัญหาเดียวกันมาตั้งแต่ประมาณ 14 ชั่วโมงก่อนหน้า และเนื่องจากเป้าหมายเป็น คอนเทนเนอร์ฐานข้อมูล จึงไม่สามารถกู้คืนได้ด้วยการ scale up อย่างเดียว
- แม้อยู่ใน แผนแบบชำระเงิน และส่งอีเมลหา support ไปเมื่อหลายชั่วโมงก่อน ก็ยังไม่ได้รับคำตอบ
- แอปดังกล่าวโฮสต์อยู่ใน รีเจียน syd จึงมีการตั้งข้อสังเกตว่าอาจมีปัญหาที่โฮสต์หนึ่งหรือสองเครื่องในพื้นที่นั้น
ผลกระทบเป็นวงกว้างและการกู้คืนชั่วคราว
- ก่อนหน้านี้จนถึงเมื่อวานมีการรัน เครื่อง 4 ตัว สำหรับแอป+Postgres (staging·production) แต่ยังมี 3 ตัวที่ล่มอยู่ รวมถึงฐานข้อมูล 2 ตัว
- เนื่องจากแอปนี้เป็น แอป External API ของบริษัท การเชื่อมต่อทั้งหมดจึงหยุดชะงัก
- เพื่อให้ระบบเดินต่อได้ มีการสร้างโปรเจกต์ใหม่บน Fly แล้วเปิด instance ใหม่ โดยใช้เวลาหลายชั่วโมงในการเติม environment variables และการตั้งค่ากลับเข้าไป
- กลายเป็นการทดสอบความสามารถ DR (disaster recovery) โดยไม่ตั้งใจ
- แม้จะไม่มีวิธีดึงข้อมูลออกจาก db machine แต่เพราะไม่ใช่ production db หลัก จึงกู้คืนสิ่งจำเป็นได้ด้วยการ ย้อนหาโครงสร้างและข้อมูลกลับมาใหม่
ความกังวลต่อความน่าเชื่อถือของแพลตฟอร์ม
- มีการแสดงความประหลาดใจที่ผ่านไป 12 ชั่วโมงแล้วก็ยัง ไม่มีการตอบกลับอย่างเป็นทางการ
- ผู้ใช้ระบุว่านี่เป็น ครั้งที่สอง ที่เจอปัญหาเดียวกัน และเมื่อบริการล่ม Fly ก็ยังรายงานว่าปกติพร้อมทั้งไม่มีข้อมูลหรือการตอบสนอง ทำได้เพียงรอ
- เปรียบเทียบกับ Heroku: หากโฮสต์ไม่เสถียร dyno จะถูกย้ายอัตโนมัติ จึงไม่ต้องกังวลแบบนี้
- ปัญหานี้เกิดขึ้นแม้กับแอปมาตรฐานขนาดเล็กแบบ Rails + Postgres ทำให้กังวลว่าหากเป็นแอปที่ซับซ้อนกว่านี้จะยิ่งรับมือได้ยาก
- ผู้ใช้ระบุว่าปัญหาเหล่านี้ทำลายความเชื่อมั่นต่อแพลตฟอร์มอย่างสิ้นเชิง
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
Fly ได้ตอบในเธรดซัพพอร์ตว่า: พวกเขาตรวจสอบฟอรัมเป็นประจำ แต่พลาดโพสต์นี้ไป และอธิบายว่าเกิด ความขัดข้องของโฮสต์เดี่ยว ในรีเจียน syd ที่ยืดเยื้อ
หลังรีสตาร์ตแล้วโฮสต์ไม่สามารถกลับมาทำงานปกติได้ และไม่ได้เชื่อมต่อกับ service discovery ด้วย จึงจำเป็นต้องกู้คืนด้วยตนเอง
แอปที่รันหลายอินสแตนซ์ได้รับผลกระทบเพียงบางอินสแตนซ์ แต่แอปที่มีอินสแตนซ์เดียวไม่สามารถเข้าถึงได้ตลอดช่วงขัดข้อง และ Fly แนะนำอย่างยิ่งให้ตั้งค่าเป็นหลายอินสแตนซ์
Fly ระบุว่าเหตุขัดข้องระดับทั่วโลก/ระดับรีเจียนจะถูกโพสต์บน status.fly.io ส่วนปัญหาโฮสต์เดี่ยวแสดงไว้ในแท็บสถานะบนแดชบอร์ดมาโดยตลอด แต่กำลังทบทวนวิธีสื่อสารสำหรับเหตุขัดข้องของโฮสต์เดี่ยวที่ยาวนานเช่นครั้งนี้
https://community.fly.io/t/service-interruption-cant-destroy...
รีสตาร์ตก็กู้คืนไม่ได้ จึงต้องกู้แบ็กอัปเก่าไปที่ RDS และรู้สึกว่าตัดสินใจถูกที่ย้ายออกมา
ยิ่งไปกว่านั้น ฟังดูเหมือนไม่ใช่คอนเทนเนอร์ผู้ใช้ตัวเดียว แต่เป็นบริการ PostgreSQL แบบ managed ดังนั้นการคาดหวังความทนทานต่อความขัดข้องของโฮสต์จึงดูสมเหตุสมผลกว่า
ผมจ่ายเดือนละราว $5~10 ได้ แต่จะไม่ใช้กับ side project ที่ไม่อยากเจอ เหตุขัดข้อง 3 วัน
[1] https://fly.io/docs/about/support/
ถ้าเหตุขัดข้องลากยาวหลายชั่วโมง ก็ควรใช้ Ansible หรืออะไรก็ได้เพื่อเปิดเครื่องใหม่ขึ้นมา ไม่ว่าจะเป็นฮาร์ดแวร์จริงหรือ VM บน AWS/GCP ก็น่าจะทำได้
Fly ดูเหมือนพยายามกลบปัญหานี้ โดยเปลี่ยนเธรด[1] ให้เป็น ส่วนตัว สำหรับคนที่ไม่ได้ล็อกอิน
ในเธรดมีกรณีที่บริการล่ม แต่สถานะของ Fly แสดงว่าปกติ ไม่มีข้อมูล และทำอะไรไม่ได้นอกจากรอ
ผู้ใช้อีกรายบอกว่าในเครื่องสี่เครื่อง ทั้งแอปและ PostgreSQL ของ staging/production ยังล่มอยู่สามเครื่อง และแอป API ภายนอกเสีย ทำให้การเชื่อมต่อทุกอย่างพังหมด
เขาบอกว่าการสร้างโปรเจกต์ Fly ใหม่เพื่อรันอินสแตนซ์ชั่วคราวใช้เวลาหลายชั่วโมง และหาวิธีดึงข้อมูลจากเครื่อง DB ไม่ได้
ยังมีปฏิกิริยาว่าการที่หน้าสถานะขององค์กรแสดงว่า “ไม่มีเหตุขัดข้อง” แต่ในหน้าเดียวกันกลับแสดงว่าแอปอยู่ระหว่างบำรุงรักษาและเข้าถึงไม่ได้นั้นรู้สึกเหมือนเป็นการดูถูก
มีโพสต์หนึ่งระบุว่าเป็นเวลา 17 ชั่วโมงแทบไม่มีการอัปเดตหน้าสถานะหรือการแจ้งเตือนใด ๆ และได้รับแค่การแจ้งเตือนจาก Better Stack
สำรองข้อมูลเธรดทั้งหมด: https://pastebin.com/ebmCSZkC
ทวีตที่ส่งถึง CEO ของ Fly: https://twitter.com/SouthPawNZ/status/1682181533673857024
[1] https://community.fly.io/t/service-interruption-cant-destroy...
สิ่งที่แย่ที่สุดของ Fly คือเวลามีอะไรผิดพลาด มันไม่ได้พังแค่อย่างเดียว แต่หลายอย่างพังพร้อมกัน และ หน้าแสดงสถานะกลับเป็นสีเขียวทั้งหมด
โดยปกติการตอบสนองก็มักเงียบ หรือมีท่าทีเบาเกินไปอย่าง “ถ้า deploy วันศุกร์ก็จะเกิดเรื่องแบบนี้แหละ”
ตัวผลิตภัณฑ์ดูเท่ แต่ให้ความรู้สึกเหมือนเอาบริการโฮสติ้งที่ไม่เสถียรที่สุดเท่าที่ผมเคยใช้มาห่อให้ดูสวย
จะทำให้งานของผู้คนพังทุกสัปดาห์ บังคับให้พวกเขาเสียเวลาคืนวันหยุดสุดสัปดาห์เพื่อกู้คืน แล้วจบด้วยคำว่า “เราน่าจะทำได้ดีกว่านี้” ไม่ได้ นั่นเป็นข้อแก้ตัวสำหรับเหตุการณ์ผิดปกติ ไม่ใช่สำหรับ แพตเทิร์นที่เกิดซ้ำ
ในเธรด HN นี้มีเสียงรบกวนเยอะ แต่ผมมองว่าแก่นเรื่องเป็นแบบนี้: ดูเหมือนพนักงานจะเห็นปัญหาตั้งแต่ก่อนที่ลูกค้าจะสังเกตเห็น และแม้หลังจากส่งอีเมลไปยังซัพพอร์ตแบบเสียเงินแล้ว ก็ยังใช้เวลาหลายชั่วโมงกว่าจะได้รับคำตอบ ส่วนอัปเดตเกี่ยวกับโฮสต์ที่ล่มก็เพิ่งออกมาหลังผ่านไปประมาณ 20 ชั่วโมง
ไม่มีการแจ้งผู้ใช้ที่ได้รับผลกระทบอย่างเหมาะสมว่าโฮสต์มีปัญหาหรือควรกู้คืนอย่างไร และใน dashboard แสดงว่ามีการบำรุงรักษาฉุกเฉิน แต่หน้า status กลับแสดงว่าทุกอย่างปกติ
ผมเข้าใจว่าด้วยลักษณะของแพลนและสถาปัตยกรรม downtime แบบนี้เป็นสิ่งที่การันตีว่าจะเกิดและพบได้บ่อย แต่ถ้าสื่อสารแย่แบบนี้ก็จะเสียลูกค้า
ถ้าเหมือนผู้ให้บริการรายอื่นที่ส่งอีเมลมาให้เมื่อโฮสต์ที่ผมใช้อยู่เริ่มมีอะไรผิดปกติเพียงเล็กน้อย อย่างน้อยผมก็ทำอะไรกับแอปของตัวเองได้ทันที
อย่างไรก็ตามยังมีความเห็นต่างกันว่าพวกเขารู้ตัวเพียงพอหรือไม่ว่าตนเองอยู่ในสภาพนั้น
มี outage ที่ยาวผิดปกติบนเซิร์ฟเวอร์เฉพาะเครื่องหนึ่ง และเมื่อปัจจัยเหล่านี้รวมกัน ก็ทำให้หลายคนเจอ outage ยาวโดยไม่มีคำอธิบาย
dashboard แสดงเฉพาะ outage ระดับ region/service ไม่ได้แสดง outage ของเซิร์ฟเวอร์รายเครื่อง ซึ่งผู้คนไม่รู้เรื่องนี้จึงมองเหมือนเป็นการโกหก
พฤติกรรมแปลก ๆ ของการตั้งค่า tag ใน Discourse ทำให้ดูเหมือนกำลังพยายามซ่อนปัญหา
สรุปคือ ผมมองว่านี่เป็นเหตุการณ์ที่โชคร้าย ขั้นตอนในมุมมองการดูแลลูกค้าแย่ และเอกสารอาจขาดบางส่วน แต่เป็นกรณีที่มีควันมากกว่าไฟ
ไทม์ไลน์ตามเวลา UTC คือ 2023-07-17 16:19 โฮสต์ล่ม, 16:49 เผยแพร่หน้า status แบบเฉพาะบุคคล, 2023-07-19 15:00 โฮสต์กู้คืน, 15:17 ระบุในหน้า status ว่าแก้ไขแล้ว
[1] https://community.fly.io/t/new-status-page/11398
Fly.io ไม่อยากเป็นโคลนของ Heroku แต่เพราะการตลาดและประสบการณ์ผู้ใช้ที่ขัดเกลามาดี สุดท้ายเลยดูเหมือนเป็นแบบนั้น
ผลคือพวกเขาต้องรับมือกับ ฐานผู้ใช้แบบ Heroku ที่สามารถสร้างความเสียหายต่อแบรนด์อย่างหนักได้ทุกครั้งที่โฮสต์เดี่ยวมีปัญหา
เพราะเป็นโปรเจกต์ส่วนตัวทำเล่น ๆ เลยไม่เป็นไร แต่ถ้าเป็นการใช้งานที่จริงจังกว่านี้ก็ไม่แน่ใจว่าจะใช้ได้สบายใจไหม
อีกอย่าง ผมยอมรับได้ยากว่ามีผู้ให้บริการคลาวด์จำนวนมากถึงขั้นเรียก downtime 20 ชั่วโมงว่า “การันตีว่าจะเกิดและเป็นเรื่องปกติ”
น่าเสียดายที่ในเธรด HN ที่เกี่ยวกับ Fly.io ผมมักรู้สึกถึง ความก้าวร้าวแบบอ้อม ๆ อยู่ค่อนข้างบ่อย
ผมอยากชอบ Fly.io มากจริง ๆ การตั้งค่าและใช้งานง่ายมาก แต่พูดตรง ๆ ผมไม่คิดว่าควรเอา แอปพลิเคชันระดับ mission-critical ไปวางบนบริการนี้
สุดท้ายก็ย้ายทั้งหมดไป AWS ทั้งที่จริง ๆ ไม่อยากทำแบบนั้นเลย
เครื่องมักไม่ทำงาน เกิดปัญหาแบบสุ่ม build ล้มเหลว และถึงจะจ่าย tier ที่สูงขึ้นเพื่อซัพพอร์ต ซัพพอร์ตก็ตอบช้าและไม่ได้อ่านคำถามให้ดี
เพิ่ม sidecar ไม่ได้ ผสานกับ monitoring ภายนอกได้ยาก และเอกสารก็โอเคสำหรับเส้นทางปกติ แต่ขาดมากในกรณี edge case
สำหรับโปรเจกต์งานอดิเรกถือว่าโอเค และตอนนี้ผมก็ยังเอาโปรเจกต์ส่วนตัวขึ้นไว้หลายตัว แต่สำหรับโครงสร้างพื้นฐานของบริษัท ต้นทุนด้านเวลาและความหงุดหงิดสูงเกินไปจนต้องย้าย
ฟังดูเหมือนผู้สืบทอดทางจิตวิญญาณของ Heroku เลยคาดหวังไว้มาก แต่ผมว่ายังไม่ถึงระดับนั้น
สัปดาห์ก่อนหน้านั้นยัง build ได้ และในเครื่องก็ทำงานได้ดี ต่อมาบน Fly ก็กลับมาใช้ได้อีกครั้ง แต่เป็น downtime ที่เข้าใจไม่ได้ ไม่มีคำอธิบายสาเหตุและไม่มีคำตอบจากซัพพอร์ต
tier ฟรีใจกว้างมาก ทำอะไรได้เยอะภายใต้เพดานค่าใช้จ่าย แต่เวลาว่างของผมน้อย และในเวลานั้นผมแค่อยาก build โปรเจกต์
ทั้งที่เป็นแค่เว็บ static เล็ก ๆ ที่ build ด้วย Node ก็ยังเป็นแบบนั้น
ตัวเครื่องมือเองยอดเยี่ยม ถ้า infra เสถียรขึ้นก็อยากกลับไปลองใช้อีก
ถ้าใช้ความพยายามเท่ากันแล้วยังเอาข้อมูลนั้นไปใส่ในเอกสารไม่ได้ ก็ไม่รู้ว่า documentation pipeline แย่แค่ไหน
คำตอบของคำถามในฟอรัมเกี่ยวกับการใช้งานควรเป็น “อยู่ในเอกสารแล้ว ถ้าไม่มีก็เพิ่งเพิ่มให้แล้ว” และ “ถ้ายังสับสนบอกเราได้ เราจะอัปเดตเอกสาร”
ต้องไปขุดดู fly logs เองถึงเห็นว่า proxy ติดต่อเซิร์ฟเวอร์ไม่ได้ และผมก็ไม่มีวิธีแก้เอง
หลายชั่วโมงต่อมาโพสต์ issue ในฟอรัม แต่ไม่มีคำตอบและไม่มีร่องรอยว่ามีใครอ่าน แล้วไม่นานมันก็กลับมาแก้ได้เองราวกับเวทมนตร์
ผมอยากให้เขาประสบความสำเร็จ แต่เพราะ การขาดการสื่อสาร แบบนี้และความรู้สึกไร้อำนาจที่ทำอะไรไม่ได้ ทำให้ช่วงนี้คงไม่ใช้ fly.io
คำตอบนี้อาจไม่น่าพอใจอย่างมาก แต่เท่าที่ผมพูดเป็นการส่วนตัวได้ก็มีประมาณนี้: ผมไม่รู้เลยว่าทำไมเธรดนี้ในไซต์ชุมชนของเราถึงถูกเอาออกจากรายการ
ผมกำลังดู UI ผู้ดูแลระบบอยู่ และมีรูปแม่กุญแจเล็ก ๆ ข้างโพสต์ แต่ตัวเลือก “unlist story” ก็ยังคลิกได้อยู่
สิ่งที่ผมพูดได้ดีที่สุดคือ ผมค่อนข้างมั่นใจว่าไม่ได้มี คำสั่งจากเบื้องบน ให้ซ่อนเธรดนี้ ไซต์เป็นสาธารณะ และใครก็สร้างบัญชีเพื่อดูเธรดได้
จะว่าเราอย่างไรก็ได้ แต่การหลบซ่อนเรื่องแบบนี้ไม่ใช่หนึ่งในข้อเสียของเรา
สำหรับปัญหาเซิร์ฟเวอร์ Sydney ผมยังไม่รู้มากพอ จึงยังให้คำตอบที่เป็นประโยชน์กับคนที่รันอินสแตนซ์อยู่บนนั้นไม่ได้ ผมเพิ่งกลับมาจากข้างนอกและกำลังเริ่มไล่ดูอยู่
ตอนนี้ผมเห็นแล้วว่าโพสต์ทั้งหมดในหมวด app-not-working ดูเหมือนเป็น “private” และคงเป็นการตั้งค่าหมวดหมู่ ในที่นี้ private หมายถึงต้องสมัครบัญชี Discourse ถึงจะดูได้
โทนของคำตอบนี้และการสื่อสารอื่น ๆ ของ fly.io ดูเป็นสัญญาณว่ายังขาดองค์ประกอบเหล่านั้น เมื่อพิจารณาจากกระแสความเห็นต่อ fly.io
ถ้ามีพนักงานมากกว่า 60 คนและมีปัญหามากขนาดนี้ มันไม่ได้ดูเป็นโทนที่เป็นกันเองแบบมนุษย์ แต่ดูเหมือนสัญญาณของธุรกิจที่ขยายขนาดไม่ได้
ธุรกิจ B2B ที่กำลังเติบโตจะประสบความสำเร็จได้ต้องมีสิ่งอย่างกระบวนการและการกำกับดูแล แต่ดูจากคำตอบอื่น ๆ เหมือนว่าพวกคุณไม่ต้องการสิ่งนั้น ซึ่งเป็นสัญญาณไม่ดี
พังครั้งหนึ่งคืออุบัติเหตุ พังสองครั้งคือโชคร้าย แต่พังสามครั้งคือกระบวนการเสียแล้ว จากคอมเมนต์ที่นี่ ดูเหมือนที่ Fly.io จะพังบ่อยกว่าสามครั้งมาก
ไม่ใช่เพราะเหตุขัดข้องเอง แต่เพราะอาจต้องใช้เวลา หลายวันกว่าจะได้รับการซัพพอร์ต
คุณให้การรับประกันอะไรกับชุมชนได้บ้างว่าครั้งหน้าการซัพพอร์ตจะดีขึ้น?
เราใช้ Fly.io รัน https://changelog.com มาตั้งแต่เดือนเมษายน 2022 และสถาปัตยกรรมปัจจุบันอยู่ที่ https://github.com/thechangelog/changelog.com/blob/master/IN...
ตลอด 15 เดือน เราประมวลผล คำขอมากกว่า 100 ล้านครั้ง ด้วยแอป Phoenix + PostgreSQL บน Fly.io แต่แทบหาเหตุผลให้บ่นไม่ได้
มีการ deploy บางครั้งล้มเหลวและแก้ด้วยการรัน pipeline ใหม่, ช่วงต้นเดือนกรกฎาคม 2023 ที่ Frankfurt มีคำขอ 9,000 ครั้งคืนค่า 503 นาน 10 วินาที และมี volume หนึ่งที่ไม่ยอมถูกลบระหว่างทดลอง machines แล้วหายไปในวันถัดมา เท่านั้นเอง
เราพูดถึงประสบการณ์กับ Fly.io บ่อย ๆ ในพอดแคสต์ Kaizen: https://changelog.com/topic/kaizen
เอพิโซดประกาศการย้ายระบบ: https://changelog.com/shipit/50
PR ที่เกี่ยวข้อง: https://github.com/thechangelog/changelog.com/pull/407
เราเพิ่งพูดถึงแผนย้ายจาก apps v1(Nomad) ไป apps v2(flyd) ด้วย: https://changelog.com/friends/2#transcript-138
น่าเสียดายที่หลายคนไม่ได้มีประสบการณ์ที่ดี แต่ผมคิดว่า Fly.io จะดีขึ้นเรื่อย ๆ หวังว่าวันหนึ่งช่วงเวลาที่ยากลำบากแบบนี้จะกลายเป็นเรื่องเล่าดี ๆ
บทความที่ให้ความหวัง: https://community.fly.io/t/reliability-its-not-great/11253
ผมชอบ fly.io มากและอยากให้ประสบความสำเร็จ พวกเขากำลังทำเรื่องยากอยู่ ดังนั้นมันพังได้
แต่ การขาดการสื่อสาร นั้นน่าผิดหวัง โดยเฉพาะเพราะในเดือนมีนาคม CEO เคยโพสต์บทความใหญ่เรื่องความน่าเชื่อถือในชุมชน และชี้ชัดเองว่าเป็นส่วนที่อยากแก้ไข จึงยิ่งน่าเสียดาย
https://community.fly.io/t/reliability-its-not-great/11253#s...
เราแสดงเหตุขัดข้องของโฮสต์เดี่ยวบนแดชบอร์ดของผู้ใช้ที่ได้รับผลกระทบ และสะท้อนปัญหาระดับแพลตฟอร์ม/รีเจียนไว้ในหน้า status page มาโดยตลอด แต่เห็นชัดว่ามี พื้นที่ก้ำกึ่ง ที่สถานะที่เราสื่อสารออกไปไม่ตรงกับประสบการณ์จริงของผู้ใช้
ช่วงหลังเราเพิ่มฮาร์ดแวร์จำนวนมากเพื่อหลีกเลี่ยงปัญหาความจุ และตามที่คาดไว้ ความน่าจะเป็นของเหตุขัดข้องโดยรวมลดลง แต่ปริมาณเหตุขัดข้องในรูปของฮาร์ดแวร์กลับเพิ่มขึ้น
เรายังทำได้มากกว่านี้ ทั้งในการช่วยผู้ใช้หลีกเลี่ยงปัญหาเหล่านี้ การเร่งความเร็วในการกู้คืน และการแจ้งให้ดีขึ้นเมื่อผู้ใช้ได้รับผลกระทบ
ต่อให้เราพลาดเรื่องการสื่อสาร เราก็รับฟังฟีดแบ็กแบบนี้อยู่
สัญญาณอันตรายที่ใหญ่กว่าคือ Fly ดูเหมือนจะไม่มี วิธีอัตโนมัติ สำหรับย้ายเวิร์กโหลดจากเซิร์ฟเวอร์ที่เสียไปยังเซิร์ฟเวอร์ปกติได้อย่างรวดเร็ว
ทั้งที่คอนเทนเนอร์และออร์เคสเตรเตอร์ได้ทำ abstraction แนวคิดของ data volume ที่เชื่อมต่อ/ถอดออกได้แล้วก็ตาม
แน่นอนว่าการให้บริการแบบนี้ต้องลงทุนทางเทคนิคสูง และผมมองว่านี่เป็นหนึ่งในเหตุผลที่สตอเรจบนคลาวด์ Big 3 มีราคาแพง แต่ถ้าจะให้บริการ data persistence ก็เป็นความสามารถที่จำเป็นต้องมี
มีความไม่สอดคล้องกันระหว่างสิ่งที่ Fly อยากให้บริการกับสิ่งที่ตลาดคาดหวัง
Fly ต้องการนวัตกรรมที่ทำให้รันแอปได้ในหลายดาต้าเซ็นเตอร์ แต่หากไม่มี บริการ data persistence ที่ดีจริง ฟีเจอร์นั้นก็ไม่ค่อยมีประโยชน์สำหรับคนส่วนใหญ่
ดูเหมือนจะพยายามแก้ปัญหา persistence ด้วยการทำ replication ของ SQLite แต่แบบนั้นนักพัฒนาส่วนใหญ่ก็ต้องเปลี่ยนวิธีพัฒนาแอปให้เข้ากับแพลตฟอร์มของ Fly
Fly ต้องเลือกว่าจะเป็นทางเลือกแทน Heroku ที่เสถียรและราคาถูก หรือจะเสนอวิธีพัฒนาแอปแบบเฉพาะตัวที่ให้ประสิทธิภาพดีที่สุดแก่ผู้ใช้ทั่วโลก
App Engine เป็นกรณีศึกษาที่น่าสนใจ มันมาก่อนยุค และกำหนดแนวทางการพัฒนาที่สเกลได้ถึงทราฟฟิกสูงมาก แต่ผู้คนไม่อยากเปลี่ยนวิธีพัฒนาให้เข้ากับมัน
ตอนนี้ดูเหมือนกำลังลนลานแบบดับไฟหนึ่งกองเสร็จก็มีอีกกองลุกขึ้นมา จึงไม่ค่อยเชื่อมั่นในโรดแมปทางเทคนิค
หลายคนใส่ Fly.io ไว้ในลิสต์ “ค่อยกลับมาดูทีหลัง” มาราว 2 ปีแล้วไม่ใช่หรือ?
ถ้าผู้คนรับรู้ว่าไม่เสถียร การกู้ชื่อเสียงกลับมาทำได้ยากจริง ๆ โดยเฉพาะในวงการ IT
data persistence ทำผ่านการส่งออก LVM snapshot รายวันหรือ snapshot ที่สร้างเองไปยัง S3
ผมคิดว่ามันไม่ใช่ที่สำหรับรันเวิร์กโหลดที่ต้องการ persistence จริง ๆ ถ้าจะรัน PostgreSQL ที่นั่น ก็ต้องเตรียมพร้อม hot load ข้อมูลไปยังอินสแตนซ์ใหม่ หรือกู้คืนจากแบ็กอัป
ด้วยเหตุผลเดียวกันนี้ ผมบอกบน HN มานานแล้วว่าอย่าใช้ Fly: https://news.ycombinator.com/item?id=31394179
หลังจากขอลบบัญชี บัญชีของผมก็กลายเป็นสถานะคล้ายถูก shadow ban โดยไม่มีการสื่อสารใด ๆ
ผมส่งอีเมลไปแล้ว แต่จนถึงตอนนี้ก็ไม่เคยได้รับคำตอบ และหลังจากนั้นก็ย้ายทั้งหมดไป Railway apps กับ Google Cloud Run
บริษัทจะ shadow ban ทำไมเพียงเพราะคุณถามคำถามที่ไม่เป็นอันตราย?
สิ่งที่น่าสนใจคือรู้สึกเหมือนประวัติศาสตร์กำลังซ้ำรอยที่ Fly.io คล้ายกับตอนที่ได้เจอ Heroku ครั้งแรก
Fly.io ในช่วงแรกสดใหม่และน่าสนใจเหมือนตอน Heroku เพิ่งปรากฏตัว และผมประทับใจกับความเรียบง่ายกับการใช้งานที่ง่าย
แต่เมื่อเวลาผ่านไป ก็เริ่มเห็นสัญญาณปัญหาเล็ก ๆ น้อย ๆ downtime ถี่ขึ้น และการ deploy ที่เคยเร็วและลื่นไหลก็ช้าลงจนทรมาน
เหมือนเป็น เดจาวู จากช่วงที่ข้อดีของ Heroku เริ่มหายไป
ยิ่งมีคนแห่เข้ามาใช้แพลตฟอร์มมากขึ้น ประสิทธิภาพก็ยิ่งแย่ลง และยิ่งได้รับความนิยมมากขึ้นก็ยิ่งดูไม่เสถียร น่าเสียดายที่ Fly.io ดูเหมือนกำลังเดินตามเส้นทางนั้น
มันรู้สึกเหมือนเป็นเรื่องเตือนใจว่าแพลตฟอร์มที่มีอนาคตก็ตกต่ำได้อย่างไร และหวังว่า Fly.io จะหลุดจากวังวนนี้และตั้งหลักได้ ก่อนจะไร้ประโยชน์เหมือนช่วงตกต่ำที่สุดของ Heroku
ผมสงสัยว่าอาจประเมินจิตสำนึกของวงการสูงเกินไป และถ้ามันเป็นที่รู้จักกว้างขวางเหมือน Heroku ก็เห็นชัดว่าจะมีคนที่ไม่อยากจ่ายเงินแห่เข้ามา
ถ้าจะลองให้บริการฟรีแบบใจกว้างอีกครั้ง ก็ต้องมี องค์กรป้องกันการใช้งานผิดวัตถุประสงค์ ที่แข็งแกร่งและมีต้นทุนสูง หรือมีทุนหนาพอจะเทฮาร์ดแวร์ลงไปเพื่อรับมือกับช่วงแรกที่ยังไม่มีสิ่งนั้น
Fly ดูไม่แข็งแกร่งในทั้งสองด้าน ซึ่งก็เป็นเหตุผลหนึ่งที่ผมชอบมัน สิ่งเหล่านั้นดูเหมือนความวุ่นวายแบบบริษัทใหญ่ และ Fly มีกลิ่นแบบนั้นน้อยกว่า
แต่ผมก็ไม่แปลกใจถ้าวิศวกรของ Fly ใช้เวลาส่วนใหญ่ไปกับการจัดการนักขุดคริปโตฟรีไรเดอร์ มิจฉาชีพ และผู้ใช้งานในทางที่ผิด รวมถึงปรับ allocation ของ resource และการจำกัดอัตโนมัติ แทนที่จะทำงานด้านความน่าเชื่อถือของโครงสร้างพื้นฐานระยะยาวหรือประสบการณ์นักพัฒนา
สงสัยว่ามันเกี่ยวกับขนาดหรือเปล่า พอบริษัทมีลูกค้าจ่ายเงินมากพอจนเริ่มมีกำไรหรือดึงดูดการลงทุนได้ ในเวลาเดียวกันปัญหาก็สะสมมากพอจนค่อย ๆ เปลี่ยนจากความรู้สึกสดใหม่และน่าสนใจในตอนแรก ไปเป็นเหมือนคู่แข่งเก่า ๆ ที่ตั้งใจจะมาแทนที่หรือเปล่า?
ประสบการณ์ของผมก็เป็นแบบนั้น เมื่อบริษัทโตจากระดับพิซซ่าไม่กี่ถาดไปถึงระดับ “จองสถานที่จัดงานแล้ว” entropy ก็เริ่มซึมเข้ามา และคติอย่าง กฎของ Conway หรือกฎของ Brooks ก็ยิ่งชัดเจนขึ้น