Shipyard: Slack’in Yeni Nesil EC2 Platformunu Nasıl Kurduğu

• Slack, uzun süre çalışan EC2’leri sürekli düzeltmeye dayalı eski yaklaşımdan değişmez AMI tabanlı ikame dağıtımına geçerek, konteynerlere taşınması zor iş yüklerine de modern bir dağıtım modeli uyguladı
• Ortak temel imaj olan slack-zero üzerine servise özel imajlar katmanlanıyor; ağır yapılandırma imaj baking aşamasında işleniyor, ortama özel sırlar ve metaveri ise yalnızca önyükleme sırasında uygulanıyor
• Dağıtım orkestratörü Gondola, AMI ile sürümlenmiş Chef artefaktını tek bir dağıtım birimi olarak yönetiyor; metrik tabanlı kademeli dağıtım, durdurma ve otomatik geri alma yapıyor
• Peekaboo, EC2 envanterinin tamamını neredeyse gerçek zamanlı sağlıyor; The Reaper ise kirlenmiş veya ömrünü doldurmuş instance’ları hız sınırı ve duraklatma mekanizmaları altında değiştiriyor
• Kısa ömürlü servislerde etkili olsa da veri düğümleri, GitHub Enterprise ve Atlassian JIRA gibi hızla değiştirilemeyen uzun ömürlü instance’lar için ayrı bir yama yöntemi ve dağıtım yürütücüsü gerekiyor

---

Sürekli değiştirilen EC2 modelinin sınırları

• Slack, eski tekil Chef stack’ini dayanıklı çoklu stack yapısına dönüştürdü; sürümlenmiş cookbook dağıtımı ve güvenli yükseltme süreçleri getirerek on binlerce EC2 instance’ı için güvenilirliği ve operasyonel kontrolü artırdı
  • İlgili süreç Advancing Our Chef Infrastructure içinde görülebilir
• Ardından bölünmüş üretim ortamları, sinyal tabanlı Chef çalıştırma ve iyileştirilmiş rollout yöntemleri getirerek ekiplerin cookbook’ları yeniden yazmadan arızaların etki alanını büyük ölçüde azaltmasını sağladı
  • Safety Without Disruption aşamasında, eski platform kararlı tutulurken gelecekteki mimariyi planlayacak alan kazanıldı
• Ancak uzun ömürlü instance’ları sürekli güncelleme modeli, servis bazlı dağıtımı zorlaştırıyor, altyapı drift’ini kaçınılmaz kılıyor ve birden fazla katmandaki değişiklikleri koordine ettikçe karmaşıklaşıyordu
• Konteynerler bazı iş yüklerinin sorunlarını çözse de tüm sistemler kolayca taşınamadığı için değişmezlik, kademeli dağıtım ve otomatik güvenlik mekanizmalarını doğrudan EC2’ye uygulayacak bir platform gerekiyordu

Shipyard’ın sunduğu EC2 işletim modeli

• Shipyard, altyapıyı sürekli değiştirilecek instance’lar olarak değil, dağıtılabilir artefaktlar olarak ele alan Slack’in yeni nesil EC2 platformudur
• Servis bazlı dağıtım kabiliyetini build ve orkestrasyon sistemleriyle birleştirerek, uygulama dağıtım platformlarıyla aynı düzeyde güvenlik ve öngörülebilirliği EC2 güncellemelerine uygular

• Birden fazla mimari ve işletim sistemi desteği

  • AMD64 ve ARM tabanlı Graviton dahil birden fazla CPU mimarisini destekler; Ubuntu, RHEL ve Amazon Linux kullanılabilir
  • Ekipler, ayrı bir platform uygulaması gerekmeksizin maliyet, performans ve uyumluluğa göre instance ve işletim sistemi seçebilir
  • Özellikle konteynerlere taşınması zor altyapı bileşenleri, Kubernetes worker node’ları ve egress ağ stack’i için uygundur

• Metrik tabanlı güvenli dağıtım

  • Her servis Gondola ile entegre olur ve metrik tabanlı otomatik güvenlik kontrolleri içeren kademeli rollout’lar yürütür
  • Servis sağlık sinyallerine göre dağıtım otomatik olarak durdurulabilir veya önceki sağlıklı sürüme otomatik geri alma yapılabilir

• Hızlı ve öngörülebilir provisioning

  • Konteynerlere benzer katmanlı imaj yapısı kullanılarak ortak golden base imaj üzerine servise özel imajlar oluşturulur
  • Çalışma zamanında yapılacak işler azaltıldığı için instance’lar birden fazla bölgede hızlı ve tutarlı biçimde ayağa kalkar

• Basitleştirilmiş yapılandırma yönetimi

  • Geçmişte zamanlanmış Chef işleri, yapılandırmayı periyodik olarak kontrol edip yeniden uygulayarak manuel veya beklenmeyen değişiklikleri istenen duruma geri döndürüyordu
  • Shipyard’da yapılandırma yalnızca imaj baking ve ilk provisioning gibi net yaşam döngüsü aşamalarında uygulanır
  • Yapılandırma yönetimi araçları, tüm sistemi sürekli değiştirmekten çok servisleri dağıtmak için kullanılır
  • Böylece arka plan yükü ve istenmeyen üzerine yazmalar azalır; instance’lar zaman içinde sürekli değişmediği için davranışlarını anlamak kolaylaşır

• Sınırlı ömre sahip instance’lar

  • Her instance’a sınırlı bir ömür verilir ve düzenli olarak otomatik değiştirilir
  • Potansiyel güvenlik açıklarının sorun çıkarabileceği süre azaltılır ve ekipler çalışan instance’ları değiştirmek yerine yenileriyle ikame etmeye yönlendirilir

Peekaboo envanteri ve tüm filoda görünürlük

• Peekaboo, Chef Server yerine bulut olayları ve instance metaverilerini kullanarak EC2 filosunun durumunu neredeyse gerçek zamanlı gösteren bir envanter sistemidir
• Shipyard dışında dağıtılmış instance’ları da izleyerek tüm filonun tek yerden görülmesini sağlar
• AWS EventBridge, OpenSearch ve Lambda ile inşa edilmiştir; şu arayüzleri sunar
  • Filo keşfi için UI
  • Sistem entegrasyonu için API
  • Hızlı komut satırı kontrolleri için CLI
• EC2 bilgisini merkezileştirerek ortam genelinde telemetri ve yönetim noktalarını tekilleştirir

slack-zero golden base imajı

• slack-zero, Compute Platform Team tarafından oluşturulan ve güvenlik ile izleme ekipleriyle birlikte yönetilen ortak makine imajıdır
• Tüm servislerin miras aldığı standartlaştırılmış ve güvenilir bir temeldir; servis ekipleri kendi çalışma zamanı ortamlarını bunun üzerinde kurar
• İmaj şu unsurları içerir
  • İşletim sistemi baseline’ı ve güvenlik sıkılaştırma ayarları
  • Ağ ve servis keşfi yapılandırması
  • İzleme ve güvenlik ajanları
  • Ortak araçlar ve temel sistem yapılandırması
• Temel imaj değişmez ve geçici bir hedef olarak ele alınır
  • Güvenlik yamaları, izleme güncellemeleri veya ağ iyileştirmeleri gerektiğinde yeni bir slack-zero imajı oluşturulur
  • Alt servis imajları, düzeltmeleri miras almak için yeni temel üzerinde yeniden build edilir

• AWS Image Builder’ın seçilme nedeni

  • slack-zero, önceki Packer yerine AWS Image Builder ile oluşturulur
  • Yaşam döngüsü politikaları eski AMI’leri otomatik temizleyerek depolama maliyetlerini azaltır
  • Yeni imaj oluşturulduğunda hesap bazlı en güncel AMI’ye işaret eden AWS Systems Manager (SSM) parametresi güncellenir; servis pipeline’ları bunu okuyarak en yeni temeli kullanır
  • İmaj baking başarılı olduğunda EventBridge ve Lambda, servis sahibi hesaplarındaki alt pipeline’ları otomatik başlatır
  • AMI yayımlanmadan önce geçici instance’larda doğrulama testleri çalıştırılarak üretim rollout riski azaltılır

Servis imajlarının baking ve provisioning süreci

• Her servis ekibi slack-zero’yu temel alarak kendi AMI’sini oluşturur; ortak platform bileşenlerini miras alırken çalışma zamanı ortamını kontrol eder
• Servis imajı pipeline’ı şu öğeleri tanımlar
  • Kurulacak yazılım
  • Servisin nasıl yapılandırılacağı
  • İlgili servisin instance başlatma prosedürü
• Yapılandırmanın çoğu imaja dahil edilerek çalışma hızı ve tutarlılık artırılır, yapılandırma drift’i en aza indirilir

• İki aşamalı rol ayrımı

  • Baking aşamasında, paketler ve ortamlar arasında ortak olan yapılandırma kurulur; böylece instance çalışmadan önce büyük ölçüde hazır ve sağlıklı duruma gelir
  • Provisioning aşamasında, önyükleme sırasında yalnızca sırlar, bölgeye özel yapılandırma ve dağıtım metaverisi gibi ortama bağımlı ayarlar uygulanır
  • Genellikle yalnızca yapılandırma dosyası yerleştirme, sırları getirme ve servisi başlatma yapılır
  • Paket kurulumu gibi ağır işler baking’e taşınarak instance’ların dakikalar yerine saniyeler içinde ayağa kalkması sağlanır
  • Hızlı başlangıç ölçekleme olayları, sıralı dağıtımlar ve otomatik instance ikamesi için önemlidir; minimal provisioning çalışma zamanı uyarlaması sırasında oluşabilecek drift’i bastırır

AMI ikamesi odaklı filo güncellemeleri

• Değişiklikler yeni bir AMI oluşturulduktan sonra dağıtım pipeline’ı ile rollout edilir; mevcut instance’lar yamalanmadan filo kontrollü ikame ile güncellenir
• Auto Scaling Group (ASG), AWS Instance Refresh’i; Kubernetes worker filoları ise Karpenter’ı kullanır
• Özel dağıtım gereksinimleri olan servisler ayrı yürütücüler ekleyebilir; Gondola farklı desenleri tutarlı bir dağıtım deneyiminde birleştirir

• Acil düzeltme yolu

  • Acil durumlarda çalışan instance’lara sınırlı yapılandırma değişiklikleri uygulanabilir, ancak ardından bu instance’ların normal dağıtım pipeline’ı üzerinden değiştirilmesi gerekir
  • AWS Systems Manager’ın önceden tanımlı dokümanlarıyla seçilen Chef recipe çalıştırılarak acil düzeltme uygulanır
  • Sistem kararlı hâle geldiğinde instance’lar döndürülerek amaçlanan değişmez duruma geri dönülür

Gondola’nın kademeli dağıtımı

• Müşteri pipeline’ları, servis ve operasyonel gereksinimlere göre birden çok aşamadan oluşacak şekilde yapılandırılabilir
• Her Gondola aşaması ASG, Kubernetes cluster’ı veya EC2 instance grubu gibi tek bir dağıtım birimini temsil eder
• Egress Team, her Availability Zone’da canary ve production ASG’leri ayrı tutar ve güncellemelerin sırayla akacağı şekilde aşamaları yerleştirir
• Gondola her aşamayı güncellerken temel metrikleri izler; sorun tespit edilirse otomatik geri alma yaparak arızanın yayılmasını önler

• Dağıtım artefaktları ve yürütücüler

  • Gondola’nın oluşturduğu dağıtım paketi iki bölümden oluşur
    • Filoya dağıtılacak AMI
    • Git commit’iyle bağlantılı sürümlenmiş recipe’leri içeren Chef artefaktı
  • İki unsur tek bir dağıtım birimi olarak ele alınır; her aşama servisin tanımladığı yürütücü üzerinden rollout edilir
  • ASG dağıtımında yürütücü, launch template’i yeni AMI ve yapılandırmayla günceller
  • Chef kodu Amazon S3’e paketlenir
  • Yeni instance’ın yerleşik bootstrapper’ı doğru artefaktı alır ve ilgili recipe’leri çalıştırır
  • Yapılandırma metaverisi kullanılarak yalnızca ilgili role uygun ayarlar uygulanır
  • Kubernetes worker filolarında yürütücü, kullanılacak AMI’yi ve aynı yapılandırma metaverisini Karpenter’a iletir; node’lar da aynı şekilde bootstrap edilir
  • Özel dağıtımlar için yürütücü eklense bile AMI, sürümlenmiş yapılandırma artefaktı ve metaveri tabanlı bootstrap yaklaşımı korunur

Platform ekibi ile servis ekipleri arasında sorumluluk paylaşımı

• Compute, Security ve Monitoring ekipleri temel katmandaki global altyapı bileşenlerini, güvenlik yamalarını ve zorunlu ayarları yönetir
• Servis ekipleri bu temel üzerine kendi yazılımlarını ve servise özel ayarlarını ekleyen AMI’ler oluşturur
• Compute ekibi güvenlik yamaları, izleme ajanları ve ağ değişiklikleri dağıttığında servis ekipleri güncellenmiş temel imajı kendi AMI’lerine yansıtmalıdır
• Bu paylaşılan sorumluluk modeli, servise özel özerkliği korurken filonun tutarlılık, güvenlik ve güvenilirliğini hizalar

Tam değişmezlik değil, sırlar istisnası

• Shipyard instance’larının paketleri ve yapılandırması çoğunlukla baking sırasında sabitlenir, ancak sırlar bunun istisnasıdır
• Her instance’daki Consul Template servisi, filoyu değiştirmeden Vault’taki yeni sırları dağıtır
• Kimlik bilgileri veya sertifikalar dinamik olarak yenilenebildiği için Shipyard, çekirdek sistemler ve servis katmanının sabit olduğu yarı değişmez altyapıdır
• Kararlılık ve öngörülebilirlik korunurken kritik çalışma zamanı sırları gerektiğinde güncellenebilir

The Reaper’ın ikame politikası

• The Reaper, ikame hedeflerini iki tür girdiye göre belirler
  • Güvenlik araçları veya AWS EC2 olayları gibi harici sistemlerin, instance’ın istenen durumun dışına çıktığını bildiren kirlenme sinyalleri
  • İzin verilen azami ömürden daha uzun süre çalışıp çalışmadığını kontrol eden periyodik taramalar
• Koşullardan herhangi biri karşılandığında, servis politikasına göre instance ikamesi planlanır
• Manuel uzaktan erişime acil durumlar için izin verilir; ancak production seviyesindeki node’lara doğrudan bağlanmak bir sinyal üretir ve ilgili instance gelecekte ikame hedefi olarak işaretlenir
• Peekaboo ile entegre olarak tüm filodaki instance yaşını izler; azami ömre ulaşan node’lar aynı sağlıklı kapatma ve ikame prosedürünü izler
• Gelecekte yazılım güncellemeleri veya yapılandırma drift’i gibi yalnızca anlamlı değişikliklerin ikame tetiklemesi; salt okunur veya düşük riskli işlemlerin gereksiz döngüler oluşturmaması için bağlam farkındalığı eklenmesi planlanıyor

• İkame hızı ve acil durum kontrolü

  • Yerleşik hız sınırları, ani kapasite etkilerini önlemek için aynı anda değiştirilebilecek instance sayısını servis, bölge ve Availability Zone bazında belirler
  • S3’e kontrol nesnesi yerleştiren global duraklatma mekanizması “big red button” ile arıza veya yüksek riskli dönemlerde tüm Reaper faaliyetleri durdurulabilir
  • CLI üzerinden hız sınırı yönetimi, yapılandırma kontrolü ve global duraklatmayı etkinleştirme/devre dışı bırakma yapılır
  • Derinlemesine inceleme gerektiren break-glass durumlarında kısa ömürlü SSH sertifikaları gibi kontrollü erişim yöntemleri kullanılabilir

Ship Quick ile gerçek altyapı testi

• Ship Quick, platform ekipleri ve servis sahiplerinin pull request’leri birleştirmeden önce gerçek altyapıda gerçekçi baking ve provisioning testleri çalıştırmasını sağlayan geliştirici iş akışıdır
• Geliştirici, cookbook deposunda CLI komutu çalıştırır ve test senaryolarını YAML dosyasıyla tanımlar
• Ship Quick şu sırayla işler
  • cookbook’u paketleyip S3’e yükler
  • İş akışı mesajını kuyruğa gönderir
  • Longshoremen tarafından yönetilen worker instance işi alır
  • Worker, Auto Scaling Group’tan ayrılarak Chef iş akışını çalıştırır
  • Logları CLI’ye stream eder ve ardından sonlanır; geliştirici isterse hata ayıklama için tutmayı seçebilir

• Temel katmana göre worker filoları

  • Bootstrap yapısı nedeniyle iki ayrı worker filosu işletilir
  • Varsayılan Ubuntu filosu, slack-zero kendi üzerinde build edilemediği için temiz bir Ubuntu AMI’den temel imajı bake eder ve test eder
  • slack-zero filosu, önceden bake edilmiş slack-zero’ya dayanan servis ekibi cookbook’larını test eder
  • Provisioning, production ile aynı temel üzerinde doğrulanır
  • Güncel production ortamını yansıtmak için en yeni imajlarla sürekli güncellenir
  • İki filo da talebe göre otomatik ölçeklenir
  • Kendi AWS hesabında imaj oluşturan ekipler, özel worker filoları yapılandırıp izolasyonu korumak için Ship Quick işlerini bu filoya gönderebilir

Uzun ömürlü iş yüklerine genişleme

• Shipyard şu anda kısa ömürlü servislerde etkili çalışıyor ve eski EC2 platformundaki ekipleri onboard etmeyi sürdürüyor
• Sıradaki konu, hızla döndürülemeyen uzun ömürlü instance’lardır
  • Slack veri düğümleri
  • GitHub Enterprise gibi singleton servisler
  • Atlassian JIRA gibi üçüncü taraf iş teknolojisi instance’ları
• Bu iş yükleri için güvenli yama ve güncelleme yöntemleri ile The Reaper’ın doğru işleyebileceği yaşam döngüsü politikaları gerekiyor
• Servis ekipleriyle birlikte Gondola için uzun ömürlü iş yükü yürütücüsü geliştiriliyor; benimseme kapsamı büyüdükçe araçlar, geliştirici iş akışları ve dağıtım deneyimi geliştirilmeye devam edecek
• Gelecekte Shipyard API’si, imaj pipeline’ları, geliştirici iş akışları, envanter sistemi bileşenleri ve platformu genişletme sürecinde ortaya çıkan sorunlar ayrıca ele alınacak