Amazon Keyspaces ile yönetimsiz Cassandra deneyimi

· Berk Avcı · 4 dk okuma · AWS , Cassandra , NoSQL , Veritabanı

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.