Bir uygulamanın tamamını Rust ile yeniden yazmak yerine, Discord'da Staff Engineer olarak görev yapan Lily Mara, en fazla kaynak tüketen işlevlerin Python gibi dinamik bir dilden Rust'a kademeli olarak taşınmasını ve iki uygulamanın aynı işlem içinde birbirine bağlanmasını öneriyor. Mara bu metodolojiyi, Discord kullanıcılarına her gün onlarca milyar bildirim gönderen dağıtık sistemler oluşturma deneyimine ve Refactoring to Rust kitabına dayanarak InfoQ üzerinden yayımlanan bir oturumda sundu.
Temel fikir, Rust daha hızlı olduğu için bir dili başka bir dille değiştirmek değil, iyileştirildiğinde en büyük etkiyi yaratacak dar sistem bölümlerini belirlemektir. Bu yaklaşım, değişikliğin kapsamını küçültmeye, yeni davranışı eski davranışla karşılaştırmalı olarak test etmeye ve sonuçların birebir aynı olmasının zor olduğu durumlarda özgün uygulamayı korumaya olanak tanır.
Tam yeniden yazım neden başlangıç noktası olmamalı?
Mara, eski bir sistemi tamamen daha yeni bir dille yeniden oluşturma hevesinin anlaşılır olduğunu, ancak bunun önemli pratik riskler taşıdığını düşünüyor. Yeniden yazma projeleri teslim tarihlerini aşabilir, beklenenden daha karmaşık hâle gelebilir veya eski sistemin daha önce çözdüğü hataları yeniden ortaya çıkarabilir. Ayrıca eski kod, her zaman yaşı nedeniyle karmaşık değildir; kullanım deneyiminden ve yeni bir projeye aktarılması zor kurumsal bilgiden biriken kısıtlamaları ve ayrıntıları yansıtabilir.
Oturum ayrıca performans sorununu yalnızca programlama diliyle açıklamaya karşı uyarıyor. Yavaşlığın nedeni veritabanı şeması, sorgu ve önbellekleme kalıpları veya hizmet tasarımı olabilir; sorun kod satırının yürütme maliyetinden kaynaklanmayabilir. Bu nedenle Rust'tan yararlanmak, yeniden yazımın mimari darboğazları otomatik olarak çözeceği anlamına gelmez.
FFI üzerinden yeniden yapılandırma nedir?
Metodoloji, Mara'nın FFI refactoring olarak adlandırdığı yaklaşımı kullanıyor: Bir işlevi veya işlevlerin küçük bir bölümünü başka bir dilde yeniden yazmak ve diller arası bağlantı arayüzü üzerinden mevcut uygulamaya bağlamak. Sunulan örnekte Flask uygulaması HTTP isteğini almaya ve JSON kodunu çözmeye devam ediyor; ardından verileri Rust ile yazılmış bir istatistik işlevine gönderiyor, sonuçları Python'a geri aktarıyor ve yanıtı gönderiyor.
Bağlantı, pratikte birçok sistem ve dil arasında ortak dil işlevi gören C arayüzüne dayanıyor. Python durumunda PyO3 projesi, Python'dan içe aktarılabilen bir modül oluşturmak için araçlar sağlıyor; Maturin ise bu modülü derlemek için kullanılabiliyor. pyfunction ve pyclass gibi programlama öznitelikleri, Rust'taki işlevleri ve veri yapılarını Python'dan çağrılabilen arayüzlere dönüştürüyor.
Doğru işlevi seçmek ve etkiyi ölçmek
Deney, çağrı sıklığı yüksek veya çağrı maliyeti fazla olan işlevlerin aranmasını öneriyor. Bir işlev her seferinde görece ucuz olabilir, ancak API işleyicilerinin önünde bulunan doğrulama mantığı gibi her istekle birlikte çalışabilir. Öte yandan nadiren çalışmasına rağmen son derece maliyetli işlemler de bulunabilir. Ölçüt, belirli bir işlevin yavaş göründüğüne dair izlenim değil, işlemci süresi üzerindeki kümülatif etkidir.
İstatistik örneğinde Rust uygulaması, Python üzerinden aynı işlev ölçüldüğünde, uygulamalar Python yorumlayıcısı aracılığıyla çalıştırılmasına rağmen yüz kata biraz yakın daha hızlıydı. Ancak Flask, JSON serileştirme ve serileştirmeden çıkarma işlemlerini içeren tam HTTP işleyicisi ölçüldüğünde iyileşme yalnızca yaklaşık %15 oldu. Özgün işlevin yürütme süresi yaklaşık 86 mikrosaniyeydi; bu tek başına küçük bir süre olsa da geniş ölçekte tekrarlandığında önemli bir maliyete dönüşebilir.
Kısmi ölçüm ile toplam ölçüm arasındaki bu fark, oturumun en önemli derslerinden biridir: İşlevin hızlandığını kaydetmek yeterli değildir; kullanımın gerçek akışını temsil eden ve gerektiğinde ağı, web çerçevesini ve veri serileştirmeyi içeren uçtan uca testler yapılmalıdır.
İşlevsel uyumluluk, testler ve kısıtlamalar
Örneğin yeniden uygulanması, Python'daki istatistik kütüphanesi ile Rust kütüphanesinin sonuçları arasında farklılık olduğunu gösterdi. Kütüphanelerden biri çeyrekleri kesin biçimde hesaplarken diğeri devasa veri kümelerine uygun tahminler kullandı; ayrıca ondalık yuvarlamada küçük farklılıklar ortaya çıktı. Bu nedenle bir kütüphanenin değiştirilmesinin aynı davranışı otomatik olarak koruduğu varsayılmamalıdır.
Birebir uyumluluk gerekliyse başka bir kütüphane aranabilir, özgün algoritma Rust'ta yeniden uygulanabilir veya hassas bölüm Python'da bırakılabilir. İşlev düzeyinde taşımanın yararı, bileşeni ayrı bir hizmete ayırıp yeni ağ iletişimleri ve işletim maliyetleri eklemek yerine, iki dilin aynı işlem içinde birlikte kullanılabilmesidir.
Testler; doğrudan Rust testlerini, Flask işleyicileri için mevcut Python testlerini, iki uygulamanın sonuçlarını karşılaştıran testleri ve uygun olduğunda özellik tabanlı rastgele testleri içerir. Bununla birlikte yerel kod eklemek operasyonel açıdan karmaşıklıklar doğurur: Geliştirme ortamlarının Rust derleyicisine veya işletim sistemi ve mimariyle uyumlu ikililere ihtiyaç duyması, dağıtımın daha karmaşık hâle gelmesi ve yeni hataların ortaya çıkma olasılığı.
Pratikte bu metodoloji, mevcut sistemlerin seçilmiş bölümlerini iyileştirmek için görece düşük riskli bir yol sunar; ancak mimari analiz, uyumluluk testleri ve uçtan uca ölçüm ihtiyacını ortadan kaldırmaz. Gerçek tasarruf, yalnızca izole bir işlev benchmark'ında değil, hizmetin tamamının akışında iyileşme görüldüğünde kanıtlanır.