Bulut Bilişim Temelleri

Bulut Bilişim Temelleri ve AWS Çözüm Mimarlığına Giriş

AWS erişim sorunlarında ilk üç kontrol hesabı, bölgeyi ve IAM yetkilerini kapsar. Ardından DNS, ağ kuralları, uygulama günlükleri ve kapasite ölçümlerini sırayla inceleyerek sorunun kaynağını daraltabilirsiniz.

Cloud Teknik Editörlüğü · 7 dk okuma
Sunucu raflarının yanındaki dizüstü bilgisayarda uygulama, veritabanı ve depolama bağlantı şeması
Bu yazıda neler var?
  1. Hizmet Modelini ve Sorumlulukları Belirleyin
  2. Hesap, Bölge ve IAM Hatalarını Giderin
  3. DNS ve Ağ Bağlantısını Katman Katman Sınayın
  4. Uygulama Durumunu ve Kapasiteyi Ölçün
  5. AWS Çözüm Mimarlığında Seçenekleri Karşılaştırın
  6. RTO ve RPO Hedeflerini Test Edin
  7. Ne Zaman Uzman Desteği Alınmalı?
  8. Sık Yapılan Hatalar ve Çözümleri

AWS uygulamasına erişemiyorsanız ilk 3 kontrolü hesabınıza, seçili bölgeye ve IAM yetkilerine ayırın. Hata mesajını kaydedin, ardından DNS çözümünü ve ağ bağlantısını sınayın. Bu sıra, yanlış ayar değiştirmeden sorunun kimlik, ağ veya uygulama katmanında olduğunu gösterir.

Bulut bilişim temelleri, işlem gücü, depolama ve ağ gibi kaynakların hizmet olarak kullanılmasını açıklar. AWS çözüm mimarlığı ise bu kaynakları güvenlik, performans, süreklilik ve işletme gereksinimleriyle birlikte tasarlar.

Hizmet Modelini ve Sorumlulukları Belirleyin

Sorun giderme başlamadan önce kullandığınız hizmet modelini belirleyin. Yönetim görevi IaaS, PaaS ve SaaS arasında aynı şekilde paylaşılmaz. Bir bileşenin sağlayıcı tarafından işletilmesi, uygulama kodu veya veriler üzerindeki sorumluluğun da sağlayıcıya geçtiği anlamına gelmez.

ModelSağlayıcının yönettiği alanSizin yönettiğiniz alan
IaaSFiziksel altyapı ve sanallaştırmaİşletim sistemi, uygulama, ağ ayarları ve veri
PaaSAltyapı ve çalışma ortamıUygulama kodu, yapılandırma ve veri
SaaSHazır uygulama ve hizmet altyapısıKullanıcılar, erişim ve kullanım ayarları

İşletim sistemi üzerinde yönetim istiyorsanız IaaS yaklaşımını seçin. Amazon EC2, sanal sunucu sağlayan bir IaaS örneğidir. Kod çalıştırmak ve sunucu işletimini azaltmak istiyorsanız PaaS türü bir hizmete bakın. Hazır işlevler için SaaS kullanın.

AWS çözüm mimarı, her bileşenin amacını ve sorumluluk sahibini açıkça yazar. Mimari şemada kullanıcı, uygulama, veri deposu, ağ sınırı ve dış hizmetleri ayrı gösterin. Bu şema, hata sırasında kontrol edilecek katmanı hızlıca seçmenizi sağlar.

Hesap, Bölge ve IAM Hatalarını Giderin

Kaynak listede görünmüyorsa veya Access Denied hatası alıyorsanız önce hesap ve bölgeyi kontrol edin. AWS kaynakları çoğu zaman belirli bir bölgede oluşturulur. Yanlış bölge seçildiğinde kaynak silinmiş gibi görünebilir; yanlış hesapta oturum açıldığında ise aynı belirti oluşur.

  1. AWS konsolunda oturum açtığınız hesap veya rolü kontrol edin.
  2. Kaynağın oluşturulduğu bölgeyi seçin ve listeyi yenileyin.
  3. Hata mesajını, işlem adını ve kaynak kimliğini kaydedin.
  4. IAM kullanıcı veya rolünün ilgili işlem için yetkisini inceleyin.
  5. İzin gerekiyorsa erişimi yalnızca gerekli işlem ve kaynağa sınırlayın.
  6. İşlemi yeniden deneyin ve yeni sonucu önceki kayıtla karşılaştırın.

IAM politikasında izin bulunması, işlemin kesin olarak serbest olduğu anlamına gelmez. Kaynak politikası, açık bir ret, kuruluş kuralı veya oturum politikası da erişimi engelleyebilir. Yetki düzeltirken geniş yönetici izni vermek yerine belirli işlem ve kaynakları tanımlayın.

İpucu: Yönetim hesabında çok faktörlü doğrulamayı etkinleştirin. Gizli anahtarları günlük dosyalarına, destek kayıtlarına veya ekran görüntülerine eklemeyin.

DNS ve Ağ Bağlantısını Katman Katman Sınayın

IAM kontrolü geçildiği hâlde uygulama yanıt vermiyorsa ağ yolunu ayrı inceleyin. İstemci, DNS, yönlendirme, güvenlik kuralları ve hedef uygulama aynı erişim zincirinin parçalarıdır. Her katmanı tek tek sınamak, aynı anda birçok ayarı değiştirip yeni bir hata oluşturmanızı önler.

  1. Alan adının beklenen hedefe çözümlendiğini kontrol edin.
  2. Aynı adrese farklı bir ağdan erişip sonuçları karşılaştırın.
  3. İstemcinin hedefe ulaşabildiğini ve doğru bağlantı noktasını kullandığını sınayın.
  4. Güvenlik gruplarını ve ağ erişim listelerini ilgili kaynakla karşılaştırın.
  5. Alt ağ, yönlendirme tablosu ve ağ geçidi ilişkisini inceleyin.
  6. Uygulamanın hedef sunucuda çalıştığını ve bağlantı noktasını dinlediğini doğrulayın.

Bir uygulama sunucusu veritabanına bağlanıyorsa dış erişimden ayrı bir bağlantı testi yapın. İstemciden uygulamaya erişim başarılı olsa bile uygulamadan veritabanına giden yol kapalı olabilir. Ağ kuralını düzeltirken kaynak, hedef ve bağlantı noktasını açıkça belirleyin.

DNS sonucu doğru, ağ yolu açık ve uygulama yanıt vermiyorsa günlükleri inceleyin. İsteğin zamanını, kaynak adresini ve hata kodunu birlikte kaydedin. Bu bilgiler, ağ reddi ile uygulama içi hatayı birbirinden ayırır.

Uygulama Durumunu ve Kapasiteyi Ölçün

Uygulama açılıyor fakat yavaş çalışıyorsa gözleminizi ölçüme çevirin. Eş zamanlı kullanıcı sayısını, isteklerin yanıt süresini, hata oranını ve veri hacmini kaydedin. Yanıt süresini milisaniye, veri hacmini MB veya GB, işlemci ve belleği yüzde olarak izleyin.

Veri akışı şeması ve performans ölçüm araçlarının bulunduğu mimari planlama masası
Veri akışını ve ölçülebilir performans hedeflerini birlikte planlayın.
  1. Yavaş işlemi ve beklenen yanıt süresini tanımlayın.
  2. Aynı senaryoyu kontrollü bir test ortamında çalıştırın.
  3. İşlemci, bellek, depolama, ağ ve uygulama hatalarını aynı zaman aralığında izleyin.
  4. Yavaşlama anını uygulama ve sistem günlükleriyle eşleştirin.
  5. Darboğazı belirleyin ve yalnızca ilgili kapasiteyi veya ayarı değiştirin.
  6. Aynı testi tekrarlayıp iki ölçüm grubunu karşılaştırın.

İşlemci kullanımı yüksekse hesaplama kapasitesini ve uygulama iş parçacıklarını inceleyin. Bellek baskısı varsa önbellek, işlem kuyruğu ve bellek tüketen sorguları kontrol edin. Depolama gecikmesi yüksekse disk işlemlerini ve veri erişim desenini ölçün.

Pilot çalışmada tek bir başarı ölçütü kullanmayın. Yanıt süresi, hata oranı ve kaynak tüketimini birlikte değerlendirin. Ölçüm sonucu olmadan kapasite artırmak, gerçek darboğazı çözmeden işletme yükünü büyütebilir.

AWS Çözüm Mimarlığında Seçenekleri Karşılaştırın

Bir mimariyi seçerken yalnızca hizmet adını listelemeyin. Her bileşenin neden kullanıldığını, hangi veriyi taşıdığını ve arıza durumunda ne olacağını yazın. Bu yaklaşım, bulut bilişim temellerini doğrudan işletme kararlarına bağlar.

İhtiyaçBaşlangıç yaklaşımıKontrol edilecek ölçüt
Hızlı prototipYönetilen çalışma ortamıDağıtım süresi ve yapılandırma sınırları
İşletim sistemi kontrolüSanal sunucuYama, izleme ve ölçekleme sorumluluğu
Hazır iş uygulamasıSaaSKullanıcı erişimi ve veri dışa aktarımı
Kesinti sonrası geri dönüşYedekleme ve geri yükleme düzeniGeri yükleme süresi ve veri kaybı sınırı

Şu durumlarda yönetilen hizmeti seçin: küçük bir ekip işletim yükünü azaltmak istiyorsa, standart bir çalışma ortamı yeterliyse veya hızlı bir pilot gerekiyorsa. İşletim sistemi ayarı, özel ağ davranışı ya da özel yazılım bağımlılığı gerekiyorsa sanal sunucu yaklaşımını değerlendirin.

Mimari karar kaydına varsayımlarınızı, alternatifleri ve ölçüm sonuçlarını ekleyin. Örneğin veri tabanının aynı ağ sınırında bulunması, uygulama trafiğinin tek bir bağlantı noktasından geçmesi ve yedeklerin geri yüklenmesi gibi varsayımları ayrı yazın.

RTO ve RPO Hedeflerini Test Edin

Hizmet sürekliliği için iki temel hedef belirleyin. RTO, hizmetin geri getirilmesi için kabul edilen süreyi ifade eder. RPO, geri yükleme sırasında kabul edilen veri kaybını zaman aralığıyla tanımlar.

  1. Hangi işlevlerin kesinti sırasında öncelikli olduğunu listeleyin.
  2. Her işlev için kabul edilen geri dönüş süresini yazın.
  3. Kaybedilebilecek veri aralığını iş birimiyle belirleyin.
  4. Yedekleme ve çoğaltma düzeninin bu hedefleri karşılayıp karşılamadığını kontrol edin.
  5. Geri yükleme testi yapın ve gerçek süreyi kaydedin.
  6. Hedef ile test sonucu arasındaki fark için düzeltme planı oluşturun.

Yedek alınması, geri yüklemenin çalıştığını kanıtlamaz. Test sırasında uygulamanın açıldığını, verinin okunabildiğini ve bağımlı hizmetlerin erişilebilir olduğunu kontrol edin. Test kayıtlarında başlangıç saatini, bitiş saatini, geri getirilen veriyi ve görülen hataları saklayın.

Ne Zaman Uzman Desteği Alınmalı?

Hesap, bölge, IAM, DNS ve ağ kontrollerinden sonra hata sürüyorsa olay kaydını genişletin. Birden fazla kullanıcı aynı anda erişemiyorsa ve uygulama günlüklerinde istek görünmüyorsa altyapı veya ağ katmanına odaklanın. İstek günlükte görünüyor, fakat uygulama hata üretiyorsa uygulama ekibini dahil edin.

Yetkili bulut yöneticisine veya AWS Support kanalına başvururken hesap tanımını, bölgeyi, hizmet adını, hata kodunu ve olay zamanını paylaşın. Denediğiniz adımları ve sonuçlarını sıralayın. Parola, gizli anahtar, erişim belirteci veya kişisel veriyi destek kaydına koymayın.

Kişisel veri işleyen mimarilerde veri işleme, saklama ve erişim yükümlülüklerini Kişisel Verileri Koruma Kurumunun resmî kaynaklarından kontrol edin. Mevzuata ilişkin güncel uygulama için kurumun yayımladığı açıklamaları ve kuruluşunuzun yetkili danışmanını esas alın.

Sık Yapılan Hatalar ve Çözümleri

  • Yanlış bölgeyi kontrol etmek: Kaynağın oluşturulduğu bölgeyi seçin ve kimlik bilgilerini doğrulayın.
  • Geniş yönetici izni vermek: Gerekli işlem ve kaynakla sınırlı bir politika kullanın.
  • Aynı anda birçok ayarı değiştirmek: Tek değişiklik yapın, testi tekrarlayın ve sonucu kaydedin.
  • Günlük saatlerini karşılaştırmamak: İstemci, uygulama ve altyapı kayıtlarında aynı zaman aralığını kullanın.
  • Yedeği hiç geri yüklememek: İzole bir ortamda geri yükleme testi yapın.
  • Performansı yalnızca işlemciyle ölçmek: Bellek, depolama, ağ, hata oranı ve yanıt süresini birlikte izleyin.

Her olay için kısa bir kayıt şablonu hazırlayın. Şablonda hesap, bölge, hizmet, hata mesajı, başlangıç zamanı, yapılan değişiklik ve test sonucu bulunsun. Bu alanlar, aynı arızanın tekrarlanması hâlinde tanı süresini kısaltır.

AWS hizmetlerinin teknik ayrıntıları ve hizmete özgü sınırlar için AWS belgelerine başvurun. Kişisel veri işleme yükümlülükleri için Kişisel Verileri Koruma Kurumunun resmî kaynaklarını kullanın.

Sık sorulan sorular

AWS'de kaynak görünmüyorsa ilk hangi kontroller yapılmalı?
Önce doğru AWS hesabında veya rolünde oturum açtığınızı kontrol edin. Ardından kaynağın oluşturulduğu bölgeyi seçin. IAM yetkilerini, kaynak politikasını ve açık ret kurallarını inceleyin. Hata mesajını, işlem adını ve kaynak kimliğini kaydedin; bu bilgiler sonraki incelemeyi hızlandırır.
Bulut uygulamasına internet kesilince uygulama kapanır mı?
İnternet bağlantısı kesilen kullanıcı buluttaki uygulamaya erişemez. Uygulama sağlayıcı tarafında çalışmayı sürdürebilir, fakat kullanıcı hizmete ulaşamaz. Çevrimdışı çalışma gerekiyorsa yerel veri saklama, bağlantı yeniden kurulduğunda eşitleme ve çakışma çözümü tasarımda ayrıca planlanmalıdır.
Hibrit bulut ile çoklu bulut arasındaki fark nedir?
Hibrit bulut, özel bulut ile genel bulut gibi farklı ortamların birlikte kullanılmasını anlatır. Çoklu bulut ise birden fazla bulut sağlayıcısının aynı çözümde kullanılmasını ifade eder. Bir mimari hem hibrit hem çoklu bulut olabilir; iki kavram farklı tasarım kararlarını tanımlar.
RTO ve RPO değerleri nasıl belirlenir?
RTO için her işlevin kesinti sonrası kaç süre içinde dönmesi gerektiğini belirleyin. RPO için kabul edilebilecek veri kaybını zaman aralığıyla yazın. İş birimi bu hedefleri onayladıktan sonra yedekleme, çoğaltma ve geri yükleme testlerini ölçülen sonuçlarla karşılaştırın.

Kaynaklar

  1. Amazon Web Services
  2. Kişisel Verileri Koruma Kurumu