วิธีแปลงงาน Linux cron เป็น "วิธีของ Amazon"

เพื่อให้ดีขึ้นหรือแย่ลงเราได้ย้ายเว็บแอปพลิเคชันLAMPทั้งหมดจากเครื่องเฉพาะไปยังระบบคลาวด์ (เครื่อง Amazon EC2) มันไปได้ดีมาก แต่วิธีที่เราทำcronsนั้นไม่เหมาะสม ฉันมีคำถามเฉพาะของ Amazon เกี่ยวกับวิธีจัดการงาน cron ในระบบคลาวด์ให้ดีที่สุดโดยใช้ "วิธีของ Amazon"

ปัญหา : เรามีเว็บเซิร์ฟเวอร์หลายเว็บและจำเป็นต้องเรียกใช้ crons สำหรับงานแบตช์เช่นการสร้าง RSS feeds การเรียกใช้อีเมลสิ่งต่างๆมากมาย แต่งาน cron จำเป็นต้องทำงานบนเครื่องเดียวเท่านั้นเพราะมักจะเขียนลงในฐานข้อมูลดังนั้นผลลัพธ์จะซ้ำกันหากทำงานบนหลายเครื่อง

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

เราจะออกแบบแอปพลิเคชันของเราใหม่เพื่อแปลงงาน Linux cron เป็นรายการงานชั่วคราวที่ไม่มีจุดล้มเหลวได้อย่างไร

ความคิดของฉันจนถึงตอนนี้:

• มีเครื่องสำหรับทำงานเฉพาะ crons เท่านั้น สิ่งนี้จะสามารถจัดการได้มากกว่าเล็กน้อย แต่ก็ยังคงเป็นจุดเดียวของความล้มเหลวและจะเสียเงินไปกับการเพิ่มอินสแตนซ์เพิ่มเติม
• งานบางอย่างสามารถย้ายจาก Linux crons ไปยังMySQL Events ได้แต่ฉันไม่ใช่แฟนตัวยงของแนวคิดนี้เพราะฉันไม่ต้องการใส่ตรรกะของแอปพลิเคชันลงในเลเยอร์ฐานข้อมูล
• บางทีเราสามารถเรียกใช้ crons ทั้งหมดในทุกเครื่อง แต่เปลี่ยนสคริปต์ cron ของเราดังนั้นทั้งหมดจึงเริ่มต้นด้วยตรรกะเล็กน้อยที่ใช้กลไกการล็อกดังนั้นเซิร์ฟเวอร์เพียงเครื่องเดียวเท่านั้นที่ดำเนินการจริงและเซิร์ฟเวอร์อื่น ๆ ฉันไม่ใช่แฟนตัวยงของความคิดนี้เพราะมันฟังดูอาจเป็นปัญหาและฉันอยากจะใช้แนวทางปฏิบัติที่ดีที่สุดของ Amazon มากกว่าที่จะทำแบบของเราเอง
• ฉันกำลังนึกภาพสถานการณ์ที่มีการกำหนดเวลางานไว้ที่ไหนสักแห่งเพิ่มในคิวแล้วเว็บเซิร์ฟเวอร์อาจเป็นคนงานที่พูดว่า "เดี๋ยวก่อนฉันจะรับงานนี้" Amazon Simple Workflow Serviceฟังดูเป็นแบบนี้ แต่ตอนนี้ฉันยังไม่ค่อยรู้เรื่องนี้มากนักดังนั้นข้อมูลเฉพาะใด ๆ จะเป็นประโยชน์ ดูเหมือนว่าจะมีน้ำหนักมากสำหรับบางสิ่งที่เรียบง่ายเหมือน cron? เป็นบริการที่ถูกต้องหรือมีบริการของ Amazon ที่เหมาะสมกว่านี้หรือไม่?

อัปเดต:ตั้งแต่ถามคำถามฉันได้ดูการสัมมนาผ่านเว็บของAmazon Simple Workflow Serviceบน YouTube และสังเกตเห็นเวลา 34:40 ( http://www.youtube.com/watch?v=lBUQiek8Jqk#t=34m40s ) ฉันได้เห็น สไลด์ที่กล่าวถึงงาน cron เป็นแอปพลิเคชันตัวอย่าง ในหน้าเอกสารของพวกเขา " ตัวอย่าง AWS Flow Framework สำหรับ Amazon SWF " Amazon กล่าวว่าพวกเขามีโค้ดตัวอย่างสำหรับ crons:

... > งาน Cronในตัวอย่างนี้เวิร์กโฟลว์ที่รันเป็นเวลานานจะเรียกใช้งานกิจกรรมเป็นระยะ ความสามารถในการดำเนินการต่อเนื่องจากการดำเนินการใหม่เพื่อให้การดำเนินการสามารถทำงานได้เป็นระยะเวลานานมากจะแสดงให้เห็น ...

ฉันดาวน์โหลด AWS SDK สำหรับ Java ( http://aws.amazon.com/sdkforjava/ ) และถูกฝังไว้ในโฟลเดอร์ที่ไร้สาระเพียงพอซึ่งมีรหัสจาวา ( aws-java-sdk-1.3.6/samples/AwsFlowFramework/src/com/amazonaws/services/simpleworkflow/flow/examples/periodicworkflow) อยู่

ปัญหาคือถ้าฉันพูดตามตรงสิ่งนี้ไม่ได้ช่วยอะไรเลยเพราะมันไม่ใช่สิ่งที่ฉันสามารถย่อยได้ง่ายๆด้วยชุดทักษะของฉัน ตัวอย่างเดียวกันหายไปจาก PHP SDK และดูเหมือนจะไม่มีบทช่วยสอนที่ดำเนินการตามกระบวนการ โดยพื้นฐานแล้วฉันยังคงต้องการคำแนะนำหรือเคล็ดลับ

ฉันลงทะเบียนเพื่อรับการสนับสนุนจาก Amazon Gold เพื่อถามคำถามนี้นี่คือคำตอบของพวกเขา:

ทอม

ฉันทำแบบสำรวจความคิดเห็นของเพื่อนร่วมงานบางคนและว่างเปล่าบน cron แต่หลังจากนอนกับมันฉันตระหนักว่าขั้นตอนสำคัญอาจ จำกัด อยู่ที่การล็อก ดังนั้นฉันจึงมองหา "การล็อกงาน cron แบบกระจาย" และพบข้อมูลอ้างอิงของ Zookeeper ซึ่งเป็นโครงการ Apache

http://zookeeper.apache.org/doc/r3.2.2/recipes.html

http://highscalability.com/blog/2010/3/22/7-secrets-to-successfully-scaling-with-scalr-on-amazon-by-se.html

นอกจากนี้ฉันยังเห็นการอ้างอิงถึงการใช้ memcached หรือกลไกการแคชที่คล้ายกันเพื่อสร้างการล็อกด้วย TTL ด้วยวิธีนี้คุณจะตั้งค่าสถานะโดยใช้ TTL เป็นเวลา 300 วินาทีและจะไม่มีผู้ปฏิบัติงาน cron คนอื่นทำงาน ระบบจะปลดล็อกโดยอัตโนมัติหลังจาก TTL หมดอายุ แนวคิดนี้คล้ายกับตัวเลือก SQS ที่เราพูดถึงเมื่อวานนี้

ดูด้วย; อ้วนของ Google http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//archive/chubby-osdi06.pdf

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

ขอแสดงความนับถืออย่างสูง,

Ronan G. Amazon Web Services

ฉันคิดว่าวิดีโอนี้ตอบคำถามของคุณได้อย่างแน่นอน - cronjobs ด้วยวิธีที่น่ากลัว (ปรับขนาดได้และทนต่อความผิดพลาด):

การใช้ Cron ในระบบคลาวด์กับ Amazon Simple Workflow

วิดีโออธิบายบริการSWFโดยใช้กรณีการใช้งานเฉพาะของการใช้งาน cronjobs

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

โปรดใช้ความระมัดระวังในการใช้ SQS สำหรับ cronjobs เนื่องจากไม่รับประกันว่าจะมีเพียง "งานเดียวเท่านั้นที่เห็นได้จากเครื่องจักรเพียงเครื่องเดียว" พวกเขารับประกันว่า "อย่างน้อยหนึ่ง" จะได้รับข้อความ

จาก: http://aws.amazon.com/sqs/faqs/#How_many_times_will_I_receive_each_message

ถาม: ฉันจะได้รับแต่ละข้อความกี่ครั้ง?

Amazon SQS ได้รับการออกแบบมาเพื่อจัดส่งข้อความทั้งหมดในคิว "อย่างน้อยหนึ่งครั้ง" แม้ว่าเวลาส่วนใหญ่แต่ละข้อความจะถูกส่งไปยังแอปพลิเคชันของคุณทุกครั้งคุณควรออกแบบระบบของคุณเพื่อให้การประมวลผลข้อความมากกว่าหนึ่งครั้งไม่ก่อให้เกิดข้อผิดพลาดหรือความไม่สอดคล้องกัน

จนถึงขณะนี้ฉันสามารถคิดเกี่ยวกับวิธีการที่คุณมีหนึ่งตัวอย่างที่มีอินสแตนซ์ Gearman งานเซิร์ฟเวอร์ที่ติดตั้ง: http://gearman.org/ บนเครื่องเดียวกันคุณกำหนดค่างาน cron ที่สร้างคำสั่งเพื่อดำเนินงาน cronjob ของคุณในพื้นหลัง จากนั้นหนึ่งในเว็บเซิร์ฟเวอร์ของคุณ (คนงาน) จะเริ่มทำงานนี้ซึ่งรับประกันได้ว่าจะมีเพียงเครื่องเดียวเท่านั้นที่รับได้ ไม่สำคัญว่าคุณจะมีพนักงานกี่คน (โดยเฉพาะเมื่อคุณใช้การปรับขนาดอัตโนมัติ)

ปัญหาในการแก้ปัญหานี้คือ:

• เซิร์ฟเวอร์ Gearman เป็นจุดเดียวของความล้มเหลวเว้นแต่คุณจะกำหนดค่าด้วยพื้นที่เก็บข้อมูลแบบกระจายตัวอย่างเช่นใช้ memcached หรือฐานข้อมูลบางส่วน
• จากนั้นใช้เซิร์ฟเวอร์ Gearman หลายเครื่องคุณต้องเลือกเซิร์ฟเวอร์ที่สร้างงานผ่าน cronjob อีกครั้งเรากลับมาที่ปัญหาเดิม แต่ถ้าคุณสามารถอยู่กับจุดเดียวของความล้มเหลวโดยใช้ Gearman ดูเหมือนเป็นทางออกที่ดีทีเดียว โดยเฉพาะอย่างยิ่งคุณไม่ต้องการอินสแตนซ์ขนาดใหญ่สำหรับสิ่งนั้น (ไมโครอินสแตนซ์ในกรณีของเราก็เพียงพอแล้ว)

Amazon เพิ่งเปิดตัวคุณสมบัติใหม่สำหรับ Elastic Beanstalk จากเอกสาร :

AWS Elastic Beanstalk รองรับงานเป็นระยะสำหรับ
ระดับสภาพแวดล้อมของผู้ปฏิบัติงานในสภาพแวดล้อมที่เรียกใช้การกำหนดค่าที่กำหนดไว้ล่วงหน้าด้วยชุดโซลูชันที่มี "v1.2.0" ในชื่อคอนเทนเนอร์ "

ตอนนี้คุณสามารถสร้างสภาพแวดล้อมที่มีcron.yamlไฟล์ที่กำหนดค่างานการจัดกำหนดการ:

version: 1
cron:
- name: "backup-job"          # required - unique across all entries in this file
  url: "/backup"              # required - does not need to be unique
  schedule: "0 */12 * * *"    # required - does not need to be unique
- name: "audit"
  url: "/audit"
   schedule: "0 23 * * *"

ฉันคิดว่าการประกันการรันเพียงครั้งเดียวในสภาพแวดล้อมที่ปรับขนาดอัตโนมัติถูกใช้ผ่านคิวข้อความ (SQS) เมื่อ cron daemon ทริกเกอร์เหตุการณ์จะทำให้การเรียกนั้นอยู่ในคิว SQS และข้อความในคิวจะถูกประเมินเพียงครั้งเดียว เอกสารกล่าวว่าการดำเนินการอาจล่าช้าหาก SQS มีข้อความจำนวนมากที่ต้องดำเนินการ

ฉันเจอคำถามนี้เป็นครั้งที่สามแล้วและคิดว่าฉันจะชิปเรามีปัญหานี้มาระยะหนึ่งแล้ว ฉันยังคงจริงๆรู้สึก AWS จะหายไปคุณลักษณะที่นี่

ในกรณีของเราหลังจากดูวิธีแก้ปัญหาที่เป็นไปได้เราตัดสินใจว่าเรามีสองทางเลือก:

• ตั้งค่าเซิร์ฟเวอร์ cronjob ซึ่งรันงานที่ควรรันครั้งละครั้งปรับขนาดอัตโนมัติและตรวจสอบให้แน่ใจว่าถูกแทนที่เมื่อสถิติ CloudWatch บางอย่างไม่ใช่สิ่งที่ควรจะเป็น เราใช้cloud-initสคริปต์เพื่อให้ cronjobs ทำงาน แน่นอนว่าสิ่งนี้มาพร้อมกับการหยุดทำงานซึ่งนำไปสู่การพลาด cronjobs (เมื่อทำงานบางอย่างทุกนาทีเหมือนที่เราทำ)
• ใช้ตรรกะที่rcronใช้. แน่นอนว่าเวทมนตร์ไม่ได้มีอยู่ในrcronตัวมันเองมันอยู่ในตรรกะที่คุณใช้เพื่อตรวจจับโหนดที่ล้มเหลว (เราใช้keepalivedที่นี่) และ "อัปเกรด" โหนดอื่นให้เชี่ยวชาญ

เราตัดสินใจเลือกใช้ตัวเลือกที่สองเพียงเพราะว่ามันเร็วมากและเรามีประสบการณ์กับเว็บเซิร์ฟเวอร์ที่เรียกใช้ cronjobs เหล่านี้แล้ว (ในยุคก่อน AWS)

แน่นอนว่าโซลูชันนี้มีไว้เพื่อแทนที่วิธีการทำงานร่วมกันแบบโหนดเดียวแบบเดิมโดยเฉพาะโดยที่เวลาเป็นปัจจัยในการตัดสินใจ (เช่น"ฉันต้องการให้งาน A ทำงานวันละครั้งตอนตี 5"หรือเช่นในกรณีของเรา"ฉันต้องการงาน B เพื่อทำงานทุกๆนาที " ) ถ้าคุณใช้ cronjobs ตรรกะทริกเกอร์การประมวลผลชุดคุณควรจริงๆSQSจะดูที่ ไม่มีภาวะที่กลืนไม่เข้าคายไม่ออกแอคทีฟ - พาสซีฟหมายความว่าคุณสามารถใช้เซิร์ฟเวอร์เครื่องเดียวหรือทั้งทีมเพื่อดำเนินการกับคิว ฉันขอแนะนำให้มองหาSWFการปรับขนาดพนักงานของคุณ (แม้ว่าauto scalingในกรณีส่วนใหญ่อาจทำได้เช่นกัน)

ขึ้นอยู่กับบุคคลที่สามรายอื่นเป็นสิ่งที่เราต้องการหลีกเลี่ยง

เมื่อวันที่ 12 / Feb / 16 Amazon blogged เกี่ยวกับงานการจัดตารางการใช้ SSH AWS แลมบ์ดา ฉันคิดว่านี่ตอบคำถาม

หากคุณมีบริการ Redis อยู่แล้วสิ่งนี้จะเป็นทางออกที่ดี:

https://github.com/kvz/cronlock

อ่านเพิ่มเติม: http://kvz.io/blog/2012/12/31/lock-your-cronjobs/

วิธีกระจาย "Amazon" หมายความว่า crons ขนาดใหญ่ควรแบ่งออกเป็นงานขนาดเล็กจำนวนมากและส่งไปยังเครื่องจักรที่เหมาะสม

ใช้คิว SQS ที่กำหนดประเภทเป็น FIFO ติดกาวเข้าด้วยกันเพื่อให้แน่ใจว่าแต่ละงานดำเนินการโดยเครื่องจักรเพียงเครื่องเดียว นอกจากนี้ยังทนต่อความล้มเหลวเนื่องจากคิวจะบัฟเฟอร์จนกว่าเครื่องจะหมุนสำรอง

FIFO Exactly-Once Processing : ข้อความจะถูกส่งครั้งเดียวและยังคงพร้อมใช้งานจนกว่าผู้บริโภคจะประมวลผลและลบทิ้ง ไม่มีการนำรายการที่ซ้ำกันเข้ามาในคิว

พิจารณาด้วยว่าคุณจำเป็นต้อง 'แบทช์' การดำเนินการเหล่านี้จริงๆหรือไม่ จะเกิดอะไรขึ้นหากการอัปเดตในคืนเดียวมีขนาดใหญ่กว่าที่คาดไว้มาก? แม้จะมีการจัดหาทรัพยากรแบบไดนามิกการประมวลผลของคุณอาจล่าช้าเพื่อรอให้เครื่องหมุนมากพอ แต่ให้จัดเก็บข้อมูลของคุณใน SDB แจ้งการอัปเดตให้กับเครื่องผ่าน SQS และสร้างฟีด RSS ของคุณได้ทันที (ด้วยแคช)

งานแบทช์มาจากช่วงเวลาที่ทรัพยากรในการประมวลผลมี จำกัด และบริการ 'สด' มีความสำคัญเหนือกว่า ในระบบคลาวด์ไม่เป็นเช่นนั้น

ทำไมคุณถึงสร้างของคุณเอง? ทำไมไม่ใช้บางอย่างเช่น Quartz (พร้อม Clustered Scheduling) ดูเอกสารประกอบ

http://quartz-scheduler.org/documentation/quartz-2.x/configuration/ConfigJDBCJobStoreClustering

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

ทำงานเหมือนแชมป์

วิธีหนึ่งในการตรวจสอบว่านิพจน์ cron ของคุณใช้งานได้กับวิธีของ Amazon คือเรียกใช้ผ่านคำสั่ง events ตัวอย่างเช่น:

aws events put-rule --name "DailyLambdaFunction" --schedule-expression "<your_schedule_expression>

หากนิพจน์กำหนดการของคุณไม่ถูกต้องสิ่งนี้จะล้มเหลว

แหล่งข้อมูลเพิ่มเติม: https://docs.aws.amazon.com/cli/latest/reference/events/put-rule.html

หากคุณยินดีที่จะใช้บริการที่ไม่ใช่ AWS แล้วคุณอาจตรวจสอบMicrosoft Azure สีฟ้ามีดีกำหนดการงาน

เนื่องจากไม่มีใครพูดถึงCloudWatch Eventฉันจึงบอกได้ว่านี่เป็นวิธีการทำงานของ cron ของ AWS สามารถรันการทำงานได้หลายอย่างเช่นฟังก์ชันแลมบ์ดางาน ECS