Sunucu Tarafı WebAssembly ve WASI: Yeni Nesil Hesaplama Katmanı

Ana Sayfa » Python » Sunucu Tarafı WebAssembly ve WASI: Yeni Nesil Hesaplama Katmanı

WebAssembly artık sadece tarayıcıda Doom veya Photoshop çalıştırmak için kullanılan havalı bir yöntem olmaktan çıktı; sessizce sunucu tarafı hesaplama, izolasyon ve taşınabilirlik için en umut vadeden temellerden biri haline geldi. Son birkaç yılda, Wasm ve WASI etrafındaki çalışma ortamları, standartlar ve araçlar o kadar hızlı gelişti ki, birçok mimar artık onu bulut tabanlı platformlar, uç bilişim, ağ geçitleri ve hatta DNS çözümleyicileri için ciddi bir yapı taşı olarak görüyor.

Sunucu tarafındaki Wasm'ı anlamanın, kavramların konteynerler, POSIX, Kubernetes, ağ geçitleri ve düşük seviyeli çalışma ortamları arasında dağılmış olması nedeniyle karmaşık olduğunu düşündüyseniz, yalnız değilsiniz. Bu makalede, genel tabloya göz atacağız: WebAssembly nedir, WASI sunucuda oyunun kurallarını nasıl değiştiriyor, konteynerler ve CRI ile nasıl karşılaştırılıyor ve entegre oluyor, API ağ geçitleri ve büyük DNS çözümleyicileri gibi gerçek projeler üretimde Wasm'ı nasıl kullanıyor ve mevcut sınırlamalar ve gelecekteki yönelimler nelerdir.

Tarayıcı gücünden evrensel düşük seviyeli çalışma zamanı ortamına

Web tarayıcısı, basit bir belge görüntüleyicisinden evrensel bir uygulama platformuna dönüştü ve WebAssembly bunun en önemli nedenlerinden biri. Çok uzun zaman önce, 3D oyunlar, VR/AR veya gelişmiş veri görselleştirme gibi ağır iş yükleri yerel masaüstü uygulamaları gerektiriyordu; bugün, bu deneyimlerin çoğu Wasm sayesinde bir sekme içinde sorunsuz bir şekilde çalışıyor.

WebAssembly, resmi olarak, derleyiciler için taşınabilir bir hedef olarak tasarlanmış, düşük seviyeli, yığın tabanlı bir komut biçimidir; özünde bir derleme diline benzer ancak web ve ötesi için standartlaştırılmıştır. İkili biçimi, tüm modern tarayıcılara yerleştirilmiş bir sanal makine içinde çalışan, kompakt, mimariden bağımsız bir bayt kodunu temsil eder.

Pratik anlamda WebAssembly, C, C++ veya Rust gibi güçlü dilleri alıp, tarafsız bir hedef dil olan C gibi bir dile derlemenizi sağlar. wasm32ve altta yatan işlemcinin x86, x64 veya ARM olmasına bakılmaksızın bir sanal ortamda çalışan küçük, bağımsız bir ikili dosya gönderir. Bu derleme, çalışma zamanına bağlı olarak önceden (AOT) veya tam zamanında (JIT) olabilir.

Tarayıcı içinde, Wasm modülü katı sınırlamalara sahip, korunaklı bir ortamda çalışır: DOM'a veya keyfi sistem kaynaklarına doğrudan müdahale edemez ve JavaScript ile açık bir API aracılığıyla iletişim kurar. Bu nedenle WebAssembly, JavaScript'in doğrudan yerine geçebilecek bir alternatif değil, JS'nin gerektiğinde çağırabileceği, performans açısından kritik kodlar için bir yardımcıdır.

Sanal ortamda çalıştırma, birçok anlık avantaj sağlar: güçlü izolasyon, küçük ikili dosyalar, iyi tanımlanmış içe/dışa aktarma işlemleri ve birçok dilin aynı taşınabilir formata derlendiği çok dilli geliştirme için uygun bir model. Zamanla, ekosistem C/C++/Rust'ın ötesine geçerek Go, Java, Python ve diğer diller için deneysel veya kısmi hedefleri içerecek şekilde büyüdü, ancak olgunluk seviyeleri büyük ölçüde değişiyor.

Güvenlik, taşınabilirlik ve POSIX benzetmesi

Varsayılan olarak, bir WebAssembly modülünün dış dünyaya erişimi yoktur: bellek ve sayılarla işlem yapar ve dosyalar, saatler, soketler veya ağ iletişimiyle ilgili herhangi bir etkileşim, ana bilgisayar tarafından içe aktarmalar yoluyla açıkça izin verilmelidir. Bu "varsayılan olarak reddetme" yaklaşımı, Wasm'ın tarayıcı dışında çekici olmasının ana nedenlerinden biridir.

Bu durum, dosya veya ağ iletişimi gibi yaygın işlemler için farklı sistemlerin biraz farklı arayüzler sunduğu erken Unix dünyasını garip bir şekilde hatırlatıyor. Bu parçalanma, uygulamaları Unix varyantları arasında taşımayı oldukça zorlaştırıyordu.

POSIX, programların birden fazla Unix benzeri çekirdekle iletişim kurmak için tutarlı bir API kullanabilmesi amacıyla standart bir işletim sistemi arayüzü olarak ortaya çıktı. Bir uygulama POSIX'e göre yazıldıktan sonra, her işletim sisteminin kendi iç yapısı olsa bile, onu sistemler arasında taşımak çok daha kolay hale geldi.

Tarayıcı dışında WebAssembly de benzer bir sorunla karşılaştı: bireysel sunucular G/Ç, zaman veya rastgelelik için geçici işlevler sunuyordu, ancak ortak bir sözleşme yoktu. Her çalışma zamanı kendi API'lerini icat edebiliyordu; bu, deneyler için harika, ancak taşınabilirlik açısından berbat bir durumdu.

WASI: WebAssembly Sistem Arayüzü

Bu parçalanmayı gidermek ve WebAssembly'i ciddi bir sunucu tarafı seçeneği haline getirmek için topluluk, WebAssembly Sistem Arayüzü (WASI) adı verilen bir yapı geliştirdi. WASI, Wasm modüllerinin dosyalar, saatler, ağ iletişimi ve diğer temel kaynaklarla taşınabilir bir şekilde etkileşim kurmak için güvenebileceği standartlaştırılmış bir sistem benzeri API kümesi tanımlar.

WASI, CloudABI ve POSIX gibi projelerden etkilenmiştir, ancak yetenek tabanlı güvenlik ve sanal alan oluşturmaya daha güçlü bir şekilde odaklanmıştır. Bir işlemin tüm dosya sistemini veya ağ yığınını görebileceğini varsaymak yerine, bir WASI modülü, tam olarak hangi kaynaklara erişebileceğini açıklayan kesin yetenekler elde eder.

WASI altında, bir WebAssembly modülünün artık tam bir tarayıcı sanal makinesine ihtiyacı yoktur; WASI API'lerini uygulayan ve bunları altta yatan işletim sistemine çeviren hafif bir çalışma zamanı ortamında çalışabilir. Bu çalışma zamanı, uygulamalara gömülebilir, komut satırı arayüzü olarak kullanılabilir veya daha üst düzey platformlara entegre edilebilir.

WASI kasıtlı olarak modülerdir: temel bir dizi ilkel öğe (genellikle "ilkel öğeler" olarak adlandırılır) vardır. wasi-coreDosyalar ve soketler gibi temel işlemler için ve ayrıca aşağıdaki gibi ek öneriler: wasi-nn Sinir ağı iş yükleri veya IoT ve blok zinciri için alana özgü uzantılar için. Bu modüler yapı, farklı platformların yalnızca ihtiyaç duydukları parçaları uygulamalarına olanak tanır.

Wasmtime, Wasmer veya WasmEdge gibi çalışma ortamları, WASI'yi uygular ve taşınabilir Wasm bayt kodu ile ana işlemci talimatları arasında köprü görevi görür. Bunlar, güvenli bir şekilde sanal ortamı uygulamaktan, içe/dışa aktarmaları düzenlemekten ve WASI çağrılarını yerel sistem çağrılarına eşlemekten sorumludur.

Sunucu tarafı WebAssembly neden bu kadar önemli?

Taşınabilir bir bayt koduna, yetenek odaklı bir sistem arayüzüne ve optimize edilmiş çalışma ortamlarına sahip olduğunuzda, şu soruyu sormak doğal hale gelir: WebAssembly, sunucularda ve uç noktalarda genel amaçlı bir hesaplama katmanı haline gelebilir mi? Ekosistemdeki birçok oyuncunun bahse girdiği vizyon tam olarak budur.

Bu alanda en çok alıntı yapılan ifadelerden biri, Docker'ın kurucu ortağı Solomon Hykes'e aitti; Hykes, WASM+WASI 2008'de var olsaydı, Docker'a asla ihtiyaç duyulmayabileceğini iddia etmişti. Temel fikir, sunucudaki Wasm'ın, tam bir konuk işletim sistemi göndermeden konteyner benzeri paketleme ve izolasyon sağlayabilmesidir.

Güvenlik açısından, WASI'nin varsayılan yaklaşımı geleneksel süreç modellerine göre önemli ölçüde daha katıdır. Wasm modülünü çalıştıran bir kullanıcının ana bilgisayarda tam yetkiye sahip olması durumunda bile, modülün kendisi yalnızca önceden belirtilen minimum yetenekleri alır. Uygulamanızın yalnızca dosya okuması gerekiyorsa, kötü amaçlı bir bağımlılık sessizce soket açamaz veya ağ yapılandırmasını yeniden düzenleyemez, çünkü bu yetenekler modülün bakış açısından mevcut değildir.

Taşınabilirlik açısından bakıldığında, Wasm ikili dosyaları aşağıdaki gibi hedefler için derlenmiştir: wasm32-wasi Uyumlu bir çalışma ortamı mevcut olduğu sürece, Linux, Windows, macOS ve farklı CPU mimarilerinde değişiklik yapılmadan çalışabilir. Bu, farklı mimariler için farklı imajlar gerektiren konteynerlere kıyasla, uzun zamandır vaat edilen "bir kez derle, her yerde çalıştır" ilkesine daha yakın.

Performans da oldukça etkileyici: Tüm konuk işletim sistemlerini ortadan kaldırıp kompakt bir bayt kodu için yapı oluşturarak, Wasm iş yükleri geleneksel konteynerlere kıyasla çok daha hızlı başlatma süreleriyle neredeyse yerel hıza ulaşabiliyor. Gecikmeye duyarlı veya kısa ömürlü iş yükleri için, soğuk başlatma süresi önemli bir fark yaratıyor.

Wasm ve konteynerler: düşman değil, dost.

İlk bakışta, sunucu tarafı WebAssembly, konteynerlerin doğrudan rakibi gibi görünüyor: her ikisi de kodu ve bağımlılıkları paketlemenin ve bunları bir sunucuda izole bir şekilde çalıştırmanın yollarıdır. Ancak pratikte, ilişki düşmanca olmaktan çok simbiyotiktir.

Günümüzün konteyner ekosistemi, Docker, containerd ve Açık Konteyner Girişimi (OCI) imaj formatı gibi araçlar etrafında şekillenmektedir. Containerd gibi üst düzey çalışma ortamları, konteynerleri yönetmek için standart bir API sunarken (çalıştır, öldür, yürüt, günlükler), alt düzey işleri "gerçek" çalışma ortamlarına devreder. runc, crun or youki.

Bu yapıda, genellikle genel containerd çağrılarını düşük seviyeli çalışma zamanı tarafından anlaşılan özel talimatlara çeviren bir ara katman bulunur. WebAssembly hikayesi burada ilginçleşiyor: eğer bir ara katman bir Wasm modülünü normal bir konteyner gibi sunabiliyorsa, üst düzey araçların aradaki farkı bilmesine gerek kalmaz.

Gibi projeler runwasi Tam olarak bunu yapıyorlar: WasmEdge gibi bir Wasm çalışma ortamıyla iletişim kuran bir ara katman kullanarak containerd'in Wasm modüllerini OCI konteynerleriymiş gibi başlatmasına olanak tanıyorlar. runc. Containerd açısından bakıldığında, bu hala sadece bir "konteyner" başlatmak anlamına geliyor; arka planda ise Wasm modülü yükleniyor ve WASI ile çalıştırılıyor.

Bu ustaca yöntem, "konteynerler olmadan konteynerler" oluşturmayı mümkün kılar: Orkestrasyon katmanı, günlük kaydı altyapısı ve araçlar geleneksel konteynerlerle uğraştıklarını düşünürken, gerçek iş yükü, tam bir konuk işletim sistemine ihtiyaç duymayan hafif bir Wasm ikili dosyasıdır. Aynı komutlar (run, exec, logsAynı Kubernetes mekanizması (RuntimeClass, dağıtımlar) yeniden kullanılabilir.

Wasm için birleşik çalışma ortamları: crun, youki ve OCI imajları.

Runwasi gibi yardımcı araçlar güçlü olsa da, birden fazla çalışma ortamı ve yardımcı araç ikili dosyasını kurup bakımını yapmanız gerektiği için kurulumu da karmaşıklaştırırlar. Bu durum, çalışma ortamı yapılandırmasının kolay olmadığı Kubernetes gibi orkestrasyonlu ortamlarda özellikle zahmetli hale gelir.

Yeni düşük seviyeli çalışma zamanı ortamları gibi crun (Red Hat) ve youki (Rust tabanlı) farklı bir yaklaşım benimsiyorlar: hem geleneksel konteynerleri hem de Wasm modüllerini doğrudan OCI çalışma ortamları olarak desteklemeyi amaçlıyorlar. Ayrı shim ikili dosyalarına ihtiyaç duymak yerine, tam bir konteyner başlatıp başlatmayacaklarına veya bir Wasm modülünü çıkarıp çalıştıracaklarına karar vermek için OCI görüntülerindeki ek açıklamaları incelerler.

Bu modelle, bir Wasm "konteyner imajı" oluşturmak, modülünüzü derlemek kadar basittir. wasm32-wasiyerleştirme .wasm minimal bir OCI görüntüsündeki dosya (genellikle) FROM scratch), ve bunun bir Wasm iş yükü olduğunu belirtmek için doğru açıklamayı eklemek. Gibi araçlar buildah Ya da Docker, bu imajları diğerleri gibi oluşturup dağıtabilir.

Sonuç olarak, containerd'in tek bir OCI çalışma ortamıyla iletişim kurduğu ve bu çalışma ortamının her bir imajı nasıl çalıştıracağını şeffaf bir şekilde seçtiği çok daha temiz bir yapı elde edilir. Bu, operatörler için zihinsel yükü azaltırken; geliştiriciler için Wasm iş yüklerinin mevcut işlem hatlarına, kayıt defterlerine ve dağıtım akışlarına entegre olmasını sağlar.

Pratik faydaları küçümsenemez: Wasm imajları genellikle konteyner imajlarından çok daha küçüktür, bu da aktarım sürelerini ve depolama ihtiyaçlarını önemli ölçüde azaltır. VMware'in Wasm Laboratuvarlarından bir örnek karşılaştırmada, bir Python konteyner imajının 1 GB'ın üzerinde olduğu, Wasm tabanlı bir Python imajının ise yaklaşık 6.8 MB olduğu belirtilmiştir; başka bir deyişle, IoT, uç düğümler ve bant genişliği kısıtlı ortamlar için son derece önemli olan, kat kat büyük bir fark söz konusudur.

API ağ geçitlerinde sunucu tarafı Wasm: APISIX örneği

API ağ geçitleri, gecikme ve izolasyonun kritik olduğu durumlarda programlanabilir aracı görevi gördükleri için sunucu tarafı WebAssembly için doğal bir uyum sağlar. Apache APISIX, Wasm'ın bu tür sistemlere nasıl entegre edilebileceğine dair somut, üretim kalitesinde bir örnek sunmaktadır.

Geleneksel olarak, APISIX eklenti ekosistemini Lua etrafında kurmuş ve OpenResty ile NGINX'in esnekliğinden yararlanmıştır. Lua eklentileri doğrudan ağ geçidi içinde çalışır; bu güçlü bir yapıdır ancak bazı endişeleri de beraberinde getirir: paylaşılan küresel durum, hatalı çalışan bir eklentinin diğerlerini etkileme riski ve rastgele komut dosyası kodunun ana ağ geçidiyle aynı adres alanında çalıştırılması durumunda ortaya çıkan güvenlik sınırlamaları.

WebAssembly eklentilerine destek ekleyerek, bu eklentilerin uyumlu olmasını sağlayan proxy-wasm ABI ve APISIX, geliştiricilerin güçlü bir sanal alan (sandboxing) yapısını koruyarak C++, Go ve Rust gibi üst düzey dillerde uzantılar yazmalarına olanak tanır. Aslen Envoy tarafından tanıtılan proxy-Wasm spesifikasyonu, eklentilerin HTTP istek başlıkları, gövdeleri, son kısımları ve yanıtları gibi olaylara müdahale edebilmesi için L4/L7 proxy'leri için istikrarlı bir ABI tanımlar.

APISIX, arka planda şuna dayanıyor: wasm-nginx-module NGINX ve Lua üzerinde proxy-Wasm ABI'yi uygulayan bir yapı. APISIX belirli bir aşamaya (örneğin, erişim aşamasına) girdiğinde, Lua fonksiyonlarını çağırır ve bu fonksiyonlar da sırasıyla aşağıdaki gibi C fonksiyonlarını çağırır: ngx_http_wasm_on_httpBu, fazı proxy-Wasm geri çağırma işlevlerine eşleyen bir yapıdır. proxy_on_http_request_headers or proxy_on_http_response_body.

Bu geri çağırma işlevleri daha sonra genellikle Wasmtime veya WasmEdge olan bir Wasm sanal makinesi içinde yürütülür ve ABI tarafından izin verilen sınırlar dahilinde istekleri ve yanıtları inceleyebilir veya değiştirebilir. Bir eklenti çökerse veya yanlış çalışırsa, tüm ağ geçidi sürecini çökertmek yerine, izole edilmiş bir sanal makine örneği içinde bunu yapar.

Geliştirici açısından bakıldığında, böyle bir eklenti oluşturmak, Go kodu yazmayı gerektirebilir. proxy-wasm-go-sdkonu derleyerek .wasm Go'nun yerel WASI desteği henüz tamamlanmadığı için dosyayı TinyGo ile oluşturup, APISIX'i bu modülü yükleyecek şekilde yapılandırıp, ardından bir rotaya eklemek gerekiyor. Etkinleştirildikten sonra, eklenti hata enjeksiyonundan veya özel kimlik doğrulamasından anlık yanıt yeniden yazmaya kadar her şeyi yapabilir.

Wasm VM'leri ve Wasmtime ile WasmEdge'in rolü

WebAssembly'nin sunucu tarafı dağıtımları, Wasm'ı çalıştırabilen ve WASI'yi güvenli ve verimli bir şekilde uygulayabilen özel sanal makinelere büyük ölçüde bağlıdır. En yaygın kullanılanlardan ikisi Wasmtime ve WasmEdge'dir.

Bytecode Alliance tarafından geliştirilen Wasmtime, WebAssembly ve WASI için hızlı, güvenli ve gömülebilir bir çalışma ortamı olmayı hedeflemektedir. Komut satırı aracı olarak kullanılabilir veya diğer sistemlere kütüphane olarak entegre edilebilir ve genellikle genel amaçlı iş yükleri veya referans uygulama olarak tercih edilir.

WasmEdge ise bunun aksine, uç ve bulut tabanlı ortamlar için hafif, yüksek performanslı yürütmeye odaklanır. Hızlı başlatma ve düşük bellek kullanımı için optimize edilmiştir; bu da onu, birçok kısa ömürlü örneğin yaygın olduğu mikro hizmetler, sunucusuz platformlar ve ağ geçitleri için ideal bir çözüm haline getirir.

APISIX senaryosunda, wasm-nginx-module Yürütmeyi bu sanal makinelerden birine devreder; modül derlenmiş dosyayı yükler. .wasm Dosyayı belleğe kaydeder ve proxy-Wasm ABI'sine göre ana bilgisayar işlevlerini (örneğin, başlık dosyalarına erişmek veya günlük yazmak için) kullanıma sunar. Sanal makine WASI'yi uyguladığı için, aynı eklenti prensip olarak aynı arayüzü tanıyan diğer sunucularda da çalışabilir.

BigPineapple: Cloudflare'ın 1.1.1.1 çözümleyicisinde WebAssembly

Cloudflare başlangıçta, HTTPS üzerinden DNS, günlük kaydı, BPF tabanlı saldırı önleme ve önbellek paylaşımı gibi özellikler eklemek için Lua tabanlı bir eklenti modeliyle Knot Resolver'ı kullandı. Bu esneklik başlangıçta harikaydı, ancak birkaç sorunla karşılaştı: geri çağırma işlevleri içindeki engelleme yapan G/Ç işlemleri tek olay döngüsünü durdurabiliyordu, önbellek kullanımı büyük ölçekte verimsizdi ve tüm eklentiler tek bir Lua durumunu paylaşıyordu, bu da izolasyonu ve hata ayıklamayı zorlaştırıyordu.

Trafik arttıkça, ekip engelleme görevlerini düzgün bir şekilde ele alan, birçok çekirdekte ölçeklenebilen ve uzantılar arasında daha iyi izolasyon sağlayan bir tasarıma ihtiyaç duydu. İlk olarak Knot Resolver'ı bir Rust servisiyle sarmaladılar ve sonunda özyinelemeli çekirdeği, Rust'ın async/await sözdizimini kullanarak karmaşık akışları okunabilir bir şekilde ifade eden, Tokio üzerine kurulu yeni bir asenkron mimariyle değiştirdiler.

Yeni tasarım, sorumlulukların net bir şekilde ayrılmasını sağladı: bir sunucu bileşeni istemci sorgularını alır ve bunları tek tip çerçevelere dönüştürür; işçi görevleri çözümlemeyi ele alır; bir önbellek modülü ARC tarzı bir değiştirme algoritması kullanır; bir özyinelemeli kütüphane DNS özyineleme mantığını yönetir; bir iletken yetkili sunuculara giden trafiği yönetir; ve bir sanal alan modülü takılabilir uzantıları barındırır.

Bu çerçevede, WebAssembly'nin devreye girdiği yer sanal ortamdır. BigPineapple, Lua'yı doğrudan ana işleme yerleştirmek yerine, eklentileri Wasmer çalışma zamanını kullanarak Wasm modülleri olarak çalıştırır. Her modül, özel belleğe sahip kendi izole edilmiş örneğinde çalışır ve ana bilgisayar, modüllerin DNS mesajları, ölçümler ve diğer kaynaklarla etkileşim kurmak için çağırabileceği bir dizi işlevi dışa aktarır.

BigPineapple'da Asenkron G/Ç, Önbellekleme ve Giden Trafik

BigPineapple mimarisi, asenkron Rust ve dikkatli kaynak yönetiminin WebAssembly'i nasıl tamamladığını göstermektedir. Gelen tarafta, bir sunucu bileşeni birden fazla arayüz ve protokolde (UDP, TCP, DoH, vb.) dinleme yapar ve gelen her mesajı meta verilerle soyut bir "çerçeve" gösterimine sarar.

Bu çerçeveler, çalışanların bir kuyruktan alıp özyinelemeli kütüphaneyi kullanarak eş zamanlı olarak çözdüğü asenkron görevlere dönüştürülür. Bu, yavaş bir geri çağırma işleminin diğer tüm trafiği engelleyeceği klasik olay döngüsü sorununu önler.

Önbellek, düz bir anahtar-değer deposu yerine uyarlanabilir değiştirme önbelleği (ARC) tasarımını kullanır; popüler girdileri korurken daha az kullanışlı olanları silmek için güncelliği ve sıklığı izler. Bu, bazı önceki yaklaşımların "dolduğunda her şeyi sil" davranışından kaçınır ve bölge numaralandırması gibi kötüye kullanım kalıplarını daha sorunsuz bir şekilde ele alır.

BigPineapple, daha önce senkronize önbellek boşaltmalarına ve gecikme artışlarına yol açan, veri merkezindeki tüm düğümlere körü körüne önbellek girdilerini çoklu yayınlamak yerine, aynı etki alanı için sorguları düğümlerin bir alt kümesine yönlendirmek için tutarlı karma algoritması kullanır. Bu düğümler, benzer trafiğe hizmet ederek önbellek durumunu dolaylı olarak paylaşır, isabet oranlarını artırır ve yukarı akış yetkili sunucuları üzerindeki yükü azaltır.

Giden tarafta, bir iletken modülü, yukarı akış DNS sunucularına olan bağlantıları yönetir ve gidiş-dönüş süresi, hizmet kalitesi ve paket kaybı gibi ölçütleri izler. Aynı soru için eş zamanlı yukarı akış sorgularını tekrarlardan arındırır, en iyi taşıma ve yönlendirme yöntemini (faydalı olduğunda Argo Akıllı Yönlendirme dahil) seçer ve gerektiğinde akıllıca yeniden deneme yapar.

DNS'te izolasyon sınırı olarak WebAssembly

BigPineapple'ın eklenti sistemi, güvenilmeyen veya deneysel kod etrafında bir izolasyon sınırı olarak sunucu tarafı Wasm'ın kullanımına dair ders niteliğinde bir örnektir. Eklentileri çözümleyiciyle aynı bellek alanında çalıştırmak yerine, her Wasm uygulaması izole edilmiş bir alanda çalıştırılır: yalnızca kendi doğrusal belleğine ve açıkça belirtilen sunucu çağrılarına erişebilir.

Ana bilgisayarın bakış açısından, süreçlere göre işletim sistemi çekirdeğine benzer bir rol oynar: kaynakları yönetir, zamanlamayı kontrol eder ve sistem çağrı yüzeyini tanımlar. Modülün bakış açısından ise, yalnızca bazı içe aktarılmış fonksiyonlara ve bir başlangıç ​​giriş noktasına sahip bir programdır.

Ana bilgisayar/konuk sınırı, bellek erişimlerini engelleyen, geçersiz işlemleri yakalayan ve tüm içe/dışa aktarmaları düzenleyen WebAssembly çalışma zamanı (bu durumda Wasmer) tarafından uygulanır. Ana bilgisayar, konuğun DNS mesajlarını okumak, günlükleri yaymak, ölçümleri yayınlamak veya iyi tanımlanmış sınırlar içinde soketleri açmak için kullanabileceği "ana bilgisayar çağrıları" (sistem çağrılarına benzer) sunar .

Öte yandan, ana makine, konuk makine içindeki bazı işlevleri de bilir; bunlara bazen "trambolinler" denir. Bu trambolinler, konuk makinenin belleğinde depolanan geri çağırma işlevlerini veya kapatmaları ana makine tarafından çağırmayı mümkün kılar; bu da aşamaya özgü kancalar (önceki önbellek, sonraki önbellek, önceki yanıt vb.) gibi özellikler için çok önemlidir.

Asenkron davranışı yönetmek için platform, Rust'ın Future soyutlamasını ana bilgisayar çağrılarına eşler: bir konuk modülü, ana bilgisayar çağrısı aracılığıyla G/Ç isteğinde bulunabilir ve ana bilgisayar, G/Ç tamamlandığında ilgili görevin devam etmesi için bir uyandırıcı kaydeder. Bu, karmaşık eklentilerin ana çözümleyici döngüsünü dondurmadan engellemeyen işlemler gerçekleştirmesine olanak tanır.

Wasm izolasyonunun maliyetleri ve çözüm yolları

Tüm bu izolasyon bedelsiz değil; WebAssembly, platform tasarımcılarının dikkatlice yönetmesi gereken bazı ek yükler getiriyor. Konuk sistemler ana bilgisayar belleğini doğrudan okuyamadığı için, verilerin konuk bellek bölgelerine kopyalanması veya eşlenmesi gerekir ki bu da yüksek işlem hacmine sahip sistemler için maliyetli olabilir.

BigPineapple, konuk adres alanında büyük bellek bölgelerini önceden ayırarak ve paylaşılan belleği bu boşluklara eşleyerek bu sorunu hafifletir. Ana bilgisayar bu eşlemeyi düzenledikten sonra, konuk kodu paylaşılan verileri tekrarlanan kopyalamaya gerek kalmadan okuyabilir ve bu da istek başına ek yükü önemli ölçüde azaltır.

Bir diğer zorluk ise kriptografidir: günümüzün temel WebAssembly komut seti, AES veya SHA-2 gibi algoritmalar için donanım hızlandırmalı temel öğeleri içermemektedir. WASI-crypto gibi projeler, ana bilgisayar donanımından yararlanabilen taşınabilir bir kripto arayüzünü standartlaştırmayı amaçlamaktadır, ancak bu tür standartlar tamamen kullanılabilir ve yaygın olarak uygulanana kadar, platformlar genellikle kripto ağırlıklı işleri ana bilgisayara geri devretmektedir.

Cloudflare, istemci sorgularını şifresini çözmesi, işlemesi ve ardından yanıtları şifrelemesi gereken bir çözümleyici olan Oblivious DoH (oDoH) ile bu sorunla karşılaştı. Hibrit açık anahtar şifrelemesini (HPKE) tamamen Wasm'da uygulamak verimsiz olacağından, HPKE'yi sunucu çağrılarına devrettiler ve tamamen Wasm uygulamasına kıyasla 4 kata kadar performans artışı gözlemlediler.

Dil desteği: Rust/C/C++ için güçlü, diğerleri için daha zayıf.

Sunucu tarafında çalışan Wasm'ın olgunluğu büyük ölçüde kaynak dile ve onun ekosistemine bağlıdır. Rust ve C/C++ gibi sistem dilleri için destek nispeten sağlamdır: araç zincirleri nasıl hedefleyeceklerini bilirler. wasm32-wasiAyrıca birçok standart kütüphane ya doğrudan kullanıma hazır halde gelir ya da iyi bir şekilde bakımı yapılmış uyumluluk dosyalarına sahiptir.

Java, Python veya JavaScript gibi üst düzey diller için durum daha karmaşık. Standart kütüphaneler genellikle işletim sistemi özelliklerine veya JIT derleyicilerine doğrudan erişim varsayar; bu da mevcut Wasm çalışma ortamlarına tam olarak uymamaktadır. Bellek yönetimi, yansıma, iş parçacığı modelleri ve FFI'nin hepsi engeller oluşturabilir.

Bununla birlikte, önemli bir ivme söz konusu: CPython projesi, temel standart kütüphaneyi destekleyen bir WebAssembly derlemesi üretmek için özel bir çaba sarf ediyor ve VMware'in Wasm Labs'ı, Wasm'a derlenmiş Python yorumlayıcısını içeren küçük OCI imajları sağlıyor. Bu imajlar, geleneksel Python konteynerlerinden çok daha küçük olup, bu erken aşamada bile açık avantajlar gösteriyor.

Yapay zeka ve Nesnelerin İnterneti'nde popüler olan diller de dahil olmak üzere birçok başka dil için de benzer girişimler mevcut; WasmEdge gibi projeler, makine öğrenimi çıkarımı ve uç nokta tabanlı iş yükleri için özellikler geliştiriyor. Bağlantıların ekosistemi (örneğin, Python üzerinden Wasm modüllerini çalıştırmak) wasmer-python) aynı zamanda hızla genişliyor.

Gerçek dünyadaki faydaları ve mevcut sınırlamaları

WASI, konteyner entegrasyonu, API ağ geçitleri, DNS çözümleyicileri ve dil çalışma ortamları gibi tüm bu parçaları bir araya getirdiğinizde, sunucu tarafı WebAssembly'nin avantajları çok açık bir şekilde ortaya çıkıyor. Daha küçük imajlar dağıtımı hızlandırıyor ve uç nokta ve IoT senaryolarını mümkün kılıyor; neredeyse yerel performans ve mikrosaniye düzeyinde başlatma süreleri, olay odaklı ve sunucusuz iş yükleri için kapıları açıyor; güçlü sanal alan (sandboxing) yapısı, yığın genelinde daha güvenli çok kiracılı bilgi işlem olanağı sağlıyor.

Aynı zamanda, en son teknolojiyi abartmamak da önemlidir: sunucu tarafı Wasm hala genç ve konteynerler veya sanal makineler için evrensel bir alternatif değil. Birçok üretim düzeyindeki senaryo, olgun Wasm desteğine sahip dillerle sınırlıdır ve hata ayıklama, gözlemlenebilirlik ve performans profilleme araçları hala geliştirilme aşamasındadır.

Çöp toplama mekanizmasına sahip bellek, daha zengin iş parçacığı modelleri ve birinci sınıf şifreleme gibi özellikler WebAssembly standart gruplarında aktif olarak geliştirilmekte ancak henüz evrensel olarak kullanıma sunulmamıştır. Bu durum, gelişmiş çöp toplama veya eşzamanlılık özelliklerine bağımlı dil çalışma ortamları için işleri zorlaştırabilir.

Bu çekincelere rağmen, bulut sağlayıcıları, konteyner platformları, tarayıcı üreticileri ve altyapı şirketleri gibi büyük oyuncuların yaptığı yatırım düzeyi, sunucu tarafı Wasm ve WASI'nin konteynerlere tamamlayıcı olarak ve güvenli, taşınabilir bilgi işlem için yeni bir temel olarak giderek daha fazla önem kazanacağını güçlü bir şekilde göstermektedir. Ağ geçitleri, uç bilgi işlem, DNS ve eklenti sistemleri gibi alanlardaki erken benimseyenler, teknolojinin zorlu, yüksek trafikli ortamlar için yeterince sağlam olduğunu zaten kanıtlamaktadır.

Wasm'a derlenmiş içerik platformlarından, APISIX gibi bulut tabanlı ağ geçitlerine ve Cloudflare'ın 1.1.1.1 sürümü gibi internet ölçekli çözümleyicilere kadar uzanan kullanım örneklerine baktığımızda, WebAssembly'nin bir tarayıcı merakından sunucu tarafı ve uç bilişimin geleceği için ciddi bir rakip haline ne kadar hızlı bir şekilde geldiğini ve gelişmek ve olgunlaşmak için hala bolca alanı olduğunu göz ardı etmek zor.