Sunucusuz (Serverless) Mimari vs. Mikroservisler: Hangisini, Ne Zaman Seçmeli?

İndirim anında ise saniyeler içinde binlerce oturum, sepet ve ödeme beklenir. Katalog, stok rezervasyonu, sipariş, ödeme, bildirim ve ERP eşitlemesi aynı hızda ve aynı tutarlılıkta yaşamaz.

Ekibin önündeki sorular omurgayı belirler. Tüm mantık tek pakette, sanal makinede mi duracak? Her iş süreci ayrı bir servis olup Kubernetes üzerinde mi yaşayacak? Boşta sunucu ödememek için Lambda veya Azure Functions gibi olay güdümlü bir hatta mı gidilecek? Yoksa çekirdek iş konteynerde, yardımcı işler sunucusuzda mı kalacak?

İstek, DNS ve TLS el sıkışmasından sonra ağ geçidine varır. Vitrin katmanını Next.js ile kurmayı ayrı bir yazıda ele almıştım. Bu rehber kapının ardını seçer: gelen isteği hangi sunucu modeli işleyecek?

Monolitik mimari bitti mi?

Yeni bir paradigma çıkınca eskisi "bitti" ilan edilir. Monolit bu algının sık kurbanıdır.

Monolit, arayüz entegrasyonu, iş mantığı, veri erişimi ve arka plan işinin tek bir pakette derlenip dağıtılmasıdır. Tek bir binary, tek bir jar veya tek bir konteyner imajı.

MONOLİTİK UYGULAMA
  Ürün modülü | Sipariş modülü | Ödeme modülü
  Ortak veri erişim katmanı
        |
        v
  Tek veritabanı

Modüler monolit

Sorun tek parça olmak değildir. Sorun, zamanla sınırların silinip kodun spagettiye dönmesidir. Modüler monolit, iş alanlarını net sınırla ayırır. Modüller birbirine doğrudan yapışmaz. Arayüz veya bellek içi olay hattı ile konuşur.

Tek konteyner olarak ECS, Container Apps veya sanal makinede ölçeklenir. Veritabanı tek sunucuda durabilir. Şemalar modüle ayrılır.

MODÜLER MONOLİT
  Ürün modülü  <== dahili olay hattı ==>  Sipariş modülü
       |                                      |
       v                                      v
  Ürün şeması                            Sipariş şeması

İlk karşılaştırma

Küçük ve orta ekip için monolit iyi bir başlangıçtır. Ağ topolojisi, dağıtık log ve tutarlılık senkronu istemez. Geliştirici işi bitirir.

Mikroservis mimarisi nedir?

Mikroservis, büyük sistemi bağımsız dağıtılan, tek bir iş yeteneğine odaklanmış küçük servisler olarak kurmaktır.

Sınır, Domain-Driven Design'daki sınırlandırılmış bağlamdır. Her servisin kendi veri modeli, iş kuralı ve veritabanı vardır.

İstemci
   |
   v
API Gateway
   |        |        |
   v        v        v
 Ürün     Sipariş    Ödeme
   |        |        |
   v        v        v
 DB       DB        DB

E-ticarette ayrım kabaca şöyledir. Ürün servisi katalog ve kategoriyi tutar. Stok servisi miktar ve rezervasyonu tutar. Sipariş servisi sepeti dondurur ve durumu izler. Ödeme servisi geçit, 3D Secure ve faturayı konuşur. Müşteri servisi profil ve kimliği tutar. Bildirim servisi e-posta, SMS ve anlık iletileri yollar.

Ne kazandırır?

Sipariş servisindeki düzeltme, tüm sistemi yeniden dağıtmaz. Arama trafiği ödemenin 50 katıysa yalnız ürün servisi çoğalır. Öneri motoru Python, sipariş hattı .NET veya Go, bildirim Node olabilir. Ödeme geçidi çökerse katalog taranmaya devam eder.

Ne yükler?

Tek veritabanı transaction'ı biter. Sipariş, stok ve ödeme artık tek COMMIT ile kapanmaz. Yerine Saga ve nihai tutarlılık gelir. Bellek içi çağrının yerini ağ çağrısı alır. Derin zincir, toplam gecikmeyi yer. Bir istek on servisten geçiyorsa, hatanın hangi sorguda kırıldığı merkezi log, metrik ve dağıtık iz olmadan bulunmaz. OpenTelemetry bu yüzden ilk günden konur.

Sunucusuz mimari nedir?

Sunucusuz, sunucu sağlama, yama, kapasite ve ölçeği bulut sağlayıcısına bırakılan bir çalıştırma modelidir. Altta sunucu ve konteyner durur. Yaşam döngüsü geliştiricinin elinde değildir.

Üç terim karışır:

• FaaS: Mantık, bir olaya cevap veren kısa ve durumsuz fonksiyonlardır. Lambda, Azure Functions, Cloud Functions.
• BaaS: Kimlik, yönetilen veritabanı veya nesne depolama, API ile tüketilir.
• Sunucusuz konteyner: Standart imaj çalışır, küme yönetimi sizde değildir, istek yokken sıfıra inebilir. Fargate, Container Apps, Cloud Run.

BULUT SAĞLAYICI
  kapasite, işletim sistemi, ağ
        |
        +-- FaaS: Lambda / Functions
        +-- Sunucusuz konteyner: Container Apps / Cloud Run
        +-- BaaS: Cosmos, DynamoDB, nesne depolama

Boşta duran FaaS için işlemci faturası çıkmaz. Gece sipariş yoksa o fonksiyon için bellek süresi de yoktur. Fatura, çalışılan süre ve bellek kadardır. Yamayı sağlayıcı basar. Kovaya görsel düşünce veya kuyruğa mesaj düşünce fonksiyon tetiklenir. Bekleme döngüsü yazılmaz.

Sınırlar da nettir. Fonksiyon uzun süre uyursa yürütme ortamı geri alınır. Yeni istekte ortam, çalışma zamanı ve bağımlılık yeniden açılır. Bu soğuk başlangıçtır. P99'u bozar. Lambda'da üst süre 15 dakikadır. Azure Functions tüketim planında varsayılan tavan daha kısadır. Saatler süren toplu iş, saf FaaS'a sığmaz.

İlişkisel veritabanı sınırlı bağlantı kabul eder. Kampanyada aynı anda kalkan binlerce fonksiyon, binlerce TCP bağlantısı açarsa havuz biter. RDS Proxy veya PgBouncer ara katman olur. Step Functions, EventBridge veya kovaya bağlı tetik ile örülmüş bir hattı başka buluta taşımak da ucuz değildir.

Bunlar birbirinin alternatifi mi?

Sık hata, sunucusuz ile mikroservisi aynı rafta değiştokuş etmektir.

Mikroservis bir mimari stildir. İşi domain sınırına göre nasıl böleceğinizi söyler. Sunucusuz bir çalıştırma modelidir. O parçanın nasıl barınıp ölçekleneceğini söyler.

Bir mikroservis Kubernetes'te konteyner olabilir. Aynı servis Lambda veya Azure Functions üzerinde de durabilir.

UYGULAMA
  Monolit | Modüler monolit | Mikroservisler
        |
        v
ÇALIŞTIRMA
  Sanal makine | Kubernetes | FaaS
  Yönetilen konteyner (Container Apps, Cloud Run, Fargate)

Kubernetes ile Lambda'yı tek eksende kıyaslamak, yük trenini elektrik şebekesiyle kıyaslamaya benzer. Biri iş yükünü taşıyan orkestrasyondur. Diğeri olay gelince kodu çalıştıran, sağlayıcının yönettiği bir servistir.

KUBERNETES
  Gateway -> Order pod -> küme ağı -> Inventory pod
  Sürekli konteyner, düğüm kapasitesi, pod içi havuz

SERVERLESS
  Gateway -> CreateOrder fonksiyonu -> kuyruk -> ReserveStock fonksiyonu
  İstek anında açılan fonksiyon, yönetilen aracısı, dış vekil ile DB

Teknik matris

Maliyet: sunucusuz her zaman ucuz mu?

"Her zaman daha ucuz" eğriyi yok sayar. Eğri, trafiğin şekline bağlıdır.

Sunucusuz faturada dört kalem vardır. İstek sayısı. Bellek çarpı süre. API Gateway, yüksek trafikte hesaplama kalemini geçebilir. Veritabanı vekili ve ağ çıkışı.

Kubernetes tarafında kontrol düzlemi, 7/24 düğüm, yük dengeleyici ve ekibin küme mesaisi vardır. Trafik sıfır olsa da düğüm durmaz.

Aşağıdaki sayılar liste fiyatının şeklini gösteren varsayımdır. Resmi teklif değildir. Varsayım: 512 MB, ortalama 150 ms, yüksek erişilebilirlik için iki işçi düğümü.

Günde 1.000 istek. Ayda 30.000 çağrı, birçok sağlayıcının ücretsiz kotasının altında kalır. FaaS artı geçit, ayda 0 ile 1 dolar bandında durabilir. İki düğümlü bir küme boşta da 100 doların üstünde bir taban üretir. Seyrek trafikte sunucusuz belirgin biçimde ucuzdur.

Günde 100.000 istek. Ayda 3 milyon çağrı. Ücretsiz kota aşılır. Hesaplama ve geçit birlikte onlarca dolar mertebesine çıkar. Kümenin tabanı değişmez ve hâlâ daha yüksektir. Yönetim yükü olmadan sunucusuz burada da avantajlı kalabilir.

Günde 5 milyon istek. Ayda 150 milyon çağrı. Geçit, hesaplama, log ve vekil birlikte yüzlerce dolara çıkar. Rezerve edilmiş birkaç sanal makine aynı düzenli yükü daha düşük bir altyapı faturasıyla taşıyabilir. Bu noktada konteyner tarafı faturada öne geçebilir. Kümenin mühendislik mesaisi denkleme ayrıca yazılır. Yazılmazsa karşılaştırma eksiktir.

Düzenli ve yüksek trafikte ayrılmış kapasite, saf FaaS faturasını geçebilir. Dalgalı ve seyrek trafikte tersi olur.

Performans ve ölçek

Yatay ölçek, yeni kopya eklemektir. Dikey ölçek, aynı makinenin işlemci ve belleğini büyütmektir. Tepki süresi, patlamanın başladığı an ile yeni kopyanın trafiği aldığı an arasındadır.

Kubernetes, pod'u saniyeler içinde çoğaltabilir. Düğüm kapasitesi bitince yeni sanal makine istenir. İşletim sistemi, imaj ve hazır olma 90 ile 180 saniyeyi bulabilir. FaaS, eşzamanlılık limiti içinde çok sayıda yürütme ortamını daha kısa sürede açar. Sıcak ortam milisaniyedir. Soğuk ortam saniyedir.

Kampanyada üç darboğaz tipiktir.

1. Soğuk başlangıç. Ağır çalışma zamanında ilk istek 1 ile 3 saniye gecikebilir. P95 ve P99 bozulur. Provisioned concurrency veya her zaman hazır örnek bunu keser. Sıfır maliyet iddiası da kesilir.
2. Aşağıdaki sistem kilitlenir. Beş bin paralel fonksiyon, PostgreSQL'e beş bin bağlantı ister. Havuz biter, işlemci dolar, sistem durur.
3. Geri basınç yoktur. Kümede aşırı yük girişte sınırlanabilir. Kontrolsüz sunucusuz hat, arkadaki ERP veya ödeme servisini ezer.

İşlem katmanının saniyede büyümesi, veritabanının veya üçüncü tarafın aynı hızda büyüyeceği anlamına gelmez.

E-ticaret senaryosu

On bin ürün. Normal günde dalgalı, kampanyada yüz kat sıçrayan bir vitrin. Ön yüz Next.js. Çekirdek .NET. PostgreSQL ve Redis. ERP, pazaryeri, ödeme geçidi ve kargo webhook'u dışarıda.

Modüler monolit

Katalog, stok, sipariş ve ödeme tek ASP.NET Core uygulamasında modüldür. Konuşma bellek içi olayladır. PostgreSQL'de şemalar ayrılır: katalog, sipariş, stok.

Üç ile altı kişilik ekip için en sakin yoldur. Sipariş ve stok rezervasyonu tek transaction'da biter. Kampanyada katalog gezintisi tüm uygulamayı ölçekler. Bağlantı havuzu zorlanır.

Kubernetes üzerinde mikroservis

Her bağlam ayrı konteyner ve ayrı API'dir. Asenkron hat Service Bus veya RabbitMQ'dur.

On beş kişiyi aşan ekipler bağımsız yürür. Katalog yirmi poda çıkarken ödeme üç podda kalabilir. Maliyet ve Saga bedeli vardır. Stok onayı gelmezse telafi işlemi çalışmalıdır.

Hibrit

Çekirdek, düşük gecikme ve ACID isteyen adımlardır. Bunlar Container Apps veya eşdeğer bir konteyner ortamında durur. Bağlantı havuzu kararlı tutulur.

Sunucusuz hat olayla uyanır. Görsel yüklenince boyutlandırma. Sipariş bitince PDF ve e-posta. Gece pazaryeri fiyatı. Kargo webhook'unu kuyruğa bırakan ince bir HTTP fonksiyonu.

İstemci -> CDN -> Next.js ve API geçidi
  |
  +-- Konteyner çekirdek
  |     Katalog ve sipariş/ödeme (.NET)
  |     Redis, PostgreSQL
  |
  +-- Sipariş olayı -> kuyruk
        |-- bildirim fonksiyonu
        |-- ERP stok fonksiyonu
        |-- kargo webhook fonksiyonu -> veritabanı
        |-- görsel fonksiyonu (depolama tetikler)
        |-- gece rapor fonksiyonu (zamanlayıcı)

.NET örneği: stok olayı

ERP'den InventoryUpdatedEvent gelir. Aynı iş iki çalıştırma modelinde yazılır.

Azure Functions

Kuyrukta mesaj varsa kalkar. Gece hareket yoksa işlemci süresi yazılmaz. Sabah 50.000 güncelleme gelirse paralel yürütücüye açılır.

using System.Text.Json;
using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

namespace ECommerce.Serverless.Functions;

public record InventoryUpdatedEvent(string Sku, int NewStockQuantity, DateTime Timestamp);

public class InventoryUpdateFunction
{
    private readonly ILogger<InventoryUpdateFunction> _logger;
    private readonly IInventoryService _inventoryService;

    public InventoryUpdateFunction(
        ILogger<InventoryUpdateFunction> logger,
        IInventoryService inventoryService)
    {
        _logger = logger;
        _inventoryService = inventoryService;
    }

    [Function(nameof(ProcessInventoryUpdate))]
    public async Task ProcessInventoryUpdate(
        [ServiceBusTrigger("inventory-updates", "erp-sync-sub", Connection = "ServiceBusConnectionString")]
        string messageBody)
    {
        var stockEvent = JsonSerializer.Deserialize<InventoryUpdatedEvent>(
            messageBody,
            new JsonSerializerOptions { PropertyNameCaseInsensitive = true });

        if (stockEvent is null || string.IsNullOrWhiteSpace(stockEvent.Sku))
        {
            _logger.LogWarning("Geçersiz stok mesajı.");
            return;
        }

        await _inventoryService.UpdateStockQuantityAsync(
            stockEvent.Sku,
            stockEvent.NewStockQuantity,
            stockEvent.Timestamp);
    }
}

public interface IInventoryService
{
    Task UpdateStockQuantityAsync(string sku, int newQuantity, DateTime timestamp);
}

Sürekli çalışan worker

Kubernetes veya Container Apps üzerinde 7/24 ayaktadır. Uzun ömürlü bağlantı kullanır. Soğuk başlangıç yoktur. Sürekli yüksek hacimde bu model daha sakindir.

using System.Text.Json;
using Azure.Messaging.ServiceBus;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

namespace ECommerce.Workers;

public class InventoryQueueProcessor : BackgroundService
{
    private readonly ServiceBusProcessor _processor;
    private readonly ILogger<InventoryQueueProcessor> _logger;
    private readonly IServiceProvider _serviceProvider;

    public InventoryQueueProcessor(
        ServiceBusClient client,
        ILogger<InventoryQueueProcessor> logger,
        IServiceProvider serviceProvider)
    {
        _logger = logger;
        _serviceProvider = serviceProvider;
        _processor = client.CreateProcessor("inventory-updates", "erp-sync-sub", new ServiceBusProcessorOptions
        {
            MaxConcurrentCalls = 10,
            AutoCompleteMessages = false,
        });
    }

    protected override async Task ExecuteAsync(CancellationToken stoppingToken)
    {
        _processor.ProcessMessageAsync += HandleAsync;
        _processor.ProcessErrorAsync += ErrorAsync;
        await _processor.StartProcessingAsync(stoppingToken);
        await Task.Delay(Timeout.Infinite, stoppingToken);
    }

    private async Task HandleAsync(ProcessMessageEventArgs args)
    {
        var stockEvent = JsonSerializer.Deserialize<InventoryUpdatedEvent>(args.Message.Body.ToString());
        if (stockEvent is null)
        {
            await args.DeadLetterMessageAsync(args.Message);
            return;
        }

        using var scope = _serviceProvider.CreateScope();
        var inventory = scope.ServiceProvider.GetRequiredService<IInventoryService>();
        await inventory.UpdateStockQuantityAsync(
            stockEvent.Sku,
            stockEvent.NewStockQuantity,
            stockEvent.Timestamp);
        await args.CompleteMessageAsync(args.Message);
    }

    private Task ErrorAsync(ProcessErrorEventArgs args)
    {
        _logger.LogError(args.Exception, "Kuyruk hatası: {Source}", args.ErrorSource);
        return Task.CompletedTask;
    }
}

Olay güdümlü konuşma

Senkron HTTP, servisleri zamana kilitler. Sipariş, stok servisini bekler. Stok iki saniye sürerse sepet onayı da iki saniye uzar. Stok çökerse sipariş de çöker.

Olay güdümlü mimaride sipariş, kaydı yazınca OrderPlaced yayımlar. Bildirim, depo ve rapor aynı olayı ayrı ayrı tüketir. Aracı Service Bus, SQS, RabbitMQ veya yüksek hacimde Kafka olabilir. Kuyruk, iş kuralı ve ölü mektup için uygundur. Kafka, akışı yeniden oynatmak için uygundur.

Üç kural ihmal edilmez.

1. Tekillik. Aynı olay iki kez gelebilir. Tüketici OrderId gördüyse ikinci kez tahsil etmez ve ikinci kez stok düşmez.
2. Outbox. Veritabanına yazmak ile kuyruğa atmak iki işlemdir. Olay, yerel transaction içinde bir outbox satırına yazılır. Ayrı bir süreç o satırı kuyruğa taşır.
3. Ölü mektup. Bozuk mesaj, deneme sınırından sonra ana kuyruğu tıkamaz. DLQ'ya alınır.

Güvenlik ve operasyon

Sunucusuzda işletim sistemi yamasını düşünmezsiniz. Her fonksiyona yalnız gideceği kuyruk veya tablo için rol verilir. Geniş yönetici rolü en sık ihlaldir. Kubernetes'te imaj taraması, root'suz çalışma, pod ağı ve sertifika sizdedir.

İz üç parçadır. Metrik, yapılandırılmış log, iz. OpenTelemetry bunları sağlayıcıdan bağımsız toplar. İstemciden gelen traceparent, geçitten servise, kuyruğa ve fonksiyona taşınır. Tek grafikte her durakta geçen süre okunur.

Hangi proje, hangi model?

Karar listesi

1. Bağımsız takımlara bölünecek en az on kişi ve bir SRE var mı? Yoksa mikroservisten uzak durun.
2. İş sınırları oturdu mu? Oturmadıysa modüler monolit. Yanlış çizilmiş servis sınırını geri almak, monoliti bölmekten zordur.
3. Trafik 7/24 düzenli mi, yoksa uzun sessizlikten sonra mı patlıyor? Düzenliyse konteyner. Dalgalıysa sunucusuz.
4. Katı ACID mi gerekiyor, birkaç saniyelik nihai tutarlılık yeter mi?
5. P99 gerçekten 50 ms altında mı olmak zorunda? Öyleyse soğuk başlangıç kabul edilmez.
6. On beş dakikayı aşan kesintisiz iş var mı? Varsa standart FaaS sığmaz.
7. Sabit taban ücret ödenebilir mi, yoksa kullandıkça öde mecbur mu?
8. Küme ağı ve otomatik ölçek, üretimde çözülebiliyor mu?
9. Başka buluta veya şirket içine taşınma şart mı?
10. Bellekte oturum veya kalıcı soket var mı?
11. Dağıtık iz ve korelasyon kimliği ilk günden kurulacak mı?
12. Veri, özel alt ağda mı durmak zorunda?

Sık hatalar

İki kişilik ekip, kullanıcısı olmayan üründe on iki servis açar. Modüler monolit ile başlanır. Sınır olgunlaşınca modül servise çıkar.

Her tablo ve her uç için ayrı fonksiyon açmak nano-servistir. Sınır, HTTP metoduna göre değil bağlama göre çizilir.

On servis aynı PostgreSQL tablolarına SQL atarsa bu mikroservis değildir. Veriye yalnız o servisin API'si veya olayı ile girilir.

A, B'yi, B, C'yi senkron çağırırsa zincirdeki tek kopma akışı düşürür. Yan iş kuyruğa alınır.

Yalnız fonksiyon süresini hesaplayıp geçit, NAT ve logu unutmak faturayı şaşırtır. Toplam maliyet yazılır.

Yüzlerce fonksiyon max_connections doldurur. Havuz vekili veya HTTP veri API'si gerekir.

Aynı mesaj üç kez denenip üç kez tahsil edilir. Tüketici işlem anahtarı ile ikinci çalıştırmayı reddeder.

Sekiz servisin logunda kaybolunur. İlk günden OpenTelemetry ve korelasyon kimliği zorunlu olur.

Otuz günlük çerçeve