G\u00fcn\u00fcm\u00fcz\u00fcn y\u00fcksek performansl\u0131 ve s\u00fcrekli eri\u015filebilir uygulamalar\u0131 i\u00e7in da\u011f\u0131t\u0131k sistemler vazge\u00e7ilmez bir mimari haline gelmi\u015ftir. Ancak, bu karma\u015f\u0131k ortamlarda veri tutarl\u0131l\u0131\u011f\u0131 ve sistem g\u00fcvenilirli\u011fi nas\u0131l sa\u011flan\u0131r? Raft konsens\u00fcs algoritmas\u0131, da\u011f\u0131t\u0131k sistemlerdeki bu temel zorluklar\u0131 a\u015farak, birden fazla sunucu aras\u0131nda g\u00fcvenilir bir \u015fekilde anla\u015fmaya var\u0131lmas\u0131n\u0131 nas\u0131l temin eder? Bu makale, da\u011f\u0131t\u0131k sistemlerin temel prensiplerinden ba\u015flayarak, Raft’\u0131n derinliklerine inecek ve ger\u00e7ek d\u00fcnya senaryolar\u0131yla bu g\u00fc\u00e7l\u00fc algoritman\u0131n \u00f6nemini g\u00f6zler \u00f6n\u00fcne serecektir.<\/p>\n
Modern yaz\u0131l\u0131m d\u00fcnyas\u0131nda, uygulamalar\u0131n s\u00fcrekli olarak daha fazla kullan\u0131c\u0131ya hizmet vermesi, daha b\u00fcy\u00fck veri setlerini i\u015flemesi ve kesintisiz \u00e7al\u0131\u015fmas\u0131 beklenir. Geleneksel tek sunuculu (monolitik) mimariler, bu talepleri kar\u015f\u0131lamakta yetersiz kalabilir. \u0130\u015fte tam bu noktada, i\u015f y\u00fck\u00fcn\u00fc birden fazla fiziksel veya sanal makineye da\u011f\u0131tan da\u011f\u0131t\u0131k sistemler (distributed systems) devreye girer. Bir da\u011f\u0131t\u0131k sistem, a\u011f \u00fczerinden ileti\u015fim kurarak ortak bir hedefe ula\u015fan ba\u011f\u0131ms\u0131z bilgisayar d\u00fc\u011f\u00fcmlerinden (nodes) olu\u015fan bir koleksiyondur. Bu mimari, beraberinde bir\u00e7ok avantaj\u0131 getirirken, ayn\u0131 zamanda kendine \u00f6zg\u00fc zorluklar\u0131 da bar\u0131nd\u0131r\u0131r.<\/p>\n
Da\u011f\u0131t\u0131k sistemlerin sundu\u011fu ba\u015fl\u0131ca avantajlar aras\u0131nda \u00f6l\u00e7eklenebilirlik (scalability) ilk s\u0131rada yer al\u0131r. Artan kullan\u0131c\u0131 trafi\u011fi veya veri hacmi kar\u015f\u0131s\u0131nda sisteme yeni d\u00fc\u011f\u00fcmler ekleyerek kapasiteyi kolayca art\u0131rabiliriz. Bu, uygulaman\u0131n performans\u0131n\u0131 ve yan\u0131t s\u00fcresini iyile\u015ftirmenin etkili bir yoludur. \u0130kinci \u00f6nemli avantaj ise hata tolerans\u0131d\u0131r (fault tolerance). Sistemdeki bir veya daha fazla d\u00fc\u011f\u00fcm\u00fcn ar\u0131zalanmas\u0131 durumunda bile, di\u011fer d\u00fc\u011f\u00fcmlerin i\u015flevselli\u011fi s\u00fcrd\u00fcrmesi sayesinde uygulaman\u0131n \u00e7al\u0131\u015fmaya devam etmesi sa\u011flan\u0131r. Bu durum, hizmet kesintilerini minimize eder ve kullan\u0131c\u0131 deneyimini olumlu etkiler. Ayr\u0131ca, co\u011frafi da\u011f\u0131t\u0131m (geographical distribution) sayesinde veriler ve servisler farkl\u0131 veri merkezlerine veya b\u00f6lgelere yay\u0131labilir, bu da gecikmeyi azalt\u0131r ve felaket kurtarma senaryolar\u0131nda b\u00fcy\u00fck bir esneklik sunar.<\/p>\n
Ancak, bu avantajlar\u0131n yan\u0131 s\u0131ra, da\u011f\u0131t\u0131k sistemlerin do\u011fas\u0131 gere\u011fi baz\u0131 temel zorluklar da ortaya \u00e7\u0131kar. En kritik sorunlardan biri, veri tutarl\u0131l\u0131\u011f\u0131d\u0131r (data consistency). Birden fazla d\u00fc\u011f\u00fcmde depolanan verilerin her zaman ayn\u0131 ve g\u00fcncel olmas\u0131 nas\u0131l garanti edilebilir? A\u011f gecikmeleri (network latencies) ve k\u0131smi ar\u0131zalar (partial failures), d\u00fc\u011f\u00fcmler aras\u0131ndaki ileti\u015fimi kesintiye u\u011fratabilir veya geciktirebilir, bu da farkl\u0131 d\u00fc\u011f\u00fcmlerin farkl\u0131 bilgilere sahip olmas\u0131na yol a\u00e7abilir. Bu tutars\u0131zl\u0131klar, kritik i\u015f s\u00fcre\u00e7lerinde yanl\u0131\u015f kararlara veya veri bozulmalar\u0131na neden olabilir. Bu ba\u011flamda, CAP Teoremi \u00f6nemli bir \u00e7er\u00e7eve sunar. CAP Teoremi’ne g\u00f6re, bir da\u011f\u0131t\u0131k sistem ayn\u0131 anda tutarl\u0131l\u0131k (Consistency), eri\u015filebilirlik (Availability) ve b\u00f6l\u00fcm tolerans\u0131 (Partition Tolerance) olmak \u00fczere bu \u00fc\u00e7 \u00f6zellikten yaln\u0131zca ikisini tam olarak sa\u011flayabilir. Modern da\u011f\u0131t\u0131k sistemler genellikle a\u011f b\u00f6l\u00fcmlemelerine kar\u015f\u0131 dayan\u0131kl\u0131 olmak zorunda oldu\u011fundan (P), ya tutarl\u0131l\u0131ktan (C) ya da eri\u015filebilirlikten (A) \u00f6d\u00fcn vermek durumunda kal\u0131rlar.<\/p>\n
\u0130\u015fte bu karma\u015f\u0131k ortamda, t\u00fcm d\u00fc\u011f\u00fcmlerin belirli bir durum veya karar \u00fczerinde anla\u015fmas\u0131n\u0131 sa\u011flamak, yani konsens\u00fcse (consensus) varmak hayati \u00f6nem ta\u015f\u0131r. Konsens\u00fcs algoritmalar\u0131, da\u011f\u0131t\u0131k sistemlerin g\u00fcvenilirli\u011fini ve tutarl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flamak i\u00e7in tasarlanm\u0131\u015ft\u0131r. Bu algoritmalar sayesinde, bir d\u00fc\u011f\u00fcm ar\u0131zalansa bile veya a\u011f ge\u00e7ici olarak kesintiye u\u011frasa bile, sistemin genel olarak do\u011fru ve tutarl\u0131 bir \u015fekilde \u00e7al\u0131\u015fmaya devam etmesi m\u00fcmk\u00fcn olur. Konsens\u00fcs, da\u011f\u0131t\u0131k veritabanlar\u0131ndan blok zincirlerine, bulut altyap\u0131s\u0131 y\u00f6netiminden da\u011f\u0131t\u0131k dosya sistemlerine kadar bir\u00e7ok alanda temel bir yap\u0131 ta\u015f\u0131d\u0131r. Bu mekanizmalar olmadan, da\u011f\u0131t\u0131k sistemlerin vadetti\u011fi g\u00fcvenilirlik ve tutarl\u0131l\u0131k seviyesine ula\u015fmak imkans\u0131z hale gelirdi.<\/p>\n
Da\u011f\u0131t\u0131k sistemlerde konsens\u00fcs sa\u011flamak, teorik olarak karma\u015f\u0131k bir problemdir. Tarihsel olarak, bu alandaki en bilinen ve g\u00fc\u00e7l\u00fc algoritmalardan biri Paxos’tur. Ancak Paxos, akademik d\u00fcnyada b\u00fcy\u00fck sayg\u0131 g\u00f6rse de, pratikte anla\u015f\u0131lmas\u0131 ve do\u011fru bir \u015fekilde uygulanmas\u0131 olduk\u00e7a zordur. \u0130\u015fte bu noktada Raft konsens\u00fcs algoritmas\u0131 devreye girer. Raft, da\u011f\u0131t\u0131k sistemlerde konsens\u00fcs problemini \u00e7\u00f6zmek i\u00e7in tasarlanm\u0131\u015f, Paxos’a k\u0131yasla \u00e7ok daha anla\u015f\u0131l\u0131r ve implementasyonu daha kolay bir algoritmad\u0131r. “Anla\u015f\u0131labilirlik” Raft’\u0131n temel tasar\u0131m hedeflerinden biridir ve bu hedef, algoritman\u0131n geni\u015f \u00e7apta benimsenmesinde kilit rol oynam\u0131\u015ft\u0131r. Raft’\u0131n temel amac\u0131, bir dizi sunucu aras\u0131nda tek bir karara var\u0131lmas\u0131n\u0131, bu karar\u0131n kal\u0131c\u0131 olmas\u0131n\u0131 ve sistemin hata toleransl\u0131 \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flamakt\u0131r. Bu sayede, t\u00fcm d\u00fc\u011f\u00fcmlerin ayn\u0131 s\u0131ral\u0131 komut dizisi \u00fczerinde anla\u015ft\u0131\u011f\u0131 bir da\u011f\u0131t\u0131k durum makinesi (distributed state machine) olu\u015fturulabilir.<\/p>\n
Raft algoritmas\u0131, \u00fc\u00e7 temel rol etraf\u0131nda d\u00f6ner: Lider (Leader), Aday (Candidate) ve Takip\u00e7i (Follower). Herhangi bir anda, bir Raft k\u00fcmesinde yaln\u0131zca bir lider bulunabilir. Lider, t\u00fcm istemci isteklerini i\u015flemekten, log girdilerini takip\u00e7ilere kopyalamaktan ve commit (taahh\u00fct) etme karar\u0131n\u0131 vermekten sorumludur. Takip\u00e7iler ise liderden gelen istekleri pasif olarak dinler ve gelen log girdilerini kendi kopyalar\u0131na ekler. E\u011fer bir takip\u00e7i belirli bir s\u00fcre liderden kalp at\u0131\u015f\u0131 (heartbeat) mesaj\u0131 alamazsa, liderin ba\u015far\u0131s\u0131z oldu\u011funu varsayar ve aday rol\u00fcne ge\u00e7erek yeni bir lider se\u00e7imi ba\u015flat\u0131r. Aday, lider olmak i\u00e7in di\u011fer d\u00fc\u011f\u00fcmlerden oy ister ve \u00e7o\u011funlu\u011fun oyunu alabilirse liderli\u011fe y\u00fckselir.<\/p>\n
Raft, konsens\u00fcs problemini \u00fc\u00e7 daha k\u00fc\u00e7\u00fck ve y\u00f6netilebilir alt probleme ay\u0131rarak \u00e7\u00f6z\u00fcme ula\u015f\u0131r: Lider se\u00e7imi (Leader Election), Log replikasyonu (Log Replication) ve G\u00fcvenlik (Safety). Bu ayr\u0131m, algoritman\u0131n anla\u015f\u0131lmas\u0131n\u0131 ve do\u011fru bir \u015fekilde uygulanmas\u0131n\u0131 kolayla\u015ft\u0131r\u0131r. Lider se\u00e7imi, k\u00fcmenin her zaman bir lideri olmas\u0131n\u0131 ve bu liderin ar\u0131zalanmas\u0131 durumunda h\u0131zl\u0131ca yeni bir liderin atanmas\u0131n\u0131 sa\u011flar. Log replikasyonu, t\u00fcm sunucular\u0131n ayn\u0131 komut dizisine sahip olmas\u0131n\u0131 ve bu komutlar\u0131n kal\u0131c\u0131 olarak depolanmas\u0131n\u0131 garanti eder. Son olarak, g\u00fcvenlik kurallar\u0131, sistemin asla tutars\u0131z bir duruma d\u00fc\u015fmemesini, yani commit edilmi\u015f verilerin asla geri al\u0131nmamas\u0131n\u0131 veya de\u011fi\u015ftirilmemesini garanti eder. Bu \u00fc\u00e7 temel bile\u015fen, Raft’\u0131n sa\u011flam ve g\u00fcvenilir bir konsens\u00fcs algoritmas\u0131 olarak i\u015flev g\u00f6rmesini sa\u011flar. \u00d6zellikle etcd, Kubernetes, Consul gibi pop\u00fcler da\u011f\u0131t\u0131k sistemlerde Raft’\u0131n kullan\u0131lmas\u0131, algoritman\u0131n pratik de\u011ferini ve etkinli\u011fini kan\u0131tlam\u0131\u015ft\u0131r.<\/p>\n
Raft’\u0131n temel ta\u015flar\u0131ndan biri, k\u00fcmenin her zaman i\u015fleyen bir lidere sahip olmas\u0131n\u0131 sa\u011flayan lider se\u00e7imi s\u00fcrecidir. Bu s\u00fcre\u00e7, sistemin hata tolerans\u0131n\u0131 ve eri\u015filebilirli\u011fini do\u011frudan etkiler. Her d\u00fc\u011f\u00fcm, Raft’ta bir “term” (d\u00f6nem) kavram\u0131yla \u00e7al\u0131\u015f\u0131r. Term, bir lider se\u00e7iminin veya bir liderin h\u00fck\u00fcm s\u00fcrd\u00fc\u011f\u00fc zaman dilimini temsil eden artan bir tam say\u0131 de\u011feridir. Her yeni lider se\u00e7imi ba\u015flad\u0131\u011f\u0131nda, term de\u011feri art\u0131r\u0131l\u0131r. Bu, eski ve yeni liderler aras\u0131ndaki kar\u0131\u015f\u0131kl\u0131\u011f\u0131 \u00f6nlemeye yard\u0131mc\u0131 olur.<\/p>\n
T\u00fcm d\u00fc\u011f\u00fcmler ba\u015flang\u0131\u00e7ta takip\u00e7i rol\u00fcndedir. Bir takip\u00e7i, liderden d\u00fczenli aral\u0131klarla “kalp at\u0131\u015f\u0131” (heartbeat) mesajlar\u0131 bekler. Bu kalp at\u0131\u015flar\u0131, liderin hala aktif oldu\u011funu ve g\u00f6revde oldu\u011funu g\u00f6sterir. Her takip\u00e7i d\u00fc\u011f\u00fcm\u00fcnde bir se\u00e7im zaman a\u015f\u0131m\u0131 (election timeout) sayac\u0131 bulunur. E\u011fer bir takip\u00e7i, bu zaman a\u015f\u0131m\u0131 s\u00fcresi i\u00e7inde liderden bir kalp at\u0131\u015f\u0131 veya yeni bir log girdisi alamazsa, liderin ba\u015far\u0131s\u0131z oldu\u011funu veya a\u011f ba\u011flant\u0131s\u0131n\u0131n koptu\u011funu varsayar. Bu durumda, takip\u00e7i rol\u00fcnden aday rol\u00fcne ge\u00e7er ve yeni bir lider se\u00e7imi ba\u015flat\u0131r.<\/p>\n
Aday rol\u00fcne ge\u00e7en d\u00fc\u011f\u00fcm, ilk olarak kendi term de\u011ferini bir art\u0131r\u0131r ve kendisine oy verir. Ard\u0131ndan, k\u00fcmedeki di\u011fer t\u00fcm d\u00fc\u011f\u00fcmlere <\/p>\n
RequestVote RPC<\/code><\/pre>\n (Remote Procedure Call) mesajlar\u0131 g\u00f6nderir. Bu mesajlarda, kendi term de\u011feri, son commit edilmi\u015f log girdisinin indeksi ve term’i gibi bilgiler bulunur. Di\u011fer d\u00fc\u011f\u00fcmler bu iste\u011fi ald\u0131klar\u0131nda, belirli kurallara g\u00f6re oy kullan\u0131p kullanmayacaklar\u0131na karar verirler:<\/p>\n
\n- Bir d\u00fc\u011f\u00fcm, ayn\u0131 term i\u00e7inde yaln\u0131zca bir adaya oy verebilir. Bu, b\u00f6l\u00fcnm\u00fc\u015f oylar\u0131 (split votes) engellemeye yard\u0131mc\u0131 olur.<\/li>\n
- E\u011fer aday\u0131n log’u, oy isteyen d\u00fc\u011f\u00fcm\u00fcn log’undan daha g\u00fcncel veya e\u015fit derecede g\u00fcncel ise (yani aday\u0131n son log girdisinin term’i daha b\u00fcy\u00fck veya term’leri e\u015fitse ve indeksi daha b\u00fcy\u00fckse), oy verir. Bu kural, liderin her zaman en g\u00fcncel log’a sahip olmas\u0131n\u0131 sa\u011flar.<\/li>\n<\/ul>\n
Bir aday, k\u00fcmedeki d\u00fc\u011f\u00fcmlerin \u00e7o\u011funlu\u011fundan (quorum) oy ald\u0131\u011f\u0131nda, liderli\u011fe y\u00fckselir. Lider olduktan sonra, hemen di\u011fer t\u00fcm d\u00fc\u011f\u00fcmlere kalp at\u0131\u015f\u0131 mesajlar\u0131 g\u00f6ndererek yeni lider oldu\u011funu duyurur ve takip\u00e7ilerin se\u00e7im zaman a\u015f\u0131m\u0131n\u0131 s\u0131f\u0131rlamas\u0131n\u0131 sa\u011flar. E\u011fer bir aday, \u00e7o\u011funlu\u011fun oyunu alamazsa (\u00f6rne\u011fin, oylar b\u00f6l\u00fcn\u00fcrse veya ba\u015fka bir aday daha fazla oy al\u0131rsa), se\u00e7im zaman a\u015f\u0131m\u0131 tekrar ba\u015flar ve s\u00fcre\u00e7 yeniden tekrarlan\u0131r. Raft, se\u00e7im zaman a\u015f\u0131m\u0131 s\u00fcrelerini rastgelele\u015ftirerek, birden fazla aday\u0131n ayn\u0131 anda se\u00e7im ba\u015flatmas\u0131n\u0131 ve oylar\u0131n b\u00f6l\u00fcnmesini minimize etmeye \u00e7al\u0131\u015f\u0131r. Bu dinamik s\u00fcre\u00e7, Raft k\u00fcmesinin s\u00fcrekli olarak i\u015flevsel bir lidere sahip olmas\u0131n\u0131 ve hatalara kar\u015f\u0131 dayan\u0131kl\u0131 olmas\u0131n\u0131 sa\u011flar.<\/p>\n
Veri Tutarl\u0131l\u0131\u011f\u0131 \u0130\u00e7in Log Replikasyonu Nas\u0131l \u00c7al\u0131\u015f\u0131r?<\/h3>\n
Raft’\u0131n kalbinde yatan bir di\u011fer kritik mekanizma, t\u00fcm d\u00fc\u011f\u00fcmler aras\u0131nda veri tutarl\u0131l\u0131\u011f\u0131n\u0131 sa\u011flayan log replikasyonudur. Bir da\u011f\u0131t\u0131k sistemde, istemciden gelen her de\u011fi\u015fiklik iste\u011fi (\u00f6rne\u011fin, bir veritaban\u0131na yazma i\u015flemi veya bir yap\u0131land\u0131rma de\u011fi\u015fikli\u011fi), \u00f6nce lider taraf\u0131ndan bir “log girdisi” (log entry) olarak kaydedilir. Bu log girdileri, sistemin durumunu de\u011fi\u015ftiren komutlar\u0131 i\u00e7erir ve s\u0131ral\u0131 bir \u015fekilde tutulur. Her log girdisinin benzersiz bir indeksi ve olu\u015fturuldu\u011fu term de\u011feri bulunur.<\/p>\n
\u0130stemciden gelen bir istek, \u00f6nce lider d\u00fc\u011f\u00fcm\u00fcne ula\u015f\u0131r. Lider, bu iste\u011fi kendi log’una bir girdi olarak ekler (ancak hen\u00fcz commit etmez). Ard\u0131ndan, bu yeni log girdisini k\u00fcmedeki t\u00fcm takip\u00e7i d\u00fc\u011f\u00fcmlere <\/p>\n
AppendEntries RPC<\/code><\/pre>\n mesajlar\u0131 arac\u0131l\u0131\u011f\u0131yla g\u00f6nderir. <\/p>\n
AppendEntries RPC<\/code><\/pre>\n sadece yeni log girdilerini g\u00f6ndermekle kalmaz, ayn\u0131 zamanda liderin aktif oldu\u011funu g\u00f6steren kalp at\u0131\u015f\u0131 mesajlar\u0131 olarak da i\u015flev g\u00f6r\u00fcr. Her <\/p>\n
AppendEntries<\/code><\/pre>\n iste\u011fi, yeni girdilerin yan\u0131 s\u0131ra, liderin son commit edilmi\u015f log girdisinin indeksini de i\u00e7erir. Takip\u00e7iler bu mesaj\u0131 ald\u0131klar\u0131nda, kendi log’lar\u0131ndaki tutarl\u0131l\u0131\u011f\u0131 kontrol ederler. E\u011fer liderin g\u00f6nderdi\u011fi bir \u00f6nceki log girdisi kendi log’lar\u0131nda yoksa veya farkl\u0131 bir term’e aitse, takip\u00e7i bu iste\u011fi reddeder ve liderin belirli bir indeksten itibaren tekrar g\u00f6ndermesini ister. Bu mekanizma, liderin ve takip\u00e7ilerin log’lar\u0131n\u0131n her zaman tutarl\u0131 olmas\u0131n\u0131 sa\u011flar.<\/p>\n
Bir takip\u00e7i, liderden gelen log girdilerini ba\u015far\u0131l\u0131 bir \u015fekilde kendi log’una ekledi\u011finde, lidere bir onay (acknowledgement) g\u00f6nderir. Lider, bir log girdisinin k\u00fcmedeki d\u00fc\u011f\u00fcmlerin \u00e7o\u011funlu\u011fu (quorum) taraf\u0131ndan ba\u015far\u0131l\u0131 bir \u015fekilde kendi log’lar\u0131na kopyaland\u0131\u011f\u0131n\u0131 \u00f6\u011frendi\u011finde, bu log girdisini “commit” (taahh\u00fct) edebilir. Bir log girdisi commit edildi\u011finde, bu, ilgili komutun da\u011f\u0131t\u0131k sistemin durumu i\u00e7in kal\u0131c\u0131 ve geri al\u0131namaz hale geldi\u011fi anlam\u0131na gelir. Lider, commit etti\u011fi log girdisini kendi durum makinesine uygular ve istemciye ba\u015far\u0131l\u0131 bir yan\u0131t d\u00f6ner. Daha sonraki kalp at\u0131\u015f\u0131 veya <\/p>\n
AppendEntries<\/code><\/pre>\n mesajlar\u0131 arac\u0131l\u0131\u011f\u0131yla, lider bu commit edilmi\u015f log girdisinin indeksini takip\u00e7ilere bildirir. Takip\u00e7iler de bu bilgiyi ald\u0131klar\u0131nda, kendi log’lar\u0131ndaki ilgili girdileri commit eder ve kendi durum makinelerine uygularlar.<\/p>\n
Bu s\u00fcre\u00e7, Raft’\u0131n “Leader Completeness” (Liderin Taml\u0131\u011f\u0131) ilkesini de destekler: E\u011fer bir log girdisi belirli bir term’de commit edilmi\u015fse, o term’deki t\u00fcm gelecekteki liderler de o log girdisine sahip olacakt\u0131r. Bu, Raft’\u0131n g\u00fcvenlik \u00f6zelliklerinin temelini olu\u015fturur ve veri kayb\u0131n\u0131 veya tutars\u0131zl\u0131\u011f\u0131n\u0131 \u00f6nler. \u00d6rne\u011fin, bir lider ar\u0131zalan\u0131p yeni bir lider se\u00e7ildi\u011finde, yeni liderin her zaman commit edilmi\u015f t\u00fcm log girdilerine sahip olmas\u0131 garanti edilir, b\u00f6ylece sistemin durumu her zaman do\u011fru bir \u015fekilde ilerler. Bu titiz log replikasyonu ve commit mekanizmas\u0131 sayesinde, Raft, da\u011f\u0131t\u0131k bir ortamda dahi g\u00fc\u00e7l\u00fc tutarl\u0131l\u0131k (strong consistency) sa\u011flayarak g\u00fcvenilir uygulamalar\u0131n temelini olu\u015fturur.<\/p>\n
Raft’\u0131n G\u00fcvenli\u011fini Sa\u011flayan Mekanizmalar Nelerdir?<\/h2>\n
Raft algoritmas\u0131, anla\u015f\u0131l\u0131rl\u0131k kadar g\u00fcvenli\u011fe de b\u00fcy\u00fck \u00f6nem verir. G\u00fcvenlik (Safety), sistemin asla tutars\u0131z bir duruma d\u00fc\u015fmemesi, yani commit edilmi\u015f verilerin asla kaybolmamas\u0131 veya de\u011fi\u015ftirilmemesi anlam\u0131na gelir. Raft, bu g\u00fcvenlik \u00f6zelliklerini sa\u011flamak i\u00e7in bir dizi kural ve mekanizma kullan\u0131r. Bu kurallar, a\u011f gecikmeleri veya d\u00fc\u011f\u00fcm ar\u0131zalar\u0131 gibi olumsuz senaryolarda bile sistemin do\u011fru \u00e7al\u0131\u015fmas\u0131n\u0131 garanti eder.<\/p>\n
Raft’\u0131n en \u00f6nemli g\u00fcvenlik prensiplerinden biri, “Liderin Taml\u0131\u011f\u0131” (Leader Completeness) \u00f6zelli\u011fidir. Bu ilke, e\u011fer bir log girdisi belirli bir term’de commit edilmi\u015fse, o term’deki veya daha sonraki herhangi bir term’deki t\u00fcm liderlerin o log girdisine sahip olaca\u011f\u0131n\u0131 garanti eder. Bu nas\u0131l sa\u011flan\u0131r? Lider se\u00e7imi s\u0131ras\u0131nda bir aday\u0131n lider olabilmesi i\u00e7in, k\u00fcmedeki d\u00fc\u011f\u00fcmlerin \u00e7o\u011funlu\u011fundan oy almas\u0131 gerekir. Oy veren d\u00fc\u011f\u00fcmler, aday\u0131n log’unun kendi log’lar\u0131ndan en az\u0131ndan e\u015fit derecede g\u00fcncel olmas\u0131n\u0131 kontrol ederler. Bu, yeni se\u00e7ilen liderin, k\u00fcmedeki commit edilmi\u015f t\u00fcm log girdilerine sahip olan d\u00fc\u011f\u00fcmlerin en az birini (\u00e7o\u011funluk oyu sayesinde) i\u00e7erece\u011fi anlam\u0131na gelir. Dolay\u0131s\u0131yla, yeni lider, \u00f6nceki term’lerde commit edilmi\u015f t\u00fcm log girdilerine sahip olacakt\u0131r.<\/p>\n
Bir di\u011fer g\u00fcvenlik kural\u0131, liderin yaln\u0131zca kendi term’indeki log girdilerini commit edebilmesidir. Yani, bir lider, \u00f6nceki term’lerden kalma log girdilerini do\u011frudan commit edemez. Bunun yerine, kendi term’inde yeni bir log girdisi olu\u015fturup bunu \u00e7o\u011funlu\u011fa kopyalay\u0131p commit ettikten sonra, bu commit i\u015flemi dolayl\u0131 olarak \u00f6nceki term’lerdeki bekleyen log girdilerinin de commit edilmesini sa\u011flar. Bu kural, lider ar\u0131zaland\u0131\u011f\u0131nda ve yeni bir lider se\u00e7ildi\u011finde, eski term’lerdeki potansiyel tutars\u0131zl\u0131klar\u0131 \u00f6nler ve sistemin tutarl\u0131 bir \u015fekilde ilerlemesini garanti eder. \u00d6rne\u011fin, bir lider ar\u0131zalanmadan \u00f6nce bir log girdisini \u00e7o\u011funlu\u011fa kopyalam\u0131\u015f ancak commit edememi\u015f olabilir. Yeni lider se\u00e7ildi\u011finde, bu log girdisi hala commit edilmemi\u015f durumda kal\u0131r. Yeni lider kendi term’inde yeni bir girdi commit etti\u011finde, bu ayn\u0131 zamanda \u00f6nceki term’deki girdilerin de commit edilmesini tetikler, b\u00f6ylece veri kayb\u0131 olmaz.<\/p>\n
Raft ayr\u0131ca, bir sunucunun commit edilmi\u015f bir log girdisini asla de\u011fi\u015ftirmemesini veya geri almas\u0131n\u0131 garanti eder. Bir log girdisi bir kez commit edildi\u011finde, kal\u0131c\u0131d\u0131r. Bu, da\u011f\u0131t\u0131k durum makinesinin do\u011frulu\u011fu i\u00e7in kritik \u00f6neme sahiptir. Lider, log girdilerini takip\u00e7ilere kopyalarken, takip\u00e7iler log’lar\u0131ndaki \u00e7ak\u0131\u015fan girdileri liderin log’uyla e\u015fle\u015fecek \u015fekilde g\u00fcnceller. Bu, tutars\u0131z log’lar\u0131n liderin log’uyla ayn\u0131 hale getirilmesini sa\u011flar, ancak bu i\u015flem sadece hen\u00fcz commit edilmemi\u015f girdiler i\u00e7in ge\u00e7erlidir. Commit edilmi\u015f girdiler \u00fczerinde herhangi bir de\u011fi\u015fiklik yap\u0131lmas\u0131na izin verilmez.<\/p>\n
\u00d6zetle, Raft’\u0131n g\u00fcvenlik mekanizmalar\u0131, lider se\u00e7iminin do\u011fru \u015fekilde yap\u0131lmas\u0131n\u0131, liderin her zaman en g\u00fcncel ve commit edilmi\u015f verilere sahip olmas\u0131n\u0131 ve commit edilmi\u015f verilerin asla kaybolmamas\u0131n\u0131 veya de\u011fi\u015ftirilmemesini sa\u011flayarak, da\u011f\u0131t\u0131k sistemlerdeki en temel g\u00fcvenilirlik endi\u015felerini ortadan kald\u0131r\u0131r. Bu sayede, Raft kullanan uygulamalar, a\u011f ar\u0131zalar\u0131 ve d\u00fc\u011f\u00fcm \u00e7\u00f6kmeleri gibi beklenmedik durumlar kar\u015f\u0131s\u0131nda bile veri tutarl\u0131l\u0131\u011f\u0131n\u0131 koruyabilir ve kesintisiz hizmet sunabilir.<\/p>\n
Raft’\u0131 Ger\u00e7ek D\u00fcnya Uygulamalar\u0131nda Nas\u0131l Kullanabiliriz? Vaka Analizleri ve \u00d6rnekler<\/h2>\n
Raft konsens\u00fcs algoritmas\u0131n\u0131n teorik sa\u011flaml\u0131\u011f\u0131, onu bir\u00e7ok ger\u00e7ek d\u00fcnya da\u011f\u0131t\u0131k sisteminin temel ta\u015f\u0131 haline getirmi\u015ftir. G\u00fcn\u00fcm\u00fcz\u00fcn en pop\u00fcler altyap\u0131 ara\u00e7lar\u0131ndan baz\u0131lar\u0131, kritik metadata veya durum y\u00f6netimi i\u00e7in Raft’\u0131 kullan\u0131r. Bu algoritmalar\u0131n pratik uygulamalar\u0131, da\u011f\u0131t\u0131k sistemlerin karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 y\u00f6netmek ve y\u00fcksek g\u00fcvenilirlik sa\u011flamak i\u00e7in ne kadar \u00f6nemli oldu\u011funu a\u00e7\u0131k\u00e7a g\u00f6stermektedir.<\/p>\n
En bilinen Raft uygulamalar\u0131ndan biri etcd<\/a>‘dir. etcd, Kubernetes gibi konteyner orkestrasyon platformlar\u0131n\u0131n da\u011f\u0131t\u0131k anahtar-de\u011fer deposudur. Kubernetes, k\u00fcmedeki t\u00fcm makinelerin, pod’lar\u0131n, servislerin ve yap\u0131land\u0131rmalar\u0131n durumunu etcd’de saklar. etcd, bu kritik bilgiyi Raft kullanarak \u00e7o\u011falt\u0131r ve tutarl\u0131l\u0131\u011f\u0131n\u0131 garanti eder. \u00d6rne\u011fin, bir pod’un durumu de\u011fi\u015fti\u011finde (\u00f6rne\u011fin, “\u00e7al\u0131\u015f\u0131yor”dan “durduruldu”ya), bu de\u011fi\u015fiklik etcd’ye bir Raft log girdisi olarak yaz\u0131l\u0131r. etcd k\u00fcmesindeki lider d\u00fc\u011f\u00fcm bu de\u011fi\u015fikli\u011fi al\u0131r, log’una ekler ve di\u011fer etcd d\u00fc\u011f\u00fcmlerine kopyalar. \u00c7o\u011funluk onaylad\u0131\u011f\u0131nda, de\u011fi\u015fiklik commit edilir ve t\u00fcm Kubernetes bile\u015fenleri (API sunucusu, zamanlay\u0131c\u0131lar vb.) bu g\u00fcncel durumu g\u00fcvenilir bir \u015fekilde okuyabilir. Bu sayede, Kubernetes k\u00fcmesi, herhangi bir d\u00fc\u011f\u00fcm\u00fcn ar\u0131zalanmas\u0131 durumunda bile tutarl\u0131 bir duruma sahip olur ve operasyonlar\u0131na devam edebilir.<\/p>\n\u0130\u015fte etcd’de bir anahtar-de\u011fer \u00e7iftinin Raft log’una nas\u0131l eklenebilece\u011fine dair kavramsal bir \u00f6rnek:<\/p>\n
\n\n\/\/ \u0130stemci iste\u011fi: \"mykey\" anahtar\u0131n\u0131n de\u011ferini \"myvalue\" olarak ayarla\n\/\/ Lider taraf\u0131ndan Raft log'una eklenen bir komut\n{\n \"term\": 5,\n \"index\": 123,\n \"command\": {\n \"operation\": \"SET\",\n \"key\": \"mykey\",\n \"value\": \"myvalue\"\n },\n \"committed\": false \/\/ Hen\u00fcz commit edilmedi\n}\n\n\/\/ \u00c7o\u011funluk onay\u0131ndan sonra lider taraf\u0131ndan commit edildi\u011finde\n{\n \"term\": 5,\n \"index\": 123,\n \"command\": {\n \"operation\": \"SET\",\n \"key\": \"mykey\",\n \"value\": \"myvalue\"\n },\n \"committed\": true \/\/ Commit edildi, durum makinesine uygulanabilir\n}\n <\/code><\/pre>\n<\/p><\/div>\n