G\u00fcn\u00fcm\u00fcz\u00fcn dijital d\u00fcnyas\u0131nda, uygulamalar\u0131n bel kemi\u011fi olan API’lar, s\u00fcrekli ve hatas\u0131z \u00e7al\u0131\u015fmak zorundad\u0131r. Peki, da\u011f\u0131t\u0131mdan \u00f6nce API’lar\u0131n\u0131z\u0131n beklenmedik sorunlara kar\u015f\u0131 ne kadar dayan\u0131kl\u0131 oldu\u011funu nas\u0131l test edersiniz? Bu makale, API’lar\u0131n\u0131z\u0131n diren\u00e7 yetene\u011fini \u00f6l\u00e7mek ve iyile\u015ftirmek i\u00e7in temel kavramlardan ileri d\u00fczey stratejilere kadar kapsaml\u0131 bir rehber sunuyor.<\/p>\n
Herhangi bir modern uygulaman\u0131n veya hizmetin temel yap\u0131 ta\u015flar\u0131ndan biri olan API’lar (Uygulama Programlama Aray\u00fczleri), farkl\u0131 yaz\u0131l\u0131m bile\u015fenlerinin birbiriyle ileti\u015fim kurmas\u0131n\u0131 sa\u011flar. Bir e-ticaret uygulamas\u0131n\u0131n \u00f6deme sisteminden envanter y\u00f6netimine, bir mobil uygulaman\u0131n arka u\u00e7 hizmetlerinden kullan\u0131c\u0131 kimlik do\u011frulama mekanizmalar\u0131na kadar say\u0131s\u0131z noktada API’lar devreye girer. Ancak bu kritik rol, beraberinde \u00f6nemli bir sorumluluk getirir: API’lar\u0131n “dayan\u0131kl\u0131” olmas\u0131 gerekir. Peki, API dayan\u0131kl\u0131l\u0131\u011f\u0131 tam olarak ne anlama gelir ve neden g\u00fcn\u00fcm\u00fcz\u00fcn rekabet\u00e7i dijital ekosisteminde hayati bir \u00f6neme sahiptir?<\/p>\n
API dayan\u0131kl\u0131l\u0131\u011f\u0131, bir API’\u0131n beklenmedik hatalar, a\u015f\u0131r\u0131 y\u00fcklenmeler, a\u011f kesintileri veya di\u011fer olumsuz ko\u015fullar alt\u0131nda bile i\u015flevselli\u011fini s\u00fcrd\u00fcrme, hatalardan kurtulma ve kabul edilebilir bir performans seviyesini koruma yetene\u011fini ifade eder. Bu, sadece API’\u0131n \u00e7al\u0131\u015fmaya devam etmesi de\u011fil, ayn\u0131 zamanda olas\u0131 bir ar\u0131za durumunda sistemin tamam\u0131n\u0131 etkileyecek domino etkisi yaratmadan, hatay\u0131 izole edip uygun bir \u015fekilde yan\u0131t vermesi anlam\u0131na da gelir. \u00d6rne\u011fin, bir \u00f6deme API’s\u0131n\u0131n ge\u00e7ici bir sunucu hatas\u0131 nedeniyle \u00e7\u00f6kmesi, t\u00fcm al\u0131\u015fveri\u015f s\u00fcrecini durdurabilir ve kullan\u0131c\u0131lar\u0131n al\u0131\u015fveri\u015f sepetlerini terk etmesine yol a\u00e7abilir. Bu durum, hem gelir kayb\u0131na hem de marka itibar\u0131n\u0131n zedelenmesine neden olabilir. Bu nedenle, dayan\u0131kl\u0131 API’lar tasarlamak ve bunlar\u0131 da\u011f\u0131t\u0131mdan \u00f6nce kapsaml\u0131 bir \u015fekilde test etmek, kesintisiz bir kullan\u0131c\u0131 deneyimi sunman\u0131n ve i\u015f s\u00fcreklili\u011fini sa\u011flaman\u0131n temel bir par\u00e7as\u0131d\u0131r.<\/p>\n
Dayan\u0131kl\u0131l\u0131k mekanizmalar\u0131 aras\u0131nda \u00e7e\u015fitli stratejiler bulunur. \u00d6rne\u011fin, “yeniden deneme (retry)” mekanizmalar\u0131, ge\u00e7ici a\u011f sorunlar\u0131 veya k\u0131sa s\u00fcreli hizmet kesintileri durumunda API \u00e7a\u011fr\u0131lar\u0131n\u0131n otomatik olarak tekrar denenmesini sa\u011flar. “Devre kesici (circuit breaker)” desenleri, s\u00fcrekli ba\u015far\u0131s\u0131z olan bir servise giden istekleri otomatik olarak engeller, b\u00f6ylece hatan\u0131n yay\u0131lmas\u0131n\u0131 \u00f6nler ve hatal\u0131 servisin kurtulmas\u0131 i\u00e7in zaman tan\u0131r. “Zaman a\u015f\u0131m\u0131 (timeout)” ayarlar\u0131, bir iste\u011fin belirli bir s\u00fcrede yan\u0131t alamamas\u0131 durumunda kesilmesini sa\u011flayarak kaynaklar\u0131n gereksiz yere me\u015fgul edilmesini engeller. Ayr\u0131ca, “hacim b\u00f6lmeleri (bulkhead)” gibi stratejiler, farkl\u0131 hizmetler i\u00e7in kaynaklar\u0131 izole ederek bir hizmetteki hatan\u0131n di\u011ferlerini etkilemesini \u00f6nler. T\u00fcm bu mekanizmalar, API’lar\u0131n kar\u015f\u0131la\u015ft\u0131\u011f\u0131 \u00e7e\u015fitli zorluklara ra\u011fmen sistemin genel stabilitesini ve g\u00fcvenilirli\u011fini korumay\u0131 hedefler. Dolay\u0131s\u0131yla, API dayan\u0131kl\u0131l\u0131k testleri, bu mekanizmalar\u0131n ne kadar etkili \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 do\u011frulamak ve potansiyel zay\u0131fl\u0131klar\u0131 hen\u00fcz \u00fcretim ortam\u0131na \u00e7\u0131kmadan \u00f6nce tespit etmek i\u00e7in kritik bir ad\u0131md\u0131r.<\/p>\n
Bir API’\u0131n yaln\u0131zca do\u011fru sonu\u00e7lar \u00fcretmesi yeterli de\u011fildir; ayn\u0131 zamanda zorlu ko\u015fullar alt\u0131nda da beklendi\u011fi gibi \u00e7al\u0131\u015fmas\u0131 gerekir. Bu nedenle, da\u011f\u0131t\u0131mdan \u00f6nce kapsaml\u0131 bir dayan\u0131kl\u0131l\u0131k testi s\u00fcreci izlemek zorunludur. Peki, bu s\u00fcreci nas\u0131l yap\u0131land\u0131r\u0131r\u0131z ve hangi ara\u00e7lar\u0131 kullan\u0131r\u0131z? Temel olarak, API dayan\u0131kl\u0131l\u0131k testleri, sistemin s\u0131n\u0131rlar\u0131n\u0131 zorlayarak ve bilerek hatalara neden olarak, API’\u0131n bu durumlara nas\u0131l tepki verdi\u011fini g\u00f6zlemlemeyi ama\u00e7lar. Bu s\u00fcre\u00e7, proaktif bir yakla\u015f\u0131mla olas\u0131 sorunlar\u0131 \u00f6nceden tespit etmemizi ve \u00e7\u00f6z\u00fcmler \u00fcretmemizi sa\u011flar.<\/p>\n
\u0130lk ad\u0131m, bir test plan\u0131 olu\u015fturmakt\u0131r. Bu plan, hangi API’lar\u0131n test edilece\u011fini, hangi dayan\u0131kl\u0131l\u0131k senaryolar\u0131n\u0131n sim\u00fcle edilece\u011fini (\u00f6rne\u011fin, a\u011f gecikmesi, servis kesintisi, a\u015f\u0131r\u0131 y\u00fck), beklenen sonu\u00e7lar\u0131 ve ba\u015far\u0131s\u0131zl\u0131k durumunda neyin kabul edilebilir oldu\u011funu belirlemelidir. Genellikle, test yakla\u015f\u0131mlar\u0131n\u0131 birka\u00e7 ana kategoriye ay\u0131rabiliriz: Y\u00fck Testleri, Stres Testleri ve Hata Enjeksiyonu Testleri. Y\u00fck testleri, API’\u0131n normal ve beklenen trafik alt\u0131nda nas\u0131l performans g\u00f6sterdi\u011fini de\u011ferlendirirken, stres testleri API’\u0131 kapasitesinin \u00f6tesine zorlayarak k\u0131r\u0131lma noktas\u0131n\u0131 ve dayan\u0131kl\u0131l\u0131k mekanizmalar\u0131n\u0131n devreye girip girmedi\u011fini anlamam\u0131z\u0131 sa\u011flar. Hata enjeksiyonu testleri ise \u00f6zellikle kaos m\u00fchendisli\u011fi prensipleriyle yak\u0131ndan ili\u015fkilidir ve sistemin belirli hata senaryolar\u0131na kar\u015f\u0131 nas\u0131l tepki verdi\u011fini do\u011frudan g\u00f6zlemlemeye odaklan\u0131r.<\/p>\n
Bu testleri ger\u00e7ekle\u015ftirmek i\u00e7in kullanabilece\u011fimiz \u00e7e\u015fitli ara\u00e7lar bulunmaktad\u0131r. \u00d6rne\u011fin, API’lar\u0131n i\u015flevselli\u011fini ve temel y\u00fck alt\u0131nda performans\u0131n\u0131 test etmek i\u00e7in Postman gibi ara\u00e7lar basit senaryolar i\u00e7in yeterli olabilirken, daha karma\u015f\u0131k ve y\u00fcksek hacimli y\u00fck testleri i\u00e7in Apache JMeter veya k6 gibi ara\u00e7lar tercih edilir. Bu ara\u00e7lar, ayn\u0131 anda binlerce sanal kullan\u0131c\u0131y\u0131 sim\u00fcle ederek API’\u0131n\u0131za yo\u011fun trafik g\u00f6ndermenizi ve yan\u0131t s\u00fcreleri, hata oranlar\u0131 gibi kritik metrikleri toplaman\u0131z\u0131 sa\u011flar. Ayr\u0131ca, kaos m\u00fchendisli\u011fi ve hata enjeksiyonu i\u00e7in Gremlin, Chaos Mesh veya LitmusChaos gibi \u00f6zel platformlar mevcuttur. Bu platformlar, belirli servisleri rastgele kapatmaktan, a\u011f gecikmelerini veya paket kay\u0131plar\u0131n\u0131 enjekte etmeye kadar geni\u015f bir yelpazede hata senaryolar\u0131n\u0131 sim\u00fcle etme yetene\u011fi sunar. Testler s\u0131ras\u0131nda, API’\u0131n ve arkas\u0131ndaki sistemin izleme (monitoring) ve g\u00f6zlemlenebilirlik (observability) ara\u00e7lar\u0131yla entegre olmas\u0131 kritik \u00f6neme sahiptir. Prometheuse, Grafana veya Datadog gibi ara\u00e7lar, testlerin etkisi alt\u0131nda sistem metriklerini ger\u00e7ek zamanl\u0131 olarak izlememize olanak tan\u0131r. B\u00f6ylece, API’\u0131n hangi noktada zorland\u0131\u011f\u0131n\u0131, hangi kaynaklar\u0131n t\u00fckendi\u011fini veya hangi dayan\u0131kl\u0131l\u0131k mekanizmalar\u0131n\u0131n tetiklendi\u011fini net bir \u015fekilde g\u00f6rebiliriz. Bu kapsaml\u0131 yakla\u015f\u0131m, API’lar\u0131m\u0131z\u0131n sadece i\u015flevsel de\u011fil, ayn\u0131 zamanda zorlu ko\u015fullara kar\u015f\u0131 diren\u00e7li oldu\u011fundan emin olmam\u0131z\u0131 sa\u011flar.<\/p>\n
Ger\u00e7ek d\u00fcnya senaryolar\u0131, API dayan\u0131kl\u0131l\u0131k testlerinin neden bu kadar \u00f6nemli oldu\u011funu en iyi \u015fekilde a\u00e7\u0131klar. Hayal edin: B\u00fcy\u00fck bir e-ticaret platformunuz var ve \u00f6zellikle indirim d\u00f6nemlerinde veya kampanya zamanlar\u0131nda, “stok sorgulama” API’\u0131n\u0131zda ciddi yava\u015flamalar ya\u015f\u0131yorsunuz. M\u00fc\u015fteriler \u00fcr\u00fcnlerin stok durumunu g\u00f6remiyor, sepetlerine ekleyemiyor veya sipari\u015f tamamlama s\u00fcreci uzuyor. Bu durum, do\u011frudan sat\u0131\u015f kayb\u0131na ve olumsuz bir kullan\u0131c\u0131 deneyimine yol a\u00e7ar. \u0130\u015fte bu noktada, API dayan\u0131kl\u0131l\u0131k testleri devreye girer.<\/p>\n
\u0130lk ad\u0131m, bu yava\u015flaman\u0131n nedenini belirlemektir. \u0130zleme ara\u00e7lar\u0131m\u0131z (\u00f6rne\u011fin, Prometheus ve Grafana) bize stok sorgulama API’\u0131n\u0131n ortalama yan\u0131t s\u00fcresinin normalin \u00e7ok \u00fczerine \u00e7\u0131kt\u0131\u011f\u0131n\u0131 ve hata oranlar\u0131n\u0131n artt\u0131\u011f\u0131n\u0131 g\u00f6steriyor. Ancak, sorun API’\u0131n kendisinde mi, yoksa ba\u011f\u0131ml\u0131 oldu\u011fu bir veritaban\u0131 veya ba\u015fka bir mikroserviste mi? Bu soruyu yan\u0131tlamak i\u00e7in bir y\u00fck testi senaryosu olu\u015ftururuz. k6 veya Apache JMeter kullanarak, normalin 2-3 kat\u0131 kadar e\u015fzamanl\u0131 istek g\u00f6ndeririz. Bu test s\u0131ras\u0131nda, stok servisi \u00fczerindeki CPU ve bellek kullan\u0131m\u0131n\u0131n tavan yapt\u0131\u011f\u0131n\u0131, veritaban\u0131 ba\u011flant\u0131 havuzunun doldu\u011funu ve veritaban\u0131 sorgular\u0131n\u0131n \u00e7ok yava\u015f \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 fark ederiz. Bu, stok servisi ile veritaban\u0131 aras\u0131ndaki ileti\u015fimde bir darbo\u011faz oldu\u011funu g\u00f6sterir.<\/p>\n
\u015eimdi, dayan\u0131kl\u0131l\u0131k mekanizmalar\u0131m\u0131z\u0131n bu senaryoya kar\u015f\u0131 ne kadar etkili oldu\u011funu test etme zaman\u0131. Stok sorgulama API’m\u0131zda zaten bir “devre kesici” deseni ve “zaman a\u015f\u0131m\u0131” ayarlar\u0131 bulunuyordu. Amac\u0131m\u0131z, veritaban\u0131n\u0131n yava\u015flamas\u0131n\u0131 sim\u00fcle ederek bu mekanizmalar\u0131n do\u011fru bir \u015fekilde tetiklenip tetiklenmedi\u011fini ve sistemin graceful degradation (zarif bozulma) sergileyip sergilemedi\u011fini g\u00f6rmektir. Bir hata enjeksiyon arac\u0131 (\u00f6rne\u011fin, Gremlin) kullanarak, stok servisi ile veritaban\u0131 aras\u0131ndaki a\u011f trafi\u011fine kas\u0131tl\u0131 olarak 5 saniyelik bir gecikme ekleriz. Bu, veritaban\u0131n\u0131n yan\u0131t s\u00fcrelerini uzat\u0131r. Beklentimiz, API’daki 3 saniyelik zaman a\u015f\u0131m\u0131 s\u00fcresinin dolmas\u0131 ve devre kesicinin a\u00e7\u0131lmas\u0131d\u0131r. Devre kesici a\u00e7\u0131ld\u0131\u011f\u0131nda, yeni istekler do\u011frudan yedek (fallback) bir mekanizmaya y\u00f6nlendirilmelidir. Bu yedek mekanizma, belki de son bilinen stok bilgisini g\u00f6steren \u00f6nbelle\u011fe al\u0131nm\u0131\u015f bir veri veya kullan\u0131c\u0131lara ge\u00e7ici bir “stok bilgisi mevcut de\u011fil” mesaj\u0131 sunan basit bir yan\u0131t olabilir.<\/p>\n
Test sonu\u00e7lar\u0131, devre kesicinin beklendi\u011fi gibi \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131, yava\u015f veritaban\u0131na giden istekleri kesti\u011fini ve API’\u0131n bir s\u00fcre sonra h\u0131zl\u0131 bir “stok bilgisi mevcut de\u011fil” yan\u0131t\u0131 d\u00f6nd\u00fcrd\u00fc\u011f\u00fcn\u00fc g\u00f6sterdi. Bu, sistemin tamamen \u00e7\u00f6kmesini engelledi ve kullan\u0131c\u0131lar\u0131n en az\u0131ndan ne oldu\u011funu anlamalar\u0131n\u0131 sa\u011flad\u0131. Bu vaka analizi, API dayan\u0131kl\u0131l\u0131k testlerinin sadece hatalar\u0131 bulmakla kalmay\u0131p, ayn\u0131 zamanda olas\u0131 kesintilerin etkisini en aza indirecek kurtarma mekanizmalar\u0131n\u0131n etkinli\u011fini de do\u011frulamak i\u00e7in ne kadar de\u011ferli oldu\u011funu ortaya koymaktad\u0131r. Test sonu\u00e7lar\u0131na g\u00f6re, veritaban\u0131 taraf\u0131nda optimizasyonlar yap\u0131lmas\u0131na, stok bilgilerinin \u00f6nbelle\u011fe al\u0131nmas\u0131 i\u00e7in Redis gibi bir \u00e7\u00f6z\u00fcm eklenmesine ve devre kesicinin daha hassas ayarlanmas\u0131na karar verildi. Bu sayede, gelecekteki yo\u011fun d\u00f6nemlerde benzer sorunlar\u0131n \u00f6n\u00fcne ge\u00e7ilmesi hedeflendi.<\/p>\n
Modern da\u011f\u0131t\u0131lm\u0131\u015f sistemler, karma\u015f\u0131kl\u0131klar\u0131 nedeniyle \u00f6ng\u00f6r\u00fclemeyen bir\u00e7ok hata senaryosuna a\u00e7\u0131kt\u0131r. Bu sistemlerin ger\u00e7ek d\u00fcnya ko\u015fullar\u0131nda ne kadar dayan\u0131kl\u0131 oldu\u011funu anlaman\u0131n en etkili yollar\u0131ndan biri de Chaos Engineering’dir. Chaos Engineering, ad\u0131ndan da anla\u015f\u0131laca\u011f\u0131 gibi, sistemlerinizde kas\u0131tl\u0131 olarak kaosa neden olarak, onlar\u0131n bu durumlara nas\u0131l tepki verdi\u011fini g\u00f6zlemleme prati\u011fidir. Geleneksel test y\u00f6ntemlerinden farkl\u0131 olarak, Chaos Engineering’in amac\u0131 belirli bir hatay\u0131 bulmak de\u011fil, sistemin i\u00e7indeki zay\u0131f noktalar\u0131 ve beklenmedik ba\u011f\u0131ml\u0131l\u0131klar\u0131 ortaya \u00e7\u0131karmakt\u0131r. Bu yakla\u015f\u0131m, sistemlerinizin yaln\u0131zca beklenen durumlar i\u00e7in de\u011fil, ayn\u0131 zamanda beklenmeyen ar\u0131zalar i\u00e7in de haz\u0131r olmas\u0131n\u0131 sa\u011flar.<\/p>\n
Chaos Engineering’in temel prensibi, d\u00f6rt ad\u0131mdan olu\u015fur: \u0130lk olarak, sistemin normal davran\u0131\u015f\u0131n\u0131 temsil eden bir “dura\u011fan durum” hipotezi tan\u0131mlars\u0131n\u0131z. \u00d6rne\u011fin, “ana \u00f6deme API’miz, bir veritaban\u0131 sunucusunun kapat\u0131lmas\u0131 durumunda bile saniyede en az 50 i\u015flem ger\u00e7ekle\u015ftirmeye devam edecektir” gibi. \u0130kinci olarak, bu hipotezi \u00e7\u00fcr\u00fctecek bir deney tasarlars\u0131n\u0131z. Bu, rastgele bir mikroservisi kapatmak, a\u011f gecikmesi enjekte etmek, CPU veya bellek t\u00fcketimini art\u0131rmak gibi \u00e7e\u015fitli hata enjeksiyonlar\u0131n\u0131 i\u00e7erebilir. \u00dc\u00e7\u00fcnc\u00fc ad\u0131mda, deneyi uygular ve sistemin davran\u0131\u015f\u0131n\u0131 ger\u00e7ek zamanl\u0131 olarak izlersiniz. Metrikler, loglar ve izleme ara\u00e7lar\u0131, sistemin hipotezinize uygun tepki verip vermedi\u011fini anlaman\u0131z i\u00e7in kritik \u00f6neme sahiptir. Son olarak, g\u00f6zlemlerinizi analiz eder ve hipotezinizi do\u011frulayacak veya \u00e7\u00fcr\u00fctecek sonu\u00e7lar \u00e7\u0131kar\u0131rs\u0131n\u0131z. E\u011fer hipoteziniz \u00e7\u00fcr\u00fcrse, bu, sisteminizde bir zay\u0131fl\u0131k oldu\u011fu anlam\u0131na gelir ve bu zay\u0131fl\u0131\u011f\u0131 gidermek i\u00e7in iyile\u015ftirmeler yapman\u0131z gerekir.<\/p>\n
Hata enjeksiyonu i\u00e7in \u00e7e\u015fitli ara\u00e7lar ve y\u00f6ntemler kullan\u0131labilir. Mikroservis tabanl\u0131 bir mimaride, Kubernetes gibi konteyner orkestrasyon ara\u00e7lar\u0131 \u00fczerine kurulu Chaos Mesh veya LitmusChaos gibi platformlar olduk\u00e7a pop\u00fclerdir. Bu ara\u00e7lar, belirli pod’lar\u0131 \u00f6ld\u00fcrmek, a\u011f trafi\u011fine gecikme eklemek veya belirli kaynaklar\u0131 t\u00fcketmek gibi operasyonlar\u0131 kolayca ger\u00e7ekle\u015ftirmenizi sa\u011flar. \u0130\u015fte basit bir senaryoda, bir hizmete kas\u0131tl\u0131 olarak gecikme enjekte etmek i\u00e7in kullan\u0131labilecek teorik bir komut \u00f6rne\u011fi:<\/p>\n
\n# Belirli bir pod'a 5 saniyelik a\u011f gecikmesi ekleme (\u00f6rne\u011fin, Chaos Mesh ile)\nkubectl apply -f - <\n<\/code><\/p>\n
Bu t\u00fcr bir deneyde, hedef API'm\u0131za d\u0131\u015far\u0131dan istekler g\u00f6ndererek ve ayn\u0131 zamanda sistem izleme ara\u00e7lar\u0131m\u0131z\u0131 kullanarak, gecikme enjeksiyonunun API'\u0131n yan\u0131t s\u00fcrelerine, hata oranlar\u0131na ve ba\u011f\u0131ml\u0131 servislerin davran\u0131\u015f\u0131na nas\u0131l etki etti\u011fini g\u00f6zlemleriz. Devre kesicilerin a\u00e7\u0131l\u0131p a\u00e7\u0131lmad\u0131\u011f\u0131n\u0131, geri deneme mekanizmalar\u0131n\u0131n do\u011fru \u00e7al\u0131\u015f\u0131p \u00e7al\u0131\u015fmad\u0131\u011f\u0131n\u0131 ve yedek mekanizmalar\u0131n devreye girip girmedi\u011fini kontrol ederiz. Chaos Engineering, sadece mevcut zay\u0131fl\u0131klar\u0131 bulmakla kalmaz, ayn\u0131 zamanda m\u00fchendislik ekibinizin olas\u0131 ar\u0131zalara kar\u015f\u0131 daha bilin\u00e7li ve haz\u0131rl\u0131kl\u0131 olmas\u0131n\u0131 sa\u011flayarak genel sistem g\u00fcvenli\u011fini ve g\u00fcvenilirli\u011fini art\u0131r\u0131r. Bu s\u00fcrekli \u00f6\u011frenme ve iyile\u015ftirme d\u00f6ng\u00fcs\u00fc, g\u00fc\u00e7l\u00fc ve dayan\u0131kl\u0131 API'lar olu\u015fturman\u0131n temelidir.<\/p>\n
Performans ve Y\u00fck Testleri ile Dayan\u0131kl\u0131l\u0131k S\u0131n\u0131rlar\u0131n\u0131 Ke\u015ffetmek M\u00fcmk\u00fcn m\u00fcd\u00fcr?<\/h3>\n
API dayan\u0131kl\u0131l\u0131\u011f\u0131 denince akla gelen ilk \u015fey genellikle sistemin hata tolerans\u0131 olsa da, performans ve y\u00fck testleri de bu dayan\u0131kl\u0131l\u0131k yolculu\u011funun ayr\u0131lmaz bir par\u00e7as\u0131d\u0131r. Neden mi? \u00c7\u00fcnk\u00fc bir API, normal \u015fartlar alt\u0131nda sorunsuz \u00e7al\u0131\u015fsa bile, yo\u011fun trafik veya s\u0131n\u0131rl\u0131 kaynaklarla kar\u015f\u0131la\u015ft\u0131\u011f\u0131nda dayan\u0131kl\u0131l\u0131k sorunlar\u0131 ya\u015fayabilir. Bu testler, API'\u0131n\u0131z\u0131n stres alt\u0131nda nas\u0131l davrand\u0131\u011f\u0131n\u0131, performans d\u00fc\u015f\u00fc\u015flerinin ne zaman ba\u015flad\u0131\u011f\u0131n\u0131 ve sistemin k\u0131r\u0131lma noktalar\u0131n\u0131 ke\u015ffetmenize olanak tan\u0131r. Dolay\u0131s\u0131yla, performans ve y\u00fck testleri, API'\u0131n\u0131z\u0131n sadece i\u015flevsel de\u011fil, ayn\u0131 zamanda zorlu ko\u015fullar alt\u0131nda da kararl\u0131 ve g\u00fcvenilir oldu\u011fundan emin olmak i\u00e7in kritik bir rol oynar.<\/p>\n
Y\u00fck testleri (Load Testing), API'\u0131n beklenen kullan\u0131c\u0131 y\u00fck\u00fc alt\u0131nda ve belirli bir s\u00fcre boyunca performans\u0131n\u0131 \u00f6l\u00e7meyi hedefler. Amac\u0131m\u0131z, normal operasyonel ko\u015fullar alt\u0131nda API'\u0131n yan\u0131t s\u00fcreleri, i\u015flem hacmi ve kaynak t\u00fcketimi gibi metriklerin kabul edilebilir s\u0131n\u0131rlar i\u00e7inde olup olmad\u0131\u011f\u0131n\u0131 anlamakt\u0131r. Bu testler, API'\u0131n mevcut altyap\u0131 ve mimariyle ne kadar trafi\u011fi kald\u0131rabilece\u011fini g\u00f6sterir. Stres testleri (Stress Testing) ise bir ad\u0131m \u00f6teye giderek, API'\u0131 kapasitesinin \u00f6tesine zorlar. Bu testler, sistemin k\u0131r\u0131lma noktas\u0131n\u0131 bulmay\u0131, a\u015f\u0131r\u0131 y\u00fck alt\u0131nda hangi bile\u015fenlerin \u00f6nce ba\u015far\u0131s\u0131z oldu\u011funu ve sistemin bu durumdan nas\u0131l kurtuldu\u011funu g\u00f6zlemlemeyi ama\u00e7lar. Yani, dayan\u0131kl\u0131l\u0131k mekanizmalar\u0131n\u0131z\u0131n (devre kesiciler, geri denemeler vb.) ger\u00e7ekten devreye girip girmedi\u011fini ve i\u015flerini do\u011fru yap\u0131p yapmad\u0131klar\u0131n\u0131 anlaman\u0131n en iyi yollar\u0131ndan biridir. \u00d6rne\u011fin, bir API'\u0131n %99.9 \u00e7al\u0131\u015fma s\u00fcresi (uptime) taahh\u00fcd\u00fc varsa, stres testleri bu taahh\u00fcd\u00fcn ger\u00e7ek\u00e7i olup olmad\u0131\u011f\u0131n\u0131 veya hangi ko\u015fullar alt\u0131nda bu taahh\u00fcd\u00fcn ihlal edilebilece\u011fini ortaya koyar.<\/p>\n
Bu testler i\u00e7in k6 veya Apache JMeter gibi ara\u00e7lar olduk\u00e7a etkilidir. \u00d6rne\u011fin, k6 ile belirli bir API endpoint'ine saniyede y\u00fczlerce istek g\u00f6ndererek yan\u0131t s\u00fcrelerini ve hata oranlar\u0131n\u0131 izleyebiliriz. \u0130\u015fte k6 ile basit bir y\u00fck testi senaryosuna ait bir kod blo\u011fu:<\/p>\n
\nimport http from 'k6\/http';\nimport { check, sleep } from 'k6';\n\nexport const options = {\n stages: [\n { duration: '30s', target: 200 }, \/\/ 30 saniyede 200 sanal kullan\u0131c\u0131ya ula\u015f\n { duration: '1m', target: 200 }, \/\/ 1 dakika boyunca 200 kullan\u0131c\u0131y\u0131 koru\n { duration: '30s', target: 0 }, \/\/ 30 saniyede kullan\u0131c\u0131 say\u0131s\u0131n\u0131 s\u0131f\u0131ra d\u00fc\u015f\u00fcr\n ],\n};\n\nexport default function () {\n const res = http.get('https:\/\/api.example.com\/products');\n check(res, {\n 'status is 200': (r) => r.status === 200,\n 'response time < 200ms': (r) => r.timings.duration < 200,\n });\n sleep(1); \/\/ Her istek aras\u0131nda 1 saniye bekle\n}\n<\/pre>\n<\/code><\/p>\n
Bu test senaryosu, API'\u0131n belirli bir y\u00fck alt\u0131nda nas\u0131l davrand\u0131\u011f\u0131n\u0131 ve belirledi\u011fimiz performans e\u015fiklerini kar\u015f\u0131lay\u0131p kar\u015f\u0131lamad\u0131\u011f\u0131n\u0131 g\u00f6rmemizi sa\u011flar. E\u011fer yan\u0131t s\u00fcreleri beklentilerin \u00fczerine \u00e7\u0131karsa veya hata oranlar\u0131 artarsa, bu bir dayan\u0131kl\u0131l\u0131k zay\u0131fl\u0131\u011f\u0131na i\u015faret eder. Tablolar da test sonu\u00e7lar\u0131n\u0131 g\u00f6rselle\u015ftirmek i\u00e7in harika bir yoldur. \u00d6rne\u011fin, farkl\u0131 y\u00fck seviyeleri alt\u0131nda API yan\u0131t s\u00fcrelerini g\u00f6steren bir tablo:<\/p>\n
\n\n\nY\u00fck Seviyesi (E\u015fzamanl\u0131 Kullan\u0131c\u0131)<\/th>\n Ortalama Yan\u0131t S\u00fcresi (ms)<\/th>\n Maksimum Yan\u0131t S\u00fcresi (ms)<\/th>\n Hata Oran\u0131 (%)<\/th>\n<\/tr>\n<\/thead>\n \n\n50<\/td>\n 120<\/td>\n 250<\/td>\n 0.1<\/td>\n<\/tr>\n \n200<\/td>\n 380<\/td>\n 1200<\/td>\n 0.5<\/td>\n<\/tr>\n \n500<\/td>\n 1500<\/td>\n 5000+<\/td>\n 15<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\nBu tablo, y\u00fck artt\u0131k\u00e7a yan\u0131t s\u00fcrelerinin \u00f6nemli \u00f6l\u00e7\u00fcde uzad\u0131\u011f\u0131n\u0131 ve hata oran\u0131n\u0131n artt\u0131\u011f\u0131n\u0131 g\u00f6steriyor. Bu durum, API'\u0131n 200 e\u015fzamanl\u0131 kullan\u0131c\u0131dan sonra performans sorunlar\u0131 ya\u015fad\u0131\u011f\u0131n\u0131 ve 500 kullan\u0131c\u0131da ciddi bir dayan\u0131kl\u0131l\u0131k zay\u0131fl\u0131\u011f\u0131 g\u00f6sterdi\u011fini ortaya koyar. Bu t\u00fcr sonu\u00e7lar, performans optimizasyonlar\u0131, otomatik \u00f6l\u00e7eklendirme veya daha etkili bir \u00f6nbellekleme stratejisi gibi iyile\u015ftirmelerin yap\u0131lmas\u0131 gerekti\u011fine i\u015faret eder. Performans ve y\u00fck testleri, API'lar\u0131n\u0131z\u0131n sadece bir \"ideal d\u00fcnya\" senaryosunda de\u011fil, ayn\u0131 zamanda ger\u00e7ek d\u00fcnyan\u0131n zorluklar\u0131 kar\u015f\u0131s\u0131nda da ne kadar sa\u011flam durdu\u011funu anlaman\u0131n anahtar\u0131d\u0131r.<\/p>\n