Y\u00fcksek eri\u015filebilirlik i\u00e7in tasarlanan sistemlerde bile tek bir yaz\u0131l\u0131m hatas\u0131 nas\u0131l felakete yol a\u00e7abilir? Redundans\u0131n (yedeklilik) ba\u011f\u0131ms\u0131zl\u0131k garantisi olmad\u0131\u011f\u0131n\u0131 ve sistemler aras\u0131 gizli ba\u011f\u0131ml\u0131l\u0131klar\u0131 ke\u015ffedin. Bu makale, d\u00f6rt \u00f6rnek (instance), iki veri merkezi (data center) ve tek bir hatan\u0131n t\u00fcm sistemi nas\u0131l \u00e7\u00f6kertti\u011fi \u00fczerine ger\u00e7ek d\u00fcnya senaryolar\u0131n\u0131 ele alarak, sistemlerinizi daha diren\u00e7li hale getirme yollar\u0131n\u0131 sunuyor.<\/p>\n
G\u00fcn\u00fcm\u00fcz dijital d\u00fcnyas\u0131nda, hizmetlerin kesintisiz \u00e7al\u0131\u015fmas\u0131 hayati \u00f6nem ta\u015f\u0131r. Bir e-ticaret sitesinin birka\u00e7 dakika kapal\u0131 kalmas\u0131 milyonlarca lira kayba yol a\u00e7abilirken, bir bankac\u0131l\u0131k uygulamas\u0131ndaki kesinti m\u00fc\u015fteri g\u00fcvenini sarsabilir ve ciddi operasyonel sorunlara neden olabilir. Bu nedenle, m\u00fchendisler sistemlerini “yedeklilik” prensibiyle tasarlar. Ama\u00e7, tek bir bile\u015fenin ar\u0131zalanmas\u0131 durumunda bile hizmetin devam etmesini sa\u011flamakt\u0131r. Birden fazla sunucu (server), birden fazla veri merkezi ve karma\u015f\u0131k y\u00fck dengeleyici (load balancer) yap\u0131lar\u0131 ile sistemlerimizi adeta kur\u015fun ge\u00e7irmez hale getirdi\u011fimizi d\u00fc\u015f\u00fcn\u00fcr\u00fcz. Ancak, bu makalede ele alaca\u011f\u0131m\u0131z senaryo, bu g\u00fcvenlik a\u011f\u0131n\u0131n ard\u0131nda yatan gizli bir tehlikeyi g\u00f6zler \u00f6n\u00fcne seriyor: Redundans\u0131n, her zaman ba\u011f\u0131ms\u0131zl\u0131k anlam\u0131na gelmemesi.<\/p>\n
Bir sistemin yedekli olmas\u0131, bir bile\u015fen ar\u0131zaland\u0131\u011f\u0131nda y\u00fck\u00fc di\u011ferine aktarabilece\u011fi anlam\u0131na gelir. \u00d6rne\u011fin, iki sunucudan biri \u00e7\u00f6kerse, di\u011feri i\u015f y\u00fck\u00fcn\u00fc \u00fcstlenir. Ancak ya her iki sunucuyu da ayn\u0131 anda etkileyen, fark edilmeyen bir hata varsa? Veya daha da k\u00f6t\u00fcs\u00fc, farkl\u0131 co\u011frafyalarda bulunan iki ayr\u0131 veri merkezindeki t\u00fcm sistemleri ayn\u0131 anda etkileyebilecek bir zay\u0131fl\u0131k mevcutsa? \u0130\u015fte tam da bu noktada, “D\u00f6rt \u00d6rnek, \u0130ki Veri Merkezi, Bir Hata” senaryosu devreye giriyor. Bu makale, bu t\u00fcr bir felaketin nas\u0131l meydana gelebilece\u011fini, gizli ba\u011f\u0131ml\u0131l\u0131klar\u0131n nas\u0131l ortaya \u00e7\u0131kt\u0131\u011f\u0131n\u0131 ve en \u00f6nemlisi, sistemlerimizi bu t\u00fcr senaryolara kar\u015f\u0131 nas\u0131l daha diren\u00e7li hale getirebilece\u011fimizi ad\u0131m ad\u0131m a\u00e7\u0131klayacak. Amac\u0131m\u0131z, yedeklilik stratejilerinizi yeniden g\u00f6zden ge\u00e7irmenizi sa\u011flayacak pratik bilgiler ve uygulanabilir \u00e7\u00f6z\u00fcmler sunmakt\u0131r.<\/p>\n
Redundans (yedeklilik) ve ba\u011f\u0131ms\u0131zl\u0131k (independence) kavramlar\u0131, sistem tasar\u0131m\u0131nda s\u0131kl\u0131kla birlikte an\u0131lsa da, asl\u0131nda farkl\u0131 anlamlara gelir ve birbirlerinin yerine kullan\u0131ld\u0131klar\u0131nda ciddi yan\u0131lg\u0131lara yol a\u00e7abilir. Bu iki temel kavram\u0131 do\u011fru anlamak, diren\u00e7li ve y\u00fcksek eri\u015filebilir sistemler in\u015fa etmenin ilk ad\u0131m\u0131d\u0131r.<\/p>\n
Redundans, bir sistemin veya bile\u015fenin ar\u0131zalanmas\u0131 durumunda hizmetin kesintiye u\u011framadan devam etmesini sa\u011flamak amac\u0131yla birden fazla ayn\u0131 fonksiyona sahip bile\u015fenin kullan\u0131lmas\u0131d\u0131r. Basit\u00e7e ifade etmek gerekirse, bir yede\u011finizin olmas\u0131d\u0131r. \u00d6rne\u011fin, bir web uygulamas\u0131n\u0131 tek bir sunucuda \u00e7al\u0131\u015ft\u0131rmak yerine, ayn\u0131 uygulaman\u0131n birden fazla kopyas\u0131n\u0131 (\u00f6rneklerini) farkl\u0131 sunucularda \u00e7al\u0131\u015ft\u0131rmak bir yedeklilik \u00f6rne\u011fidir. Bu sayede, sunuculardan biri ar\u0131zalan\u0131rsa, di\u011ferleri i\u015f y\u00fck\u00fcn\u00fc devralabilir ve kullan\u0131c\u0131lar hizmet kesintisi ya\u015famaz. Yedeklilik, genellikle y\u00fcksek eri\u015filebilirlik (High Availability – HA) ve hata tolerans\u0131 (Fault Tolerance) sa\u011flamak i\u00e7in kullan\u0131l\u0131r. \u00c7e\u015fitli yedeklilik modelleri bulunur:<\/p>\n
Yedeklilik, donan\u0131m katman\u0131nda (\u00e7ift g\u00fc\u00e7 kayna\u011f\u0131, RAID diskler), a\u011f katman\u0131nda (yedekli router’lar, anahtarlar) ve uygulama katman\u0131nda (birden fazla uygulama \u00f6rne\u011fi, veri taban\u0131 replikasyonu) uygulanabilir.<\/p>\n
Ba\u011f\u0131ms\u0131zl\u0131k ise, bir sistemdeki bile\u015fenlerin birbirlerinden izole bir \u015fekilde \u00e7al\u0131\u015fmas\u0131 ve bir bile\u015fendeki hatan\u0131n di\u011fer bile\u015fenleri etkilememesi durumudur. Yedeklili\u011fin ger\u00e7ekten etkili olabilmesi i\u00e7in, yedekli bile\u015fenlerin m\u00fcmk\u00fcn oldu\u011funca ba\u011f\u0131ms\u0131z olmas\u0131 gerekir. E\u011fer yedekli bile\u015fenleriniz ortak bir zay\u0131fl\u0131\u011fa, payla\u015f\u0131lan bir kayna\u011fa veya ayn\u0131 hata mekanizmas\u0131na sahipse, yedeklilik sadece bir yan\u0131lsama olabilir.<\/p>\n
\u00d6rne\u011fin, iki yedekli sunucunuz oldu\u011funu varsayal\u0131m. E\u011fer bu iki sunucu da ayn\u0131 fiziksel raf i\u00e7inde, ayn\u0131 g\u00fc\u00e7 kayna\u011f\u0131na ba\u011fl\u0131 ve ayn\u0131 a\u011f anahtar\u0131na (switch) ba\u011fl\u0131ysa, g\u00fc\u00e7 kayna\u011f\u0131nda veya a\u011f anahtar\u0131nda meydana gelecek bir ar\u0131za her iki sunucuyu da ayn\u0131 anda etkileyebilir. Bu durumda, sunucular\u0131n\u0131z “yedekli” olsa da, “ba\u011f\u0131ms\u0131z” de\u011fildirler. Ger\u00e7ek ba\u011f\u0131ms\u0131zl\u0131k, bile\u015fenlerin hata alanlar\u0131n\u0131n (fault domains) birbirinden ayr\u0131lmas\u0131n\u0131 gerektirir. Bu, farkl\u0131 veri merkezlerinde, farkl\u0131 g\u00fc\u00e7 \u015febekelerinde, farkl\u0131 a\u011f altyap\u0131lar\u0131nda ve hatta farkl\u0131 yaz\u0131l\u0131m s\u00fcr\u00fcmlerinde \u00e7al\u0131\u015fmak anlam\u0131na gelebilir.<\/p>\n
Peki, bu iki kavram neden s\u0131kl\u0131kla kar\u0131\u015ft\u0131r\u0131l\u0131r? Genellikle, m\u00fchendisler yedekli bir mimari tasarlad\u0131klar\u0131nda, otomatik olarak ba\u011f\u0131ms\u0131zl\u0131\u011f\u0131 da sa\u011flad\u0131klar\u0131n\u0131 varsayarlar. “\u0130ki sunucum var, biri \u00e7\u00f6kerse di\u011feri devam eder” d\u00fc\u015f\u00fcncesi yayg\u0131nd\u0131r. Ancak bu d\u00fc\u015f\u00fcnce, ayn\u0131 yaz\u0131l\u0131m hatas\u0131n\u0131n veya ayn\u0131 altyap\u0131 zay\u0131fl\u0131\u011f\u0131n\u0131n her iki sunucuyu da ayn\u0131 anda etkileyebilece\u011fi olas\u0131l\u0131\u011f\u0131n\u0131 g\u00f6z ard\u0131 eder. Bir yaz\u0131l\u0131m hatas\u0131, bir yap\u0131land\u0131rma hatas\u0131 veya payla\u015f\u0131lan bir d\u0131\u015f hizmetteki (\u00f6rne\u011fin, DNS veya kimlik do\u011frulama servisi) bir sorun, yedekli t\u00fcm bile\u015fenleri ayn\u0131 anda devre d\u0131\u015f\u0131 b\u0131rakabilir. Bu nedenle, sistem tasarlarken sadece yedeklili\u011fi d\u00fc\u015f\u00fcnmekle kalmay\u0131p, ayn\u0131 zamanda her bir yedekli bile\u015fenin olas\u0131 hata kaynaklar\u0131ndan ne kadar ba\u011f\u0131ms\u0131z oldu\u011funu da titizlikle de\u011ferlendirmek kritik \u00f6nem ta\u015f\u0131r.<\/p>\n
\u015eimdi, yedeklili\u011fin ba\u011f\u0131ms\u0131zl\u0131k olmad\u0131\u011f\u0131 bir senaryoyu somut bir \u00f6rnek \u00fczerinden inceleyelim. Bu vaka analizi, modern da\u011f\u0131t\u0131k sistemlerde s\u0131k\u00e7a kar\u015f\u0131la\u015f\u0131lan bir durumu ve tek bir hatan\u0131n nas\u0131l y\u0131k\u0131c\u0131 sonu\u00e7lara yol a\u00e7abilece\u011fini g\u00f6zler \u00f6n\u00fcne serecek.<\/p>\n
Hayali bir e-ticaret \u015firketimiz oldu\u011funu d\u00fc\u015f\u00fcnelim. \u015eirketin kritik \u00f6neme sahip sipari\u015f i\u015fleme servisi, y\u00fcksek eri\u015filebilirlik gereksinimleri nedeniyle olduk\u00e7a sa\u011flam bir mimariyle tasarlanm\u0131\u015ft\u0131r. Bu mimari, iki farkl\u0131 co\u011frafi konumda bulunan veri merkezine (Veri Merkezi A ve Veri Merkezi B) yay\u0131lm\u0131\u015ft\u0131r. Her veri merkezinde, sipari\u015f i\u015fleme servisini \u00e7al\u0131\u015ft\u0131ran iki adet sunucu \u00f6rne\u011fi (instance) bulunmaktad\u0131r. Yani toplamda d\u00f6rt adet aktif sunucu \u00f6rne\u011fi mevcuttur: Veri Merkezi A’da Instance-1 ve Instance-2, Veri Merkezi B’de ise Instance-3 ve Instance-4.<\/p>\n
T\u00fcm gelen kullan\u0131c\u0131 istekleri, co\u011frafi olarak yak\u0131n olan veri merkezine y\u00f6nlendiren bir k\u00fcresel y\u00fck dengeleyici (Global Load Balancer) \u00fczerinden da\u011f\u0131t\u0131lmaktad\u0131r. Her veri merkezi i\u00e7inde de yerel bir y\u00fck dengeleyici, o veri merkezindeki iki instance aras\u0131nda trafi\u011fi adil bir \u015fekilde payla\u015ft\u0131r\u0131r. Veri taban\u0131 (database) katman\u0131nda ise, her iki veri merkezinde de replikasyon (replication) ile tutarl\u0131l\u0131k sa\u011flanmaktad\u0131r. Bu mimari, \u015firket y\u00f6neticilerine ve teknik ekibe b\u00fcy\u00fck bir g\u00fcven vermektedir: “Bir veri merkezi tamamen devre d\u0131\u015f\u0131 kalsa bile, di\u011fer veri merkezi hizmeti kesintisiz olarak devam ettirecektir. Ayn\u0131 veri merkezindeki bir sunucu \u00e7\u00f6kerse, di\u011feri y\u00fck\u00fc \u00fcstlenecektir.” \u015feklinde bir inan\u00e7 hakimdir. Bu, ka\u011f\u0131t \u00fczerinde kusursuz g\u00f6r\u00fcnen, yedeklili\u011fin t\u00fcm faydalar\u0131n\u0131 sunan bir sistemdir.<\/p>\n
Sipari\u015f i\u015fleme servisi, yak\u0131n zamanda yeni bir \u00f6zellik seti ve performans iyile\u015ftirmeleri i\u00e7eren bir g\u00fcncelleme ile canl\u0131ya al\u0131nm\u0131\u015ft\u0131r. Bu g\u00fcncelleme, \u00fc\u00e7\u00fcnc\u00fc taraf bir a\u00e7\u0131k kaynak k\u00fct\u00fcphanesinin (open-source library) yeni bir s\u00fcr\u00fcm\u00fcn\u00fc de i\u00e7ermektedir. Ne yaz\u0131k ki, bu k\u00fct\u00fcphanenin yeni s\u00fcr\u00fcm\u00fcnde, belirli ko\u015fullar alt\u0131nda (\u00f6rne\u011fin, ayn\u0131 anda \u00e7ok say\u0131da b\u00fcy\u00fck boyutlu sipari\u015fin gelmesi veya belirli bir \u00fcr\u00fcn kategorisine yo\u011fun talep olmas\u0131 gibi) tetiklenen, sinsi bir bellek s\u0131z\u0131nt\u0131s\u0131 (memory leak) hatas\u0131 bulunmaktad\u0131r. Bu hata, uygulaman\u0131n kulland\u0131\u011f\u0131 belle\u011fi yava\u015f\u00e7a t\u00fcketmekte, ancak hemen bir \u00e7\u00f6kme (crash) veya hata mesaj\u0131 \u00fcretmemektedir. Bunun yerine, zamanla uygulaman\u0131n performans\u0131n\u0131 d\u00fc\u015f\u00fcrmekte ve sonunda kaynak yetersizli\u011finden dolay\u0131 uygulaman\u0131n yan\u0131t veremez hale gelmesine neden olmaktad\u0131r.<\/p>\n
Bu hata, yaz\u0131l\u0131m\u0131n t\u00fcm d\u00f6rt instance’\u0131na da ayn\u0131 anda da\u011f\u0131t\u0131lm\u0131\u015ft\u0131r, \u00e7\u00fcnk\u00fc da\u011f\u0131t\u0131m (deployment) s\u00fcreci otomatikle\u015ftirilmi\u015f ve t\u00fcm instance’lar ayn\u0131 kod taban\u0131ndan (codebase) derlenerek ayn\u0131 s\u00fcr\u00fcm numaras\u0131yla g\u00fcncellenmi\u015ftir. Yani, “tek bir hata” t\u00fcm sisteme yay\u0131lm\u0131\u015ft\u0131r.<\/p>\n
Her \u015fey normal seyrederken, yo\u011fun bir kampanya d\u00f6nemi ba\u015flar. Bir anda binlerce yeni sipari\u015f sisteme akmaya ba\u015flar. \u0130lk olarak Veri Merkezi A’daki Instance-1, bu yo\u011fun y\u00fck alt\u0131nda bellek s\u0131z\u0131nt\u0131s\u0131 hatas\u0131n\u0131 tetikler. Yava\u015f yava\u015f performans\u0131 d\u00fc\u015fer, yan\u0131t s\u00fcreleri uzar. Yerel y\u00fck dengeleyici, Instance-1’in sa\u011fl\u0131kl\u0131 olmad\u0131\u011f\u0131n\u0131 fark eder ve trafi\u011fi Instance-2’ye y\u00f6nlendirmeye ba\u015flar. Bu, ilk ba\u015fta beklenen yedeklilik davran\u0131\u015f\u0131d\u0131r.<\/p>\n
Ancak, Instance-2 de ayn\u0131 kod taban\u0131na sahip oldu\u011fu i\u00e7in, ayn\u0131 yo\u011fun y\u00fck alt\u0131nda k\u0131sa s\u00fcre sonra ayn\u0131 bellek s\u0131z\u0131nt\u0131s\u0131 hatas\u0131n\u0131 tetikler. Veri Merkezi A’daki her iki instance da yava\u015f\u00e7a yan\u0131t veremez hale gelir. Bu noktada, k\u00fcresel y\u00fck dengeleyici Veri Merkezi A’n\u0131n tamamen devre d\u0131\u015f\u0131 kald\u0131\u011f\u0131n\u0131 alg\u0131lar ve t\u00fcm trafi\u011fi Veri Merkezi B’ye y\u00f6nlendirir. \u0130\u015fte burada, “iki veri merkezi” yedeklili\u011finin devreye girdi\u011fi d\u00fc\u015f\u00fcn\u00fcl\u00fcr.<\/p>\n
Ne var ki, Veri Merkezi B’deki Instance-3 ve Instance-4 de ayn\u0131 yaz\u0131l\u0131m s\u00fcr\u00fcm\u00fcn\u00fc ve dolay\u0131s\u0131yla ayn\u0131 bellek s\u0131z\u0131nt\u0131s\u0131 hatas\u0131n\u0131 i\u00e7ermektedir. Veri Merkezi B, Veri Merkezi A’dan gelen t\u00fcm trafi\u011fi de \u00fcstlenince, \u00fczerindeki y\u00fck daha da artar. Bu artan y\u00fck alt\u0131nda, Instance-3 ve k\u0131sa s\u00fcre sonra Instance-4 de ayn\u0131 bellek s\u0131z\u0131nt\u0131s\u0131 hatas\u0131n\u0131 tetikler ve yan\u0131t veremez hale gelir. Yakla\u015f\u0131k 30-45 dakika i\u00e7inde, d\u00f6rt instance’\u0131n d\u00f6rd\u00fc de, iki ayr\u0131 veri merkezinde bulunmalar\u0131na ra\u011fmen, ayn\u0131 yaz\u0131l\u0131m hatas\u0131 nedeniyle tamamen devre d\u0131\u015f\u0131 kalm\u0131\u015ft\u0131r. \u015eirketin sipari\u015f i\u015fleme servisi tamamen \u00e7\u00f6km\u00fc\u015ft\u00fcr.<\/p>\n
Bu olay, \u015firketin milyonlarca liral\u0131k gelir kayb\u0131na u\u011framas\u0131na, m\u00fc\u015fteri g\u00fcveninin sars\u0131lmas\u0131na ve ciddi itibar kayb\u0131na yol a\u00e7m\u0131\u015ft\u0131r. Teknik ekip, ilk ba\u015fta donan\u0131m veya a\u011f sorunlar\u0131 ararken, sorunun k\u00f6k nedeninin t\u00fcm sistemlere yay\u0131lm\u0131\u015f tek bir yaz\u0131l\u0131m hatas\u0131 oldu\u011funu anlamakta zorlanm\u0131\u015ft\u0131r. Bu senaryo, yedeklili\u011fin tek ba\u015f\u0131na yeterli olmad\u0131\u011f\u0131n\u0131, yedekli bile\u015fenlerin ger\u00e7ekten ba\u011f\u0131ms\u0131z olmas\u0131n\u0131n kritik \u00f6nem ta\u015f\u0131d\u0131\u011f\u0131n\u0131 ac\u0131 bir \u015fekilde g\u00f6stermi\u015ftir. Ayn\u0131 yaz\u0131l\u0131m s\u00fcr\u00fcm\u00fcn\u00fc her yere da\u011f\u0131tmak, g\u00f6r\u00fcn\u00fc\u015fte verimli bir da\u011f\u0131t\u0131m stratejisi olsa da, asl\u0131nda t\u00fcm sisteme yay\u0131lan tek bir hata noktas\u0131 yaratm\u0131\u015ft\u0131r.<\/p>\n
Yukar\u0131daki vaka analizinde g\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi, sistemlerimizde yedeklilik sa\u011flad\u0131\u011f\u0131m\u0131z\u0131 d\u00fc\u015f\u00fcnsek bile, gizli ba\u011f\u0131ml\u0131l\u0131klar nedeniyle tek bir hata t\u00fcm sistemi fel\u00e7 edebilir. Bu t\u00fcr felaketlerden ka\u00e7\u0131nmak i\u00e7in, sistemlerimizi tasarlarken ve i\u015fletirken olas\u0131 t\u00fcm gizli ba\u011f\u0131ml\u0131l\u0131klar\u0131 aktif olarak tespit etmemiz ve azaltmam\u0131z gerekmektedir. Peki, bu gizli ba\u011f\u0131ml\u0131l\u0131klar nerede saklan\u0131r ve nereye bakmal\u0131y\u0131z?<\/p>\n
Yaz\u0131l\u0131m, modern sistemlerin kalbidir ve genellikle en b\u00fcy\u00fck gizli ba\u011f\u0131ml\u0131l\u0131k kayna\u011f\u0131d\u0131r. Ayn\u0131 yaz\u0131l\u0131m kodunun veya bile\u015fenlerinin birden fazla yedekli \u00f6rnekte kullan\u0131lmas\u0131, tek bir hatan\u0131n t\u00fcm \u00f6rneklere yay\u0131lmas\u0131na neden olabilir.<\/p>\n
Yaz\u0131l\u0131m\u0131n alt\u0131nda yatan fiziksel veya sanal altyap\u0131 da \u00f6nemli bir ba\u011f\u0131ml\u0131l\u0131k kayna\u011f\u0131d\u0131r. \u00c7e\u015fitli altyap\u0131 bile\u015fenleri, yedekli g\u00f6r\u00fcnen sistemler aras\u0131nda gizli ba\u011flant\u0131lar olu\u015fturabilir.<\/p>\n
Altyap\u0131 ve yaz\u0131l\u0131m\u0131n \u00f6tesinde, sistemlerin i\u015fletilmesiyle ilgili s\u00fcre\u00e7ler ve insan fakt\u00f6r\u00fc de gizli ba\u011f\u0131ml\u0131l\u0131klar yaratabilir.<\/p>\n
Bu ba\u011f\u0131ml\u0131l\u0131klar\u0131 tespit etmek, sistem mimarisinin derinlemesine incelenmesini, risk analizlerinin yap\u0131lmas\u0131n\u0131 ve d\u00fczenli denetimleri gerektirir. Sadece “bir yede\u011fim var” demek yerine, “yedeklerim ne kadar ba\u011f\u0131ms\u0131z?” sorusunu sormak, ger\u00e7ek diren\u00e7lili\u011fe ula\u015fman\u0131n anahtar\u0131d\u0131r.<\/p>\n
Gizli ba\u011f\u0131ml\u0131l\u0131klar\u0131n fark\u0131na varmak, sorunun ilk ad\u0131m\u0131d\u0131r. Ancak as\u0131l zorluk, bu ba\u011f\u0131ml\u0131l\u0131klar\u0131 aktif olarak azaltmak ve yedekli sistemlerimizin ger\u00e7ekten ba\u011f\u0131ms\u0131z olmas\u0131n\u0131 sa\u011flamakt\u0131r. \u0130\u015fte bu hedefe ula\u015fmak i\u00e7in atabilece\u011finiz pratik ad\u0131mlar ve uygulayabilece\u011finiz stratejiler:<\/p>\n
Benzerlik, ba\u011f\u0131ml\u0131l\u0131k demektir. Ba\u011f\u0131ms\u0131zl\u0131\u011f\u0131 art\u0131rman\u0131n en etkili yollar\u0131ndan biri, yedekli bile\u015fenler aras\u0131nda kas\u0131tl\u0131 farkl\u0131l\u0131klar yaratmakt\u0131r.<\/p>\n
Bu y\u00f6ntemler, yeni bir s\u00fcr\u00fcmdeki hatan\u0131n t\u00fcm sistemi etkilemesini \u00f6nler. E\u011fer bir hata ortaya \u00e7\u0131karsa, sadece k\u00fc\u00e7\u00fck bir b\u00f6l\u00fcm etkilenir ve h\u0131zl\u0131ca geri d\u00f6n\u00fc\u015f (rollback) yap\u0131labilir.<\/p>\n<\/li>\n
Sistemleri mant\u0131ksal ve fiziksel olarak birbirinden ay\u0131rmak, bir hatan\u0131n yay\u0131lmas\u0131n\u0131 s\u0131n\u0131rlar.<\/p>\n
Ba\u011f\u0131ms\u0131zl\u0131\u011f\u0131 sa\u011flamak sadece mimari de\u011fi\u015fikliklerle olmaz; bu de\u011fi\u015fikliklerin etkinli\u011fini s\u00fcrekli olarak do\u011frulamak da gerekir.<\/p>\n
Bir hatan\u0131n ne zaman ve nerede ba\u015flad\u0131\u011f\u0131n\u0131 h\u0131zl\u0131ca anlamak, onun yay\u0131lmas\u0131n\u0131 engellemek i\u00e7in kritiktir.<\/p>\n
Bu stratejileri uygulayarak, yedekli sistemlerinizin sadece var olmas\u0131n\u0131 de\u011fil, ayn\u0131 zamanda olas\u0131 t\u00fcm hata senaryolar\u0131na kar\u015f\u0131 ger\u00e7ekten ba\u011f\u0131ms\u0131z ve diren\u00e7li olmas\u0131n\u0131 sa\u011flayabilirsiniz. Unutmay\u0131n, yedeklilik bir ara\u00e7t\u0131r, ba\u011f\u0131ms\u0131zl\u0131k ise bu arac\u0131n etkinli\u011fini belirleyen temel prensiptir.<\/p>\n
Sistemlerimizi daha diren\u00e7li hale getirmek i\u00e7in temel ad\u0131mlar\u0131 att\u0131ktan sonra, bir ad\u0131m \u00f6teye ge\u00e7erek daha geli\u015fmi\u015f stratejilere odaklanabiliriz. Bu b\u00f6l\u00fcmde, \u00f6zellikle Kaos M\u00fchendisli\u011fi ve modern da\u011f\u0131t\u0131m modellerinin, yedeklili\u011fin ba\u011f\u0131ms\u0131zl\u0131\u011f\u0131n\u0131 sa\u011flamada nas\u0131l kritik roller oynad\u0131\u011f\u0131n\u0131 inceleyece\u011fiz.<\/p>\n
Kaos M\u00fchendisli\u011fi (Chaos Engineering), da\u011f\u0131t\u0131k sistemlerdeki zay\u0131fl\u0131klar\u0131 ve gizli ba\u011f\u0131ml\u0131l\u0131klar\u0131 proaktif olarak bulmak i\u00e7in, \u00fcretim (production) ortam\u0131nda veya ona \u00e7ok yak\u0131n ortamlarda kas\u0131tl\u0131 olarak hatalar enjekte etme prati\u011fidir. Bu, sistemin beklenmedik ko\u015fullar alt\u0131nda nas\u0131l davrand\u0131\u011f\u0131n\u0131 \u00f6\u011frenmeyi ve bu bilgilerle daha diren\u00e7li sistemler in\u015fa etmeyi ama\u00e7lar. “E\u011fer bir sorun ya\u015fanabilecekse, ya\u015fanacakt\u0131r” felsefesinden yola \u00e7\u0131karak, sorunlar\u0131 kontroll\u00fc bir \u015fekilde ve kendi iste\u011fimizle tetikleyerek onlar\u0131 daha b\u00fcy\u00fck bir felakete d\u00f6n\u00fc\u015fmeden \u00f6nce \u00e7\u00f6zme f\u0131rsat\u0131 sunar.<\/p>\n
Kaos M\u00fchendisli\u011fi Nas\u0131l Uygulan\u0131r?<\/strong><\/p>\n Faydalar\u0131:<\/strong> Kaos M\u00fchendisli\u011fi, sadece gizli ba\u011f\u0131ml\u0131l\u0131klar\u0131 ortaya \u00e7\u0131karmakla kalmaz, ayn\u0131 zamanda ekiplerin kriz an\u0131nda daha h\u0131zl\u0131 ve etkili tepki vermesini sa\u011flar. Sistemlerin “karanl\u0131k k\u00f6\u015felerindeki” zay\u0131fl\u0131klar\u0131 bulur ve mimariyi s\u00fcrekli olarak iyile\u015ftirmeye te\u015fvik eder. Bu sayede, yedekli bile\u015fenlerinizin ger\u00e7ekten ba\u011f\u0131ms\u0131z olup olmad\u0131\u011f\u0131n\u0131 pratik bir \u015fekilde test etmi\u015f olursunuz.<\/p>\n \u00d6rne\u011fin, bir sunucunun belle\u011fini yava\u015f\u00e7a dolduran bir komut \u00e7al\u0131\u015ft\u0131rarak, bellek s\u0131z\u0131nt\u0131s\u0131 gibi sinsi bir hatan\u0131n etkilerini \u00f6nceden g\u00f6zlemleyebilirsiniz:<\/p>\n Bu t\u00fcr bir deneyi kontroll\u00fc bir ortamda yaparak, uygulaman\u0131z\u0131n bellek s\u0131z\u0131nt\u0131s\u0131na nas\u0131l tepki verdi\u011fini ve yedekli sistemlerin bu duruma ne kadar diren\u00e7li oldu\u011funu g\u00f6zlemleyebilirsiniz.<\/p>\n Yaz\u0131l\u0131m da\u011f\u0131t\u0131m\u0131 (deployment) s\u00fcre\u00e7leri, yukar\u0131daki vaka analizinde g\u00f6rd\u00fc\u011f\u00fcm\u00fcz gibi, tek bir hatan\u0131n t\u00fcm sisteme yay\u0131lmas\u0131nda kritik bir rol oynayabilir. Bu riski azaltmak i\u00e7in, geleneksel “big-bang” da\u011f\u0131t\u0131m yakla\u015f\u0131mlar\u0131 yerine daha kontroll\u00fc ve kademeli modeller tercih edilmelidir.<\/p>\n Bu modelde, yeni bir yaz\u0131l\u0131m s\u00fcr\u00fcm\u00fc (canary s\u00fcr\u00fcm), \u00f6ncelikle \u00e7ok k\u00fc\u00e7\u00fck bir kullan\u0131c\u0131 alt k\u00fcmesine veya sunucu grubuna da\u011f\u0131t\u0131l\u0131r. Bu “kanarya” grubu, yeni s\u00fcr\u00fcm\u00fcn istikrarl\u0131 ve beklenen \u015fekilde \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 do\u011frulamak i\u00e7in bir test alan\u0131 g\u00f6revi g\u00f6r\u00fcr. E\u011fer kanarya grubunda herhangi bir sorun (hata oran\u0131nda art\u0131\u015f, performans d\u00fc\u015f\u00fc\u015f\u00fc vb.) tespit edilirse, da\u011f\u0131t\u0131m durdurulur ve eski s\u00fcr\u00fcme geri d\u00f6n\u00fcl\u00fcr. Sorun yoksa, yeni s\u00fcr\u00fcm kademeli olarak daha fazla kullan\u0131c\u0131ya veya sunucuya yay\u0131l\u0131r.<\/p>\n Bu yakla\u015f\u0131m, tek bir hata noktas\u0131n\u0131n etkisini s\u0131n\u0131rlayarak, b\u00fcy\u00fck \u00f6l\u00e7ekli bir hizmet kesintisi riskini minimize eder. Genellikle y\u00fck dengeleyiciler veya servis a\u011flar\u0131 (service mesh) kullan\u0131larak trafik y\u00f6nlendirmesi yap\u0131l\u0131r.<\/p>\n Bu \u00f6rnekte, Mavi\/Ye\u015fil da\u011f\u0131t\u0131m, iki tamamen \u00f6zde\u015f \u00fcretim ortam\u0131n\u0131n (biri “mavi” di\u011feri “ye\u015fil”) paralel olarak \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131na dayan\u0131r. Bir ortam (\u00f6rne\u011fin “mavi”) mevcut canl\u0131 s\u00fcr\u00fcm\u00fc bar\u0131nd\u0131r\u0131rken, di\u011fer ortam (“ye\u015fil”) yeni s\u00fcr\u00fcmle g\u00fcncellenir. Yeni s\u00fcr\u00fcm ye\u015fil ortamda kapsaml\u0131 bir \u015fekilde test edildikten sonra, t\u00fcm kullan\u0131c\u0131 trafi\u011fi y\u00fck dengeleyici arac\u0131l\u0131\u011f\u0131yla maviden ye\u015file an\u0131nda y\u00f6nlendirilir. E\u011fer yeni s\u00fcr\u00fcmde bir sorun ortaya \u00e7\u0131karsa, trafik an\u0131nda tekrar mavi ortama geri y\u00f6nlendirilebilir.<\/p>\n Bu y\u00f6ntem, s\u0131f\u0131r kesinti s\u00fcresiyle (zero downtime) da\u011f\u0131t\u0131m yapma imkan\u0131 sunar ve geri d\u00f6n\u00fc\u015f (rollback) s\u00fcre\u00e7lerini son derece h\u0131zl\u0131 ve g\u00fcvenli hale getirir. Her iki ortam da ba\u011f\u0131ms\u0131z bir \u015fekilde \u00e7al\u0131\u015fabildi\u011fi i\u00e7in, bir ortamdaki hata di\u011ferini etkilemez.<\/p>\n<\/li>\n<\/ul>\n Bu geli\u015fmi\u015f da\u011f\u0131t\u0131m stratejileri ve Kaos M\u00fchendisli\u011fi gibi proaktif yakla\u015f\u0131mlar, yedekli sistemlerinizin sadece ka\u011f\u0131t \u00fczerinde de\u011fil, ger\u00e7ek d\u00fcnya senaryolar\u0131nda da ba\u011f\u0131ms\u0131z ve diren\u00e7li olmas\u0131n\u0131 sa\u011flar. S\u00fcrekli \u00f6\u011frenme, test etme ve iyile\u015ftirme k\u00fclt\u00fcr\u00fc, modern sistemlerin g\u00fcvenilirli\u011finin temelini olu\u015fturur.<\/p>\n Bu makalede ele ald\u0131\u011f\u0131m\u0131z “D\u00f6rt \u00d6rnek, \u0130ki Veri Merkezi, Bir Hata” senaryosu, modern da\u011f\u0131t\u0131k sistemlerin karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 ve yedeklili\u011fin tek ba\u015f\u0131na yeterli olmad\u0131\u011f\u0131n\u0131 \u00e7arp\u0131c\u0131 bir \u015fekilde g\u00f6stermektedir. Sistemlerimizi tasarlarken ve y\u00f6netirken, sadece bile\u015fenleri \u00e7o\u011faltmakla (yedeklilik) kalmay\u0131p, ayn\u0131 zamanda bu bile\u015fenlerin birbirlerinden ne kadar ba\u011f\u0131ms\u0131z oldu\u011funu da derinlemesine anlamam\u0131z gerekti\u011fi ortaya \u00e7\u0131km\u0131\u015ft\u0131r. Tek bir yaz\u0131l\u0131m hatas\u0131, hatal\u0131 bir yap\u0131land\u0131rma veya payla\u015f\u0131lan bir altyap\u0131 zay\u0131fl\u0131\u011f\u0131, en geli\u015fmi\u015f yedeklilik mimarilerini bile alt edebilir ve t\u00fcm hizmetlerin fel\u00e7 olmas\u0131na yol a\u00e7abilir.<\/p>\n Ger\u00e7ek diren\u00e7lilik (resilience), yedeklilik ile ba\u011f\u0131ms\u0131zl\u0131\u011f\u0131n el ele y\u00fcr\u00fcmesiyle sa\u011flan\u0131r. Bu, payla\u015f\u0131lan yaz\u0131l\u0131m bile\u015fenlerinden altyap\u0131 kaynaklar\u0131na ve operasyonel s\u00fcre\u00e7lere kadar t\u00fcm olas\u0131 gizli ba\u011f\u0131ml\u0131l\u0131klar\u0131 aktif olarak tespit etmek ve azaltmak anlam\u0131na gelir. Farkl\u0131la\u015ft\u0131rma, izolasyon, kapsaml\u0131 testler (\u00f6zellikle Kaos M\u00fchendisli\u011fi) ve geli\u015fmi\u015f da\u011f\u0131t\u0131m stratejileri (Canary ve Mavi\/Ye\u015fil da\u011f\u0131t\u0131mlar) gibi pratik ad\u0131mlar, sistemlerimizi bu t\u00fcr senaryolara kar\u015f\u0131 daha sa\u011flam hale getirmemize yard\u0131mc\u0131 olur.<\/p>\n Unutulmamal\u0131d\u0131r ki, sistem g\u00fcvenilirli\u011fi s\u00fcrekli bir yolculuktur, var\u0131lacak bir hedef de\u011fil. Teknolojiler geli\u015ftik\u00e7e, yeni ba\u011f\u0131ml\u0131l\u0131klar ve hata mekanizmalar\u0131 ortaya \u00e7\u0131kabilir. Bu nedenle, s\u00fcrekli g\u00f6zlemlemek, \u00f6\u011frenmek, test etmek ve mimarilerimizi iyile\u015ftirmek, kesintisiz hizmet sunma taahh\u00fcd\u00fcm\u00fcz\u00fcn temelini olu\u015fturur. Redundans\u0131n ger\u00e7ek g\u00fcc\u00fc, ancak ba\u011f\u0131ms\u0131zl\u0131kla birle\u015fti\u011finde ortaya \u00e7\u0131kar.<\/p>\n A\u015fa\u011f\u0131da, konuyla ilgili s\u0131k\u00e7a kar\u015f\u0131la\u015f\u0131lan sorulara yan\u0131tlar bulabilirsiniz.<\/p>\n S1: Redundans ve ba\u011f\u0131ms\u0131zl\u0131k aras\u0131ndaki temel fark nedir?<\/strong><\/p>\n C1:<\/strong> Redundans (yedeklilik), bir sistemde ayn\u0131 i\u015flevi g\u00f6ren birden fazla bile\u015fenin bulunmas\u0131d\u0131r; birinin ar\u0131zalanmas\u0131 durumunda di\u011ferinin g\u00f6revi devralmas\u0131n\u0131 sa\u011flar. Ba\u011f\u0131ms\u0131zl\u0131k ise, bu yedekli bile\u015fenlerin birbirlerinden izole \u00e7al\u0131\u015fmas\u0131, yani bir bile\u015fendeki hatan\u0131n di\u011ferini etkilememesidir. Yedeklilik, sistemin ayakta kalma kapasitesini art\u0131r\u0131rken, ba\u011f\u0131ms\u0131zl\u0131k bu kapasitenin ger\u00e7ekten i\u015flevsel olmas\u0131n\u0131 garanti eder. Redundans varsa, ba\u011f\u0131ms\u0131zl\u0131k olmak zorunda de\u011fildir, ancak ba\u011f\u0131ms\u0131z yedeklilik en sa\u011flam \u00e7\u00f6z\u00fcmd\u00fcr.<\/p>\n S2: Kaos m\u00fchendisli\u011fi her proje i\u00e7in uygun mudur?<\/strong><\/p>\n C2:<\/strong> Kaos m\u00fchendisli\u011fi, \u00f6zellikle da\u011f\u0131t\u0131k, karma\u015f\u0131k ve y\u00fcksek eri\u015filebilirlik gerektiren sistemler i\u00e7in \u00e7ok de\u011ferli bir pratik olmakla birlikte, her proje i\u00e7in uygun olmayabilir. K\u00fc\u00e7\u00fck, monolitik (monolithic) veya kritik olmayan uygulamalar i\u00e7in a\u015f\u0131r\u0131ya ka\u00e7an bir yat\u0131r\u0131m olabilir. Genellikle, \u00fcretim ortam\u0131nda (production environment) uygulanmas\u0131 tavsiye edilir, ancak bu ciddi bir haz\u0131rl\u0131k, kapsaml\u0131 izleme ve h\u0131zl\u0131 geri d\u00f6n\u00fc\u015f (rollback) yetenekleri gerektirir. Ba\u015flang\u0131\u00e7ta daha kontroll\u00fc test ortamlar\u0131nda denemeler yapmak daha g\u00fcvenli bir yakla\u015f\u0131md\u0131r.<\/p>\n S3: Tek bir hata t\u00fcm veri merkezlerini nas\u0131l etkileyebilir?<\/strong><\/p>\n C3:<\/strong> Tek bir hata, \u00f6zellikle payla\u015f\u0131lan bir yaz\u0131l\u0131m bile\u015feninde (\u00f6rne\u011fin, ayn\u0131 uygulama kodu, ayn\u0131 \u00fc\u00e7\u00fcnc\u00fc taraf k\u00fct\u00fcphane) veya payla\u015f\u0131lan bir altyap\u0131 ba\u011f\u0131ml\u0131l\u0131\u011f\u0131nda (\u00f6rne\u011fin, ayn\u0131 DNS sunucusu, ayn\u0131 kimlik do\u011frulama servisi) bulunuyorsa, t\u00fcm veri merkezlerini etkileyebilir. E\u011fer bu hata, t\u00fcm yedekli sistemlere ayn\u0131 anda da\u011f\u0131t\u0131lm\u0131\u015fsa ve belirli ko\u015fullar alt\u0131nda tetikleniyorsa, veri merkezlerinin fiziksel ayr\u0131l\u0131\u011f\u0131 bile bu hatan\u0131n yay\u0131lmas\u0131n\u0131 engelleyemez. Yukar\u0131daki vaka analizindeki bellek s\u0131z\u0131nt\u0131s\u0131 buna iyi bir \u00f6rnektir.<\/p>\n S4: Farkl\u0131 veri merkezlerinde farkl\u0131 yaz\u0131l\u0131m s\u00fcr\u00fcmleri kullanmak riskli de\u011fil midir?<\/strong><\/p>\n C4:<\/strong> Farkl\u0131 veri merkezlerinde veya \u00f6rneklerde farkl\u0131 yaz\u0131l\u0131m s\u00fcr\u00fcmleri kullanmak, “farkl\u0131la\u015ft\u0131rma” stratejisinin bir par\u00e7as\u0131d\u0131r ve baz\u0131 riskleri (\u00f6rne\u011fin, y\u00f6netim karma\u015f\u0131kl\u0131\u011f\u0131, uyumluluk sorunlar\u0131) beraberinde getirse de, tek bir hatan\u0131n t\u00fcm sistemi \u00e7\u00f6kertme riskini \u00f6nemli \u00f6l\u00e7\u00fcde azalt\u0131r. Canary veya Mavi\/Ye\u015fil da\u011f\u0131t\u0131m gibi kontroll\u00fc y\u00f6ntemlerle bu riskler y\u00f6netilebilir. Ama\u00e7, hatan\u0131n yay\u0131lmas\u0131n\u0131 engellemek i\u00e7in t\u00fcm yumurtalar\u0131 ayn\u0131 sepete koymamakt\u0131r. Kritik hatalar\u0131n ke\u015ffedilmesi ve d\u00fczeltilmesi i\u00e7in bu t\u00fcr stratejiler hayati \u00f6neme sahiptir.<\/p>\n S5: K\u00fc\u00e7\u00fck ekipler ba\u011f\u0131ms\u0131zl\u0131\u011f\u0131 sa\u011flamak i\u00e7in ne yapabilir?<\/strong><\/p>\n C5:<\/strong> K\u00fc\u00e7\u00fck ekipler i\u00e7in de ba\u011f\u0131ms\u0131zl\u0131k \u00f6nemlidir. Ba\u015flang\u0131\u00e7 olarak, kritik bile\u015fenlerin yedekli oldu\u011fundan emin olun ve her bir yedekli bile\u015fenin olas\u0131 tek hata noktalar\u0131n\u0131 (payla\u015f\u0131lan yap\u0131land\u0131rma, tek bir a\u011f cihaz\u0131 vb.) belirleyin. Otomatik testlere yat\u0131r\u0131m yap\u0131n, felaket kurtarma planlar\u0131n\u0131 belgeleyin ve basit tatbikatlar yap\u0131n. Bulut sa\u011flay\u0131c\u0131lar\u0131n b\u00f6lgesel yedeklilik ve farkl\u0131 kullan\u0131labilirlik alanlar\u0131 (availability zones) gibi \u00f6zelliklerini kullanarak fiziksel izolasyonu kolayca sa\u011flayabilirsiniz. Ayr\u0131ca, Kaos M\u00fchendisli\u011fi’ne ba\u015flamak i\u00e7in basit betikler veya a\u00e7\u0131k kaynak ara\u00e7lar\u0131 kullanmak da iyi bir ba\u015flang\u0131\u00e7 olabilir.<\/p>\n #Teknoloji #Yedeklilik #Ba\u011f\u0131ms\u0131zl\u0131k #VeriMerkezi #SistemMimarisi #KaosM\u00fchendisli\u011fi #Y\u00fcksekEri\u015filebilirlik #Yaz\u0131l\u0131mGeli\u015ftirme<\/p>\n\n
# Linux \u00fczerinde bellek s\u0131z\u0131nt\u0131s\u0131 sim\u00fclasyonu i\u00e7in basit bir Python beti\u011fi\n# D\u0130KKAT: \u00dcretim ortam\u0131nda dikkatli kullan\u0131lmal\u0131d\u0131r!\nimport os\nimport time\n\ndata = []\nwhile True:\n data.append(os.urandom(1024 * 1024)) # Her d\u00f6ng\u00fcde 1MB bellek t\u00fcketir\n print(f\"Bellek kullan\u0131m\u0131: {len(data)} MB\")\n time.sleep(1) # Her saniye 1MB ekle<\/code><\/pre>\n<\/p><\/div>\nFarkl\u0131 Da\u011f\u0131t\u0131m Modelleri: G\u00fcvenli ve Kademeli G\u00fcncellemeler<\/h3>\n
\n
# \u00d6rnek bir Kubernetes servisi ve Canary da\u011f\u0131t\u0131m stratejisi (s\u00f6zde kod)\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n name: my-app-v1\nspec:\n replicas: 90 # %90 trafik\n template:\n spec:\n containers:\n - name: my-app\n image: my-app:v1.0\n\n---\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n name: my-app-canary\nspec:\n replicas: 10 # %10 trafik\n template:\n spec:\n containers:\n - name: my-app\n image: my-app:v1.1 # Yeni s\u00fcr\u00fcm<\/code><\/pre>\n<\/p><\/div>\nmy-app-v1<\/code> mevcut stabil s\u00fcr\u00fcm\u00fc temsil ederken, my-app-canary<\/code> yeni v1.1<\/code> s\u00fcr\u00fcm\u00fcn\u00fc k\u00fc\u00e7\u00fck bir y\u00fczdeyle (\u00f6rne\u011fin %10) devreye al\u0131r. \u0130zleme sistemleri bu %10’luk trafi\u011fi dikkatlice takip eder.<\/p>\n<\/li>\nSonu\u00e7: Redundans\u0131n Ger\u00e7ek G\u00fcc\u00fcn\u00fc Ke\u015ffetmek<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n