การปรับใช้ Rails กับ AWS Lambda

การประมวลผลแบบไร้เซิร์ฟเวอร์ช่วยลดภาระงานในการจัดการและจัดเตรียมเซิร์ฟเวอร์ให้กับผู้ให้บริการระบบคลาวด์ และกำลังกลายเป็นสิ่งสำคัญสำหรับทีมเทคโนโลยีส่วนใหญ่อย่างรวดเร็ว AWS Lambda เป็นเทคโนโลยีไร้เซิร์ฟเวอร์ประเภทหนึ่งที่ใช้โดยทีมเทคโนโลยีจำนวนมาก AWS Lambda รองรับภาษาการเขียนโปรแกรมหลักส่วนใหญ่ รวมถึง NodeJS, Java, Python และ Ruby แม้ว่าภาษาโปรแกรมหลักจะได้รับการสนับสนุน แต่อาจมีบางครั้งที่คุณต้องการเรียกใช้ฟังก์ชันแบบไร้เซิร์ฟเวอร์ขึ้นอยู่กับคุณลักษณะที่เป็นส่วนหนึ่งของกรอบงานที่สร้างขึ้นด้วยภาษาเหล่านี้ ในโพสต์นี้ เราจะสำรวจวิธีเรียกใช้แอปพลิเคชัน Rails ใน AWS Lambda โพสต์นี้อนุมานว่าคุณคุ้นเคยกับการประมวลผลแบบไร้เซิร์ฟเวอร์และ AWS Lambda และคุณต้องการทราบวิธีเรียกใช้ Rails บน AWS Lambda เครื่องมือที่ชื่อว่า Lamby ทำให้การรัน Rails ใน AWS Lambda นั้นทำได้ง่าย และเราจะครอบคลุมถึงวิธีที่ Lamby สามารถใช้ในการสร้างและปรับใช้ Rails กับ Lambda ฉันจะเรียกมันว่า "Rails on Lambda"

แลมบีคืออะไร

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

แลมบ์ดาคาดหวังให้โค้ดของคุณมีโครงสร้างบางอย่าง ดังนั้น หากคุณต้องการใช้โฮสต์บางอย่าง เช่น แอป Rails คุณจะต้องใช้อะแดปเตอร์อย่าง Lamby

Lamby เป็นอะแดปเตอร์แร็คที่เรียบง่าย โดยอยู่ระหว่างแอป Rails และ AWS Lambda และแปลงเหตุการณ์การเรียกใช้ Lambda จากแหล่ง AWS ต่างๆ เช่น เกตเวย์ API หรือตัวโหลดบาลานซ์ของแอปพลิเคชัน เป็นเหตุการณ์ Rack ที่แอป Rails ของคุณสามารถรับฟังได้

แหล่งที่มาของสถาปัตยกรรม Rails Lambda:Lamby Docs

Lamby ใช้ประโยชน์จาก Docker &AWS SAM เพื่อสร้าง จัดทำแพ็คเกจ และปรับใช้แอป Rails กับ Lambda

AWS Serverless Application Model (AWS SAM) เป็นเฟรมเวิร์กโอเพ่นซอร์สที่คุณสามารถใช้เพื่อสร้างแอปพลิเคชันแบบไร้เซิร์ฟเวอร์บน AWS แอปพลิเคชันแบบไร้เซิร์ฟเวอร์เป็นการผสมผสานระหว่างฟังก์ชัน Lambda แหล่งที่มาของเหตุการณ์ และทรัพยากรอื่นๆ ที่ทำงานร่วมกันเพื่อทำงาน โปรดทราบว่าแอปพลิเคชันแบบไร้เซิร์ฟเวอร์เป็นมากกว่าฟังก์ชัน Lambda—แต่สามารถรวมทรัพยากรเพิ่มเติม เช่น API, ฐานข้อมูล และการจับคู่แหล่งที่มาของเหตุการณ์-- เอกสาร AWS SAM

ในการเริ่มต้นใช้งาน Lamby เราจำเป็นต้องติดตั้ง Docker สร้างบัญชี AWS และกำหนดค่าการเข้าถึงแบบเป็นโปรแกรมสำหรับบัญชี AWS ของคุณ

กำลังติดตั้ง Docker

AWS SAM ใช้ Docker เพื่อจำลองสภาพแวดล้อมรันไทม์ของ Lambda Docker ยังช่วยลดความซับซ้อนในการติดตั้ง AWS CLI และ SAM CLI ซึ่งทั้งคู่ต้องอาศัย Python หากคุณยังไม่ได้ติดตั้ง Docker การติดตั้ง Docker นั้นง่ายมาก เนื่องจากคุณสามารถดาวน์โหลดและติดตั้งได้จากเว็บไซต์ทางการ ในการตรวจสอบว่ามีการติดตั้ง Docker หรือไม่ ให้รันคำสั่งด้านล่างในเทอร์มินัลของคุณ หากติดตั้ง Docker ไว้ คุณจะเห็นหมายเลขเวอร์ชันและบิลด์คล้ายกับที่แสดงด้านล่าง:

$ docker --version

การยืนยันการติดตั้ง Docker

การตั้งค่าบัญชี AWS

หากคุณยังไม่มีบัญชี AWS คุณจะต้องตั้งค่า Amazon มีแผนฟรีเทียร์ ซึ่งจะครอบคลุมการสร้างและทดสอบแอป Rails ใน Lambda ตลอดจนคำแนะนำเกี่ยวกับวิธีสร้างและเปิดใช้งานบัญชี AWS ทำตามคำแนะนำเพื่อตั้งค่าบัญชีของคุณ

การตั้งค่าการเข้าถึงแบบเป็นโปรแกรมของ AWS

ตอนนี้คุณมีบัญชี AWS แล้ว คุณจะต้องกำหนดค่าการเข้าถึงแบบเป็นโปรแกรมโดยใช้ AWS Access Key ID และ AWS Secret Access Key ของบัญชีของคุณ หากยังไม่มี คุณสามารถสร้างได้โดยทำดังต่อไปนี้

• เข้าสู่ระบบบัญชี AWS ของคุณ
• ใน AWS Management Console ให้คลิกที่ "บริการ" ในแถบเครื่องมือ
• ค้นหาและเลือก "IAM"
• คลิกที่ "ผู้ใช้" จากการนำทางด้านซ้ายมือ
• หากมี "IAM" อยู่แล้ว ให้เลือกชื่อผู้ใช้ของคุณ
  • คลิกแท็บ "ข้อมูลรับรองความปลอดภัย"
  • คลิกปุ่ม "สร้างคีย์การเข้าถึง"
  • คัดลอกรหัสคีย์และข้อมูลลับของคุณไปยังที่ที่ปลอดภัย
• หากไม่มีผู้ใช้ "IAM"
  • คลิกที่ "เพิ่มผู้ใช้"
  • เพิ่มชื่อผู้ใช้และเลือกตัวเลือก "การเข้าถึงแบบเป็นโปรแกรม"
  • ปฏิบัติตามคำแนะนำเพื่อดำเนินการให้เสร็จสิ้น

ลองใช้ Docker เพื่อกำหนดค่าการเข้าถึงแบบเป็นโปรแกรมของ CLI คัดลอกโค้ดด้านล่างไปยังเทอร์มินัลของคุณ คุณจะได้รับข้อความให้ใส่รหัส AWS Access Key และ AWS Secret Access Key ป้อนคีย์จากขั้นตอนก่อนหน้า

$ docker run \
  --interactive \
  --tty \
  --rm \
  --volume "${HOME}/.aws:/root/.aws" \
  "amazon/aws-cli" \
  configure

การสร้างแอปพลิเคชัน Rails ใหม่

เราจะใช้ SAM CLI เพื่อบูตสแตรปโครงการ Rails ของเรา AWS SAM CLI ช่วยให้คุณเริ่มต้นโปรเจ็กต์ใหม่จากเทมเพลตที่เก็บ GitHub ซึ่งเรียกกันทั่วไปว่าเครื่องตัดคุกกี้ ในการเริ่มโครงการ SAM ใหม่ เราจะใช้คอนเทนเนอร์ Docker เพื่อเรียกใช้ sam init ซึ่งใช้ประโยชน์จากเทมเพลตโปรเจ็กต์ Lamby Cookiecutter เพื่อเริ่มต้นโฟลเดอร์โปรเจ็กต์ใหม่สำหรับคุณ คุณจะได้รับแจ้งให้ระบุชื่อโครงการ แต่ฉันใช้ "rails_on_lambda" แล้ว

$ docker run \
  --rm \
  --interactive \
  --volume "${PWD}:/var/task:delegated" \
  lambci/lambda:build-ruby2.7 \
  sam init --location "gh:customink/lamby-cookiecutter"

โฟลเดอร์โปรเจ็กต์ SAM ใหม่ของคุณมีทุกสิ่งที่คุณต้องการสำหรับโปรเจ็กต์ Rails บน Lambda ใหม่ของคุณ จากระดับที่สูงขึ้น นี่คือสิ่งที่สร้างขึ้นในโครงการใหม่ของคุณ

• การตั้งค่า Docker โดยใช้ทั้ง Dockerfile และ Docker-compose
• โปรเจ็กต์ Ruby ที่ใช้งานได้พร้อมไดเร็กทอรี lib, บันเดิล และการทดสอบ
• SAM template.yaml ไฟล์.

ตั้งค่าและปรับใช้

ตอนนี้เราได้สร้างแอป Rails ใหม่แล้ว เราต้องตั้งค่าสำหรับการปรับใช้ Lambda สองคำสั่งด้านล่างรันสคริปต์ที่สร้างอิมเมจการพัฒนา Docker และบันเดิลเจม bootstrap คำสั่งเป็นกระบวนการแบบครั้งเดียว ในขณะที่ setup คำสั่งจะทำงานทุกครั้งที่คุณเพิ่มการพึ่งพาโปรเจ็กต์ใหม่

$ ./bin/bootstrap
$ ./bin/setup

เมื่อดำเนินการคำสั่งก่อนหน้านี้สำเร็จแล้ว โปรเจ็กต์ของคุณก็พร้อมสำหรับการปรับใช้ผ่าน SAM การปรับใช้ทำได้โดยใช้สคริปต์ Lamby ที่สร้าง แพ็กเกจ และปรับใช้แอปพลิเคชัน Rails ของคุณ

./bin/deploy

deploy คำสั่งเรียกใช้สคริปต์การสร้าง Lamby ที่ทำซ้ำไดเร็กทอรีโครงการปัจจุบันของคุณลงใน .lamby ไดเร็กทอรีและรันคำสั่ง SAM สามคำสั่งที่จำเป็นในการปรับใช้แอปพลิเคชันของคุณ

• แซมบิวด์
• แซมแพ็คเกจ
• แซมปรับใช้

หากสคริปต์ทำงานตามที่คาดไว้ คุณควรเห็นผลลัพธ์สำหรับงานการปรับใช้ CloudFormation ของ SAM ที่ลงท้ายด้วยสิ่งนี้:

คุณควรเห็น URL เป็นส่วนหนึ่งของเอาต์พุตเทอร์มินัลด้วย URL คือปลายทาง API เกตเวย์ HTTP API ที่เรียกใช้แอปพลิเคชัน Rails ของคุณโดยใช้แร็ค เปิดในเบราว์เซอร์ของคุณและคุณจะเห็นหน้าจอ "ยินดีต้อนรับสู่ Rails" ที่คุ้นเคย:

การเรียกใช้แอป Rails ของคุณจากคอนโซล AWS

เราสามารถทดสอบแอปของเราได้จากแดชบอร์ดของแลมบ์ดา เข้าสู่ระบบ AWS Management Console:

• คลิกที่ "บริการ" ในแถบเครื่องมือ
• ป้อน "Lambda" ในช่องค้นหาบริการ เลือก

จากหน้านี้ คุณจะเห็นโปรเจ็กต์ "RailsOnLambda" ที่เพิ่งปรับใช้ใหม่

• เปิดฟังก์ชัน "RailsOnLambda"
• คลิกที่ปุ่ม "ทดสอบ" ที่มุมขวาบน
• ใช้เทมเพลตเหตุการณ์ "Amazon API Gateway Proxy" (ใช้เทมเพลต JSON ด้านล่างเพื่ออัปเดตฟิลด์ที่เกี่ยวข้อง)
• ตั้งชื่อเป็น "RailsOnLambdaTest"
• คลิกปุ่ม "สร้าง"
• คลิกปุ่ม "ทดสอบ" เพื่อเรียกใช้ Lambda ของคุณ

{
  "body": "",
  "path": "/",
  "httpMethod": "GET",
  "queryStringParameters": {},
  "multiValueQueryStringParameters": {},
  "pathParameters": {
    "proxy": "/"
  },
  "stageVariables": {},
  "requestContext": {
    "path": "/",
    "httpMethod": "GET"
  }
}

สมมติว่าทุกอย่างราบรื่น คุณควรเห็นผลลัพธ์คล้ายกับด้านล่าง

ยินดีด้วย! ตอนนี้คุณมี Rails บน Lambda แล้ว แม้ว่าแอปพลิเคชัน Rails บน Lambda จะยังคงเป็นแอปพลิเคชัน Rails ปกติก็ตาม ข้อแตกต่างเพียงอย่างเดียวคือ Lamby gem แปลง API เกตเวย์ HTTP API, API เกตเวย์ REST API และเหตุการณ์เป้าหมายตัวโหลดบาลานซ์ของแอปพลิเคชันเป็น env ที่เข้ากันได้กับแร็ค วัตถุและส่งไปยัง Rails จากนั้น Rails จะส่งคืนผลลัพธ์ของเหตุการณ์ไปยังตัวจัดการ Lambda ที่กำหนดไว้ในโปรเจ็กต์ของคุณ

def handler(event:, context:)
 Lamby.handler $app, event, context
end

Rails บน Lambda ทำงานได้ดีเพียงใด

Rails บน Lambda จะมีเวลาตอบสนองช้าสำหรับคำขอแรกหลังการปรับใช้ ปรากฏการณ์นี้เรียกว่า "สตาร์ทเย็น" อย่างไรก็ตาม หลังจากขอครั้งแรก ประสิทธิภาพก็ยอดเยี่ยมและสามารถตอบสนองหรือเอาชนะ EC2 ได้ หากไม่มีคำขอที่ตามมาหลังจากคำขอครั้งแรก ทรัพยากรเซิร์ฟเวอร์ที่ให้บริการแอป Rails จะถูกกำหนดแบบไดนามิกให้กับฟังก์ชัน Lambda อื่นๆ หลังจากประมาณ 5-7 นาที การดำเนินการนี้จะทำให้เกิดการเริ่มเย็นสำหรับคำขอใหม่ มีสองวิธีในการหลีกเลี่ยงการสตาร์ทแบบเย็นและทำให้แอป Rails อุ่นขึ้น

ตัวจับเวลา CloudWatch

คุณสามารถตั้งเวลาในการ ping Rails บนฟังก์ชัน Lambda ทุกนาทีเพื่อให้เครื่องอุ่นขึ้น เปิดคอนโซล AWS และค้นหา CloudWatch จากนั้นไปที่เหตุการณ์แล้วคลิกสร้างกฎ ตั้งค่าประเภทกิจกรรมเป็นกำหนดการ และเราจะจัดกิจกรรมนี้ทุกๆ 1 นาที

การทำงานพร้อมกันที่มีการเตรียมใช้งาน

การทำงานพร้อมกันที่มีการเตรียมใช้งานเป็นคุณลักษณะของ AWS ที่ช่วยให้คุณสลับและตกลงที่จะจ่ายมากขึ้นเพื่อให้ AWS รักษาคอนเทนเนอร์ที่ไม่ได้ใช้ให้ทำงานตลอดเวลา ในการกำหนดค่าสกุลเงินที่เตรียมใช้งานสำหรับแอป Rails ให้เปิดคอนโซล AWS และเปิดหน้าบริการ Lambda

• เลือกฟังก์ชัน (rails-on-lambda)
• เลือกการกำหนดค่า จากนั้นเลือก Concurrency
• ภายใต้การกำหนดค่าการทำงานพร้อมกันที่มีการเตรียมใช้งาน ให้คลิกที่เพิ่มการกำหนดค่า
• เลือกนามแฝงหรือเวอร์ชัน
• ป้อนจำนวนของการทำงานพร้อมกันที่จัดเตรียมไว้ (เช่น 500) เพื่อจัดสรร
• บันทึกการเปลี่ยนแปลงของคุณ สกุลเงินที่จัดเตรียมสามารถกำหนดค่าผ่าน AWS CLI โดยใช้คำสั่งต่อไปนี้:

aws lambda put-provisioned-concurrency-config --function-name my-function \
--qualifier BLUE --provisioned-concurrent-executions 100

ค่าใช้จ่ายของ Lambda บน AWS คืออะไร

ด้วย AWS Lambda คุณจะจ่ายเฉพาะสิ่งที่คุณใช้เท่านั้น ต้นทุนคือการรวมกันของจำนวนคำขอและระยะเวลาของการดำเนินการโค้ด ราคาระยะเวลาขึ้นอยู่กับจำนวนหน่วยความจำที่คุณจัดสรรให้กับฟังก์ชันของคุณ ขนาดหน่วยความจำมีตั้งแต่ 128 MB ถึง 10,240 MB และคุณสามารถจัดสรรหน่วยความจำจำนวนเท่าใดก็ได้ให้กับฟังก์ชันของคุณขึ้นอยู่กับความต้องการของคุณ ด้านล่างนี้คือแผนภูมิที่แสดงค่าใช้จ่ายในการเรียกใช้ฟังก์ชัน Lambda 100,000 ครั้งในช่วงเวลาที่แตกต่างกัน

ค่าใช้จ่ายแลมบ์ดา

เมื่อคุณไม่ควรใช้ Rails บน Lambda

เราได้เห็นแล้วว่าเราสามารถเรียกใช้แอป Rails บน AWS Lambda ได้ แต่ทุกแอปพลิเคชัน Rails ควรทำงานบน Lambda หรือไม่ Rails ถือว่าแอปพลิเคชันของคุณทำงานบนเซิร์ฟเวอร์แบบเดิมและไม่ใช่แบบไม่มีเซิร์ฟเวอร์ การดำเนินการบางอย่างที่ทำงานได้ง่ายในแอปเซิร์ฟเวอร์ Rails แบบดั้งเดิมอาจไม่ทำงานแบบไร้เซิร์ฟเวอร์ ตัวอย่างเช่น การอัปโหลดไฟล์หรือรูปภาพจะไม่ทำงานในแอป Rails บน Lambda เนื่องจากแอปไม่มีสิทธิ์เข้าถึงระบบไฟล์แบบถาวร นอกจากนี้ การสื่อสาร WebSocket จะไม่ทำงานบน Lambda เนื่องจากเซิร์ฟเวอร์ของคุณไม่มีอยู่จริงเมื่อไม่มีคำขอ

บทสรุป

เราได้แสดงวิธีการปรับใช้แอปพลิเคชัน Rails พื้นฐานเท่านั้น แต่มีการปฏิบัติตามกระบวนการเดียวกันสำหรับแอปพลิเคชันขนาดใหญ่ คุณสามารถเพิ่มตัวควบคุม เส้นทาง และทดสอบจากคอนโซลหรือผ่านบุรุษไปรษณีย์และไคลเอ็นต์ HTTP อื่นๆ ได้