GCP Cloud SQL ile PostgreSQL Kurulumu ve Yapılandırması

Tarafındankomut
0 Comments

Google Cloud Platform’da PostgreSQL veritabanı kurmak, özellikle ilk kez yapıyorsanız, onlarca seçenek ve parametre arasında kaybolmak oldukça kolay. Hangi tier’ı seçmem lazım, backup nasıl ayarlayayım, bağlantı güvenliğini nasıl sağlayım gibi sorular kafanızı karıştırabilir. Bu yazıda, sıfırdan başlayıp production’a hazır bir Cloud SQL PostgreSQL instance’ı kuracağız ve bunu yaparken gerçek dünya senaryolarını da göz önünde bulunduracağız.

Başlamadan Önce: Gereksinimler

Öncelikle birkaç şeyin hazır olması gerekiyor. GCP hesabınızın aktif olması ve faturalama ayarlarının yapılmış olması şart. Ayrıca gcloud CLI aracını da kurmanızı şiddetle tavsiye ediyorum, çünkü bazı işlemleri konsoldan yapmak yerine komut satırından yapmak hem daha hızlı hem de tekrarlanabilir olması açısından çok daha mantıklı.

gcloud kurulumu yaptıktan sonra projenizi ayarlayın:

# gcloud CLI kurulumu sonrası kimlik doğrulama
gcloud auth login

# Kullanacağınız projeyi ayarlayın
gcloud config set project PROJE_ID_SINIZ

# Gerekli API'leri aktif edin
gcloud services enable sqladmin.googleapis.com
gcloud services enable servicenetworking.googleapis.com

Cloud SQL API’yi aktif etmeden hiçbir şey yapamayacaksınız, bu yüzden bu adımı atlamayın. servicenetworking.googleapis.com ise Private IP kullanacaksanız zorunlu.

Cloud SQL Instance Oluşturma

Konsol Üzerinden Kurulum

GCP Console’da SQL menüsüne girip “Create Instance” butonuna tıklayın. PostgreSQL seçeneğini seçin. Karşınıza bir form gelecek, bu formdaki kritik alanları tek tek inceleyelim.

Instance ID: Bu isim değiştirilemez, dikkatli seçin. prod-db-01 gibi anlamlı bir isim kullanın.

Password: Root kullanıcısı için güçlü bir şifre belirleyin. Bu şifreyi mutlaka bir password manager’a kaydedin.

Database version: Mümkün olduğunca güncel bir versiyon seçin. Bu yazıyı yazarken PostgreSQL 15 stabil sürümdü.

Region ve Zone: Uygulamanızın koştuğu region ile aynı yeri seçin. Farklı region’lara bağlantı hem yavaş hem de pahalı olabilir.

gcloud CLI ile Instance Oluşturma

Benim tercihim her zaman CLI’dan yapmak. Hem script’e dökülebilir hem de ne yaptığınız netleşir:

gcloud sql instances create prod-db-01 
  --database-version=POSTGRES_15 
  --tier=db-custom-2-7680 
  --region=europe-west1 
  --storage-type=SSD 
  --storage-size=50GB 
  --storage-auto-increase 
  --backup-start-time=02:00 
  --enable-bin-log 
  --retained-backups-count=7 
  --availability-type=REGIONAL 
  --maintenance-window-day=SUN 
  --maintenance-window-hour=3 
  --no-assign-ip

Bu komuttaki parametreleri açıklayalım:

  • –tier: Makine tipi. db-custom-2-7680 demek 2 vCPU ve 7.5GB RAM demek. İhtiyacınıza göre özelleştirebilirsiniz.
  • –storage-auto-increase: Disk dolunca otomatik genişlesin, production’da bu özelliği mutlaka açın.
  • –availability-type=REGIONAL: Yüksek erişilebilirlik için standby instance oluşturur, failover otomatik olur.
  • –no-assign-ip: Public IP atanmasın, güvenlik açısından önemli.
  • –retained-backups-count=7: 7 günlük backup saklansın.

Instance oluşması birkaç dakika sürebilir. Durumunu şöyle kontrol edin:

gcloud sql instances describe prod-db-01 --format="value(state)"

RUNNABLE döndürünce hazır demektir.

Ağ Güvenliği Ayarları

Bu kısım çoğu zaman ihmal ediliyor ama en kritik adımlardan biri. Public IP açmak yerine Private IP kullanmanızı kesinlikle öneririm.

Private IP Konfigürasyonu

VPC’niz ile Cloud SQL arasında özel bir bağlantı kurmanız gerekiyor. Buna Private Service Connection deniyor:

# VPC'niz için IP aralığı ayırın
gcloud compute addresses create google-managed-services-default 
  --global 
  --purpose=VPC_PEERING 
  --prefix-length=16 
  --network=default

# VPC Peering bağlantısını oluşturun
gcloud services vpc-peerings connect 
  --service=servicenetworking.googleapis.com 
  --ranges=google-managed-services-default 
  --network=default

Ardından instance’ınıza Private IP ekleyin:

gcloud sql instances patch prod-db-01 
  --network=projects/PROJE_ID_SINIZ/global/networks/default

Bu işlem sonrası instance’ınıza sadece aynı VPC içindeki makinelerden erişilebilecek. GKE cluster’ınız, Compute Engine instance’larınız ya da Cloud Run servisleriniz bu VPC içindeyse doğrudan bağlanabilirler.

Cloud SQL Proxy Kullanımı

Eğer local geliştirme ortamınızdan ya da farklı bir yerde çalışan uygulamanızdan bağlanmak istiyorsanız, Cloud SQL Auth Proxy kullanın. Bu, Google’ın resmi ve güvenli çözümü:

# Cloud SQL Auth Proxy indirin (Linux)
curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.6.0/cloud-sql-proxy.linux.amd64
chmod +x cloud-sql-proxy

# Proxy'yi başlatın
./cloud-sql-proxy PROJE_ID_SINIZ:europe-west1:prod-db-01 
  --port=5432 
  --credentials-file=/path/to/service-account.json

Proxy çalıştıktan sonra uygulamanız localhost:5432 adresine bağlanır, proxy bu trafiği güvenli şekilde Cloud SQL’e iletir. Sertifika yönetimini otomatik yapar, IAM ile kimlik doğrulama sağlar.

Veritabanı ve Kullanıcı Yönetimi

Instance hazır olduktan sonra veritabanı ve kullanıcıları oluşturmak gerekiyor. Her uygulama için ayrı bir kullanıcı ve veritabanı oluşturmak en iyi pratik.

# Yeni veritabanı oluştur
gcloud sql databases create myapp_production 
  --instance=prod-db-01
  --charset=UTF8 
  --collation=en_US.UTF8

# Uygulama kullanıcısı oluştur
gcloud sql users create myapp_user 
  --instance=prod-db-01 
  --password=GUCLU_SIFRE_BURAYA

Kullanıcı oluşturduktan sonra bu kullanıcıya sadece ihtiyacı olan izinleri verin. postgres superuser ile uygulama çalıştırmak büyük bir güvenlik riskidir. Bunun için Cloud SQL proxy üzerinden veya doğrudan bağlanarak:

# psql ile bağlanın
psql -h 127.0.0.1 -U postgres -d myapp_production

# Veritabanına connect olup izinleri ayarlayın
# psql içinde çalıştırılacak komutlar
GRANT CONNECT ON DATABASE myapp_production TO myapp_user;
GRANT USAGE ON SCHEMA public TO myapp_user;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO myapp_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO myapp_user;
GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO myapp_user;

Bu şekilde myapp_user sadece o veritabanındaki tablolara erişebilir, sistem tablolarına ya da başka veritabanlarına dokunamaz.

Yedekleme ve Kurtarma Stratejisi

Production veritabanında yedekleme olmadan gidilmez. Cloud SQL’in yedekleme mekanizmasını doğru anlamak önemli.

Otomatik Backup Ayarları

# Backup ayarlarını güncelleyin
gcloud sql instances patch prod-db-01 
  --backup-start-time=01:00 
  --retained-backups-count=14 
  --retained-transaction-log-days=7
  • –backup-start-time: Backupın başlayacağı saat (UTC). Trafiğin en az olduğu saati seçin.
  • –retained-backups-count: Kaç günlük backup tutulsun.
  • –retained-transaction-log-days: Point-in-time recovery için transaction logları kaç gün saklanasın.

Point-in-time recovery (PITR) özelliği sayesinde veritabanını herhangi bir geçmiş ana geri yükleyebilirsiniz. Birisi yanlışlıkla tabloyu truncate ettiyse, tam o andan 5 dakika öncesine dönebilirsiniz. Bu çok kritik bir özellik.

Manuel Backup ve Restore

# Manuel backup al
gcloud sql backups create --instance=prod-db-01

# Mevcut backupları listele
gcloud sql backups list --instance=prod-db-01

# Belirli bir backup'tan restore et
gcloud sql backups restore BACKUP_ID 
  --restore-instance=prod-db-01 
  --backup-instance=prod-db-01

Restore işlemi sırasında instance’a bağlantılar kesilir, bunu göz önünde bulundurun. Production’da restore yapmak yerine önce bir test instance’ı oluşturup restore’u orada test etmek her zaman daha akıllıca.

Performans İzleme ve Optimizasyon

Cloud Monitoring Entegrasyonu

Cloud SQL metrikleri otomatik olarak Cloud Monitoring’e gelir. Önemli metrikleri alarm olarak ayarlayın:

# gcloud ile alert policy oluşturun (JSON policy dosyasıyla)
gcloud alpha monitoring policies create 
  --policy-from-file=alert-policy.json

Takip etmeniz gereken kritik metrikler:

  • database/cpu/utilization: CPU kullanımı yüzde 80’i geçince alarm
  • database/memory/utilization: Bellek kullanımı kritik eşiğe ulaşınca
  • database/disk/utilization: Disk doluluk oranı yüzde 85’i geçince
  • database/postgresql/num_backends: Aktif bağlantı sayısı
  • database/disk/read_ops_count ve write_ops_count: Disk I/O

PostgreSQL Parametrelerini Ayarlama

Cloud SQL’de postgresql.conf dosyasını doğrudan düzenleyemezsiniz ama flags aracılığıyla pek çok parametreyi ayarlayabilirsiniz:

gcloud sql instances patch prod-db-01 
  --database-flags=
max_connections=200,
shared_buffers=2048MB,
effective_cache_size=6144MB,
work_mem=16MB,
maintenance_work_mem=256MB,
checkpoint_completion_target=0.9,
wal_buffers=64MB,
default_statistics_target=100,
random_page_cost=1.1,
effective_io_concurrency=200,
log_min_duration_statement=1000

Bu değerleri instance’ınızın RAM miktarına göre ayarlayın. shared_buffers genellikle toplam RAM’in yüzde 25’i, effective_cache_size ise yüzde 75’i olarak ayarlanır. log_min_duration_statement=1000 değeri 1 saniyeden uzun süren sorguları loglayacak, yavaş sorgu analizinde çok işe yarar.

Query Performans Analizi

Cloud SQL’in Query Insights özelliği, yavaş sorguları ve darboğazları görselleştirmek için harika bir araç. Console’dan SQL > Instance’ınız > Query Insights yolunu izleyin.

Ayrıca psql üzerinden de yavaş sorgu analizi yapabilirsiniz:

# pg_stat_statements extension'ı aktif edin
gcloud sql instances patch prod-db-01 
  --database-flags=cloudsql.enable_pg_cron=on,
pg_stat_statements.track=all

# psql'de extension'ı yükleyin
psql -h 127.0.0.1 -U postgres -d myapp_production -c 
  "CREATE EXTENSION IF NOT EXISTS pg_stat_statements;"

# En yavaş 10 sorguyu listeleyin
psql -h 127.0.0.1 -U postgres -d myapp_production -c 
  "SELECT query, calls, total_exec_time/calls as avg_time, rows
   FROM pg_stat_statements
   ORDER BY avg_time DESC
   LIMIT 10;"

Yüksek Erişilebilirlik ve Read Replica

Read Replica Oluşturma

Okuma yoğunluklu uygulamalar için read replica kurmak performansı ciddi artırır:

gcloud sql instances create prod-db-01-replica 
  --master-instance-name=prod-db-01 
  --region=europe-west1 
  --tier=db-custom-2-7680

Replica oluştuktan sonra uygulama tarafında okuma işlemlerini replica’ya, yazma işlemlerini primary’ye yönlendirin. Bu basit değişiklik bile yoğun okuma altında büyük fark yaratır.

Farklı Region’da Replica

Felaket kurtarma senaryoları için farklı bir region’da replica tutabilirsiniz:

gcloud sql instances create prod-db-01-dr 
  --master-instance-name=prod-db-01 
  --region=europe-west3 
  --tier=db-custom-2-7680

Bu replica’ya primary’den felaket anında promote edebilirsiniz:

gcloud sql instances promote-replica prod-db-01-dr

Bu komut replica’yı bağımsız bir instance’a çevirir. DNS veya bağlantı string’ini güncellemeniz gerekecek, bunu da otomatik yapacak bir mekanizma kurmanız uzun vadede işinizi kolaylaştırır.

Gerçek Dünya Senaryosu: Uygulama Migration

Diyelim ki var olan bir PostgreSQL veritabanını Cloud SQL’e taşıyacaksınız. Benim en çok karşılaştığım senaryo bu. pg_dump ve pg_restore kullanacağız ama dikkat edilmesi gereken noktalar var.

# Kaynak veritabanından dump alın
pg_dump -h KAYNAK_HOST 
  -U postgres 
  -d myapp_production 
  -Fc 
  --no-owner 
  --no-acl 
  -f myapp_production.dump

# Dump'ı GCS bucket'a yükleyin
gsutil cp myapp_production.dump gs://BUCKET_ADINIZ/backups/

# Cloud SQL instance'ına import edin
gcloud sql import pg prod-db-01 
  gs://BUCKET_ADINIZ/backups/myapp_production.dump 
  --database=myapp_production 
  --user=postgres

Migration sırasında dikkat edilmesi gerekenler:

  • –no-owner: Cloud SQL’de superuser kısıtlamaları var, owner bilgisi sorun çıkarabilir.
  • –no-acl: ACL’leri de atlamak daha temiz bir migration sağlar.
  • -Fc: Custom format kullanın, daha hızlı restore eder.
  • Extension’ları önceden oluşturun, dump içindeki extension komutları bazen çalışmaz.

Import işleminin durumunu takip edin:

gcloud sql operations list --instance=prod-db-01 
  --filter="status!=DONE" 
  --format="value(name,operationType,status)"

Maliyet Yönetimi

Cloud SQL maliyetleri göz ardı edilemez. Özellikle HA aktif olduğunda maliyet iki katına çıkar çünkü standby instance de ücretlendirilir. Bazı maliyet optimizasyon ipuçları:

  • Dev/Test ortamları için: Shared-core tier kullanın (db-f1-micro veya db-g1-small). Production için hiç uygun değil ama geliştirme için yeterli.
  • HA’yı sadece production’da açın: Staging’de HA’ya gerek yok.
  • Storage’ı doğru boyutlandırın: --storage-auto-increase açık olsa bile başlangıç boyutunu çok büyük seçmeyin, minimum 10GB bile yeterli olabilir küçük veritabanları için.
  • Kullanılmayan instance’ları durdurun: Test instance’larını gece durdurun.
# Instance'ı durdur (sadece shared-core instance'lar durdurulabilir)
gcloud sql instances patch prod-db-01 --activation-policy=NEVER

# Instance'ı başlat
gcloud sql instances patch prod-db-01 --activation-policy=ALWAYS

Dedicated core instance’lar (custom tier) durdurulamaz, sadece silinebilir. Bu önemli bir kısıtlama.

IAM ile Kimlik Doğrulama

Şifre yerine GCP IAM kimliklerini kullanarak veritabanına bağlanmak çok daha güvenli. Özellikle birden fazla geliştiricinin erişeceği ortamlarda şifre paylaşımı sorun yaratır:

# IAM kullanıcısına Cloud SQL erişimi ver
gcloud projects add-iam-policy-binding PROJE_ID_SINIZ 
  --member="user:[email protected]" 
  --role="roles/cloudsql.client"

# Instance'da IAM auth'u aktif et
gcloud sql instances patch prod-db-01 
  --enable-google-cloud-iam-authentication

Ardından PostgreSQL’de IAM kullanıcısını oluşturun:

gcloud sql users create [email protected] 
  --instance=prod-db-01 
  --type=cloud_iam_user

Bu kullanıcı artık gcloud auth login ile authenticate olduktan sonra şifresiz bağlanabilir. Cloud SQL Proxy bunu otomatik halleder.

Sonuç

Cloud SQL PostgreSQL, doğru kurulduğunda oldukça güçlü ve yönetimi kolay bir çözüm sunuyor. Patch yönetimi, storage yönetimi, fiziksel backup gibi işlemlerle uğraşmaktan kurtuluyorsunuz. Ama bu kolaylık, konfigürasyona dikkat etmemeyi haklı kılmıyor.

Özetlemek gerekirse: Private IP kullanarak başlayın, her uygulama için ayrı kullanıcı ve veritabanı oluşturun, PITR ile birlikte yedeklemeyi doğru ayarlayın, Query Insights’ı aktif tutun ve monitoring alarm’larınızı kurun. Bu beş adımı doğru yaparsanız production’da ciddi sorunla karşılaşma ihtimaliniz büyük ölçüde azalır.

Replica ve HA konularına gelince, bu maliyet-fayda dengesi. Küçük bir uygulama için HA belki gereksiz ama kritik bir sistemde 15 dakikalık downtime’ın maliyeti ne olur, bunu hesaplayın ve karar verin. Cloud SQL bu tür kararları kolaylaştırmak için esnek bir yapı sunuyor, bunu iyi kullanın.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir