Egress, verinin bulut sağlayıcının ağından, bölgesinden ya da hizmetinden dışarı çıkmasıdır. Sunucu ve depolama kalemleri genellikle kapasiteye bağlı olduğu için önceden tahmin edilir. Veri çıkışı ise iş yükünün davranışına bağlıdır ve ay sonunda faturada beklenmedik bir satır olarak görünebilir. Bu yazı bulut maliyet yönetimi ve FinOps danışmanlığı sayfasının veri çıkışı tarafını destekler. Fiyat, oran veya sonuç taahhüdü içermez.
Hızlı Özet
Çıkış maliyetini izlemek üç şeye dayanır. Verinin hangi yönlerde aktığını bilmek, faturada çıkış kalemlerini ayrı görmek ve normal seviyeyi tanımlayıp sapmayı fark etmek. Ücretlendirme kuralları sağlayıcıya, bölgeye ve hizmete göre değişir. Bu yüzden güncel koşulların sağlayıcının resmi dokümantasyonundan ve sözleşmeden doğrulanması gerekir. Leon-X bulut altyapısının sahibi değildir. Mimari ve izleme düzenini sağlayıcı koşullarıyla birlikte değerlendirir.
İçindekiler
- Egress Hangi Akışlardan Doğar
- Faturada Nasıl Ayrıştırılır
- Veri Akış Haritası
- Normal Seviye ve Sapma Uyarısı
- Mimari Kararlar
- Sözleşme ve Çıkış Senaryoları
- Yaygın Hatalar
- Kontrol Listesi
- Leon-X ile Sonraki Adım
- Sık Sorulan Sorular
- Sonuç
- Kaynaklar
Kaynak Wikimedia Commons, Optical fiber cable-10ASD. Fotoğraf Asurnipal tarafından çekilmiş olup CC BY-SA 4.0 lisansıyla yayımlanmıştır.
Egress Hangi Akışlardan Doğar
Çıkış trafiği tek bir yerden gelmez. Faturada tek satıra toplanmış görünse de arkasında birkaç farklı akış vardır.
- Uygulamanın internete verdiği yanıtlar, indirmeler ve API çağrıları
- Bölgeler arası replikasyon ve yedek kopyaları
- Aynı bölge içinde olsa bile farklı erişilebilirlik alanları arasındaki trafik
- Bulut ile şirket içi ortam arasındaki hibrit trafik
- Bir sağlayıcıdan diğerine veri taşıma ve geri yükleme işlemleri
- Üçüncü taraf bir hizmete gönderilen log, metrik ve izleme verisi
Bu akışların her biri farklı bir ekibin kararından doğar. Replikasyonu depolama ekibi, indirme trafiğini uygulama ekibi, log gönderimini operasyon ekibi belirler. Bu yüzden çıkış maliyeti tek bir sahibe bağlanamaz ve ortak izleme gerektirir.
Faturada Nasıl Ayrıştırılır
Bulut sağlayıcıların fatura ve kullanım raporları çoğunlukla kullanım türü ya da ölçüm kategorisi alanı taşır. Çıkış trafiği bu alanda ayrı bir kategori olarak görünür. İzlemenin ilk adımı bu kategoriyi diğer kalemlerden ayırıp tek bir görünümde toplamaktır.
Yalnızca toplam tutara bakmak yetmez. Aynı görünüm hizmete, bölgeye ve mümkünse kaynağa göre kırılabilmelidir. Hangi hizmetin çıkış trafiğine yol açtığını görmek, bir sonraki adımda kimin konuşulacağını belirler. Kırılım için kaynakların ortama ve uygulamaya bağlanmış olması gerekir. Bu bağlantı FinOps döngüsünün bilgilendirme aşamasında kurulan sahiplik düzenine dayanır.
Kategori adları ve kırılım alanları sağlayıcıdan sağlayıcıya farklıdır. Bu yüzden rapor kurulmadan önce ilgili sağlayıcının faturalama dokümantasyonu okunmalıdır.
Veri Akış Haritası
Faturadaki rakam trafiğin miktarını gösterir ama nedenini göstermez. Nedeni bulmak için uygulamaların birbiriyle ve dış dünyayla nasıl konuştuğunu gösteren basit bir akış haritası gerekir.
Harita karmaşık olmak zorunda değildir. Her uygulama için şu sorulara kısa cevap yeterlidir. Veriyi kim üretiyor, nereye gidiyor, hangi yönde ve hangi sıklıkla. Dış kullanıcıya mı, başka bir bölgeye mi, şirket içine mi, başka bir sağlayıcıya mı.
Haritayı çıkarırken sıklıkla şaşırtıcı akışlar bulunur. Test ortamından üretim bölgesine giden bir kopya işi, kimsenin hatırlamadığı bir yedek hedefi ya da gereğinden sık çalışan bir veri senkronizasyonu bunlara örnektir. Bu akışlar kodda ya da yapılandırmada durduğu için faturaya bakarak değil, haritaya bakarak yakalanır.
Hibrit ve çoklu bulut ortamlarında harita daha da önemlidir. Veri yönü ile ağ ve kimlik entegrasyonu birlikte düşünülür. Bu çerçeve hibrit bulut ağ ve kimlik entegrasyonu yazısında anlatılır. Birden fazla sağlayıcı kullanıldığında veri çıkışı her biri için ayrı okunmalıdır. Bu ayrım multi-cloud ve hibrit farkı yazısında ele alınır.
Normal Seviye ve Sapma Uyarısı
Çıkış trafiği iş hacmiyle birlikte dalgalanır. Bu yüzden sabit bir eşik çoğu zaman yanıltıcıdır. Daha işe yarar yaklaşım, her uygulama için normal seviyenin tanımlanması ve bu seviyeden sapmanın izlenmesidir.
Normal seviyeyi tanımlarken iş döngüsü de hesaba katılır. Ay sonu raporları, kampanya dönemleri ve yedek pencereleri çıkışı doğal olarak artırır. Bunlar baz çizgiye yazılmazsa her dönemsel artış yanlış alarm üretir.
Uyarı kuralları iki kademeli olabilir. Birinci kademe sapmayı ilgili uygulama sahibine haber verir. İkinci kademe sapma sürdüğünde finans ve mühendislik tarafını birlikte bilgilendirir. Her uyarının bir sahibi ve bir inceleme adımı olmalıdır. Sağlayıcıların bütçe ve maliyet uyarı özellikleri bu amaçla kullanılabilir. Özelliklerin kapsamı ve ayarları sağlayıcıya göre değişir.
Mimari Kararlar
İzleme sorunu gösterir, mimari karar sorunu azaltır. Çıkışı etkileyen kararlar genellikle tasarım aşamasında alınır.
Sık konuşan hizmetlerin aynı bölgede ve mümkünse aynı alanda tutulması, gereksiz bölgeler arası trafiği önler. Bu kararın bir de dayanıklılık karşılığı vardır. Bu yüzden maliyet ile dayanıklılık birlikte tartılır.
Sık erişilen içeriğin önbellek katmanından sunulması, kaynak hizmetten çıkan veriyi azaltabilir. Veriyi sıkıştırmak ve yalnızca gereken alanları döndürmek de aynı yönde etki eder.
Yedek ve arşiv verisinin nerede tutulduğu da çıkış maliyetini etkiler. Geri yükleme sırasında veri sağlayıcı dışına çıkacaksa bu kalem hesaba katılmalıdır. Nesne depolamanın yedek ve arşiv rolü object storage yazısında ayrıntılı anlatılır.
Log ve izleme verisinin nereye gönderildiği de gözden geçirilmelidir. Tüm ayrıntı düzeyindeki logları dış bir hizmete akıtmak sessiz bir çıkış kaynağı olabilir.
Sözleşme ve Çıkış Senaryoları
Çıkış maliyeti yalnızca günlük işletmede değil, platform değiştirirken de önem kazanır. Büyük bir veri setini başka bir sağlayıcıya ya da şirket içi ortama taşımak, tek seferlik ama yüksek bir çıkış kalemi doğurabilir.
Bu nedenle sözleşme ve fiyatlandırma dokümanında üç soru yazılı olarak cevaplanmalıdır. Hangi yönler ve hizmetler çıkış olarak ücretlendiriliyor. Taşıma ya da çıkış için ayrı bir koşul veya program var mı. Geri yükleme ve doğrulama testleri çıkış sayılıyor mu.
Bu cevaplar sağlayıcıdan sağlayıcıya değiştiği için varsayımla değil, resmi dokümantasyon ve sözleşmeyle doğrulanmalıdır. Taşıma projelerinde veri hacmi ve çıkış yönü planın en başında hesaplanmalıdır. Geçiş katmanlarının genel çerçevesi için buluta geçiş kontrol listesi yazısına bakabilirsiniz.
Yaygın Hatalar
Çıkış kalemini toplam ağ ya da depolama satırının içinde bırakmak, kaynağı görünmez kılar. Ayrı bir görünüm kurmak ilk iştir.
Yalnızca fatura geldikten sonra bakmak ikinci yaygın hatadır. Çıkış trafiği gün içinde birikir ve sapma ay sonunu beklemeden fark edilebilmelidir.
Geri yükleme testini hiç yapmamak da risk taşır. Test yapılırsa çıkış maliyeti ve süre ilk kez görülür. Yapılmazsa ilk gerçek geri yükleme sırasında şaşırtıcı bir kalemle karşılaşılır.
Mimari tasarım sırasında maliyeti hiç konuşmamak da sık görülür. Bölgeler arası bir replikasyon kararı, maliyet etkisi bilinmeden verilirse sonradan değiştirmek zor olur.
Kontrol Listesi
- Faturada çıkış kalemleri diğer kalemlerden ayrı görülebiliyor mu
- Çıkış hizmete, bölgeye ve uygulamaya göre kırılabiliyor mu
- Her uygulama için veri akış haritası çıkarılmış mı
- Normal seviye iş döngüsüne göre tanımlanmış mı
- Sapma uyarısının sahibi ve inceleme adımı belli mi
- Bölgeler arası replikasyon kararları maliyet etkisiyle birlikte alınıyor mu
- Geri yükleme ve taşıma senaryosunun çıkış maliyeti hesaplanmış mı
- Çıkış koşulları sağlayıcının resmi dokümantasyonu ve sözleşmesiyle doğrulanmış mı
Leon-X ile Sonraki Adım
Leon-X mevcut bulut ortamınızdaki veri akışlarını, çıkış kalemlerinin kaynağını ve uyarı düzenini birlikte inceler. Hangi akışların haritada olmadığını, hangi kalemlerin sahipsiz kaldığını ve hangi mimari kararların çıkışı artırdığını listeler. Kapsam ve düzen ortamınıza göre netleşir. Sağlayıcıya ait fiyat ve koşul ayrıntıları resmi dokümantasyon ve sözleşmeyle doğrulanır. Ayrıntılar bulut maliyet yönetimi ve FinOps danışmanlığı sayfasında yer alır. Keşif için iletişime geçin.
Sık Sorulan Sorular
Egress ile ingress aynı şekilde ücretlendirilir mi?
Bu sağlayıcıya, bölgeye ve hizmete göre değişir. Giriş ve çıkış için geçerli kurallar sağlayıcının resmi fiyatlandırma dokümanında ayrı ayrı okunmalıdır.
Aynı bölge içindeki trafik de egress sayılır mı?
Bu da sağlayıcıya göre değişir. Bazı hizmetlerde aynı bölge içinde farklı alanlar arasındaki trafik de ölçülür. İlgili hizmetin faturalama dokümanı bu ayrıntıyı belirtir.
Egress maliyetini tamamen ortadan kaldırmak mümkün mü?
Genellikle hayır, çünkü çıkış iş yükünün doğal bir parçasıdır. Amaç sıfırlamak değil, görünür kılmak ve gereksiz akışları azaltmaktır.
Çıkış maliyetini kim izlemeli?
Tek bir ekip değil. Uygulama sahibi akışı, finans tarafı kalemi, operasyon ekibi uyarıyı takip eder. Koordinasyon tek bir kişide olabilir ama sahiplik paylaşılır.
Sonuç
Bulut maliyetinde egress, verinin hangi yönlerde aktığını bilmeden okunamayan bir kalemdir. Çıkış kalemini faturada ayırmak, veri akış haritası çıkarmak, normal seviyeyi tanımlayıp sapmayı izlemek ve mimari kararları maliyet etkisiyle birlikte vermek bu kalemi yönetilebilir kılar. Taşıma ve geri yükleme senaryoları için sağlayıcı koşulları baştan doğrulanmalıdır. Kapsam için bulut maliyet yönetimi ve FinOps danışmanlığı sayfasına bakabilirsiniz.
Kaynaklar
- Bulut sağlayıcıların resmi fiyatlandırma ve faturalama dokümantasyonu (veri aktarımı bölümleri)
- FinOps Foundation, FinOps Framework (finops.org)
- Leon-X, bulut maliyet yönetimi ve FinOps danışmanlığı
