Elasticsearch Cluster Kurulumu ve Etkili Shard Yönetimi Stratejileri

Büyük hacimli verilerin indekslenmesi, aranması ve analiz edilmesi için dağıtık bir sistem olan Elasticsearch, doğru mimarilendirilmediğinde performans darboğazlarına yol açabilir. Başarılı bir Elasticsearch kümesi, sadece kurulumla sınırlı değildir; shard yönetimi, veri bütünlüğü ve sorgu performansının temelini oluşturur.

Elasticsearch Küme Mimarisi Temelleri

Bir Elasticsearch kümesi, en az bir düğümden (node) oluşur ancak üretim ortamlarında genellikle birden fazla düğümle çalışırız. Bu düğümler farklı roller üstlenebilir:

• Master Düğümler: Kümenin meta verilerini yönetir, indeks oluşturma/silme gibi küme çapında operasyonları koordine eder. Hafif yüklü ve kararlı olmaları esastır.
• Data Düğümleri: İndekslenmiş veriyi ve shard'ları barındırır. Yüksek CPU, RAM ve I/O kapasitesine sahip olmalıdır.
• Ingest Düğümleri: Dokümanlar indekslenmeden önce ön işleme tabi tutulur (dönüştürme, zenginleştirme).
• Coordinating Düğümler: Sorguları ve bulk isteklerini diğer düğümlere yönlendirir, sonuçları birleştirir. Genellikle istemcilerin bağlandığı düğümlerdir.

Üretim senaryolarında, bu rolleri ayırmak önemlidir. Örneğin, master düğümleri için daha küçük, data düğümleri için daha güçlü instance'lar seçmek maliyet ve performans dengesi sağlar.

AWS Üzerinde Elasticsearch Kümesi Kurulumu

AWS EC2 üzerinde manuel bir kurulum, küme kontrolünü tamamen sizin elinize verir. İşte temel adımlar:

# 1. EC2 Instance'larını Hazırlama (Örn: t3.medium master, m5.xlarge data)#   - AMI seçimi (Ubuntu Server 20.04 LTS veya Amazon Linux 2)#   - IAM Rolü: S3 snapshot yedeklemeleri için S3 erişimi.#   - Güvenlik Grubu: 9200 (HTTP) ve 9300 (transport) portlarına erişime izin verin.#   - Disk Yapılandırması: Data düğümleri için gp3/io2 Block Express gibi yüksek IOPS'lu EBS diskler kullanın.# 2. OpenJDK Kurulumu (Elasticsearch için gerekli)sudo apt updatesudo apt install openjdk-11-jdk# 3. Elasticsearch Kurulumu (DEB paketi)wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -sudo apt install apt-transporthttps_echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-7.x.listsudo apt updatesudo apt install elasticsearch# 4. elasticsearch.yml Yapılandırması (/etc/elasticsearch/elasticsearch.yml)#   - Cluster name: Tüm düğümlerde aynı olmalı.#   - Node name: Her düğüm için benzersiz.#   - Path data: Verilerin depolanacağı dizin. (Örn: /mnt/data/elasticsearch)#   - Network host: 0.0.0.0 (tüm arayüzlerden erişime izin verir, güvenlik grubu ile kısıtlayın)#   - Discovery seed hosts: Diğer düğümlerin IP adresleri veya DNS adları.#   - Cluster initial master nodes: Master olabilecek düğümlerin listesi.cluster.name: my-production-clusternode.name: node-1path.data: /var/lib/elasticsearchnetwork.host: 0.0.0.0discovery.seed_hosts: ["10.0.0.4", "10.0.0.5", "10.0.0.6"]cluster.initial_master_nodes: ["node-1", "node-2", "node-3"]node.roles: [ master, data ] # veya [ master ], [ data ] vb.# 5. Sistemi Başlatma ve Etkinleştirme_sudo systemctl enable elasticsearchsudo systemctl start elasticsearch

Bu temel kurulum sonrası JVM heap size, dosya tanımlayıcı limitleri gibi işletim sistemi ayarlarının da optimize edilmesi gerekir.

Shard Yönetimi: Performans ve Dayanıklılığın Anahtarı

Shard'lar, Elasticsearch'in veriyi dağıtma ve paralel işleme kapasitesini sağlayan temel birimlerdir. Bir indeks, bir veya daha fazla primary shard'dan oluşur ve her primary shard'ın sıfır veya daha fazla replica shard'ı olabilir.

Shard Boyutlandırma ve Sayısı

Doğru shard boyutunu ve sayısını belirlemek kritik öneme sahiptir. Çok küçük shard'lar, kaynak israfına (her shard'ın kendi overhead'i vardır) ve çok fazla açık dosya hatasına yol açabilir. Çok büyük shard'lar ise rebalancing ve kurtarma sürelerini uzatır.

• İdeal Boyut: Genellikle 10GB ile 50GB arası bir primary shard boyutu önerilir.
• Shard Sayısı: Kümedeki data düğümü sayısı ve her düğümün kapasitesi ile orantılı olmalıdır. Her data düğümü, belirli sayıda shard'ı barındırabilir. Bir düğümde çok fazla shard olması, JVM heap kullanımını artırır ve performansı düşürür.

Üretim Senaryosu: Bir e-ticaret platformunun ürün katalogunu indekslediğinizi düşünelim. Günde yüz binlerce ürün güncellemesi ve milyonlarca arama sorgusu alıyor. Başlangıçta 100GB'lık bir indeksi 5 primary shard (20GB her biri) ve 1 replica ile başlattınız. Ancak zamanla indeks boyutu büyüdü ve sorgu performansı düştü. Shard boyutları 80GB'a ulaştığında, refresh ve merge operasyonları uzun sürmeye başladı. Bu durumda, daha küçük boyutlu yeni indeksler oluşturarak (örneğin, aylık indeksler) veya mevcut indeksi reindex ederek shard sayısını artırmak çözüm olabilir.

Replica Shard'ların Rolü

Replica shard'lar iki temel fayda sağlar:

1. Yüksek Erişilebilirlik: Bir data düğümü çöktüğünde, replica shard'lar devreye girer ve veri kaybı olmadan servisin devamlılığını sağlar.
2. Sorgu Yükünü Dağıtma: Okuma (arama) istekleri, hem primary hem de replica shard'lara dağıtılarak sorgu throughput'unu artırır.

Genellikle üretim ortamlarında en az 1 replica shard (index.number_of_replicas: 1) kullanılması önerilir.

Index Lifecycle Management (ILM) ile Otomatik Yönetim

Zaman bazlı indeksler (loglar, metrikler) için ILM, shard yönetimini otomatikleştiren güçlü bir araçtır. ILM politikaları, indekslerin yaşam döngüsünü (Hot, Warm, Cold, Delete) tanımlar:

• Hot: Yeni verinin yazıldığı, aktif sorgulanan faz. Yüksek performanslı depolama gerektirir.
• Warm: Veri hala aranıyor ancak yeni yazma yok. Daha az performanslı, daha ucuz depolamaya taşınabilir.
• Cold: Nadiren erişilen, arşivlenmiş veri. Çok ucuz depolama ve daha yavaş sorgular kabul edilebilir.
• Delete: Verinin silindiği faz.

Gerçek Senaryo: Bir mikroservis mimarisindeki tüm uygulama loglarını Elasticsearch'e gönderiyorsunuz. Her gün yeni bir indeks oluşturuluyor (logs-2023-10-27). ILM politikası ile:

PUT _ilm/policy/my_log_policy{  "policy": {    "phases": {      "hot": {        "actions": {          "rollover": {            "max_age": "1d",            "max_docs": 100000000,            "max_size": "50gb"          }        }      },      "warm": {        "min_age": "7d",        "actions": {          "forcemerge": {            "max_num_segments": 1          },          "shrink": {            "number_of_shards": 1          }        }      },      "cold": {        "min_age": "30d",        "actions": {          "freeze": {}        }      },      "delete": {        "min_age": "90d",        "actions": {          "delete": {}        }      }    }  }}

Bu politika, 1 gün veya 50GB'a ulaşan indeksleri otomatik olarak roll-over yapar, 7 gün sonra Warm faza geçirir (segmentleri birleştirir, shard sayısını düşürür), 30 gün sonra Cold faza (salt okunur) ve 90 gün sonra siler. Bu, depolama maliyetlerini düşürürken performansı optimize eder.

Shard Dengesizlikleri ve Çözümleri

Shard'ların düğümler arasında dengesiz dağılması, bir düğümün aşırı yüklenmesine, diğerlerinin ise boş kalmasına neden olabilir. Bu, sorgu performansını olumsuz etkiler ve disk doluluğu riskini artırır.

Tanı: Kibana'daki Stack Monitoring veya _cat/allocation API'si ile shard dağılımını izleyin:

GET _cat/allocation?v

Çözüm: Elasticsearch, normalde shard'ları otomatik olarak dengelemeye çalışır. Ancak, düğüm karakteristikleri veya geçici durumlar (örneğin, bir düğümün uzun süre çevrimdışı kalması) dengesizliğe yol açabilir. Mevcut shard'ları manuel olarak belirli düğümlere taşımak için Allocation Awareness veya Reroute API'si kullanılabilir, ancak bu dikkatli yapılmalıdır.

POST _cluster/reroute{  "commands" : [ {      "move" : {        "index" : "my-index", "shard" : 0,        "from_node" : "node-1", "to_node" : "node-2"      }    }  ]}

Bu tür operasyonlar, küme üzerindeki yükü artırabileceğinden genellikle planlı bakım pencerelerinde veya otomatik ILM/shard ayarları ile önlenerek yapılmalıdır.

Sonuç

Elasticsearch kümesi kurulumu, sadece binary'leri çalıştırmakla bitmez. Küme mimarisi tasarımı, donanım seçimi ve özellikle etkili shard yönetimi stratejileri, üretim ortamlarında kararlı, yüksek performanslı ve ölçeklenebilir bir sistem için olmazsa olmazdır. ILM gibi otomasyon araçlarını kullanarak operasyonel yükü azaltırken, shard boyutlandırma ve dengeleme konularında proaktif olmak, uzun vadeli başarıyı garantileyecektir.