Rails 8 จัดส่งโดยมีหลักฐานที่ชัดเจน:“ไม่จำเป็นต้องใช้ PaaS” เนื่องจากแพลตฟอร์มคลาวด์มีค่าใช้จ่ายเพิ่มมากขึ้น Ruby on Rails จึงได้เปลี่ยนไปลดการพึ่งพาโครงสร้างพื้นฐานภายนอก เพื่อให้นักพัฒนาสามารถติดตั้งและรันแอปพลิเคชันโดยมีการพึ่งพาบริการน้อยลง
โดยทั่วไปแล้ว การใช้แอป Rails บนอินเทอร์เน็ตหมายถึงการจัดเตรียมเซิร์ฟเวอร์ฐานข้อมูล (เช่น PostgreSQL) และบริการเพิ่มเติม เช่น Redis สำหรับการแคช งานเบื้องหลัง หรือ WebSockets ด้วย Rails 8 ทีมงานหลักหวังที่จะเปลี่ยนแปลงสิ่งนั้นโดยการรวมโซลูชันสำหรับแคช คิวงาน และ WebSockets แบบเรียลไทม์ ซึ่งทั้งหมดนี้ขับเคลื่อนโดยฐานข้อมูลแอปพลิเคชันของคุณ
ในบทความนี้ เราจะสำรวจว่า Rails 8 ส่งมอบสัญญา “ไม่จำเป็นต้องใช้ PaaS” ได้อย่างไร โดยเริ่มจากภาพรวมของ “Solid Trifecta”
Solid Cache ช่วยให้คุณแคชโดยไม่ต้องใช้ Redis
สิ่งที่ฉันชอบเพิ่มเติมอย่างหนึ่งใน Rails 8 คือ Solid Cache ซึ่งเป็นที่เก็บแคชใหม่ที่ แทนที่ความต้องการ Redis หรือ Memcached . Solid Cache ใช้ฐานข้อมูลเพื่อเก็บข้อมูลแคชไว้แทนการจัดเก็บคีย์-ค่าในหน่วยความจำ แม้ว่าในทางเทคนิคแล้วการจัดเก็บอ็อบเจ็กต์ที่แคชไว้บนดิสก์จะช้ากว่า RAM แต่ก็มีข้อดีที่สำคัญบางประการ
ประการแรก พื้นที่จัดเก็บดิสก์ช่วยให้คุณมีพื้นที่มากขึ้นและราคาถูกกว่าหน่วยความจำมาก ด้วย Solid Cache คุณจะสามารถแคชข้อมูลได้มากขึ้น (และเก็บไว้นานกว่า) โดยที่ RAM ไม่หมด ที่ 37signals (บริษัทที่อยู่เบื้องหลัง Basecamp และ HEY) การเปลี่ยนจาก Redis เป็น Solid Cache ช่วยให้พวกเขาขยายแคชเป็นข้อมูลขนาด 10+ เทราไบต์ ส่งผลให้เวลาการเรนเดอร์ P95 ลดลง 50% ในท้ายที่สุด
ใช่ การอ่านจากหน่วยความจำเร็วกว่าการอ่านจากดิสก์ ในหลายกรณี (เช่น การใช้งานของ Basecamp) ข้อดีข้อเสียของการแคชข้อมูลที่มากขึ้นทำให้การเร่งความเร็วนี้คุ้มค่า
ตามค่าเริ่มต้น Rails 8 จะใช้ Solid Cache (สนับสนุนโดย SQLite) แน่นอนว่า ตามปกติสำหรับแบบแผนของ Rails คุณยังคงสามารถเลือกใช้ตัวเลือกอื่น เช่น Redis ได้ หากเป็นตัวเลือกที่ดีกว่าสำหรับคุณ แต่การใช้ค่าเริ่มต้นนี้จะทำให้คุณสามารถแคชสิ่งต่าง ๆ ได้โดยไม่ต้องรองรับบริการการผลิตอื่นเช่น Redis ซึ่งช่วยลดภาระโครงสร้างพื้นฐานของคุณ
Solid Queue ช่วยให้คุณทำงานเบื้องหลังได้โดยไม่ต้อง Redis
ส่วนที่สองที่ฉันชื่นชอบใน Trifecta “Solid” คือ Solid Queue ซึ่งเป็นแบ็กเอนด์ Active Job ใหม่ ที่จัดการการประมวลผลงานเบื้องหลังโดยไม่จำเป็นต้องใช้ Redis หรือแม้แต่การพึ่งพาระบบงานที่แยกต่างหาก เช่น Sidekiq
นักพัฒนา Rails จำนวนมากใช้ Gem เช่น Sidekiq (ซึ่งอาศัย Redis) หรือ Delayed Job สำหรับงานเบื้องหลัง Solid Queue คือความพยายามของ Rails ในการลบ ความต้องการ สำหรับการพึ่งพาอื่น โดยผสานรวมการจัดคิวงานเข้ากับฐานข้อมูลแอปพลิเคชันของคุณ คุณจึงไม่จำเป็นต้องใช้โซลูชันหน่วยความจำหรือระบบการจัดคิว
Solid Queue จัดเก็บงานเป็นบันทึกในตารางฐานข้อมูลและใช้คุณสมบัติ SQL ที่มีประสิทธิภาพเพื่อจัดการคิวงาน สามารถรันได้ทั้งแบบฝังอยู่ในกระบวนการเว็บ Rails (เป็นปลั๊กอิน Puma สำหรับการตั้งค่าเซิร์ฟเวอร์เดี่ยว) หรือในกระบวนการของผู้ปฏิบัติงานแยกต่างหาก
ดังที่สมาชิกในทีมหลักของ Rails คนหนึ่งตั้งข้อสังเกต เป้าหมายคือให้นักพัฒนา “ติดตั้ง Rails ตั้งค่าฐานข้อมูล และมีการประมวลผลงานเบื้องหลังได้ทันทีโดยไม่ต้องจัดการ Gem และระบบอื่นๆ ทั้ง 7 ตัว”
Solid Cable ช่วยคุณสร้างเว็บซ็อกเก็ต (แปลกใจ โดยไม่ต้องใช้ Redis)
ชิ้นส่วนที่สามของปริศนา "ไม่จำเป็นต้องใช้ Redis" ของ Rails 8 คือ Solid Cable — อะแดปเตอร์ Action Cable ใหม่ที่คุณเดาได้ว่าใช้ฐานข้อมูล ในอดีต Action Cable จำเป็นต้องใช้เซิร์ฟเวอร์ Redis เพื่อเผยแพร่ข้อความระหว่างกระบวนการ Rails หลายกระบวนการ ด้วย Solid Cable คุณสามารถใช้ประโยชน์จาก Action Cable สำหรับฟังก์ชัน WebSocket แบบเรียลไทม์ ปลดล็อกการอัปเดตสดสำหรับคุณสมบัติของแอปพลิเคชัน เช่น การแชทและการแจ้งเตือน โดยไม่ต้องใช้บริการเพิ่มเติม
ฉันหวังว่าประโยชน์ของไตรเฟคตา "โซลิด" จะเริ่มชัดเจนขึ้นในตอนนี้ คุณสามารถแคชข้อมูลระยะยาว ประมวลผลงานพื้นหลังที่มีปริมาณการประมวลผลสูง และปรับใช้คุณสมบัติแบบเรียลไทม์โดยไม่ต้องมีเซิร์ฟเวอร์ Redis หรือบริการผับ/ย่อยอื่นๆ คุณสมบัติเหล่านี้ร่วมกันลดความซับซ้อนสำหรับแอปขนาดเล็ก (คุณสามารถรันทุกอย่างบนโฮสต์เดียวด้วยฐานข้อมูลเดียว) และสอดคล้องกับปรัชญา Rails 8 ที่ทำให้การปรับใช้ง่ายขึ้น
การขจัดความจำเป็นในการ Redis เป็นเรื่องใหญ่หรือไม่
หลังจากได้เห็นว่า Rails 8 เกี่ยวข้องกับการลบการพึ่งพา Redis มากเพียงใด คุณอาจสงสัยว่าจริงๆ แล้วสิ่งนี้มีความสำคัญเพียงใด คำตอบขึ้นอยู่กับบริบทของคุณ แต่ไม่ต้องสงสัยเลยว่ามีประโยชน์ที่โดดเด่นบางประการ
ชิ้นส่วนที่เคลื่อนไหวน้อยลงหมายถึงความซับซ้อนน้อยลง โดยเฉพาะในการปรับใช้ บริการเพิ่มเติมทุกอย่าง (Redis, ผู้ดำเนินการงานเบื้องหลังแยกต่างหาก ฯลฯ) เป็นอีกสิ่งหนึ่งที่สามารถทำลายหรือจำเป็นต้องปรับขนาด การใช้ฐานข้อมูลเพิ่มเติมจะทำให้การดำเนินการผลิตของคุณง่ายขึ้น คุณไม่จำเป็นต้องตรวจสอบหน่วยความจำ Redis หรือตรวจสอบให้แน่ใจว่าอินสแตนซ์ Redis ทำงานอยู่เสมอ
นักพัฒนา Rails จำนวนมากต้องเผชิญกับสถานการณ์ที่ในการพัฒนา คุณไม่ได้ใช้แคชเซิร์ฟเวอร์หรืออาจใช้อะแดปเตอร์คิวอื่น แต่ในการใช้งานจริง คุณใช้ Redis/Sidekiq ด้วยค่าเริ่มต้นของ Rails ใหม่ คุณสามารถเรียกใช้การตั้งค่าเดียวกันในการพัฒนาและการใช้งานจริงได้ ช่วยลดความประหลาดใจให้เหลือน้อยที่สุด สแต็กมีความสมบูรณ์ในตัวเองมากกว่าและ "ใช้งานได้" ทันทีโดยไม่ต้องมีการกำหนดค่าพิเศษสำหรับการใช้งานจริง
เซิร์ฟเวอร์หรือส่วนเสริมที่น้อยลงยังหมายถึงค่าโฮสติ้งที่ถูกกว่าอีกด้วย แม้ในระดับที่ใหญ่ขึ้น การรวมโครงสร้างพื้นฐานยังมาพร้อมกับประสิทธิภาพด้านต้นทุนอยู่บ้าง พื้นที่ฐานข้อมูลถูกกว่าหน่วยความจำ!
Rails ไม่ได้ป้องกันคุณจากการใช้ Redis หรือบริการอื่นๆ มันแค่ทำให้พวกเขา เป็นทางเลือก . คุณสามารถเริ่มต้นด้วยอะแดปเตอร์ Solid ในตัว และหากจำเป็น คุณสามารถแนะนำ Redis หรือโซลูชันอื่นๆ ตามมาได้
SQLite ขจัดความจำเป็นในกระบวนการฐานข้อมูล
การเปลี่ยนแปลงที่สำคัญอีกประการหนึ่งใน Rails 8 คือการปรับใช้ SQLite เป็นฐานข้อมูลการผลิตที่ใช้งานได้ ซึ่งเปิดใช้งานโดยการปรับปรุงมากมายกับอะแดปเตอร์ SQLite ของ Rails หากแอปของคุณสามารถใช้ SQLite ในการผลิตได้ คุณไม่จำเป็นต้องมีเซิร์ฟเวอร์ฐานข้อมูลแยกต่างหากที่ทำงานอยู่ ข้อมูลของคุณอยู่ในไฟล์ธรรมดาบนดิสก์ที่จัดการโดยกระบวนการของแอปแทน การปรับปรุง SQLite ของ Rails 8 ทำให้สิ่งนี้สมจริงกว่าที่เคยเป็น
SQLite สามารถทำให้การปรับใช้ตรงไปตรงมามากขึ้น คุณไม่จำเป็นต้องติดตั้งหรือจัดการ MySQL หรือ Postgres บนเซิร์ฟเวอร์ หรือใช้ (และชำระค่าบริการ!) บริการ DB ที่มีการจัดการ มันเป็นเพียงไฟล์ที่แอป Rails อ่านและเขียน
หากคุณเติบโตเร็วกว่า SQLite คุณสามารถย้ายไปยังระบบฐานข้อมูลที่มีคุณสมบัติครบถ้วนได้ในภายหลัง ทีมงานหลักของ Rails เพิ่งเปลี่ยนค่าเริ่มต้นเป็นตัวเลือกแบบน้ำหนักเบา ซึ่งเข้ากันได้ดีกับการเล่าเรื่องแบบ "ไม่มี PaaS"
Kamal 2 ช่วยคุณปรับใช้
Rails 8 ทำให้ การวิ่ง ง่ายขึ้น แอปที่กำลังใช้งานจริง แต่การได้แอปไปล่ะ การผลิต? การเปิดตัว Kamal 2 พยายามที่จะตอบคำถามนั้น
Kamal เป็นเครื่องมือจัดระเบียบที่ปรับใช้แอปของคุณ (ผ่านคอนเทนเนอร์ Docker) กับเซิร์ฟเวอร์ Linux ใด ๆ ด้วยความยุ่งยากน้อยที่สุด มันสร้างอิมเมจของแอปของคุณ พุช และรันบนเซิร์ฟเวอร์โดยอัตโนมัติ โดยที่คุณไม่ต้องสร้างการตั้งค่าเซิร์ฟเวอร์ทั้งหมดด้วยตนเอง
ด้วยการกำหนดค่าบางอย่างและคำสั่งเดียว (kamal setup ) Kamal จะนำกล่อง Linux ใหม่และจัดเตรียมสิ่งที่จำเป็นในการเรียกใช้คอนเทนเนอร์ Docker ของคุณ
หลังจากนั้น การใช้งานก็ทำได้ง่ายเพียงแค่เรียกใช้ kamal deploy ซึ่งจะดึงอิมเมจล่าสุดและสลับคอนเทนเนอร์เก่าเป็นคอนเทนเนอร์ใหม่ เป็นการปรับใช้แบบไม่ต้องหยุดทำงาน
Kamal 2 หวังที่จะมอบประสบการณ์การใช้งานที่เหมือนกับ PaaS บนโฮสต์ Linux ใดๆ ให้กับคุณ คุณสามารถเปลี่ยนเซิร์ฟเวอร์ใดๆ ให้เป็นเซิร์ฟเวอร์ Rails ที่รันแอปของคุณด้วยคำสั่งเดียว การกำหนดค่าเริ่มต้นอาจเป็นเรื่องยุ่งยาก แต่การใช้งานในภายหลังจะตรงไปตรงมามากกว่ามาก เป็นก้าวสำคัญในการทำให้การโฮสต์ด้วยตนเองสะดวกพอๆ กับการผลักดันไปสู่แพลตฟอร์มอย่าง Heroku
"ไม่มี PaaS" เป็นความคิดที่ดีหรือไม่
Rails 8 แท้จริงหรือไม่ ทำให้แพลตฟอร์มกลายเป็นอดีตไปแล้วเหรอ? และทีมขนาดเล็กถึงขนาดกลางสามารถประหยัดเงินด้วยการโฮสต์เองได้จริงหรือ
ฉันเพิ่งปรับใช้โปรเจ็กต์งานอดิเรกบน VPS โดยใช้ Kamal และมันเป็นประสบการณ์ที่น่าหงุดหงิด แม้ว่าการติดตั้งใช้งานจะค่อนข้างราบรื่นหลังจากที่ฉันใช้งานได้ แต่การตั้งค่าก็ยังห่างไกล และงานของฉันก็ถูกตัดออกไปหากจำเป็นต้องขยายขนาดโปรเจ็กต์นี้
ดังนั้นสำหรับฉัน คำตอบคือ ไม่ — Rails 8 ไม่ได้ลบคุณค่าที่นำเสนอของแพลตฟอร์ม . ฉันอยากจะมุ่งเน้นไปที่แอปของฉันและปล่อยให้แพลตฟอร์มเช่น Heroku จัดการโครงสร้างพื้นฐาน
นักพัฒนาเดี่ยวและทีมขนาดเล็กจะได้รับประโยชน์จากการมุ่งเน้นไปที่ผู้ใช้มากกว่าการไล่ตามการประหยัดต่อขนาด ทำไมไม่จ้างโฮสติ้ง การปรับใช้ และการปรับขนาดจากภายนอกมาเป็นแพลตฟอร์มที่ตอบโจทย์ในด้านเหล่านี้ และมุ่งเน้นไปที่การสร้างผลิตภัณฑ์ที่ลูกค้าชื่นชอบ
แน่นอนว่าเมื่อทีมและแอปพลิเคชันของคุณเติบโตขึ้น คุณอาจพบว่าราคาของแพลตฟอร์มมีความน่าดึงดูดน้อยลง เมื่อถึงจุดหนึ่ง การมีเวลาและ/หรือบุคคลที่ทุ่มเทให้กับ SRE และความรับผิดชอบในการปฏิบัติงานก็สมเหตุสมผลดี และ Kamal (รวมถึงค่าเริ่มต้นที่ยอดเยี่ยมอื่นๆ ของ Rails 8) ก็เป็นก้าวสำคัญในการทำให้ง่ายขึ้น
นำทุกอย่างมารวมกัน
Rails 8 ลดช่องว่างระหว่างการโฮสต์ด้วยตนเองและการใช้แพลตฟอร์ม แต่ก็ไม่ได้ปิดเพียงพอที่จะอ้างว่า “ไม่จำเป็นต้องใช้ PaaS” อย่างไรก็ตาม เป็นที่ชัดเจนแล้วว่า Rails 8 ช่วยให้การเลือก VPS ผ่าน PaaS ง่ายขึ้น โดยไม่ต้องเสียสละประสบการณ์ของนักพัฒนามากเกินไป ฉันไม่คิดว่ามันจะเป็นนักฆ่าแพลตฟอร์ม
Solid Cache, Solid Queue และ Solid Cable ล้วนนำข้อกำหนดของบุคคลที่สามก่อนหน้านี้สำหรับเว็บแอปมาสู่การสนับสนุนของบุคคลที่หนึ่ง และฉันรู้สึกขอบคุณสำหรับสิ่งนั้น เป็นเรื่องดีที่การมีค่าเริ่มต้นที่เบาแต่ทรงพลังในการทำให้แอปพลิเคชันใช้งานได้จริง และยิ่งกว่านั้นคือ แอปพลิเคชันเหล่านี้ไม่ต้องการโครงสร้างพื้นฐานมากนัก หากคุณเลือกที่จะโฮสต์เอง Kamal ก็สามารถแบ่งเบาภาระการติดตั้งใช้งานบางส่วนให้กับคุณได้
ไม่ว่าคุณจะใช้แพลตฟอร์มหรือไม่ก็ตาม การตรวจสอบถือเป็นสิ่งสำคัญสำหรับการตอบสนองต่อข้อผิดพลาดและการหยุดทำงานอย่างรวดเร็ว และมอบประสบการณ์ผู้ใช้ที่ยอดเยี่ยมให้กับลูกค้าของคุณ ลงทะเบียนเพื่อรับ Honeybadger เพื่อรับข้อมูลเชิงลึกแบบเรียลไทม์เกี่ยวกับประสิทธิภาพและประสิทธิภาพของแอปพลิเคชัน Rails ของคุณ
