Uç Bilişim ve Sunucusuz Mimari: Geliştirici Rehberi

Yazılım dağıtım biçimimiz sessiz bir devrim geçirdi. On yıl önce bir uygulamayı dağıtmak, sanal bir makine kurmak, bir çalışma zamanı yüklemek, bir ters proxy yapılandırmak ve izleme sisteminin sorunları kullanıcılardan önce yakalamasını ummak anlamına geliyordu. Bugün ise bir fonksiyonu sunucusuz bir platforma gönderebilir ve saniyeler içinde küresel ölçekte istekleri yanıtlamaya başlamasını sağlayabilirsiniz — hiçbir zaman bir işletim sistemi düşünmeniz gerekmez. Uç bilişim bunu bir adım öteye taşır: kodunuz tek bir bölgede değil, gezegenin dört bir yanına dağılmış düzinelerce veri merkezinde, her kullanıcıya birkaç dakika mesafede çalışır.

Sunuculardan fonksiyonlara ve bölgelerden uca olan bu geçiş, yalnızca operasyonel bir değişiklik değildir. Uygulamalarınızı nasıl tasarladığınız konusunda temel bir değişimdir. Önbellekleme stratejileri değişir. Veritabanı erişim desenleri değişir. Dağıtım iş akışları değişir. Sürekli çalışan ve durumu bellekte tutan bir süreç zihinsel modelinin yerini, durumsuz olması, hızlı başlaması ve her isteğin farklı bir makineye düşebileceği bir dünya için tasarlanmış geçici çağrımlar alır.

Bu rehber, uç bilişim ve sunucusuz fonksiyonlarla uygulama geliştirmenin pratik gerçekliğini ele alır. Platformları, ödünleşimleri, üretimde gerçekten önemli olan optimizasyon stratejilerini ve — en az bunlar kadar önemlisi — bunların hiçbirini kullanmamanız ve uzun ömürlü bir sunucuda kalmanız gereken durumları kapsar.

Sunucusuz bilişim modellerini anlamak

Sunucusuz terimi bir yanlış adlandırmadır. Sunucular vardır — hem de bir sürü — ancak siz onları yönetmezsiniz. Bulut sağlayıcısı; tedarik, ölçekleme, yama yönetimi ve kapasite planlamasını üstlenir. Siz kodu sağlarsınız, sağlayıcı da onu talep üzerine çalıştırır. Bu üst düzey tanımın ötesinde, çok farklı amaçlara hizmet eden iki ayrı model ortaya çıkmıştır.

Hizmet Olarak Fonksiyon (FaaS)

FaaS, çoğu geliştiricinin sunucusuz deyince aklına gelen şeydir. Tek amaçlı bir fonksiyon yazar, AWS Lambda, Cloudflare Workers veya Google Cloud Functions gibi bir platforma dağıtırsınız ve platform bu fonksiyonu olaylara yanıt olarak çağırır — HTTP istekleri, kuyruk mesajları, veritabanı değişiklik akışları veya zamanlanmış zamanlayıcılar. Her çağrı, yalıtılmış bir kum havuzunda çalışır ve sağlayıcıya bağlı olarak en yakın milisaniyeye veya yüz milisaniyelik artımlara yuvarlanan yalnızca fonksiyonunuzun tükettiği işlem süresi kadar ödeme yaparsınız.

FaaS, istek-yanıt iş yükleri, webhook işleyicileri, görüntü işleme hatları ve girdinin çıktıya durumsuz dönüşümü olarak ifade edilebilen her tür görev için iyi çalışır. Kısıtlama, yürütme süresidir: Lambda fonksiyonları on beş dakika sonra zaman aşımına uğrar, Workers otuz saniyede (veya ücretli planlarda Durable Objects kullanarak on beş dakika), Cloud Functions ise HTTP ile tetiklenen fonksiyonlar için dokuz dakika ve arka plan fonksiyonları için altmış dakika sonra zaman aşımına uğrar. Bu sınırlamalar ne inşa edebileceğinizi şekillendirir.

Hizmet Olarak Arka Uç (BaaS)

BaaS farklı bir yaklaşım benimser. Kodunuzu çalıştırmak yerine, sağlayıcı SDK'lar ve API'ler aracılığıyla entegre olduğunuz yönetilen hizmetleri sunar. Firebase, Supabase, Auth0 ve Neon BaaS ürünleridir. Hiçbir şey dağıtmadan kimlik doğrulama, veritabanı, dosya depolama ve gerçek zamanlı abonelikler elde edersiniz. BaaS ve FaaS sıklıkla birbirini tamamlar: fonksiyonlarınız kalıcılık ve kimlik doğrulama için BaaS hizmetlerini kullanır ve BaaS hizmetleri veri değiştiğinde fonksiyonlarınızı tetikler.

Temel fark mimaridir. FaaS ile mantığı siz kontrol edersiniz; BaaS ile mantığı yapılandırırsınız. BaaS ile geliştirmek daha hızlıdır ancak kaçmak daha zordur. Kimlik doğrulamanız Firebase'e ve dosya depolamanız S3'e bağlandığında, geçiş yapmak aylar süren bir proje haline gelir. Bu mutlaka kötü bir ödünleşim değildir, ancak bu kararı kazara değil bilinçli olarak vermelisiniz.

Uç bilişim platformları ve kullanım alanları

Uç bilişim, hesaplamayı kullanıcılara coğrafi olarak yakın konumlara taşır. Tüm istekleri tek bir us-east-1 veri merkezine yönlendirmek yerine, uç platformlar kodunuzu dünya çapında düzinelerce veya yüzlerce konumda çalıştırır. Gecikme farkı çarpıcıdır: Tokyo'daki bir kullanıcının us-east-1'e bağlanması yaklaşık 150 milisaniyelik ağ gecikmesi görürken; bir Tokyo uç düğümüne bağlanması beş milisaniyenin altındadır.

Üç platform, her biri farklı bir mimari ve ödünleşim setiyle uç bilişim alanına hakimdir.

Cloudflare Workers

Cloudflare Workers, konteynırlar yerine V8 Isolate çalışma zamanında çalışır. Her Worker bir JavaScript isolate içinde çalışır — bir konteynırın ihtiyaç duyduğu onlarca veya yüzlerce milisaniye yerine mikrosaniyeler içinde başlayan hafif bir kum havuzu. Bu tasarım kararının derin etkileri vardır: Workers, 330'dan fazla veri merkezinde saniyede milyonlarca isteği işleyebilir, soğuk başlatmalar neredeyse tamamen ortadan kalkar ve fiyatlandırma işlem süresi yerine istek sayısına dayanır. Ödünleşim, Workers'ın sınırlı bir çalışma zamanı ortamında çalışmasıdır. Rastgele ikili dosyalar çalıştıramazsınız, istek başına CPU süresi sınırlıdır ve varsayılan katmanda dosya sistemi erişimi yoktur.

Workers, istek değişiklikleri, API kompozisyonu, kimlik doğrulama ve yetkilendirme kontrolleri, A/B testi ve kaynak sunucularınızın önünde bir orkestrasyon katmanı olarak hizmet vermede üstündür. CPU yoğun hesaplamalar veya 30 saniyelik CPU süresi sınırını aşan iş yükleri için daha az uygundur.

AWS Lambda@Edge ve CloudFront Functions

AWS, CloudFront ile entegre iki uç bilişim katmanı sunar. CloudFront Functions, uç konumlarda çalışır ve hafif istek ve yanıt dönüşümlerini yönetir. 10 mikrosaniyelik faturalama artımı, 2 MB bellek sınırı ve 100 mikrosaniyelik yürütme sınırı vardır. URL yeniden yazmalar, başlık değişiklikleri ve önbellek anahtarı manipülasyonu için tasarlanmışlardır — CloudFront'in önbelleğe vurma veya kaynağa yönlendirme kararı vermeden önce tamamlanması gereken görevler.

Lambda@Edge, aynı CloudFront uç konumlarında çalışır ancak Node.js, Python ve Lambda Execution Environment aracılığıyla özel çalışma zamanları için tam Lambda ortamını sağlar. Görüntüleyici-isteği ve görüntüleyici-yanıtı tetikleyicileri için beş saniye, kaynak-isteği ve kaynak-yanıtı tetikleyicileri için otuz saniye yürütme sınırı vardır. Lambda@Edge, DynamoDB'den okuyabilir, harici API'leri çağırabilir ve uçta dinamik içerik üretebilir; bu da onu kişiselleştirme, konum tabanlı içerik ve bot tespiti için uygun kılar.

Diğer uç platformları

Fastly Compute@Edge, Rust, JavaScript (Javy aracılığıyla) ve C'yi destekleyen WebAssembly tabanlı bir çalışma zamanı kullanır. WASM derlemesi istek zamanında değil dağıtım zamanında gerçekleştiği için milisaniye altı soğuk başlatma ve öngörülebilir performans sunar. Deno Deploy ve Vercel Edge Functions da Cloudflare Workers'a benzer şekilde V8 isolate üzerinde çalışır ve kendi platform ekosistemleriyle sıkı entegrasyon sağlar.

• Cloudflare Workers: Milisaniye altı soğuk başlatmalarla küresel ölçekte HTTP orkestrasyonu, kimlik doğrulama ve API kompozisyonu için en iyisi.
• Lambda@Edge: DynamoDB ve S3 dahil AWS ekosistemine erişimle uçta tam Lambda yeteneklerine ihtiyaç duyduğunuzda en iyisi.
• Fastly Compute@Edge: Öngörülebilir performans ve çok dilli çalışma zamanı desteği gerektiren WASM tabanlı iş yükleri için en iyisi.
• Vercel Edge Functions: Zaten Vercel ekosistemindeyken ve ön yüz çerçevenizle sıkı entegre uç bilişime ihtiyaç duyduğunuzda en iyisi.
• Deno Deploy: Küresel dağıtımla basit bir dağıtım deneyimi isteyen TypeScript doğal geliştiricileri için en iyisi.

Uç bilişim için birincil kullanım alanları

• Önbellek isabetsizliğine veya merkezi bir kaynağa gidiş-dönüşe zorlamadan uçta dinamik içerik kişiselleştirme.
• Tüm uç konumlara dağıtılmış API ağ geçidi işlevselliği — kimlik doğrulama, hız sınırlama, istek doğrulama ve yanıt dönüşümü.
• Bayrak kontrolünün istek kaynak sunucuya ulaşmadan gerçekleştiği A/B testi ve özellik bayrağı değerlendirme.
• Farklı bölgelerdeki kullanıcıların ek gecikme olmadan bölgeye özgü içerik gördüğü konum tabanlı yönlendirme ve içerik dağıtımı.
• Kötü niyetli trafiği uygulama sunucularına ulaşmadan engelleyen ağ ucunda bot tespiti ve istek filtreleme.
• Tam SEO desteğiyle hızlı ilk sayfa yüklemeleri sunmak için uçta HTML'in sunucu tarafında render edilmesi.

Son kullanıcılar için gecikmeyi azaltmak, ekibiniz için karmaşıklığı azaltmaktan daha önemli olduğunda mantığı uca taşıyın. Uç bilişim bedava değildir — dağıtık hata ayıklama, durum yönetimi ve dağıtım koordinasyonunun tümü ek yük getirir. Bu maliyeti yalnızca kullanıcılarınız farkı gerçekten hissettiğinde ödeyin.

Soğuk başlatma optimizasyon stratejileri

Soğuk başlatmalar, sunucusuz bilişimin en çok tartışılan dezavantajı olmaya devam ediyor. Bir fonksiyon boştayken çağrıldığında, platform yeni bir kum havuzu sağlamalı, kodunuzu yüklemeli ve isteği işleyebilmeden önce başlatma mantığını çalıştırmalıdır. Bu, çalışma zamanına ve dağıtım paketinizin boyutuna bağlı olarak tipik olarak 200 milisaniye ile birkaç saniye arasında gecikme ekler.

Soğuk başlatmaların şiddeti platforma ve çalışma zamanına göre önemli ölçüde değişir. Cloudflare Workers, konteynırlar yerine V8 isolate kullanarak sorunu neredeyse tamamen ortadan kaldırdı — soğuk başlatmalar mikrosaniyeler sürer. Lambda, SnapStart özelliğinde Node.js ile bir anlık görüntüden geri yükleyerek soğuk başlatmaları 200 milisaniyenin altına indirir. Optimizasyon yapılmamış Java veya .NET ile Lambda birkaç saniye sürebilir. Bu farklılıkları anlamak, sorunu hafifletmenin ilk adımıdır.

Dağıtım paketi boyutunu küçültün

En etkili optimizasyon, dağıtım paketinizi küçültmektir. Soğuk başlatma süresi, belleğe yüklenmesi gereken kodun boyutuyla güçlü bir şekilde ilişkilidir. Gereksiz bağımlılıkları kaldırın, kullanılmayan dışa aktarımları temizlemek için tree-shaking kullanın ve tek bir küçültülmüş dosya üretmek için esbuild veya tsup gibi bir paketleyici kullanmayı düşünün. 500 KB'lık bir paket olarak dağıtılan bir Lambda fonksiyonu, her ikisi de aynı çalışma zamanını kullansa bile, 50 MB'lık bir paket olarak dağıtılandan önemli ölçüde daha hızlı başlar.

// Önce: tüm SDK'nın paketlendiği lambda işleyicisi
import { DynamoDBClient } from "@aws-sdk/client-dynamodb";
import { S3Client } from "@aws-sdk/client-s3";
import { LambdaClient } from "@aws-sdk/client-lambda";

// Sonra: yalnızca gerçekten kullandığınızı içe aktarın
import { DynamoDB } from "@aws-sdk/client-dynamodb";

const client = new DynamoDB({ region: process.env.AWS_REGION });

export const handler = async (event: APIGatewayProxyEvent) => {
  const result = await client.getItem({
    TableName: process.env.TABLE_NAME!,
    Key: { pk: { S: event.pathParameters!.id } },
  });
  return {
    statusCode: 200,
    body: JSON.stringify({ item: result.Item }),
    headers: { "content-type": "application/json" },
  };
};

Tembel başlatma ve bağlantı yeniden kullanımı

İkinci büyük optimizasyon, pahalı başlatma işlemlerini istek işleyicisinin dışına ve küresel kapsama taşımaktır. Lambda'da, işleyici dışında yürütülen kod, kum havuzu başlatıldığında bir kez çalışır ve sıcak çağrımlar arasında kalıcı olur. Veritabanı bağlantıları, HTTP istemcileri ve yapılandırma yükleyicileri, işleyici fonksiyonunun içinde değil, modül kapsamında başlatılmalıdır.

// Kötü: her çağrıda yeni bir bağlantı oluşturur
import { PrismaClient } from "@prisma/client";

export const handler = async () => {
  const prisma = new PrismaClient();
  const result = await prisma.user.findMany();
  await prisma.$disconnect();
  return result;
};

// İyi: bağlantıyı sıcak çağrımlar arasında yeniden kullanır
import { PrismaClient } from "@prisma/client";

const prisma = new PrismaClient();

export const handler = async () => {
  return prisma.user.findMany();
};

Burada bir incelik var. AWS SDK v3 for JavaScript, istekleri yeniden deneyen ve kimlik bilgilerini yöneten ara katman içerir. Modül kapsamında tek bir istemci oluşturmak, bir kum havuzu içindeki tüm çağrımların aynı bağlantı havuzunu ve SSL oturumunu paylaşması anlamına gelir. Bu, ilk çağrımdan sonra çağrım başına gecikmeyi 50-100 milisaniye azaltır. Aynı ilke HTTP istemcileri, Redis bağlantıları ve diğer pahalı kaynaklar için de geçerlidir.

Sağlanan eşzamanlılık ve sıcak tutma desenleri

Soğuk başlatmalara tolerans gösteremeyen fonksiyonlar için, sağlanan eşzamanlılık belirli sayıda kum havuzunu sıcak ve hazır tutar. AWS Lambda sağlanan eşzamanlılığı, yürütme ortamlarını başlatılmış halde tutar ve istekleri anında işlemeye hazır olmalarını sağlar. Maliyet, bu örnekleri sürekli çalıştırmaya eşdeğerdir ve bu da sunucusuzun ana avantajlarından birini — yalnızca kullandığınız kadar ödeme — aşındırır.

Bazı iş yükleri için daha uygun maliyetli bir alternatif, sıcak tutma desenidir: fonksiyonunuzu her birkaç dakikada bir çağırarak kum havuzunun geri dönüştürülmesini önleyen bir CloudWatch Event. Lambda, boştaki yürütme ortamlarını yaklaşık on beş dakika sonra geri alır, bu nedenle her beş dakikada bir yapılan bir ping, minimum maliyetle birkaç ortamı sıcak tutar. Buradaki uyarı, bunun yalnızca öngörülebilir trafik desenlerine sahip fonksiyonlar için çalışmasıdır. Trafiğiniz sıfırdan saniyede binlerce isteğe sıçrarsa, pingler patlamayı karşılayacak kadar ortamı sıcak tutamaz.

Sunucusuz için durum yönetimi desenleri

Sunucusuz fonksiyonlar tasarım gereği durumsuzdur. Aynı kullanıcıdan gelen iki ardışık çağrım, farklı makinelerdeki farklı kum havuzlarında çalışabilir. Yerel dosya sistemi yazmaları kaybolur. Bellek içi veri kaybolur. Bu temel üzerinde güvenilir uygulamalar oluşturmak, durumu fonksiyon çalışma zamanının dışında bilinçli bir şekilde yönetmeyi gerektirir.

Harici durum depoları

En basit ve en güvenilir yaklaşım, durumu harici bir hizmete göndermektir. Kalıcı durum için DynamoDB, Redis (ElastiCache veya Upstash aracılığıyla) veya ilişkisel bir veritabanı kullanın. Dosya depolama ve büyük nesneler için S3 veya Cloudflare R2 kullanın. Fonksiyon, SDK çağrıları aracılığıyla durumu okur ve yazar ve her çağrımı belirli bir kum havuzundan bağımsız ve tekrar edilebilir kılar.

Bunun maliyeti gecikmedir. Duruma ihtiyaç duyan her fonksiyon çağrımı, durum deposuna en az bir ağ gidiş-dönüşü yapmalıdır. Tek bir bölgede dağıtılan Lambda fonksiyonları için bir DynamoDB okuması 5-15 milisaniye sürer. Hindistan'daki bir uç düğümünden us-east-1'deki merkezi bir veritabanına bağlanan uç fonksiyonları için aynı okuma 200-300 milisaniye sürer. Uç bilişimdeki temel gerilim budur: uç, kullanıcıya yakın hızlı işlem gücü verir, ancak verileriniz hâlâ bir yerdedir ve onları uca getirmek zaman alır.

Durable Objects ve D1 (Cloudflare)

Cloudflare, Durable Objects ile durum sorununa benzersiz bir çözüm sunar. Durable Object, belirli bir veri merkezinde bulunan ve istekler arasında bellek içi durumu koruyan tek örnekli bir JavaScript sınıfıdır. Birden fazla Worker aynı Durable Object'e mesaj gönderebilir ve bunları tutarlı bir sırayla işler. Bu, işlem gücünün küresel dağılımından ödün vermeden uçta güçlü tutarlı durum sağlar.

• Koordinasyon durumu için Durable Objects kullanın: WebSocket bağlantı yönetimi, hız sınırlama sayaçları, dağıtık kilitler ve gerçek zamanlı çok oyunculu oyun durumu.
• Bölgeler arasında okuma çoğaltması ile uç dağıtımdan faydalanan ilişkisel veriler için D1 (Cloudflare sunucusuz SQLite) kullanın.
• Güçlü tutarlılık gerektirmeyen yapılandırma, özellik bayrakları ve önbelleklenmiş veriler için KV (Cloudflare anahtar-değer deposu) kullanın.
• Çıkış ücreti olmadan küresel olarak erişilebilir olması gereken nesne depolama için R2 kullanın.

Step Functions ve Workflows ile fonksiyon orkestrasyonu

Karmaşık iş süreçleri genellikle birden fazla fonksiyona yayılır. Bir kullanıcı kayıt akışı, girdiyi bir fonksiyonda doğrulayabilir, ikincisinde bir veritabanı kaydı oluşturabilir, üçüncüsünde bir hoş geldin e-postası gönderebilir ve dördüncüsünde bir arama indeksini güncelleyebilir. Bu adımları yeniden denemeler, hata yönetimi ve gözlemlenebilirlik ile güvenilir bir şekilde koordine etmek, orkestrasyon gerektirir.

AWS Step Functions, iş akışlarını JSON ile durum makineleri olarak tanımlamanızı sağlar. Her durum bir Lambda çağrımı, bir seçim dalı, bir paralel yürütme veya bir bekleme adımı olabilir. Durum makinesinin kendisi iş akışı durumunu kalıcı olarak depolar, böylece her Lambda fonksiyonu aynı anda başarısız olsa bile iş akışı son tamamlanan adımdan devam eder. Cloudflare, Queues ve Durable Object tabanlı iş akışları aracılığıyla benzer bir yetenek sunar.

Sunucusuz geliştirmedeki en zor ders, durumsuz fonksiyonların son derece disiplinli durum yönetimi gerektirdiğidir. Bir fonksiyonda her küresel değişkene veya yerel dosyaya uzandığınızda, yalnızca yük altında ortaya çıkacak bir hata ekliyorsunuzdur. Durumu erken dışsallaştırın ve üretim hata ayıklama oturumlarınız önemli ölçüde kısalacaktır.

Uç ve sunucusuzdan veritabanı erişimi

Veritabanı erişimi, sunucusuz mimaride en tartışmalı konudur. Geleneksel veritabanı sürücüleri kalıcı bağlantılar varsayar — uygulama başlangıcında bir TCP bağlantısı açar ve işlemin ömrü boyunca yeniden kullanırlar. Sunucusuz fonksiyonlar bağlantıları hızla açar ve kapatır ve her çağrım için yeni bir TLS bağlantısı kurma yükü, toplam yürütme süresine hakim olabilir.

Bağlantı havuzlama ve sunucusuz sürücüler

Sunucusuz veritabanı erişiminin ilk nesli, PgBouncer veya RDS Proxy gibi bağlantı havuzlama katmanları kullandı. Bu hizmetler, fonksiyonunuz ile veritabanı arasında durur, kalıcı bağlantılardan oluşan bir havuz tutar ve geçici fonksiyon bağlantılarını bunlar arasında çoğullar. RDS Proxy, bağlantı yükünü yüzlerce milisaniyeden tek haneli rakamlara düşürürken aynı zamanda veritabanını fonksiyonlar hızla ölçeklendiğinde oluşan bağlantı fırtınalarından korur.

İkinci nesil, TCP soketleri yerine HTTP veya WebSocket taşımaları kullanan amaca yönelik sunucusuz veritabanı sürücüleridir. Neon, TCP el sıkışma yükünü tamamen ortadan kaldıran WebSocket tabanlı bir sürücü kullanır. PlanetScale, MySQL uyumlu bir HTTP API sunar. Turso, HTTP ve WebSocket desteğiyle libsql kullanır. Bu sürücüler milisaniyeler içinde bağlanır ve bu da onları saniyenin altında yürütme sürelerine sahip Lambda fonksiyonları için uygun kılar.

import { neon } from "@neondatabase/serverless";
import { drizzle } from "drizzle-orm/neon-http";

const sql = neon(process.env.DATABASE_URL!);
const db = drizzle(sql);

export async function handler(request: Request) {
  const users = await db.query.users.findMany({
    where: (users, { gte }) => gte(users.lastLogin, new Date("2026-01-01")),
    limit: 50,
  });

  return new Response(JSON.stringify(users), {
    headers: { "content-type": "application/json" },
  });
}

Sunucusuz gecikme bütçeleri için sorgu optimizasyonu

Sunucusuz bir fonksiyondaki her veritabanı sorgusu, sınırlı bir yürütme bütçesi için rekabet eder. 500 milisaniye süren bir fonksiyon, 50 milisaniye sürenden daha pahalıya mal olur ve daha yavaş hissedilir. Bu, optimizasyon odağını sunucu maliyetlerini azaltmaktan fonksiyon süresini azaltmaya kaydırır. Sonuç olarak, bir sunucu bağlamında kabul edilebilir olan veritabanı sorguları — bir yanıtı birleştirmek için üç veya dört sıralı sorgu — sunucusuzda kabul edilemez hale gelir çünkü her sorgu bir ağ gidiş-dönüşü ekler.

Çözüm, sorguları agresif bir şekilde birleştirmektir. Ayrı aramalar yerine JOIN kullanın. Tek bir çağrım içinde sorguları toplu işlemek için GraphQL DataLoader veya DataLoader desenlerini kullanın. Gerçek zamanlı tutarlılık gerektirmeyen sorgular için okuma çoğaltmaları veya önbelleklenmiş materialized view kullanın. Ortadan kaldırılan her gidiş-dönüş, fonksiyon yürütme süresinde ve dolayısıyla maliyette doğrudan bir azalmadır.

Uç veritabanı ödünleşimleri

us-east-1'deki merkezi bir veritabanını sorgulayan uç fonksiyonları, sorgu başına 100-300 milisaniyelik ağ gecikmesiyle karşılaşır. Bu, uç bilişimin faydasının çoğunu ortadan kaldırır. Çözüm, ya verileri uca çoğaltmak ya da verileri uç konumlara daha yakın depolayan D1 veya Turso gibi dağıtık SQLite tabanlı bir veritabanı kullanmaktır.

Dağıtık veritabanlarının kendi ödünleşimleri vardır. D1, SQLite kullanır ve tek yazıcı modeli aracılığıyla eşzamanlı yazmaları işler — okuma ağırlıklı iş yükleri için kabul edilebilir ancak yazma ağırlıklı uygulamalar için sınırlayıcıdır. Turso, okumalar için gömülü çoğaltmalar ve yazmalar için bir birincil kullanır ve okuma çoğaltmaları için nihai tutarlılık sağlar. Kullanım durumunuz için güçlü tutarlılık gerekip gerekmediğine karar vermelisiniz. Gerekiyorsa, uçtan merkezi bir birincil veritabanına ulaşmanın gecikmesini kabul etmeniz gerekebilir.

Gözlemlenebilirlik ve hata ayıklama

Sunucusuz fonksiyonlarda hata ayıklamak, sunucularda hata ayıklamaktan daha zordur çünkü çalışma zamanı geçicidir. Bir fonksiyona SSH ile bağlanıp durumunu kontrol edemezsiniz. Çalışan bir çağrıma hata ayıklayıcı ekleyemezsiniz. Belirli bir örneğin günlüklerini izleyemezsiniz çünkü örnekler dinamik olarak oluşturulur ve yok edilir. Etkili gözlemlenebilirlik, temelde farklı bir yaklaşım gerektirir.

Yapılandırılmış günlükleme ve dağıtık izleme

CloudWatch Logs'a dağılmış Console.log ifadeleri, üretim hata ayıklaması için yeterli değildir. Her fonksiyon çağrımı, çağrımı yukarı ve aşağı akış hizmetlerine bağlayan bir korelasyon kimliği içeren yapılandırılmış JSON günlükleri yaymalıdır. AWS Lambda, bağlam nesnesinde istek kimliğini otomatik olarak sağlar ve bu kimliği veritabanı sorgularınız, harici API çağrılarınız ve aşağı akış fonksiyon çağrılarınız aracılığıyla yaymalısınız.

AWS X-Ray, DataDog ve Honeycomb gibi dağıtık izleme araçları, bir isteğin tüm yaşam döngüsü hakkında size görünürlük sağlar: her fonksiyonun ne kadar sürdüğü, hangi aşağı akış hizmetlerini çağırdığı, hangi veritabanı sorgularını yürüttüğü ve zamanın nerede harcandığı. X-Ray, Lambda ve Step Functions ile doğal olarak entegre olur ve herhangi bir kod değişikliği olmadan fonksiyonlarınız arasındaki etkileşimleri görselleştiren hizmet haritaları sağlar.

Yerel öykünme ve test

Sunucusuz fonksiyonları yerel olarak test etmek önemli ölçüde gelişti. AWS SAM CLI, Serverless Framework Offline ve LocalStack; Lambda, API Gateway, DynamoDB ve diğer hizmetlerin yerel öykünmesini sağlar. Cloudflare Workers, sıcak yeniden yükleme ve KV, D1, R2 ve Durable Objects'in yerel öykünmelerine erişim sağlayan wrangler dev ile yerel olarak çalıştırılabilir. Bu araçlar, her değişiklik için üretime dağıtmadan hızla yineleme yapmanızı sağlar.

# Yerel geliştirme için wrangler.toml — Cloudflare Workers
name = "api-worker"
main = "src/index.ts"
compatibility_date = "2026-06-01"

[[d1_databases]]
binding = "DB"
database_name = "app-db"
database_id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

[[kv_namespaces]]
binding = "KV"
id = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

# Yerel çalıştırma: npx wrangler dev
# Dağıtım: npx wrangler deploy

Tek bir isteği tüm sisteminiz boyunca — onu alan uç fonksiyondan ona hizmet eden veritabanı sorgusuna kadar — izleyemiyorsanız, gözlemlenebilirliğiniz yok demektir, günlük gürültünüz var demektir. Korelasyon kimlikleri ve dağıtık izleme, üretim sunucusuz sistemleri için isteğe bağlı değildir. Bunlar, beş dakikalık bir hata ayıklama oturumu ile beş saatlik bir hata ayıklama oturumu arasındaki farktır.

Maliyet hususları ve ölçekleme

Sunucusuz fiyatlandırması aldatıcıdır. Kâğıt üzerinde çağrım başına maliyet çok küçüktür — Lambda, milyon istek başına $0.20 artı GB-saniye başına $0.0000166667 işlem süresi ücretlendirir. Bu rakamlar imkansız derecede ucuz görünür. Pratikte, maliyetler sunucusuz faturalamanın gerçek dünya trafik desenleriyle nasıl etkileşime girdiğini anlamayan ekipleri şaşırtabilir.

Maliyet sürücülerini anlamak

Üç faktör sunucusuz maliyetlerini yönlendirir: çağrım sayısı, yürütme süresi ve bellek ayırımı. Bellek ayırımını iki katına çıkarmak saniyelik işlem maliyetini iki katına çıkarır ancak yürütme süresini yarıya indirebilir ve potansiyel olarak toplam maliyeti değiştirmeden bırakabilir veya hatta azaltabilir. Her fonksiyon için en uygun bellek ayırımını bulmak deney gerektirir: fonksiyonunuzu 256 MB, 512 MB, 1024 MB ve 2048 MB'da kıyaslayın ve her seviyede çağrım başına maliyeti hesaplayın.

Veri aktarım maliyetleri gizli vergidir. Bölgeler arasında iletişim kuran Lambda fonksiyonları — başka bir bölgedeki merkezi bir veritabanını çağıran bir uç fonksiyonu — işlem maliyetlerini bir büyüklük sırasıyla aşabilen veri aktarım ücretlerine tabidir. Cloudflare Workers çıkış için ücret almaz, ancak Lambda@Edge ve Vercel Edge Functions alır. Bir mimariye bağlanmadan önce veri akışınızı modelleyin ve uçta verileri önbelleğe almak ve bölgeler arası trafiği azaltmak için Cloudflare R2 veya CloudFront kullanın.

Ölçekleme davranışı ve hız sınırlama

Sunucusuz otomatik olarak ölçeklenir, ancak sonsuza kadar ölçeklenmez. Lambda'nın bölgesel bir eşzamanlılık sınırı vardır (varsayılan olarak tipik olarak 1000 eşzamanlı yürütme, destek talebiyle ayarlanabilir). Cloudflare Workers'ın plan başına istek sınırı vardır. Bir trafik artışı eşzamanlılık sınırınızı aşarsa, istekler 429 veya 503 yanıtıyla hız sınırlanır. Çözüm, limit artışlarını proaktif olarak talep etmek, arka plan görevleri için kuyruk tabanlı yük dengeleme uygulamak ve gecikmeye duyarlı fonksiyonlar için sağlanan eşzamanlılık kullanmaktır.

Sunucusuz için ideal nokta, değişken trafiğe ve düşük-orta verime sahip iş yükleridir. Saniyede 10 istek sunan bir fonksiyon ayda kuruşlara mal olur. Saniyede 10.000 istek sunan bir fonksiyon binlerce dolara mal olur. Bir noktada — tipik olarak saniyede yaklaşık 50.000 istek civarında — sabit bir sunucu altyapısı daha uygun maliyetli hale gelir. Geçiş noktası, fonksiyon karmaşıklığınıza, bellek ayırımınıza ve yürütme sürenize bağlıdır.

Sunucusuz NE ZAMAN kullanılmamalı

Sunucusuz ve uç bilişim güçlü araçlardır, ancak her iş için doğru araç değildirler. Sunucusuzun orantılı fayda olmadan maliyet ve karmaşıklık eklediği durumları tanımak, mühendislik olgunluğunun bir işaretidir.

Uzun süreli veya durum bilgisi olan iş yükleri

WebSocket sunucuları, gerçek zamanlı video işleme hatları ve büyük modellerle makine öğrenimi model çıkarımı, tümü sunucusuz sınırlarını aşan yürütme süreleri veya kaynak ayırımları gerektirir. Lambda fonksiyonları on beş dakikadan fazla çalışamaz. Cloudflare Workers'ın otuz saniyelik CPU süresi sınırı vardır. İş yükünüz kalıcı bir bağlantı tutması, uzun süreler boyunca bellek içi durumu koruması veya saatlerce çalışması gerekiyorsa, geleneksel bir sunucu veya konteynır tabanlı bir hizmet doğru seçimdir.

Öngörülebilir yüksek verimli trafik

Trafiğiniz sabit ve öngörülebilirse — günde yirmi dört saat aynı saniyede 500 isteği sunan bir B2B API — sunucusuz, sabit bir sunucudan daha pahalıya mal olur. Bir t3.medium EC2 örneği kabaca ayda $30'a mal olur ve iyi optimize edilmiş bir Node.js hizmeti için saniyede binlerce isteği işleyebilir. Lambda'daki aynı iş yükü, istek başına yük ve ihtiyacınız olmayan otomatik ölçekleme yeteneği için prim nedeniyle ayda birkaç yüz dolara mal olur.

• Otomatik ölçekleme avantajının kullanılmadığı ancak istek başına fiyatlandırma priminin ödendiği sabit durumlu, yüksek verimli iş yükleri için sunucusuzdan kaçının.
• GPU'lar, büyük bellek ayırımları (>10 GB) veya özel donanıma erişim gerektiren iş yükleri için sunucusuzdan kaçının.
• Veritabanlarına veya mesaj kuyruklarına uzun ömürlü bağlantılar sürdüren uygulamalar için sunucusuzdan kaçının, çünkü bağlantı değişimi performansı düşürür ve maliyetleri artırır.
• Soğuk başlatma dalgalanmasının kabul edilemez olduğu ve sağlanan eşzamanlılık maliyetlerinin özel altyapıyı aştığı gecikme açısından kritik gerçek zamanlı sistemler için sunucusuzdan kaçının.
• Ekibiniz dağıtık hata ayıklama, yapılandırılmış günlükleme ve izleme için operasyonel araçlara sahip değilse sunucusuzdan kaçının — bu araçlar olmadan sunucusuzda hata ayıklamak acı vericidir.

Zoraki bir soyutlama olarak sunucusuz

Bazı ekipler, modern seçenek olduğu için veya bir platform satıcısı bunu sürtünmesiz hale getirdiği için sunucusuzu benimser. Bunlar yanlış nedenlerdir. Sunucusuz, belirli ödünleşimleri olan bir mimaridir: operasyonel kontrolü operasyonel basitlik için, tutarlı gecikmeyi otomatik ölçekleme için ve sisteminizi tek bir süreç olarak ele alma yeteneğini bağımsız fonksiyonlar dağıtma yeteneği için takas edersiniz. Ödünleşimler belirli kullanım durumunuza fayda sağlamıyorsa, basit bir systemd birim dosyasıyla bir VM'de çalışan bir konteynır daha iyi bir çözümdür.

Çoğu ekip için en pratik yaklaşım hibrittir. Trafiğin değişken olduğu ve otomatik ölçeklemenin önemli olduğu istek-yanıt API katmanı için sunucusuz fonksiyonlar kullanın. İşlerin dakikalar veya saatler sürdüğü arka plan işleme katmanı için konteynırlar veya sunucular kullanın. Bilişim modelinden bağımsız olarak yönetilen veritabanları (RDS, Neon, Supabase) kullanın, çünkü üretimde kendi veritabanınızı yönetmek nadiren çabaya değer. Hibrit yaklaşım, her iş yükünü tek bir soyutlamadan geçirmek yerine bilişim modelini iş yüküyle eşleştirmenizi sağlar.

Sonuç ve öneriler

Uç bilişim ve sunucusuz mimari, yazılımı inşa etme ve dağıtma biçimimizde gerçek bir ilerlemeyi temsil ediyor. Dünya çapında düzinelerce veri merkezinde kod çalıştırabilmek, herhangi bir tedarik olmadan sıfırdan saniyede binlerce isteğe ölçeklenebilmek ve yalnızca tükettiğiniz bilişim için ödeme yapabilmek, bağımsız geliştiriciler ve kurumsal ekipler için mümkün olanı değiştirdi.

Bu teknolojileri etkili bir şekilde kullanmanın anahtarı, avantajlarını olduğu kadar kısıtlamalarını da derinlemesine anlamaktır. Durumsuz fonksiyonlar disiplinli durum yönetimi gerektirir. Hızlı soğuk başlatmalar, dağıtım paketlerinin ve başlatma kodunun dikkatli optimizasyonunu gerektirir. Dağıtık hata ayıklama, ilk günden itibaren yapılandırılmış günlükleme ve izleme gerektirir. Uçtan veritabanı erişimi, sorgu desenlerini ve veri yerelliğini yeniden düşünmeyi gerektirir. Bu kısıtlamaların hiçbiri bir anlaşma bozucu değildir, ancak her biri mimaride hesaba katılmalıdır.

İş yükü profilinizin net bir resmiyle başlayın. Kullanıcılarınızın gerçekte deneyimlediği gecikmeyi ölçün, fonksiyonunuzun izole olarak bildirdiği gecikmeyi değil. Maliyetleri, fiyatlandırma sayfasındaki çağrım başına fiyattan değil, gerçekçi trafik seviyelerinde modelleyin. Gözlemlenebilirliği ilk commit'ten itibaren her fonksiyona yerleştirin. Ve her zaman eklediğiniz karmaşıklığın çözdüğünüz problem tarafından haklı çıkarılıp çıkarılmadığını kendinize sorun.

2026'da yeni uygulamalar geliştiren çoğu ekip için varsayılan başlangıç noktası, yönetilen bir veritabanı (Neon veya Supabase) tarafından desteklenen bir sunucusuz API katmanı (Cloudflare Workers veya API Gateway ile Lambda) ve arka plan görevleri için konteynır tabanlı bir iş çalıştırıcı olmalıdır. Bu kombinasyon, kullanıcıya yönelik istekler için sunucusuzun küresel dağıtım ve otomatik ölçeklemesini sağlarken, uymayan iş yükleri için sunucusuzun sorunlu noktalarından kaçınır. Uygulamanız büyüdükçe, bireysel bileşenleri daha özelleşmiş altyapıya taşıyabilirsiniz — ancak basit başlayıp karmaşıklığı yalnızca veri haklı çıkardığında eklemek, her mimari paradigmada en iyi strateji olmaya devam eder.