Kısaca IIS

IIS, dış dünyayla sunucu arasında middleman görevi görmektedir. Gelen requestleri karşılar ve ilgili uygulamaya yönlendirmektedir. HTTP/HTTPS, FTP/FTPS ve SMTP gibi protokoller desteklenir. Ek olarak web.config dosyasında yer alan yapılandırmaları tanımlayabilir, application’ın çalışma davranışlarını belirleyebilirsiniz.

Örneğin: iisnode, Node.js uygulamalarını IIS üzerinden çalıştırma imkânı sağlamaktadır.

Mülakatlarda sorulması muhtemel bir bilgi olarak şunu söyleyebiliriz: IIS, yalnızca Windows tabanlı sunucular üzerinde çalışan bir web sunucusudur. IIS’ten önce Windows ortamında PWS (Personal Web Server) gibi sınırlı çözümler bulunuyordu; ancak IIS ile birlikte Windows tarafında gerçek anlamda enterprise seviyesinde bir web sunucusu ortaya çıkmıştır. Günümüzde IIS, bankacılık ve kamu altyapıları başta olmak üzere birçok alanda yaygın olarak kullanılmaktadır.

Basit Şekilde IIS Nasıl Çalışır ?

IIS(Internet Information Services), Application Pool ve Request Pipeline üzerinden anlatacak olursak, süreç aşağıdaki gibi işlenmektedir:

Tarayıcıyı bir ziyaretci, IIS ise güvenlik kapımız olarak varsayalım. Uygulamamızı da ziyaretcinin erişmek istediği iç kısım olarak belirleyelim.

• Application Pool, uygulamanın çalıştığı ofis odası görevini görür. Farklı ofis odaları vardır.
• Worker Process: Ofis çalışanı gibidir, requestleri işler ve ilgili response’u ziyaretciye dönmektedir.

IIS Mimarisi

Kernel Mode

Client: Sunucu istemcisidir, HTTP.sys driver ile iletişime geçmektedir.

HTTP.sys: HTTP isteklerinin işlenmesinden sorumludur. Ayrıca caching mekanizması bulunur; requestler worker process tarafından işlenene kadar queue’ya alabilir. Kernel mode olarak çalışmaktadır, ilgili hardware ve sistem verilerine tam yetkili bir şekilde erişimi vardır.

User Mode

Windows Process Activation Service (WAS): İlgili Application Pool için çalışan bir worker process sürecini başlatır, applicationHost.config’den yapılandırma bilgilerini ister. User mode’da çalışır; hardware ve referans bellek erişimi yoktur.

World Wide Web Publishing Service(WWW): Windows Server işletim sisteminin bir parçasıdır. User’lar için içeriklere erişim izni verir. Windows Process Activation Service üzerinden Application Pool ve Site yapılandırma bilgilerini alarak HTTP.sys’i yapılandırmak için kullanmaktadır.

Application Pool: IIS’te uygulamaların çalıştığı, içinde bir veya daha fazla worker process barındırabilen uygulama havuzudur. Her bir uygulama yani worker process’ın kendine ait sınırları vardır. IIS 6'da Worker Process Isolation Mode vardı, IIS 7+ ile Integrated geldi.

“IIS 6.0'da, worker process isolation mode ve IIS 5.0 izolasyon mode sunucu düzeyinde ayarlanır. Bu durum, aynı sunucuda her iki izolasyon mode’nun da çalıştırılmasını imkansız hale getirir.”

Ancak IIS 7 ve üzeri sürümlerde, isteklerin (request) nasıl işleneceğini belirleyen iki farklı mode bulunmaktadır:

1. Integrated Mode: IIS ve ASP.NET, Request Pipeline üzerinden birlikte çalışır. IIS 7 ile birlikte ASP.NET, IIS’e tamamen entegre edilmiştir. Bu mode’da ASP.NET HttpModule’leri, ISAPI filter’ların sahip olduğu yeteneklere; ASP.NET HttpHandler’ları ise ISAPI extension’ların sahip olduğu yeteneklere eşdeğer bir güce sahiptir.
2. Classic Mode: Integrated Mode’un çalışmadığı veya uyumluluk gerektiren durumlarda kullanılmalıdır. Bu mode, klasik ISAPI (aspnet_isapi.dll) mimarisini kullanmaktadır.

Worker Process(w3wp.exe): Worker Process, IIS’in kalbi olarak düşünülebilir ve .NET uygulamaları burada çalıştırılır. Client tarafından gönderilen isteklerin (request) işlenmesi ve karşılık olarak üretilen yanıtların (response) oluşturulmasından sorumludur. Tüm ASP.NET uygulamaları, ilgili Application Pool altında çalışan Worker Process tarafından yönetilir ve çalıştırılır.

En iyi pratik olarak her site/uygulama için ayrı Application Pool önerilir. Bir pool içinde birden fazla worker process (Web Garden) tanımlanabilir, ancak çoğu senaryoda tek process yeterlidir ve multiple process’ler state yönetimi sorunları yaratabilir.

Türkiyede IIS Kimler Kullanıyor

• Cumhurbaşkanlığı
• Turkcell
• Migros
• Garanti Bankası
• Sabancı Üniversitesi
• Orta Doğu Teknik Üniversitesi
• Anadolu Ajansı
• Fabrikalar

Diğer Bilinmesi Gerekenler

Web Farm

Web Farm, birden fazla server üzerinde birden fazla uygulamanın
çalıştırılması ve çok sayıda gelen isteklerin(request) bu sunucular arasında dağıtım prensibiyle çalışır.

Web Garden

Tek bir Application Pool altında birden fazla worker process (w3wp.exe) tanımlanmasıdır. Bu, tek sunucuda işlem yükünü dağıtmak için kullanılır.

Kestrel ve IIS Reverse Proxy

.NET Core için Kestrel sunucusu ve IIS ile reverse proxy olarak kullanılması önerilmiştir.

Peki neden Kestrel ve IIS Reverse Proxy Önerildi?

Bu soruya verilecek cevap şudur: Microsoft’un resmi dokümanlarında da belirtildiği üzere, Kestrel internet-facing senaryolarda bazı güvenlik, stabilite ve yönetim özellikleri açısından tek başına yeterli değildir. Bu eksiklikleri tamamlamak amacıyla Kestrel’in, IIS Reverse Proxy ile birlikte kullanılması önerilmektedir.

IIS Kurulumu

1. Server Manager açınız ardından Add roles and features tıklayınız.
2. Server roles’a kadar next diyiniz.
3. Roles listesinden Web Server(IIS)’i işaretleyiniz ve next buttonuna basınız.
4. İlgili .net feature sürümlerini seçiniz.
5. IIS ile ilgili servisleri seçiniz.
6. Next buttonuna tekrar tıklayınız ve son olarak install basınız ardından kurulumun tamamlanmasını bekleyiniz.
7. Kurulumun başarılı şekilde kurulduğunu anlamanız için Server Manager > Dashboard tıklarsanız, IIS ile ilgili köşeyi görebilirsiniz.

Visual Studio ile Deployment ve IIS için Web Deploy Paketi

Web Deploy (msdeploy), IIS üzerinde çalışan bir web uygulamasını kaynak sunucudan hedef sunucuya teknik olarak kopyalayan ve senkronize eden bir dağıtım aracıdır. Sadece dosyaları değil; IIS site ayarlarını, application pool yapılandırmalarını ve gerekli bağımlılıkları da birlikte taşımaktadır.

ASP.NET / ASP.NET Core projelerinde Visual Studio’nun Publish özelliği arka planda Web Deploy’u kullanır. IIS Reverse Proxy kullanılan senaryolarda ise Web Deploy, IIS üzerindeki site ve binding ayarlarının doğru şekilde oluşturulmasını sağlar ve Kestrel’in arkasında çalışan uygulamanın sorunsuz yayınlanmasına yardımcı olmaktadır.

Not: Firewall Inbound yapılandırılması şarttır.

IIS URL Rewrite Module

IIS URL Rewrite, Microsoft IIS için geliştirilmiştir. Gelen HTTP isteklerinin URL’lerini belirlenen kurallara göre yeniden yazmanıza veya yönlendirmenize olanak tanımaktadır. Ancak önemli bir nokta vardır: Bu işlemler IIS request pipeline’ın başında (PreBeginRequest veya BeginRequest aşamasında) gerçekleşir; yani web uygulaması (handler) devreye girmeden önce URL yeniden yazılır veya yönlendirme yapılır. Bu sayede erken müdahale (HTTPS zorunluluğu, canonical URL vb.) sağlanır.

URL Rewriter Nasıl Çalışmaktadır?

IIS URL Rewrite’ın çalışma mantığı oldukça nettir: Her şey kurallar üzerinden ilerler. Sunucuya gelen her HTTP isteği, önceden tanımlanmış bu kurallar doğrultusunda değerlendirilir ve istenen davranış buna göre uygulanır.

İlk aşamada Regular Expression (RegExp) ile pattern matching yapılır. Yani gelen isteğin URL yapısı, belirlenen desenle karşılaştırılır. Bu desenle eşleşme sağlanmadığı sürece kural devreye girmez. Eşleşme başarılıysa süreç bir sonraki adıma taşınır.

Ardından Conditions devreye girer. Conditions, kuralın çalışmasını daha kontrollü hâle getiren ek şartlardır. İsteğin HTTPS üzerinden gelmesi, belirli bir domain’e ait olması, query string içermesi ya da belirli bir HTTP metodu kullanılması gibi kontroller bu aşamada yapılır. Böylece tek bir URL için bile farklı senaryolar üretmek mümkün olur.

Son adım ise Action kısmıdır. Tüm koşullar sağlandığında URL Rewrite’ın ne yapacağı burada tanımlanır. Gelen isteğin arka planda farklı bir URL’ye yönlendirilmesi (rewrite), kullanıcıya başka bir adrese yönlendirme yapılması (redirect) ya da isteğin tamamen engellenmesi bu aşamada gerçekleşir.

Visual Studio ile Build Almak

IIS ile Canlıya Alım

1. Build aldığınız publish klasörünü kopyalayın ve ilgili VDS (Windows Server) sunucunuzda bulunan bir klasöre yapıştırın. Bu klasör, sizin belirlediğiniz özel bir dizin olabileceği gibi, varsayılan olarak inetpub altında da yer alabilir.

2. IIS Web sitesini oluşturunuz.

• Sitename: IIS’te siteye verilen isimdir.
• Application Pool: Sitenin hangi Application Pool üzerinde çalışacağını belirttiğimiz alandır.
• Physical path: Uygulamanın build/publish dosyalarının bulunduğu klasör dizinidir.
• Binding/Type: Kullanılacak HTTP / HTTPS protokolünün belirlendiği alandır.
• IP Address: Siteye dışarıdan erişimin sağlanacağı veya belirli bir IP üzerinden erişimin tanımlandığı alandır.
• Port: Sitenin çalışacağı port numarasını ifade eder.
• Host name: Sitenin hangi host adı (domain) ile yayınlanacağını belirlediğimiz alandır.
• Start Website immediately: Siteyi hemen başlatır ve sürekli çalışır durumda olmasını ifade eder.

3. Tarayıcı üzerinden ilgili web sitesine erişiniz.

4. Erişim hatası ile karşılaşılacaktır. Bu hatayı gidermek için ilgili dizin üzerinde IIS kullanıcısına yetki verilmesi gerekmektedir.

IIS User erişimi nasıl verilir?
Klasör özellikleri açılır, Security (Güvenlik) sekmesine girilir ve IIS_IUSRS grubu eklenerek gerekli izinler (genellikle Read / Write veya Modify) tanımlanır.

5. Manage Website menüsünden ilgili web sitesini yeniden başlattıktan sonra site canlıya alınacaktır.

Son Söz

Sevgili dostlar, Bu yazıda IIS 7+’ın temel yapısını; mimarisiyle birlikte Application Pool, Worker Process işleyişini ve canlıya alım adımlarını en sade hâliyle ele aldık. Kestrel + reverse proxy kullanımının neden önerildiği, URL Rewrite’ın neden erken devreye girdiği gibi pratik ama kritik detaylara da değindik. IIS, bugün bankalardan kamu kurumlarına kadar pek çok yerde aktif olarak kullanılmakta ve doğru yapılandırıldığında oldukça sağlam bir çözüm sunmaktadır.

Umarım faydalı olmuştur. Bir sonraki yazıda görüşmek üzere, herkese iyi çalışmalar 🙂

Merhaba; Bu makalede ASP.NET Page Lifecycle ele alacağız. Web uygulamalarında sayfanın oluşturulmasından tarayıcıya gönderilmesine kadar geçen süreci detaylı bir şekilde yönetmektedir. Döngü, geliştiricilere sayfa ve kontrol seviyesinde olayları yakalama, veri işleme, dinamik içerik oluşturma ve kaynakları doğru şekilde yönetme imkânı sağlamaktadır. Her bir aşama, sayfanın ve kontrollerin belirli durumlarda hangi işlemleri gerçekleştireceğini belirler ve doğru zamanda müdahale edebilme olanağı sunar gelgelelim sevgili dostlar sırasıyla anlatacak olursak:

1. PreInit

• Sayfa başlatma (start) durumunu tamamladıktan sonra ve initialization (başlatma) durumuna geçmeden önce tetiklenir.
• IsPostBack özelliği belirlenir.
• Dinamik kontroller oluşturulabilir.
• Profil değerleri okunabilir veya ayarlanabilir.

2. Init

• Kontroller başlatıldığında devreye girer.
• Kontrol veya sayfa özelliklerini okumak veya ayarlamak için kullanılır.
• Kontrolün Init olayı, sayfanın Init olayından önce gerçekleşir.

3. InitComplete

• Tüm başlatma işlemleri tamamlandığında tetiklenir.
• ViewState henüz yüklenmemiştir; ViewState üzerinde değişiklik yapmak için kullanılabilir.
• Tüm başlatma işlemlerinin tamamlanmasını gerektiren işlemler burada yapılabilir.

4. PreLoad

• Sayfa, ViewState’i yüklediğinde tetiklenir.
• Postback verileri yüklenir.

5. Load

• Sayfa nesnesi OnLoad metodunu çağırır.
• Daha sonra her kontrol için OnLoad metodu rekürsif olarak çağrılır.

6. ControlEvents

• Belirli kontrollerin olaylarını yönetmek için kullanılır.
  Örneğin, bir Button kontrolünün Click olayı veya bir TextBox kontrolünün TextChanged olayı.

7. LoadComplete

• Olay işleme aşamasının sonunda tetiklenir.
• Sayfadaki tüm kontrollerin yüklenmiş olmasını gerektiren işlemler için uygundur.

8. PreRender

• Sayfa nesnesi PreRender olayını tetikler, ardından her çocuk kontrol için aynı işlem rekürsif olarak yapılır.
• Render aşamasına geçmeden önce sayfa veya kontroller üzerinde son değişiklikler yapmak için kullanılabilir.

9. PreRenderComplete

• Her veri bağlı kontrolün (DataBound Control) DataSourceID özelliği ayarlandığında ve DataBind metodu çağrıldığında tetiklenir.

10. SaveStateComplete

• Sayfa ve tüm kontroller için ViewState ve ControlState kaydedildikten sonra tetiklenir.

11. Render

• Render bir olay değildir, bir süreçtir.
• Sayfa nesnesi, her kontrol için Render metodunu çağırır ve HTML çıktısı oluşturulur.

12. Unload

• İlk olarak her kontrol için, ardından sayfa için tetiklenir.
• Tüm kaynaklar ve referanslar (ör. veritabanı bağlantıları) serbest bırakılır ve final temizliği yapılır.

Son Söz

Dostlar, bu yazıda ASP.NET sayfa yaşam döngüsünü adım adım inceledik. Her aşamanın sayfa ve kontroller üzerindeki etkilerini ve veri ile olay işleme süreçlerini ele aldık. Amaç, yalnızca belirli bir teknoloji tanıtmak değil, geliştiricilerin doğru ve sürdürülebilir çözümler üretebilmesi için yaşam döngüsünü anlamasını sağlamaktı. Umarım faydalı olmuştur; bir sonraki yazıda görüşmek üzere, iyi çalışmalar 🙂

Merhaba; asenkron iletişime dayalı dağıtık sistemlerde, servisler arası veya servis ile mesajlaşma aracısı (message broker) arasındaki etkileşimlerde iletişim hataları kaçınılmazdır. Mesajların hedef sisteme ulaşamadan bağlantının kopması, çalışma zamanı hataları ya da beklenmeyen donanımsal ve yazılımsal kesintiler, servisler arasında veri kaybına ve tutarsızlıklara yol açabilmektedir. Bu bağlamda Outbox Pattern, mesaj iletim sürecini daha güvenilir hâle getirerek bu tür tutarsızlık risklerini azaltmayı amaçlayan temel tasarım desenlerinden biridir.

Outbox Pattern’ın arkasındaki temel motivasyon, bir servisin kendi iş mantığını başarıyla tamamlamasına rağmen ürettiği mesajı başka bir servise veya message broker’a anında iletememesi durumunda ortaya çıkan tutarlılık problemidir. Dağıtık mimarilerde hedef servislerin geçici sürelerle erişilemez olması olağan kabul edildiğinden, her başarısız iletişim denemesinde işlemlerin geri alınması (ör. compensable transaction) her zaman uygulanabilir veya tercih edilen bir çözüm değildir.

Bu yaklaşım yerine Outbox Pattern, iletilmesi gereken message/event’lerin servis içerisindeki işlemlerle aynı transaction kapsamında kalıcı bir outbox yapısına kaydedilmesini önerir. Ardından, bu kayıtları periyodik olarak kontrol eden bağımsız bir yayınlayıcı bileşen (Outbox Publisher), ilgili mesajları hedef servise ya da message broker’a göndermeye çalışır. Böylece alıcı taraf geçici olarak erişilemez olsa dahi mesajlar kaybolmaz ve bağlantı yeniden sağlandığında iletim süreci devam eder.

Sonuç olarak Outbox Pattern, mesajların en az bir kez hedefe ulaşmasını garanti altına alarak veri kaybı riskini azaltır ve servisler arası iletişimi alıcı bileşenin anlık durumundan bağımsız hâle getirir. Bu sayede sistem, hem daha dayanıklı bir yapıya kavuşur hem de gevşek bağlı (loosely coupled) bir mimari tasarımın gerekliliklerini daha etkin biçimde karşılar.

Mikroservis mimarilerinde, kritik mesajlar üreten her bir servis kendisine ait bir Outbox tablosuna sahip olmalı; iletilmesi gereken mesajları öncelikle bu tabloya kaydettikten sonra bir yayınlayıcı (publisher) bileşen aracılığıyla hedef servise ya da mesajlaşma aracısına (message broker) iletmelidir.

Outbox Pattern Ne Zaman Kullanılır?

Outbox Pattern, özellikle e-ticaret gibi mikroservis tabanlı sistemlerde, bir servisin kendi veritabanına (örneğin Order tablosuna) veri yazdığı ve aynı işlem kapsamında OrderCreated gibi olayların yayınlanmasının gerektiği senaryolarda tercih edilmektedir. Bu tür durumlarda ortaya çıkan temel problem, aynı anda hem veritabanına hem de mesajlaşma sistemine veri yazılmasını gerektiren Dual Write yaklaşımıdır. Dual Write kaynaklı tutarsızlıklar kısa vadede fark edilmese de, sistem büyüdükçe ve yük arttıkça kendisini daha belirgin şekilde göstermektedir. Bu nedenle Outbox Pattern, özellikle Dual Write gereksiniminin bulunduğu senaryolarda değerlendirilmesi gereken kritik bir yaklaşımdır.

Outbox Pattern ve Event Sourcing Arasındaki Kavramsal Ayrım

Outbox Pattern ile Event Sourcing sıklıkla karıştırılsa da, bu iki yaklaşım aynı değildir. Event Sourcing’de bir veriye ait tüm olaylar kalıcı olarak saklanırken, Outbox Pattern’da mesajlar yalnızca güvenli iletim sağlanana kadar tutulur ve işlem tamamlandıktan sonra silinir veya güncellenir. Dolayısıyla Event Sourcing sistemin geçmişini modellemeyi amaçlarken, Outbox Pattern mesajlaşma sürecinin güvenilirliğine odaklanır.

Outbox Pattern için Publish Yöntemleri

Outbox Pattern’da mesajların yayınlanması için temel olarak iki farklı yöntem bulunmaktadır. Bu yöntemlerden ilki Pulling (Polling) yöntemidir.

Pulling yöntemi, Outbox tablosunda yer alan kayıtların belirli aralıklarla okunarak hedef servise ya da message broker’a publish edilmesi esasına dayanır. Okuma periyodunun sıklaştırılması, mesajların daha hızlı iletilmesini sağlasa da, veritabanı üzerindeki yükü artırarak ek maliyetlere yol açabilir. Bu durum, Pulling yönteminin temel dezavantajı olarak değerlendirilmektedir.

Özellikle sistemin ölçeklendiği senaryolarda, birden fazla publisher bileşenin aynı kayıtları eş zamanlı olarak okuması (multiple read) riski ortaya çıkabilir. Bu tür tutarsızlıkların önüne geçebilmek için veritabanı seviyesinde çeşitli senkronizasyon ve kontrol mekanizmalarının uygulanması gerekmektedir. Örneğin, MSSQL ortamlarında UPDLOCK, ROWLOCK veya READPAST gibi kilitleme yaklaşımları kullanılarak eş zamanlı okuma işlemleri sınırlandırılabilirken, PostgreSQL tarafında SELECT … FOR UPDATE SKIP LOCKED yapısı tercih edilebilir. MongoDB tarafında ise findAndModify operasyonu ile atomik okuma ve güncelleme işlemleri gerçekleştirilebilir. Buna ek olarak, durum bazlı işaretleme, lease/timeout mekanizmaları ve idempotent consumer tasarımı, Pulling yönteminde sıklıkla başvurulan tamamlayıcı önlemler arasında yer almaktadır.

İkinci yöntem ise Transaction Log Tailing (CDC — Change Data Capture) yaklaşımıdır. Bu yöntemde, Outbox tablosunun bulunduğu veritabanına ait transaction logları takip edilerek gerçekleşen veri değişiklikleri yakalanır ve ilgili message/event’ler hedef servise ya da message broker’a publish edilir. Bu yaklaşımda uygulama seviyesinde aktif bir polling mekanizmasına ihtiyaç duyulmaz; değişiklikler veritabanı logları üzerinden asenkron olarak izlenir.

Transaction Log Tailing yaklaşımına örnek olarak Debezium ve Eventuate Tram gibi araçlar gösterilebilir. Bu yöntem, veritabanı üzerindeki okuma yükünü azaltması ve daha düşük gecikme süreleri sunması nedeniyle yüksek hacimli sistemlerde sıklıkla tercih edilmektedir.

Outbox Pattern Gerektiren Örnek Senaryolar

Outbox Pattern, bir işlemin başarıyla tamamlanmasının ardından birden fazla dış sistemle asenkron iletişim kurulmasının gerektiği senaryolarda etkin biçimde kullanılmaktadır. Aşağıda, bu duruma örnek teşkil eden bazı senaryolar yer almaktadır:

• Uçak bileti satın alma işlemi sonrasında, kullanıcıya bilgilendirme amaçlı e-posta gönderilmesi
• Uçak bileti kaydının oluşturulmasının ardından, ilgili olayın mesajlaşma aracısı (broker) üzerinden diğer servislerle paylaşılması
• Bilet satın alma işlemi tamamlandıktan sonra, uçuşa ait kabin bilgilerinin başka bir servis aracılığıyla güncellenmesi

Idempotent Sorunu

Outbox Pattern’da, mesaj başarıyla publish edildikten sonra ilgili kaydın Outbox tablosunda işaretlenmesi veya silinmesi aşamasında oluşabilecek olası bir veritabanı hatası, aynı mesajın yeniden publish edilmesine yol açabilir. Bu durumun sistem genelinde tutarsızlığa sebep olmaması için, mesajları tüketen consumer bileşenlerin idempotent olarak tasarlanması kritik öneme sahiptir. Bu bağlamda Inbox Pattern, tekrar eden mesajların güvenli şekilde işlenmesini sağlayarak idempotency probleminin çözümünde Outbox Pattern ile tamamlayıcı (akraba) bir yaklaşım olarak değerlendirilmektedir.

Inbox Pattern

Inbox Pattern, dağıtık sistemlerde mesajların en az bir kez (at-least-once) iletilmesi durumunda ortaya çıkabilecek tekrar işleme (duplicate processing) problemini önlemek amacıyla kullanılan bir tasarım desenidir. Bu yaklaşımda, message broker’dan alınan her mesaj, işlenmeden önce alıcı servisin kendi veritabanındaki Inbox tablosuna kalıcı olarak kaydedilir.

Mesaj işleme süreci, Inbox kaydı ile aynı transaction kapsamında gerçekleştirilir. İlgili mesaj daha önce Inbox tablosuna eklenmişse, mesaj tekrar işlenmez ve bu sayede idempotent bir tüketim modeli sağlanmış olur. Servis çökmesi, yeniden deneme (retry) veya ağ kesintileri gibi durumlarda mesajın tekrar iletilmesi söz konusu olsa dahi, sistem bütünsel tutarlılığını korur.

Inbox Pattern, Outbox Pattern ile birlikte kullanıldığında; mesajların güvenilir şekilde üretilmesini (reliable send) ve güvenilir şekilde tüketilmesini (reliable receive) sağlayarak, dağıtık sistemlerde pratikte en yaygın tercih edilen teslimat modeli olan at-least-once + idempotency yaklaşımını mümkün kılar.

Bununla birlikte, iletilen mesajların boyutunun zamanla artması performans ve ağ maliyetleri açısından bir risk oluşturabilir. Bu tür senaryolarda Claim Check Pattern, büyük veri payload’larının mesajdan ayrıştırılarak yalnızca bir referans bilgisinin iletilmesini sağlayarak Inbox ve Outbox desenleriyle birlikte etkin biçimde kullanılabilir.

Claim Check Pattern

Mesaj boyutunun büyük olduğu durumlarda entegre edilebilir. Bu pattern, büyük boyutlu event payload’larının message broker’lar üzerinden taşınması yerine, ilgili payload verisinin external bir storage üzerinde saklanmasını ve buna referans eden bir token veya key’in (claim-check) oluşturulmasını önermektedir.

Yüzeysel olarak ilişkili yaklaşımlara değindiğimize göre, Outbox Pattern’in uygulanması sırasında dikkat edilmesi gereken bazı pratik noktaları ele almakta fayda vardır. Bu noktalar, desenin gereksiz karmaşıklıklardan arındırılarak sürdürülebilir ve etkin biçimde uygulanmasını amaçlayan temel tüyolar niteliğindedir.

Outbox Pattern için Temel Tüyolar

Keep It Simple

Outbox Pattern’in temel sorumluluğu mesajları saklamak ve iletmektir. Outbox Publisher bileşeninin iş akışı yönetimi, state machine veya ek iş mantıklarıyla zenginleştirilmesi; zamanla hata üretmeye ve operasyonel karmaşıklığa neden olabilir. Basit bir veri modeli ve sade bir publish süreci, desenin sürdürülebilirliğini artırır.

Veritabanı Kilitlenmelerine Dikkat

Sistemi ölçeklerken birden fazla publisher örneğinin aynı Outbox tablosunu eş zamanlı okuması, veritabanı üzerinde ciddi kilitlenmelere ve performans düşüşlerine yol açabilir. Her API pod’una bir publisher bağlamak yerine, kontrollü ve sınırlı sayıda worker ile ilerlemek çoğu senaryoda daha sağlıklı sonuç verebilir.

Veritabanı Bir Queue Gibi Kullanılmamalıdır

Outbox tablosu, kalıcı bir kuyruk (queue) değildir; yalnızca kısa süreli bir buffer görevi görmelidir. Mesajlar mümkün olan en kısa sürede asıl mesajlaşma altyapısına (Kafka, RabbitMQ vb.) aktarılmalı ve yüksek hacimli trafik bu sistemler tarafından karşılanmalıdır. Aksi takdirde, veritabanı ölçeklenebilirlik açısından darboğaz hâline gelebilir.

Outbox Tablosunun Bakımı

Outbox tablosundaki eski kayıtların tek tek DELETE işlemleriyle temizlenmesi, yüksek kilitlenme maliyetlerine ve transaction log şişmesine neden olabilir. Bunun yerine batch silme, zaman bazlı partitioning veya partition truncate/drop yaklaşımları tercih edilmelidir. Bu yöntemler, hem bakım süreçlerini hızlandırır hem de veritabanı performansını korumaya katkıda bulunur.

Monitoring

Publish gecikmeleri gibi hususlar için Monitoring mutlaka yapılmalıdır ve hata durumları kontrol edilmelidir.

Anti Pattern

Retry ve işleme sorumlulukları alıcı servislerin kendi sınırları içinde kalmalıdır.

Son Söz

Sevgili Dostlar. Bu yazıda, mikroservis mimarilerinde asenkron iletişimin neden doğal olarak hataya açık olduğunu ve bu problemi pratikte nasıl ele alabileceğimizi Outbox Pattern odağında inceledik. Outbox ve Inbox Pattern’lerinin birlikte kullanımıyla güvenilir mesaj üretimi ve tüketiminin nasıl sağlanabildiğini; Claim Check, CDC ve benzeri tamamlayıcı yaklaşımlarla hangi noktalarda desteklenebileceğini ele aldık.

Amaç belirli bir teknoloji ya da araç tanıtmak değil, dağıtık sistemlerde sıkça karşılaşılan tutarlılık problemlerine karşı uygulanabilir ve sürdürülebilir bir bakış açısı sunmaktı. Anlatılan desenler, kullanılan tech stack’ten bağımsız olarak farklı mimarilere uyarlanabilir niteliktedir.

İlerleyen yazılarda; daha ileri seviye event-driven mimari pratiklerine değinmeyi planlıyorum. Umarım faydalı bir içerik olmuştur. Bir sonraki yazıda görüşmek üzere, herkese iyi çalışmalar 🙂

Bu noktada en kritik başlıklardan biri, dağıtık sistemler (Distributed Systems) içerisinde transaction yönetimi ve veri tutarlılığı(Data Consistency) oluyor. Tek bir veritabanı ve tek bir transaction sınırı olmadığında, “her şey yolunda mı?” sorusu çok daha zor cevaplanıyor. İşte tam da burada, bizi kurtaran önemli tasarım yaklaşımlarından biri devreye giriyor: Saga Pattern.

Saga Pattern, kısaca bir servisin client tarafından tetiklenip başarılı olduğu durumunda, diğer ilgili servislerin sırayla tetiklenmesi ve işleme devam etmesidir. Eğer bir servis başarısız olursa, önceki servisler telafi (Compensating Transaction) yani geri alma işlemleri yaparak sistemi tutarlı hale getirir. İki tip saga söz konusudur:

1. Choreography-Based Saga
2. Orchestration-Based Saga

Choreography-Based Saga

Choreography-Based Saga’da her mikroservis ilgili işlerini tamamladıktan sonra event publish(yayınlamak) eder. Diğer servislerde bu eventi consume(dinlemek) ederek kendi adımını başlatır. Her servis yalnızca kendi sorumluluğunu bilir.

Choreography-Based Saga’nın Avantajları

1. Loosely Coupled(Servisler bağımsızdır ve daha modüler bir yapıdadır).
2. Decentralized Coordination(Saga’ları yöneten bir orkestrator yoktur).
3. Independent Scaling (Yüklenmeye bağlı olarak bağımsız ölçeklendirme yapılabilir).
4. Event-Driven Architecture (Olay bazlı mimaridir).
5. Resilience and Fault Tolerance (Her servis kendi transactionını yönetir, arıza kapsamını azaltır ve geri alma yani Compensating Transaction işlemi yapılarak sistemin dayanıklılığı sağlanmaktadır).
6. Flexibility and Agility (Orkestrator olmadığından değiştirebilirlik rahattır, servisler orkestrator ihtiyaç duymadan yeni olayları yayınlayıp dinleyebildikçe iş akışı dinamik olarak gelişebilir).

Choreography-based Saga Ne Zaman Seçilmeli/Kullanılmalıdır ?

1. Microservice Mimarisi: Sisteminiz microservices olarak tasarlanmışsa, Choreography-Based Saga doğal bir uyum sağlar. Bu yaklaşım, loose coupling ve service autonomy destekleyerek her servisin bağımsız çalışmasına olanak tanır.
2. High Scalability Requirements: Her servisin bağımsız olarak ölçeklenmesi gerektiğinde, choreography yaklaşımı, merkezi bir orkestrator olmadan hizmetlerin yük değişimlerine cevap vermesini sağlar.
3. Resilience: Sistem hatalarının kaçınılmaz olduğu durumlarda, Choreography-Based Saga, sistemi kırmadan Eventual Consistency(Gecici Tutarsizlik yani her iki bankada yer alan hesaptaki para miktarı farklı olabilir lakin kısa bir zaman içerisinde düzelir) sağlamaya ve hataları yönetmeye yardımcı olur.
4. Dynamic Business: İş süreçleriniz sık sık değişiyorsa, bu yaklaşım merkezi bir orkestratorı büyük ölçüde yeniden yazmaya gerek kalmadan esneklik sunar gelgelelim ki esnekliğin yanında iş akışının takibi zorlaşmaktadır.

Compensating ve Eventual’dan sık sık bahsettik, farkları şunlardır:

Compensating Transaction

• Saga’da her adim icin bir compensating transaction (telafi edici islem) tanimlanir.
• Chain’de bir adim başarısız olursa, önceki adımlardaki işlemler geri alınır.

Eventual Consistency

• Eventual Consistency, verinin anlik tutarliligini garanti etmez.
• BASE uyumludur. BASE, sistemin her zaman kullanılabilir olmasını sağlar. Kısa Süreli tutarsızlıkları kabul eder lakin sonunda verilerin tutarlı olmasını hedefler.

Orchestration-Based Saga

Orchestration-Based Saga’da ise tüm işlem adımlarının merkezi bir Saga Orchestrator/Coordinator tarafından yönetildiği yaklaşımdır. Bu orkestratör, gerekli servisleri çağırır ve bir hata durumunda compensating transaction’ları tetikleyerek sistemi tutarlı hâle getirir.

Choreography-Based Saga’yı Diğer Saga Patternleriyle Karşılaştıralım

Orchestration-Based Saga

• Merkezi Orkestrator vardır, iş akışından sorumludur.
• Logging ve Debugging kolaydır.
• Yönetilebilirlik yüksektir.
• Loose Coupling azalır ve Dependency artar.
• Koordinatör fazla sorumluluk alır ve God Object riski doğurur.

Traditional Distributed Transactions

• Strong Consistency (Güçlü Tutarlılık): Servisler arasında güçlü tutarlılık sağlar, ancak dağıtık sistemlerde karmaşık ve performans açısından maliyetli olabilir.
• Two-Phase Commit (2PC): Sıkça kullanılır, fakat performans darboğazı yaratabilir ve tek bir hata noktası (single point of failure) oluşturur.
• Use Case: ACID özelliklerinin kesinlikle gerekli olduğu sistemlerde ve dağıtık kilitlemenin (distributed locking) performans etkilerinin kabul edilebilir olduğu durumlarda uygundur.

Karşılaştırma Tablosu

Choreography-Based Saga Tasarlayalım

Teknolojiler: .NET Core, MassTransit 8 (9+ Enterprise olarak ücretlidir), Mediator ve RabbitMQ.

Mikroservis Sorumlulukları

Account Microservice: Kullanıcı üyeliklerinin oluşturulması, silinmesi ve dondurulmasından sorumludur. Kullandığı event’ler sırasıyla:

• account-created (Producer): Yeni bir kullanıcı üyeliğinin başarıyla oluşturulduğunu bildirir.
• welcome-mail-send-failed (Consumer – Compensating Transaction): Hoş geldin e-postasının gönderilememesi durumunda ilgili üyelik için geri alım (Compensating Transaction) işlemlerini gerçekleştirir.

Mail Microservice: Hoş geldin e-postalarının gönderilmesinden ve e-posta gönderim hatalarının yönetiminden sorumludur. Kullandığı event’ler sırasıyla:

1. account-created (Consumer): Yeni bir kullanıcı üyeliğinin oluşturulduğunu dinleyerek hoş geldin e-postası gönderim sürecini başlatır.
2. welcome-mail-send-failed (Producer): Hoş geldin e-postasının gönderilemediği durumları sistem geneline bildirir.

Rollback ve Retry Mantığı

Rollback, Saga kapsamında başarısız olan bir adım sonrasında, daha önce başarıyla tamamlanan işlemleri telafi etmek (compensating transaction) için kullanılan mekanizmadır. Retry ise bir adımın geçici bir hata nedeniyle başarısız olması durumunda, işlemin belirlenen sayıda yeniden denenmesini ifade eder.

Son Söz

Bu yazıda, microservice mimarilerinde dağıtık transaction yönetiminin neden zor bir problem olduğunu ve bu problemi çözmek için kullanılan Saga Pattern’i detaylarıyla ele aldık. Özellikle Choreography-Based ve Orchestration-Based Saga yaklaşımlarını; avantajları, dezavantajları ve hangi senaryolarda tercih edilmeleri gerektiğiyle birlikte inceledik. Ayrıca Compensating Transaction, Eventual Consistency, Rollback ve Retry kavramlarının Saga içerisindeki rollerine değindik.

Anlatımı somutlaştırmak adına Account ve Mail mikroservisleri üzerinden event-driven bir örnek senaryo kurguladık. Buradaki amaç belirli bir ürün ya da teknoloji tanıtımı yapmak değil, Saga Pattern’in temel mantığını ve dağıtık sistemlerde nasıl konumlandığını anlaşılır bir şekilde aktarmaktı. Kendi projelerinizde kullandığınız tech stack’e ve ihtiyaçlarınıza göre bu yapıyı rahatlıkla uyarlayabilirsiniz.

Bu konunun bir ileri aşamasında; observability, idempotency, retry–backoff stratejileri, dead-letter queue kullanımı ve daha kompleks Saga senaryoları gibi başlıklara da değinilebilir. İlerleyen yazılarda bu konuları daha derinlemesine ele almayı planlıyorum.

Umarım sizler için faydalı ve yol gösterici bir içerik olmuştur. Bir sonraki yazıda yeni konularla tekrar buluşmak üzere…
Herkese iyi çalışmalar 🙂

Amazon EC2 (Elastic Compute Cloud), AWS’nin bulut tabanlı sanal sunucu hizmetidir. Fiziksel sunucu satın almak ve kurmak yerine, dakikalar içinde bulutta çalışan sanal sunucular oluşturabilirsiniz.

İhtiyaçlarınız doğrultusunda ölçeklendirme yapabilir; dilediğiniz gibi kaynakları azaltabilir ya da instance kaynaklarınızı artırabilirsiniz.

Instance kavramından bahsetmişken, “Instance nedir?” sorusuna kısaca değinelim. Sevgili dostlar, instance; EC2 üzerinde çalışan sanal makinelere verilen isimdir. Tıpkı fiziksel bir bilgisayar gibi, kendi içerisinde bellek (RAM), işlemci (CPU), depolama, işletim sistemi(AMI/OS) ve ağ (network) gibi bileşenlere sahiptir.

Not: Servis ile Instance’ları karıştırmayın. EC2, S3 gibi diğer Amazon Web Services hizmetleriyle birlikte sunulan bir hizmettir. EC2 veya başka bir hizmeti kullandığımızda, bunu bir örnek üzerinden kullanırız; örneğin, EC2'deki t3.micro örneği vb.

Neden EC2 ?

Kendi sunucularınızı satın alıp bağımsız çalışabilirsiniz; ancak bu durumda güvenlik güncellemeleri, bakım, arıza giderme ve altyapı yönetimi gibi birçok ek sorumluluk da size ait olur. Bunlar için ya zaman harcamanız ya da ekstra personel istihdam etmeniz gerekir.

AWS EC2 kullandığınızda ise bu altyapı süreçlerinin tamamı Amazon tarafından yönetilir. Siz yalnızca uygulamanıza odaklanırsınız ve üstelik bunu çok daha düşük maliyetle yaparsınız.

Maliyet Avantajı Kısaca:

1. Fiziksel sunucularda altyapıyı yönetmek için bir IT ekibi gerekirken, EC2’de bu sorumluluk AWS tarafından üstlenilir.
2. Fiziksel sunucularda donanım arızaları ve kesintiler ek maliyet oluşturur; yüksek erişilebilirlik için yedek sistemler gerekirken, EC2 esnek ve kolay ölçeklenebilir yapısıyla öne çıkar.
3. Fiziksel sunucularda satın alınan donanımlar zamanla değer kaybederken, EC2’de zaman geçtikçe daha güçlü donanımlar daha düşük maliyetlerle sunulur.

Neden EC2 kullanmalıyız konusuna değindik. Şimdi ise instance tiplerini inceleyelim.

t3,t4g: Genel amaçlı kullanımlar için tercih edilir. Ne eksik ne fazla; günlük iş yükleri için dengeli performans sunan, “her işe yeterim” diyen instance tipleridir.

c6g,c7i: CPU ağırlıklı işlemler içindir.

r6i, r7g: Database ağırlıklı işlemler için kullanabilirsiniz. RAM Ağırlıklı olanlar için tercih edilir.

p4,g5: GPU ağırlıklıdır.

Burstable Performance Instances (T2 / T3 / T4g)

T2 Instance’ları Burstable Performance’lara sahiptir. CPU’nun belirli seviyede çalıştığı anlamına gelir lakin daha fazla işlem gücü gerektiğinde kısa süreliğine burst moduna geçer ve yüksek verim sağlar.

• CPU Boşta ise Credit kazanırsınız.
• Kullanılmayan Credit’lar hesapta birikir.
• Credit bakiyenize göre scale-up veya down kararı verebilirsiniz.
• Her burst işlemi sırasında Credit’lar harcanır; yani her şeyin maliyeti olduğu gibi burst’un da maliyeti söz konusudur.

Elastic Block Storage Optimized Instances

C4, M4 ve D2 instance’ları varsayılan olarak EBS optimized gelir.
EBS (Elastic Block Storage), AWS tarafından sunulan ve yüksek IOPS değerlerine sahip bir depolama servisidir. Bu sayede EBS volume’leri optimize edilmiş instance’lara bağlandığında tek haneli milisaniye gecikmeler elde edilebilir.

IOPS(Input/Output Operations Per Second): Depolama sistemlerinin saniyede gerçekleştirebildiği okuma/yazma işlem sayısını ifade eden bir performans ölçütüdür.

Cluster Networking Instances

X1, M4, C4, C3, I2, G2 ve D2 instance’ları cluster networking desteği sunar.
Aynı placement group içinde başlatılan instance’lar, yüksek bant genişliği ve düşük gecikme süresi sağlayan mantıksal bir gruba yerleştirilir. Bu sayede grup içindeki tüm instance’lar arasında hızlı ve düşük gecikmeli ağ iletişimi sağlanır.

Placement group, belirli EC2 instance’larının bir araya getirildiği mantıksal bir kümedir. Bu gruba dahil olan instance’lar, tek akışta (single-flow) 10 Gbps, çoklu akışta (multi-flow) ise her yönde 20 Gbps’ye kadar ağ bant genişliğinden faydalanabilir.

Placement group’a dahil olmayan instance’lar ise çoklu akış trafiğinde 5 Gbps ile sınırlandırılır.

Cluster Networking, yüksek performans gerektiren analitik sistemler, HPC (High Performance Computing) ve büyük ölçekli veri işleme senaryoları için idealdir.

Dedicated Instances

Tek bir müşteriye ait single-tenant donanım üzerinde çalışan instance’lardır. Kurumsal politikalar veya sektörel regülasyonlar gereği, iş yüklerinin diğer müşterilerin instance’larından tamamen izole edilmesi gereken senaryolar için idealdir; ancak maliyetleri yüksektir.

Bu modelde instance’lar donanım seviyesinde izole edilir ve müşteriye özel fiziksel makineler üzerinde çalışır. Özellikle yüksek güvenlik, uyumluluk (compliance) ve izolasyon gereksinimi olan kurumlar tarafından tercih edilir.

Dedicated Hosts

Dedicated Host’lar, AWS üzerinde tamamen size ayrılmış fiziksel sunuculardır. Dedicated Instance’lara kıyasla daha fazla kontrol sunar ve daha pahalıdır.

Bu modelde fiziksel sunucu üzerindeki instance yerleşimini siz yönetirsiniz. Özellikle lisanslama (BYOL) gereksinimi olan yazılımlar, donanım seviyesinde detaylı kontrol isteyen ve sıkı kurumsal politikaları bulunan yapılar için tercih edilir.

EC2 Instance Oluşturma

• AWS üyeliğinize giriş yapınız, arama kutucuğuna ec2 yazarak ilgili yere tıklayınız.
• Launch Instance basınız.

• Açılan ilgili sayfada bir takım bilgileri girmeniz/seçmeniz gerekmektedir.,

• Name and tags bölümünde sunucu adınızı belirleyebilirsiniz.
• Application ve OS Image seçmeniz gerekmektedir. Peki, AMI nedir? Gelin bunu yüzeysel olarak öğrenelim. AMI (Amazon Machine Image), bir EC2 instance’ı başlatmak için gerekli olan işletim sistemi, uygulamalar ve temel yapılandırmaları içeren hazır bir şablondur. Kısaca, EC2 instance’ınızın başlangıç noktasıdır. AMI’ler iki şekilde kullanılabilir: önceden yapılandırılmış AMI’ler veya kendi ihtiyaçlarınıza göre yapılandırdığınız AMI’ler.
• Instance type olarak örnek amaçlı t3.micro kullanacağız; ancak ihtiyaçlarınıza göre farklı bir instance tipi de tercih edebilirsiniz.
• Key Pair tanımını yapmanız gerekmektedir; önceden oluşturduğunuz bir key pair’i kullanabilir ya da yeni bir key pair oluşturabilirsiniz. Create new key pair butonuna tıklayarak devam edelim. Açılan pencerede (modal) sizden Key pair name istenir.
• Key pair name, anahtarın adıdır ve oluşturulacak EC2 instance’ına bağlanırken kimlik doğrulama amacıyla kullanılır. Bu anahtar, instance’a güvenli şekilde erişim sağlamanızı mümkün kılar. Create key pair butonuna tıklayıp .pem formatını seçtikten sonra işleminize devam edebilirsiniz.

• Network, VPC gibi yapılandırmaların seçilmesi gerekmektedir. Yüzeysel olarak VPC şu anlama gelir: VPC (Virtual Private Cloud), AWS üzerinde size özel, izole bir sanal ağ ortamıdır. EC2 instance’larınızı bu ağ içinde konumlandırır, IP adresleme, subnet, routing ve güvenlik kurallarını kontrol etmenizi sağlar. Bununla birlikte, zaten bir security group’unuz varsa onu kullanabilirsiniz.

• Storage bölümünde EC2 instance’ınız için kullanılacak depolama alanı yapılandırılır. Bu depolama alanı EBS (Elastic Block Storage) kullanılarak sağlanır. Disk türü (gp2, gp3 vb.), disk boyutu ve gerekirse IOPS değerleri belirlenir. Varsayılan ayarlar çoğu senaryo için yeterlidir; ancak uygulama ihtiyacına göre depolama kapasitesi ve performans ayarları özelleştirilebilir. Advanced yazan butona tıklayarak daha detaylı depolama ayarlarına erişebilirsiniz.

Delete on termination: Bu ayar, EC2 instance silindiğinde (terminate) bağlı olan EBS volume’un otomatik olarak silinip silinmeyeceğini belirler.

• Enabled (Varsayılan): Instance silindiğinde volume da silinir.
• Disabled: Instance silinse bile volume AWS hesabınızda kalır ve manuel olarak silinmesi gerekir.

Size (GiB): EBS volume’un disk boyutunu belirtir.

IOPS (Input/Output Operations Per Second): Volume’un saniyede gerçekleştirebileceği okuma/yazma işlem sayısını ifade eder.

• gp3,gp2: Genel amaçlı volume tipleridir. Saniyede 3.000 ile 16.000 arasında işlem yapabilir. Fiyat olarak ortalama bir fiyat kullanmaktadır. Web server olarak rahatlıkla kullanabilirsiniz.
• io1,io2: Provisioned SSD olarak geçmektedir ancak yüksek performans gerektiren durumlarda kullanılır ve saniyede 64.000 işlem yapabilir. Production database’lerde yaygın kullanılır(MongoDB).
• st1(Throughput Optimized HDD),sc1(Cold HDD): Disklerde performans IOPS yerine MiB/s üzerinden ölçülür. Büyük ve ardışık veri okuma/yazma işlemleri için uygundur. Saniyede 500 MB/s(st1) ile 250 MB/s(sc1) işlem yaparlar. Big Data, data warehouse gibi sistemlerde kullanılır.

Son olarak, Launch Instance butonuna tıklayarak instance oluşturma işlemini tamamlayınız. İşlem başarıyla tamamlandığında, oluşturulan instance’a ait Instance ID ekranda görüntülenecektir. Bu ID’ye tıklayarak ilgili sayfaya geçebilir ve sunucuya ait tüm detaylı bilgilere ulaşabilirsiniz.

EC2 instance’ınızı oluşturduğunuza göre, şimdi EC2 Fiyatlandırma (Pricing) konusuna geçelim ve AWS’in sunduğu farklı ücretlendirme modellerini inceleyelim.

EC2 Fiyatlandırma

Free Tier

Free Tier, ay bazlı 750 saat EC2 kullanım hakkı sunar. Bu ücretsiz kullanım, AWS platformuna kayıt olduğunuz tarihten itibaren 1 yıl boyunca geçerlidir.

EC2 fiyatlandırmasını basitçe 3 başlık altında inceleyebiliriz:

Spot Instances

Spot Instances, AWS’nin kullanılmayan EC2 kapasitesini daha düşük maliyetle kullanmanızı sağlayan bir fiyatlandırma modelidir. Spot instance’ların saatlik fiyatı AWS tarafından belirlenir ve bulunduğu Availability Zone’daki kapasite durumuna göre değişkenlik gösterir. Bu modelde, bir instance için ödemek istemediğiniz maksimum saatlik fiyatı belirlersiniz. Spot fiyat bu belirlediğiniz değerin üzerine çıktığı anda, ilgili instance otomatik olarak durdurulur. Bu nedenle Spot Instance’lar, kesintiye toleransı olan iş yükleri için uygundur.

On-Demand Instances

On-Demand Instances, herhangi bir uzun vadeli taahhüt veya peşin ödeme olmadan, saatlik bazda ödeme yaparak kullanılan instance’lardır. Trafiği öngörülemeyen uygulamalar veya ilk kez yayına alınan test ve development uygulamaları için oldukça uygundur.

Reserved Instances

Reserved Instances, On-Demand Instance’lara kıyasla önemli maliyet avantajları sunar. Bu modelde, belirli bir süre boyunca instance kullanımını rezerve edersiniz ve bunun karşılığında indirimli fiyatlardan yararlanırsınız. Reserved Instance’lar için üç farklı ödeme seçeneği bulunmaktadır:

• No Upfront: Peşin ödenek yoktur, saatlik ücret söz konusudur.
• Partial Upfront: Bir kısmını peşin, bir kısmını saatlik indirimli olarak ödediğiniz modeldir.
• All Upfront: Sözleşmeyle tek ödenek alınır ve ilgili süre boyunca kullanılır. Taahüt sürenize bağlı kaldığınız modeldir, genellikle production ortamları için tercih edilir.

EC2 Reserved Instance’larda üç farklı ödeme seçeneğine ek olarak iki farklı tür (type) bulunmaktadır:

• Standard Reserved Instances: Indirim oranların yüksek olduğu instance’lardır. Instance tipi, işletim sistemi, bölge ve tenancy değiştirilemez. Uzun süre değişim yapmak gibi derdiniz yoksa kullanabilirsiniz.
• Convertible Reserved Instances: Standard Reserved’lara göre indirim oranları biraz daha düşüktür. Instance tipi, işletim sistemi, bölge ve tenancy için değişim imkanı verir. Zaman içerisinde mimarisi değişebilecek sistemler için uygundur.

Ephemeral Storage

• Fiziksel olarak Instance’ın olduğu sunucuya bağlıdır.
• Milyonlarca IOPS yeteneği vardır.
• Boyutu seçtiğiniz Instance göre sabittir.
• Buffering, Caching yada tmp data için kullanılır.
• Kalıcı değildir, kapatıp açıldığında silinir.

Elastic File System (Network File System)

• Dosya sistemi (file-based) depolamadır.
• Aynı anda birden fazla EC2 instance tarafından kullanılabilir. Peki ne anlama geliyor? Bir sunucuda dosya oluşturulduğu anda diğer sunucuya yansıtılır.
• Otomatik ölçeklenir (boyut yönetimi gerekmez).
• NFS protokolü üzerinden erişilir.
• Paylaşımlı dosya yapıları için idealdir.
• Birden fazla Availability Zone(AZ)’da çalışabilir.

Kullanım Alanları: Mikroservisler, Content Management Sistemleri ve Container Storage.

EBS ve EFS Farkı

• Tek instance + yüksek performans gereksinimi için EBS tercih edilir.
• Birden fazla instance + paylaşımlı dosya sistemi ihtiyacı için ise EFS kullanılır.

Bonus: Windows Server ile Remote Desktop Connection

Bir EC2 Windows Server Instance oluşturduktan sonra sunucuya bağlantı kurmanız gerekir. Bu bağlantıyı sağlamak için Remote Desktop Connection (RDP) kullanılır. RDP, Windows işletim sistemlerinde varsayılan olarak yüklü gelir ve ek bir kurulum gerektirmez. Velhasıl kelam, bu uygulama sayesinde Windows Server instance’ınıza kolayca bağlanabilirsiniz.

VPC security group yapılandırmaları doğru şekilde yapılmadığı takdirde troubleshoot gibi sorunlar yaşayabilirsiniz.

• Type: RDP olarak ayarlanmalıdır.
• Source: Anywhere IPv4 seçilebilir; bu ayar, sunucuya her yerden erişime izin verir. Ancak güvenlik açısından önerilen yöntem, erişimi yalnızca kendi IP adresinizle sınırlandırmaktır.

Ek olarak HTTP (80) ve HTTPS (443) için gerekli Security Group kurallarını eklemeyi unutmayınız.
Windows Server instance’larda varsayılan olarak dış erişim kapalı gelebilir; bu nedenle web uygulamanızın dış dünyadan erişilebilir olması için bu portların Inbound Rules altında açık olması gerekmektedir.

Doğru VPC yapılandırması sayesinde Windows Server instance’a başarıyla bağlantı sağlandığını gösteren görüntü:

Son Söz

Bu yazıda AWS EC2’nin ne olduğunu ve instance’ların nasıl oluşturulduğunu adım adım ele aldık. Kişisel projelerimde .NET/Java ve React uygulamalarını deploy ederken Windows Server + IIS veya Ubuntu + Nginx gibi teknolojiler kullandım; siz de ihtiyaçlarınız ve planlarınız doğrultusunda en uygun tech stack’i tercih edebilirsiniz.

Elbette bu anlatılanların bir ileri seviyesi olarak, container teknolojileri kullanılarak yapılan auto — scaling ve deploy süreçleri de bulunmaktadır. Bu konulara ilerleyen makalelerde değineceğiz.

Umarım sizler için faydalı ve yol gösterici bir içerik olmuştur. Bir sonraki yazıda yeni konularla tekrar buluşmak üzere…
Herkese iyi çalışmalar 🙂

Bu makalede Amazon İlişkisel Veritabanı Hizmeti (Amazon RDS) ele alınacaktır.

AWS RDS, ilişkisel bir veritabanının kurulumunu, işletimini ve ölçeklendirilmesini kolaylaştıran bir web hizmetidir. Sektör standardı ilişkisel veritabanları için uygun maliyetli ve yeniden boyutlandırılabilir kapasite sunar ve yaygın veritabanı yönetim görevlerini otomatik olarak yönetir.

Detaylı Olarak AWS İlişkisel Veritabanı Hizmeti Kullanmanın Faydaları

1. Multiple Database Engine desteği sunar (SQL Server, Oracle, MySQL, PostgreSQL vb.).
2. Managed Service olarak; otomatik veritabanı yedekleme, patch ve versiyon güncellemeleri, monitoring ve logging hizmetleri sağlar ve failover desteği sunar.
3. Multi-AZ mimarisi sayesinde kesintilere hızlı yanıt verir ve yüksek erişilebilirlik sağlar.
4. Replikasyon hizmetlerini destekler.
5. VPC ile entegre edilebilir.
6. IAM (Identity and Access Management) ile erişim kontrolleri sağlanabilir.
7. Encryption ile veriler şifrelenebilir.
8. Kullandıkça öde fiyatlandırma modeli sunar; yalnızca kullanılan kaynaklar kadar ödeme yapılır. Uzun vadeli tasarruf için Reserved Instances seçenekleri de mevcuttur.

Peki ne anlama geliyor ?

Kurumsal şirketlerde sıkça karşılaşılan fault detection, yazılım / patch / versiyon güncellemeleri ve yedek alma gibi operasyonel süreçler, AWS RDS gibi managed servisler sayesinde otomatik olarak yönetilir. Böylece bu süreçlerden kaynaklanan sorunlar ortadan kaldırılır, operasyonel yük azalır ve iş sürekliliği sağlanmış olur.

Limitler

• Storage Limiti: RDS veritabanlarının maksimum boyutu ve bölge başına örnek sayısı için belirli sınırlar vardır.
• Root erişimi yoktur: RDS, veritabanının altında çalışan işletim sistemine doğrudan root erişimi sağlamaz.
• Tam özelleştirme sınırlıdır: RDS birçok yönetimsel detayı soyutladığı için, tam sistem kontrolü gerektiren senaryolar için uygun olmayabilir.

AWS RDS için Use Case’ler

1. Web Uygulamaları: Güvenilir bir arka uç veritabanına ihtiyaç duyan dinamik web siteleri.
2. Mobil Uygulamalar: Kullanıcı verilerinin ve uygulama durumunun saklanması.
3. Analitik: Yapılandırılmış veriler üzerinde sorgular ve analizler çalıştırmak.
4. Kurumsal Uygulamalar: Güçlü ve ölçeklenebilir veritabanlarına ihtiyaç duyan iş uygulamala

SQL Server Database Oluşturalım

Sevgili dostlar, yukarıda AWS RDS’in temel faydalarından bahsettik. Şimdi ise SQL Server Database nasıl oluşturulur ve nasıl bağlanılır sorularına adım adım yanıt verelim.

1. Arama kutucuğuna RDS yazarak Aurora and RDS servisine tıklayınız.

2. Create database butonuna tıklayınız.

3. Easy Create seçeneğini seçiniz. Bu seçenekle best-practice ayarları varsayılan olarak gelir. Alternatif olarak Full configuration, detaylı yapılandırma yapmak isteyenler için kullanılabilir.

4. DB instance identifier alanında veritabanına bir isim veriniz. Her veritabanı isminin benzersiz (unique) olması gerekmektedir.

5. Veritabanına bağlanabilmek için bir Master kullanıcı adı belirleyiniz. Güvenlik sebebiyle admin gibi tahmin edilebilir kullanıcı adlarından kaçınılmalıdır.

6. Credential Management alanında iki seçenek bulunmaktadır:

• Secrets Manager: Şifrelerin AWS Secrets Manager ile yönetilmesi.
• Self Managed: Şifrenin manuel olarak belirlenmesi.

Self Managed seçeneğini seçerek Master password alanında şifrenizi belirleyiniz.

7. EC2 ile bağlantı kurulabilir; ancak bu adım opsiyoneldir.

8. Create database butonuna tıklayınız. Veritabanı yaklaşık 1–5 dakika içerisinde oluşturulacaktır.

9. Instance listesinden CPU kullanımı gibi metrikleri görüntüleyebilirsiniz.

SSMS (SQL Server Management Studio) ile Bağlanalım

1. Veritabanına tıklayınız.

Endpoint: SQL Server bağlantı adresidir.

Port: SQL Server’ın çalıştığı port numarasıdır.

2. VPC Security Group tanımına yeni bir kural eklenmelidir. Bunun için default security group’a tıklayınız ve açılan sayfada ilgili Security Group ID’ye giriniz.

3. Edit inbound rules butonuna tıklayınız.

4. Add rule ile yeni bir kural ekleyiniz:

• Protocol: TCP
• Port range: 1433
• Source: My IP olarak işaretleyiniz. Bu işlem, mevcut IP adresinizin otomatik olarak tanımlanmasını sağlar ve external bağlantıya izin verir (public erişim gerektirir).

Save rules ile kaydediniz.

5. Public erişim izni vermek için Modify butonuna basınız.

• Connectivity — Additional configuration bölümünde
  Not publicly accessible değerini Publicly accessible olarak değiştiriniz.
• Continue ile kaydediniz. Yaklaşık 5 dakika içinde erişim aktif olur.

6. SQL Server Management Studio’yu açınız ve AWS üzerinden kopyaladığınız endpoint’i Server Name alanına yapıştırınız.

7. Authentication tipini SQL Server Authentication olarak seçiniz ve Master kullanıcı adı ile şifreyi giriniz.

8. Connect butonuna basınız. Tüm adımlar doğruysa bağlantı başarılı bir şekilde kurulacaktır.

Son Söz

Bu yazıda, AWS RDS (Amazon İlişkisel Veritabanı Hizmeti)’nin ne olduğunu, sağladığı temel faydaları ve SQL Server veritabanının nasıl oluşturulup SSMS üzerinden nasıl bağlanılacağını adım adım ele aldık.

Umarım sizler için faydalı ve yol gösterici bir içerik olmuştur. Bir sonraki yazıda yeni konularla tekrar buluşmak üzere…
Herkese iyi çalışmalar 🙂

Bu makalede, AWS Secrets Manager kullanılarak veritabanı bağlantı bilgileri veya encryption master key gibi hassas değerlerin nasıl güvenli bir şekilde saklandığını ele alacağız.

AWS Secrets Manager; credential’ların yönetilmesini, credential rotation süreçlerini ve gizli bilgilerin güvenli şekilde saklanmasını sağlar. Ayrıca OAuth token’ları veya özel API key’ler (örneğin Turkcell API) gibi hassas verilerin tutulmasına imkân tanır.

Peki ne anlama geliyor ?

Uygulama içinde credential’ları hard-code etmenize gerek kalmadan, bu bilgileri güvenli ve merkezi bir şekilde yönetebileceğiniz anlamına gelmektedir.

AWS Secrets Manager Dashboard’unu Keşfedelim

AWS Secrets Manager Dashboard’unu keşfetmeye başlamadan önce AWS Management Console giriş yapalım ve secrets manager yazarak aratalım;

Ardından açılan sayfada “Store a new secret” butonuna tıklayarak ilgili sayfaya geçelim. Secret type alanında “Other type of secret” seçeneğini seçelim.

Key/Value Pairs alanı, gizli bilginin anahtar/değer (Key/Value) şeklinde mi yoksa Plaintext olarak mı tutulacağına karar verdiğimiz bölümdür. .NET tarafında generic sınıfları kullanacağımız için Plaintext seçeneğini tercih etmemiz daha doğru olacaktır. Elbette ihtiyaç duyulması halinde Key/Value formatı da kullanılabilir; bu tamamen opsiyoneldir.

Plaintext Değeri

{
  "ConnectionStrings": {
    "CatalogueDB": "Server=HP\\SQLEXPRESS;Database=dotnetmicroservice;Trusted_Connection=True;TrustServerCertificate=True;Encrypt=False;",
    "RedisConnection": "localhost:6379"
  }
}

Bu yapılandırma bizim için yeterli olacaktır. Ancak çalışma sürecinde bu hassas veriye daha kolay erişebilmek adına bir sonraki adımda secret name değerini tanımlayacak ve isteğe bağlı olarak kısa bir açıklama ekleyebiliriz.

Ayrıca yüksek erişilebilirlik sağlamak için aşağıdaki gibi Replicate secret kısmında yapılandırmada bulunabilir ve böylece diğer AWS region’larında hassas verilerin read-only kopyalarını oluşturabilirsiniz. Unutmayın! Sizlere sunulan ek özelliğin bir maddi karşılığı vardır. Bu husus dikkate alınarak planlamalar yapılmalıdır. Rotation’ları şimdilik atlayacağız, sonraki makalelerde ayrı ele alıyor olacağız.

Store diyerek işlemi tamamlayalım. Bu adımın ardından AWS Secrets Manager üzerindeki secret değerlerimizi oluşturmuş olacağız.

.NET Tarafında Nasıl Bir Yol İzleyeceğiz ?

1. Shared isimli bir class library oluşturacağız. Eğer hâlihazırda bir Core veya Infrastructure katmanınız varsa onu da kullanabilirsiniz; ancak bu anlatımda Shared üzerinden devam edeceğiz.
2. AWS isimli bir klasör ekleyeceğiz. Bu klasör, AWS ile ilgili tüm altyapı desteğinin sağlandığı alan olacaktır.
3. AWS klasörü içerisinde SecretsManager isimli bir alt klasör oluşturacağız. Bu alt klasör, AWS Secrets Manager altyapısını barındıracaktır. Bu yapı altında, ilgili sorumluluklara göre ayrılmış başka alt klasörlerimiz de yer alacak ve separated yapıyı korumaya özen göstereceğiz.
4. Provider, Extension ve ConfigurationSource yapılarını aktif olarak kullanacağız. Extension aracılığıyla IConfigurationBuilder’ı genişletecek ve AddAwsSecretsManager metodunu kullanarak istediğimiz generic tipte configuration property kayıtlarını gerçekleştireceğiz.

Temel olarak yol haritamızın nasıl ilerleyeceğini artık büyük ölçüde anladığınızı varsayıyorum.

.NET Yol Haritasının Uygulanması

Yol haritamızı uygulamaya başlayalım. S3 oluşturmayınız; çünkü kişisel projemde S3, depolama amacıyla kullanılmaktadır. Bu adımda projedeki altyapıyı birlikte inceleyip uygulayacağız, ancak S3 konusu başka bir makalede detaylı olarak ele alınacaktır.

Configurations/ApplicationSettings.cs

using Shared.AWS.SecretManagers.Model;

namespace Shared.AWS.SecretManagers.Configurations
{
    public class ApplicationSettings
    {
        public ConnectionStrings ConnectionStrings { get; set; }
    }
}

ConfigurationSources/AwsSecretsManagerConfigurationSource.cs

using Microsoft.Extensions.Configuration;
using Shared.AWS.SecretManagers.Providers;

namespace Shared.AWS.SecretManagers.ConfigurationSources
{
        public class AwsSecretsManagerConfigurationSource<T> : IConfigurationSource where T : class
        {
            private readonly string _region;
            private readonly string _secretName;
            private readonly string _sectionName;

            public AwsSecretsManagerConfigurationSource(string region, string secretName, string sectionName = null)
            {
                _region = region;
                _secretName = secretName;
                _sectionName = sectionName;
            }

            public IConfigurationProvider Build(IConfigurationBuilder builder)
            {
                return new AwsSecretsManagerConfigurationProvider<T>(_region, _secretName, _sectionName);
            }
        }
}

Extensions/AwsSecretManagerExtension.cs

using Amazon.S3;
using Microsoft.Extensions.Configuration;
using Shared.AWS.SecretManagers.ConfigurationSources;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Runtime.CompilerServices;
using System.Text;
using System.Threading.Tasks;

namespace Shared.AWS.SecretManagers.Extensions
{
    public static class AwsSecretsManagerExtensions
    {
        public static IConfigurationBuilder AddAwsSecretsManager<T>(
            this IConfigurationBuilder builder,
            string region,
            string secretName,
            string sectionName = null) where T : class
        {
            return builder.Add(new AwsSecretsManagerConfigurationSource<T>(region, secretName, sectionName));
        }
        public static IConfigurationBuilder AddAwsSecretsManager(
            this IConfigurationBuilder builder,
            string region,
            string secretName)
        {
            return builder.Add(new AwsSecretsManagerConfigurationSource<Dictionary<string, string>>(region, secretName));
        }
    }
}

Models/ConnectionStrings.cs

namespace Shared.AWS.SecretManagers.Model
{
    public class ConnectionStrings
    {
        public string CatalogueDB { get; set; }
        public string RedisConnection { get; set; }
    }
}

Providers/AwsSecretsManagerConfigurationProvider.cs

AWS Secrets Manager’daki verileri .NET uygulamasında kullanabilmek için temel bir provider’dır. Generik tipi sayesinde secret’lar tip güvenli bir şekilde deserialize edilir; eğer T tipi Dictionary<string, string> ise JSON doğrudan key-value formatında işlenir, aksi takdirde FlattenObject metodu ile nested yapılar düz key-value çiftlerine dönüştürülür. Load() metodu, GetSecret() aracılığıyla AWS Secrets Manager’a istek gönderir ve verileri çeker; hem string hem de binary format desteklenir. Bu sayede hassas bilgiler hard-code edilmeden, güvenli ve kolay erişilebilir hale gelir.

using Amazon;
using Amazon.SecretsManager;
using Amazon.SecretsManager.Model;
using Microsoft.Extensions.Configuration;
using System.Text;
using System.Text.Json;

namespace Shared.AWS.SecretManagers.Providers
{
    public class AwsSecretsManagerConfigurationProvider<T> : ConfigurationProvider where T : class
    {
        private readonly string _region;
        private readonly string _secretName;
        private readonly string _sectionName;

        public AwsSecretsManagerConfigurationProvider(string region, string secretName, string sectionName = null)
        {
            _region = region;
            _secretName = secretName;
            _sectionName = sectionName;
        }

        public override void Load()
        {
            try
            {
                var secretString = GetSecret();

                if (string.IsNullOrWhiteSpace(secretString))
                {
                    Console.WriteLine("Secret is empty or null");
                    return;
                }

                // Generic tip Dictionary<string, string> ise direkt deserialize et
                if (typeof(T) == typeof(Dictionary<string, string>))
                {
                    var secrets = JsonSerializer.Deserialize<Dictionary<string, string>>(secretString);
                    if (secrets != null)
                    {
                        Data = secrets.ToDictionary(
                            kvp => kvp.Key.Replace("__", ConfigurationPath.KeyDelimiter),
                            kvp => kvp.Value,
                            StringComparer.OrdinalIgnoreCase
                        );
                    }
                }
                // Strongly-typed object ise flatten et
                else
                {
                    var configObject = JsonSerializer.Deserialize<T>(secretString);
                    if (configObject != null)
                    {
                        Data = FlattenObject(configObject, _sectionName);
                    }
                }
            }
            catch (JsonException jsonEx)
            {
                Console.WriteLine($"JSON Deserialization error: {jsonEx.Message}");
                throw;
            }
            catch (Exception ex)
            {
                Console.WriteLine($"Error loading AWS secret: {ex.Message}");
                throw;
            }
        }

        private Dictionary<string, string> FlattenObject(object obj, string prefix = null)
        {
            var result = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);
            FlattenObjectRecursive(obj, prefix, result);
            return result;
        }

        private void FlattenObjectRecursive(object obj, string prefix, Dictionary<string, string> result)
        {
            if (obj == null) return;

            var properties = obj.GetType().GetProperties();

            foreach (var property in properties)
            {
                var value = property.GetValue(obj);
                var key = string.IsNullOrEmpty(prefix)
                    ? property.Name
                    : $"{prefix}{ConfigurationPath.KeyDelimiter}{property.Name}";

                if (value == null)
                {
                    result[key] = null;
                }
                else if (value is string || value.GetType().IsPrimitive || value.GetType().IsEnum)
                {
                    result[key] = value.ToString();
                }
                else if (value is Dictionary<string, string> dict)
                {
                    foreach (var kvp in dict)
                    {
                        result[$"{key}{ConfigurationPath.KeyDelimiter}{kvp.Key}"] = kvp.Value;
                    }
                }
                else if (value.GetType().IsClass)
                {
                    FlattenObjectRecursive(value, key, result);
                }
            }
        }

        private string GetSecret()
        {
            var request = new GetSecretValueRequest
            {
                SecretId = _secretName,
                VersionStage = "AWSCURRENT" //VARSAYILAN
            };

            var regionEndpoint = RegionEndpoint.GetBySystemName(_region);

            using (var secretsManagerClient = new AmazonSecretsManagerClient(regionEndpoint))
            {
                var response = secretsManagerClient.GetSecretValueAsync(request).Result;

                if (response.SecretString != null)
                {
                    return response.SecretString;
                }
                else
                {
                    using var memoryStream = response.SecretBinary;
                    using var reader = new StreamReader(memoryStream);
                    return Encoding.UTF8.GetString(Convert.FromBase64String(reader.ReadToEnd()));
                }
            }
        }
    }
}

Artık altyapımız hazır. Şimdi, Program.cs yapılandırmasını yapalım.

Program.cs

builder.Services.AddDefaultAWSOptions(builder.Configuration.GetAWSOptions());
builder.Services.AddAWSService<IAmazonS3>();
builder.Configuration.AddAwsSecretsManager<ApplicationSettings>(
    region: "eu-central-1", //Dikkat! AWS Region doğru olduğundan emin olunuz.
    secretName: "ApplicationSettings" // AWS üzerinde oluşturulan SecretName değeridir.
);
//DI
builder.Services.Configure<ApplicationSettings>(builder.Configuration);

Controller Örneği

 [HttpGet("connection-string")]
 public async Task<IActionResult> ReadDatabaseConnectionString()
 {
     return Ok(new
     {
         catalogueDb = _applicationSettings.ConnectionStrings.CatalogueDB,
         redisConnection = _applicationSettings.ConnectionStrings.RedisConnection
     });
 }

Kurulması Gereken NuGet Paketleri

• https://www.nuget.org/packages/AWSSDK.Core/4.0.3.9?_src=template
• https://www.nuget.org/packages/AWSSDK.SecretsManager/4.0.4.4?_src=template
• https://www.nuget.org/packages/AWSSDK.Extensions.NETCore.Setup/4.0.3.20?_src=template

Son Söz

Bu yazıda, AWS Secrets Manager kullanarak uygulamalarımızın hassas verilerini nasıl güvenli bir şekilde depolayabileceğimizi gördük ve ASP.NET Core ile AWS SDK entegrasyonunu adım adım inceledik. Artık ihtiyaç duyduğumuz her an AWS’nin sunduğu bu güçlü servisi rahatlıkla kullanabiliriz. 🙂

Umarım faydalı olmuştur. Bir sonraki yazıda yeni konularla tekrar buluşmak üzere…
Herkese iyi çalışmalar!

Mimariyi Tasarlarken Çıkış Noktası

Barlas’ı geliştirirken en başta kendime şu soruyu sordum:

“Günümüz CMS teknolojilerinden ne bekliyoruz ?”

Bu sorunun cevabı genellikle şunlar oldu:

• SEO uyumluluğu
• Yüksek performans
• Ölçeklenebilirlik
• Geliştirici dostu bir altyapı
• Modern front-end teknolojileriyle uyum

Bu ihtiyaçlar doğrultusunda mimari kararlar şekillenmeye başladı.

Neden Next.js ?

Barlas’ın temelinde Next.js bulunmasının sebebi, sunduğu esneklik ve modern web gereksinimlerine doğrudan cevap verebilmesi.

Next.js sayesinde:

• SSR (Server Side Rendering) ile SEO dostu sayfalar
• SSG (Static Site Generation) ile yüksek performans
• API Routes ile backend ihtiyaçlarının karşılanması
• Dosya tabanlı routing ile sade bir yapı

tek bir çatı altında toplanabiliyor. Bu da Barlas’ın hem headless CMS yaklaşımına yakın durmasını hem de klasik CMS’lerin güçlü yönlerini bir araya getirmesini sağlıyor.

Klasik CMS Yaklaşımlarından Barlasın Farkı

Barlas, “tema + eklenti” mantığından ziyade, projeye özel mimariler kurulmasını teşvik eder. Bu da onu:

• Daha esnek
• Daha performanslı
• Daha uzun ömürlü

bir CMS hâline getirir.

Bonus

Tema altyapısının nasıl çalıştığına dair ufak bir gösterim.

Sonuç

Barlas’ın mimarisi, bugünün değil yarının web projeleri düşünülerek tasarlandı. Next.js seçimi, modüler yapı ve geliştirici odaklı yaklaşım; bu vizyonun doğal bir sonucu.

Okuduğunuz için teşekkürler 🙌
Bir sonraki günlükte görüşmek üzere 🚀

Barlas

Barlas, Türkiye’de geliştirilen yerli ve milli bir Content Management System (CMS)’tir. Temel amacı; modern web projeleri için hızlı, ölçeklenebilir, geliştirici dostu ve wordpress alternatifi bir içerik yönetim altyapısı sunmaktır.

Barlas’ın altyapısı Next.js üzerine inşa edilmiştir. Bu sayede:

• Sunucu tarafı ve istemci tarafı render seçenekleri
• Self Hosting
• Yüksek performans
• Seo Uyumluluğu
• Modern Frontend Ekosistemi
• Plugin Sistemi
• No-Code Tema Sistemi
• Development Ready State Yönetim Sistemi

gibi avantajları doğal olarak beraberinde getirir.

Barlas, klasik CMS yaklaşımlarının ötesine geçerek daha esnek, daha modüler ve günümüz web standartlarına uygun bir yapı sunmayı hedefliyor.

Barlas Ne Değildir?

Barlas;

• Kapalı Sistem değildir
• Sadece “hazır tema + içerik” mantığıyla çalışan bir yapı değildir
• Geliştiriciyi kısıtlayan, özelleştirmesi zor bir CMS hiç değildir
• Geliştiriciler lisans satın alımına muhtaç değildir

Aksine, Barlas geliştiricinin kontrolünü ön planda tutar ve projeye göre şekillenebilen özgür bir yapı sunmaktadır.

Bu Seride Neler Olacak?

Bu günlüklerde;

• Mimari kararlar
• Next.js üzerinde CMS geliştirme deneyimleri
• Karşılaşılan problemler ve çözümleri
• Performans, güvenlik ve ölçeklenebilirlik konuları

gibi birçok detayı şeffaf bir şekilde paylaşmayı planlıyorum.

Ekran Görüntüsü

Hedefler

Barlas’ın geliştirme sürecinde yalnızca teknik yeterlilikler değil, aynı zamanda topluluk, ekosistem ve yerli yazılım bilinci de önemli bir yer tutuyor. Bu nedenle erken dönem hedefleri belirlerken, ürünün geleceğini şekillendirecek stratejik adımlara odaklandım.

Vercel Community ile İletişim ve Aksiyonlar

Barlas’ın altyapısında Next.js bulunması, doğal olarak Vercel ekosistemiyle güçlü bir bağ kurulmasını gerektiriyor. Bu kapsamda erken dönem hedeflerimden biri, Vercel Community ile doğrudan iletişime geçmek ve bu doğrultuda çeşitli aksiyonlar almak.

Bu aksiyonlar arasında:

• Projenin Vercel topluluğuna tanıtılması
• Teknik geri bildirimlerin toplanması
• Open-source katkı süreçlerinin değerlendirilmesi
• Olası iş birlikleri ve görünürlük fırsatları

yer alıyor. Amaç, Barlas’ı yalnızca yerel ölçekte değil, küresel ölçekte de bilinir ve takip edilir bir proje hâline getirmek.

Yerli ve Özgür Yazılımın Benimsenmesini Sağlamak

Barlas’ın en temel motivasyonlarından biri, yerli ve özgür yazılım kültürünün yaygınlaşmasına katkıda bulunmak. Türkiye’de geliştirilen projelerin yalnızca tüketilen değil, aynı zamanda üreten, katkı sağlayan ve sürdürülebilir yapılar hâline gelmesi gerektiğine inanıyorum.

Bu doğrultuda Barlas:

• Açık kaynak felsefesini benimser
• Geliştiricilerin projeye katkı sağlamasını teşvik eder
• Yerli yazılım ekosistemine örnek bir CMS olmak hedefler arasındadır

Barlas’ın sadece bir ürün değil, aynı zamanda bir topluluk projesi olması bu vizyonun doğal bir sonucudur.

Bir sonraki yazıda Barlas’ın mimari yapısına ve neden bu teknolojilerin seçildiğine daha derinlemesine gireceğiz.

Okuduğunuz için teşekkürler 🙌
Görüşmek üzere!

Instrumentation

Instrumentation, bir uygulamanın çalışması sırasında telemetri verisi (log, metric, trace) üretmesini sağlamak için koda eklenen ölçüm noktalarıdır. Telemetry verisi nedir sorusunun cevabına aşağıda değinmiş olacağım.

Telemetry Data

Telemetri verileri, uygulamalarınız tarafından oluşturulan tüm günlükleri, ölçümleri, olayları ve izleri kapsamaktadır. Telemetre verileri üç ana başlıktan toplanmaktadır.

Log: Zaman damgalı metin kayıtlarıdır.

Metrik: Uygulamanın davranışını sayısal (numerik) olarak zaman içinde izlememizi sağlar(performans vb.).

Tracing: Tek bir isteğin (request) sistem içindeki uçtan uca yolculuğunu detaylı şekilde izlemeyi sağlar.

• Arada bir verilerin temizlenmesi şarttır bellek şişmesi yaşansın istenmez.

Open Telemetry Collector

Open Telemetry Collector, Verileri alır, Jaeger veya Prometheus gibi monitoring toollara gönderen bir proxy’dir. Verileri yönetmek için sorumluluğu üstlenir.

Open Telemetry Collector’ün üç ana bileşeni vardır:

1. Receiver: Verilerin toplayıcıya gelmesini sağlar. Birden çok veri kaynağından gelen verileri alır.
2. Processor: Verilerin ilgili monitoring toollara gönderilmeden önce manipüle edebilmemizi sağlar.
3. Exporter: Telemetri verilerini OTLP, Prometheus veya Jaeger gibi monitrong toollara gönderir.

Open Telemetry Protocol

Open Telemetry Protocol(OTLP), telemetri verilerini aktarmak için kullanılan bir protokoldür. İki çeşit desteklenen protokol vardır:

1. OTLP/HTTP(protobuf)
2. gRPC

Open Telemetry Protocol(OTLP), telemetri verilerini seri hale getirmek için Protocol Buffers(Protobuf) ve verileri göndermek için gRPC veya HTTP’yi kullanır.

Bir sonraki makalede görüşmek üzere…