- TablePlus กำลังเฝ้าสังเกตสถานะเซิร์ฟเวอร์ แม้จะมี ความพยายามโจมตี DDoS ต่อเนื่องมาหลายสัปดาห์ โดยไม่บล็อก IP หรือเปิดโหมด “Under Attack” ของ Cloudflare
- ในช่วง 30 วันที่ผ่านมา มีความพยายามดาวน์โหลดไฟล์ติดตั้งประมาณ 6 ล้านครั้ง และเฉพาะ 5 วันที่ผ่านมามี 800,126 ครั้ง โดยไฟล์มีขนาดประมาณ 200MB ต่อการดาวน์โหลด
- แม้ระหว่างการโจมตี การใช้งาน CPU ของเซิร์ฟเวอร์ส่วนใหญ่อยู่ที่ 0~1% และถูกตั้งค่าให้บริการ API ราว 8 รายการกับฐานข้อมูลสามารถรองรับคำขอหลายพันล้านครั้งต่อเดือนโดยไม่ใช้แคชได้
- แบ็กเอนด์ถูกรวมเป็น บริการแบบโมโนลิธิก แยกตามแอป และใช้วิธีดีพลอยไบนารีเดี่ยวไปยัง VPS ใหม่ โดยไม่มี Docker, Kubernetes หรือสภาพแวดล้อม runtime
- โครงสร้างที่เรียบง่าย เช่น Go/Rust framework, การทำ indexing ฐานข้อมูล, การแยก DB สำหรับ log, Nginx reverse proxy, Cloudflare CDN/R2 และ throttling การส่งอีเมล ช่วยลดต้นทุนของการโจมตีและความซับซ้อนในการดำเนินงาน
ความพยายามโจมตี DDoS ที่ต่อเนื่องหลายสัปดาห์
- มีใครบางคนส่ง คำขอหลายร้อยล้านรายการ ไปยังเซิร์ฟเวอร์ของ TablePlus เป็นเวลาหลายสัปดาห์ และพยายามดาวน์โหลดไฟล์ติดตั้งหลายล้านครั้ง
- ความพยายามดาวน์โหลดไฟล์ติดตั้งมี 800,126 ครั้ง ในช่วง 5 วันที่ผ่านมา และประมาณ 6 ล้านครั้ง ในช่วง 30 วันที่ผ่านมา
- ไฟล์ติดตั้งมีขนาดประมาณ 200MB ต่อการดาวน์โหลด
- เมื่อดูจาก API call ในช่วง 30 วันที่ผ่านมา ทราฟฟิกส่วนใหญ่มาจาก EU โดยเฉพาะ Germany และ United Kingdom
- ตัวเลขนี้ไม่รวมคำขอดาวน์โหลดและทราฟฟิก CDN
- ณ เวลาที่เขียนบทความ การโจมตียังคงดำเนินอยู่
การรับมือจริง: โครงสร้างที่ทนได้มากกว่าการบล็อก
- ไม่ได้บล็อกที่อยู่ IP ของผู้โจมตี
- ใช้ Cloudflare แต่ไม่ได้เปิดโหมด “Under Attack”
- แม้ระหว่างการโจมตี CPU ของเซิร์ฟเวอร์ส่วนใหญ่อยู่เพียงระดับ 0~1% แทบจะว่างอยู่
- บริการสามารถรองรับคำขอหลายพันล้านครั้งต่อเดือนได้โดยไม่มีปัญหา และภาระค่าใช้จ่ายก็ไม่สูงมาก จึงแทบไม่ต้องดำเนินมาตรการเพิ่มเติม
การออกแบบแบ็กเอนด์ที่เรียบง่าย
- การออกแบบแอป TablePlus มุ่งเน้นความเรียบง่าย และบริการแบ็กเอนด์ก็รักษาไว้ให้เป็น โครงสร้างขั้นต่ำ เท่าที่ทำได้
- ไม่ใช้บริการเรนเดอร์ของบุคคลที่สามอย่าง Vercel หรือ Netlify เพราะอาจทำให้เกิดคอขวดหรือบิลที่คาดไม่ถึงระหว่างถูกโจมตี
- มองว่าการใช้เว็บเซิร์ฟเวอร์ของตนเองช่วยหลีกเลี่ยงข้อจำกัดเหล่านี้ได้
- ในอดีต โมโนลิธอาจกลายเป็นคอขวดได้เพราะ VPS และโปรเซสเซอร์ที่อ่อนแอ แต่ VPS ในปัจจุบันให้ CPU แบบหลายคอร์, RAM ขนาดใหญ่ และ SSD ความเร็วสูง
- SSD และ RAM ที่เร็วช่วยเพิ่มประสิทธิภาพฐานข้อมูลอย่างมาก
- หากนำไปใช้อย่างถูกต้อง บริการโมโนลิธ บนอินสแตนซ์เดียวก็สามารถรองรับคำขอหลายพันล้านครั้งต่อเดือนได้
วิธีดำเนินงานโมโนลิธแยกตามแอป
- รวม API, เว็บไซต์, อีเมล, การชำระเงิน ฯลฯ ที่แต่ละแอปต้องใช้ไว้ในบริการเดียว
- การดีพลอยจบได้ด้วยไฟล์ตั้งค่าเดียว การ build และการ deploy
- เมื่อย้ายบริการไปยังผู้ให้บริการคลาวด์รายอื่น หรือดีพลอยใหม่ สามารถดำเนินการได้อย่างรวดเร็ว
- มี dependency น้อย ทำให้ debug และระบุคอขวดได้ง่าย
- แม้เกิดข้อผิดพลาด ก็มีบริการที่ต้องตรวจสอบเพียงหนึ่งรายการหรือไม่กี่รายการเท่านั้น
- ตัวอย่างเฟรมเวิร์กโมโนลิธที่เลือกใช้ได้มีดังนี้
- Golang: Echo, Gin
- PHP: Laravel
- Ruby: Rails
- Rust: Actix, Rocket, Warp
หลักการตั้งค่าสำหรับคำขอหลายพันล้านครั้งต่อเดือน
- เลือกเว็บเฟรมเวิร์กประสิทธิภาพสูง โดย TablePlus ชอบ Golang และ Rust
- เมื่อ dataset มีขนาดใหญ่ขึ้น จะตั้งค่า index ในฐานข้อมูลเพื่อลดเวลาในการ query
- แยกฐานข้อมูลหลักออกจากฐานข้อมูล log และ usage เพื่อปกป้องประสิทธิภาพของธุรกิจหลัก
- ฐานข้อมูลหลักใช้สำหรับข้อมูลที่ไม่เปลี่ยนแปลง หรือข้อมูลที่ขนาดไม่เพิ่มขึ้นเมื่อเวลาผ่านไป
- ฐานข้อมูล log และ usage ใช้สำหรับข้อมูลที่เติบโตขึ้นเรื่อย ๆ ตามเวลา
- วาง reverse proxy ไว้หน้า API หลักเพื่อจัดการและกระจายคำขอ
- ช่วยได้เมื่อจำเป็นต้องใช้หลายเซิร์ฟเวอร์
- TablePlus ใช้ Nginx
- วางทุกอย่างไว้หลัง Cloudflare และตั้งค่า cache, Argo รวมถึง full SSL ระหว่าง Cloudflare กับเซิร์ฟเวอร์อย่างเหมาะสม
- ใช้ CDN ที่มีการป้องกัน DDoS
- TablePlus ชอบใช้ Cloudflare R2 และ CDN มากกว่า Amazon CloudFront + S3 เพื่อประหยัดค่าใช้จ่ายและเพิ่มการป้องกัน
- หากวางไฟล์ดาวน์โหลดขนาดใหญ่ไว้บน VPS โดยไม่มี CDN หรือ caching แบนด์วิดท์จะถูกใช้หมดอย่างรวดเร็ว
- TablePlus ใช้ Cloudflare CDN ที่มีแบนด์วิดท์ไม่จำกัด
- หากเปิดใช้ Argo บนโดเมนเดียวกัน ทราฟฟิก Cloudflare CDN อาจวิ่งผ่าน Argo ได้ และแบนด์วิดท์ของ Argo ไม่ฟรี จึงอาจทำให้ค่าใช้จ่ายสูงขึ้น
- คำขอที่เซิร์ฟเวอร์ต้องส่งอีเมล เช่น การกู้รหัสผ่าน จะปกป้อง mailer ด้วย throttling
วิธีดีพลอย: รันไบนารีโดยไม่ใช้คอนเทนเนอร์
- TablePlus รักษากระบวนการดีพลอยให้เรียบง่ายที่สุด โดยไม่ใช้ Docker, Kubernetes, container หรือการตั้งค่าสภาพแวดล้อม runtime แยกต่างหาก
- หน่วยของการดีพลอยคือ ไบนารี
- คัดลอกไปยังเซิร์ฟเวอร์ Linux แล้วรันเป็น process
- จัดการในลักษณะคล้ายกับการรันแอป TablePlus บน macOS
- สามารถให้ Linux Systemctl เฝ้าดู process และ restart เมื่อเกิดข้อผิดพลาดร้ายแรงได้
- รันแบบ native เพื่อไม่ให้สูญเสีย CPU/RAM ไปกับชั้นกลางอย่าง VM, virtualization หรือผู้จัดการโครงสร้างพื้นฐานของบุคคลที่สาม
- เลือก Go และ Rust เพราะเป็นภาษาประสิทธิภาพสูงและสามารถสร้างไฟล์ไบนารีสำหรับการดีพลอยได้
ฟีเจอร์ป้องกันที่ควรเปิดไว้เมื่อใช้ Vercel
- Vercel มีฟีเจอร์สำหรับปกป้องไซต์ในสถานการณ์เช่นนี้ ได้แก่ Spend Management และ Attack Challenge Mode
- Spend Management: สามารถตั้งขีดจำกัดค่าใช้จ่ายแบบ soft หรือ hard ได้
- Attack Challenge Mode: คล้ายกับโหมด “Under Attack” ของ Cloudflare
- หากใช้ Vercel จำเป็นต้องเปิดฟีเจอร์ดังกล่าวไว้
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
บทความนี้ให้ความรู้สึกว่า ชมตัวเอง มากเกินไป “1 พันล้านคำขอต่อเดือน” ก็มีแค่ไม่กี่ร้อยคำขอต่อวินาที ซึ่งเป็นระดับเล็กน้อย และแทบเรียกว่า DDoS ได้ไม่เต็มปาก
ยิ่งไปกว่านั้น เว็บไซต์ก็อยู่หลัง CDN อย่าง Cloudflare อยู่แล้ว จึงยิ่งไม่เข้าใจว่าทำไมในมุมประสิทธิภาพถึงถูกมองว่าเป็นเรื่องที่ยิ่งใหญ่อะไรนัก
ตัวอย่างเช่น ไม่มีเหตุผลที่สมเหตุสมผลเลยที่ไฟล์ 200MB จะไม่ถูกแคชและเสิร์ฟผ่าน CDN การที่เซิร์ฟเวอร์แอปพลิเคชันไม่ต้องอ่านไฟล์ 200MB จากดิสก์แล้วคัดลอกส่งให้ไคลเอนต์ทุกครั้งที่มีการดาวน์โหลด ไม่ใช่เรื่องที่ควรภูมิใจ เพราะถ้าทำแบบนั้นก็เป็นการออกแบบที่แย่อย่างเห็นได้ชัดอยู่แล้ว
ถ้า ไฟล์ 200MB ที่พูดถึงคือไฟล์ดาวน์โหลดแอปไคลเอนต์ TablePlus ที่ https://tableplus.com/download เวอร์ชัน Windows มีขนาด 183MB และถูกแคชบน Cloudflare จริง
# curl -v https://files.tableplus.com/windows/5.9.2/TablePlusSetup.exec > /dev/null< cache-control: max-age=691200< cf-cache-status: HIT< age: 2980ปกติเรื่องแบบนี้ไม่ใช่สิ่งที่บริษัทระดับ FAANG จะคิดว่าต้องใช้ นักพัฒนาเกิน 1,000 คน ถึงจะทำได้หรอกหรือ? เลยไม่เข้าใจว่าจะบอกว่าเป็นการชมตัวเองอย่างเดียวได้อย่างไร ในเมื่อแม้แต่บริษัทใหญ่ก็ยังทำเรื่องพื้นฐานแบบนี้ไม่ได้สม่ำเสมอ
มองว่าเป็นแค่ไม่กี่ร้อยคำขอต่อวินาทีอย่างเดียวก็ไม่ได้ ความหนาแน่นของคำขอไม่ได้กระจายเท่ากันตามเวลา และมักพุ่งได้ถึง 20 เท่า ของค่าเฉลี่ย
เดือนละ 4TB จริง ๆ แล้วก็ยากจะเรียกว่าเป็นการโจมตี DDoS นะ ถ้าเป็น 4TB ต่อชั่วโมงค่อยเรียกแบบนั้นได้ แต่ 4TB ต่อเดือนคือแค่ 1.5MB ต่อวินาทีเท่านั้น
ส่วน 6 ล้านคำขอต่อเดือนก็เท่ากับเพียง 2 คำขอต่อวินาที ในระดับนี้ การที่ระบบรันเป็นโมโนลิธิกเซอร์วิสก็ไม่น่าจะสำคัญอะไรนัก โดยเฉพาะเมื่อ Cloudflare รับคำขอส่วนใหญ่ไปผ่าน CDN cache อยู่แล้ว
เว็บไซต์ส่วนใหญ่ของโลกเป็น WordPress ที่อยู่บนโฮสติ้งแบบหลายผู้เช่าราคา 5~20 ดอลลาร์ต่อเดือน และถ้าเป็นองค์กรใหญ่ขึ้นมาก็มักจะเป็น Drupal หลายแห่งไม่มีแคชด้วยซ้ำและต่อฐานข้อมูลโดยตรง ดังนั้นเว็บไซต์ส่วนใหญ่บนอินเทอร์เน็ตอาจล่มได้ด้วยคำขอเพียง 4 ครั้งต่อวินาที
ฟังดูบ้าแต่ความจริงก็เป็นแบบนั้น ผมเคยดูแลงานป้องกัน DDoS, WAF, ไฟร์วอลล์ และโครงการความปลอดภัยสำหรับลูกค้าที่ Cloudflare และเห็นอยู่บ่อย ๆ ว่าเว็บลูกค้าล่มเพราะการสแครปเว็บหรืออัตรา HTTP request ที่ต่ำมากอย่างไม่น่าเชื่อ
ตัวเลขใหญ่ได้ขึ้นพาดหัวก็จริง แต่สิ่งที่คนส่วนใหญ่เจอจริง ๆ คือ ตัวเลขเล็ก
การโจมตีแบบปฏิเสธการให้บริการอาจทำได้ด้วยปริมาณเพียงไม่กี่ KB ต่อชั่วโมง ถ้าโจมตี API endpoint ที่หนัก ของบริการเป้าหมาย แค่นั้นก็ทำให้บริการล่มได้แล้ว และคำว่า Distributed ก็แค่หมายถึงมีหลายเครื่องโจมตีพร้อมกัน
DDoS ไม่จำเป็นต้องมีทราฟฟิกมหาศาลเสมอไป เพียงแต่ที่เป็นข่าวมักจะเป็นการโจมตีขนาดใหญ่
เป้าหมายของการโจมตีแบบนี้อาจเป็นการเผาโควตาแบนด์วิดท์ของเซิร์ฟเวอร์ต้นทาง หรือทำให้ค่าแบนด์วิดท์สูงจนรับไม่ไหว ซึ่งทำได้ถูกมากแม้ใช้เครื่องโจมตีแค่เครื่องเดียวหรือไม่กี่เครื่อง ดาต้าเซ็นเตอร์และผู้ให้บริการโฮสติ้งส่วนใหญ่มีการจำกัดแบนด์วิดท์หรือคิดเงินเพิ่มหลังเกินโควตา และบ่อยเกินไปที่บริษัทที่ถูกโจมตีจะรู้ตัวก็ตอนเจอบิลที่จ่ายไม่ไหวแล้ว
มีเว็บไซต์ดาวน์โหลดเกมแห่งหนึ่งที่มีผู้เล่นรวมกันราว 50 คน แทบไม่มีใครใช้ และคนจริง ๆ น่าจะดาวน์โหลดเกมกันไม่กี่ครั้งต่อเดือน
แต่ไฟล์ zip 2GB ไฟล์เดียวกลับสร้างทราฟฟิก 5TB ในเดือนที่แล้ว และเป็นแบบนี้ต่อเนื่องมาหลายปีแล้ว นี่ไม่ใช่ DDoS แต่เป็นบอต/ครอว์เลอร์ที่ตั้งค่าผิดและไล่ตามทุกลิงก์โดยไม่ยกเลิกการดาวน์โหลด
ดูเหมือนจะประมาณ 1TB ต่อวัน แต่ถึงอย่างนั้นก็ยังเล็กมากอยู่ดี
น่าจะขึ้นอยู่กับว่าทราฟฟิกไม่สม่ำเสมอแค่ไหน
นี่ก็เป็นแค่ เว็บไซต์การตลาดแบบสแตติก สำหรับเดสก์ท็อปแอป ไม่มีฟอรัมสนทนา และรับฟีดแบ็กผ่าน GitHub issue
การเอามาคุยอวดว่า deployment ของเว็บไซต์การตลาดแบบสแตติกมันง่ายแค่ไหน และไฟล์สแตติกยังทนการดาวน์โหลดวันละหลายล้านครั้งได้ มันดูแปลกพอสมควร แล้วคนที่ทำ mitigation ที่นี่ก็เป็น Cloudflare ไม่ใช่พวกเขาเองอยู่แล้ว ถ้าทราฟฟิกเล็กนิดเดียวแบบนี้ยังต้องทำ mitigation น่ะนะ
ถ้าผมโดน “การโจมตี” แบบนี้ คงไม่รู้ตัวด้วยซ้ำจนกว่าจะได้รับอีเมลรายเดือนจาก Cloudflare ที่บอกว่า “ส่งข้อมูล X TB ประหยัดแบนด์วิดท์ไปเกือบ 100%”
ตัวแอปเองผมชอบนะ และแนะนำได้
นี่ดูเหมือนจะใกล้เคียงกับการเป็น “การใช้งานบริการในทางที่น่ารำคาญและไร้สาระ” มากกว่าจะเป็น DDoS เพราะจากคำอธิบายก็คือทราฟฟิกเพิ่มราว 8TB ต่อเดือน
ถ้าการใช้งานแบบนั้นไม่ได้สร้างปัญหาเรื่องต้นทุนหรือทำให้ทรัพยากรหมด ก็ปล่อยผ่านได้ แต่เรื่องแนว ๆ “เพิ่งมารู้ว่าความจุของ auto-scaling fleet 80% ไม่ได้ทำงานที่มีประโยชน์อะไรเลย” นั้นพบได้บ่อยจนน่าหดหู่ จึงควรเฝ้าดูไว้อย่างน้อย
ส่วนที่น่ารำคาญที่สุดของการใช้งานแบบนี้มักเป็น ล็อก เป็นหลัก ล็อกส่วนใหญ่จะเต็มไปด้วยเนื้อหาที่โฮสต์เดิม ๆ ทำพฤติกรรมไร้สาระแบบเดิมซ้ำ ๆ ถ้าพื้นที่เก็บล็อกราคาถูกและมีเหลือเฟือก็อาจไม่ใช่ปัญหาใหญ่ แต่การมีวิธีจัดประเภททราฟฟิกบางอย่างเป็นการใช้งานในทางที่ผิดโดยอัตโนมัติ และยับยั้งการประมวลผลตามปกติไว้ ก็นับว่าเป็นไอเดียที่ดีแน่นอน
เพียงแต่มันไม่ได้ง่ายอย่างที่พูด ผมนับไม่ถ้วนแล้วว่าเคยเพิ่มตรรกะจัดประเภทเพื่อจับการใช้งานแบบโจ่งแจ้งและงี่เง่าบนเซิร์ฟเวอร์ SMTP ขาเข้ากี่ครั้ง แต่ทุกครั้งก็มักจะไปจับโดนกรณีที่ยังถือว่าใช้งานได้จริงแบบเฉียด ๆ ด้วย
ถ้าเสียเวลาไปกับโพรงกระต่ายต่อเนื่องมากเกินไป ก็มีแต่จะทำให้งานจริงไม่เดิน ดังนั้นบางครั้งการจ้างคนนอกทำ หรือถ้ามันยังยุ่งยากหรือแพงเกินไป ก็อาจดีกว่าที่จะยอมรำคาญแล้วปล่อยการใช้งานแบบผิด ๆ นั้นไป
DigitalOcean ยกตัวอย่างเช่น s-4vcpu-8gb-intel ถ้าเกิน 5TB ที่รวมมาแล้วอีก 3TB จะเสียเพิ่ม 30 ดอลลาร์ และ Linode คิด 15 ดอลลาร์สำหรับส่วนที่เกิน 3TB ดังนั้นผมคิดว่าประเด็นของบทความก็ยังมีอยู่
นี่ไม่ใช่ “การโจมตี” ที่น่าสนใจอะไรนัก แค่ bash script ตัวเดียวที่ทำงานค้างบนเครื่องของใครสักคนก็ทำได้
“50 ล้านคำขอต่อเดือนจากสหราชอาณาจักร” เฉลี่ยแล้วยังไม่ถึง 20 คำขอต่อวินาทีเลย คาดว่า Go server เครื่องเดียวก็น่าจะรับปริมาณคำขอมากกว่านั้น 250 เท่าได้โดยไม่ต้องปรับแต่งอะไรมาก
ตัวคำแนะนำเองอาจไม่ได้แย่เสมอไป แต่ตัวเลขเหล่านั้นไม่ได้เป็นหลักฐานรองรับคำแนะนำดังกล่าว ถ้าเป็นบริการ Go HTTP API ก็คาดหวังได้ว่าบน VPS ขนาดเล็กถึงกลางจะรับได้ 5,000 คำขอต่อวินาทีโดยไม่ต้อง optimize มากนัก แม้จะมีงานฐานข้อมูลและการจัดรูปแบบ JSON อยู่บ้าง ตัวเลขนี้อิงจากประสบการณ์ที่เคย deploy บริการลักษณะคล้ายกันหลายสิบตัวในระบบที่รับคำขอหลายพันล้านครั้งต่อวัน และช่วงพีกเกิน 500,000 คำขอต่อวินาที
ก็ดีที่มันไม่ได้สร้างความเสียหาย แต่จะรับสิ่งนี้เป็นคำแนะนำเลยก็ดูน่ากังวลเพราะมีหลายส่วนที่ตกหล่น
การบอกว่าควร prefer การแจกจ่ายแบบไบนารีมากกว่า Docker ก็พอเข้าใจได้ แต่แล้วจะจัดการโฮสต์ที่รันไบนารีนั้นอย่างไร? เหตุผลหนึ่งที่คนใช้คอนเทนเนอร์ก็เพื่อผูกการตั้งค่าด้าน hardening ไว้กับการ deploy เพื่อให้มั่นใจได้ว่าถ้าต้องขยายในภายหลัง การตั้งค่าความปลอดภัยบนแต่ละโหนดจะเหมือนกัน
monolith ที่พูดถึงนี้สามารถรันบน VPS เดียวได้ ซึ่งก็ดีและถูกด้วย แต่ถ้ามัน crash หรือฮาร์ดแวร์พังไม่ว่าด้วยเหตุผลใด ก็อาจเกิด downtime ค่อนข้างมาก
อีกเรื่องที่น่ากังวลคือถ้าจับทุกอย่างยัดรวมไว้ใน monolith เราจะสูญเสีย defense in depth ของ application stack ไป ถ้ามีคนเจาะแอปผ่าน frontend ได้ ก็อาจไปถึง backend data store ได้ตรง ๆ เลย นี่จึงเป็นเหตุผลที่หลายคนวาง data store ไว้หลัง internal web service และใช้ security group บน private network ที่แยกออกจาก frontend เพื่อจำกัด attack surface ให้อยู่แค่ระดับพฤติกรรมที่ทำผ่านเบราว์เซอร์ได้
ไม่มีโลกไหนที่การเพิ่ม attack surface จะทำให้ความปลอดภัยดีขึ้น
ถ้าคิดว่าแค่ติดตั้ง Docker แล้วโฮสต์จะปลอดภัยขึ้น นั่นไม่จริง แล้วถ้าต้องขยายระบบจะตั้งค่าโฮสต์เพิ่มอย่างไร?
ถ้าใช้ Docker ก็ต้องทำให้ปลอดภัยไม่ใช่แค่คอนเทนเนอร์ แต่รวมถึงโฮสต์และบริการที่ใช้รันคอนเทนเนอร์ด้วย และเมื่อขยายระบบไป deploy โฮสต์เพิ่ม ก็ต้องปลอดภัยแบบเดียวกันทั้งหมด
ถ้าใช้ infrastructure as code และ configuration as code การ deploy ไบนารีหลังตั้งค่าระบบไว้แล้ว กับการ deploy Docker ก็ไม่ได้ต่างกันในสาระสำคัญ
มีเครื่องมือที่ช่วยให้การตั้งค่าแบบ “bare metal” ทำซ้ำได้ในระดับหนึ่ง เช่น NixOS, Ansible และการ build Amazon AMI image
ผมไม่เคยเข้าใจคำว่า “เจาะแอปผ่าน frontend” เลย SQL injection ก็ไปยุ่งกับ data store ได้โดยตรงโดยไม่ต้อง remote code execution ส่วน XSS ก็ส่งผลในแนวขวางกับผู้ใช้อื่น
แต่จาก frontend จะทะลุไปถึง backend ทั้งหมดได้อย่างอิสระนี่คือยังไง? หรือคนกำลังรัน JavaScript interpreter ที่มีสิทธิ์เข้าถึง shell อยู่ในบริการ Go API แล้วเรียก
evalกับอินพุตจากผู้ใช้กัน? มันฟังดูฝืนทางเทคนิคเกินไปสุดท้ายแล้วนี่ไม่ใช่ security through obscurity หรอกหรือ? ทำทุกอย่างให้ซับซ้อนจนแม้แต่เรายังไม่เข้าใจ แล้วหวังว่าคนอื่นก็คงไม่เข้าใจเหมือนกัน?
สิ่งสำคัญไม่ใช่การสร้างกำแพงให้มากขึ้น แต่คือทำให้กำแพงพังไม่ได้ต่างหาก อินเทอร์เฟซมีแต่จะลดประสิทธิภาพและเพิ่มความซับซ้อน
ส่วนตัวรู้สึกติดใจกับถ้อยคำนี้ “1 พันล้านคำขอต่อเดือน” คิดคร่าว ๆ ก็ประมาณ 370 คำขอต่อวินาที ระดับที่เซิร์ฟเวอร์เครื่องเดียวที่ตั้งค่าดี ๆ ก็รับไหว และแน่นอนว่าไม่น่าต้องถึง 10 เครื่อง
แค่ bash script อันตรายตัวเดียวก็สร้างทราฟฟิกระดับนั้นได้
อาจเป็นเพราะผมไม่ค่อยแตะดินก็ได้ แต่คำขอระดับหลายพันล้านต่อเดือนฟังดูไม่ได้มากอะไรนัก แบบนี้ถือเป็น การโจมตี DDoS ครั้งใหญ่แล้วหรือ?
ชอบส่วนที่ว่า “เราสร้าง บริการแบบ monolith สำหรับแต่ละแอปที่ deploy และดูแลรักษาได้ง่าย ไม่มีทั้ง Docker, Kubernetes, dependency หรือ runtime environment มีแค่ไฟล์ไบนารีหนึ่งไฟล์ที่ deploy ไปยัง VPS ใหม่ที่เพิ่งสร้างขึ้นที่ไหนก็ได้”
ไม่ได้ใช้ TablePlus โดยตรง ถ้าพูดถึงเว็บไซต์การตลาด ก็แน่นอนว่าไม่จำเป็นต้องใช้ Kubernetes
แต่ถ้าหมายถึงตัวแอปพลิเคชัน ก็แปลกใจที่บอกว่าไม่มี dependency ไม่ได้เก็บข้อมูลและเขียนล็อกกันหรือ?
นี่คือข้อดีที่ยอดเยี่ยมมากของ Golang แค่เปิด VPS ตั้งค่า default ที่สมเหตุสมผล จากนั้น cross-compile แล้วรันไบนารีได้เลย
เมื่อเทียบกับการ deploy Python, Node หรือ PHP แล้ว มีความซับซ้อนที่ไม่จำเป็นน้อยกว่ามาก
ถ้าการรันและดูแลให้ database server ทำงานต่อเนื่องอยู่ได้ง่ายขนาดนี้ก็คงดี
เห็นจากชื่อเรื่องแล้วคาดหวังเนื้อหาที่เข้ากับ swole doge มากกว่านี้หน่อย ผมเห็นด้วยกับคำแนะนำหลายส่วน แต่การอยู่หลัง Cloudflare ไม่ได้แปลว่าไม่มีอะไรเลย
ขึ้นอยู่กับการกระจายของทราฟฟิกด้วย บางทีต่อให้ไม่มี Cloudflare แค่ VPS ก็อาจรับไหว และขนาดก็ดูไม่ได้ใหญ่มากนัก ถ้าได้เห็นสถิติละเอียดกว่านี้ เช่น จำนวนคำขอต่อวินาที และ Cloudflare บล็อกไปได้เท่าไรก่อนถึง origin ก็คงน่าสนใจมาก
DDoS ระดับเลเยอร์ 7 จากรัสเซียที่มุ่งเป้าไปยังบริษัทสวีเดนที่ผมรู้จักนั้นใหญ่ถึงขั้นผู้ให้บริการรายใหญ่หลายเจ้าล้มเพราะติดปัญหาความจุ รวมถึง Verizon, Azure Frontdoor, Cloudflare และ GCP load balancer ด้วย ถ้าเจอขนาดนั้น กลยุทธ์นี้ใช้ไม่ได้แน่นอน