ทำตามคู่มือทางการของ AWS Amplify แล้วโดนเรียกเก็บเงิน $1,100

 (elliott-king.github.io)
1 คะแนน โดย GN⁺ 2024-11-15 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • หลังทดลองตาม คู่มือทางการสำหรับการเชื่อมต่อ OpenSearch ของ AWS Amplify ค่าใช้จ่ายของ Amazon OpenSearch Service ก็พุ่งขึ้นไปถึง $1,124.88 ต่อเดือน ทั้งที่ใช้งานไม่ได้มากนัก
  • สาเหตุของค่าใช้จ่ายคือ OpenSearch domain ที่ npx ampx sandbox สร้างไว้ยังคงอยู่แม้จะปิดหรือลบ sandbox แล้ว และเมื่อรันใหม่ก็มีการเพิ่มโดเมนใหม่ ทำให้ค่าใช้จ่ายสะสม
  • การตั้งค่าอย่างเป็นทางการจะสร้างอินสแตนซ์ r5.large.search เป็นค่าเริ่มต้น และค่าใช้จ่ายพื้นฐานขั้นต่ำ $134 ต่อเดือน นี้ไม่ได้แสดงชัดเจนในโค้ด boilerplate หรือในคู่มือ
  • AWS Support ได้ให้ เครดิตแบบครั้งเดียว สำหรับ OpenSearch และ storage และขอให้ตั้งค่า AWS Budgets เพื่อป้องกันไม่ให้เกิดซ้ำ
  • หากใช้ Amplify ร่วมกับ OpenSearch ควรตรวจสอบทรัพยากรที่ยังค้างอยู่หลังลบ sandbox และตรวจสอบประเภทอินสแตนซ์เริ่มต้นด้วยตนเอง เพื่อหลีกเลี่ยงการถูกคิดค่าบริการที่ไม่คาดคิด

ค่าใช้จ่าย OpenSearch ที่ไม่คาดคิด

  • หลังทำตาม คู่มือทางการสำหรับการเชื่อมต่อ OpenSearch บน AWS Amplify แล้ว ไม่กี่สัปดาห์ต่อมาใบแจ้งหนี้ AWS ก็ออกมามากกว่า $1,200
  • บริการที่ระบุในคำขอ Support คือ Amazon OpenSearch Service และยอดรวมทั้งเดือนอยู่ที่ $1,124.88
  • ผู้เขียนเคยใช้ Amplify และ OpenSearch มาก่อนในปี 2020 และมองว่าสำหรับการใช้งานส่วนตัวปกติแล้วแม้จะแพงก็อยู่ราว $50 ต่อเดือน ไม่ใช่ระดับ $1,200
  • หลังตรวจสอบรายละเอียด AWS Customer Support ได้ดำเนินการปรับยอดเรียกเก็บเงินในลักษณะ one time courtesy สำหรับค่าใช้จ่ายที่ไม่คาดคิด
  • ระหว่างกระบวนการ Support มีการให้เครดิตสำหรับ OpenSearch และบริการ storage และยังขอให้ตั้งค่า AWS Budgets
    • AWS Budgets สามารถคาดการณ์ค่าใช้จ่ายล่วงหน้าทั้งสำหรับบริการเฉพาะหรือทั้ง AWS และส่งการแจ้งเตือนเมื่อคาดว่าจะเกินงบได้

ทรัพยากรที่คู่มือทางการสร้างขึ้น

  • quickstart ของ Amplify จะสร้างแอปตัวอย่างสำหรับ TODO notes ด้วยโค้ดที่ AWS ให้มา และ Amplify จะสร้าง ฐานข้อมูล DynamoDB พร้อมคำขอ CRUD ที่มีการยืนยันตัวตน
  • สามารถรันแบบโลคัลได้ แต่ Amplify ยังสร้าง โดเมน ที่เข้าถึงได้ขึ้นมาด้วย
  • ในขั้นตอนตั้งค่า OpenSearch จะต้องเขียน boilerplate TypeScript เพื่อประกาศทรัพยากรของ Amplify
    • กำหนดตาราง DynamoDB เป็นตัวแปรเพื่ออ้างอิงใน pipeline
    • สร้างอินสแตนซ์ OpenSearch, index และ indexMapping
    • เขียนคิวรีสำหรับเข้าถึงข้อมูลที่อยู่ใน OpenSearch
    • สร้าง OpenSearchIngestionService pipeline เพื่อคัดลอกข้อมูลจาก DynamoDB ไปยัง OpenSearch
  • การตั้งค่าที่เกี่ยวข้องถูกจัดการใน TypeScript/JavaScript ภายใน repository ร่วมกับโค้ดฝั่งฟรอนต์เอนด์
  • npx ampx sandbox จะเปิดบริการ AWS ขึ้นมาและตรวจจับการเปลี่ยนแปลงของการตั้งค่าเพื่อแก้ไขบริการ AWS เดิมโดยอัตโนมัติ

โดเมนที่ยังค้างอยู่แม้ลบ sandbox แล้ว

  • การตั้งค่านี้ประกอบด้วยทรัพยากรหลายอย่าง เช่น ฐานข้อมูล DynamoDB, บริการ OpenSearch 1 ตัว, OSIS pipeline 1 ตัว, IAM roles และอื่น ๆ
  • boilerplate อย่างเป็นทางการจะสร้างอินสแตนซ์ OpenSearch แบบ r5.large.search โดยค่าเริ่มต้น
    • ค่าเริ่มต้นนี้ไม่ได้ถูกแสดงอย่างชัดเจนในโค้ด boilerplate หรือในคู่มือ
    • r5.large.search มีค่าใช้จ่ายขั้นต่ำ $134 ต่อเดือน
  • เมื่อจบงานในวันนั้นแล้วหยุด sandbox ด้วย CTRL-C จะมีพรอมป์ต์ถามว่าจะลบถาวรหรือไม่ และผู้ใช้สามารถเลือก Y ได้
  • แต่ในกรณีนี้ DynamoDB ถูกลบ ขณะที่ OpenSearch domain ยังปรากฏค้างอยู่ใน AWS console
  • เมื่อลองรัน npx ampx sandbox ใหม่ในวันถัดไป ก็จะมีการสร้างอินสแตนซ์ OpenSearch ใหม่ และ npx ampx sandbox delete ก็ไม่ลบอินสแตนซ์เดิม
  • หากทำขั้นตอนเดิมซ้ำไปเรื่อย ๆ ก็จะมี หลาย OpenSearch domain ค้างอยู่เบื้องหลังในโปรเจ็กต์เดียวกัน และค่าใช้จ่ายจะสะสมเพิ่มขึ้น

ความเป็นไปได้ของบั๊กและประเภทอินสแตนซ์เริ่มต้น

  • พฤติกรรมนี้ดูเป็น footgun ครั้งใหญ่ และแม้หลังเปิดทิกเก็ตกับ AWS Support แล้ว ในเวลานั้นก็ยังไม่ได้รับการแก้ไข
  • มีรายงานบั๊กเก่าที่เกี่ยวข้องอยู่ แต่ไม่พบรายการในช่วง 1 ปีที่ผ่านมา
  • มีความเป็นไปได้ว่า OpenSearch domain เคยถูกลบได้ถูกต้องใน v1 แต่ไม่เป็นเช่นนั้นใน v2 อย่างไรก็ตามยังไม่ใช่สาเหตุที่ยืนยันแล้ว
  • ปัจจุบัน flow นี้ไม่ได้รันผ่าน Amplify CLI แต่รันผ่าน npx
  • การที่ r5.large.search เป็นประเภทเครื่องเริ่มต้นก็ยังเป็นปัจจัยเสี่ยง
    • มองว่าการกำหนดให้เป็นฟิลด์บังคับโดยไม่มีค่าเริ่มต้นจะดีกว่า
    • หากคู่มือแสดง r5.large.search เป็นค่าเริ่มต้นอย่างชัดเจน ผู้ใช้ก็น่าจะสังเกตได้ง่ายขึ้น
    • ค่าเริ่มต้นนี้ไม่ได้เป็นของ Amplify โดยเฉพาะ แต่เป็นส่วนหนึ่งของ AWS CDK จึงไม่มองว่าเป็นความรับผิดชอบของทีม Amplify เพียงฝ่ายเดียว

ข้อควรระวังเมื่อใช้ Amplify กับ OpenSearch

  • แม้จะคาดไว้ว่าเครื่องมือที่ช่วยเร่งการพัฒนาด้วยเทคโนโลยีใหม่อาจมีค่าใช้จ่ายสูงกว่า bare metal แต่ค่าใช้จ่ายครั้งนี้ถือว่าเกินกว่านั้นมาก
  • หากใช้ budget console ของ AWS ก็สามารถรับคำเตือนได้เมื่อคาดว่าค่าใช้จ่ายจะเกินงบ
  • แม้ทำตามเฉพาะส่วน OpenSearch ก็ยังมีการสร้าง IAM account, OpenSearch domain, OSIS pipeline, log group และ S3 storage ทำให้มีทรัพยากรแฝงจำนวนมาก
  • OpenSearch เป็นบริการที่ลูกค้าองค์กรใช้งานกันบ่อย จึงอาจถูกมองว่าเป็นบริการ “ระดับสูง” และอาจคาดหวังว่าผู้ใช้จะเข้าใจระบบนิเวศของ AWS มากกว่าเดิม
  • ผู้เขียนใช้ OpenSearch เพราะต้องการรองรับ geo_point bounding-box query แต่ก็ยังไม่แน่ใจว่าจะใช้ผลิตภัณฑ์ที่เรียบง่ายกว่านี้แทนได้หรือไม่
  • ตามอัปเดต คู่มือของ AWS ได้ถูก แก้ไข ในภายหลัง และแม้จะยังไม่อัปเดตในช่วง 3 เดือนก่อนที่ผู้เขียนจะเริ่มตั้งคำถาม แต่ดูเหมือนว่ามีการเริ่มทำเอกสาร PR ก่อนบทความนี้เผยแพร่

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-11-15
ความคิดเห็นบน Hacker News

  • การแจ้งเตือนการเรียกเก็บเงินแทบจะเป็นเรื่องตลก สิ่งที่ควรมีจริง ๆ คือ ขีดจำกัดการใช้จ่ายแบบตายตัว
    และระหว่างการเริ่มใช้งานก็ควรมีวิธีตั้งค่าขีดจำกัดนั้นให้ด้วย
    การสร้างธุรกิจบนเช็คเปล่าและการคิดเงินโดยไม่ตั้งใจนั้นดูน่าสงสัย และยังเป็นอุปสรรคต่อการเริ่มใช้งานอย่างมาก
    ยิ่งนักพัฒนาเห็นกรณีอย่าง “ทำตามบทเรียน 20 นาทีแล้วโดนเรียกเก็บเงินเท่าเงินเก็บทั้งชีวิต ครั้งนี้ฝ่ายซัพพอร์ตยกเว้นให้ แต่ครั้งหน้าดูท่าจะเอาบ้านไปด้วย” ก็ยิ่งไม่อยากลองสำรวจผลิตภัณฑ์ของ AWS

    • ไม่ใช่ปัญหาเฉพาะ AWS และดูเหมือนผู้ให้บริการคลาวด์โดยทั่วไปมีอยู่แค่สองแบบ
      แบบที่ ผลักความเสี่ยงให้ลูกค้า อย่าง AWS หรือ DigitalOcean กับแบบที่ขายแพ็กเกจราคา “ไม่จำกัด”·“ไม่คิดตามมิเตอร์” ที่น่าสงสัย
      ทั้งสองแบบไม่ใช่สิ่งที่ต้องการ
      อยากให้มีผู้ให้บริการที่ทำให้วางแผนความจุได้อย่างถูกต้องด้วยขีดจำกัดที่ชัดเจนและมีเอกสารกำกับ โดยลูกค้ารับความเสี่ยงด้านความพร้อมใช้งาน แต่ ผู้ให้บริการรับความเสี่ยงด้านการเงิน
      ถ้าไม่แพงเกินไป ก็ยินดีจ่ายค่าบริการคงที่ที่สูงขึ้น
    • ขีดจำกัดการใช้จ่ายแบบตายตัวแทบจะให้ผลตรงข้ามกับลูกค้าหลักของ AWS คือ ลูกค้าองค์กรขนาดใหญ่
      แทบไม่มีการคิดเงินเกินโดยไม่ตั้งใจครั้งไหนที่ถูกกว่าการทำให้แอปพลิเคชันสำคัญล่มหรือข้อมูลสูญหาย
      ต่อให้เป็นแค่ตัวเลือก ทีมบัญชีก็อาจกดดันให้ใช้ และเมื่อเกิดปัญหา ก็เสี่ยงนำไปสู่อุบัติเหตุข้อมูลสูญหาย
      เรื่องนี้อาจสมเหตุสมผลสำหรับผู้ให้บริการคลาวด์ที่เน้นนักพัฒนาอินดี้หรือธุรกิจขนาดเล็กและกลาง
    • มีคนพูดในคอมเมนต์ HN หลายครั้งว่าโค้ดระบบเรียกเก็บเงินของ AWS เป็น สปาเกตตีโค้ดขนาดมหึมา จนภายในกลัวมากที่จะไปแตะการเปลี่ยนแปลงใหญ่ ๆ
      เป็นหนึ่งในเรื่องวงในที่ได้รู้จากที่นี่ซึ่งค่อนข้างน่าสนใจ
    • เคยสนใจ AWS อยู่ แต่ด้วยเหตุผลแบบนี้จึงไม่เคยกล้าลงไปใช้อย่างจริงจัง
      ใช้ VPS ที่ราคาถูกและเป็นแบบเหมาจ่ายยังปลอดภัยกว่าต้องมาเสียใจทีหลัง
    • ควรต้องมีการกำกับดูแล
      การขอให้ Amazon ช่วยทำอะไรสักอย่างแทบไม่มีความหมาย
      ต้องบังคับด้วยกฎหมายให้ Amazon และผู้ให้บริการรายอื่นเคารพเงินของผู้ใช้
      โดยพื้นฐานแล้วบริษัทไม่ได้ทำสิ่งที่มีจริยธรรมหรือดีต่อเศรษฐกิจ แต่ทำสิ่งที่ทำเงินได้

  • เทียบกันแล้วอาจเป็นเรื่องเล็ก แต่ตอนพยายามดีพลอยแอปบน ECS แล้วได้รับ บิล 100 ดอลลาร์ เลยตัดสินใจว่าจะไม่ใช้ AWS อีก
    ข้อผิดพลาดที่ทำให้บริการไม่ขึ้นเป็นปัญหาฝั่งแอปของผมเอง แต่ CloudWatch logs แสดงออกมาแค่ประมาณ 20% ทำให้ต้องดีพลอยซ้ำห้าครั้งเพื่อเอา log แล้วแก้ จากนั้นก็ดีพลอยซ้ำอีกห้าครั้ง
    การดีพลอยที่ล้มเหลวทุกครั้งถูกคิดเงิน และหลังจากทรมานอยู่ราวสองวัน ผมก็ลบบัญชีแล้วไปดีพลอยบน DigitalOcean App Platform
    ที่นั่นการดีพลอยก็ล้มเหลวเพราะข้อผิดพลาดของแอปเหมือนกัน แต่ log ออกมาทุกครั้ง แก้ได้ภายใน 10 นาทีและรันได้ โดยยอดเรียกเก็บรวมมีแค่ไม่กี่เซนต์
    ตั้งแต่วันนั้นเป็นต้นมา ผมตั้งใจว่า ถ้ามีทางเลือก จะไม่ใช้ AWS เด็ดขาดและจะไม่แนะนำด้วย

    • เคยใช้แต่ Azure แต่ ECS ดูเหมือนจะเทียบได้กับ Azure Container Apps
      สำหรับงานพัฒนาและทดสอบ โมเดลคิดเงินตามการใช้งานจริง ราคาถูกมาก
      ไม่รู้ว่าเวิร์กโหลดขนาดใหญ่เป็นอย่างไร แต่การคิดเงินต่อการดีพลอยแต่ละครั้งนี่แปลก
    • พอรู้ว่าไม่สามารถดีพลอยคอนเทนเนอร์ลง EC2 ได้โดยตรงเหมือน GCP ก็เลิกใช้ AWS
      ถ้าเป็นโปรเจกต์ใหญ่ การซัพพอร์ตอาจดีกว่า แต่สำหรับขนาดเล็กถึงกลาง GCP ดีกว่ามาก
      มีองค์ประกอบพื้นฐานที่เข้ากับวิธีใช้คอนเทนเนอร์ในปัจจุบัน และยังมี BigQuery ด้วย

  • ดูเหมือนสคริปต์ที่คำสั่ง npx นั้นรันมี บั๊กชัดเจน
    ผู้เขียนพูดถูก และถ้าเป็นบทเรียน ก็ควรเลือกทรัพยากรที่ถูกที่สุด 100% และเมื่อรันสคริปต์ย่อย delete ก็ควรล้างทรัพยากรให้เรียบร้อย
    การคาดหวังให้นักพัฒนาต้องไล่ตรวจทั้งบัญชี AWS อย่างหวาดระแวงหลังรันของแบบนี้เพื่อหาทรัพยากรที่หลงเหลืออยู่ ไม่ยุติธรรมเลย
    ถ้าเป็นสตาร์ทอัพที่ทำงานแบบนี้ ผู้คนจะปล่อยผ่านว่า “เรื่องแบบนี้เกิดขึ้นได้อยู่แล้ว ต้องระวังเอง” หรือเปล่า?
    ไม่เข้าใจว่าทำไมถึงใช้มาตรฐานคนละแบบกับ AWS

    • จุดที่น่าหงุดหงิดที่สุดของ AWS ก็คือเรื่องนี้
      ไม่มีวิธีง่าย ๆ ให้ดูทรัพยากรทั้งหมดที่ตอนนี้เรากำลังจ่ายเงินอยู่
      ต่อให้มี ผมก็หาไม่เจอ
      ถ้าไม่มีภาพรวมที่เข้าใจง่าย ก็รู้สึกเหมือนไม่ได้ควบคุมบัญชีของตัวเองอย่างเต็มที่
    • สิ่งแรกที่ตรวจสอบเมื่อจะใช้ของใหม่คือสามารถรับ บิลคงที่ ทุกเดือนได้หรือไม่
      แล้วก็ดูว่าถ้าใช้เกินนั้นจะเกิดอะไรขึ้น และสามารถจำกัดการคิดเงินที่ไม่คาดคิดได้ไหม
      ถ้าไม่ได้ ก็ไปหาอย่างอื่น
      หลังจาก Google Maps เปลี่ยนการคิดเงินเมื่อหลายปีก่อน เราก็ระวังมากกับการผูกตัวเองลึก ๆ เข้ากับบริการ Google ที่ “ฟรี” และสุดท้ายมันก็มีค่าใช้จ่ายสูง
    • มีวิธีง่าย ๆ ในการลิสต์ทรัพยากรทั้งหมดที่มีอยู่ในบัญชี AWS จริง ๆ ไหม?
      ที่ผ่านมาเราต้องตรวจทีละบริการ ทีละรีเจียนเสมอ ซึ่งน่าเบื่อและผิดพลาดได้ง่าย
    • จากมุมของ Amazon นี่ไม่ใช่บั๊ก แต่เป็นฟีเจอร์ เพราะทำเงิน 1000 ดอลลาร์ ได้ง่าย ๆ
      ต่อให้พวกเขาคิดว่าเป็นบั๊ก ก็คงมีลำดับความสำคัญต่ำกว่างานอื่นที่กระทบกำไรขาดทุนของตัวเองโดยตรงมาก
    • เห็นด้วยว่าการคาดหวังให้นักพัฒนาตรวจสอบอย่างหวาดระแวงนั้นไม่ยุติธรรม
      แต่ในทางปฏิบัติมันก็สมเหตุสมผล
      เวลา จะสร้างอะไรบน AWS ผมปฏิบัติกับ AWS เหมือนเป็น สถาบันการเงินศัตรูที่หลุดการควบคุม

  • เพราะกรณีแบบนี้ ผมเลยผัดผ่อนการลองขุด AWS อย่างจริงจังมาหลายปีแล้ว
    ควรมี หลักสูตรการเรียนรู้มาตรฐาน ที่ไม่ต้องขอข้อมูลบัตรเครดิต และให้ผู้คนทดลองใช้งานได้ฟรี
    แต่ดูเหมือนมีพวกพนักงานออฟฟิศคำนวณไว้ว่าอาจดูดเงินหลายพันดอลลาร์จากที่ต่าง ๆ ได้ด้วยข้ออ้างว่าเป็น “ความผิดพลาดของผู้ใช้”
    การเรียกเก็บเงินแบบนี้โต้แย้งได้ยาก และบางกรณีก็แทบเป็นไปไม่ได้เลย
    ผมคงไม่ใช่คนเดียวที่หลีกเลี่ยงสภาพแวดล้อม AWS เพราะความกลัวที่สมเหตุสมผลว่าอาจตื่นมาเจอบิลก้อนโต

    • ในสถานการณ์แบบนี้ การที่ AWS ไม่คืนเงินให้นั้นผิดปกติมาก จึงมองว่าเป็นกลยุทธ์รีดเงินหลายพันดอลลาร์จากความผิดพลาดของผู้ใช้ได้ยาก
      เป็นไปได้สูงว่าเขามองว่า การจัดการคืนเงิน เป็นภาระน้อยกว่าการจัดทำ tutorial ที่ถูกต้องและมีต้นทุนต่ำ
      นั่นไม่ได้ทำให้การกระทำนั้นชอบธรรม แต่ผมเคยใช้ AWS Textract แล้วเกิดค่าใช้จ่าย 600 ดอลลาร์อย่างถูกต้องตามการใช้งาน ก็ยังเคยขอยกเลิกบิลได้
      ตอนนั้นผมทำงานอยู่ในบริษัทมูลค่าหลายพันล้านดอลลาร์
    • ผมคิดว่าเหตุผลที่ผู้คนตกอยู่ในสถานการณ์การชำระเงินแบบนี้ เป็นเพราะจริง ๆ แล้วไม่ได้ขุด AWS ให้ลึกพอ
      ตารางราคาหาได้ง่าย และแม้จะไม่ได้เข้าใจง่ายเสมอไป แต่ต้นทุนส่วนใหญ่เพิ่มขึ้นเกือบเป็นเส้นตรง จึงทดสอบได้ค่อนข้างง่าย
      ควรหลีกเลี่ยง บริการ wrapper อย่าง AWS Amplify, CloudFormation และ Stack สารพัดแบบ
      ใช้บริการหลักโดยตรงก็พอ
      ทุกบริการมี API และการขอ API key ที่ผูกกับ IAM user ก็ง่ายเหมือนกดปุ่ม
      ที่เหลือจัดการได้ด้วยการทำ caching ที่เหมาะสม และปรับ cost model ให้เข้ากับโมเดลรายได้
      ทำให้ต้นทุนของบริการที่ auto scale กลายเป็นสัดส่วนค่อนข้างคงที่ของรายได้ โดยแทบไม่ขึ้นกับดีมานด์ปัจจุบันก็พอ
      แบนด์วิดท์เป็นฝันร้ายจริง ๆ บน AWS แต่ในคอนโซลมีส่วนลดระยะยาวอัตโนมัติให้ และถ้าผ่านฝ่ายขายก็อาจได้ส่วนลดตามสัญญาที่ดีกว่านั้นเล็กน้อย
      ด้วยเหตุนี้ผมจึงคิดว่าควรเลี่ยง EC2 และเพราะแบนด์วิดท์ภายในของ EC2 ก็แพงกว่าเช่นกัน การใช้ Lambda + S3 + CloudFront โดยตรงน่าจะดีกว่า
      หลังผ่านไปประมาณ 3 เดือน ก็เริ่มคาดเดาได้ค่อนข้างง่ายแล้วว่าชุดบริการใดคุ้มค่าที่สุดเมื่อต้องทำฟีเจอร์ใหม่ที่ผู้ใช้เห็น
    • A Cloud Guru / Pluralsight มีฟีเจอร์ที่เรียกว่า “Cloud Playground” หรือ “sandboxes”
      อาจใช้เพื่อวัตถุประสงค์แบบนั้นได้ แต่ผมยังไม่เคยลองเอง จึงไม่แน่ใจ
    • เงินที่เกิดจากความผิดพลาดของผู้ใช้ประเภทนี้ เมื่อเทียบกับ AWS ทั้งหมดแล้วคงเป็นแค่ หยดน้ำในมหาสมุทร
      จากประสบการณ์ของผม AWS ดูจะพยายามหลีกเลี่ยงปัญหาที่ทำให้เสียชื่อเสียงจนมีต้นทุนใหญ่กว่า
      AWS ไม่ได้ถูก และในบางกรณีก็แพงมหาศาล โดยเฉพาะค่าถ่ายโอนข้อมูล แต่ผมไม่คิดว่าวิธีของเขาคือหลอกลูกค้าให้เผลอใช้เงินเพิ่มอีกไม่กี่ร้อยดอลลาร์

  • สมกับเป็น AWS
    เมื่อไม่กี่เดือนก่อน ผมทำตาม คู่มือเริ่มต้นใช้งาน SageMaker อย่างรวดเร็ว อย่างเป็นทางการเพื่อรัน Llama 2 มันขึ้นเร็วจริง ๆ แต่วันถัดมาดูแล้วพบว่ากำลังเสียเงินวันละ 400 ดอลลาร์
    ขอให้ยกเลิกบิลได้ แต่ก็ได้เรียนรู้อย่างชัดเจนว่าไม่ควรเชื่อคู่มือทางการ

    • SageMaker เป็นหนึ่งในผลิตภัณฑ์ที่น่าผิดหวังที่สุดในมุมมองผลิตภัณฑ์ และเป็นตัวอย่างชัดเจนของ enshittification
      ช่วงแรกของผลิตภัณฑ์ในปี 2017–2018 การตั้งค่าค่อนข้างเข้าใจง่าย
      มันชัดเจนว่ามี notebook instance, inference, REST API สำหรับ serving, EFS เล็กน้อย และ S3 เป็นศูนย์กลางของบริการ
      ราคาก็เป็นแบบปิด จึงไม่มีอะไรให้ตกใจ
      โดยรวมให้ความรู้สึกเหมือน DigitalOcean และ data scientist ที่มีความรู้พื้นฐานกับความอยากรู้อยากเห็นด้านโครงสร้างพื้นฐานก็สามารถสร้างการตั้งค่าที่ถูก คาดการณ์ได้ และเรียบง่ายได้
      ตอนนี้มี Wrangler, Feature Store, RStudio ประสบการณ์ผู้ใช้ในคอนโซล notebook ก็แย่มาก และภายในมีหลายบริการย้ายข้อมูลไปมาแล้วคิดเงินกับสิ่งนั้น

  • ด้วยเหตุจำเป็น ผมต้องส่ง คำขอ HTTP ดิบ แทนการใช้ SDK ขนาดเทอะทะของ AWS แล้วพบว่า header content-type: application/json ล้มเหลว แต่ content-type: application/x-amz-json-1.0 กลับสำเร็จ
    อยากให้เลิก nonsense แบบนี้เสียที

    • ผมรู้สึกคล้ายกันกับแทบทุกส่วนของ AWS ที่เคยแตะตลอดอาชีพ
      มันเทอะทะเกินไป ซับซ้อนเกินไป หรือมีการทำเองแบบแปลก ๆ มากมาย โดยไม่มีประโยชน์ชัดเจน
    • พูดตรง ๆ คือรายละเอียดภายในรั่วออกมา
      เพราะภายใน แอปส่วนใหญ่ใช้ Coral framework รุ่นเก่า และใช้รูปแบบ JSON นี้ที่กำหนดรูปแบบ input, output และ error ไว้อย่างชัดเจน

  • คู่มือ AWS ทางการทั้งหมดถูกออกแบบมาให้ใช้บริการ AWS ให้มากที่สุดเท่าที่เป็นไปได้ และความเสี่ยงด้านค่าใช้จ่ายก็เพิ่มตามไปด้วย
    ต้องมองสิ่งที่ AWS แนะนำ ไม่ว่าจะเป็นค่าเริ่มต้นใน GUI, เครื่องมือ CLI, คู่มือ, สถาปัตยกรรมที่แนะนำ ฯลฯ ด้วยสายตาวิจารณ์อย่างหนัก
    มีเหตุผลที่ในบริษัทมี ตำแหน่งเงินเดือนสูง สำหรับคอยแนะนำเพื่อนร่วมงานให้ใช้ AWS อย่างคุ้มค่าและมีความเสี่ยงต่ำ

    • ใช่
      สำหรับการ deploy ขนาดเล็กหรือการทดสอบ ส่วนที่แพงที่สุดแทบจะเป็นสิ่งประกอบข้างเคียง หรือบริการใหม่ล่าสุดที่ถูกแนะนำแทนทางเลือกที่เรียบง่ายกว่าเสมอ

  • ถ้ากำลังใช้ OpenSearch เพราะ query แบบ bounding box ของ geo_point แล้ว PostgreSQL + PostGIS เป็นอย่างไรบ้าง?
    https://postgis.net/docs/using_postgis_query.html

  • ผมคิดว่าการตั้งค่าที่ไร้แรงเสียดทานแบบนี้, UX/อินเทอร์เฟซที่เข้าใจไม่ง่าย, ความระแวดระวังต่อการลงทะเบียนบัตรเครดิตที่ต่ำ และ การคิดเงินแบบผูกมัดข้ามบริการ อย่าง AWS Batch + Lambda + EC2 เป็นส่วนหนึ่งของโมเดลธุรกิจ
    ไม่รู้จะอธิบายอย่างไรดี แต่มันคล้ายสวนสนุกสมัยใหม่ที่คุณจ่ายค่าเข้าก่อน แล้วต้องจ่ายเพิ่มสำหรับเครื่องเล่นทุกอย่าง แม้กระทั่งห้องน้ำ

    • ผมก็รู้สึกแบบนั้น
      โมเดลการคิดเงินของคลาวด์โยนความรับผิดชอบให้ผู้ใช้ภายใต้ชื่อ “ความยืดหยุ่น” และ “การปรับแต่งได้”
      ลองนึกภาพบริษัทให้เช่ารถที่คิดเงินทุกชิ้นส่วนเป็นหน่วยมิลลิวินาที เช่น การหมุนของเพลาลูกเบี้ยวเครื่องยนต์, การหมุนของยาง, การทำงานของที่ปัดน้ำฝน, เวลาที่เปิดระบบอุ่นเบาะ แล้วบอกว่าลูกค้า “ควบคุม” การใช้งานและงบประมาณได้ เพราะสามารถตั้งการแจ้งเตือนแยกได้ในแต่ละรายการ
      ตั้งแต่ค่าเริ่มต้น มันก็เป็น โมเดลต้นทุน ที่เป็นปฏิปักษ์และอันตรายต่อผู้ใช้แล้ว