Python ve SQL

ClickHouse ve PostgreSQL Arasinda Cift Yonlu Senkronizasyon

2026-06-14T00:00:00Z

Selamlar, bu yazıda ClickHouse ile PostgreSQL'i aynı sistemin iki ucu gibi nasıl konuşturduğumuza bakacağız. Klasik bir 'master-master' senaryosu değil bu; daha çok her sistemin kendi güçlü olduğu işi yaptığı, sonuçların tek yönde değil, ihtiyaca göre iki yönde aktığı bir desen. Hadi başlayalım.

OLTP tarafında PostgreSQL'in alternatifi yok denecek kadar oturmuş; transaction'ları, kısıtları, foreign key'leri sorunsuz çekiyor. Ama gün sonunda 'son 30 gün ülke bazında ciro' gibi bir analitik sorgu istediğinizde aynı tablo üzerinden saatler harcayabilirsiniz. ClickHouse burada devreye girer: kolon tabanlı, sıkıştırmalı, agregasyonu saniyede bitiren bir motor. Sorun şu: uygulamanız sonuçları yine PostgreSQL'den okumak istiyor olabilir. İşte cift yonlu senkronizasyon tam bu boşluğu kapatıyor.

Mimari nasıl kurguluyoruz?

Düşünmesi kolay olsun diye şöyle özetleyeyim:

PostgreSQL (yazma) --> ClickHouse (analitik)
                              |
                              v
              ClickHouse Agregasyonlari --> PostgreSQL (uygulama okur)

Yani aynı veri iki yöne replicate edilmiyor. Ham operasyonel veri PostgreSQL'den ClickHouse'a akıyor; ClickHouse'da hesaplanan özet sonuçlar ise PostgreSQL'e geri yazılıyor. Aynı satırın iki kopyası gibi düşünmeyin - bu daha çok 'farklı veri kümeleri için farklı yönler' demek.

Yön 1: PostgreSQL'den ClickHouse'a

ClickHouse'un MaterializedPostgreSQL motoru tam bu iş için var. Logical replication slot'u açıyor, WAL'i okuyor ve değişiklikleri ClickHouse tarafında yansıtıyor.

CREATE DATABASE pg_live
ENGINE = MaterializedPostgreSQL('pg-host:5432', 'myapp', 'clickhouse_user', 'secret')
SETTINGS materialized_postgresql_schema = 'public';

Çalışıp çalışmadığını anlamak için:

SELECT count() FROM pg_live.orders;

PostgreSQL tarafında aynı sayıyı görüyorsanız akış kuruldu demektir. PostgreSQL'in wal_level = logical ayarını ve clickhouse_user'a REPLICATION yetkisini vermeyi unutmayın; en sık ben bu iki adımı atlanırken görüyorum.

Yön 2: ClickHouse'tan PostgreSQL'e geri yazma

Bu sefer ClickHouse'un PostgreSQL table engine'ını kullanıyoruz. Hedef tabloyu önce PostgreSQL tarafında açın:

CREATE TABLE clickhouse_reports.daily_revenue (
    report_date DATE,
    country VARCHAR(100),
    total_revenue NUMERIC(18, 4),
    order_count INTEGER,
    PRIMARY KEY (report_date, country)
);

Sonra ClickHouse tarafında aynı tabloya bir 'tutamak' tanımlıyoruz ve agregasyonun sonucunu doğrudan oraya yazıyoruz:

CREATE TABLE pg_daily_revenue
(
    report_date Date,
    country String,
    total_revenue Decimal(18, 4),
    order_count UInt32
)
ENGINE = PostgreSQL('pg-host:5432', 'myapp', 'daily_revenue', 'clickhouse_user', 'secret');

INSERT INTO pg_daily_revenue
SELECT
    toDate(created_at) AS report_date,
    customer_country AS country,
    sum(total_amount) AS total_revenue,
    count() AS order_count
FROM pg_live.orders
WHERE toDate(created_at) = yesterday()
GROUP BY report_date, country;

Uygulama tarafı bu sonuçları artık PostgreSQL'den, kendi bildiği SQL diyalektiyle okuyabiliyor. ClickHouse'un varlığından haberi olmasına gerek yok.

Replikasyon dongusunu nasıl kırarız?

İşin en kritik noktası burası. ClickHouse, az önce yazdığı clickhouse_reports.daily_revenue tablosunu logical replication ile tekrar kendine çekerse sonsuz döngüye girersiniz - en azından gereksiz veri trafiği yapar, en kötüsünde tutarlılık karışır.

Çözüm sade: ClickHouse'un yazdığı tabloları replikasyon kapsamından dışarıda bırakın. Bunu ayrı bir schema ile veya materialized_postgresql_tables_list ayarıyla yapabilirsiniz.

CREATE DATABASE pg_live
ENGINE = MaterializedPostgreSQL('pg-host:5432', 'myapp', 'clickhouse_user', 'secret')
SETTINGS
    materialized_postgresql_schema = 'public',
    materialized_postgresql_tables_list = 'orders,customers,products';

Burada clickhouse_reports schema'sı listede yok, dolayısıyla CDC akışına dahil değil. Bence ayrı schema tercih etmek daha temiz; tablo isimlerini tek tek yazmak zorunda kalmıyorsunuz, ek bir tablo açtığınızda da yanlışlıkla kapsama girmiyor.

Agregasyonu zamanlamak

Geri yazma işini elle tetiklemek istemezsiniz. Basit bir cron yeterli:

#!/bin/bash
clickhouse-client --query="
INSERT INTO pg_daily_revenue
SELECT
    toDate(created_at) AS report_date,
    customer_country AS country,
    sum(total_amount) AS total_revenue,
    count() AS order_count
FROM pg_live.orders
WHERE toDate(created_at) = yesterday()
GROUP BY report_date, country
"

Daha modern bir yaklaşım isterseniz ClickHouse'un refreshable materialized view'larına bakabilirsiniz; aynı işi motorun içinde, harici bir scheduler olmadan yapıyor.

Sık karşılaşılan tuzaklar

wal_level ayarını atlamak: PostgreSQL logical modda değilse MaterializedPostgreSQL slot açamaz. postgresql.conf değişikliği restart ister; planlayarak yapın.
Replication slot'u temizlememek: ClickHouse tarafını silmeden veritabanını DROP ederseniz PostgreSQL'de yetim slot kalır ve WAL büyümeye başlar. pg_replication_slots'u zaman zaman kontrol edin.
ClickHouse yazdığı tabloyu kapsamda bırakmak: Yukarıda anlattığımız döngü tam olarak buradan başlıyor. Ayrı schema ya da explicit tables_list şart.
Decimal hassasiyetinin kayması: Decimal(18, 4) ve NUMERIC(18, 4) aynı görünür, ama tip dönüşümleri bazen yuvarlama getirir. Geri yazma sonrası PostgreSQL tarafında birkaç sample satırı doğrulayın.

Doğrulama

Her iki yönü de hızlıca kontrol etmek için:

SELECT name, engine
FROM system.databases
WHERE engine = 'MaterializedPostgreSQL';

PostgreSQL tarafında ise:

SELECT *
FROM clickhouse_reports.daily_revenue
WHERE report_date = CURRENT_DATE - 1
LIMIT 10;

İkisinden de beklediğiniz çıktıyı alıyorsanız boru hattı ayakta demektir.

Kapanış

Bu yazıda PostgreSQL'i transactional kaynak, ClickHouse'u analitik motor olarak konumlandıran bir cift yonlu senkronizasyon desenini kurguladık. Şahsi kanaatim, bu mimari iki ucu da aynı şeyi yazmaya zorlamadığı için bakım yükü en düşük çözümlerden biri; yeter ki replikasyon kapsamını dikkatli tanımlayıp döngüye fırsat vermeyin. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

Python ile Redis: Pratik Desenler ve Tuzaklar

2026-06-14T00:00:00Z

Merhabalar, bu yazımda Python tarafında redis-py ile çalışırken aklımda bekleyen birkaç pratik konuyu derli toplu paylaşmak istiyorum. Sıfırdan Redis anlatan bir rehber değil bu; daha çok 'kodun çalışıyor ama prod'a çıkınca canını sıkacak' şeylere odaklanıyoruz. Bence en kıymetli kısım sonlardaki tuzak listesi, ama önce küçük bir ısınma turu yapalım.

redis-py ile baglanti: gorunmeyen detay

İlk satırı yazarken kimse bağlantı parametreleri üzerine düşünmüyor, bu çok normal. Ama tek bir Redis() instance'ının arka planda otomatik olarak bir connection pool taşıdığını bilmek faydalı.

import redis

r = redis.Redis(
    host='redis-cache',
    port=6379,
    db=0,
    decode_responses=True,
    socket_timeout=2,
    socket_connect_timeout=2,
)

decode_responses=True parametresi olmadan her get çağrısı bytes döner; uygulama kodunda her yerde .decode() yapmaktan kurtulmak için ben her zaman aktif tutuyorum. socket_timeout ise asıl önemli olanı; vermediğinizde Redis bir şekilde tıkandıysa çağrı sonsuza kadar bekleyebilir. İki saniye genelde yeterli, ihtiyaca göre artırırsınız.

Cache decorator: kisa ama dogru

Fonksiyon sonuçlarını cache'lemek için 10 satırlık bir decorator iş görür ama detay önemli. Şöyle yazalım:

import json
import hashlib
from functools import wraps

def cached(ttl: int = 300, prefix: str = 'fn'):
    def decorator(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            raw = f'{func.__name__}:{args}:{sorted(kwargs.items())}'
            key = f'{prefix}:{hashlib.sha1(raw.encode()).hexdigest()}'
            hit = r.get(key)
            if hit is not None:
                return json.loads(hit)
            result = func(*args, **kwargs)
            r.setex(key, ttl, json.dumps(result, default=str))
            return result
        return wrapper
    return decorator

Burada birkaç şey kasıtlı: md5 yerine sha1 (çarpışma riski daha düşük), json.dumps'a default=str (datetime gibi tipler patlatmasın), TTL'i setex ile aynı çağrıda veriyoruz (set + expire ayrı yazmak yarış durumuna sebep olabilir).

Pipeline: ag gidis donusunden tasarruf

Birden fazla komutu peşpeşe çağırıyorsanız her biri ayrı bir round-trip demek. Pipeline ile bunları tek pakette gönderirsiniz:

with r.pipeline(transaction=False) as pipe:
    for user_id in user_ids:
        pipe.hgetall(f'user:{user_id}')
    profiles = pipe.execute()

transaction=False parametresi MULTI/EXEC'i kapatır; sadece komutları batch'lemek istiyorsanız bu yeterli ve daha hızlı. Atomiklik gerekiyorsa transaction=True (varsayılan) bırakın.

Async tarafi

Async uygulama yazıyorsanız redis.asyncio arayüzü neredeyse birebir aynı. Tek fark await koymanız:

import asyncio
import redis.asyncio as aioredis

async def fetch_user(user_id: int) -> dict:
    r = aioredis.Redis(host='redis-cache', decode_responses=True)
    data = await r.hgetall(f'user:{user_id}')
    await r.aclose()
    return data

Production'da her çağrıda yeni client açmazsınız tabii; uygulama startup'ında bir tane oluşturup paylaşırsınız. Ama burada minimum örnek için böyle gösteriyorum.

Sik karsilasilan tuzaklar

KEYS * komutu: Tek thread'li Redis'te tüm anahtar tablosunu tarar, on binlerce anahtar varsa sunucuyu birkaç saniye bloke eder. Yerine SCAN cursor'ı kullanın.
TTL vermeyi unutmak: set çağrısının ex parametresi olmadan yazdığınız her anahtar ölümsüz olur. Bellek sessizce şişer, fark ettiğinizde geç olur.
json.dumps default'unu vermemek: Datetime, Decimal, UUID gibi tipler TypeError atar. default=str koymak en pratik kurtuluş.
Connection pool'u her istek başı yeniden yaratmak: Flask/FastAPI uygulamalarında her request'te redis.Redis(...) çağırırsanız her seferinde yeni TCP bağlantısı kurulur. Module seviyesinde tek instance yeter.
pickle ile cache yazmak: Bir tarafta Python 3.11, başka tarafta 3.12 olunca uyumsuzluk çıkabiliyor; ayrıca güvenlik riski de var. JSON tercih edilir.

Kapanis

Bu yazıda redis-py'nin bağlantı kurulumundan cache decorator'a, pipeline'dan async kullanıma kadar pratik desenleri özetledik. Bana sorarsanız Redis'in gücünün yarısı kütüphanenin kendisinde değil, doğru TTL ve doğru anahtar şemasında saklı; o yüzden tuzak listesini iki kere okumanızı öneriyorum. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

Python, Node.js ve Go ile ClickHouse Bağlantısı

2026-06-14T00:00:00Z

Selam, bu yazımda ClickHouse'a üç farklı dilden, yani Python, Node.js ve Go'dan nasıl bağlandığımıza bakacağız. Konuyu sıfırdan açmaktan ziyade, her dilin resmi istemcisinin üzerinde bence en çok işe yarayan kalıbı bir araya toplamak istedim. Lafı çok uzatmadan başlayayım.

ClickHouse iki ayrı protokol sunuyor: HTTP (8123) ve Native (9000). Native daha hızlı, ama dile özel sürücü istiyor. HTTP ise neredeyse her ortamla konuşur, küçük bir overhead'i göze almanız yeter. Hangisini seçersek seçelim, üçünde de ortak bazı alışkanlıklar var: bağlantıyı tek seferde kurup tekrar kullanmak, sorguları parametreyle yazmak, insert'leri toplu göndermek. Aşağıda her dilde bunu nasıl yaparız görelim.

Python ile clickhouse-connect

Resmi Python istemcisi clickhouse-connect. HTTP'yi kullanıyor ama veri transferinde optimizasyonları var.

pip install clickhouse-connect

Basit bir bağlantı ve sorgu:

import clickhouse_connect

client = clickhouse_connect.get_client(
    host='localhost',
    port=8123,
    username='default',
    password='your_password'
)

result = client.query('SELECT version()')
print(result.result_rows)

Sorgularda parametreyi mutlaka kullanın. String'i f'...' ile birleştirip atmak ileride canınızı yakar:

from datetime import datetime

result = client.query(
    'SELECT * FROM events WHERE event_type = {etype:String} AND created_at > {since:DateTime}',
    parameters={'etype': 'page_view', 'since': datetime(2026, 1, 1)}
)

Büyük sonuç kümeleri için streaming şart, yoksa Python süreci şişirilir:

with client.query_rows_stream('SELECT * FROM events') as stream:
    for row in stream:
        process_row(row)

Insert'i de bilerek toplu yapın. Tek tek satır göndermek ClickHouse için neredeyse en kötü desen:

data = [
    ['evt-1', 'page_view', 100, datetime.now()],
    ['evt-2', 'click', 101, datetime.now()],
]
client.insert('events', data, column_names=['event_id', 'event_type', 'user_id', 'created_at'])

Node.js ile @clickhouse/client

Node tarafında resmi istemci @clickhouse/client. HTTP üzerinden çalışır, hem normal hem stream sorguyu rahat handle eder.

npm install @clickhouse/client

Tipik kurulum:

const { createClient } = require('@clickhouse/client');

const client = createClient({
  url: 'http://localhost:8123',
  username: 'default',
  password: 'your_password',
  database: 'default',
  max_open_connections: 10,
});

async function getVersion() {
  const result = await client.query({
    query: 'SELECT version()',
    format: 'JSONEachRow',
  });
  console.log(await result.json());
}

Parametreli sorgu Node tarafında da aynı mantıkla:

async function queryByType(eventType) {
  const result = await client.query({
    query: 'SELECT * FROM events WHERE event_type = {etype:String} LIMIT 100',
    query_params: { etype: eventType },
    format: 'JSONEachRow',
  });
  return result.json();
}

Express içinde tek bir client örneğini uygulama ömrü boyunca paylaşın; her istek için yeni client açmayın. Kapanışta await client.close() çağırmayı unutmayın.

Insert tarafında objelerden oluşan bir dizi göndermek en pratik yol:

await client.insert({
  table: 'events',
  values: [
    { event_id: 'evt-1', event_type: 'page_view', user_id: 100 },
    { event_id: 'evt-2', event_type: 'click', user_id: 101 },
  ],
  format: 'JSONEachRow',
});

Go ile clickhouse-go v2

Go tarafında hem database/sql arayüzünü hem de native API'yi sunan tek bir paket var: clickhouse-go/v2. Bence native API'yi tercih edin, performansı gerçekten farklı.

go get github.com/ClickHouse/clickhouse-go/v2

Native bağlantı:

conn, err := clickhouse.Open(&clickhouse.Options{
    Addr: []string{"localhost:9000"},
    Auth: clickhouse.Auth{
        Database: "default",
        Username: "default",
        Password: "your_password",
    },
    DialTimeout:     10 * time.Second,
    MaxOpenConns:    10,
    MaxIdleConns:    5,
    ConnMaxLifetime: time.Hour,
})
if err != nil {
    log.Fatal(err)
}
defer conn.Close()

Yüksek hızlı insert için PrepareBatch ile gidin. Tek tek INSERT çalıştırmak ClickHouse'da herkesin yaptığı ilk hata:

batch, err := conn.PrepareBatch(ctx, "INSERT INTO events (event_id, event_type, user_id, created_at)")
if err != nil {
    return err
}
for i := 0; i < count; i++ {
    if err := batch.Append(uuid.New().String(), "page_view", uint64(i), time.Now()); err != nil {
        return err
    }
}
return batch.Send()

Sık karşılaşılan hatalar

Tek tek INSERT atmak: ClickHouse her insert'i bir part olarak yazar. Saniyede yüzlerce küçük insert atarsanız Too many parts hatasıyla tanışırsınız. Çözüm: dilinize özel batch API'sini kullanmak veya Buffer engine ile arabelleğe almak.
Bağlantıyı her istekte yeniden açmak: Web uygulamasında her request'te get_client veya createClient çağırmak istemcinin pool'unu sıfırlar. Tek bir client'ı process ömrü boyunca paylaşın.
Parametre yerine string concat: Native protokol parametreyi binary olarak gönderir, HTTP istemciler ise sunucu tarafında parse eder. Manuel concat hem hatalı tip dönüşümüne hem de injection'a kapı açar.
Timeout ayarlamamak: ClickHouse aggregate sorguları uzun sürebilir. connect_timeout, send_receive_timeout veya Go tarafında context.WithTimeout ile sınırlamak şart, yoksa deadlock'a benzeyen bekleyişlerle uğraşırsınız.

Doğrulama

Yerel ortamda Docker ile bir ClickHouse kaldırın:

docker run -d --name ch-test -p 8123:8123 -p 9000:9000 clickhouse/clickhouse-server

Sonra istediğiniz dilden basit bir SELECT version() sorgusu atın. Versiyon string'i geldiyse bağlantı tamam demektir. Insert testleri için önce küçük bir events tablosu oluşturun, sonra batch ile 10 bin satır gönderip SELECT count() FROM events ile doğrulayın.

Kapanış

Bu yazıda ClickHouse'a Python, Node.js ve Go'dan resmi istemcilerle bağlanmanın temel kalıbına baktık. Şahsi kanaatim, hangi dili kullanıyorsanız kullanın üç tane şey size hep kazandırır: client'ı bir kere açmak, sorguları parametreyle yazmak ve insert'leri toplu göndermek. Üstüne retry ve timeout'u eklediniz mi production'da rahat ediyorsunuz. Umarım faydalı olur, görüşmek üzere.

Kubernetes Dağıtımı Seçimi: Hangi Tat Hangi Ekibe Yakışır

2026-06-14T00:00:00Z

Merhaba arkadaşlar, bu yazıda Kubernetes dünyasının dağıtım (distribution) çeşitliliğine bakacağız. kubeadm'den OpenShift'e, EKS'ten K3s'e kadar onlarca seçenek var; ekipler de hangisine yaslanacaklarını tartışmakla çeyrekleri yakıyor. Lafı uzatmadan başlayalım, ama önce küçük bir uyarı: bence buradaki asıl mesele 'hangisi en iyi' değil, 'sizin ekibinize hangisi en az acı veriyor'.

Türkiye'deki ekiplerin çoğu önce managed bir bulut servisiyle tanışıyor, sonra fatura ya da uyumluluk derdi yüzünden başka kapılar çalmaya başlıyor. O kapıların ardında ne var, ona bakalım.

Dort ana tat

Kubernetes dağıtımlarını bence dört kategoride toplamak en temizi. Aşağıdaki tabloyu yanınızda tutun, çoğu tartışma şu üç soruya iniyor: Control plane'i kim yamalıyor? Network ve storage default'larını kim getiriyor? etcd hıçkırınca SLA'yı kim imzalıyor?

Tat	Örnekler	Ne vaat ediyor	Ne zaman tutar	Sizde kalan iş
Upstream / DIY	kubeadm, Talos, Kubespray	Tam kontrol, sıfır lisans	Özel network/storage ve maliyet kontrolü	Her şey: upgrade, etcd, CNI, yedek
Managed Bulut	GKE, EKS, AKS	Control plane servis olarak	Hyperscaler'da yaşıyorsanız	Worker image, addon, autoscaler
Kurumsal	OpenShift, Tanzu, RKE2	GitOps, policy, destek	Uyumluluk + çoklu cluster	Donanım/bulut faturası, app guardrail
Hafif / Edge	K3s, MicroK8s, k0s	Küçük ayak izi	<1 GB RAM, kopuk ortam	OS yaması, air-gap registry

Upstream DIY: zorlu ama ozgur

kubeadm, Talos veya Kubespray ile yapılan kurulumlar. İşletim sistemini siz seçiyorsunuz, etcd'yi siz besliyorsunuz, sertifikaları siz döndürüyorsunuz.

Bunu tercih eden ekipler genellikle şu üç şeyi istiyor: bare metal'de Ceph veya MinIO'yla ucuz storage, vendor onayı beklemeden Cilium / Calico / eBPF kullanma özgürlüğü, ve per-core lisans tax'ından kaçınma. Ama uyarayım: upgrade'ler çok adımlı (drain, kubelet rotasyonu, CRD update). Bu işi erkenden pipeline'a almazsanız her yamadan korkar hale geliyorsunuz.

Açıkçası bu yolu sadece etcd, Linux network ve storage konusunda rahat SRE'leriniz varsa seçin. Yoksa sabaha karşı 03:00'te ayakta olursunuz.

Managed bulut: en hizli baslangic

GKE, EKS, AKS, DigitalOcean Kubernetes - çoğu şirket buradan başlıyor, mantıklı da. Bulut sağlayıcı control plane'i çalıştırıyor, size SLA'lı bir API endpoint'i veriyor.

Otomatik olarak ne geliyor? Control plane yaması ve self-healing. IAM entegrasyonu (RBAC zaten kullandığınız kimliklerle eşleşiyor). Bulut-native load balancer, node pool, managed node upgrade ve autoscaler.

Aralarında küçük farklar var:

GKE: Upstream feature'lara en hızlı erişim, multi-cluster servisler.
EKS: AWS entegrasyonu derin ama worker AMI'ı hâlâ siz yönetiyorsunuz.
AKS: Node auto-upgrade en sade, Windows node desteği güçlü.

Eğer iş yükleriniz zaten RDS, Pub/Sub, S3 gibi PaaS'lara bağlıysa, network egress'i ucuza tutmak için bulut içinde kalmak en doğal seçim. İnsan gücünü cluster tesisatına değil uygulamalara harcayabiliyorsunuz. Tabii node ölçekleme, ingress controller, service mesh, gözlemlenebilirlik hâlâ size düşüyor.

Kurumsal platformlar: paragrafli yollar

OpenShift, VMware Tanzu, Rancher RKE2 gibi dağıtımlar Kubernetes'i policy, pipeline ve multi-cluster dashboard'larla sarıyor. Az kişiyle çok cluster yönetmek ya da denetim raporlarına hazır olmak isteyen ekipler için biçilmiş kaftan.

Ne kazanıyorsunuz? Hazır GitOps ve registry, FIPS-sertifikalı build'ler, admission policy, tek tıkla rolling upgrade. Ama esneklikten fedakarlık edersiniz: CNI veya CSI sürücüsünü değiştirmek istediğinizde 'sertifikalı seçenekler' dışına çıkmak zorlaşıyor. Per-core lisans maliyetleri de overprovision yaparsanız managed bulut faturasıyla yarışabilir.

Bana sorarsanız: regülasyonlu bir sektördeyseniz (banka, sigorta, sağlık) veya 30+ cluster'ı 5 kişilik platform ekibiyle yönetiyorsanız, bu kategori parasını fazlasıyla çıkarır.

Hafif ve edge dagitimlari

Fabrikaya, gemiye, perakende mağazasına Kubernetes götürdüğünüzde ağır bağımlılıklar yük olur. K3s tek binary, SQLite veya etcd backend'iyle IoT'ye ve CI runner'larına hitap ediyor. MicroK8s laptop lab'ı için ideal. k0s ve Talos Edge immutable OS + Kubernetes kombosuyla kilitli appliance'lar için tasarlanmış.

Şu durumlarda mantıklı: ağ bağlantısı güvenilmez ve workload'ları periyodik senkronluyorsunuz; donanım sınırlı (Raspberry Pi, Intel NUC) ama hâlâ declarative deploy istiyorsunuz; binlerce minik cluster'ı tek tek SRE ekibiyle değil filo yöneticisiyle yönetmek istiyorsunuz.

Tasarım notları: pull-tabanlı GitOps şart, çünkü merkezden push yapmak kopuk ortamlarda her zaman çalışmıyor. Container'ları kendi registry'nizden (Harbor, Dragonfly) senkronlamak için otomasyon kurun.

Pilot calismadan karar vermeyin

Bence en kritik adım bu. Karar masasına oturmadan önce şunları yapın:

Aynı workload'u iki tatta deneyin. Ana revenue API'nızı hem GKE'de hem bare metal kubeadm'de döndürün. Autoscaler davranışı ve on-call gürültüsü ortaya çıksın.
Control plane MTTR'ını ölçün. Vendor'a sorun: 'etcd bozulduğunda kim onarıyor, SLA ne?' DIY cluster'larda recovery runbook'unuz olmalı (snapshot frekansı, quorum restore adımları).
Bütçeyi gerçek rakamlarla yapın. Managed control plane saatlik, kurumsal dağıtımlar core başına, bare metal capex + tesis. Üçünü de aynı tabloya koyun.
Storage'ı ilk günden planlayın. Vendor CSI'sine kilitlenmemek ileride kendi donanımınıza geçtiğinizde size çok zaman kazandırır.

Sik karsilasilan tuzaklar

'En popülerini seçelim' refleksi: Topluluk büyüklüğü değil, sizin ekibinizin hangi failure mode'ları kaldırabildiği önemli. EKS yaygın diye seçip sonra IAM modeline savaş açıyorsanız yanlış kapıdasınız.
Lisansı sonra düşünmek: Per-core fiyatlandırma overprovision durumunda hızla katlanır. POC sırasında 3 node kullandığınız için sözleşme imzalayıp prod'da 30 node'a çıkınca şok yaşanır.
Edge için 'mini bulut' beklemek: K3s'i fabrikaya kurup HQ'dan push etmeye çalışmak. Pull-tabanlı GitOps'a geçmezseniz drift kaçınılmaz.
Upgrade'i sonraya bırakmak: Upstream DIY'da ilk upgrade'i otomatize etmezseniz, sonraki her yamada ekip korkudan ertelemeye başlar. CVE biriktikçe risk artar.

Hizli oneriler

Küçük ekip + tamamen AWS/GCP/Azure: Managed servisle başla, autoscaler veya Karpenter aç, kazandığın zamanı gözlemlenebilirliğe yatır.
Regülasyonlu kurum veya çok-bulutlu SRE ekibi: OpenShift veya Rancher; denetim kapıyı çaldığında destek sözleşmesi rahatlatır.
Maliyet odaklı ve donanım zaten elinizde: Upstream kubeadm veya Talos + Ceph; opex düşük, egemenlik yüksek.
Perakende, edge, IoT filosu: K3s veya MicroK8s + GitOps pull agent; manuel drift'i öldürür.

Kapanis

Doğru Kubernetes tatı, failure mode'larını anladığınız ve upgrade ritmi ekibinizin kapasitesine uyan tat. Tartışmayı vendor FUD'una değil sahiplik çizgisine çekin: kim yamalıyor, kim incident'ta nöbette, kim faturayı ödüyor? Bu üçünü netleştirdiğinizde dağıtım neredeyse kendi kendini seçiyor. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

PostgreSQL okuma replikaları ile ölçekleme rehberi

2026-06-14T00:00:00Z

Selamlar, bu yazıda PostgreSQL'de okuma replikalarını (read replica) nasıl kurduğumuza, trafiği nasıl yönlendirdiğimize ve gecikme (lag) konusunda neye dikkat ettiğimize bakacağız. Konu yazılı bilgi olarak kafa karıştırıcı durabiliyor; ben de ilk başlarda 'streaming replication mu, logical mi?' karmaşasına çok düşmüştüm. Hadi adım adım gidelim.

Bir noktada veritabanınız tek başına yetmemeye başlar. Genelde önce yazma değil, okuma yorulur: raporlar, listeler, dashboard sorguları, herkes aynı primary'i kemiriyor. Okuma replikaları tam burada işe yarıyor. Yazmaları primary'de tutuyorsunuz, okumaları birden fazla replikaya dağıtıyorsunuz, primary nefes alıyor.

Okuma replikası nedir?

Okuma replikası, primary sunucudan WAL (write-ahead log) kayıtlarını streaming yoluyla alan ve aynı veriyi salt-okunur (read only) modda servis eden bir PostgreSQL örneğidir. Bunlara teknik dilde hot standby de deniyor; çünkü ayakta dururken sorgu kabul ediyor. Yazmayı kabul etmezler, sadece SELECT çalıştırırsınız.

Mantığı kabaca şöyle: primary her commit'te WAL üretir, replikalar bu WAL'ı ağ üzerinden alıp kendi diskine uygular. Yani replika her zaman primary'nin biraz gerisindedir; bu farka 'replikasyon gecikmesi' diyoruz. Sıfır olmaz, kabul edilebilir bir aralıkta tutulur.

Primary tarafında ayar

PostgreSQL 14 ve üstü için tipik postgresql.conf ayarları aşağıdaki gibi. Bence bu kısımları kopyala-yapıştır yerine satır satır anlamak iyi olur, çünkü production'da bunları sonradan değiştirmek genelde restart gerektiriyor:

wal_level = replica
max_wal_senders = 10
max_replication_slots = 10
wal_keep_size = 1GB
hot_standby = on
hot_standby_feedback = on

Sonra replikasyon için ayrı bir kullanıcı açıyoruz. Primary kullanıcısıyla aynı şeyi yapmayın, ayrıştırın:

CREATE USER replicator WITH REPLICATION ENCRYPTED PASSWORD 'guclu_parola';
GRANT pg_read_all_data TO replicator;

pg_hba.conf içine de replika IP'lerini ekliyoruz:

host    replication     replicator      10.0.0.12/32    scram-sha-256
host    replication     replicator      10.0.0.13/32    scram-sha-256

Restart edip primary'de replication slot'larını oluşturuyoruz. Slot kullanmak şart değil ama şiddetle tavsiye ederim - replika kısa süre offline kalsa bile primary onun WAL'ını silmez:

SELECT pg_create_physical_replication_slot('replica1');

Replika kurulumu

Replika tarafında veriyi sıfırdan pg_basebackup ile çekiyoruz. Var olan data dizinini temizleyip:

sudo -u postgres pg_basebackup \
    -h primary.example.com \
    -D /var/lib/postgresql/16/main \
    -U replicator \
    -P -v -R -X stream \
    -S replica1

-R parametresi standby.signal dosyasını ve postgresql.auto.conf içine bağlantı bilgilerini otomatik yazıyor. Servisi başlattığınızda replika streaming moduna geçer:

sudo systemctl start postgresql
sudo -u postgres psql -c 'SELECT pg_is_in_recovery();'

Cevap t (true) ise iş tamam.

Trafiği yönlendirme

Burası işin uygulama tarafına dokunan yeri. Üç yol var, ben kısaca üçünü de söyleyeyim:

HAProxy / PgBouncer: 5432 yazma, 5433 okuma gibi ayrı portlar verirsiniz. Uygulama hangi havuza bağlanacağına bağlantı string'inden karar verir.
target_session_attrs: psycopg ve pg (Node.js) sürücüleri prefer-standby veya read-only modunu destekliyor. Birden fazla host yazıyorsunuz, sürücü uygun olanı seçiyor.
Uygulama düzeyinde iki havuz: writePool ve readPool diye iki ayrı bağlantı havuzu açıp INSERT/UPDATE/DELETE için birini, SELECT için diğerini kullanmak. En esnek yol bu.

Bence küçük-orta ölçekte uygulama düzeyinde ayrım en sağlıklısı. HAProxy işin altyapı tarafına ek yük getiriyor, küçük ekipler için fazla.

Replikasyon gecikmesi

Gecikmenin sıfır olmayacağını kabul edin. Önemli olan ne kadar olduğunu bilmek ve uygulamanın bunu hesaba katması.

Primary'de pg_stat_replication, replikada pg_last_xact_replay_timestamp() ile bakabilirsiniz:

SELECT
    EXTRACT(EPOCH FROM NOW() - pg_last_xact_replay_timestamp())
    AS lag_seconds;

Kullanıcının az önce yazdığı bir kaydı hemen okuması gereken senaryolar var (read-your-writes). Bu durumda son N saniye içinde yazma yaptıysa o kullanıcının okumasını primary'ye yönlendiriyoruz; aksi durumda replikadan okuyor. Basit ama hayat kurtaran bir desen.

Sık karşılaşılan tuzaklar

Replication slot vermemek: Replika 30 dakika offline kaldığında primary WAL'ı atar, replika bir daha yetişemez ve baştan kurmak zorunda kalırsınız.
Tüm okumayı replikaya yıkmak: Hesap bakiyesi gibi anlık tutarlılık isteyen sorgular replikadan okunmamalı. Listeleme, arama, dashboard - bunlar replikaya gider; kritik görüntüler primary'de kalır.
hot_standby_feedback ihmal etmek: Replikada uzun süren bir analitik sorgu varsa primary VACUUM'u onun ihtiyacı bittikten sonra yapar. Bu açıksa gecikme artar ama replikadaki sorgular canceling statement due to conflict with recovery hatası almaz.
Aynı bağlantı string'inden hem yazma hem okuma yapmak: Application kodunda iki ayrı havuz tutun; tek bir DSN ile ikisini birden hallederim demek başınızı ağrıtır.
Promosyon prosedürünü hiç test etmemek: pg_promote() çalışıyor mu, DNS değişimi nasıl olacak, uygulama yeni primary'i nasıl bulacak - bunları felaket gününde değil, bugün deneyin.

Doğrulama

Kurulumu çalıştırıp primary'de şu sorguyu atın:

SELECT client_addr, state, sent_lsn, replay_lsn,
    pg_size_pretty(pg_wal_lsn_diff(sent_lsn, replay_lsn)) AS lag
FROM pg_stat_replication;

Her replika için bir satır görmelisiniz, state sütunu streaming, lag ise birkaç kilobayt mertebesinde. Sonra primary'de bir test tablosuna INSERT atın, replikada birkaç saniye sonra SELECT ile çıkıp çıkmadığına bakın. Çıkıyorsa replikasyon canlı.

Kapanış

Bu yazıda PostgreSQL okuma replikalarını streaming replication ile nasıl kurduğumuza, trafiği nasıl ayırdığımıza ve gecikmeyle nasıl yaşadığımıza baktık. Bana sorarsanız, replika eklemek mimari olarak ucuz görünür ama operasyonel maliyeti gerçek; bu yüzden ihtiyaç gerçekten doğmadan replika atmayın, doğduğunda da slot'sız kurmayın. Umarım faydalı olur, görüşmek üzere.

Python List Comprehension ile Daha Temiz Kod

2026-06-14T00:00:00Z

Selam, bu yazımda Python'un en sevilen özelliklerinden biri olan list comprehension üzerine konuşalım. Çok yazılan, çok da yanlış yazılan bir konu; o yüzden sentaks türlerini tek tek görmekle kalmayacağız, hangi durumda doğal hangi durumda zorlama olduğunu da konuşacağız. Hadi başlayalım.

Bir for döngüsü yazıp listeye append etmek bir süre sonra göz tırmalıyor. Python'da aynı işi tek satırda yapan, hem de çoğu zaman daha hızlı çalışan bir alternatif var: list comprehension. Yapı basit, kapasitesi ise tahminden çok daha geniş.

List Comprehension Nedir?

Genel kalıbı şu şekilde: [ifade for eleman in iterable]. Soldaki ifade her elemana uygulanır, sağdaki for kısmı nereden geçtiğini söyler. Karşılaştıralım:

# Klasik dongu
kareler = []
for x in range(10):
    kareler.append(x ** 2)

# List comprehension
kareler = [x ** 2 for x in range(10)]

İki kod da [0, 1, 4, 9, 16, 25, 36, 49, 64, 81] üretir. Comprehension sürümü daha kısa, ama sadece kısa olması tek başına yeterli sebep değil. Aşağıda göreceğimiz gibi performans tarafında da net bir farkı var.

Filtreleme ve Dönüşüm

if ekleyerek elemanları filtreleriz, üçlü operatörle (x if koşul else y) şartlı dönüşüm yaparız:

sayilar = range(1, 11)

ciftler = [n for n in sayilar if n % 2 == 0]
# [2, 4, 6, 8, 10]

etiketler = ['cift' if n % 2 == 0 else 'tek' for n in sayilar]
# ['tek', 'cift', 'tek', 'cift', ...]

negatifler = [-5, 3, -1, 7]
sifirlanmis = [n if n >= 0 else 0 for n in negatifler]
# [0, 3, 0, 7]

Burada ufak bir tuzak var: if for'dan sonra geldiğinde filtre, for'dan önce geldiğinde dönüşüm koşulu. Karıştırmaya çok müsait, dikkat edin.

İç İçe Döngüler

Birden fazla for da yazılabilir. Soldan sağa okumak, iç içe yazılmış döngülere denk düştüğünü hatırlamak yeterli:

matris = [[1, 2, 3], [4, 5, 6], [7, 8, 9]]

duz = [n for satir in matris for n in satir]
# [1, 2, 3, 4, 5, 6, 7, 8, 9]

Buradan öteye, örneğin matris transpozu ya da kartezyen çarpım için de çalışır. Ama bence iki seviyeden derinleşince comprehension'ı bırakmak gerekiyor, aşağıda konuşalım.

Dict ve Set Comprehension

Aynı mantık süslü parantezle çalışır:

isimler = ['ali', 'ayse', 'mehmet']

uzunluk = {ad: len(ad) for ad in isimler}
# {'ali': 3, 'ayse': 4, 'mehmet': 6}

skorlar = {'ali': 85, 'ayse': 72, 'mehmet': 91}
gecenler = {ad: s for ad, s in skorlar.items() if s >= 75}
# {'ali': 85, 'mehmet': 91}

benzersiz = {len(w) for w in ['hello', 'world', 'hello']}
# {5}

Generator Expression: Hafıza Dostu Akrabası

Köşeli parantez yerine yuvarlak parantez kullanınca elimizde generator olur. Tüm listeyi belleğe almaz, değer üretir:

# Listeyi bellege alir, milyonlarca eleman icin agir
toplam = sum([x ** 2 for x in range(1_000_000)])

# Generator: deger deger uretir, sabit hafiza
toplam = sum(x ** 2 for x in range(1_000_000))

Büyük veri setlerinde varsayılan tercihim generator. Listeyi gerçekten saklayacaksanız comprehension, sadece bir kez gezecekseniz generator yeterli.

Performans

Comprehension, klasik for döngüsünden tipik olarak %20-40 daha hızlıdır. Sebebi sihir değil: append çağrısının her seferinde method lookup yapmaması, döngünün C seviyesinde dönmesi ve uygun durumda boyutun önceden ayrılması. Yine de mikro-optimizasyon uğruna kodu okunmaz hale getirmeyin; comprehension'ın asıl kazanımı okunabilirlik.

Sık Karşılaşılan Hatalar

Aşırı iç içe yazma: İki seviyeden fazla for ya da iki koşulu olan dev bir comprehension kimsenin keyifle okuduğu kod değildir. Böyle bir noktaya geldiyseniz döngü yazın, kimse üzülmez.
Yan etki üretmek: [print(x) for x in items] çalışır ama gereksiz bir liste üretir ve niyeti gizler. Yan etki istiyorsanız for döngüsü kullanın, comprehension değer üretmek içindir.
Exception yakalamak: Comprehension içinde try/except yazamazsınız. Hata olabilecek dönüşümlerde (int(x) gibi) klasik döngüye geçin, validasyonu açıkça yapın.
Walrus'i unutmak: Tekrar eden bir hesap varsa := operatörü ile bir kere hesaplayıp yeniden kullanmak okunabilirliği artırır, performansa da yarar. Sık kullanılmıyor ama uygun yerde altın değerinde.
Generator'i iki kez gezmek: Generator bir kez tükenir. İkinci list(gen) çağrısı boş liste döner. Tekrar gerekiyorsa ya tee ile çoğaltın ya da listeye alın.

Kapanış

Şahsi kanaatim, list comprehension Python'un karakter özelliklerinden biri ve doğru yerde kullanıldığında kodun kalitesini gerçekten artırıyor. Ama her şeyi tek satıra sığdırmak gibi bir hedef varsa iş tersine dönüyor; o yüzden iki seviyeden derin gidince ya da yan etki gerekince döngüye dönmek doğru tercih. Umarım faydalı olur, görüşmek üzere.

Python'da JSON Dosyalarını Okumak ve Yazmak

2026-06-13T00:00:00Z

Selamlar, bu yazımda Python'da JSON dosyalarıyla nasıl çalıştığımıza biraz farklı bir açıdan bakacağız. Konuyu en baştan anlatmaya çalışmayacağım; bunun yerine her geliştirici bir şekilde takılır deyip geçtiğim tuzaklara ve json modülünün gerçekten işine yarayan parçalarına odaklanacağım. Lafı uzatmadan başlayayım.

JSON (JavaScript Object Notation) artık veri taşımanın ortak dili gibi. API yanıtlarını parse ederken, konfigürasyon tutarken, hatta küçük bir veri deposu olarak bile karşımıza sürekli çıkıyor. Python tarafında işin güzel yanı, JSON'un yapısı dict ve list'e neredeyse bire bir oturuyor. Yani başka bir kütüphaneye ihtiyacımız yok; standart kütüphanedeki json modülü çoğu durumda yeter.

json modülünün dört kapısı

json modülünü ilk öğrenirken çoğumuzu kafa karıştıran şey, dört tane benzer isimli fonksiyonun olması: load, loads, dump, dumps. Aslında işin mantığı çok basit: sondaki s 'string' anlamına geliyor. Yani loads string'den okur, load ise dosyadan. Aynı şekilde dumps string'e yazar, dump dosyaya. Karıştırırsanız da Python size güzelce hata verir, korkmayın.

import json

# Dosyadan oku
with open('config.json', 'r', encoding='utf-8') as file:
    data = json.load(file)

# String'den oku
raw = '{"name": "Ayşe", "active": true}'
parsed = json.loads(raw)
print(parsed['active'])  # True (Python boolean'una donustu)

Buradaki kritik nokta: JSON'daki true/false/null değerleri Python'da otomatik olarak True/False/None'a dönüşüyor. Bu küçük detay, özellikle API yanıtlarını işlerken düşülen çukurların başında geliyor.

Yazarken biraz nezaket: indent ve ensure_ascii

Bir dict'i json.dump ile yazdığınızda varsayılan olarak tek satırlık, sıkıştırılmış bir çıktı alırsınız. Bu, makineler için iyi; ama git diff'te gördüğünüzde gözünüzü kanatır. İnsanın da okuyacağı dosyalar için indent parametresini ekleyin:

import json

user = {
    'isim': 'Ayşe',
    'roller': ['admin', 'editor'],
    'ayarlar': {'tema': 'koyu'}
}

with open('user.json', 'w', encoding='utf-8') as file:
    json.dump(user, file, indent=2, ensure_ascii=False)

ensure_ascii=False çoğu kişinin atladığı bir parametre. Varsayılan True olduğu için Türkçe karakterleriniz ç gibi escape edilmiş hâlde dosyaya yazılır. Çalışır, evet, ama dosyayı bir editörde açtığınızda ne olduğunu anlamak imkansız hâle gelir. Bence Türkçe içerikle uğraşıyorsanız bu parametreyi neredeyse her zaman False yapın.

Hatalari ciddiye almak

İki tip hatayla sık karşılaşırsınız: dosya yok ya da içeriği bozuk. Birincisi FileNotFoundError, ikincisi json.JSONDecodeError. Üretim kodunda ikisini de yakalamadan geçmeyin:

import json
from pathlib import Path

def load_config(filepath: str) -> dict:
    path = Path(filepath)
    if not path.exists():
        return {}

    try:
        with open(path, 'r', encoding='utf-8') as file:
            content = file.read()
            if not content.strip():
                return {}
            return json.loads(content)
    except json.JSONDecodeError as exc:
        print(f'Bozuk JSON {filepath}: satir {exc.lineno}, sutun {exc.colno}')
        return {}

JSONDecodeError'ün üzerinde durmak istiyorum çünkü hata mesajı gerçekten yardımcıdır. exc.lineno ve exc.colno size bozuk yerin satır-sütun bilgisini verir. Bir keresinde 200 satırlık config'in 137. satırındaki sondaki virgülü bulmak için tam beş dakika harcamıştım, sonra fark ettim ki istisna nesnesi zaten söylüyormuş.

datetime gibi yabancilar

JSON tipi olarak sadece string, sayı, boolean, null, dizi ve nesne anlar. datetime yok. Bu yüzden bir datetime'ı dump etmeye kalkarsanız TypeError yer:

import json
from datetime import datetime

class IsoDatetimeEncoder(json.JSONEncoder):
    def default(self, obj):
        if isinstance(obj, datetime):
            return obj.isoformat()
        return super().default(obj)

event = {'isim': 'Konferans', 'tarih': datetime.now()}
print(json.dumps(event, cls=IsoDatetimeEncoder, ensure_ascii=False))

ISO format tercih etmemin sebebi standart olması ve datetime.fromisoformat ile geri okumanın kolay olması. Şahsi tercihim, datetime alanlarını her zaman bu şekilde tutmak; epoch saniye saklayanlar olur, anlarım, ama bir dosyayı bir yıl sonra açıp 1735689600 görmek pek hoş bir deneyim değil.

Buyuk dosyalar icin streaming

Dosya gigabyte boyutlarına ulaşıyorsa json.load her şeyi belleğe yükler ve makineniz inler. Bu noktada ijson kütüphanesi devreye girer:

import ijson

with open('users.json', 'rb') as file:
    for user in ijson.items(file, 'users.item'):
        print(user['name'])

Alternatif olarak veriyi her satırda bir JSON nesnesi olacak şekilde JSON Lines (jsonl) formatında saklayabilirsiniz. Log dosyaları için ideal: append etmek O(1), okurken for line in file ile satır satır gidersiniz, hafıza problemi yok.

Sik karsilasilan tuzaklar

encoding='utf-8' yazmamak: Linux'ta sorun çıkarmaz; Windows'ta Türkçe karakterler bozuk gelebilir, dosya yazarken sistem kodlamasıyla yazılır. Açık yazın, bağımlılığı kapatın.
ensure_ascii varsayılanını unutmak: Türkçe içerikli dosyalarınızda ç görüyorsanız sebebi budur. ensure_ascii=False çözer.
eval() ile parse etmek: İnternette eski kod örneklerinde görebilirsiniz. Yapmayın. Güvenilmez kaynaklı string kod yürütür. json.loads her zaman güvenli.
JSON'da yorum beklemek: JSON spec'inde yorum yok. // comment yazılı bir dosyayı json.loads reddeder. Konfigürasyon için yorum lazımsa YAML, TOML ya da JSON5 düşünün.
Sondaki virgul: {"a": 1,} geçerli JSON değildir, JavaScript objesi gibi davranır diye varsaymayın.

Kapanis

Python'un json modülü gündelik işleri rahatça halleder; ihtiyacınızın yüzde doksanına yeter. Bence kritik nokta dört fonksiyonu (load/loads/dump/dumps) net ayırt etmek, encoding ile ensure_ascii parametrelerini bilinçli kullanmak ve datetime gibi tipleri bir custom encoder ile evcilleştirmek. Performans gerçekten dert olduğunda orjson veya ujson'a bakabilirsiniz, ama o noktaya gelene kadar standart kütüphane sizi yormayacaktır. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

Terratest ile GCP Terraform Modullerini Gercekten Test Etmek

2026-06-13T00:00:00Z

Selamlar, bu yazimda Terraform modullerinizi Terratest ile nasil ciddi anlamda test edersiniz, ona bakacagiz. Konuyu sevenlerden biriyim cunku 'plan tertemiz, apply patladi' hikayesi insanin uretimde gormesi gereken son sey. Hadi baslayalim.

Test yazmadan modul yayinlamak, testsiz uygulama kodu yazmak gibi: bir gun calismayi durduruyor ve genelde o gun production'da. Terratest, bu noktada devreye giren bir Go kutuphanesi (library). Mock ile is yapmiyor; gercek GCP kaynaklarini kaldiriyor, kontrolleri calistiriyor, sonra hepsini yikiyor. Yavas mi? Evet. Ama static analysis'in yakalayamadigi seyleri yakaliyor.

Terratest neden?

Terraform tarafinda birkac test araci var. Terratest'i one cikaran sey su:

Gercek altyapi - Mock degil, gercek kaynak. Ne deploy ediyorsaniz onu test ediyorsunuz.
Programlama dili - HCL'in dar kalibinda kalmiyorsunuz; Go ile istediginiz assertion'i yazabiliyorsunuz.
Retry mantigi - Eventual consistency icin hazir helper'lar var.
HTTP yardimcilari - Olusturdugunuz endpoint'i test etmek icin kullanissiz.
Paralel calisma - Testler eszamanli kosabiliyor, isim catismasini random.UniqueId() cozuyor.

Bence en buyuk avantaji, 'gercekten ne oluyor?' sorusuna cevap vermesi. Plan ciktisina guvenmek bir noktada yetmiyor; Cloud Run servisi gerekirken paylasilan bir VPC connector'a yanlis CIDR vermissiniz, plan bunu fark etmiyor, ama uygulama acilmiyor.

Iskelet kurmak

Modulun yanina bir test klasoru aciyoruz:

modules/
  cloud-run/
    main.tf
    variables.tf
    outputs.tf
    test/
      cloud_run_test.go
      go.mod
      go.sum

Sonra Go modulunu baslatip gerekli paketleri cekiyoruz:

cd modules/cloud-run/test
go mod init test
go get github.com/gruntwork-io/terratest/modules/terraform
go get github.com/gruntwork-io/terratest/modules/gcp
go get github.com/gruntwork-io/terratest/modules/http-helper
go get github.com/stretchr/testify/assert

Buraya kadar her sey hazirlik. Asil is, Go testinde basliyor.

Cloud Run modulu icin gercek bir test

Hadi bir ornek gorelim. Asagidaki test, cloud-run modulunu apply ediyor, output'lari topluyor ve servisin gerekten 200 dondurdugunu retry'li bir HTTP cagrisiyla dogruluyor:

package test

import (
    "fmt"
    "os"
    "strings"
    "testing"
    "time"

    httpHelper "github.com/gruntwork-io/terratest/modules/http-helper"
    "github.com/gruntwork-io/terratest/modules/random"
    "github.com/gruntwork-io/terratest/modules/terraform"
    "github.com/stretchr/testify/assert"
)

func TestCloudRunServiceCreation(t *testing.T) {
    t.Parallel()

    uniqueID := random.UniqueId()
    serviceName := fmt.Sprintf("test-service-%s", strings.ToLower(uniqueID))
    projectID := os.Getenv("GCP_PROJECT_ID")

    opts := terraform.WithDefaultRetryableErrors(t, &terraform.Options{
        TerraformDir: "../",
        Vars: map[string]interface{}{
            "project_id":            projectID,
            "region":                "us-central1",
            "service_name":          serviceName,
            "image":                 "gcr.io/cloudrun/hello",
            "port":                  8080,
            "allow_unauthenticated": true,
        },
        NoColor: true,
    })

    defer terraform.Destroy(t, opts)
    terraform.InitAndApply(t, opts)

    serviceURL := terraform.Output(t, opts, "service_url")
    assert.NotEmpty(t, serviceURL)

    httpHelper.HttpGetWithRetryWithCustomValidation(
        t, serviceURL, nil, 30, 10*time.Second,
        func(status int, body string) bool { return status == 200 },
    )
}

Buradaki kritik nokta defer terraform.Destroy. Test ortada patlasa bile bu satir cagriliyor; yani t.Fatal ile dussek de kaynaklar yikiliyor. Bunu unutursaniz GCP fatura ekraninda hosgelmeyen bir surpriz oluyor.

HttpGetWithRetryWithCustomValidation da onemli: Cloud Run apply'dan hemen sonra hazir olmuyor, bir-iki saniye lazim. 30 deneme ve 10 saniyelik aralik benim icin makul; siz kendi ortaminiza gore ayarlayin.

Hizli testler: validate ve plan

Her test gercek kaynak yaratmasin. Validate ve plan testleri, modulu deploy etmeden konfigurasyonu kontrol ediyor:

func TestTerraformValidate(t *testing.T) {
    t.Parallel()

    opts := &terraform.Options{
        TerraformDir: "../",
        Vars: map[string]interface{}{
            "project_id":   "test-project",
            "service_name": "test-service",
            "image":        "gcr.io/test/image:latest",
        },
    }

    terraform.Init(t, opts)
    terraform.Validate(t, opts)
}

Bunlari -short flag'i ile koruyup go test -short calistirdiginizda saniyeler icinde bitiyor. CI'da pre-commit niteligindeki bir sasama cizgisi olarak iyi is goruyor; gercek deploy'lu testleri gece veya manuel tetikle birakirsiniz.

Sik karsilasilan tuzaklar

Tek bir GCP projesi kullanmak: Production projesinde test calistirmayin. Adi 'test' olan ayri bir proje acin, IAM'ini sikilastirin. Bir keresinde firma icinde 'sadece staging-like ortam' diye paylasilan bir projede testler patlatildi, manuel cleanup yapan ekip iki saatini verdi.
Destroy'u defer'lememek: terraform.InitAndApply'dan sonra defer terraform.Destroy yazmazsaniz panic olusursa kaynak orada kaliyor. Buna ek olarak periyodik cleanup script'i sart - Terratest %100 idempotent degil; iptal edilen test'ten kalan artiklari haftalik bir job temizlesin.
Sabit isim kullanmak: Iki test ayni isimde Cloud Run servisi yaratmaya calisinca biri 409 alir. random.UniqueId() zaten cozuyor, kullanmamak icin sebep yok.
Timeout'u kucuk tutmak: GKE Autopilot cluster'i 10-15 dakika alabiliyor. go test -timeout 30m minimum; varsayilan 10 dakika cluster testlerinde ortada keser.
Maliyeti gormezden gelmek: Bu testler para harciyor. Her local kayitta kosturmayin; CI'da nightly veya PR-uzerine sinirli kosun.

Dogrulama

Lokalde calistirip dogrulamak icin:

cd modules/cloud-run/test
GCP_PROJECT_ID=my-test-project go test -v -timeout 30m

Sadece hizli testleri calistirmak isterseniz:

go test -v -short -timeout 5m

Ciktida PASS ve --- PASS: TestCloudRunServiceCreation satirini goruyorsaniz, hem apply hem assertion hem de destroy bitmis demektir.

Kapanis

Bu yazida Terratest ile GCP Terraform modullerini gercek kaynak yaratip yikan entegrasyon testlerine baktik. Sahsi kanaatim, validate testleri her zaman, integration testleri ise haftalik nightly veya release oncesi calismali; her commit'te tum suite'i acmak hem yavas hem pahaliya patliyor. Umarim faydali olur, gorusmek uzere.

ClickHouse Bitmap Aralıklarını bitmapMin ve bitmapMax ile Bulmak

2026-06-13T00:00:00Z

Selam, bu yazımda ClickHouse'un az konuşulan ama segment ve kohort analizinde işi gerçekten kolaylaştıran iki fonksiyonuna, bitmapMin() ve bitmapMax(), yakından bakacağız. Roaring bitmap'lerle ilk tanışan arkadaşlar için biraz bağlam vereceğim, sonra doğrudan örneklere geçeceğim. Hadi başlayalım.

ClickHouse'da roaring bitmap, bir sürü UInt32 ya da UInt64 değerini sıkıştırılmış biçimde tutmanın çok ucuz bir yolu. Milyonlarca kullanıcı kimliğini bir satırın bir hücresinde tutabiliyorsunuz, üstelik birleşim, kesişim, fark gibi küme operasyonları neredeyse bedava. Ben ilk başlarda 'tamam, kümeyi koyduk, ama bu kümeden minimum ve maksimum değeri nasıl alacağız?' diye uzun süre dokümantasyona bakmıştım. Cevap aslında çok basit: bitmapMin() ve bitmapMax().

bitmapMin ve bitmapMax nedir?

İki fonksiyon da tek iş yapar: bitmap'in içindeki en küçük ve en büyük tamsayıyı döndürür. Karşılığı kabaca şöyle:

SELECT
    bitmapMin(bitmapBuild([3, 7, 1, 42, 15])) AS min_val,
    bitmapMax(bitmapBuild([3, 7, 1, 42, 15])) AS max_val;

Çıktı:

min_val | max_val
--------+--------
1       | 42

Yani MIN() ve MAX() gibi düşünebilirsiniz, ama Array ya da satır kümeleri yerine bitmap üzerinde çalışıyor. Aradaki performans farkı da küçümsenecek gibi değil; bitmap üzerinde min/max O(1) civarı.

Segmentin en eski ve en yeni kullanıcısı

Kullanıcı kimlikleri monoton artıyorsa (auto-increment ya da Snowflake ID gibi), bitmapMin() size segmentin en eski üyesini, bitmapMax() ise en yeni üyesini verir. Şahsi kanaatim, bu sorgu kohort dashboard'larının %80'inde işe yarıyor:

SELECT
    segment_name,
    bitmapMin(user_bitmap) AS oldest_user_id,
    bitmapMax(user_bitmap) AS newest_user_id,
    bitmapCardinality(user_bitmap) AS segment_size
FROM user_segments
GROUP BY segment_name;

Tek tablo taraması, üç toplulaştırma. JOIN yok.

Oturum içi olay aralığı

Her oturuma ait olay sıra numaralarını bir bitmap'te tutuyorsanız, ilk ve son olayı tek seferde çekebilirsiniz. Aşağıdaki sorgu en uzun olay aralığına sahip on oturumu sıralar:

SELECT
    session_id,
    bitmapMin(event_seq_bitmap) AS first_event_seq,
    bitmapMax(event_seq_bitmap) AS last_event_seq,
    bitmapMax(event_seq_bitmap) - bitmapMin(event_seq_bitmap) AS sequence_span
FROM session_events
GROUP BY session_id
ORDER BY sequence_span DESC
LIMIT 10;

sequence_span değeri olay sayısı değil, ilk ve son olay arasındaki numara farkı. İkisinin arasındaki uçurum büyükse oturumun bazı olayları atlamış olduğunu (ya da numaralandırma boşluk bıraktığını) anlarsınız.

Seyrek kohortları bulmak

Bir kohort 100 milyon ile 100 milyon 50 bin arasında 50 bin kullanıcıyı tutuyorsa, kimlik aralığı dar; toplulaşmış. Aynı 50 bin kullanıcı 1 milyon ile 100 milyon arasına dağılmışsa kohort seyrek. bitmapMin/Max ile bitmapCardinality() arasındaki oranı kullanarak doluluk yüzdesini çıkarmak çok kolay:

SELECT
    cohort_id,
    bitmapMin(user_bitmap)                              AS min_uid,
    bitmapMax(user_bitmap)                              AS max_uid,
    bitmapMax(user_bitmap) - bitmapMin(user_bitmap) + 1 AS id_range,
    bitmapCardinality(user_bitmap)                      AS actual_count,
    round(
        100.0 * bitmapCardinality(user_bitmap)
              / (bitmapMax(user_bitmap) - bitmapMin(user_bitmap) + 1),
        1
    ) AS fill_pct
FROM cohorts;

Düşük fill_pct seyrek kohortu işaret eder. Pazarlama tarafında 'aynı kohort ama hangileri yeni katılım, hangileri eski' tartışmasını bu tek sorgu çözüyor.

groupBitmap toplulastirmasi ile birlikte

Birden fazla satırın bitmap'ini birleştirip min/max almak istiyorsanız, groupBitmapState ile zincirlemek doğal:

SELECT
    toDate(event_date)                      AS date,
    bitmapMin(groupBitmapState(user_id))    AS min_uid_active,
    bitmapMax(groupBitmapState(user_id))    AS max_uid_active
FROM daily_active_users
GROUP BY date
ORDER BY date DESC;

Burada günlük olarak aktif olan kullanıcıların kimlik aralığını çıkarıyoruz. ClickHouse bitmap'leri arka planda birleştirir, sonra üzerine min/max uygular.

Sık karşılaşılan tuzaklar

Boş bitmap'i unutmak: Boş bir bitmap'e bitmapMin() çağırdığınızda 4294967295 (UINT32_MAX), bitmapMax() çağırdığınızda ise 0 döner. Sorguya bu sayıyı geçerli bir kullanıcı kimliği gibi yansıtırsanız dashboard'unuz tuhaf görünür. Her zaman önce bitmapCardinality(b) > 0 kontrolü yapın.
UInt64 ve UInt32 karışımı: Bitmap'i UInt64 değerlerle kurduysanız boş durumda bitmapMin() UINT64_MAX döner. İki bitmap'i birleştirirken tipler tutmuyorsa beklemediğiniz cast hataları alırsınız.
bitmapMax - bitmapMin ile aralığı sayı zannetmek: Aralık iki ucu kapsadığı için doğru formül bitmapMax - bitmapMin + 1. Bunu yazmadığınız zaman %1 - %2 oranında küçük bir sapma yaşarsınız; küçük gibi görünür, ama eşik değerlerinde ciddi farklar yaratır.
Filtre uygulamadan tüm bitmap'i kaldırmak: Çok büyük bitmap'lerde min/max ucuz olsa da, gereksiz bitmapBuild çağrısı pahalı. Mümkünse bitmap'i AggregatingMergeTree ya da materialize edilmiş bir kolonda hazır tutun.

Kapanış

Bu yazıda ClickHouse'un bitmapMin() ve bitmapMax() fonksiyonlarını segment, kohort ve oturum analizi için nasıl kullanacağımıza baktık. Bana sorarsanız, kullanıcı kimliklerini bitmap'te tutuyorsanız bu iki fonksiyon olmadan analizi tamamlamak çok zor; toplam kardinalite ile birleştirince elinize hem 'kim' hem 'ne kadar yayılmış' bilgisi geçiyor. Umarım faydalı olur, görüşmek üzere.

MySQL JSON_REPLACE ile Güvenli Alan Güncelleme

2026-06-13T00:00:00Z

Selamlar, bu yazımda MySQL'in JSON_REPLACE() fonksiyonu üzerinde duracağız. JSON kolonlarıyla çalışmaya başladığınızda er ya da geç karşınıza çıkan bir ihtiyaç var: 'sadece var olan alanı güncelle, yeni alan ekleme'. JSON_SET() her şeyi yapar gibi durur ama bazen tam da bunu istemezsiniz. Hadi farkları somutlaştıralım.

JSON_REPLACE Nedir?

JSON_REPLACE(), bir JSON dokümanı içindeki var olan path'in değerini güncelleyen bir fonksiyon. Yani path zaten dokümanda yoksa, fonksiyon herhangi bir şey eklemez; dokümanı olduğu gibi geri verir. Bu davranış kulağa kısıtlayıcı gelebilir, ama bence işin güzel tarafı bu. Şemasız bir alanda kazara yeni anahtar yaratmak, ileride 'bu alan nereden geldi?' diye uzun uzun loglara bakmaya neden oluyor.

Söz dizimi sade:

JSON_REPLACE(json_doc, path, val [, path, val] ...)

Birden fazla path-değer çiftini aynı çağrıda geçebilirsiniz. Eğer json_doc veya path'lerden biri NULL ise sonuç da NULL olur, dikkat edin.

Basit Örnekler

Önce kuru kuru birkaç örnek görelim:

-- Var olan bir alani guncelle
SELECT JSON_REPLACE('{"ad":"Ayse","yas":25}', '$.yas', 30);
-- Sonuc: {"ad": "Ayse", "yas": 30}

-- Path yok: dokuman degismez
SELECT JSON_REPLACE('{"ad":"Ayse"}', '$.yas', 30);
-- Sonuc: {"ad": "Ayse"}  (yas EKLENMEDI)

-- Birden fazla alani tek seferde guncelle
SELECT JSON_REPLACE('{"ad":"Ayse","yas":25,"sehir":"Izmir"}',
  '$.yas', 30, '$.sehir', 'Ankara');
-- Sonuc: {"ad": "Ayse", "yas": 30, "sehir": "Ankara"}

-- Ic ice degeri guncelle
SELECT JSON_REPLACE('{"kullanici":{"ad":"Ayse","yas":25}}',
  '$.kullanici.yas', 30);

Buradaki kritik nokta şu: ikinci sorguda $.yas path'i mevcut değil, dolayısıyla doküman değişmeden geliyor. JSON_SET() olsaydı yas: 30 olarak eklenecekti.

JSON_REPLACE, JSON_SET ve JSON_INSERT Farkı

Üç fonksiyon birbirine benzer, ama davranışları üç farklı niyete denk düşer. Aynı dokümana üçünü uygulayalım:

SET @doc = '{"ad":"Ayse","yas":25}';

-- JSON_REPLACE: var olani gunceller, eksigi gormezden gelir
SELECT JSON_REPLACE(@doc, '$.yas', 30, '$.sehir', 'Ankara');
-- {"ad": "Ayse", "yas": 30}   sehir EKLENMEDI

-- JSON_SET: var olani gunceller, eksigi ekler (upsert)
SELECT JSON_SET(@doc, '$.yas', 30, '$.sehir', 'Ankara');
-- {"ad": "Ayse", "yas": 30, "sehir": "Ankara"}

-- JSON_INSERT: sadece eksigi ekler, var olana dokunmaz
SELECT JSON_INSERT(@doc, '$.yas', 30, '$.sehir', 'Ankara');
-- {"ad": "Ayse", "yas": 25, "sehir": "Ankara"}   yas DEGISMEDI

Şahsi kanaatim, çoğu update senaryosunda JSON_SET() 'genel amaçlı' diye seçiliyor ama asıl güvenli olan JSON_REPLACE(). Çünkü kodda yazım hatasıyla '$.statu' yerine '$.status' yazıp bir gün milyonlarca satırınıza sessizce yeni bir alan açmış olmazsınız.

Tablo Üzerinde Pratik Kullanım

Şimdi gerçek bir senaryo. Diyelim ki bir urunler tablomuz var, JSON kolonu içinde marka, RAM, depolama gibi öznitelikler tutuluyor:

CREATE TABLE urunler (
  id INT AUTO_INCREMENT PRIMARY KEY,
  ad VARCHAR(100),
  ozellikler JSON
);

INSERT INTO urunler (ad, ozellikler) VALUES
('Laptop', '{"marka":"Dell","ram":16,"depolama":512}'),
('Telefon', '{"marka":"Apple","ram":8,"depolama":256}');

-- Tum Dell urunlerinin depolamasini 1024 yap
UPDATE urunler
SET ozellikler = JSON_REPLACE(ozellikler, '$.depolama', 1024)
WHERE JSON_UNQUOTE(JSON_EXTRACT(ozellikler, '$.marka')) = 'Dell';

Burada bilinçli tercih: bazı kayıtlarda depolama alanı eksik olabilir, biz JSON_REPLACE() kullandığımız için onlara yanlışlıkla yeni alan eklemiyoruz. JSON_SET() kullansaydık eksiklerin hepsi 1024 ile dolardı, ki bu büyük ihtimalle istemediğimiz bir 'shadow migration' olurdu.

Koşullu Güncelleme

JSON_REPLACE()'i WHERE ile birleştirip 'optimistic update' tarzı bir akış da kurabilirsiniz:

-- Sadece su an 'aktif' olan urunu 'pasif' yap
UPDATE urunler
SET ozellikler = JSON_REPLACE(ozellikler, '$.durum', 'pasif')
WHERE id = 5
  AND JSON_UNQUOTE(JSON_EXTRACT(ozellikler, '$.durum')) = 'aktif';

Eğer kayıt zaten 'pasif'se güncelleme satır etkilemez. Bunu uygulamada kontrol edip 'beklediğim durumdan farklıydı' diye dönebilirsiniz.

Sık Karşılaşılan Hatalar

JSON_SET ile karıştırmak: Klavyenizden JSON_SET daha kolay çıkıyor diye refleksle yazıp yeni anahtarlar yaratıyorsunuz. Kod review sırasında bu farkı özellikle gözden geçirin.
NULL path tuzağı: Path argümanı NULL olursa fonksiyon doğrudan NULL döner ve UPDATE ifadesinde tüm JSON kolonu NULL olabilir. Path'leri sabit string olarak yazın ya da COALESCE() ile koruyun.
String tırnak'ı yanlış kaçırmak: JSON_REPLACE(@doc, '$.ad', "Ayse") MySQL ayarınıza göre "Ayse" bir kolon adı sanılabilir. Tek tırnak kullanın.
JSON_EXTRACT ile karşılaştırmada JSON_UNQUOTE unutmak: JSON_EXTRACT(...) = 'Dell' çalışmaz; çünkü extract sonucu "Dell" olur, tırnaklarla. JSON_UNQUOTE() ile sarın.

Kapanış

JSON_REPLACE(), MySQL'in JSON araç kutusundaki en sade ama en disiplinli üyelerinden biri. Bana sorarsanız, JSON kolonlarına yazarken varsayılan tercihiniz bu olmalı; JSON_SET() sadece gerçekten upsert davranışı istediğiniz yerlerde devreye girsin. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

OpenTofu'da iç içe dynamic bloklar: karmaşık kaynakları evcilleştirmek

2026-06-13T00:00:00Z

Selamlar, bu yazımda OpenTofu (eski adıyla Terraform tarafının topluluk fork'u) içindeki iç içe dynamic blokları konuşacağız. Konu özünde basit ama insanı belaya sokmakta üstüne yok: bir kaynağın içinde başka bir blok, onun içinde başka bir blok... Ve siz statik HCL ile bunu tek tek yazmaya kalkarsanız, hem dosya şişer hem de değişiklik geldiğinde elinizde bir tomar tekrar kalır.

Hadi lafı çok uzatmadan dalalım.

Dynamic blok nedir, ne işe yarar?

OpenTofu kaynakları çoğunlukla iki şeyden oluşur: argümanlar (name = "...") ve bloklar (tags { ... }, lifecycle { ... } gibi). Bloklar genellikle birden fazla kez tekrarlanabilir. Mesela bir IAM policy'nin birden fazla statement'ı, bir ECS service'in birden fazla placement_strategy'si olabilir.

dynamic bloğu, bir bloğu veriden türetmenizi sağlar. Yani 'şu listedeki her eleman için bir tane bu bloktan üret' diyorsunuz, OpenTofu da onu açıyor. Listeniz boşsa hiç blok üretilmiyor; üç eleman varsa üç tane.

İç içe dynamic ise tam tahmin ettiğiniz şey: blok içinde blok. IAM statement içinde condition, Kubernetes container içinde port ve env gibi.

IAM policy: statement içinde condition

Klasik örnekle başlayalım. AWS IAM policy'si yazıyoruz, her statement'ın istediği kadar koşulu olsun istiyoruz.

variable "policy_statements" {
  type = list(object({
    sid       = string
    effect    = string
    actions   = list(string)
    resources = list(string)
    conditions = list(object({
      test     = string
      variable = string
      values   = list(string)
    }))
  }))
}

data "aws_iam_policy_document" "policy" {
  dynamic "statement" {
    for_each = var.policy_statements
    content {
      sid       = statement.value.sid
      effect    = statement.value.effect
      actions   = statement.value.actions
      resources = statement.value.resources

      dynamic "condition" {
        for_each = statement.value.conditions
        content {
          test     = condition.value.test
          variable = condition.value.variable
          values   = condition.value.values
        }
      }
    }
  }
}

Dış dynamic her statement için bir blok açıyor; iç dynamic ise o statement'ın conditions listesini gezerek alt blokları üretiyor. Şahsi kanaatim, bu yapı var.policy_statements listesini bir JSON dosyasından okuduğunuzda asıl meyvesini veriyor: HCL dosyaları sade kalıyor, veri ayrı duruyor.

ECS service: birden fazla placement stratejisi

ECS tarafında da benzer hikaye. Service'in ordered_placement_strategy ve placement_constraints blokları sıfırdan N'e kadar olabiliyor.

variable "placement_strategies" {
  type = list(object({
    type  = string
    field = string
  }))
  default = [
    { type = "spread",  field = "attribute:ecs.availability-zone" },
    { type = "binpack", field = "cpu" }
  ]
}

resource "aws_ecs_service" "app" {
  name            = var.service_name
  cluster         = var.cluster_arn
  task_definition = var.task_definition_arn
  desired_count   = var.desired_count

  dynamic "ordered_placement_strategy" {
    for_each = var.placement_strategies
    content {
      type  = ordered_placement_strategy.value.type
      field = ordered_placement_strategy.value.field
    }
  }
}

Burada iç içe değil, sadece düz dynamic var; ama gerçek hayatta placement_constraints ile birlikte kullanılınca aynı kaynakta birden fazla dynamic görüyorsunuz - bu da hızla okunmaz hale gelebiliyor.

Kubernetes deployment: container içinde port ve env

Belki de en sık karşılaştığım örnek. Bir deployment'ta birden fazla container, her container'ın kendi port ve env listesi olsun istiyoruz.

resource "kubernetes_deployment" "app" {
  spec {
    template {
      spec {
        dynamic "container" {
          for_each = var.containers
          content {
            name  = container.value.name
            image = container.value.image

            dynamic "port" {
              for_each = container.value.ports
              content {
                container_port = port.value.container_port
                protocol       = port.value.protocol
              }
            }

            dynamic "env" {
              for_each = container.value.env
              content {
                name  = env.value.name
                value = env.value.value
              }
            }
          }
        }
      }
    }
  }
}

Üç katmanlı bir veri modelini iki katmanlı dynamic ile çözüyoruz. Aynı container bloğu içinde iki ayrı iç dynamic (port ve env) bulunması gayet doğal; her biri farklı alt listeyi gezdiği için karışmıyor.

Blok değil, map argümanı: CloudWatch örneği

Bir tuzağa dikkat: her tekrar eden şey blok değildir. aws_cloudwatch_metric_alarm kaynağındaki dimensions aslında bir map argümanı. Yani dynamic ile değil, for ifadesiyle inşa ediliyor:

resource "aws_cloudwatch_metric_alarm" "alarms" {
  for_each = { for a in var.metric_alarms : a.name => a }

  alarm_name          = each.value.name
  metric_name         = each.value.metric_name
  namespace           = each.value.namespace
  comparison_operator = each.value.comparison_operator
  threshold           = each.value.threshold
  evaluation_periods  = each.value.evaluation_periods

  dimensions = {
    for dim in each.value.dimensions : dim.name => dim.value
  }
}

dimensions = { ... } eşitliğine dikkat edin. Blok olsaydı dimensions { ... } yazardık, dynamic kullanırdık. Bu ayrım tofu plan çıktısı garipleşince ilk bakacağınız yer olsun.

Sık karşılaşılan tuzaklar

Blok ile argümanı karıştırmak: Yukarıdaki CloudWatch örneği klasik. Provider dokümanına bakıp Argument Reference mı yoksa Block mı, önce ona karar verin.
Üç kattan fazla iç içe gitmek: Teknik olarak mümkün, ama insan gözü için cehennem. Bence iki kat yeterli; daha derine ihtiyaç duyduğunuzda veri modelinizi sadeleştirmek ya da kaynağı bölmek daha sağlıklı.
Boş listeyi unutmak: for_each = [] durumunda hiç blok üretilmiyor, ki bu çoğu zaman istediğiniz şey. Ama bazı kaynaklar 'en az bir blok' bekliyor olabilir; bu durumda plan değil, apply hata veriyor. Provider belgelerinde 'Required: Yes' yazan blokları boş bırakmayın.
statement.value yerine value yazmak: İç içe dynamic'lerde değişken adı, blok adıyla aynı oluyor (statement, condition, container vs.). İçeride value diye tek başına yazmak yasak; her seferinde <blok-adı>.value yazmanız gerek. Hatayı genelde iç bloktayken yapıyoruz, çünkü hangi blok hangisi karışıyor.

Kapanış

İç içe dynamic bloklar, derin yapılı kaynakları statik HCL'in kombinatorik patlamasından kurtaran sade bir araç. Bana sorarsanız bu özelliği abartmadan, iki kat ile sınırlı tutarak kullanmak en sağlıklısı; daha öteye geçmek istediğinizde ya veriyi düzleştirin ya da kaynağı parçalayın. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

Python ile AWS Lambda üzerinde serverless fonksiyon

2026-06-13T00:00:00Z

Selamlar arkadaşlar, bu yazıda Python ile AWS Lambda üzerinde serverless fonksiyon yazarken sıkça unuttuğumuz bir kaç ayrıntıyı toparlayacağız. Konuya tamamen yabancı olanlar için 'Lambda nedir?' bölümünden başlıyorum, ama yazının asıl kıymeti handler düzeninde, cold start ile warm start arasındaki farkta ve API Gateway'den gelen event'i nasıl ehlileştireceğimizde. Hadi başlayalım.

Lambda nedir, neden Python?

AWS Lambda kısaca 'sunucu provizyonu yapmadan kod çalıştırmak' demek. Siz bir handler yazıyorsunuz, AWS sizin yerinize runtime'ı ayağa kaldırıyor, çalıştırıyor, indiriyor. Faturada da yalnızca fonksiyonun çalıştığı milisaniyeler var. Boş duran sunucuya para yok.

Python bu işin en sevilen runtime'larından biri. Soğuk başlatma süresi makul, ekosistem zengin ve boto3 zaten standart kütüphane gibi çalışıyor. Bence basit bir webhook ya da event işleyici için Python + Lambda kombinasyonunu geçmek zor.

Cold start ve warm start

Lambda'nın yaşam döngüsünü anlamadan optimizasyon yapmak biraz karanlıkta el yordamı. İki temel durum var:

Cold start: Yeni bir execution environment ayağa kalkıyor. Kod indiriliyor, runtime başlatılıyor, handler dışındaki tüm init kodu bir kez çalışıyor. Bu en pahalı senaryo.
Warm start: Mevcut environment yeniden kullanılıyor. Sadece handler tekrar çağrılıyor, init kodu atlanıyor.

Buradaki kritik nokta şu: handler dışında yazdığınız kod her cold start'ta bir kez çalışır, sonra environment yaşadığı sürece bedava nimet olur. Bu yüzden boto3 client'larını, DynamoDB tablo nesnelerini, SSM'den çekilen sırları handler'ın dışında tanımlıyoruz.

Temiz bir handler iskeleti

Şimdi minimum bir örnekle başlayalım. Aşağıdaki handler hem cold start'ta hem warm start'ta mantıklı davranır:

import json
import logging
import os
import boto3

logger = logging.getLogger()
logger.setLevel(logging.INFO)

# Bu satirlar cold start'ta bir kez calisir, warm start'ta tekrar etmez
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table(os.environ.get('USERS_TABLE', 'users'))


def handler(event: dict, context) -> dict:
    user_id = event.get('pathParameters', {}).get('userId')
    if not user_id:
        return _response(400, {'error': 'userId zorunlu'})

    item = table.get_item(Key={'userId': user_id}).get('Item')
    if not item:
        return _response(404, {'error': 'Kullanici bulunamadi'})

    return _response(200, item)


def _response(status: int, body: dict) -> dict:
    return {
        'statusCode': status,
        'headers': {'Content-Type': 'application/json'},
        'body': json.dumps(body, default=str),
    }

Burada dynamodb ve table değişkenleri modül seviyesinde. İlk istekte oluşturuldular, sonraki yüzlerce istekte aynı bağlantı havuzu üzerinden çalışıyorlar. Eğer bu üç satırı handler() içine taşırsanız, her warm invocation'da bile yeniden client kuracaksınız - bu hem yavaş hem de gereksiz.

API Gateway entegrasyonunda dikkat edilenler

API Gateway proxy entegrasyonu kullanıyorsanız Lambda'ya gelen event şişman bir sözlük olur. İçinde httpMethod, path, pathParameters, queryStringParameters, headers, body alanları var. body her zaman string'tir; JSON ise siz parse etmek zorundasınız:

def parse_body(event: dict) -> dict | None:
    raw = event.get('body')
    if not raw:
        return None
    try:
        return json.loads(raw)
    except json.JSONDecodeError:
        return None

Bir başka tuzak: queryStringParameters istek hiç query string içermiyorsa None gelir, boş sözlük değil. Doğrudan .get() çağırmadan önce or {} koyun:

qs = event.get('queryStringParameters') or {}
limit = int(qs.get('limit', 20))

CORS kontrolü için OPTIONS isteklerini erkenden kısa devre yapmak da klasik:

if event.get('httpMethod') == 'OPTIONS':
    return _response(200, {})

Sık karşılaşılan hatalar

Init kodunu handler'ın içine yazmak: Her warm invocation'da boto3 client'ı yeniden kuruyorsunuz. Hem yavaş hem de connection pool reset oluyor. Modül seviyesine taşıyın.
Timeout'u API Gateway'in 29 saniyesinden uzun tutmak: API Gateway 29 saniyede zaten 504 döner. Lambda 5 dakika çalışıyor olsa bile kullanıcı beklemiyor; gereksiz fatura.
Memory'yi 128 MB'da bırakmak: Lambda'da CPU bellek miktarına bağlı tahsis edilir. 1024 MB altı genelde CPU kıtlığı yaşatır; ölçüp artırmak çoğu zaman daha ucuza çıkar.
SSM Parameter Store'u her invocation'da çağırmak: Cold start'ta bir kez çekip modül seviyesinde önbelleğe alın, warm start'larda bedava.
event['body']'nin string olduğunu unutmak: Direkt event['body']['email'] yazıp TypeError: string indices must be integers ile karşılaşmak Lambda klasiklerindendir.

Lokal test ve doğrulama

SAM CLI ile lokalde event göndererek handler'ı çalıştırabilirsiniz:

sam local invoke ApiFunction --event events/get-user.json
sam local start-api --port 3000

Birim test tarafında ise moto kütüphanesi AWS servislerini taklit eder; boto3 çağrılarını gerçek bir AWS hesabına gitmeden test edebilirsiniz:

import boto3
import pytest
from moto import mock_aws

@mock_aws
def test_handler_returns_user():
    dynamodb = boto3.resource('dynamodb', region_name='eu-west-1')
    dynamodb.create_table(
        TableName='users',
        KeySchema=[{'AttributeName': 'userId', 'KeyType': 'HASH'}],
        AttributeDefinitions=[{'AttributeName': 'userId', 'AttributeType': 'S'}],
        BillingMode='PAY_PER_REQUEST',
    )
    # ... handler import ve cagri

Kapanış

Bu yazıda Python ile Lambda fonksiyonu yazarken handler dışı init'in neden hayati olduğunu, API Gateway event'ini nasıl güvenli işleyeceğimizi ve lokal testin pratik araçlarını gördük. Şahsi kanaatim, küçük bir webhook için Lambda fazlasıyla yeterli; ama uzun süreli işlemler ya da WebSocket gibi senaryolar için Fargate veya ECS düşünün, zorlamayın. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

ClickHouse kullanan Python kodunu nasıl test ederiz?

2026-06-12T00:00:00Z

Selamlar, bu yazımda ClickHouse'a bağlı Python kodunu nasıl test ettiğimize bakacağız. Konu kulağa basit gelse de iş başa düşünce 'şu sorgu prod'da gerçekten doğru sonucu mu döndürüyor?' sorusu epey sinir bozucu olabiliyor. Lafı uzatmadan başlayayım.

ClickHouse, OLAP tarafında biz Python'cuların sevdiği bir veritabanı. Ama test yazma kültürü hâlâ çoğunlukla 'mock'la geç, hayatına devam et' tarafında. Bence bu eksik bir yaklaşım. Çünkü ClickHouse'un asıl değerli olduğu yerler (aggregate fonksiyonlar, materialized view'lar, uniq, quantile gibi yapılar) mock'larla test edildiğinde aslında hiç test edilmemiş oluyor.

Üç katmanlı bir yaklaşım

Bana sorarsanız ClickHouse bağımlı kodu üç farklı seviyede test etmek lazım:

Birim testler: ClickHouse istemcisini mock'larız, sadece iş mantığını test ederiz. Hızlı ama sorgunun kendisini garanti etmez.
Entegrasyon testleri: Testcontainers ile gerçek bir ClickHouse instance'ı kaldırırız. Yavaş ama dürüst.
Kontrat testleri: Sorgu çıktısının beklenen şemaya uyduğunu doğrularız.

Üçü birbirini tamamlıyor; birini diğerine tercih etmeyin.

Mock ile birim test

Diyelim ki günlük aktif kullanıcı sayısını hesaplayan basit bir fonksiyonumuz var:

# app.py
def get_daily_active_users(client, date: str) -> int:
    result = client.query(
        f"SELECT uniq(user_id) FROM events WHERE toDate(event_time) = '{date}'"
    )
    return result.first_row[0]

Test tarafında istemciyi MagicMock ile sahteliyoruz:

# test_app.py
from unittest.mock import MagicMock
from app import get_daily_active_users

def test_daily_active_users_returns_int():
    mock_client = MagicMock()
    mock_result = MagicMock()
    mock_result.first_row = [42]
    mock_client.query.return_value = mock_result

    count = get_daily_active_users(mock_client, '2026-03-31')

    assert count == 42
    assert '2026-03-31' in mock_client.query.call_args[0][0]

Burada test ettiğimiz şey çok dar: fonksiyon first_row[0]'ı doğru döndürüyor mu, tarihi sorguya gerçekten yerleştiriyor mu? Bu kadar. uniq fonksiyonunun doğru çalışıp çalışmadığını test etmiyoruz. Açıkçası ben bu seviyeyi çoğunlukla SQL injection riskini görmek için kullanıyorum.

Testcontainers ile gerçek ClickHouse

Şimdi işin gerçek kısmı. testcontainers paketiyle her test oturumu için tek bir ClickHouse container'ı kaldırıyoruz:

pip install testcontainers[clickhouse] clickhouse-connect pytest

conftest.py içinde fixture'larımızı tanımlıyoruz:

# conftest.py
import pytest
import clickhouse_connect
from testcontainers.clickhouse import ClickHouseContainer

@pytest.fixture(scope='session')
def ch_client():
    with ClickHouseContainer('clickhouse/clickhouse-server:latest') as ch:
        client = clickhouse_connect.get_client(
            host=ch.get_container_host_ip(),
            port=int(ch.get_exposed_port(8123)),
        )
        client.command('''
            CREATE TABLE events (
                user_id UInt64,
                event_time DateTime DEFAULT now(),
                event_type String
            ) ENGINE = MergeTree() ORDER BY (user_id, event_time)
        ''')
        yield client

scope='session' olması kritik. Her test için container kaldırırsanız test süitiniz yarım saatte biter; oturum başına bir kez kaldırırsanız 5-10 saniyelik bir sabit maliyetiniz olur, sonrası akar gider.

Testin kendisi sade:

# test_integration.py
def test_insert_and_count(ch_client):
    ch_client.insert(
        'events',
        [[1, 'login'], [2, 'click']],
        column_names=['user_id', 'event_type'],
    )
    result = ch_client.query('SELECT count() FROM events')
    assert result.first_row[0] == 2

Materialized view'ları test etmek

İşin sinsi tarafı burası. Materialized view'lar arka planda merge bekliyor; insert sonrası hemen sorgu atarsanız beklenen sonucu göremeyebilirsiniz. OPTIMIZE ... FINAL ile merge'ü zorlamak gerekiyor:

def test_event_counts_materialized_view(ch_client):
    ch_client.command('''
        CREATE MATERIALIZED VIEW event_counts
        ENGINE = SummingMergeTree() ORDER BY event_type
        AS SELECT event_type, count() AS cnt
        FROM events GROUP BY event_type
    ''')
    ch_client.insert('events', [[3, 'login']], column_names=['user_id', 'event_type'])
    ch_client.command('OPTIMIZE TABLE event_counts FINAL')

    result = ch_client.query(
        "SELECT cnt FROM event_counts WHERE event_type = 'login'"
    )
    assert result.first_row[0] >= 1

Sık karşılaşılan hatalar

Her test için yeni container kaldırmak: scope='function' kullanırsanız süit dakikalarca akar. Oturum bazlı fixture kullanın, test başında TRUNCATE TABLE ile temizleyin.
Materialized view'da merge'ü beklememek: Insert sonrası hemen SELECT atarsanız sonuç boş gelebilir. OPTIMIZE TABLE <View> FINAL çağırmayı unutmayın.
f-string ile sorgu kurmak: Yukarıdaki örnekte tarihi f-string ile yerleştirdik; gerçek hayatta parameters= argümanını kullanın, yoksa SQL injection kapısı açıyorsunuz.
Sadece mock ile yetinmek: uniq, quantile, argMax gibi ClickHouse'a özgü fonksiyonların doğru sonuç verdiğini ancak gerçek bir instance ile doğrulayabilirsiniz.

Kapanış

Bu yazıda ClickHouse'a bağımlı Python kodunu mock'tan Testcontainers'a, oradan da materialized view senaryolarına kadar üç farklı seviyede nasıl test ettiğimize baktık. Şahsi kanaatim, mock'lara fazla yaslanmadan en azından kritik sorguları gerçek bir container'a karşı çalıştırmak şart; oturum kapsamlı fixture'larla bunun maliyeti de görünenden çok daha düşük. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

Python ile IPv6 ağ sağlığını izleyen küçük bir araç yazmak

2026-06-12T00:00:00Z

Selamlar arkadaşlar, bu yazımızda Python ile küçük ama gerçekten faydalı bir IPv6 izleme aracı yazacağız. Adres dağıtımı, prefix delegation falan değil derdimiz; konumuz daha sıradan ama bir o kadar can sıkıcı bir mesele: IPv6 tarafı ne durumda, kimse fark etmeden çökmüş olabilir mi? Hadi başlayalım.

İşin aslı şu: çoğu şirkette IPv4 izlemesi yıllardır oturmuş, IPv6 ise ya yarı kurulu durumda ya da ' çalışıyor herhalde' modunda. Tecrübeyle sabittir, IPv6 routing'i bir gece sessizce düşer ve bunu fark eden ilk kişi genellikle bir kullanıcı olur. Bu yüzden ufak bir Python script'i bile büyük fark yaratıyor.

Neden Python ve neden asyncio?

ping6 veya ping -6 zaten her Linux kutusunda var; biz onun üzerine ince bir katman yazıyoruz. Tek bir host için subprocess yeter, ama gerçekçi bir senaryoda 20-30 host paralel kontrol edilmek istenir. Sıralı ping yapsanız her hedef için 2-3 saniye bekler, toplam tur 60 saniyeye dayanır. Asyncio ile bunu birkaç saniyeye indiriyoruz.

Şahsi kanaatim, bu tür araçlarda framework kullanmaya gerek yok; standart kütüphane fazlasıyla yetiyor.

Tek host için ping fonksiyonu

Hadi minimum bir örnekle başlayalım. Aşağıdaki fonksiyon ping6 çıktısını parse edip yapılandırılmış bir sonuç döndürüyor:

import asyncio
import re
from dataclasses import dataclass

@dataclass
class PingSonuc:
    host: str
    ulasilabilir: bool
    rtt_ms: float | None
    paket_kaybi_yuzde: float

async def ping6_async(host: str, sayi: int = 3) -> PingSonuc:
    proc = await asyncio.create_subprocess_exec(
        'ping', '-6', '-c', str(sayi), '-W', '2', host,
        stdout=asyncio.subprocess.PIPE,
        stderr=asyncio.subprocess.DEVNULL,
    )
    stdout, _ = await proc.communicate()
    cikti = stdout.decode()

    kayip = re.search(r'(\d+(?:\.\d+)?)% packet loss', cikti)
    paket_kaybi = float(kayip.group(1)) if kayip else 100.0

    rtt = re.search(r'min/avg/max.*= [\d.]+/([\d.]+)/', cikti)
    rtt_ms = float(rtt.group(1)) if rtt else None

    return PingSonuc(host, proc.returncode == 0, rtt_ms, paket_kaybi)

Burada create_subprocess_exec ile ping komutunu non-blocking şekilde çağırıyoruz. -W 2 parametresi her bir paket için en fazla 2 saniye bekleyeceğimizi söylüyor; donmuş hedefler bütün döngüyü tıkamasın diye bu önemli.

Paralel toplu kontrol

Tek host'a bakmak ısınma turu. Şimdi gerçek senaryoya geçelim. Bir hedef listesini paralel pingleyip sonuçları toplayalım:

async def topla(hedefler: list[str]) -> list[PingSonuc]:
    gorevler = [ping6_async(h) for h in hedefler]
    return await asyncio.gather(*gorevler, return_exceptions=False)

async def main():
    hedefler = [
        '2001:4860:4860::8888',   # Google DNS
        '2606:4700:4700::1111',   # Cloudflare DNS
        '2001:db8:cafe::1',       # ic gateway
    ]
    sonuclar = await topla(hedefler)
    for s in sonuclar:
        durum = 'UP' if s.ulasilabilir else 'DOWN'
        rtt = f'{s.rtt_ms:.1f}ms' if s.rtt_ms else 'N/A'
        print(f'[{durum}] {s.host} rtt={rtt} kayip={s.paket_kaybi_yuzde:.0f}%')

asyncio.run(main())

20 hedef için bu kod yaklaşık 3 saniyede toplam sonucu veriyor; sıralı versiyonun yanından bile geçmiyor. Tabii burada ICMP rate limit'lere de dikkat etmek lazım, ağ ekibi sizi düşman zannetmesin.

SLO bütçesi: sadece UP/DOWN değil

Bana sorarsanız, gerçek değer UP/DOWN'da değil, gecikme dağılımında saklı. Bir host hâlâ ping'e cevap veriyor olabilir ama RTT 12 ms'den 180 ms'ye fırladıysa kullanıcı zaten yandı. Basit bir SLO sınıfı:

def slo_durumu(s: PingSonuc, esik_ms: float = 50.0) -> str:
    if not s.ulasilabilir:
        return 'KRITIK'
    if s.paket_kaybi_yuzde > 0:
        return 'BOZULDU'
    if s.rtt_ms and s.rtt_ms > esik_ms:
        return 'YAVAS'
    return 'SAGLIKLI'

Bu üç-dört durumlu çıktı, alert kuralları yazmayı çok rahatlatıyor. Tek bir gauge yerine bir histogram tutarsanız Grafana'da p95'i takip etmek de kolay olur ama bu yazının kapsamı dışına taşar.

Sık karşılaşılan hatalar

-W parametresini unutmak: Hedef sessizce paket düşürüyorsa varsayılan timeout dakikalara çıkabilir. Tüm async döngünüz tek bir DOWN host yüzünden kilitlenir. -W 2 veya -W 3 koymak zorunlu.
Sadece DNS adı denemek: Hostname AAAA kaydı dönmüyorsa Linux sessizce IPv4'e fallback yapabilir; siz IPv6'yı izlediğinizi sanırken aslında IPv4 ölçüyorsunuzdur. Mümkünse hedefi doğrudan IPv6 literali olarak verin, requests kullanıyorsanız URL'de köşeli parantezle (https://[2001:db8::1]/health).
Tek thread'de senkron subprocess.run: 30 hedef için döngü kuruyorsanız asyncio'ya geçmek üç katı performans değil, on katı performans demek. asyncio.gather burada hayat kurtarıyor.
Loopback üzerinde test edip iyi sandığınız kod: ::1 her zaman ulaşılabilir; gerçek bir test ortamı için harici bir IPv6 hedefi şart, yoksa script'iniz sahada ilk ICMP filtresinde patlar.

Doğrulama

Local'de bir tail komutuyla manuel doğrulamak en hızlısı:

python ipv6_monitor.py | grep -E 'DOWN|YAVAS'

Beklediğiniz çıktı yoksa, yani her şey UP ve hızlı görünüyorsa, bilerek olmayan bir adres ekleyin (2001:db8:dead::1 gibi). DOWN satırı görüyor musunuz? Görüyorsanız hata yolu çalışıyor demektir.

Kapanış

Bu yazıda Python ve asyncio ile basit ama işine yarayan bir IPv6 sağlık izleme aracı yazdık; UP/DOWN'un ötesine geçip RTT ve paket kaybı eşikleriyle SLO mantığı ekledik. Bence bu küçük script kurumsal izleme yığınınızın yerine geçmez ama IPv6 tarafının gerçekten ne durumda olduğunu öğrenmenin en hızlı yolu hâlâ böyle 80 satırlık bir Python dosyası. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

FastAPI ve PostgreSQL stack'ini Portainer ile yayına almak

2026-06-12T00:00:00Z

Selamlar, bu yazımda FastAPI tarafında bir API'yi PostgreSQL ile beraber Portainer'in stack özelliği üzerinden nasıl ayağa kaldırdığıma bakacağız. Konuya çok yabancı olmayan ama 'compose dosyasını Portainer'a yapıştırınca neden patlıyor?' diyen arkadaşlar için yazdım. Lafı uzatmadan başlayalım.

Açıkçası ben de ilk denemelerimde container'ları ayağa kaldıran depends_on kuralının yeterli olduğunu zannetmiştim. Sonra görüyorsunuz ki API, PostgreSQL daha hazır olmadan migration çalıştırmaya başlıyor ve connection refused ile düşüyor. Buradaki kritik nokta service_healthy koşulu ve pg_isready ile doğru bir healthcheck yazmak.

Stack dosyası

Portainer'da Stacks > Add stack diyip aşağıdaki compose dosyasını yapıştırmanız yeterli. Ben üretim için aşağıdaki gibi bir şablon kullanıyorum:

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: siparis
      POSTGRES_USER: siparis_app
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - pg_data:/var/lib/postgresql/data
    healthcheck:
      test: ['CMD-SHELL', 'pg_isready -U siparis_app -d siparis']
      interval: 10s
      timeout: 5s
      retries: 5

  api:
    build: ./app
    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    ports:
      - '8000:8000'
    environment:
      DATABASE_URL: postgresql+asyncpg://siparis_app:${DB_PASSWORD}@db:5432/siparis
      APP_SECRET: ${APP_SECRET}
    command: >
      bash -lc 'alembic upgrade head && uvicorn main:app --host 0.0.0.0 --port 8000 --workers 4'

volumes:
  pg_data:

Burada birkaç noktanın altını çizmek isterim. depends_on.condition: service_healthy olmadan API container'ı, veritabanı daha hazır değilken ayağa kalkar. Healthcheck'in pg_isready -U siparis_app -d siparis şeklinde hem kullanıcı hem de veritabanı parametresiyle yazılması sık gözden kaçan bir detay. Sadece pg_isready derseniz socket'i kontrol eder, asıl DB hazır olmadan da yeşil yanabilir.

${DB_PASSWORD} ve ${APP_SECRET} değerlerini Portainer'in 'Environment variables' kısmından girin. Stack içine düz metin şifre yapıştırmak istemezsiniz; hem versiyon kontrolüne kaçar hem de Portainer ekranı üzerinden herkes okur.

Uygulama tarafı

API tarafında elimden geldiğince ince bir şablon tutuyorum. SQLAlchemy 2.x'in async desteği artık gerçekten oturdu; asyncpg ile beraber kullanınca performans gayet tatmin edici.

# app/main.py
from fastapi import FastAPI
from sqlalchemy import text
from sqlalchemy.ext.asyncio import create_async_engine
import os

app = FastAPI(title='Siparis API')
engine = create_async_engine(os.environ['DATABASE_URL'], pool_pre_ping=True)

@app.get('/health')
async def health():
    try:
        async with engine.connect() as conn:
            await conn.execute(text('SELECT 1'))
        return {'status': 'ok'}
    except Exception as exc:
        return {'status': 'down', 'detail': str(exc)}

pool_pre_ping=True parametresi tecrübeyle sabittir; gece yarısı PostgreSQL'in bakım için kısa bir kapanmasından sonra havuzdaki ölü bağlantıların temizlenmesini sağlıyor. Bu küçük parametre olmadan sabaha karşı birçok 'OperationalError: connection invalid' alırsınız.

Sık karşılaşılan hatalar

Healthcheck'i unutmak: depends_on tek başına yeterli değildir. Container ayaktadır ama PostgreSQL hazır olmayabilir; migration patlar.
asyncpg yerine psycopg driver yazmak: DATABASE_URL'de postgresql+asyncpg:// yazmak zorundasınız, yoksa SQLAlchemy async driver bulamayınca anlamsız bir hata verir.
Migration'ı command içinde çalıştırmak: Tek replica için bu kabul. Birden fazla replica açınca her instance aynı anda alembic upgrade head çalıştırır ve advisory lock kullanmazsanız migration tablosunda bozulma riski çıkar. Bu durumda ayrı bir migrate job'ı açın.
Volume'u dış bir path'e bind etmek: ./pg_data:/var/lib/postgresql/data gibi bir bind kullanınca SELinux veya UID/GID sorunları yaşarsınız. Portainer host'unda named volume kalsın.
POSTGRES_PASSWORD Portainer environment alanında ama compose'da değişken referansı olmamak: Boş string ile container ayağa kalkar, sonra trust authentication zannedip yanılırsınız.

Doğrulama

Stack ayağa kalkınca şu komutlarla durumu hızlıca gözden geçirebilirsiniz:

curl -s http://localhost:8000/health
docker exec -it $(docker ps -qf name=db) pg_isready -U siparis_app -d siparis
docker logs --tail 50 $(docker ps -qf name=api)

/health endpoint'i {'status': 'ok'} dönmüyorsa önce API loglarına bakın; çoğunlukla DATABASE_URL içindeki host adı yanlış ya da şifre escape edilmemiş oluyor. Bende bir keresinde @ karakteri içeren bir şifre yüzünden yarım saat kaybetmiştim, URL-encode etmek lazım.

Kapanış

Bu yazıda FastAPI ve PostgreSQL stack'ini Portainer üzerinden ayağa kaldırırken healthcheck, async driver ve migration konularında dikkat edilmesi gereken noktalara baktık. Bence Portainer GUI'si küçük ve orta ölçekli takımlar için kubectl ihtiyacı doğmadan yeterince güçlü; asıl mesele compose dosyasını olabildiğince açık yazmak. Umarım faydalı olur, görüşmek üzere.

MongoDB projeksiyonlarinda dizi elemanlarini $slice ile sinirlamak

2026-06-12T00:00:00Z

Selamlar, bu yazımda MongoDB tarafında çok sık ihtiyaç duyduğumuz ama bir o kadar da gözden kaçan bir konuya bakacağız: bir doküman içindeki uzun dizinin tamamını çekmeden sadece istediğimiz kısmını almak. Konunun adı $slice projection operatörü. Hadi başlayalım.

İlk başlarda MongoDB ile çalışırken, comments veya notifications gibi alanları sorgudan çekerken dizinin hepsi geliyordu ve buna dokunmadan rahatça yaşıyorduk. Sonra bir kullanıcının üstüne otuz bin tane bildirim biriktiğinde işler değişti. Tek bir findOne çağrısı bile listede gözle görülür şekilde ağırlaşıyordu. İşte $slice tam burada işe yarıyor.

$slice projection nedir?

Kısaca: bir sorguda dizi alanının tamamı yerine sadece bir kısmını döndürmemizi sağlayan projeksiyon operatörü. Üç temel formu var:

// Ilk N eleman
{ comments: { $slice: 3 } }

// Son N eleman (negatif deger)
{ comments: { $slice: -3 } }

// skip kadar atla, limit kadar al
{ comments: { $slice: [skip, limit] } }

Burada dikkat edilecek nokta, $slice filtreleme değil, projeksiyon yapıyor. Yani sorgu yine eşleşen tüm dokümanları taramaya devam ediyor, ama sonuçta dizinin sadece belirttiğin parçası dönüyor. Bunu sık karıştıranı gördüm; benim de ilk başlarda kafam karışmıştı.

Pratikte nasil kullaniyoruz?

Diyelim elimizde şöyle bir koleksiyon var:

{
  _id: 1,
  title: 'MongoDB ipuclari',
  comments: ['c1', 'c2', 'c3', 'c4', 'c5']
}

Son iki yorumu istiyorsan:

db.posts.find({}, { comments: { $slice: -2 } })
// donus: comments: ['c4', 'c5']

Sayfa numarasıyla yorum çekmek istiyorsan, [skip, limit] formu cuk oturuyor:

function getCommentPage(postId, page, pageSize) {
  return db.posts.findOne(
    { _id: postId },
    { comments: { $slice: [(page - 1) * pageSize, pageSize] } }
  );
}

Tabii burada şuna dikkat: dizinin tamamı belleğe alındıktan sonra dilimleniyor. Yani 100 bin elemanlı bir dizide ortadaki 10'u istiyorsanız MongoDB diziyi yine de okuyor. Eğer dizilerin gerçekten patlama riski varsa, yorumları ayrı koleksiyona almak daha sağlıklı; bana sorarsanız üç haneli sayıları geçen yerlerde $slice'a güvenmek yanıltıcı.

Diger projeksiyonlarla birlestirmek

$slice'ı klasik dahil/hariç (1 / 0) projeksiyonuyla rahatça birlikte kullanabiliyoruz:

db.posts.find(
  { status: 'published' },
  {
    title: 1,
    author: 1,
    comments: { $slice: 5 },
    _id: 0
  }
)

Ama aynı alan üzerinde $elemMatch veya pozisyonel $ operatörüyle birleştiremiyoruz. Bu da Mongo dokümantasyonunun arka sayfalarında gizli bir kural; staging'de hiç sorun çıkarmadan geçen bir sorgunun production'da Cannot specify positional operator and $slice hatasını verdiğini görmek mümkün.

Aggregation icindeki $slice

Bir de aggregation pipeline'ında ayrı bir $slice ifade operatörü var, ki bu çok daha esnek:

db.posts.aggregate([
  {
    $project: {
      title: 1,
      recentComments: { $slice: ['$comments', -5] },
      commentCount: { $size: '$comments' }
    }
  }
])

Burada hem son 5 yorumu alıyoruz hem de $size ile toplam yorum sayısını döndürüyoruz. Projection formu bunu yapamaz; aggregation formu yapar. Şahsi kanaatim, dinamik dilimleme ya da hesaplama gerekiyorsa doğrudan aggregation'a geçmek daha temiz.

Sik karsilasilan tuzaklar

Tüm diziyi taradığını unutmak: $slice ağ trafiğini azaltır, disk okumasını değil. Çok büyük dizilerde performans hâlâ sıkıntılı olabilir.
[skip, limit] formunda negatif skip: [-3, 2] ifadesi sondan 3 atlar ve 2 alır. İlk gördüğümde [3, 2] ile karıştırmıştım; doküman dikkatli okunmalı.
Pozisyonel $ ile birlikte kullanmak: Aynı alanda iki array operatörünü çakıştıramazsınız. Çakıştırırsanız sorgu hata verir.
Dizi olmayan alana uygulamak: Hata vermez ama alan olduğu gibi döner. Sessiz bir aldatmaca; testinizde fark etmeniz zor.

Kapanis

$slice küçük ama aklımızda tutmamız gereken bir araç; özellikle bildirim, yorum, son aktiviteler gibi 'sadece son N tanesi lazım' senaryolarında yapay bir aggregation'a girmeden işi halledebiliyoruz. Bence tek ipucu şu: dizilerin gerçekten büyüdüğü yerlerde $slice çözüm değil, ayrı koleksiyona geçmenin habercisidir. Umarım faydalı olur, görüşmek üzere.

RHEL üzerinde Tox ile Python test otomasyonu

2026-06-12T00:00:00Z

Selamlar, bu yazıda RHEL sunucu üzerinde tox'u kurup, birden fazla Python sürümüne karşı testlerimizi nasıl koşturduğumuza bakacağız. Konu basit ama bir-iki yerde insanın canını sıkan ufak detaylar var, ben de tam o detaylara değineceğim. Hadi başlayalım.

Bir Python kütüphanesi yazıyorsanız ya da farklı sunucularda farklı Python sürümleriyle karşılaşacak bir uygulama paketliyorsanız, 'benim makinemde çalışıyordu' cümlesi er ya da geç başınıza patlıyor. Tox tam burada devreye giriyor: izole virtualenv'ler kuruyor, her ortamda paketinizi sıfırdan yüklüyor, testleri çalıştırıyor ve sonucu net bir özetle veriyor. Yani aslında küçük bir CI'yi yerel makineye taşıyorsunuz.

Tox aslında ne yapıyor?

Tox bir tox.ini ya da pyproject.toml dosyası okur. Tanımladığınız her ortam (env) için şu adımları sırayla yapar:

Temiz bir virtualenv açar.
Paketinizi ve tanımladığınız bağımlılıkları kurar.
Belirttiğiniz komutları çalıştırır (genelde pytest).
Geçti / kaldı diye raporlar.

Bu kadar. Sihir yok; ama bu kadarı bile elle yapmaya kalktığınızda kafa şişiriyor.

Birden fazla Python sürümü kurmak

RHEL 9 varsayılan olarak Python 3.9 ile geliyor. Test matrisini büyütmek için AppStream'den ek sürümleri çekiyoruz:

sudo dnf install -y python3 python3-pip python3-devel
sudo dnf install -y python3.11 python3.11-pip python3.11-devel
sudo dnf install -y python3.12 python3.12-pip python3.12-devel

Burada python3.12-devel paketini atlamak ilk anda işe yaramış gibi görünür, ama bağımlılıklarınız içinde C uzantısı derleyen bir şey çıktığında (mesela psycopg2'nin binary olmayan sürümü) hata yer. Bence baştan -devel'i de kurun, dert etmeyin.

Tox'u kurmak

Tox'u sistem geneline değil, kullanıcı seviyesinde kurmak benim tercihim:

pip3 install --user tox
tox --version

Eğer tox komutu bulunamıyorsa ~/.local/bin dizini PATH'inizde olmayabilir. Bunu .bashrc'ye eklemek bir kerelik bir iş.

Ornek bir tox.ini

Kafamızda somutlaşması için küçük bir paket düşünelim. src/mypackage/__init__.py içinde iki fonksiyon olsun:

def add(a, b):
    return a + b

def divide(a, b):
    if b == 0:
        raise ValueError('Sifira bolme yok')
    return a / b

Test dosyamız tests/test_math.py:

import pytest
from mypackage import add, divide

def test_add():
    assert add(2, 3) == 5

def test_divide_by_zero():
    with pytest.raises(ValueError):
        divide(1, 0)

Şimdi tox.ini:

[tox]
envlist = py39, py311, py312, lint
isolated_build = True

[testenv]
deps =
    pytest
    pytest-cov
commands =
    pytest tests/ -v --cov=mypackage --cov-report=term-missing

[testenv:lint]
deps =
    flake8
    black
commands =
    flake8 src/ tests/
    black --check src/ tests/

tox komutunu çalıştırdığınızda dört ortam birden açılır, paketinizi her birine ayrı ayrı kurar ve testleri koşar. tox -e py311 derseniz tek ortam çalışır.

Paralel kosma ve yeniden olusturma

Üç Python sürümü ardı ardına kurulup testler çalışınca süre uzayabiliyor. Paralel modu deneyin:

tox -p auto

Bağımlılık değişip ortamlar bayatladığında ise:

tox -r

Bütün ortamları siler, sıfırdan kurar. CI dışında yerelde sık ihtiyaç duyduğum bir komut, çünkü requirements'a yeni bir paket eklediğinizde tox bunu otomatik fark etmiyor her zaman.

Bizim takildigimiz bir nokta

Şahsi tecrübeden söyleyeyim: bir keresinde RHEL 9 üzerinde py312 ortamı tox listesinde 'görünmüyor' diye uğraşmıştık. Sebebi gayet basitti aslında - paket kurulu değildi ama dnf sessizce başka bir paketi çözmüştü. python3.12 --version denediğimizde 'command not found' aldık. AppStream module setlerinde sürüm bazen gizli kalıyor; dnf module list python ile aktif modülü görmek bu durumda iş kurtarır. Üzerinde bir kahve harcadıktan sonra alışkanlık oldu, ilk iş onu çağırıyorum şimdi.

CI hattina baglamak

GitHub Actions tarafında matris tanımı şu kadar:

name: Tests
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ['3.9', '3.11', '3.12']
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python-version }}
      - run: pip install tox
      - run: tox -e py

tox -e py o anki Python sürümünün ortamını seçiyor; matris bunu üç farklı versiyon için ayrı ayrı tetikliyor. Yerel tox.ini'yi değiştirmeden CI'yi büyütebiliyorsunuz, en hoş tarafı bu.

Sik karsilasilan tuzaklar

isolated_build = True'yi unutmak: pyproject.toml ile çalışıyorsanız bu satır olmazsa olmaz. Yoksa tox eski stil setup.py davranışına düşer ve modern build backend'lerinizi tanımaz.
deps icindeki surumleri sabitlememek: CI'da yeşil olan tox koşusu ertesi gün kırmızı dönerse, büyük ihtimalle pytest ya da flake8 minor sürüm zıplaması yapmıştır. Kritik araçlar için pytest>=8,<9 gibi bir aralık koyun.
passenv'i bos birakmak: Tox güvenlik için ortam değişkenlerinizi temizler. CI'nin koyduğu CI, GITHUB_ACTIONS gibi değişkenler de gider. Lazımsa açıkça passenv = CI HOME GITHUB_* deyin.
Sistem Python'u ile karistirmak: pip install tox derken root olmayın. Sistem paketleriyle çakışırsa toparlamak yorucu olur; pip3 install --user tox ya da pipx install tox çok daha temiz.

Kapanis

Bu yazıda tox ile RHEL üzerinde çoklu Python sürümü test ortamını nasıl kurduğumuza, paralel koşmaya ve CI'a bağlamaya kısaca baktık. Bana sorarsanız tox, kütüphane yazan herkes için artık opsiyonel bir araç değil; matris testi olmadan farklı sürümlerde kırılan bir paketi yayınlamanın bedeli her zaman daha ağır oluyor. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

MySQL InnoDB çöktükten sonra veri kurtarma

2026-06-11T00:00:00Z

Selamlar, bu yazımda MySQL'in en sevilen ama en az anlaşılan konularından birine, InnoDB'nin crash recovery mekanizmasına bakacağız. Konuyu hem teorik hem de pratik tarafıyla ele alacağız; çünkü production'da bir gece yarısı MySQL ayağa kalkmıyorsa, dokümantasyonu o anda okumak biraz geç oluyor. Lafı çok uzatmadan başlayalım.

InnoDB aslında çökmelerden tek başına kurtulmak için tasarlanmıştır. Yani sunucu fişten çekildiğinde bile, redo log dosyaları sayesinde commit edilmiş işlemleri geri oynatır, yarım kalanları rollback eder. Çoğu zaman siz farkına bile varmazsınız. Ama bazen otomatik kurtarma yetmez ve iş başa düşer.

InnoDB crash recovery nasıl çalışır?

InnoDB, write-ahead logging (kısaca WAL) yaklaşımını kullanır. Şöyle ki, veri sayfaları diske yazılmadan önce değişiklikler önce redo log'a yazılır. MySQL 8.0.30 öncesinde bu dosyalar ib_logfile0 ve ib_logfile1 idi; sonrasında #innodb_redo/ klasörü altına taşındı.

Çökme sonrası başlangıçta InnoDB üç şey yapar:

Son checkpoint'ten itibaren redo log'u okur.
Commit edilmiş işlemleri ileri sarar (roll forward).
Yarım kalan işlemleri undo log ile geri alır (rollback).

Recovery'nin gerçekten çalışıp çalışmadığını şuradan kontrol edebilirsiniz:

SELECT * FROM performance_schema.global_status
WHERE VARIABLE_NAME LIKE 'Innodb_redo_log%';

Otomatik kurtarma ve error log

Vakaların büyük çoğunluğunda MySQL kendi kendine ayağa kalkar. Bizim ilk işimiz error log'a bakmak olmalı:

sudo tail -100 /var/log/mysql/error.log | grep -i 'recovery\|innodb\|crash'

Tipik olarak şuna benzer satırlar görürsünüz:

InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages
InnoDB: Completed initialization of buffer pool

Bu satırları gördüyseniz rahat nefes alabilirsiniz; InnoDB işini yapmış demektir.

MySQL ayağa kalkmıyorsa

İşler çığrından çıktığında, yani MySQL servisi başlamıyorsa, error log yine ilk durağımız:

sudo journalctl -u mysql --since '1 hour ago'

Genelde şu iki hata mesajı yön gösterir:

[ERROR] InnoDB: Corruption in the InnoDB tablespace - use innodb_force_recovery
[ERROR] InnoDB: Unable to lock ./ibdata1 - check if another mysqld is running

İkincisi aslında masum bir durum; çoğu zaman zombi bir mysqld process'i takılı kalmıştır. İlki ise daha can sıkıcı, çünkü innodb_force_recovery parametresine başvurmamız gerekecek.

Yedekten geri dönmek

Açıkçası bana sorarsanız, ciddi bir bozulma varsa en sağlıklı yol yedekten dönmektir. innodb_force_recovery=6 ile veriyi kurtarabilirsiniz, ama o noktada veri tutarlılığı zaten yarım yamalaktır.

Mantıksal yedek (mysqldump) için:

mysql -u root -p < /backup/full_backup_2026-03-31.sql

Fiziksel yedek (Xtrabackup) için MySQL durdurulmalı ve data dizini boşaltılmalı:

sudo systemctl stop mysql
xtrabackup --prepare --target-dir=/backup/xtrabackup_2026-03-31/
sudo rm -rf /var/lib/mysql/*
xtrabackup --copy-back --target-dir=/backup/xtrabackup_2026-03-31/
sudo chown -R mysql:mysql /var/lib/mysql/
sudo systemctl start mysql

Binary log ile point-in-time recovery

Yedeği geri yüklediniz; tamam ama yedek sabah 03:00'a ait, çökme öğlen 13:00'da oldu. Aradaki on saatlik veri ne olacak? Eğer binary log açıksa, o on saati mysqlbinlog ile geri oynatabiliriz:

mysqlbinlog --start-datetime='2026-03-31 03:05:00' \
            --stop-datetime='2026-03-31 12:55:00' \
            /var/lib/mysql/mysql-bin.000001 | mysql -u root -p

Sık karşılaşılan hatalar

Binary log'u kapalı bırakmak: Yedeğiniz olsa bile son N saatin verisi gider. log_bin production'da pazarlığa açık değil.
Tek replica'yı yedek sanmak: Replica master'ın bozulmasını da seve seve replike eder. Yedek dediğimiz şey ayrı, periyodik ve geri yüklemesi test edilmiş olandır.
innodb_force_recovery=6 ile uzun süre çalışmak: Bu mod read-only'dir ve veri çıkarmak içindir. Veriyi alır almaz yeni bir instance kurun.
Redo log boyutunu küçük bırakmak: Yoğun yazma altında checkpoint baskısı recovery süresini de uzatır. MySQL 8.0.30+ için innodb_redo_log_capacity ile ayarlayın:

[mysqld]
innodb_redo_log_capacity=2G
log_bin=mysql-bin
binlog_expire_logs_seconds=604800

Kapanış

Bu yazıda InnoDB'nin redo log üzerinden nasıl kendi kendine toparlandığına, otomatik kurtarma yetmediğinde error log'dan başlayarak yedek ve binary log'a uzanan yola baktık. Şahsi kanaatim, crash recovery'nin asıl çözümü çökme anında değil, çökmeden çok önce alınan kararlardadır: düzenli yedek, açık binary log ve geri yükleme tatbikatı. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

Python'da özel context manager yazmak

2026-06-11T00:00:00Z

Selamlar, bu yazımda Python'ın en zarif özelliklerinden biri olan context manager'lara, özellikle de kendi context manager'larınızı nasıl yazacağınıza bakacağız. with open(...) kalıbını hepimiz biliyoruz; ama aynı mantığı veritabanı bağlantıları, kilitler, zamanlayıcılar ve genel olarak setup-teardown isteyen her kaynak için kullanabilirsiniz. Hadi dalalım.

Context manager neden lazım?

Açıkça söyleyeyim, eğer kodunuzda her yerde try/finally tekrar eden satırlar varsa, orada büyük ihtimalle gizli bir context manager bekliyor. with bloğu üç şeyi bir arada veriyor: garantili temizlik (exception olsa bile), tekrar kullanılabilir kalıp ve kaynak kapsamını net görsel olarak işaretleyen bir blok. Bu üçü olmadan kod hızla 'try'lı, dağınık' bir hale geliyor.

Buradan ne çıkarmalıyız? Aynı setup-teardown desenini iki yerde gördüğünüzde durup düşünün; muhtemelen bir context manager'a kavuşturmanın zamanı gelmiştir.

Sınıf tabanlı yaklaşım

En esnek yol, __enter__ ve __exit__ metotlarını içeren bir sınıf yazmak. Şablonu şöyle:

class OrnekContext:
    def __enter__(self):
        # Hazirlik kodu burada
        return self

    def __exit__(self, exc_type, exc_val, exc_tb):
        # Temizlik kodu burada, her durumda calisir
        # True donerseniz exception bastirilir, False ile yukari iletilir
        return False

__enter__'ın döndürdüğü değer as ile bağlanan değişken olur. __exit__ ise bloktan çıkarken çalışır; eğer içeride exception fırladıysa parametreler dolu gelir, fırlamadıysa hepsi None olur.

Şimdi bir veritabanı bağlantısı örneği görelim. Aşağıdaki sınıf, blok normal biterse commit, exception olursa rollback çağırıyor:

import sqlite3
from typing import Optional


class DbConnection:
    def __init__(self, db_path: str):
        self.db_path = db_path
        self.connection: Optional[sqlite3.Connection] = None
        self.cursor: Optional[sqlite3.Cursor] = None

    def __enter__(self) -> sqlite3.Cursor:
        self.connection = sqlite3.connect(self.db_path)
        self.cursor = self.connection.cursor()
        return self.cursor

    def __exit__(self, exc_type, exc_val, exc_tb) -> bool:
        if exc_type is not None:
            self.connection.rollback()
        else:
            self.connection.commit()
        self.cursor.close()
        self.connection.close()
        return False


with DbConnection('app.db') as cursor:
    cursor.execute('INSERT INTO users VALUES (1, ?)', ('Ayse',))

Kullanırken sadece with yazıyoruz; commit, rollback ve close'u tek tek hatırlamak zorunda değiliz. Bence bu yaklaşımın en güzel tarafı bu: tek bir yerde doğru yaptıktan sonra her yerde doğru.

contextlib ile daha kısa yol

Her seferinde sınıf yazmak istemeyebilirsiniz. Bu durumda contextlib.contextmanager dekoratörü işinizi görür. Generator fonksiyonu yazıyorsunuz; yield öncesi setup, sonrası teardown:

from contextlib import contextmanager
import os


@contextmanager
def working_directory(path: str):
    original_dir = os.getcwd()
    try:
        os.chdir(path)
        yield path
    finally:
        os.chdir(original_dir)


with working_directory('/tmp'):
    # Burada gecici olarak /tmp icindeyiz
    pass

Buradaki kritik nokta try/finally. yield'i çıplak bırakırsanız, blok içinde exception fırladığında temizlik kodunuz çalışmaz. Şahsi kanaatim, dekoratör yaklaşımı sadece basit setup-teardown için; durum tutmanız gerekiyorsa sınıfa geçin.

Birden fazla context'i birlikte kullanmak

Python 3.10 ile parantez sözdizimi geldi:

with (
    open('input.txt') as infile,
    open('output.txt', 'w') as outfile,
):
    outfile.write(infile.read())

Sayı dinamikse ExitStack daha pratik:

from contextlib import ExitStack


def process_files(filenames: list):
    with ExitStack() as stack:
        files = [stack.enter_context(open(fname)) for fname in filenames]
        for f in files:
            print(f.readline())

ExitStack her dosyayı otomatik kapatır, sıraya da kendisi karar verir.

Sık karşılaşılan hatalar

Generator'da try/finally unutmak: yield'den sonraki temizlik kodu, exception olursa çalışmaz. finally bloğuna almazsanız sızıntı kaçınılmazdır.
__exit__'te True döndürmek: Bu, blok içindeki tüm exception'ları sessizce yutar. Hata ayıklamayı imkansız hale getirir. Sadece gerçekten 'bu exception'ı buradan öteye iletme' demek istiyorsanız kullanın, o da çoğu zaman istemediğiniz şeydir.
__enter__'da exception fırlatmak ama temizliği yapmamak: Eğer __enter__ ortasında patlarsa __exit__ çağrılmaz. Bu yüzden __enter__ içinde de kendi try/except'inizle yarım kalmış kaynakları kapatın.
Aynı context'i birden fazla kez girmek: Sınıfı yeniden girilebilir (reentrant) yazmadıysanız ikinci with durumu bozar. Gerekiyorsa threading.RLock benzeri bir yapıya bakın.

Kapanış

Bu yazıda hem sınıf tabanlı hem de contextlib ile context manager yazmaya baktık. Bana sorarsanız, kodunuzdaki her tekrar eden try/finally deseni aslında 'beni bir context manager'a çevir' diye bağırıyor. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

Amazon Keyspaces ile yönetimsiz Cassandra deneyimi

2026-06-10T00:00:00Z

Selamlar, bu yazımda Amazon Keyspaces'e bir göz atacağız. Cassandra'yı kendi sunucularında çalıştırmış olanlar bilir; compaction ayarları, gossip protokolü, tombstone temizliği derken ortaya neredeyse tam zamanlı bir iş çıkar. Keyspaces, AWS'nin Cassandra uyumlu yönetilen servisi; CQL'i konuşuyor ama altta cluster yönetimi yok. Lafı uzatmadan başlayayım.

Keyspaces, Cassandra'dan ne kadar farklı?

Keyspaces, Cassandra Query Language'i (CQL) ve resmi Apache sürücülerini destekliyor. Yani mevcut sorgularınızın büyük çoğunluğu hiç dokunmadan çalışır. Ama bazı özelliklerde duvara toslayabilirsiniz:

Lightweight transaction (LWT) desteği kısıtlı; bazı operasyonlarda IF NOT EXISTS çalışmıyor.
User-defined type (UDT), user-defined function ve materialized view yok.
Secondary index desteklenmiyor (bunun yerine custom indexler var).
BATCH ifadesi tek tabloya sınırlı; çok tablolu batch yazılamaz.
Tunable consistency yok. Yazmalarda LOCAL_QUORUM, okumalarda LOCAL_ONE veya LOCAL_QUORUM ile yetiniyorsunuz.

Karşılığında node yönetimi, replikasyon faktörü, kapasite planlaması gibi başlıkları unutuyorsunuz. Bence ekip küçükse bu trade-off neredeyse her zaman mantıklı.

Keyspace ve tablo oluşturma

Cluster provision etmeye gerek yok. Bir keyspace açıyorsunuz, içine tabloları ekliyorsunuz. AWS CLI ile şöyle:

aws keyspaces create-keyspace \
  --keyspace-name my_application

aws keyspaces get-keyspace --keyspace-name my_application

Tablo tarafında JSON şema verebilir ya da CQL ile gidebilirsiniz. Cassandra'dan geliyorsanız ikincisi daha tanıdık gelir:

CREATE TABLE my_application.users (
    user_id uuid,
    email text,
    name text,
    created_at timestamp,
    status text,
    PRIMARY KEY (user_id)
);

SigV4 ile Python'dan bağlanmak

Keyspaces'e iki yoldan bağlanabilirsiniz: IAM'de oluşturulan service-specific credential ya da SigV4 plugin'i. Production için bence SigV4 daha temiz; uzun ömürlü parola tutmuyorsunuz, IAM rolünüzü olduğu gibi kullanıyorsunuz.

Bağlanmadan önce Starfield kök sertifikasını indirmeniz gerekiyor; Keyspaces TLS şart koşuyor:

curl https://certs.secureserver.net/repository/sf-class2-root.crt -O

Sonrası standart Cassandra sürücüsü:

from cassandra.cluster import Cluster
from ssl import SSLContext, PROTOCOL_TLSv1_2, CERT_REQUIRED
from cassandra_sigv4.auth import SigV4AuthProvider
import boto3

ssl_context = SSLContext(PROTOCOL_TLSv1_2)
ssl_context.load_verify_locations('sf-class2-root.crt')
ssl_context.verify_mode = CERT_REQUIRED

boto_session = boto3.Session(region_name='us-east-1')
auth_provider = SigV4AuthProvider(boto_session)

cluster = Cluster(
    ['cassandra.us-east-1.amazonaws.com'],
    ssl_context=ssl_context,
    auth_provider=auth_provider,
    port=9142,
)

session = cluster.connect()
print('Keyspaces bagli')

Burada dikkat: port 9142, klasik Cassandra'nın 9042'sinden farklı. Hata alıyorsanız ilk bakacağınız yer bu.

Veriyle çalışmak

Bağlantıyı kurduk, şimdi tipik bir zaman serisi tablosuna bir-iki kayıt yazalım:

session.execute("""
    CREATE KEYSPACE IF NOT EXISTS my_application
    WITH REPLICATION = {'class': 'SingleRegionStrategy'}
""")
session.set_keyspace('my_application')

session.execute("""
    CREATE TABLE IF NOT EXISTS events (
        device_id text,
        event_date date,
        event_time timestamp,
        event_type text,
        payload text,
        PRIMARY KEY ((device_id, event_date), event_time)
    ) WITH CLUSTERING ORDER BY (event_time DESC)
""")

Partition key'e event_date koymamızın sebebi şu: tek bir cihazın yıllarca biriken kaydı tek partition'a düşerse partition şişer. Tarihle parçalayınca her gün için ayrı bir partition oluyor, bu da Keyspaces'in 1 GB altı partition önerisine uyuyor.

Kapasite modları

İki seçenek var. On-demand, isteğe göre ölçekleniyor; öngöremediğiniz, ani yükselen iş yükleri için iyi. Provisioned ise saniyede beklediğiniz okuma/yazma birimini siz tanımlıyorsunuz, auto-scaling de açabiliyorsunuz. Tahmin edilebilir trafiklerde provisioned belirgin biçimde ucuza geliyor; şahsi kanaatim, gündüzleri sabit yük taşıyan API'ler için doğrudan provisioned'a gitmek mantıklı.

PITR (point-in-time recovery) son 35 güne kadar restore vermenizi sağlıyor; tabloyu oluştururken ya da sonra update-table ile açabiliyorsunuz. Açık olsun, kötü bir gün hayat kurtarır.

Sık karşılaşılan tuzaklar

9042 portuyla bağlanmaya çalışmak: Keyspaces 9142'yi dinliyor. Yanlış port verirseniz timeout alırsınız.
TLS'siz bağlantı denemek: Keyspaces düz TCP kabul etmiyor. Sertifika dosyasını yüklemeden cluster connect() patlar.
Büyük IN listeleri kullanmak: Arka planda her değer için ayrı partition okuması yapılır, throttle yersiniz. Sürücü zaten paralel çalışıyor, tek tek sorgu atın.
LWT'ye güvenmek: Cassandra'da çalışan IF NOT EXISTS mantığı Keyspaces'te her yerde geçerli değil. Tasarımı LWT etrafına kurmadan önce hedef tabloyla deneyin.
CloudWatch'a bakmamak: ThrottledRequests ve SystemErrors metrikleri AWS/Cassandra altında yayınlanıyor; bu ikisine alarm koymadan production'a almayın.

Kapanış

Keyspaces, ekibiniz Cassandra biliyor ama operasyon yükünü taşımak istemiyorsa oldukça rahatlatıcı bir servis. Ben olsam yine de UDT, materialized view ve LWT kullanan kod yollarını listeleyip, geçişten önce bunları test ortamında bir tarayışla doğrulardım. Umarım faydalı olur, bir sonraki yazıda görüşmek üzere.

Python ve SQL

ClickHouse ve PostgreSQL Arasinda Cift Yonlu Senkronizasyon

Mimari nasıl kurguluyoruz?#

Yön 1: PostgreSQL'den ClickHouse'a#

Yön 2: ClickHouse'tan PostgreSQL'e geri yazma#

Replikasyon dongusunu nasıl kırarız?#

Agregasyonu zamanlamak#

Sık karşılaşılan tuzaklar#

Doğrulama#

Kapanış#

Python ile Redis: Pratik Desenler ve Tuzaklar

redis-py ile baglanti: gorunmeyen detay#

Cache decorator: kisa ama dogru#

Pipeline: ag gidis donusunden tasarruf#

Async tarafi#

Sik karsilasilan tuzaklar#

Kapanis#

Python, Node.js ve Go ile ClickHouse Bağlantısı

Python ile clickhouse-connect#

Node.js ile @clickhouse/client#

Go ile clickhouse-go v2#

Sık karşılaşılan hatalar#

Doğrulama#

Kapanış#

Kubernetes Dağıtımı Seçimi: Hangi Tat Hangi Ekibe Yakışır

Dort ana tat#

Upstream DIY: zorlu ama ozgur#

Managed bulut: en hizli baslangic#

Kurumsal platformlar: paragrafli yollar#

Hafif ve edge dagitimlari#

Pilot calismadan karar vermeyin#

Sik karsilasilan tuzaklar#

Hizli oneriler#

Kapanis#

PostgreSQL okuma replikaları ile ölçekleme rehberi

Okuma replikası nedir?#

Primary tarafında ayar#

Replika kurulumu#

Trafiği yönlendirme#

Replikasyon gecikmesi#

Sık karşılaşılan tuzaklar#

Doğrulama#

Kapanış#

Python List Comprehension ile Daha Temiz Kod

List Comprehension Nedir?#

Filtreleme ve Dönüşüm#

İç İçe Döngüler#

Dict ve Set Comprehension#

Generator Expression: Hafıza Dostu Akrabası#

Performans#

Sık Karşılaşılan Hatalar#

Kapanış#

Python'da JSON Dosyalarını Okumak ve Yazmak

json modülünün dört kapısı#

Yazarken biraz nezaket: indent ve ensure_ascii#

Hatalari ciddiye almak#

datetime gibi yabancilar#

Buyuk dosyalar icin streaming#

Sik karsilasilan tuzaklar#

Kapanis#

Terratest ile GCP Terraform Modullerini Gercekten Test Etmek

Terratest neden?#

Iskelet kurmak#

Cloud Run modulu icin gercek bir test#

Hizli testler: validate ve plan#

Sik karsilasilan tuzaklar#

Dogrulama#

Kapanis#

ClickHouse Bitmap Aralıklarını bitmapMin ve bitmapMax ile Bulmak

bitmapMin ve bitmapMax nedir?#

Segmentin en eski ve en yeni kullanıcısı#

Oturum içi olay aralığı#

Seyrek kohortları bulmak#

groupBitmap toplulastirmasi ile birlikte#

Sık karşılaşılan tuzaklar#

Kapanış#

MySQL JSON_REPLACE ile Güvenli Alan Güncelleme

JSON_REPLACE Nedir?#

Basit Örnekler#

JSON_REPLACE, JSON_SET ve JSON_INSERT Farkı#

Mimari nasıl kurguluyoruz?

Yön 1: PostgreSQL'den ClickHouse'a

Yön 2: ClickHouse'tan PostgreSQL'e geri yazma

Replikasyon dongusunu nasıl kırarız?

Agregasyonu zamanlamak

Sık karşılaşılan tuzaklar

Doğrulama

Kapanış

redis-py ile baglanti: gorunmeyen detay

Cache decorator: kisa ama dogru

Pipeline: ag gidis donusunden tasarruf

Async tarafi

Sik karsilasilan tuzaklar

Kapanis

Python ile clickhouse-connect

Node.js ile @clickhouse/client

Go ile clickhouse-go v2

Sık karşılaşılan hatalar

Doğrulama

Kapanış

Dort ana tat

Upstream DIY: zorlu ama ozgur

Managed bulut: en hizli baslangic

Kurumsal platformlar: paragrafli yollar

Hafif ve edge dagitimlari

Pilot calismadan karar vermeyin

Sik karsilasilan tuzaklar

Hizli oneriler

Kapanis

Okuma replikası nedir?

Primary tarafında ayar

Replika kurulumu

Trafiği yönlendirme

Replikasyon gecikmesi

Sık karşılaşılan tuzaklar

Doğrulama

Kapanış

List Comprehension Nedir?

Filtreleme ve Dönüşüm

İç İçe Döngüler

Dict ve Set Comprehension

Generator Expression: Hafıza Dostu Akrabası

Performans

Sık Karşılaşılan Hatalar

Kapanış

json modülünün dört kapısı

Yazarken biraz nezaket: indent ve ensure_ascii

Hatalari ciddiye almak

datetime gibi yabancilar

Buyuk dosyalar icin streaming

Sik karsilasilan tuzaklar

Kapanis

Terratest neden?

Iskelet kurmak

Cloud Run modulu icin gercek bir test

Hizli testler: validate ve plan

Sik karsilasilan tuzaklar

Dogrulama

Kapanis

bitmapMin ve bitmapMax nedir?

Segmentin en eski ve en yeni kullanıcısı

Oturum içi olay aralığı

Seyrek kohortları bulmak

groupBitmap toplulastirmasi ile birlikte

Sık karşılaşılan tuzaklar

Kapanış

JSON_REPLACE Nedir?

Basit Örnekler

JSON_REPLACE, JSON_SET ve JSON_INSERT Farkı

Tablo Üzerinde Pratik Kullanım

Koşullu Güncelleme

Sık Karşılaşılan Hatalar

Kapanış

Dynamic blok nedir, ne işe yarar?

IAM policy: statement içinde condition

ECS service: birden fazla placement stratejisi

Kubernetes deployment: container içinde port ve env

Blok değil, map argümanı: CloudWatch örneği

Sık karşılaşılan tuzaklar

Kapanış