จาก FileStack ไปสู่ S3: สิ่งที่ได้จากการย้ายระบบที่ดูเหมือนไม่มีอะไร

บทความสรุปปัญหาและกระบวนการแก้ไขที่เกิดขึ้นระหว่างการรวมการอัปโหลดโลโก้บริษัท/รูปโปรไฟล์ซึ่งเดิมพึ่งพา FileStack เข้าสู่ S3

ที่มาของการนำมาใช้

• ในช่วงแรก FileStack ช่วยลดเวลาในการสร้าง “ฟีเจอร์อัปโหลดที่ไม่ใช่แกนหลัก” ได้มาก และใช้งานในโปรดักชันได้อย่างไม่มีปัญหามาเป็นเวลานาน
• เมื่อเวลาผ่านไป อินฟราสตรักเจอร์ S3 พร้อมแล้ว แต่ยังคงมีเฉพาะโลโก้/โปรไฟล์ที่อยู่บนบริการภายนอก ซึ่งเริ่มทำให้รู้สึกคาใจ
• ในสภาพแวดล้อม Dev/ทดสอบ มักเกิดปัญหารูปเสียบ่อยจาก FileStack Rate Limit

ปัญหา

• เมื่อต้องพัฒนาแบบโลคัลโดยใช้ AWS S3 ก็มีความไม่สะดวกจากการหมดอายุของโทเค็นชั่วคราว STS, การพึ่งพาเครือข่าย, และอุปสรรคในการ onboarding
• กับดักที่เกือบพลาดระหว่างการย้ายระบบ: โลโก้ในอีเมลอาจเสียภายหลังได้เพราะ presigned URL TTL หมดอายุ

วิธีแก้

• ทำให้การพัฒนาแบบโลคัลง่ายขึ้นด้วย MinIO (รองรับ S3 API และตั้งค่าได้ง่ายด้วย Docker)
• สำหรับโลโก้ในอีเมล แยกวิธีจัดการโดยคง bucket เป็น private ไว้ และเปิดเผยเฉพาะเส้นทาง public/* ผ่าน CloudFront

ทำไมถึงทำครั้งนี้

• ปกติแล้ว “การปรับปรุงระบบ legacy” มักถูกเลื่อนเพราะปัญหาเรื่อง ROI แต่ครั้งนี้ตัดสินใจว่า “น่าลองทำ” เพราะเครื่องมือเขียนโค้ด AI ช่วยลดต้นทุนการลองผิดลองถูก
• พูดตรง ๆ ว่าถ้าไม่มี AI ก็คงไม่ได้ลอง

สิ่งที่ได้เรียนรู้

• FileStack ไม่ใช่ตัวเลือกที่แย่ แต่ในตอนนั้นมันคือตัวเลือกที่ดีที่สุด และประเด็นที่สำคัญกว่าคือ “จะถอดมันออกเมื่อไร”
• เมื่อสถานการณ์เปลี่ยนก็ถอดออกได้ และเครื่องมือ AI ก็กำลังทำให้คำว่า “ไว้ทีหลัง” นั้นทำได้ง่ายขึ้น