7 Nisan 2026 ikas Servis Kesintisi

Öncelikle, bize güvenen 15.000’den fazla kullanıcımıza ve onların müşterilerine, yaşanan bu kesinti nedeniyle özürlerimizi iletiyoruz.

Sorunun, altyapı sağlayıcımız Amazon Web Services kaynaklı olduğunu ve ikas sistemlerinden bağımsız geliştiğini şeffaflıkla paylaşmak isteriz. Bu kesintiyle beraber aksiyon ve önlem planlarımızda güncellemeler yaptık. 

İlk andan itibaren tüm teknik ekiplerimizle süreci yakından takip ettik ve duruma hızlıca müdahale ederek, sistemlerin yeniden stabil hale gelmesi için kesintisiz şekilde çalıştık. Yaşanan bu kesinti süresince iş akışınızın etkilenmiş olabileceğinin farkındayız. Sonraki süreçlerde benzer durumların etkisini en aza indirmek için altyapı tarafında ek önlemler almaya devam edeceğiz.

Anlayışınız ve sabrınız için teşekkür ederiz.

Bu paragraftan sonrası, teknik olarak kesinti hakkında daha fazla detay isteyen kullanıcı ve yazılım ekosistemine hitap etmektedir. Bu yazı ve teknik post-mortem belgesi, yaşananlar hakkında tam şeffaflık sağlamak amacıyla yayınlanmıştır. Sorularınız, önerileriniz veya geri bildirimleriniz için dev@ikas.com adresine ulaşabilirsiniz.

Zaman Çizelgesi

İlk olarak 7 Nisan 2026 saat 15:15’te Storefront API’ımızdaki searchProducts sorgusunun timeout bildirimleri ile durumdan haberdar olduk. Tüm kullanıcılarımızın ürünlerinin barındırıldığı OpenSearch servisimiz yanıt vermez hale geldi. Tüm satıcılarımızın sitelerinde ürünler görünmemeye başladı, ürünle ilgili sayfalar 502/503 hatası döndürdü. Kesinti 18:40’ta tam olarak sona erdi.

Bu yazıda ne olduğunu, neden olduğunu ve tekrar yaşanmaması için ne yapacağımızı olduğu gibi anlatıyoruz.

Saat	Olay
14:00	AWS OpenSearch servislerinde anormal bir yük tespit edildi ve bundan dolayı arama ve sitelere ürün yansımalarında gecikme yaşanmaya başlandı
14:20	20 dakika boyunca OpenSearch sunucu CPU’ları %100’ün altına düşmediği için yazdığımız takip scriptleri otomatik olarak OpenSearch servisini bir üst seviyeye yükseltme işlemini başlattı
15:02	OpenSearch servisi güncellenmesi tamamlandı
15:14	Storefront API’da searchProducts timeout alarmları tetiklendi. Arama altyapısının yanıt vermediği tespit edildi.
15:21	İncelendiğinde yapılan güncellemenin hemen ardından ikinci bir OpenSearch güncellemesini otomatik olarak başladığı tespit edildi. Bu güncellemenin sebebi ise OpenSearch Service Software Update’in otomatik uygulanmaya çalışması olduğu anlaşıldı. Normalde otomatik güncellemeler kapalı ama bunun neden olduğunu hâlâ bilmiyoruz. Fakat sistem üzerindeki anormal yükten dolayı ve ikinci güncelleme işlemi sunucuları ulaşılamaz hale getirdi ve güncelleme süreci tıkanmış oldu.
15:30	ikas Yönetim Paneli üzerinden satıcılarımıza ilk durum bildirimi gönderildi.
15:42	Güncellemenin otomatik olarak normale tamamlaması beklendi fakat böyle olmayınca  AWS Enterprise Support’a resmi destek talebi açıldı.
~16:15	AWS destek ekibi aktif Blue/Green Deployment sürecine müdahale edemeyeceği ve tıkanmış olan servis güncellemesini beklememiz gerektiği yönde geri bildirimde bulundu. Bunun üzerine hemen yeni bir OpenSearch servisi açma kararı verildi.
~16:15–17:00	Yeni AWS OpenSearch servisi oluşturuldu (~45 dakika).
~17:00–17:10	Yeni servis konfigüre edildi (~10 dakika).
~17:10–18:40	Tüm mağazaların ürün verisi yeni OpenSearch servise yeniden index’lendi ve trafik bu yeni servise yönlendirildi.
~18:40-19:10	Kesinti sona erdi. Tüm mağazalar normal çalışmaya döndü. Tüm sitelerdeki sayfalar yeniden oluşturulmaya başlandı 30 dakika içerisinde ikas üzerindeki tüm sitelerin %90 oranında tamamlandı.
21:05	Eski OpenSearch servisi hâlâ Modifying statüsünde, AWS tarafında beklemede.
22:30	Deployment süreci düzelmeyince AWS Destek ekibi ilgili node’ları yeniden başlattığını ve hâlâ bekleyen Blue/Green deployment’ı tekrar tetiklediğini ve eski servisin tekrar ulaşılabilir olduğunu bildirdi ama artık ihtiyacımız kalmamış idi.

Kesinti Müşterilerimizi Nasıl Etkiledi?

Tüm ikas mağazalarında aşağıdaki işlevler devre dışı kaldı:

• Ürün listeleme ve kategori sayfaları,
• Ürün arama,
• Ürün detay sayfaları.

Bu süre boyunca tüm mağazalar beyaz ekran veya 502/503 HTTP hatası gösterdi. ikas Yönetim Paneli ve Public API gibi farklı servislerde herhangi bir sorun yaşanmadı.

Altyapı Bağlamı

ikas e-ticaret satış kanallarına ürün verisini serve eden birincil sistem AWS OpenSearch Service’tir. Bu servis, Public GraphQL API’ımız aracılığıyla tüm listeleme, arama ve ürün detay sayfalarını beslemektedir. Bu yapıya neden geçtiğimizi bundan 1 sene önce yayınladığımız TypeSense -> OpenSearch yazımızda anlatmıştık.

AWS OpenSearch Service, cluster konfigürasyon değişikliklerini blue/green deployment mekanizmasıyla uygular. Bu mekanizmada süreç şöyle işler:

1. Yeni bir ortam (green) oluşturulur ve node’lar hazırlanır,
2. Index verileri eski sunuculardan yenisunuculara kopyalanır,
3. Trafik yeni altyapıya yönlendirilir; eski kaynaklar silinir.

Fakat bu sürece veya OpenSearch ilgili herhangi bir server’a müdahale etmemiz mümkün değil ve bizim yaşadığımız gibi deployment sürecinde herhangi bir takılma olduğunda bunu support ekibine bildirip beklemekten başka çaremiz yok.

Ne Oldu?

7 Nisan günü AWS OpenSearch altyapımızda anormal bir yük tespit edildi; arama ve ürün yansımalarında gecikmeler başladı. Yük 20 dakika boyunca CPU’ları %100’de tutunca, otomatik izleme scriptlerimiz altyapıyı bir üst seviyeye yükseltme işlemini başlattı.

Yükseltme tamamlanır tamamlanmaz sistem, bekleyen bir OpenSearch Service Software Update’i otomatik olarak uygulamaya çalıştı ve ikinci bir güncelleme süreci tetiklendi. Altyapı üzerindeki anormal yük nedeniyle bu ikinci güncelleme sunucuları ulaşılamaz hale getirdi ve Blue/Green deployment süreci tıkandı.

Güncellemenin kendi kendine tamamlanması beklendi; olmayınca AWS Enterprise Support’a destek talebi açıldı. AWS destek ekibi aktif bir Blue/Green Deployment sürecine müdahale edemeyeceğini ve sürecin kendi kendine tamamlanmasını beklememiz gerektiğini bildirdi. Bunun üzerine tıkanmış süreci beklemek yerine sıfırdan yeni bir arama altyapısı oluşturma kararı verildi.

Yeni altyapı ~45 dakikada oluşturuldu, ~10 dakikada konfigüre edildi. Tüm mağazaların ürün verisi (~78 milyon kayıt) yeni altyapıya yeniden indexlendi ve trafik yönlendirildi. Kesinti 18:40’ta sona erdi; tüm sayfalar yeniden oluşturulmaya başlandı ve 30 dakika içinde ikas üzerindeki sitelerin %90’ı tamamlandı.

Eski altyapı hâlâ Modifying statüsünde beklerken, AWS destek ekibi daha sonra ilgili node’ları yeniden başlatarak tıkanmış deployment’ı tekrar tetikledi ve eski servisin tekrar ulaşılabilir hale geldiğini bildirdi — ancak bu noktada yeni altyapıya geçiş çoktan tamamlanmıştı.

Gün sonunda AWS sağolsun artık güncel bir OpenSearch servisimiz var ama buna ek olarak da kendimizi affettirmemiz gereken binlerce müşterimiz var 🙁

Neden Müdahale Edemedik?

AWS OpenSearch Service, aktif bir blue/green deployment sürecinde rollback veya manuel müdahale imkanı sunmuyor. Süreç başladıktan sonra tamamlanmasını beklemekten başka seçeneğimiz yoktu. Ekip tüm süreç boyunca AWS Support ile temas halinde kaldı; ancak bu süreçte AWS tarafından da somut bir çözüm alamadık.

Peki Kesintiyi Nasıl Çözdük?

Çözüm, mevcut servisi kurtarmak yerine ondan bağımsız, temiz bir ortam oluşturmaktı.

Yeni bir AWS OpenSearch servisi açtık. Domain’in hazır hale gelmesi yaklaşık 45 dakika, konfigürasyonu ise 10 dakika civarında sürdü. Bu kararı kesintinin başlangıcından yaklaşık 1 saat sonra, AWS’den müdahale alamayacağımız netleşince verdik.

Migration süreci şu adımlardan oluştu:

1. Yeni bir AWS OpenSearch servisi oluşturuldu ve bağımsız konfigürasyonla ayarlandı.
2. Tüm mağazaların ürün verileri yeni servise yeniden index’lendi. Yaklaşık 78 milyon kayıt.
3. Storefront API, yeni domain servisine yönlendirildi.

Bu geçişin ardından tüm online mağazalar 18:40’ta normal çalışmaya döndü.

Ne Yapıyoruz?

Bu gece

Bugün yaşadığımız en büyük sorun, primary cluster çöktüğünde devreye girecek, bizim yönettiğimiz bir backup servisimizin(Warm/Hot Standby) olmamasıydı. Bunu bu gece gideriyoruz ve aktif cluster ile eş zamanlı senkronize olacak pasif bir cluster kurarak bu gibi durumlara çok daha hızlı reaksiyon verilebilecek.
Ayrıca her ihtimale karşı bazı servislerimizde uyguladığımız gibi tenant bazlı veriyi N tane yeni cluster’a bölüp her ihtimale karşı bütün müşterilerimizin etkilenmesini engellemek için planlamaları başlayacağız, aslında zaten gündemimizde multi-region geliştirmeleri kapsamında böyle bir plan vardı ama onu aynı regionda tiered cluster yapısı olabilecek şekilde güncelleyeceğiz.

Orta vadeli (2-4 hafta)

• Storefront fallback katmanı revizyonu: Cache mekanizmamız mevcut; ancak 502/503 senaryolarında beyaz ekrana düşme ya da cache’den silinme sorununu çözüyoruz. OpenSearch unavailable olduğunda temel sayfaların önbellekten servis edilmesi için bu mekanizmayı güçlendiriyoruz.
• Index shard optimizasyonu: Gelecekteki blue/green kopyalama sürelerini kısaltmak için shard boyutu ve dağılımını gözden geçiriyoruz.
• OpenSearch GC/JVM Heap Optimizasyonu: Süreç sırasında farkedilen GC ve JVM heap hatalarına sebep veren isteklerin bulunup optimize edilmesi.
• status.ikas.com: Sistemdeki tüm kritik bilgileri servislerin durumunu anlık takip ettiğimiz verileri Public hale getireceğiz ve bildirim mekanizmasını kuracağız.

Uzun vadeli (8-12 hafta)

• Tiered Cluster Yapısı: Tiered cluster yapısı süreçleri tamamlanıp var olan trafiği küçük OpenSearch servislerine yönlendirme altyapısı canlıya alınacak.

Nerede Hata Yaptık?

Kesintinin kısa özeti: AWS tarafındaki bir altyapı sorunuydu. Ancak kesintinin bu kadar uzun sürmesinde bizim hazırlık eksikliklerimiz belirleyici rol oynadı.

Neler eksikti:

• AWS’den bağımsız yönettiğimiz, bağımsız bir backup servisi yoktu,
• AWS’deki sorun doğrudan canlı ortama yansıdı,
• Managed servislerin DevOps yükünü azaltması avantaj sağlıyor, ama sisteme direkt müdahale edemediğimiz için sorunun çözümünü hızlandıramadık.

Alınan ders: Managed servisleri kullanırken, AWS tarafında çözülemeyen durumlarda fallback mekanizmaları (backup servisi, redundancy) hazırlamak şart. İlerde böyle bir mimari seçimi yaparsak, bu riskler için önceden hazırlıklı olacağız.