{"id":32848,"date":"2025-10-26T16:01:44","date_gmt":"2025-10-26T13:01:44","guid":{"rendered":"https:\/\/fatihsoysal.com\/blog\/chaos-testing-aws-eks-ile-aws-fis-dayanikliligi-artirma-kilavuzu\/"},"modified":"2025-10-26T16:01:44","modified_gmt":"2025-10-26T13:01:44","slug":"chaos-testing-aws-eks-ile-aws-fis-dayanikliligi-artirma-kilavuzu","status":"publish","type":"post","link":"https:\/\/fatihsoysal.com\/blog\/chaos-testing-aws-eks-ile-aws-fis-dayanikliligi-artirma-kilavuzu\/","title":{"rendered":"Chaos Testing AWS EKS ile AWS FIS: Dayan\u0131kl\u0131l\u0131\u011f\u0131 Art\u0131rma K\u0131lavuzu"},"content":{"rendered":"

<\/p>\n

AWS EKS k\u00fcmenizin beklenmedik ar\u0131zalara kar\u015f\u0131 ne kadar dayan\u0131kl\u0131 oldu\u011funu merak m\u0131 ediyorsunuz? AWS FIS ile Chaos Testing yaparak uygulamalar\u0131n\u0131z\u0131n zorlu ko\u015fullarda bile kararl\u0131l\u0131\u011f\u0131n\u0131 nas\u0131l korudu\u011funu ke\u015ffedin. Bu kapsaml\u0131 rehber, dayan\u0131kl\u0131l\u0131k m\u00fchendisli\u011finde ustala\u015fman\u0131za yard\u0131mc\u0131 olacak ve AWS Community Day Bangalore 2025’teki sunumun ruhunu yans\u0131tarak, bulut yerel uygulamalar\u0131n\u0131z\u0131n sars\u0131lmaz bir kararl\u0131l\u0131kla \u00e7al\u0131\u015fmas\u0131n\u0131 sa\u011flaman\u0131n yollar\u0131n\u0131 ad\u0131m ad\u0131m \u00f6\u011fretecek. G\u00fcn\u00fcm\u00fcz\u00fcn dinamik ve karma\u015f\u0131k mikroservis mimarilerinde, sistemlerin yaln\u0131zca \u00e7al\u0131\u015f\u0131r durumda olmas\u0131 yeterli de\u011fildir; ayn\u0131 zamanda beklenmedik ar\u0131zalara kar\u015f\u0131 diren\u00e7li olmas\u0131 da hayati \u00f6nem ta\u015f\u0131maktad\u0131r. Bu makalede, bu direnci test etmek ve art\u0131rmak i\u00e7in Chaos Testing prensiplerini AWS Fault Injection Simulator (FIS) ile AWS Elastic Kubernetes Service (EKS) ortamlar\u0131nda nas\u0131l uygulayaca\u011f\u0131m\u0131z\u0131 detayl\u0131ca inceleyece\u011fiz.<\/p>\n

Modern uygulama geli\u015ftirme, b\u00fcy\u00fck \u00f6l\u00e7\u00fcde mikroservis mimarilerine ve bulut platformlar\u0131na y\u00f6nelmi\u015f durumda. AWS EKS gibi y\u00f6netilen Kubernetes servisleri, bu da\u011f\u0131t\u0131k sistemlerin orkestrasyonunu b\u00fcy\u00fck \u00f6l\u00e7\u00fcde kolayla\u015ft\u0131r\u0131yor olsa da, beraberinde yeni zorluklar\u0131 da getiriyor. Birbirine ba\u011fl\u0131 onlarca, hatta y\u00fczlerce mikroservis, farkl\u0131 availability zone’larda (AZ) \u00e7al\u0131\u015fan sunucular, a\u011f gecikmeleri, disk I\/O sorunlar\u0131 veya basit bir konfig\u00fcrasyon hatas\u0131 gibi say\u0131s\u0131z potansiyel ar\u0131za noktas\u0131na sahip olabilir. Geleneksel test y\u00f6ntemleri, bu t\u00fcr karma\u015f\u0131k sistemlerin ger\u00e7ek d\u00fcnya ko\u015fullar\u0131na ne kadar dayan\u0131kl\u0131 oldu\u011funu tam olarak ortaya koymakta genellikle yetersiz kal\u0131r. Bu nedenle, Chaos Testing, yani kaos m\u00fchendisli\u011fi, sistemlerinizin zay\u0131f noktalar\u0131n\u0131 proaktif bir \u015fekilde ortaya \u00e7\u0131karmak ve dayan\u0131kl\u0131l\u0131klar\u0131n\u0131 art\u0131rmak i\u00e7in vazge\u00e7ilmez bir ara\u00e7 haline gelmi\u015ftir. Bu yakla\u015f\u0131mla, sorunlar ortaya \u00e7\u0131kmadan \u00f6nce onlar\u0131 ke\u015ffedebilir ve d\u00fczeltebiliriz.<\/p>\n

D\u00fc\u015f\u00fcn\u00fcn ki, Black Friday gibi kritik bir al\u0131\u015fveri\u015f d\u00f6neminde, bir e-ticaret siteniz var ve yo\u011funlu\u011fun en tepe noktas\u0131nda kritik bir mikroservisiniz veya bir veritaban\u0131 ba\u011flant\u0131n\u0131z aniden kesiliyor. Bu durum, sadece sat\u0131\u015f kayb\u0131na de\u011fil, ayn\u0131 zamanda m\u00fc\u015fteri memnuniyetinin d\u00fc\u015fmesine ve marka itibar\u0131n\u0131n zedelenmesine yol a\u00e7abilir. \u00c7o\u011fu zaman bu t\u00fcr durumlar, “hi\u00e7 beklemedi\u011fimiz bir \u015fey oldu” \u015feklinde a\u00e7\u0131klan\u0131r. Ancak Chaos Engineering tam da bu “beklenmedik” durumlar\u0131 planl\u0131 bir \u015fekilde sim\u00fcle etmeyi ve sistemin bu durumlara nas\u0131l tepki verdi\u011fini g\u00f6zlemlemeyi hedefler. Kontroll\u00fc bir ortamda, bilerek ar\u0131zalar enjekte ederek sistemin bu ar\u0131zalara nas\u0131l tepki verdi\u011fini, kendini nas\u0131l onard\u0131\u011f\u0131n\u0131 veya hangi noktalarda k\u0131r\u0131ld\u0131\u011f\u0131n\u0131 g\u00f6r\u00fcr\u00fcz. Bu sayede, operasyon ekipleri, geli\u015ftiriciler ve hatta i\u015f birimleri, sistemin dayan\u0131kl\u0131l\u0131k e\u015fiklerini daha iyi anlayabilir ve gerekli iyile\u015ftirmeleri yapabilirler. AWS EKS, konteynerle\u015ftirilmi\u015f uygulamalar i\u00e7in esnek ve \u00f6l\u00e7eklenebilir bir platform sunar; ancak bu esneklik, ar\u0131za noktalar\u0131n\u0131n da artmas\u0131na neden olabilir. Bu y\u00fczden, AWS FIS ile EKS ortam\u0131nda Chaos Testing yapmak, bulut yerel uygulamalar\u0131n\u0131z\u0131n ger\u00e7ek d\u00fcnya stresine kar\u015f\u0131 haz\u0131rl\u0131kl\u0131 olmas\u0131n\u0131 sa\u011flaman\u0131n en etkili yollar\u0131ndan biridir. Bu, sadece bir teknik uygulama de\u011fil, ayn\u0131 zamanda ekiplerin sistemleri hakk\u0131nda derinlemesine bilgi edinmelerini ve operasyonel m\u00fckemmelli\u011fi s\u00fcrekli iyile\u015ftirmelerini sa\u011flayan k\u00fclt\u00fcrel bir de\u011fi\u015fimi de beraberinde getirir. Sonu\u00e7 olarak, da\u011f\u0131t\u0131k sistemlerin karma\u015f\u0131kl\u0131\u011f\u0131 artt\u0131k\u00e7a, Chaos Testing, g\u00fcvenilir ve dayan\u0131kl\u0131 uygulamalar sunman\u0131n temel ta\u015flar\u0131ndan biri haline gelmektedir. Bu s\u00fcre\u00e7, sadece sorunlar\u0131 tespit etmekle kalmaz, ayn\u0131 zamanda ekiplerin proaktif bir yakla\u015f\u0131mla sistemlerini s\u00fcrekli olarak g\u00fc\u00e7lendirmesine olanak tan\u0131r.<\/p>\n

Chaos Engineering ve AWS FIS Nedir? Temel Kavramlara H\u0131zl\u0131 Bir Bak\u0131\u015f<\/h2>\n
Chaos Engineering, da\u011f\u0131t\u0131k sistemlerin kararl\u0131l\u0131\u011f\u0131n\u0131 art\u0131rmak amac\u0131yla proaktif olarak ar\u0131zalar enjekte etme bilimi ve sanat\u0131d\u0131r. Bu disiplin, sistemlerin en zay\u0131f noktalar\u0131n\u0131 ortaya \u00e7\u0131karmay\u0131 ve bu zay\u0131fl\u0131klar\u0131 gidermeyi hedefler. Temel prensipleri aras\u0131nda bir hipotez olu\u015fturma (\u00f6rne\u011fin, “bir veri taban\u0131 replikas\u0131 ba\u015far\u0131s\u0131z olursa sistem \u00e7al\u0131\u015fmaya devam eder”), kontroll\u00fc bir deney yapma (ger\u00e7ekten replikay\u0131 devre d\u0131\u015f\u0131 b\u0131rakma), sonu\u00e7lar\u0131 g\u00f6zlemleme ve sistemin dayan\u0131kl\u0131l\u0131\u011f\u0131n\u0131 art\u0131rma yer al\u0131r. Bu s\u00fcre\u00e7, beklenmedik durumlar kar\u015f\u0131s\u0131nda sistemin nas\u0131l davranaca\u011f\u0131n\u0131 \u00f6nceden \u00f6\u011frenmemizi sa\u011flar ve b\u00f6ylece \u00fcretim ortam\u0131nda ya\u015fanabilecek b\u00fcy\u00fck kesintileri engelleme potansiyeli sunar. Manuel olarak bu t\u00fcr testleri yapmak olduk\u00e7a zahmetli, riskli ve hata yapmaya a\u00e7\u0131k bir s\u00fcre\u00e7 olabilir. \u0130\u015fte tam bu noktada AWS Fault Injection Simulator (FIS) devreye giriyor.<\/p>\n
AWS Fault Injection Simulator (FIS), AWS ortamlar\u0131nda kontroll\u00fc ar\u0131za enjeksiyon deneyleri y\u00fcr\u00fctmeyi kolayla\u015ft\u0131ran, tam olarak y\u00f6netilen bir hizmettir. FIS, EC2 instance’lar\u0131n\u0131 durdurma, yeniden ba\u015flatma, EKS pod’lar\u0131n\u0131 sonland\u0131rma, a\u011f gecikmesi veya paket kayb\u0131 enjekte etme gibi \u00e7e\u015fitli “aksiyonlar\u0131” ger\u00e7ekle\u015ftirebilir. Bu hizmetin en b\u00fcy\u00fck avantaj\u0131, ar\u0131za enjeksiyonunu otomatikle\u015ftirmesi ve bunu g\u00fcvenli bir \u015fekilde yapmas\u0131d\u0131r. FIS ile bir “Deney \u015eablonu” (Experiment Template) olu\u015fturursunuz. Bu \u015fablon, deneyin nas\u0131l yap\u0131laca\u011f\u0131n\u0131, hangi hedeflere uygulanaca\u011f\u0131n\u0131 (Target), hangi ar\u0131zalar\u0131n enjekte edilece\u011fini (Action) ve ne zaman durdurulaca\u011f\u0131n\u0131 (Stop Condition) tan\u0131mlar. Duru\u015f Ko\u015fullar\u0131 \u00f6zellikle \u00f6nemlidir, \u00e7\u00fcnk\u00fc bir deneyin kontrolden \u00e7\u0131kmas\u0131n\u0131 ve \u00fcretim ortam\u0131na zarar vermesini engellemek i\u00e7in g\u00fcvenlik mekanizmalar\u0131 sa\u011flarlar. \u00d6rne\u011fin, belirli bir CloudWatch alarm\u0131 tetiklendi\u011finde deneyi otomatik olarak durduracak bir duru\u015f ko\u015fulu belirleyebilirsiniz. Bu sayede, Chaos Testing g\u00fcvenli ve kontrol edilebilir bir s\u00fcre\u00e7 haline gelir.<\/p>\n
AWS FIS’in EKS ile entegrasyonu, Kubernetes k\u00fcmelerinde \u00e7al\u0131\u015fan mikroservis mimarilerinin dayan\u0131kl\u0131l\u0131\u011f\u0131n\u0131 test etmek i\u00e7in paha bi\u00e7ilmezdir. EKS ortam\u0131nda, Pod’lar, Node’lar, Availability Zone’lar veya hatta veri taban\u0131 ba\u011flant\u0131lar\u0131 gibi bir\u00e7ok farkl\u0131 seviyede ar\u0131zalar enjekte edebilirsiniz. \u00d6rne\u011fin, belirli bir deployment’a ait Pod’lar\u0131 rastgele sonland\u0131rarak uygulaman\u0131z\u0131n kendili\u011finden iyile\u015fme mekanizmalar\u0131n\u0131n (\u00f6rne\u011fin Kubernetes ReplicaSet’leri) d\u00fczg\u00fcn \u00e7al\u0131\u015f\u0131p \u00e7al\u0131\u015fmad\u0131\u011f\u0131n\u0131 test edebilirsiniz. Veya, belirli bir Availability Zone’daki t\u00fcm EC2 instance’lar\u0131n\u0131 durdurarak, uygulaman\u0131z\u0131n multi-AZ mimarisinin felaketlere kar\u015f\u0131 ne kadar diren\u00e7li oldu\u011funu sim\u00fcle edebilirsiniz. Bu testler, uygulaman\u0131z\u0131n sadece teoride de\u011fil, pratikte de beklendi\u011fi gibi davrand\u0131\u011f\u0131ndan emin olman\u0131z\u0131 sa\u011flar. AWS FIS, bu karma\u015f\u0131k deneyleri basit ve y\u00f6netilebilir bir aray\u00fcze d\u00f6n\u00fc\u015ft\u00fcrerek, ekiplerin daha az \u00e7abayla daha fazla g\u00fcvenilirlik elde etmesine yard\u0131mc\u0131 olur. Sonu\u00e7 olarak, AWS FIS, AWS EKS \u00fczerinde \u00e7al\u0131\u015fan bulut yerel uygulamalar\u0131n\u0131z\u0131n dayan\u0131kl\u0131l\u0131k m\u00fchendisli\u011fi s\u00fcre\u00e7lerinin vazge\u00e7ilmez bir par\u00e7as\u0131d\u0131r ve sistemlerinizin s\u00fcrekli olarak sa\u011flaml\u0131\u011f\u0131n\u0131 korumas\u0131n\u0131 sa\u011flamak i\u00e7in g\u00fc\u00e7l\u00fc bir ara\u00e7 seti sunar.<\/p>\n

AWS EKS Ortam\u0131n\u0131z\u0131 Chaos Testing’e Nas\u0131l Haz\u0131rlars\u0131n\u0131z? \u0130lk Ad\u0131mlar<\/h2>\n

AWS EKS k\u00fcmenizi AWS FIS ile Chaos Testing’e tabi tutmadan \u00f6nce, ortam\u0131n\u0131z\u0131n do\u011fru \u015fekilde yap\u0131land\u0131r\u0131ld\u0131\u011f\u0131ndan emin olman\u0131z gerekir. Bu \u00f6n haz\u0131rl\u0131k ad\u0131mlar\u0131, testlerinizin g\u00fcvenli, etkili ve \u00f6ng\u00f6r\u00fclebilir olmas\u0131n\u0131 sa\u011flar. \u0130lk olarak, \u00e7al\u0131\u015fan bir AWS EKS k\u00fcmenizin olmas\u0131 ve bu k\u00fcmeye eri\u015fim yetkinli\u011finizin bulunmas\u0131 gerekmektedir. E\u011fer hen\u00fcz bir EKS k\u00fcmeniz yoksa, AWS Y\u00f6netim Konsolu, eksctl<\/code> veya Terraform gibi ara\u00e7larla h\u0131zl\u0131ca bir tane olu\u015fturabilirsiniz. Bu makalenin oda\u011f\u0131 Chaos Testing oldu\u011fu i\u00e7in bir EKS k\u00fcmenizin zaten var oldu\u011funu varsayaca\u011f\u0131z.<\/p>\n

\u0130kinci ve en kritik ad\u0131m, AWS FIS’in EKS k\u00fcmenizle etkile\u015fime girebilmesi i\u00e7in gerekli IAM (Identity and Access Management) rollerini ve izinlerini yap\u0131land\u0131rmakt\u0131r. AWS FIS, arka planda EKS Pod’lar\u0131n\u0131 sonland\u0131rmak veya EC2 instance’lar\u0131n\u0131 durdurmak gibi i\u015flemler yapmak i\u00e7in belirli yetkilere ihtiya\u00e7 duyar. Bu yetkileri vermek i\u00e7in \u00f6zel bir IAM rol\u00fc olu\u015fturup FIS servisine ataman\u0131z gerekmektedir. Bu rol, FIS’in EKS kaynaklar\u0131n\u0131 hedefleyebilmesi ve \u00fczerinde belirli eylemleri ger\u00e7ekle\u015ftirebilmesi i\u00e7in gerekli izinleri i\u00e7ermelidir. Genellikle bu, EKS ile ilgili izinleri (\u00f6rne\u011fin eks:ListNodegroups<\/code>, eks:DescribeNodegroup<\/code>, eks:TerminatePod<\/code> gibi) ve hedefleyece\u011finiz EC2 instance’lar\u0131 veya di\u011fer AWS kaynaklar\u0131 i\u00e7in gerekli izinleri i\u00e7erir. Bu izinlerin en az ayr\u0131cal\u0131k prensibiyle verilmesi, yani yaln\u0131zca ihtiya\u00e7 duyulan yetkilerin atanmas\u0131 b\u00fcy\u00fck \u00f6nem ta\u015f\u0131r.<\/p>\n

A\u015fa\u011f\u0131da, EKS Pod’lar\u0131n\u0131 sonland\u0131rmak i\u00e7in AWS FIS taraf\u0131ndan kullan\u0131lacak \u00f6rnek bir IAM politikas\u0131 (JSON format\u0131nda) ve bu politikay\u0131 bir role nas\u0131l ba\u011flayaca\u011f\u0131n\u0131za dair bir \u00f6rnek bulabilirsiniz:<\/p>\n

\n{\n    \"Version\": \"2012-10-17\",\n    \"Statement\": [\n        {\n            \"Effect\": \"Allow\",\n            \"Action\": [\n                \"eks:ListNodegroups\",\n                \"eks:DescribeNodegroup\",\n                \"eks:ListPods\",\n                \"eks:TerminatePod\"\n            ],\n            \"Resource\": \"*\"\n        },\n        {\n            \"Effect\": \"Allow\",\n            \"Action\": [\n                \"ec2:DescribeInstances\",\n                \"ec2:DescribeTags\",\n                \"ec2:RebootInstances\",\n                \"ec2:StopInstances\"\n            ],\n            \"Resource\": \"*\"\n        },\n        {\n            \"Effect\": \"Allow\",\n            \"Action\": \"cloudwatch:PutMetricData\",\n            \"Resource\": \"*\"\n        },\n        {\n            \"Effect\": \"Allow\",\n            \"Action\": \"fis:InjectApiError\",\n            \"Resource\": \"*\"\n        }\n    ]\n}\n\n<\/pre>\n<\/code><\/p>\n
Bu IAM politikas\u0131n\u0131 AWS Konsolu \u00fczerinden bir IAM rol\u00fcne ekleyebilir veya AWS CLI ile olu\u015fturabilirsiniz. Rol\u00fc olu\u015ftururken, hizmet varl\u0131\u011f\u0131 (trust policy) olarak fis.amazonaws.com<\/code> servisini belirtmeyi unutmay\u0131n, b\u00f6ylece FIS bu rol\u00fc \u00fcstlenebilir.<\/p>\n
\n# FIS servisi i\u00e7in bir trust policy olu\u015fturma\ncat > fis-trust-policy.json << EOF\n{\n  \"Version\": \"2012-10-17\",\n  \"Statement\": [\n    {\n      \"Effect\": \"Allow\",\n      \"Principal\": {\n        \"Service\": \"fis.amazonaws.com\"\n      },\n      \"Action\": \"sts:AssumeRole\"\n    }\n  ]\n}\nEOF\n\n# fis-service-role ad\u0131nda bir IAM rol\u00fc olu\u015fturma\naws iam create-role --role-name fis-service-role --assume-role-policy-document file:\/\/fis-trust-policy.json\n\n# Yukar\u0131daki JSON politikas\u0131n\u0131 bir dosya olarak kaydedin (\u00f6rne\u011fin fis-eks-policy.json)\n# Ve bu politikay\u0131 yeni olu\u015fturdu\u011funuz role ili\u015ftirin\naws iam put-role-policy --role-name fis-service-role --policy-name FIS-EKS-ChaosPolicy --policy-document file:\/\/fis-eks-policy.json\n\n<\/pre>\n<\/code><\/p>\n
Ek olarak, kubectl<\/code> ve AWS CLI'nin yerel makinenizde veya CI\/CD ortam\u0131n\u0131zda kurulu ve yap\u0131land\u0131r\u0131lm\u0131\u015f olmas\u0131, EKS k\u00fcmenizle etkile\u015fim kurman\u0131z ve test sonu\u00e7lar\u0131n\u0131 g\u00f6zlemlemeniz i\u00e7in gereklidir. kubectl<\/code> ile Pod durumlar\u0131n\u0131, deployment'lar\u0131 ve di\u011fer Kubernetes kaynaklar\u0131n\u0131 kontrol ederken, AWS CLI ile AWS FIS deneylerini ba\u015flatabilir ve durdurabilirsiniz. Son olarak, test etmek istedi\u011finiz bir \u00f6rnek uygulaman\u0131n (\u00f6rne\u011fin, bir Nginx deployment'\u0131 veya basit bir mikroservis) EKS k\u00fcmenizde \u00e7al\u0131\u015ft\u0131\u011f\u0131ndan emin olun. Bu sayede, Chaos Testing'in uygulaman\u0131z \u00fczerindeki etkilerini somut bir \u015fekilde g\u00f6zlemleyebilirsiniz. Bu haz\u0131rl\u0131k ad\u0131mlar\u0131 tamamland\u0131\u011f\u0131nda, EKS ortam\u0131n\u0131zda AWS FIS ile g\u00fcvenle Chaos Testing deneyleri yapmaya haz\u0131rs\u0131n\u0131z demektir. Bu ad\u0131mlar\u0131n titizlikle uygulanmas\u0131, hem testlerin do\u011frulu\u011funu hem de olas\u0131 istenmeyen yan etkilerin minimize edilmesini garanti eder.<\/p>\n
AWS FIS ile EKS Pod'lar\u0131na Ar\u0131za Enjeksiyonu: Ad\u0131m Ad\u0131m Uygulama<\/h3>\n\u015eimdi s\u0131ra geldi AWS FIS'i kullanarak EKS ortam\u0131n\u0131zda somut bir Chaos Testing deneyi ger\u00e7ekle\u015ftirmeye. Bu b\u00f6l\u00fcm, temel bir senaryoyu ele alarak ad\u0131m ad\u0131m bir deney \u015fablonu olu\u015fturmay\u0131, hedefleri tan\u0131mlamay\u0131 ve deneyi ba\u015flatmay\u0131 anlatacak. Senaryomuz: \"Bir EKS k\u00fcmesindeki belirli bir deployment'a ait Pod'lar\u0131n rastgele bir k\u0131sm\u0131n\u0131 sonland\u0131rarak uygulaman\u0131n bu duruma nas\u0131l tepki verdi\u011fini g\u00f6zlemlemek.\" Bu test, Kubernetes'in kendi kendini iyile\u015ftirme mekanizmalar\u0131n\u0131n (\u00f6rne\u011fin ReplicaSet'lerin) beklenen \u015fekilde \u00e7al\u0131\u015ft\u0131\u011f\u0131ndan emin olmak i\u00e7in kritik \u00f6neme sahiptir.<\/p>\n
\u0130lk olarak, test etmek istedi\u011fimiz bir Kubernetes deployment'\u0131na ihtiyac\u0131m\u0131z var. Basit bir Nginx deployment'\u0131 kullanabiliriz. E\u011fer k\u00fcmenizde yoksa, a\u015fa\u011f\u0131daki YAML ile bir tane olu\u015fturabilirsiniz:<\/p>\n
\napiVersion: apps\/v1\nkind: Deployment\nmetadata:\n  name: nginx-deployment\n  labels:\n    app: nginx\nspec:\n  replicas: 3\n  selector:\n    matchLabels:\n      app: nginx\n  template:\n    metadata:\n      labels:\n        app: nginx\n    spec:\n      containers:\n      - name: nginx\n        image: nginx:latest\n        ports:\n        - containerPort: 80\n\n<\/pre>\n<\/code><\/p>\n
Bu deployment'\u0131 kubectl apply -f nginx-deployment.yaml<\/code> komutuyla k\u00fcmenize uygulay\u0131n. \u00dc\u00e7 adet Nginx Pod'unun \u00e7al\u0131\u015ft\u0131\u011f\u0131ndan emin olmak i\u00e7in kubectl get pods -l app=nginx<\/code> komutunu kullanabilirsiniz.<\/p>\n
\u015eimdi AWS FIS Deney \u015eablonu'nu olu\u015ftural\u0131m. AWS Konsolu'na gidin, \"Fault Injection Simulator\" hizmetini aray\u0131n ve sol men\u00fcden \"Experiment templates\" se\u00e7ene\u011fine t\u0131klay\u0131n. \"Create experiment template\" butonuna bas\u0131n. Burada a\u015fa\u011f\u0131daki ad\u0131mlar\u0131 izleyece\u011fiz:<\/p>\n
\nDescription:<\/strong> \"EKS Nginx Pod Sonland\u0131rma Deneyi\" gibi a\u00e7\u0131klay\u0131c\u0131 bir isim verin.<\/li>\n
IAM role:<\/strong> Daha \u00f6nce olu\u015fturdu\u011funuz fis-service-role<\/code> rol\u00fcn\u00fc se\u00e7in.<\/li>\n
Targets (Hedefler):<\/strong>\n\n\"Add target\" butonuna t\u0131klay\u0131n.<\/li>\n
Name:<\/strong> MyNginxPods<\/code> gibi bir isim verin.<\/li>\n
Resource type:<\/strong> aws:eks:pod<\/code> se\u00e7ene\u011fini se\u00e7in.<\/li>\n
Target method:<\/strong> \"All resources in specified resource tags or filters\" se\u00e7ene\u011fini i\u015faretleyin.<\/li>\n
Filters:<\/strong>\n\nField:<\/strong> eks:cluster-name<\/code><\/li>\n
Values:<\/strong> <\/code> (\u00d6rne\u011fin, my-eks-cluster<\/code>)<\/li>\n<\/ul>\n\nField:<\/strong> eks:namespace<\/code><\/li>\n
Values:<\/strong> default<\/code> (Nginx Pod'lar\u0131n\u0131z\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131 namespace)<\/li>\n<\/ul>\n\nField:<\/strong> eks:pod-label:app<\/code><\/li>\n
Values:<\/strong> nginx<\/code> (Nginx Pod'lar\u0131n\u0131z\u0131n etiketi)<\/li>\n<\/ul>\n<\/li>\n
Selection mode:<\/strong> \"Count\" se\u00e7ene\u011fini se\u00e7in ve 1<\/code> veya 2<\/code> gibi bir de\u011fer girin. Bu, her deneme \u00e7al\u0131\u015ft\u0131\u011f\u0131nda ka\u00e7 Pod'un hedeflenece\u011fini belirtir. Alternatif olarak \"Percent\" se\u00e7ene\u011fini se\u00e7ip, \u00f6rne\u011fin %50'sini de hedefleyebilirsiniz.<\/li>\n<\/ul>\n<\/li>\n
Actions (Aksiyonlar):<\/strong>\n\n\"Add action\" butonuna t\u0131klay\u0131n.<\/li>\n
Name:<\/strong> TerminateNginxPods<\/code> gibi bir isim verin.<\/li>\n
Action type:<\/strong> aws:eks:terminate-pods<\/code> se\u00e7ene\u011fini se\u00e7in. Bu aksiyon, se\u00e7ilen EKS Pod'lar\u0131n\u0131 sonland\u0131r\u0131r.<\/li>\n
Target:<\/strong> \u00d6nceki ad\u0131mda tan\u0131mlad\u0131\u011f\u0131n\u0131z hedef (MyNginxPods<\/code>) se\u00e7ene\u011fini belirleyin.<\/li>\n
Start after:<\/strong> E\u011fer birden fazla aksiyonunuz varsa, bu aksiyonun ne zaman ba\u015flayaca\u011f\u0131n\u0131 belirtebilirsiniz. \u015eu an i\u00e7in bo\u015f b\u0131rak\u0131n.<\/li>\n<\/ul>\n<\/li>\n
Stop conditions (Duru\u015f Ko\u015fullar\u0131):<\/strong>\n\nBu k\u0131s\u0131m olduk\u00e7a \u00f6nemlidir. Deneyin kontrolden \u00e7\u0131kmas\u0131n\u0131 \u00f6nlemek i\u00e7in bir CloudWatch alarm\u0131 belirleyebilirsiniz. \u00d6rne\u011fin, uygulaman\u0131z\u0131n HTTP 5xx hatalar\u0131 belirli bir e\u015fi\u011fin \u00fczerine \u00e7\u0131kt\u0131\u011f\u0131nda deneyi durduracak bir alarm olu\u015fturabilirsiniz. \"Add stop condition\" butonuna t\u0131klay\u0131n.<\/li>\n
CloudWatch alarm ARN:<\/strong> Olu\u015fturdu\u011funuz veya var olan bir CloudWatch alarm\u0131n\u0131n ARN'\u0131n\u0131 girin. \u00d6rne\u011fin, Nginx Pod'lar\u0131n\u0131z\u0131n CPU kullan\u0131m\u0131n\u0131n a\u015f\u0131r\u0131 y\u00fckseldi\u011fini veya belirli bir hata say\u0131s\u0131n\u0131n artt\u0131\u011f\u0131n\u0131 izleyen bir alarm. Bu \u00f6rnek i\u00e7in \u015fimdilik bo\u015f b\u0131rakabiliriz, ancak \u00fcretim ortam\u0131nda mutlaka kullanmal\u0131s\u0131n\u0131z.<\/li>\n<\/ul>\n<\/li>\n
Tags:<\/strong> Deney \u015fablonunuza etiketler ekleyebilirsiniz.<\/li>\n
Ayarlar\u0131 g\u00f6zden ge\u00e7irin ve \"Create experiment template\" butonuna t\u0131klay\u0131n.<\/li>\n<\/ol>\nDeney \u015fablonunuz olu\u015ftuktan sonra, onu ba\u015flatmaya haz\u0131rs\u0131n\u0131z. Olu\u015fturdu\u011funuz \u015fablonu se\u00e7in ve \"Start experiment\" butonuna t\u0131klay\u0131n. Bir onay penceresi a\u00e7\u0131lacak, burada \"Start experiment\" yazarak i\u015flemi onaylay\u0131n.<\/p>\n
Deney ba\u015flad\u0131ktan sonra, kubectl get pods -l app=nginx --watch<\/code> komutunu kullanarak Pod'lar\u0131n\u0131z\u0131n durumunu izleyebilirsiniz. K\u0131sa bir s\u00fcre sonra, baz\u0131 Nginx Pod'lar\u0131n\u0131n Terminating<\/code> durumuna ge\u00e7ti\u011fini ve ard\u0131ndan Kubernetes ReplicaSet'i taraf\u0131ndan yeni Pod'lar\u0131n olu\u015fturuldu\u011funu g\u00f6receksiniz. Bu, Kubernetes'in kendini iyile\u015ftirme mekanizmas\u0131n\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 g\u00f6sterir.<\/p>\n
Bu g\u00f6rsel betimleme, konsol ekran\u0131nda ad\u0131m ad\u0131m ilerlerken Pod'lar\u0131n durum de\u011fi\u015fikliklerini izlemenizi, kubectl<\/code> \u00e7\u0131kt\u0131s\u0131nda Terminating<\/code> ve ContainerCreating<\/code> gibi durumlar\u0131 g\u00f6rmenizi ve uygulaman\u0131z\u0131n kesintiye u\u011framadan devam edip etmedi\u011fini kontrol etmenizi sa\u011flar. Deney bittikten sonra FIS konsolunda deneyin durumunu ve sonu\u00e7lar\u0131n\u0131 inceleyebilirsiniz. Ba\u015far\u0131l\u0131 bir Chaos Testing, uygulaman\u0131z\u0131n bu t\u00fcr ar\u0131zalara kar\u015f\u0131 diren\u00e7li oldu\u011funu kan\u0131tlar ve size operasyonel g\u00fcven verir. Ancak, e\u011fer uygulama beklenen \u015fekilde tepki vermezse, bu bir iyile\u015ftirme f\u0131rsat\u0131d\u0131r ve sistemi daha dayan\u0131kl\u0131 hale getirmek i\u00e7in yap\u0131lmas\u0131 gereken de\u011fi\u015fiklikleri i\u015faret eder.<\/p>\n
Ger\u00e7ek D\u00fcnya Senaryolar\u0131 ve \u0130leri D\u00fczey Chaos Testing Teknikleri<\/h2>\nChaos Testing'in g\u00fcc\u00fc, sadece basit Pod sonland\u0131rma senaryolar\u0131n\u0131n \u00f6tesine ge\u00e7erek, ger\u00e7ek d\u00fcnya ar\u0131zalar\u0131n\u0131 sim\u00fcle etme yetene\u011finde yatar. AWS FIS, bu geni\u015f spektrumu destekleyerek ekiplerin karma\u015f\u0131k sistemlerini daha kapsaml\u0131 bir \u015fekilde test etmelerine olanak tan\u0131r. \u0130\u015fte iki farkl\u0131 ger\u00e7ek d\u00fcnya vaka analizi ve daha ileri d\u00fczey Chaos Testing teknikleri.<\/p>\n
Vaka Analizi 1: Bir Finansal Kurulu\u015fun AZ Ar\u0131zas\u0131 Sim\u00fclasyonu<\/h4>\nB\u00fcy\u00fck bir finansal kurulu\u015f, m\u00fc\u015fteri i\u015flemlerinin kesintisiz devaml\u0131l\u0131\u011f\u0131n\u0131 sa\u011flamak i\u00e7in AWS EKS \u00fczerinde \u00e7al\u0131\u015fan kritik bir mikroservis mimarisine sahipti. Uygulama, y\u00fcksek eri\u015filebilirlik i\u00e7in birden fazla Availability Zone'a (AZ) yay\u0131lm\u0131\u015ft\u0131. Ancak, \"Tek bir AZ'nin tamamen devre d\u0131\u015f\u0131 kalmas\u0131 durumunda sistemimiz ne kadar s\u00fcreyle \u00e7al\u0131\u015f\u0131r durumda kal\u0131r ve veri b\u00fct\u00fcnl\u00fc\u011f\u00fc sa\u011flan\u0131r m\u0131?\" sorusuna tam bir g\u00fcvenle yan\u0131t veremiyorlard\u0131. Geleneksel felaket kurtarma (DR) tatbikatlar\u0131 pahal\u0131 ve zaman al\u0131c\u0131yd\u0131. AWS FIS'i kullanarak, bir AZ'deki t\u00fcm EC2 instance'lar\u0131n\u0131 (EKS node'lar\u0131n\u0131) durdurma veya yeniden ba\u015flatma aksiyonunu i\u00e7eren bir deney \u015fablonu olu\u015fturdular (aws:ec2:stop-instances<\/code>).<\/p>\n
\nHipotez:<\/strong> Uygulama, bir AZ ar\u0131zas\u0131nda otomatik olarak kendini di\u011fer AZ'lere kayd\u0131racak ve m\u00fc\u015fteri deneyiminde fark edilir bir kesinti ya\u015fanmayacak.<\/li>\n
Deney:<\/strong> FIS ile bir AZ'deki t\u00fcm EKS node'lar\u0131 hedeflenerek durduruldu. Duru\u015f ko\u015fulu olarak, kritik i\u015flem hacminin belirli bir e\u015fi\u011fin alt\u0131na d\u00fc\u015fmesi veya y\u00fcksek hata oranlar\u0131 belirlendi.<\/li>\n
G\u00f6zlem:<\/strong> Deney s\u0131ras\u0131nda, Kubernetes'in Pod'lar\u0131 di\u011fer AZ'lerde yeniden \u00e7izelgeledi\u011fi g\u00f6zlemlendi. Ancak, baz\u0131 Pod'lar Pending<\/code> durumunda kald\u0131 \u00e7\u00fcnk\u00fc PersistentVolumeClaim'ler (PVC'ler) ilk AZ'deki EBS birimlerine ba\u011fl\u0131yd\u0131 ve bu birimler AZ'ler aras\u0131nda ta\u015f\u0131nam\u0131yordu. Ayr\u0131ca, baz\u0131 mikroservisler aras\u0131ndaki a\u011f ba\u011flant\u0131lar\u0131 yeniden kurulurken beklenenden daha uzun gecikmeler ya\u015fand\u0131.<\/li>\n
\u0130yile\u015ftirme:<\/strong>\n\nPersistentVolume'lar i\u00e7in AZ'ler aras\u0131 replikasyonu destekleyen \u00e7\u00f6z\u00fcmler (\u00f6rne\u011fin Amazon EFS veya farkl\u0131 CSI s\u00fcr\u00fcc\u00fcleri) ara\u015ft\u0131r\u0131ld\u0131 ve uyguland\u0131.<\/li>\n
Mikroservisler aras\u0131 ileti\u015fimi daha esnek hale getirmek i\u00e7in Service Mesh (Istio) konfig\u00fcrasyonlar\u0131 optimize edildi ve tolerans s\u00fcreleri ayarland\u0131.<\/li>\n
CloudWatch metrikleri ve alarmlar\u0131, bu t\u00fcr ar\u0131zalar\u0131 daha h\u0131zl\u0131 tespit etmek i\u00e7in geli\u015ftirildi.<\/li>\n<\/ul>\n<\/ul>\nBu deney, finansal kurulu\u015fun DR stratejilerindeki \u00f6nemli eksiklikleri ortaya koyarak, m\u00fc\u015fterilere kesintisiz hizmet sunma yetene\u011fini \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131rmas\u0131na yard\u0131mc\u0131 oldu.<\/p>\n
Vaka Analizi 2: Bir Oyun \u015eirketinin A\u011f Gecikmesi Testleri<\/h4>\nBir \u00e7evrimi\u00e7i oyun \u015firketi, EKS \u00fczerinde \u00e7al\u0131\u015fan ger\u00e7ek zamanl\u0131 \u00e7ok oyunculu oyun sunucular\u0131n\u0131n a\u011f sorunlar\u0131na kar\u015f\u0131 ne kadar dayan\u0131kl\u0131 oldu\u011funu merak ediyordu. \u00d6zellikle, oyun sunucular\u0131n\u0131n farkl\u0131 co\u011frafi b\u00f6lgelerdeki oyuncularla etkile\u015fiminde olu\u015fabilecek a\u011f gecikmelerinin kullan\u0131c\u0131 deneyimini nas\u0131l etkiledi\u011fi kritikti. AWS FIS, aws:ec2:inject-network-latency<\/code> gibi aksiyonlarla a\u011f gecikmesi enjekte etme yetene\u011fi sunar.<\/p>\n
\nHipotez:<\/strong> Belirli bir oranda a\u011f gecikmesi, oyun deneyimini \u00f6nemli \u00f6l\u00e7\u00fcde k\u00f6t\u00fcle\u015ftirmeyecek ve mevcut e\u015fle\u015ftirme algoritmalar\u0131 gecikmeli oyuncular\u0131 uygun \u015fekilde y\u00f6netebilecek.<\/li>\n
Deney:<\/strong> Oyun sunucular\u0131n\u0131n \u00e7al\u0131\u015ft\u0131\u011f\u0131 EC2 instance'lar\u0131na 50ms ve 100ms'lik gecikmeler enjekte edildi. Ayn\u0131 zamanda, oyun i\u00e7indeki oyuncu metrikleri (ping, frame drop, lag spike) ve e\u015fle\u015ftirme algoritmalar\u0131n\u0131n performans\u0131 izlendi.<\/li>\n
G\u00f6zlem:<\/strong> 50ms'lik gecikme kabul edilebilir bir seviyedeyken, 100ms'lik gecikme baz\u0131 oyun t\u00fcrlerinde (\u00f6rne\u011fin FPS oyunlar\u0131) \"kabul edilemez\" bir lag deneyimine yol a\u00e7t\u0131. E\u015fle\u015ftirme algoritmalar\u0131, gecikmeli oyuncular\u0131 ayn\u0131 lobiye atayarak deneyimi daha da k\u00f6t\u00fcle\u015ftirdi.<\/li>\n
\u0130yile\u015ftirme:<\/strong>\n\nOyun sunucular\u0131n\u0131n daha fazla b\u00f6lgede konu\u015fland\u0131r\u0131lmas\u0131 stratejisi g\u00fc\u00e7lendirildi.<\/li>\n
E\u015fle\u015ftirme algoritmalar\u0131, oyuncu gecikmesini de bir fakt\u00f6r olarak dahil edecek \u015fekilde g\u00fcncellendi.<\/li>\n
Kritik a\u011f yollar\u0131 i\u00e7in AWS Direct Connect veya AWS Global Accelerator gibi \u00e7\u00f6z\u00fcmler de\u011ferlendirildi.<\/li>\n<\/ul>\n<\/ul>\nBu testler, oyun \u015firketinin global oyunculara daha istikrarl\u0131 ve keyifli bir deneyim sunmas\u0131 i\u00e7in \u00f6nemli veriler sa\u011flad\u0131.<\/p>\n
Bu vaka analizleri, AWS FIS'in sadece Pod sonland\u0131rman\u0131n \u00f6tesinde, daha geni\u015f ve karma\u015f\u0131k senaryolar\u0131 test etmek i\u00e7in nas\u0131l kullan\u0131labilece\u011fini g\u00f6stermektedir. EKS \u00fczerindeki Chaos Testing, yaln\u0131zca altyap\u0131 seviyesindeki ar\u0131zalar\u0131 de\u011fil, ayn\u0131 zamanda uygulaman\u0131n kendisinin ve entegrasyonlar\u0131n\u0131n dayan\u0131kl\u0131l\u0131\u011f\u0131n\u0131 da test etmenize olanak tan\u0131r. Deneyleri otomatikle\u015ftirmek (\u00f6rne\u011fin CI\/CD pipeline'lar\u0131na entegre etmek veya AWS Lambda fonksiyonlar\u0131 ile belirli aral\u0131klarla \u00e7al\u0131\u015ft\u0131rmak) ve geli\u015fmi\u015f duru\u015f ko\u015fullar\u0131 (Prometheus metrikleri, \u00f6zel API \u00e7a\u011fr\u0131lar\u0131) kullanmak, Chaos Testing program\u0131n\u0131z\u0131n olgunlu\u011funu art\u0131r\u0131r. AWS FIS, EKS k\u00fcmenizle entegre olarak, bulut yerel uygulamalar\u0131n\u0131z\u0131n beklenmedik durumlara kar\u015f\u0131 tam donan\u0131ml\u0131 olmas\u0131n\u0131 sa\u011flar.<\/p>\n
Mobil uyumlu HTML \u00fcretimi i\u00e7in ise, CSS media query'ler kullanmak standart bir yakla\u015f\u0131md\u0131r. A\u015fa\u011f\u0131da, temel bir mobil uyumlu stil \u00f6rne\u011fi bulunmaktad\u0131r:<\/p>\n
\n