Cognizant OrderServ çok kiracılı ECS ile %64 tasarruf etti

Bir yemek siparişi platformunda marka sayısı ikiye katlandığında, her markaya ayrılmış kümeler en büyük maliyet kalemine dönüşüyor. Trafik patlaması sırasında başarısız olan her istek de kaybedilmiş bir satış demek. AWS Architecture Blog’daki bu vaka çalışması, Cognizant ile AWS Professional Services’in bu sorunu nasıl çözdüğünü anlatıyor.

Cognizant’ın OrderServ hizmeti, yemek sektörü için çok kanallı bir sipariş çözümü. Farklı cihazlardan sipariş almayı destekliyor; satış noktası (POS), mutfak ekranı, ödeme, sadakat programı ve diğer kurumsal sistemlerle entegre çalışıyor.

Cognizant 2022’de, OrderServ 2.0’ı monolitten AWS Fargate üzerindeki mikroservislere taşıyarak klasik barındırma mimarisine göre %30 tasarruf ettiğini anlatmıştı. O günden bu yana hizmet, tek bir hızlı servis restoranı (QSR) markasından farklı pazarlarda birden fazla markaya hizmet veren bir platforma dönüştü. Her marka 21 mikroservisli kendi Amazon ECS kümesinde çalışıyordu. Bu yapı sıkı bir izolasyon sağlıyordu ama her yeni markayla maliyet doğrusal artıyordu ve ölçeklenme hızı, dakikalar içinde 5–10 kat sıçrayan kampanya trafiğine yetişemiyordu.

Yazının konusu, OrderServ’in çok kiracılı (multi-tenant) bir SaaS hizmetine dönüştürülmesi. Sonuçlar: işlem maliyetinde %47–64 düşüş, ölçeklenme süresinin 5–7 dakikadan 30–60 saniyeye inmesi ve kimlik doğrulama maliyetinde %80 azalma.

Sorun: Ayrı kümeler marka sayısıyla ölçeklenmiyor

OrderServ 2.0 her marka için 21 mikroservisi ayrı Fargate kümelerinde çalıştırıyordu. Beş marka için bu şu anlama geliyordu:

• 105 ECS servisi (21 × 5), her biri yoğun olmayan saatlerde boşta kapasiteyle.
• Gözlemlenebilirlik, yapılandırma ve log yönlendirme için her markada tekrarlanan 315 sidecar container.
• Doğrusal maliyet artışı: Yeni bir marka eklemek tüm bir kümeyi kurmayı gerektiriyordu.
• 5 dakikalık ölçeklenme açığı: Büyük container imajları Fargate’te imaj çekme ve görev başlatma süresini uzatıyor, kampanya trafiğinde kapasite eklenmesini geciktiriyordu.

QSR dünyasında trafik patlaması sırasında başarısız olan her istek kayıp bir satış ve kullanıcı anında rakip uygulamaya geçebiliyor. Hizmetin öğle yoğunluğu, kampanyalar ve bayram dönemleri gibi öngörülemeyen trafik düzenlerini kaldırırken 10’dan fazla markaya uygun maliyetle hizmet vermesi gerekiyordu.

Çözüme genel bakış

Ekip bu sorunları dört mimari değişiklikle ele aldı:

• Kiracılık kütüphanesiyle paylaşımlı ECS kümesi: Markaya özel altyapının yerini uygulama düzeyinde izolasyon alıyor.
• Bottlerocket ile EC2 warm pool: Fargate soğuk başlatmalarının yerini bir dakikanın altında ölçeklenme alıyor.
• Çökme gözlemlenebilirliği hattı: Kayıpsız loglama ve servis başına ayda 10 dolara 90 günlük adli inceleme imkânı.
• Çok kiracılı kimlik doğrulama için passkey: Biyometrik giriş, sürekli SMS maliyetini düşürüyor.

1. Uygulama düzeyinde izolasyonlu paylaşımlı küme

OrderServ bir markadan beşe çıktıkça, her kiracı için 21 mikroservisi çoğaltmanın maliyeti sürdürülemez hâle geldi. Hedef, her markanın ihtiyaç duyduğu veri izolasyonu garantilerini koruyarak altyapıyı birleştirmekti. Ayrı küme modeli güçlü izolasyon sağlıyordu ama ölçek ekonomisi yoktu; yeni marka eklemek bir altyapı kurulumu değil, bir yapılandırma değişikliği olmalıydı.

Varsayılan olarak paylaşımlı küme seçildi; yüksek hacimli markalar gerektiğinde ayrı kümelere alınabiliyor. Beş ayrı ECS kümesinden (105 servis, 315 sidecar) 21 servisli tek bir paylaşımlı kümeye geçildi. Kiracılık kütüphanesi kiracı çözümleme, kaynak yönlendirme ve bağlam aktarımını üstleniyor; kiracıya özel veri depoları (Amazon DynamoDB, Amazon Aurora, Valkey) sıkı veri izolasyonunu koruyor.

Tüm veri depoları AWS KMS anahtarlarıyla şifreleniyor; servisler arası ve istemci-servis trafiği TLS ile korunuyor. DynamoDB tabloları varsayılan olarak şifreli. Aurora kümeleri ve Amazon EFS dosya sisteminde şifreleme oluşturma sırasında açılıyor; ElastiCache for Valkey kümesinde hem durağan hem aktarım hâlindeki şifreleme yapılandırılıyor.

Birincil izolasyon katmanı olarak kiracılık kütüphanesi

Çok kiracılı mimarilerin çoğu izolasyonu altyapı düzeyinde sağlar: ayrı hesaplar, ayrı IAM rolleri ya da ayrı işlem kaynakları. Burada farklı bir yol izlendi: kiracı izolasyonunun birincil uygulama noktası paylaşımlı bir .NET Core kütüphanesi. IAM ve kaynak politikaları ise kütüphanede bir hata olduğunda etki alanını sınırlayan ikinci savunma hattı.

Her istek, Amazon API Gateway authorizer’ın eklediği bir X-Tenant-Id başlığı taşıyor. Kiracılık kütüphanesi:

• Kiracı bağlamını her istekte, istek kapsamlı depolama (AsyncLocal<T>) ile çözümlüyor; statik ya da singleton durum asla kullanılmıyor.
• Tüm veri erişimini yönlendiriyor: DynamoDB tablo adları, Valkey anahtar önekleri, Aurora şema seçimi ve S3 yolları.
• Kiracı öneki olmadan kaynak kimliği oluşturmayı reddediyor; böylece kiracı bağlamı eksik olduğunda istek başka bir kiracının verisini okumak yerine güvenli şekilde başarısız oluyor (fail closed).
• Kiracı bağlamını servisler arası çağrılara ve asenkron mesajlara (SQS/SNS öznitelikleri) aktarıyor.
• Her log satırına ve dağıtık izlemeye kiracı kimliğini ekliyor.

Bu tasarım sayesinde aynı servis binary’si paylaşımlı kümede de ayrı kümede de aynı şekilde çalışıyor. İşlem modeli mimari bir kısıt değil, bir dağıtım kararı hâline geliyor.

Uygulama düzeyinde izolasyon, izolasyon sınırını koda taşıyor ve kodda hata olabilir. ECS görev rolü istek başına değil görev başına verildiği için, paylaşımlı kümedeki bir görev hizmet verdiği tüm markaları kapsayan izinlere sahip olmak zorunda. Bu kapsamı daraltmak için kütüphane çalışma anında kiracıya özel kimlik bilgileri alıyor: kiracı kimliğini session tag olarak verip sts:AssumeRole çağırıyor, rol politikaları da bu etikete başvurduğu için kimlik bilgileri yalnızca o kiracının DynamoDB tablolarına, S3 öneklerine ve Aurora şemasına erişebiliyor. ElastiCache for Valkey kendi katmanını ekliyor: kiracının anahtar kalıbıyla sınırlı, kiracıya özel RBAC kullanıcıları sayesinde önbellek motoru, kütüphanenin anahtarı doğru oluşturduğuna güvenmek yerine kiracılar arası erişimi kendisi reddediyor.

2. Bir dakikanın altında ölçeklenme: Bottlerocket ile EC2 warm pool

Tüm markalar tek kümeyi paylaşınca, herhangi bir markadaki trafik sıçraması diğerlerini de etkileyebilir hâle geldi. Ani yükleri dakikalar değil saniyeler içinde karşılayan bir ölçeklenme stratejisi gerekiyordu.

Fargate altyapı yönetimini ortadan kaldırıyor, ancak OrderServ’in öngörülemeyen talep artışlarında bir dakikadan kısa sürede ek kapasiteye ihtiyacı vardı. Yeni görevlerin sağlıklı duruma gelmesi 5–7 dakika sürüyordu. Bunun başlıca nedeni, Fargate’in uygulamayı başlatmadan önce büyük container imajını indirip açmak zorunda olmasıydı. Görev hazırlama, uygulama başlatma ve sağlık kontrolleri de gecikmeye ekleniyordu ama en büyük pay imaj indirmenindi. Bu sürede mevcut görevler doyuyor, gecikme artıyor ve bazı siparişler başarısız oluyordu.

Ekip, Bottlerocket (AWS’nin container’lar için geliştirdiği işletim sistemi) ve warm pool kullanan EC2 Auto Scaling gruplarına geçti:

• Warm pool sunucuları önceden hazırlanıp durduruluyor; yalnızca EBS depolaması için ödeme yapılıyor (sunucu başına ayda yaklaşık 3 dolar).
• ECS kapasiteye ihtiyaç duyduğunda Auto Scaling grubu, imajı önbellekte ve ECS agent’ı kayıtlı durdurulmuş bir sunucuyu 30–60 saniyede başlatıyor.
• Hedef kullanım %80’e ayarlanarak kapasite payı bırakılıyor; böylece ilk dalga anında karşılanıyor.
• Bottlerocket atomik otomatik güncellemeler sunarak EC2 yama yükünü ortadan kaldırıyor.

Tek bir ölçeklenme mekanizmasına güvenmek yerine, algılama ile tepki arasındaki boşlukları kapatmak için her biri belirli bir trafik düzenini hedefleyen beş tamamlayıcı katman kuruldu:

Maliyet ve performans etkisi

Fargate’ten EC2’ye geçiş, ölçeklenme performansının yanında Asya Pasifik (Mumbai, ap-south-1) bölgesinde 21 servisi çalıştırmanın öngörülen aylık maliyetini de düşürdü. Burada iki araç farklı işler görüyor: On-Demand Capacity Reservations, bir sıçrama warm pool’u devreye soktuğunda Availability Zone’da kapasite bulunmasını sağlıyor; indirim ise Compute Savings Plan’dan geliyor. Rezervasyonun süre taahhüdü yok ve filo değiştikçe yeniden boyutlandırılabiliyor ya da bırakılabiliyor. Aşağıdaki 1 ve 3 yıllık süreler yalnızca Savings Plan için geçerli.

Rezervasyon sabit filoyu karşılıyor; durdurulan warm pool sunucuları ise ayda yaklaşık 30 dolar EBS depolama maliyeti ekliyor. Ölçeklenme süresi 5–7 dakikadan 30–60 saniyeye iniyor.

3. Çökme gözlemlenebilirliği hattı

Üretimde container çöktüğünde destek ekibinin üç şeye ihtiyacı var: ne olduğu, kök nedeni ve container’ın çökme anındaki çalışma durumu. Önceki yapıda OrderServ container çıktısını awslogs sürücüsüyle CloudWatch Logs’a gönderiyordu. Bu normal uygulama çıktısını yakalıyordu ama kalıcı görev durma meta verisi, servisler arası istek ilişkilendirmesi ya da kalıcı çökme kalıntıları sağlamıyordu:

• Çökmede son log kayıtlarının kaybolma riski: Görev aniden sonlandığında, log sürücüsünün gönderim tamponundaki kayıtlar CloudWatch Logs’a ulaşmayabiliyor.
• Kısa ömürlü görev meta verisi: ECS, durmuş görev bilgisini API üzerinden yalnızca 1 saat tutuyor ve inceleme penceresi daralıyor.
• Servisler arası ilişkilendirme yok: Düz metin loglarda, başarısız bir isteği servisler arasında izlemek için gereken trace ID ve tutarlı görev, container, servis tanımlayıcıları yoktu.
• Kalıcı çökme kalıntısı yok: Fargate’in geçici görev depolaması görev durunca yerel crash dump’ları ve tanı dosyalarını da götürüyordu.

Yeni hatta uygulama container’ı, X-Ray trace ID’leri içeren yapılandırılmış JSON logları bir FireLens (Fluent Bit) sidecar’ına gönderiyor. Sidecar container sonlansa da ayakta kalıyor ve logları hem 30 gün saklamalı Infrequent Access sınıfındaki CloudWatch Logs’a hem de gzip ile bölümlenmiş, 365 gün saklamalı Amazon S3’e yönlendiriyor. Amazon EventBridge görev durma olaylarını tüm meta verisiyle yakalıyor, AWS Distro for OpenTelemetry (ADOT) collector X-Ray’e otomatik enstrümante edilmiş izler gönderiyor, EFS ise crash dump’ları Availability Zone’lar arasında kalıcı tutuyor. Hepsinin maliyeti servis başına ayda yaklaşık 10 dolar.

Kilit mimari tercih, FireLens’in sidecar olarak kullanılması. ECS uygulama container’ının stdout çıktısını container çalışma zamanı düzeyinde yönlendiriyor; uygulama container’ı bellek yetersizliği (OOM) nedeniyle öldürülse bile loglar Fluent Bit’te kalıyor.

Stack overflow ya da native kod hatası gibi uygulama loglarının yetmediği sert çökmelerde .NET Core çalışma zamanı, /tmp/dumps/<container-id> yolundaki Amazon EFS bağlantısına otomatik olarak bir mini dump yazıyor. EFS yazmaları anında kalıcı olduğu ve bağlantı container ölse de durduğu için, süreç durumu (thread çağrı yığınları, heap nesneleri, yüklü modüller) SIGKILL sonrasında da korunuyor. Bir Lambda fonksiyonu dump’ları VPC erişimi olmadan analiz için S3’e kopyalıyor. Maliyeti ayda yaklaşık 0,02 dolar.

EventBridge’den CloudWatch Logs’a giden kural, ECS görev durum değişikliği olayının tamamını 90 gün saklıyor; bunun için Lambda gerekmiyor. Her log satırı X-Ray trace ID’li yapılandırılmış JSON. Destek akışı basit: hatayı ara, trace ID’yi bul, X-Ray’i aç ve isteğin 21 servis boyunca izlediği yolu gör.

CloudWatch Logs Infrequent Access sınıfı ve FireLens’in çift çıktısı (CloudWatch + S3) sayesinde gözlemlenebilirlik maliyeti servis başına %62 düştü. Hattın tamamı servis başına ayda yaklaşık 10 dolar.

4. Çok kiracılı kimlik doğrulama için passkey

QSR mobil uygulamalarında girişin anında olması gerekiyor; her saniyelik sürtünme bir sipariş kaybı. Hizmet daha önce her girişte SMS ile tek kullanımlık şifreye (OTP) dayanıyordu ve milyonlarca aylık aktif kullanıcıda bu hem ciddi maliyet hem de kullanıcı sürtünmesi demekti. Ekip, Amazon Cognito’nun yerleşik desteğiyle passkey (WebAuthn) uyguladı:

• İlk kayıt: Telefon numarası ve OTP ile kimlik doğrulanıyor, ardından cihaz Secure Enclave’e bağlı bir passkey kaydediyor.
• Sonraki her giriş: Face ID ya da parmak izi; yaklaşık 2 saniyede tamamlanıyor ve SMS maliyeti yok.
• Yeni cihaz ya da eski profil: Operatörler telefon numaralarını yeniden atadığı için bir numaraya sahip olmak kimlik kanıtı değil, yalnızca bir iddia olarak ele alınıyor. Yeni cihazda passkey kaydı OTP doğrulamasını tekrarlıyor; son doğrulaması yeniden doğrulama penceresinden eski olan profiller de kayıtlı bir kimlik bilgisi kabul edilmeden önce yeniden doğrulanıyor.
• Marka başına izolasyon: Her markanın, işletim sistemi düzeyinde kriptografik olarak izole edilmiş ayrı bir Relying Party ID’ye sahip kendi Cognito User Pool’u var.

Yaklaşık 60 satırlık bir Post-Authentication Lambda fonksiyonu, DynamoDB’de marka/kiracı kimliği ile müşterinin telefon numarasının hash’iyle anahtarlanmış bir kimlik doğrulama profili tutuyor. Marka kimliği anahtarın parçası olduğu için aynı müşterinin iki markaya kaydı birbiriyle ilişkisiz iki kayıt oluşturuyor ve sistem marka bağlamı olmadan hiçbir kaydı bulamıyor. Profil yalnızca hangi cihazların ne zaman kaydedildiği ve en son ne zaman doğrulandığı gibi kimlik doğrulama durumunu tutuyor; sipariş geçmişi, sadakat bakiyesi ya da markaya özel başka veri içermiyor. Passkey kimlik bilgileri de aynı ilkeyle izole: her marka ayrı bir Relying Party ID kullandığı için bir marka için kaydedilen kimlik bilgisi başka bir markaya sunulamıyor ve bu sınırı cihaz uyguluyor. Cognito’nun kimlik doğrulama mantığına entegrasyon için yaklaşık 95 satır özel kod yeterli oldu.

Genel sonuçlar

5’ten fazla markaya hizmet veren bir hizmette toplam yıllık tasarruf, önceki altyapı maliyetinin %60’ını aşıyor; üstelik ölçeklenme hızı, operasyonel görünürlük ve kullanıcı deneyimi de aynı anda iyileşiyor.

Sonuç

OrderServ dört mimari değişiklikle tek kiracılı bir mikroservis hizmetinden çok kiracılı bir SaaS hizmetine dönüştü: kiracılık kütüphanesiyle paylaşımlı işlem kaynakları, bir dakikanın altında ölçeklenme için EC2 warm pool, çökme gözlemlenebilirliği hattı ve sürtünmesiz giriş için passkey. Mimari, kiracı doğrulaması, kapasite payı, kiracı başına kısıtlama ve yüksek hacimli markalar için ayrı küme seçeneğiyle başlıca hata senaryolarını karşılıyor. Bunun bedeli de var: uygulama düzeyinde izolasyonun getirdiği sorumluluk, EC2 kapasite yönetimi ve Compute Savings Plan taahhütleri.

Yazarların ana çıkarımı şu: çok kiracılılık her kiracı için altyapı izolasyonu gerektirmiyor. Sıkı kaynak yönlendirme kurallarına sahip iyi tasarlanmış bir kiracılık kütüphanesi, işlem kaynaklarını paylaşırken uygulama düzeyinde izolasyon sağlıyor ve izolasyon modelini mimari bir kısıt olmaktan çıkarıp dağıtım kararına dönüştürüyor. Amazon ECS üzerinde çok markalı ya da çok kiracılı bir hizmet işletiyor ve maliyet ölçeklenmesi ya da trafik patlamalarıyla benzer sorunlar yaşıyorsanız önerilen adımlar:

• İzolasyon gereksinimlerinizin gerçekten kiracı başına altyapı gerektirip gerektirmediğini, yoksa kiracıya özel veri depolarıyla uygulama düzeyinde izolasyonun yeterli olup olmadığını değerlendirin.
• Öngörülemeyen sıçramaları olan iş yüklerinde, Fargate’te fazla kapasite tutmanın toplam maliyetini Compute Savings Plan’lı EC2 warm pool ile karşılaştırın.
• Container çökmesinin mümkün olduğu her ortamda log iletimi için FireLens sidecar kullanın.

Vakanın en öğretici yanı, rakamlardan çok izolasyonun nerede yapıldığı. Kiracı ayrımını koda taşımak riskli görünebilir, ama burada kütüphane tek başına bırakılmamış: session tag’li AssumeRole ile daraltılmış kimlik bilgileri ve Valkey RBAC ikinci bir kilit görevi görüyor. Maliyet tarafında %64’ün 3 yıllık Savings Plan taahhüdüyle ve Mumbai bölgesi fiyatlarıyla hesaplandığını, taahhütsüz senaryoda farkın daha küçük olacağını hatırlatmak gerekiyor. Rakamların tamamı AWS ve Cognizant’ın kendi ölçümleri.

Kaynak: https://aws.amazon.com/tr/blogs/architecture/how-orderserv-achieved-up-to-64-cost-savings-with-multi-tenant-ecs/