Linux cron işleri "Amazon tarzı" na nasıl dönüştürülür?

İyi ya da kötü, tüm LAMP web uygulamamızı özel makinelerden buluta (Amazon EC2 makineleri) taşıdık. Şimdiye kadar harika gidiyor ama crons yapma şeklimiz yetersiz . Buluttaki cron işlerini "Amazon yöntemini" kullanarak en iyi şekilde nasıl yönetebileceğim konusunda Amazon'a özgü bir sorum var.

Sorun : Birden fazla web sunucumuz var ve RSS beslemeleri oluşturma, e-postaları tetikleme, aslında birçok farklı şey gibi toplu işler için cron'lar çalıştırmamız gerekiyor. ANCAK cron işlerinin yalnızca bir makinede çalışması gerekir, çünkü genellikle veritabanına yazarlar ve birden fazla makinede çalıştırılırsa sonuçları çoğaltır.

Şimdiye kadar, web sunucularından birini "ana web sunucusu" olarak belirledik ve diğer web sunucularının sahip olmadığı birkaç "özel" görevi var. Bulut bilişimin değiş tokuşu güvenilirliktir - "ana web sunucusu" istemiyoruz çünkü bu tek bir hata noktası. Bunların hepsinin aynı olmasını ve ana web sunucusunu kümeden çıkarmamayı hatırlamadan ölçeklendirip küçültebilmelerini istiyoruz.

Linux cron işlerini tek bir hata noktası olmayan geçici çalışma öğelerine dönüştürmek için uygulamamızı nasıl yeniden tasarlayabiliriz?

Şimdiye kadarki fikirlerim:

• Yalnızca çalışan cronlara ayrılmış bir makineye sahip olun. Bu biraz daha yönetilebilir, ancak yine de tek bir başarısızlık noktası olur ve fazladan bir örnekle biraz para israfına neden olur.
• Bazı işler muhtemelen Linux crons'tan MySQL Events'e taşınabilir, ancak uygulama mantığını veritabanı katmanına koymak istemediğim için bu fikrin büyük bir hayranı değilim.
• Belki tüm cronları tüm makinelerde çalıştırabiliriz, ancak cron betiklerimizi değiştirebiliriz, böylece hepsi bir kilitleme mekanizması uygulayan bir mantıkla başlar, böylece sadece bir sunucu gerçekten harekete geçer ve diğerleri sadece atlar. Potansiyel olarak hatalı göründüğü için bu fikrin hayranı değilim ve kendiminkini devirmek yerine Amazon'un en iyi uygulamasını kullanmayı tercih ederim.
• İşlerin bir yerde planlandığı, bir kuyruğa eklendiği ve ardından web sunucularının her birinin "hey, bunu alacağım" diyebilen birer işçi olabileceği bir durum hayal ediyorum. Amazon Simple Workflow Service tam olarak bu tür bir şey gibi görünüyor, ancak şu anda hakkında pek bir şey bilmiyorum, bu nedenle herhangi bir ayrıntı yardımcı olabilir. Bir cron kadar basit bir şey için biraz ağır gibi görünüyor? Doğru hizmet mi yoksa daha uygun bir Amazon hizmeti var mı?

Güncelleme: Soruyu sorduğumdan beri YouTube'da Amazon Simple Workflow Service web seminerini izledim ve 34:40 ( http://www.youtube.com/watch?v=lBUQiek8Jqk#t=34m40s ) cron işlerinden örnek bir uygulama olarak bahseden slayt. Amazon , " Amazon SWF için AWS Flow Framework örnekleri " adlı belge sayfalarında, crons için örnek kodlara sahip olduklarını söylüyor:

... > Cron işleri Bu örnekte, uzun süren bir iş akışı periyodik olarak bir etkinlik yürütür. Yürütme işlemlerine yeni yürütmeler olarak devam etme yeteneği, böylece bir yürütmenin çok uzun süreler boyunca çalışabileceği gösterilmiştir. ...

AWS SDK for Java'yı ( http://aws.amazon.com/sdkforjava/ ) indirdim ve gülünç klasör katmanlarının içinde yeterince java kodu ( aws-java-sdk-1.3.6/samples/AwsFlowFramework/src/com/amazonaws/services/simpleworkflow/flow/examples/periodicworkflow) bulunduğundan eminim .

Sorun şu ki, eğer dürüst olursam, beceri setimle kolayca sindirebileceğim bir şey olmadığı için bu gerçekten yardımcı olmuyor. Aynı örnek PHP SDK'da eksik ve süreç boyunca yürüyen bir öğretici görünmüyor. Yani temelde, hala tavsiye veya ipucu arıyorum.

Onlara bu soruyu sormak için Amazon Gold desteğine kaydoldum, bu onların yanıtıydı:

Tom

Meslektaşlarımdan bazılarına hızlı bir anket yaptım ve cronda boş göründüm, ancak üzerinde uyuduktan sonra önemli adımın kilitlemekle sınırlı olabileceğini fark ettim. Bu yüzden "dağıtılmış cron işi kilitlemeyi" aradım ve bir Apache projesi olan Zookeeper'a bir referans buldum.

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

Ayrıca, bir TTL ile kilitler oluşturmanın bir yolu olarak memcached veya benzer bir önbellekleme mekanizmasını kullanma referansını gördüm. Bu şekilde, 300 saniyelik bir TTL'ye sahip bir bayrak belirlersiniz ve başka hiçbir cron işçisi işi yürütmez. TTL'nin süresi dolduktan sonra kilit otomatik olarak serbest bırakılacaktır. Bu, kavramsal olarak dün tartıştığımız SQS seçeneğine çok benziyor.

Ayrıca bakınız; Google'ın tombul http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//archive/chubby-osdi06.pdf

Bunun yardımcı olup olmadığını bana bildirin ve soru sormaktan çekinmeyin, hizmetlerimizin hem yeni başlayanlar hem de deneyimli geliştiriciler için karmaşık ve göz korkutucu olabileceğinin farkındayız. Mimari ve en iyi uygulama tavsiyeleri sunmaktan her zaman mutluluk duyarız.

Saygılarımla,

Ronan G. Amazon Web Hizmetleri

Bu videonun tam olarak sorunuzu yanıtladığını düşünüyorum - aws yöntemiyle cronjobs (ölçeklenebilir ve hataya dayanıklı):

Amazon Simple Workflow ile Bulutta Cron Kullanımı

Video, SWF hizmetini cronjobs uygulamasının özel kullanım durumunu kullanarak açıklamaktadır .

Doğrudan bir crontab'dan geliyorsanız, çözümün göreceli karmaşıklığını yutmak zor olabilir. Sonunda, bu ekstra karmaşıklığın size ne kazandırdığını anlamama yardımcı olan bir vaka çalışması var. Mevcut crontab çözümünüzden geçiş yapmanız gerekip gerekmediğine karar vermek için örnek olay incelemesini izlemenizi ve ölçeklenebilirlik ve hata toleransı gereksinimlerinizi göz önünde bulundurmanızı öneririm.

Cronjobs için SQS kullanırken dikkatli olun, çünkü bunlar "yalnızca bir işin yalnızca bir makine tarafından görülmesini" garanti etmez. "En az birinin" mesajı alacağını garanti ediyorlar.

Gönderen: http://aws.amazon.com/sqs/faqs/#How_many_times_will_I_receive_each_message

S: Her mesajı kaç kez alacağım?

Amazon SQS, sıralarındaki tüm iletilerin "en az bir kez" teslim edilmesini sağlayacak şekilde tasarlanmıştır. Çoğu zaman her mesaj uygulamanıza tam olarak bir kez teslim edilecek olsa da, sisteminizi bir mesajın birden fazla kez işlenmesi herhangi bir hata veya tutarsızlık oluşturmayacak şekilde tasarlamalısınız.

Şimdiye kadar Gearman Job Server örneğinin kurulu olduğu bir örneğinizin olduğu çözümü düşünebilirim: http://gearman.org/ . Aynı makinede, cronjob görevinizi arka planda yürütmek için komut üreten cron işlerini yapılandırırsınız. Ardından web sunucularınızdan (çalışanlarınızdan) biri bu görevi yerine getirmeye başlayacak, yalnızca birinin onu alacağını garanti ediyor. Kaç işçiniz olduğu önemli değildir (özellikle otomatik ölçeklendirmeyi kullanırken).

Bu çözümle ilgili sorunlar şunlardır:

• Gearman sunucusu, memcached veya bazı veritabanlarını kullanarak dağıtılmış depolama ile yapılandırmadığınız sürece tek hata noktasıdır.
• Daha sonra birden fazla Gearman sunucusu kullanarak, cronjob aracılığıyla görev oluşturan birini seçmeniz gerekir, böylece yine aynı soruna geri dönüyoruz. Ancak bu tür tek bir hata noktasıyla yaşayabilirseniz, Gearman'i kullanmak oldukça iyi bir çözüm gibi görünüyor. Özellikle bunun için büyük örneğe ihtiyacınız olmadığı için (bizim durumumuzda mikro örnek yeterlidir).

Amazon, Elastic Beanstalk için yeni özellikler yayınladı . Gönderen docs :

AWS Elastic Beanstalk
, kapsayıcı adında "v1.2.0" içeren bir çözüm yığınıyla önceden tanımlanmış bir yapılandırma çalıştıran ortamlarda çalışan ortamı katmanları için periyodik görevleri destekler . "

Artık cron.yamlzamanlama görevlerini yapılandıran bir dosya içeren bir ortam oluşturabilirsiniz :

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 * * *"

Otomatik ölçeklendirilmiş bir ortamda yalnızca bir kez çalıştırmanın sigortasının mesaj kuyruğu (SQS) aracılığıyla kullanıldığını hayal ediyorum. Cron daemon bir olayı tetiklediğinde, bu aramayı SQS kuyruğuna koyar ve kuyruktaki mesaj yalnızca bir kez değerlendirilir. Dokümanlar, SQS'nin işlenecek çok sayıda mesajı varsa yürütmenin gecikebileceğini söylüyor.

Şimdi bu soruyla üçüncü kez karşılaştım ve devreye gireceğimi düşündüm. Bu ikilemi bir süredir yaşıyoruz. Hala gerçekten AWS burada bir özellik eksik hissediyorum.

Bizim durumumuzda olası çözümlere baktıktan sonra iki seçeneğimiz olduğuna karar verdik:

• Her seferinde yalnızca bir kez çalıştırılması gereken işleri çalıştıran bir cronjob sunucusu kurun, onu otomatik olarak ölçeklendirin ve belirli CloudWatch istatistikleri olması gerektiği gibi olmadığında değiştirildiğinden emin olun. cloud-initCronjobs'u çalıştırmak için betikler kullanıyoruz . Tabii ki, bu bir kesinti süresiyle birlikte gelir ve kaçırılan cronjob'lara yol açar (yaptığımız gibi her dakika belirli görevleri çalıştırırken).
• Kullanan mantığı kullanın rcron. Elbette, sihir aslında rcronkendi başına değil , başarısız bir düğümü tespit etmek (burada kullanıyoruz keepalived) ve başka bir düğümü ustalaşmak için "yükseltmek" için kullandığınız mantıkta .

İkinci seçeneğe geçmeye karar verdik, çünkü son derece hızlı ve bu cronjob'ları çalıştıran web sunucuları ile zaten deneyimimiz vardı (AWS öncesi çağımızda).

Elbette, bu çözüm özellikle zamanlamanın belirleyici faktör olduğu geleneksel tek düğümlü cronjob yaklaşımının yerini almaya yöneliktir (ör. "A işinin günde bir kez saat 5'te çalışmasını istiyorum" veya bizim durumumuzda olduğu gibi "B işini istiyorum dakikada bir çalıştırmak için " ). Toplu işleme mantığını tetiklemek için cronjobs kullanıyorsanız, gerçekten bir göz atmalısınız SQS. Aktif-pasif ikilem yoktur, yani kuyruğunuzu işlemek için tek bir sunucu veya bütün bir iş gücü kullanabilirsiniz. İş SWFgücünüzü ölçeklendirmeyi de öneririm (ancak auto scalingçoğu durumda hile de yapabilir).

Başka bir üçüncü tarafa bağlı olmak, kaçınmak istediğimiz bir şeydi.

12 Şubat / 16'da Amazon , AWS Lambda'yı kullanarak SSH işlerini zamanlama hakkında blog yazdı . Sanırım bu soruya cevap veriyor.

Zaten bir Redis hizmetiniz varsa, bu iyi bir çözüm gibi görünüyor:

https://github.com/kvz/cronlock

Daha fazlasını okuyun: http://kvz.io/blog/2012/12/31/lock-your-cronjobs/

"Amazon" yolu dağıtılacak, yani hacimli cronlar birçok küçük işe bölünmeli ve doğru makinelere teslim edilmelidir.

Tür FIFO olarak ayarlanmış SQS kuyruğunu kullanarak, her işin yalnızca bir makine tarafından yürütülmesini sağlamak için birbirine yapıştırın. Ayrıca, bir makine geri dönene kadar kuyruklar arabelleğe alınacağı için hatayı tolere eder.

FIFO Tam Olarak Bir Kez İşleniyor : Bir mesaj bir kez teslim edilir ve bir tüketici onu işleyip silene kadar kullanılabilir durumda kalır. Kopyalar kuyruğa dahil edilmez.

Ayrıca, bu işlemleri gerçekten 'toplu hale getirmeniz' gerekip gerekmediğini de düşünün. Bir gecelik güncellemeler beklenenden önemli ölçüde fazlaysa ne olur? Dinamik kaynak kullanımında bile, işlemleriniz yeterli makinenin dönmesini beklerken gecikebilir. Bunun yerine, verilerinizi SDB'de saklayın, makinelere SQS aracılığıyla güncellemeleri bildirin ve RSS beslemenizi anında oluşturun (önbelleğe alarak).

Toplu işler, kaynakların işlenmesinin sınırlı olduğu ve "canlı" hizmetlerin öncelik kazandığı bir zamandır. Bulutta durum böyle değil.

Neden kendininkini inşa ettin? Neden Quartz gibi bir şey kullanmıyorsunuz (Kümelenmiş Zamanlama ile). Belgelere bakın.

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

Yaptığımız şey, ELB'nin arkasındaki web uygulama kümemizin parçası olan belirli bir sunucumuz var, ayrıca belirli bir DNS adı atadı, böylece işleri belirli bir sunucuda çalıştırabiliriz. Bu aynı zamanda, eğer bu iş sunucunun yavaşlamasına neden olursa ELB'nin onu kümeden kaldırması ve iş bittikten ve tekrar sağlıklı hale geldikten sonra onu geri getirmesi avantajına da sahiptir.

Bir şampiyon gibi çalışır.

Cron ifadenizin Amazon yöntemiyle çalıştığını doğrulamanın bir yolu, onu events komutu aracılığıyla çalıştırmaktır. Örneğin:

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

Zamanlama ifadeniz geçersizse, bu başarısız olur.

Daha fazla kaynak: https://docs.aws.amazon.com/cli/latest/reference/events/put-rule.html

AWS dışı bir hizmeti kullanmak istiyorsanız Microsoft Azure'a göz atabilirsiniz . Azure harika bir iş planlayıcı sunar .

Hiç kimse CloudWatch Event'den bahsetmediğinden , cron işleri yapmanın AWS yolu olduğunu söyleyebilirim. Lambda işlevi, ECS görevi gibi birçok eylemi çalıştırabilir.