![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
Bu yazı ilk olarak The New Stack'te yayınlandı.
Birkaç yıl boyunca, "özel bulut" terimi olumsuz bir çağrışım taşıyordu. Ancak bildiğimiz gibi, teknoloji bir ok olmaktan çok bir çarktır ve tam zamanında, özel bulut çok fazla ilgi görüyor ve hepsi olumlu. İstatistikler açık, Forrester'ın 2023 Altyapı Bulut Anketi'ne katılan 1.300 kurumsal karar vericinin %79'u özel bulutları uyguladıklarını söyledi. Bir
Sebepler çeşitlidir ve bunları ayrıntılı olarak açıklayacağız, ancak daha önemlisi, geri göndermek için doğru mimari nedir? Özel bulutun mühendislik ilkeleri nelerdir? Ve son olarak, yapay zekanın veri altyapısı gereksinimleri için nasıl tasarım yaparım?
Şirketlerin geri göndermelerinin birincil nedeni maliyettir. Geri göndererek %70'e kadar tasarruf sağlarlar. Bu, çeşitli şirketler tarafından kamuoyuna kanıtlanmıştır.
İlgili, ancak aynı olmayan şey öngörülebilirliktir. Özel bulutlar daha az esneklikle gelir, ancak daha fazla öngörülebilirlik (aşağıda bazı esneklik hilelerine değiniyoruz). İş yüklerini anlayan çoğu CIO için bu takas buna değer. CFO'lar için daha da kolay bir seçimdir.
Güvenlik sorunları üçüncü sırada yer alıyor. Bu, genel bulutun doğası gereği güvensiz olduğu anlamına gelmiyor, öyle değil. CISO'ların genel bulut ortaklarına (aslında çoğu bulut sağlayıcısı kovalarınıza bakma hakkını saklı tutar) bu konuda tamamen güvenmediğini söylüyor. AI çağında riskler daha da artıyor.
İlgili bir not olarak, kontrol her CIO'nun listesinde yer alır. Maliyet tasarrufu, öngörülebilirlik ve güvenlikle birlikte, yalnızca AI veri altyapınızın tam kontrolüne sahip olmakla kalmazsınız, aynı zamanda bu veriler tüm uygulamalarınızın tüketmesi için yakındır ve bu sayede modellerinizi, sizin ve ekibinizin benzersiz güvenlik gereksinimlerinizle - hatta fiziksel erişimle - eşleşecek şekilde güvenlik standartlarının belirlenebileceği AI veri altyapısında barındırabilirsiniz.
Olgunluk da sıralanır. Modern bulut bir işletme modelidir, bir konum değil. Bir zamanlar büyük genel bulutların münhasır tedarikçisi olan bu model artık her yerdedir — uçtan çekirdeğe. Konteynerleştirme, orkestrasyon, mikro hizmetler, yazılım tanımlı altyapı, RESTful API'ler standart işletme prosedürleridir. Bunları nerede çalıştırdığınız önemli değildir — ve önemli değilse, neden maliyetin iki ila üç katını ödeyesiniz ki?
Düzenlemeler de özellikle evrimleştikçe bir rol oynar. Bazı mimariler, bazı coğrafyalar, bazı dağıtım senaryoları (askeri/istihbarat) başlangıçta özel bulutları gerektirmedi ama şimdi gerektiriyor.
Tekrar söylüyorum, sebepler farklı olacak ama etkisi aynı. Özel bulut tekrar moda oldu. Soru şu: Geçtiğimiz birkaç yılda ne değişti?
Yukarıda belirtildiği gibi, özel bulut, genel bulut gibi, bulut işletim modelinde çalışır. Uç bulut, bulut işletim modelinde çalışır. Ortak yerleşim, bulut işletim modelinde çalışır.
Bu işletim modeli belirli bir mimariyi tanımlar ve bu mimari, modern veri gölünü mümkün kılar. Elbette başka mimariler de vardır, ancak modern veri gölünüzü oluşturmak için özel bulutu kullanmak, kuruluşların yalnızca ihtiyaç duydukları şey için ödeme yapmalarını sağlar. İşleri büyüdüğünde, ölçeklendirme bir kümeye daha fazla kaynak eklemek kadar basittir. Yeniden tasarıma gerek yoktur.
Modern bir veri gölü, yarı veri ambarı ve yarı veri gölüdür ve her şey için nesne depolamasını kullanır. Nesne depolama katmanı yazılım tanımlı, ölçeklenebilir, bulut tabanlı ve performanslıdır. Performans, aşağıdakilerin seçimiyle ayarlanabilir:
Nesne depolamayı veri gölüyle kullanmak standarttır, veri ambarıyla kullanmak yenidir ve Apache Iceberg, Apache Hudi ve Delta Lake gibi Açık Tablo Biçimleri (OTF'ler) sayesinde mümkün olmuştur. Bu mimari hakkında bu makalenin kapsamının ötesinde önemli ayrıntılar vardır. Bunun için Keith Pijanowski'nin tam
Bu mimari, tamamı temel bulut işletim prensipleri ve dolayısıyla özel bulutun temel prensipleri olan aşağıdakileri sunmak üzere tasarlanmıştır:
Yüksek performans: Özel bulut kapasite için tasarlanabilse de, modern özel bulut ölçekte performans sunmayı hedefler. Bu mimari, hız ve verimliliği vurgulayan araçlara öncelik verir. Jeff Bezos'un dediği gibi, kim daha fazla ödeme yapmak ve onu elde etmek için daha uzun süre beklemek ister? Aynı ilkeler burada da geçerlidir: Kim daha yavaş ister?
Ayrık bilgi işlem ve depolama: Bu bileşenlerin birbirinden ayrılması, daha fazla esneklik ve ölçeklenebilirlik sunarak seçtiğiniz altyapının, hizmetlerin ve araçların kendi uzmanlık alanlarında mükemmelleşmesini sağlar.
Açık standartlar: Açık standartlar yalnızca birlikte çalışabilirliği teşvik etmekle kalmaz, aynı zamanda yatırımlarınızı geleceğe hazırlar. Bu yalnızca açık kaynaklı çözümleri değil, aynı zamanda inceleyeceğimiz gibi açık tablo biçimlerini de kapsar. Bu nedenlerden dolayı (ve asla bulut yerel olmayacakları gerçeğinden dolayı) bir depolama cihazıyla özel bir bulut oluşturmayın.
RESTful API'lerle uyumluluk: Bağlantılılık şarttır. Araçlarınız ortak bir dili paylaşmalıdır ve S3 bulut depolama için ortak dil olarak hizmet etmelidir. Bu nedenle, S3'ü desteklediğini iddia etse bile özel bulutunuzu POSIX merkezli bir çözümle oluşturmayın. Gerçek olanla devam edin.
Yazılım odaklı/Kod Olarak Altyapı: Altyapınızı otomatikleştirin ve Kubernetes'in düzenlemesini yapmasına izin verin, böylece manuel yönetimin karmaşıklıklarını ortadan kaldırabilir ve hızlı ve etkili ölçeklenebilirliğe olanak tanıyabilirsiniz.
Gelişmiş güvenlik ve uyumluluk: Özel bulutlar özel bir altyapı sağladığı için veriler üzerinde daha fazla kontrol ve gelişmiş güvenlik önlemleri sunar. Bu, finans ve sağlık hizmetleri gibi hassas bilgileri işleyen sektörler için özellikle faydalıdır.
Düzenleyici uyumluluk: Bu mimari, belirli endüstri standartlarını karşılamak için özelleştirilebilir güvenlik ayarları ve denetim kontrolleri sağlayarak düzenleyici uyumluluğu destekleyebilir.
Özel Bulutunuzu Oyuna Sokmak
Özel bulutu aydınlatmak için gördüğümüz bir dizi yaklaşım var. Hepsi işe yarayabilir; bu gerçekten kuruluşa ve kullanım durumuna bağlıdır.
Zaman Sınırlı Hibrit Yaklaşım: Zaman sınırlı hibrit yaklaşım, temelde genel bulutu soğuk depolamaya dönüştürür ve özel bulut ayak izinizi belirli bir zaman diliminde (yıllar değil aylar/çeyrekler) oluşturur. Bu, altyapınızı ve yazılım yığınınızı özel bulutta satın almayı ve yapılandırmayı içerir. Ardından veri hattınızı genel buluta değil, özel buluta yönlendirirsiniz. Her ikisini de yapabileceğiniz bir zaman dilimi olabilir. Ancak amaç, genel bulutu kademeli soğuk depolama ve özel bulutu sıcak depolama olarak kullanmaktır. Zamanla, genel bulut soğuktan dondurulmuşa geçerken özel bulut birincil ve baskın depolama türü haline gelir.
Önde gelen bir siber güvenlik oyuncusunun yaptığı şey budur. MinIO ve Equinix ile birlikte özel bir bulut kurarak başladı, ardından günde 250 tebibayt (TiB) veri hortumunu bu yöne çevirdi. Günlük analitiğinin operasyonel değer açısından yüksek bir bozulma işlevi olduğu göz önüne alındığında, yeni özel bulutun tehdit avlama verilerinin birincil kaynağı olması uzun sürmedi. Bu özel bulut neredeyse bir eksabayta ulaştı (ve yakında bu eşiği geçecek) ve bu iş yüklerini (etkili bir şekilde çekirdek işi) özel bir buluta (capex değil opex ile) taşıma kararı, işin brüt marjını %2'den fazla artırdı. Sonuç olarak, bu şirket akranlarının kıskandığı bir değerleme çarpanına sahip.
Tam Geri Dönüş : Uygulamaları ve verileri hem genel hem de özel bulutta tutmanın bir seçenek olmadığı zamanlar vardır. Bu durumlarda, bulut sağlayıcınızla ilişkinizi kesmeniz gerekir. Bu zordur ve çıkış ücretlerinin ortadan kaldırılmasına rağmen, bunu acı verici hale getirirler (küçük yazılar temelde herhangi bir çıkış ücreti indirimi almak için her şeyin gitmesi gerektiğini söyler). Çok yapılabilir; sadece biraz daha fazla planlama ve biraz daha fazla iş sürtüşmesi gerekir. Bu durumda, colo'nuzu veya özel bulutunuzu ve uygulama yığınınızı sağlayın. Ardından veri kamyonunu yedekleyin veya verileri özel bulut veri altyapınıza hortumla göndermek için ağı kiralayın. Bu noktada özgürsünüz, ancak kemer ve askı tipi biriyseniz bir veya iki ay boyunca iki katı ödeme yapmayı bekleyin. Önde gelen akış şirketlerinden biri, genel buluttan ayrılırken bu yaklaşımı benimsedi. Tüm filmler, şovlar, belgeseller vb. dahil olmak üzere yarım eksabaytlık veriyi yeni özel buluta taşıdı. İşlem yaklaşık üç çeyrek sürdü. Ancak getirisi çok büyüktü ve hizmeti yöneten ekip için karmaşıklık büyük ölçüde azaldı. Ayrıca "güzel bir pop"un yan faydasının da tadını çıkardılar
Greenfield Özel Bulut:
Bu oldukça basit bir önermedir ve genellikle her şeyin yeni olmasını içerir. Proje yenidir, projedeki veriler yeni (veya yeni sayılır) veya çevrimiçi hale gelen bir kaynaktan (örneğin dev bir üretim tesisi veya yeni bir bulut video isteğe bağlı hizmeti) üretilecektir. Burada iş yükünü boyutlandırırsınız - hatta genel bulutta test edebilirsiniz - ancak fikir, başlangıçtan itibaren özel bulutta çalışmasıdır. Bunu AI veri altyapısında oldukça sık görüyoruz. İlk deneyler genel bulutta gerçekleşiyor. Veriler o kadar önemli değil. GPU kullanılabilirliği oldukça iyi. Bununla birlikte, işletme iş yükünün üretim için özel bulutta olması gerektiğini biliyor - hem ölçek hem de güvenlik, gizlilik ve kontrol için. Dünyanın önde gelen otomotiv şirketlerinden biri yakın zamanda tam otonom sürüş girişimini kurallara dayalı bir sistemden gerçek sürücülerin davranışlarına dayalı bir sisteme çevirdi.
Bu davranış, araçlarından gelen milyonlarca ve milyonlarca video ve günlük dosyasından "öğrenilir". İyi sürücüler, kötü sürücüler, ortalama sürücüler. Sadece videodan değil, frenleme, hızlanma, direksiyon torku vb. gibi araç telemetrisinin diğer unsurlarından da. Kurallara dayalı ML yaklaşımı petabaytlarca ölçekteydi; videonun ölçeği ise eksabaytlarcaydı. Şirket bu verileri kimseyle paylaşmıyor (aslında genel bulutlardan ikisinin rekabet eden girişimleri var). Bu AI iş yükü — 300'den fazla sunucuya denk — her zaman özel bir bulut girişimiydi.
Brownfield Özel Bulut:
Burada dürüst olacağız: Bunu görüyoruz, ancak bundan hoşlanmıyoruz. Bu, MinIO'yu katmanlamak için sabit disk sürücülerinde yüksek performanslı iş yüklerini çalıştırmayı da içerir.
Çalışır, ancak nadiren en iyi çözümdür. Ekonomiktir (donanımı yeniden kullanıyorsunuz), düşük sürtünmelidir (tedarik yok) ancak nadiren performanslıdır. Yine de kapsamlı olması için buraya dahil ediyoruz. Önemli bir noktayı gündeme getiriyor. Özel bulutunuzu tasarlarken, senaryolardan herhangi birinde, heterojenliğe plan yapın. Bu bir garantidir ve açıkçası planın bir parçası olmalıdır. Yukarıdaki senaryolardan birinde, donanımın yarısı Supermicro'dan. Diğer yarısı Dell'den. Dünya değiştikçe ve yeni teknoloji mevcut oldukça, yazılımınız umursamamalıdır.
Diğerleri:
Daha az sıklıkta görülen ancak dikkate alınması gereken iki senaryo daha vardır. Biri hibrit patlama yaklaşımı, diğeri ise harici tablolar yaklaşımıdır. Her ikisi de hibrit seçeneğiyle ilgilidir ancak zamanla sınırlı olmayabilir. Hibrit patlama yaklaşımında, ek esneklik için genel buluta sorunsuz bir şekilde genişlemek veya "patlamak" üzere tasarlarken özel bir bulutu korursunuz. Bu strateji genellikle ekstra GPU kapasitesinden yararlanmak veya belirli bulut hizmetlerini kullanmak için benimsenir. Bu modelde, belirli görevler işleme için geçici olarak genel buluta aktarılır. Analiz tamamlandıktan sonra sonuçlar özel buluta geri gönderilir ve genel bulut kaynakları daha sonra devre dışı bırakılır. Bunu kredi riski ve piyasa riski hesaplamalarıyla yapan büyük bir finansal hizmetler müşterimiz var. Bazı hesaplama işlemleri için genel bulutu kullanır ve bunu MinIO ve Dremio kullanan özel bir bulut veri gölüyle birleştirir. Bulut işletim modelinin güzelliği, mimarinin her iki yerdeki işlemleri desteklemesi gerektiğidir. Etkili bir şekilde iki yönlü bir yoldur.
Bir noktada, tek yönlü bir yoldu, ancak dünya değişti ve işletmeler için opsiyonellik var. Harici tablolar seçeneğiyle, kuruluşlar Snowflake ve SQL Server gibi mevcut bulut veri ambarlarını özel bulut üzerine kurulu bir veri gölüyle entegre ederek bulut işletim modelinin ilkelerinden yararlanmaya devam edebilir. Bu hibrit kurulum, işletmelerin bulut altyapısına yapılan mevcut yatırımlardan yararlanırken modern bir veri gölünün performansından, veri güvenliğinden ve açık standart tasarımından faydalanmalarını sağlar. Artık her büyük veritabanı satıcısı harici tablolar için destek sunuyor. Bu işlevsellik, kullanıcıların nesne depolamasındaki verileri, veritabanındaki normal bir tablo gibi, göç etme zahmetine girmeden, nerede olursa olsun sorgulamasına olanak tanır. Verileriniz özel bulutta kalır, ancak ihtiyaç duyulduğu her yerde kullanılabilir hale gelir.
Son Düşünceler ve Tavsiye
Yıllar boyunca bu özel bulut geri dönüşlerinin/yeni yapıların birçoğuna katıldık. Ekipler için sürpriz olan bir şey de donanımı tekrar yönetmek oldu. Bulutta şeffaftır. DevOps ve site güvenilirlik mühendisleri altyapıyla yalnızca API düzeyinde etkileşim kurar. Bir VM sorun çıkarıyorsa sonlandırın ve yerine yenisini başlatın. Ne yazık ki yeni özel bulutta, sadece donanımı hurdaya çıkarıp yenisini satın almak yerine, mevcut donanımı çalışır hale getirmek zorundayız.
Altyapı yönetimi bir şeydir. Bu, işin doğasında vardır. Korkutucu olmamalı, ancak planlanmalıdır. Yazılım mühendisliği/DevOps tarafı ve veri merkezi mühendisi arasında sorumlulukların belirlenmesi gerekir. Veri merkezlerindeki bu KOBİ (konu uzmanı), tüm donanımlar hakkında her şeyi bilmelidir. Arızalar, değiştirmeler ve bakım dahil olmak üzere donanımla ilgili her şeyden sorumlu olacaklardır.
Burada yazılım önemlidir. MinIO'nun küresel konsoluna gözlemlenebilirliği yerleştirmesinin nedeni budur. Özel bulut dünyasında, akıllı yazılımlar ve aptal donanımlar çalıştırıyor olmalısınız. Ancak bu yazılım, bu ekonomik bereketin operasyonel yükünü taşımak zorundadır. Donanım adamları gözlemlenebilirlik katmanını inşa edemediler, MinIO bunu yapmak zorundaydı.
Haftada bir dağıtım yapan bir organizasyonsanız, bu her dağıtımın muhtemelen bir gösteri olduğu anlamına gelir. Bunun nedeni, seyrek dağıtımlarda hataları tahmin etmenin ve düzeltmenin zor olmasıdır. Dağıtımlar planlandığı gibi gitmediğinde, herkes güvertede olur. Genellikle akış aşağıdaki gibi görünür:
Bu CI/CD prensipleri pratikte uygulandığında, güçlü bir veri merkezi mühendisi, güçlü bir DevOps/SRE mühendisiyle yakın bir şekilde çalışarak, özel bir bulut veya kolo tesisinde 5.000'den fazla düğümü kolayca yönetebilir. Tam olarak bunu yapan müşterilerimiz var. CI/CD temel prensiplerini takip ettiğinizde, hemen hemen her şey otomatikleştirilebilir ve otomatikleştirilmelidir ve veri merkezi ve DevOps mühendisleri yalnızca otomatikleştirilemeyen görevlere odaklanacaktır. Son olarak, kaçırmış olmanız durumunda, kololar özel bulut tanımımızla eş anlamlıdır.
Ortak yerleşim, tamamen şirket içi altyapı ile genel bulut arasında bir orta yol sağlar ve her iki dünyanın da avantajlarını sunar. Üst düzey ağlara erişim ve genel bulut sağlayıcılarına yakınlık ile ortak yerleşimler, düşük gecikmeli bağlantıları ve hibrit bulut kurulumlarını kolaylaştırarak verimli veri aktarımı ve işleme olanağı sağlar. Bu esneklik ve başarılı hibrit bulut dağıtımları için potansiyel, operasyonlarını optimize etmeyi ve rekabet avantajını sürdürmeyi hedefleyen işletmeler için hayati önem taşır. Bunun nasıl çalıştığı hakkında daha fazla bilgi edinmek için şuraya göz atın: