Şirket içine AWS altyapısı kurmak: Outposts planlama ve kurulum rehberi

Outposts ne zaman gündeme gelir?

AWS Outposts, AWS altyapısını, hizmetlerini, API'lerini ve araçlarını müşterinin kendi tesisine uzatan, AWS tarafından işletilen bir hizmettir. Uygulamalar bölgedeki ile aynı programlama arayüzleriyle çalışır; fark, hesaplama ve depolamanın yerelde olmasıdır.

Bu seçeneğin gündeme geldiği tipik durumlar şunlardır:

• Üretim hattı, hastane cihazı ya da ticaret sistemi gibi çok düşük gecikme isteyen uygulamalar
• Verinin yasal ya da sözleşmesel nedenlerle tesis dışına çıkamaması
• Büyük ölçekli yerel veri işleme: verinin buluta taşınmadan önce yerelde süzülmesi
• Eski sistemlerle yakın çalışması gereken ve bir anda buluta taşınamayan iş yükleri

Bulutun tamamını kullanabiliyorsanız Outposts gereksiz karmaşıklıktır. Sorun "gecikme" ya da "veri yerelliği" değilse önce standart bölge mimarisini değerlendirin.

Temel kavramlar: site, rack, server, service link

Planlamaya başlamadan önce AWS'nin kullandığı terimleri ayırmak gerekir:

• Outpost sitesi: AWS'nin ekipmanı kuracağı, sizin yönettiğiniz fiziksel bina. Tesis, ağ ve güç gereksinimlerini karşılaması gerekir.
• Outposts rack: sektör standardı bir dolap biçimi. Rafa takılabilir sunucular, anahtarlar, ağ ara paneli ve güç rafı içerir. Çok dolaplı kurulumlarda ağ birleştirme noktası olarak ACE rafı kullanılır.
• Outposts server: standart bir kabine yerleştirilebilen, dar alanlı ve küçük kapasiteli yerler için tasarlanmış sunucu biçimi.
• Service link: Outpost ile bağlı olduğu AWS bölgesi arasındaki ağ yolu. Her Outpost, bir erişilebilirlik bölgesinin uzantısı gibi çalışır.
• Local gateway (LGW): rack ile yerel ağınız arasındaki mantıksal yönlendirici.
• Yerel ağ arayüzü: server biçiminde yerel ağla iletişimi sağlar.

Önemli bir sonuç: Outpost, bölgeye bağımlıdır. Outpost bölgenin uzantısı olarak çalıştığı için service link kesintisinde neyin etkileneceğini önceden bilmek gerekir. Bu yüzden bağlantıyı yedekli kurmak ve kesinti senaryosunu tasarlamak gerekir.

Rack mi server mı: nasıl seçilir?

Seçim, hangi hizmetleri yerelde çalıştıracağınıza bağlıdır. AWS dokümantasyonundaki hizmet desteği tablosuna göre fark şöyle özetlenebilir:

• Rack biçiminde EC2, ECS, EKS düğümleri, RDS, ElastiCache, EMR, EBS, S3 ve Application Load Balancer gibi geniş bir hizmet yelpazesi çalıştırılabilir.
• Server biçiminde EC2 ve ECS ile ağ hizmetlerinin bir bölümü desteklenir; EKS düğümleri, RDS, EBS, S3 ve Application Load Balancer desteklenmez.

Ölçüt olarak şu soruları sorun: Yerelde veritabanı gerekiyor mu? Depolama yerelde mi tutulacak? Tesisiniz dolap alanı ve güç sunabiliyor mu? Küçük bir şube, mağaza ya da fabrika hattı için server, veri merkezi ölçeğinde çoklu iş yükü için rack mantıklıdır. Kurulum sorumluluğu da farklıdır: rack için teslimat, kurulum ve bakım hizmetin parçasıdır; server için kurulum ve iade paketleme sizin işinizdir.

Hizmet desteği bölgeye göre değiştiği için hedef bölgenin güncel desteğini resmî dokümantasyonda kontrol edin.

Kurulum akışı: siparişten çalışan iş yüküne

Gerçekçi bir akış şu adımları izler:

• İhtiyaç analizi: iş yükü profili, gecikme hedefi, depolama ve ağ ihtiyacı çıkarılır.
• Site değerlendirmesi: güç, soğutma, fiziksel erişim, zemin ve ağ çıkışı kontrol edilir.
• Sipariş: örnek tipi ve depolama kombinasyonu seçilir, sözleşme süresi ve ödeme biçimi belirlenir. Fiyat siparişe göre değişir.
• Fiziksel kurulum: AWS ekipmanı teslim eder ve bağlar; siz ağ ve güç tarafını hazırlarsınız.
• Bölgeye bağlanma: service link kurulur, Outpost bölgede görünür hale gelir.
• Alt ağ ve yönlendirme: VPC içinde Outpost'a ait alt ağlar oluşturulur, local gateway üzerinden yerel ağ ile yönlendirme tanımlanır.
• İş yükü yerleşimi: EC2 örnekleri, kapsayıcılar ve veritabanları Outpost alt ağlarında oluşturulur.

VPC içinde Outpost alt ağındaki örnekler bölgedeki örneklerle özel IP adresleri üzerinden konuşabilir. Bu, hibrit mimaride uygulamanın bir parçasının yerelde, diğer parçasının bölgede çalışmasına izin verir.

Ağ tasarımı ve bağlantı

Outposts projelerinde en çok sorun çıkaran alan ağdır. İki akışı ayrı düşünün:

• Aşağı yönlü bağlantı: Outpost ile bölge arasındaki service link. Yönetim, izleme ve bölge hizmetlerine erişim bundan geçer. AWS Direct Connect gibi özel bir hat ya da genel internet üzerinden kurulabilir; kurumsal ortamda yedekli hat tercih edilir.
• Yerel erişim: kullanıcıların ve yerel sistemlerin Outpost'taki iş yüklerine erişimi. Rack için local gateway, server için yerel ağ arayüzü kullanılır.

Kontrol listesi: IP adres planı bölge VPC'siyle çakışmıyor mu, alt ağ boyutu iş yükü büyümesine yetiyor mu, güvenlik duvarı kuralları service link trafiğine izin veriyor mu, DNS çözümlemesi yerelde de bölgede de tutarlı mı? Bir Outpost'u aynı VPC içinde başka bir Outpost ya da Local Zone ile bağlayamazsınız; çok sahalı yapıda her site için ayrı tasarım gerekir.

Kapasite, işletim ve maliyet kontrolü

Outpost sınırlı fiziksel kapasiteye sahiptir; bulutun sonsuz kapasite varsayımı geçerli değildir. Kapasite, Outposts konsolundan görülür ve yönetilir. Hangi örnek ailesinin ve kaç uygulamanın yerleşeceği baştan hesaplanmalı, büyüme için pay bırakılmalıdır.

İşletim tarafında dikkat edilecekler:

• İzleme: service link durumu, kapasite kullanımı ve örnek sağlığı CloudWatch ile izlenir.
• Yedekleme ve felaket kurtarma: yerel verinin kopyasının nerede tutulacağı baştan belirlenir; tek sahaya güvenilmez.
• Sorumluluk ayrımı: donanımın bakımı AWS'dedir; tesis güvenliği, güç ve soğutma sizdedir.
• Maliyet: sözleşme süresi ve ödeme seçeneği siparişe bağlıdır, bölgeden Outpost'a veri aktarımı ayrıca faturalanır. Kullanılmayan kapasite de bedel taşıdığı için doluluk takip edilir.

Sık hata: Outposts'u geçici bir deneme gibi görmek. Donanım siparişi, sözleşme ve saha kurulumu nedeniyle bu karar bir altyapı yatırımıdır; küçük bir kanıtlama çalışmasıyla başlayıp ölçüleri netleştirmek akıllıca olur.

Mindset programında bu beceri

AWS Outposts ile Şirket İçi AWS Altyapısı eğitimi, hibrit bulut yaklaşımını ve Outposts mimarisini, ardından ağ tasarımı ve bağlantıyı, kurulum ve kapasite senaryolarını, en sonunda operasyon modelini ve kurumsal değerlendirme atölyesini ele alır.

Bu içerik, veri merkezi yöneten altyapı ekipleri ve bulut mimarları için uygundur. Kurumsal ekipler kendi sahalarını, gecikme gereksinimlerini ve uyum kısıtlarını atölyede somut bir değerlendirme olarak çalışabilir.