- Tavuk fast-food zinciri Chick-Fil-A, her restoranda bir edge Kubernetes kümesi işletiyor
- Her şubedeki tüm cihazlar (fritözler, ızgaralar vb.) sürekli IoT telemetri bilgisi sağlıyor ve on binlerce cihaz bağlı durumda
- Bu bilgilerden gerçek zamanlı talep tahmini yapılıyor ve analiz süreçlerinin çalıştırılması için buluta gönderiliyor
- İç pişirme süreçlerinden mobil ödeme terminallerine (drive-thru) kadar her şey entegre
Restaurant Edge Compute platformu
- Günümüzde birçok sistem bulut/veri merkezi için tasarlanmış durumda
- Kaynakların kısıtlı olduğu, internet bağlantısının zayıf olduğu ortamlar ve binlerce Kubernetes kümesi için uygun değil
- Bu yüzden kendileri oluşturmaya karar verdiler. Bir MVP yapıp gerçek kurulumlar gerçekleştirerek öğrenmeye başladılar
Donanım
- Genel tüketici tipi Intel NUC kullanılmasına karar verildi
- NUC nesilleri gruplanarak 3 düğümlü kümeler oluşturuldu; böylece güvenilirlik, kapasite ve HA yapılandırmalarına esnek şekilde yanıt verilebildi
İşletim sistemi
- İlk sürümde temel işletim sistemi olarak Ubuntu kullanıldı
- Tasarım hedefi, NUC'leri doğrudan restoranlara dropshipping ile göndermekti; restoran bazında manuel yapılandırma gerekmemeliydi
- Yani tüm provizyon işlemleri dinamik olarak anında çalışıyor
- Elbette bazı güvenlik özellikleriyle diğer cihazların kümeye katılması veya iç bulut servislerine erişmesi engelleniyor
Edge Commander
- Küme önyükleme ve yönetim süreci
- Her edge kümesi düğümü aynı imajla kuruluyor
- Birden fazla disk bölümü ve OverlayFS kullanan bazı hileler de içeriyor
- Belirli verileri uzun süre saklama veya düğümün diğer bölümlerini uzaktan silme (
Wipe) gibi özellikler
Kubernetes
- K3s uygulamasını kullanmaya karar verdiler
- Kubernetes spesifikasyonu ile uyumlu ancak bazı özellikleri çıkarılmış durumda. Büyük ölçekte yapılandırmak ve desteklemek çok daha kolay
- Bulut kullanılmadığı için Kubernetes'in tüm özelliklerine ihtiyaç duymuyorlar
- Bundan çok memnunlar ve ileride değiştirmeyi düşünmüyorlar
GitOps
- İlk platform sürümü oluşturulurken, kaynakları kısıtlı edge ortamında çalışabilecek bir GitOps ajan çözümü yoktu
Vessel adını verdikleri kendi ajanlarını geliştirdiler- Git deposunu (her mağaza için benzersiz bir depo) poll ederek küme değişikliklerini işliyor
- Buluttaki Kubernetes kümesinde açık kaynak bir GitLab instance'ı barındırıyorlar
- Kendi Git sunucularını işletmenin yükünü istemeseler de, maliyet açısından verimli bir barındırma çözümü lisans modeli bulamadılar
Deployments
- GitOps için her şube kendi Git deposunu tanımlıyor (Atlas adını veriyorlar)
- Her restorana yeni dağıtım, Atlas'ın master branch'ine yeni yapılandırmanın merge edilmesiyle mümkün oluyor
- Bu yaklaşım kurumsal yönetim açısından bazı trade-off'lar içerse de, dağıtım durumu yönetimini ve denetimi çok basitleştirdi
Zincir genelinde dağıtımı desteklemek
- En büyük zorluk, MVP'yi çok küçük bir ekibin sürdürebileceği, aynı zamanda ölçeklenebilir ve desteklenebilir bir platforma dönüştürmekti
API First stratejisi
- İş açısından ilk öncelik, tüm manuel süreçleri ve doğrulama adımlarını Restful API ile sarmalamaktı
- Her adım için kapsamlı bir API paketi oluşturduktan sonra, bunun üzerine bir orkestrasyon katmanı kurarak manuel süreçleri otomatikleştirmeye başladılar
- Kapsamlı ve iyi belgelenmiş bir PostMan projesi oluşturarak, yeni API'leri hızlıca kullanabilip destek ekipleri için Web UI geliştirmeyi erteleyebildiler
- OAuth kullanarak API paketine ayrıntılı, adım bazlı erişim sağladılar. Belirli işlevleri kolayca kilitleyebiliyor ya da müşterilere müdahalesiz durum ve raporlama uç noktaları açabiliyorlardı
Özel rollout ekibi
- Kısa sürede bu kadar çok cihazı tüm zincire nasıl dağıtabildiler?
- Çekirdek geliştirme ekibi çok küçüktü; platform desteği, geliştirme ve zincir genelindeki rollout'u aynı anda desteklemek zordu
- Tüm rollout öncesinde 3 NUC önceden gönderilip kurulmuştu; geriye yalnızca yapılandırma ve doğrulama adımları kalmıştı
- API paketi çalışır durumda olduğu için, platform yayını/durum izleme/basit destek sorunlarını çözmekten sorumlu bir "yarı teknik destek ekibi" hızlıca oluşturuldu
- Pair-Support, playbook'lar ve dokümantasyon geri bildirim döngüsü kullanılarak rollout ekibi hızla güçlendirildi
- Birkaç hafta içinde ekip kendi kendine yeterli hale geldi ve zincir genelindeki rollout tamamlandı
- Sonrasında, yeni özellikler eklenip ölçek büyürken platforma güçlü destek verebilecek organize bir yapı kuruldu
- Amaç, operasyonel kısımları otomatikleştirmek ve kalan destek işlerini destek zincirinde mümkün olduğunca üst kademeye taşımaktı
- Bu, First Tier Support ile Support DevOps ekipleri arasındaki geri bildirim döngüsüyle sağlandı
- Tüm sorunlar ilk olarak birinci seviye üzerinden başlıyor
- Çözülemeyen ya da yeni ve karmaşık sorunlar Support DevOps ekibine aktarılıyor
- İki ekip sorunu çözmek için birlikte çalışıyor ve First Tier ekibi, benzer bir sorun tekrar yaşandığında doğrudan müdahale edebilmek için dokümantasyonu ve playbook'ları güncelliyor
- Haftalık destek retrospektifleriyle DevOps ekibi backlog'una iyileştirme ve otomatik geliştirme fırsatları ekleniyor
- Ayrıca Support DevOps ekibi, yeni araçlar veya destek iyileştirmeleri gibi konularda öncelik belirlemek için geliştirme ekibinin backlog'unu da etkiliyor
İzleme ve otomatik düzeltme
- 2500'den fazla K3 kümesi var
- İzleme süreci geliştirilerek kümedeki tüm sorunların önceden tespit edilip giderilmesi gerekiyordu. Bunun için çok yönlü bir yaklaşım geliştirildi
Synthetic Client
- Temel platform işlevlerini test etmek ve sorunları (servis sorunları, veri gecikmesi vb.) analiz etmek için küme içinde container olarak çalışan bir Synthetic Client geliştirildi
- Bir sorun bulunduğunda istemci, API üzerinden bulut kontrol düzlemine raporluyor. Destek ekibine bildirim gidiyor ve otomatik remediation süreci başlıyor
Node Heartbeats
- Kubernetes kümeleri self-healing özelliklerine sahip olduğu için, bir düğüm arızalansa bile iş yükü aktif düğümler arasında otomatik olarak yeniden dengeleniyor
- Düğüm arızalarını algılamak için kümedeki her düğüme basit bir
Heartbeat Pod dağıtıldı
- Bu Pod düzenli olarak buluttaki API uç noktasına durum bildiriyor
Auto Remediation
- Haftalık destek retrospektifleri sayesinde hata, doğrulama ve düzeltme adımları arasında tekrar eden örüntüler keşfedildi
- Tüm destek araçları API tabanlı olduğu için, bu API'ler üzerinde orkestrasyon akışları kurabildiler ve yaygın sorunlar için otomatik düzeltme (Auto Remediation) sağlayabildiler
Yeni yetenekler
- Altyapıyı geliştirmeye devam ederken, geliştirme ekibi self-service ve destek kolaylığını artıracak yeni platform özellikleri geliştirmeyi sürdürdü
Deployment Orchestration
- GitOps modelleri basit
- Başta manuel değişikliklerle başladılar, ancak kısa süre sonra küme değişikliklerini ve birden fazla restorana dağıtımı yönetebilen
Fleet adlı bir araç oluşturdular
- Platform büyüdükçe, tüm zincire dağıtım yapmanın ve dağıtım başarısızlıkları ile başarılarını doğrulamanın bir yoluna ihtiyaç duydular
- İkinci iterasyonda yeni bir Deployment Orchestration API geliştirildi
- API ile birlikte her kümeye bir geri bildirim ajanı dağıtılarak, dağıtım ve durum bilgilerinin buluta raporlanması sağlandı
- Bu sayede zincir genelinde release yönetimi ve kendi kendine yönetilebilen canary deployment kalıpları oluşturabildiler
- Bu değişiklikle ekip dağıtımları daha ince ayarlı biçimde kontrol edip gözlemleyebildiği için dağıtım güvenilirliği arttı
Log Exfiltration
- Başlangıçta iç DevOps ekibinin restoranlardaki K3s kümelerine doğrudan erişip gerçek zamanlı durum almasına ve log aramasına izin veriliyordu
- Temel bir Log Exfiltration özelliği vardı ancak gecikme ve ağ sorunları nedeniyle kullanımı çok zordu
- Kümelere uzaktan erişimi en aza indirmek istedikleri için API uç noktaları eklediler
- Şu anda daha güçlü bir Log Exfiltration özelliği eklenmiş durumda
Vector adlı açık kaynak araç kullanılarak edge kümelerinden loglar toplanıp buluta iletiliyor
- Filtreleme, depolama ve iletme, logların otomatik döndürülmesi gibi özellikler sunuyor
- Bulut tarafında başka bir Vector servisi kurup tüm edge'lerden gelen logları toplayarak kurallar uyguluyor ve çeşitli araçlara yönlendiriyorlar (Data Dog, Grafana, CloudWatch vb.)
Metrikler ve dashboard'lar
- Prometheus Remote Write kullanılarak tüm restoranlardan metrik toplanıp buluttaki merkezi Grafana'ya iletilmesi sağlandı
- Her K3s kümesi; durum, düğümler ve temel servis iş yüklerini yakalıyor
- Özel iş metriklerini publish etme yeteneği de eklendi
Sonuç
- "Restaurant Compute Platform" ve destek süreçleri, küçük bir geliştirme ekibinin yüksek düzeyde kararlılık ve müşteri desteği sunabilmesine yetecek kadar olgunlaştı
Öğrenilenler
- Küçük bir ekibin iş açısından kritik bir MVP Edge Compute platformu oluşturabilmesi için güçlü mühendislik ve akıllı ödünleşimler gerekiyordu
- 2500'den fazla Kubernetes kümesini küçük bir ekiple işletmek çok zor, ancak API öncelikli otomasyon yaklaşımı büyük yardım sağladı
- Cloud-first bir dünyadan gelindiğinde en büyük zorluk, edge'in kısıtları olmasıydı (hesaplama kapasitesi, sınırlı ağ bant genişliği, uzaktan erişim)
- Kısıtları anlamaya zaman ayırmak ve bu kısıtları ortadan kaldırmanın mı (zaman ve maliyet açısından pahalı), yoksa yönetmenin mi daha doğru olduğunu değerlendirmek faydalı oluyor
5 yorum
Gerçekten harika :)
Gerçekten en alt katmandan itibaren inşa etmişler. Uygulama sürecinde de çok ilham veriyor.
Daha sonra bir kez daha sakin kafayla baştan sona okumam gerekecek.
Chick-fil-A tavuk burgeri çok lezzetli, değil mi? :)
Aynı konuda 2018'de de bir paylaşım yapılmıştı; o zaman biraz deneysel bir havası vardı ama belli ki bugüne kadar sürdürmüşler. Yazıda da bu süreçte biriken deneyimin izleri görülüyor.
https://medium.com/@cfatechblog/…
Henüz Türkiye pazarına girmemiş bir zincir olduğu için ülkede bilinirliği neredeyse yok, ancak Piper Sandler’ın yılda iki kez yayımladığı ABD’li gençlerin şirket tercihleri araştırmasında restoran tercihinde her zaman 1. sırada yer alan, gençler arasında da oldukça popüler bir restoran.