Sanallaştırma ve Konteynerizasyon: Derin Teknik Bir Karşılaştırma

Sanallaştırma ve konteynerizasyon, paylaşılan fiziksel donanım üzerinde birden fazla izole iş yükü çalıştırmanıza olanak tanıyan altyapı soyutlama teknolojileridir; ancak yığının temelden farklı katmanlarında çalışırlar. Sanallaştırma, bir hipervizör aracılığıyla eksiksiz donanım ortamlarını taklit ederek her iş yüküne kendi işletim sistemi çekirdeğini verir. Konteynerizasyon, bir uygulamayı ve bağımlılıklarını, Linux ad alanlarını ve cgroup’ları izolasyon için kullanarak ana bilgisayar işletim sistemi çekirdeğini paylaşan taşınabilir bir birim içinde paketler.

Aralarında seçim yapmak bir tercih meselesi değildir — güvenlik duruşu, kaynak yoğunluğu, başlatma gecikmesi, taşınabilirlik ve operasyonel karmaşıklık üzerinde doğrudan sonuçları olan mimari bir karardır. Bu kılavuz, her iki teknolojiyi teknik düzeyde ele alır, gerçek dünya uç durumlarını kapsar ve doğru kararı vermeniz için somut bir çerçeve sunar.

Sanallaştırma Nedir?

Sanallaştırma, fiziksel donanımı birden fazla bağımsız Sanal Makineye (VM) soyutlar. Her VM, hipervizör adı verilen bir yazılım katmanının üzerinde çalışan tam bir işletim sistemi yığını — çekirdek, sistem kütüphaneleri ve uygulama ikilileri — içerir. Misafir işletim sisteminin bakış açısından, diğer VM’lerle fiziksel kaynakları paylaşıyor olsa bile özel donanım üzerinde çalışıyor gibi görünür.

Hipervizör Nasıl Çalışır?

Hipervizör, misafir VM’lerden gelen donanım talimatlarını yakalar ve bunları ya doğrudan CPU üzerinde çalıştırır (Intel VT-x veya AMD-V aracılığıyla donanım destekli sanallaştırma ile) ya da yazılımda çevirir. VM’ler arasında katı bellek, CPU ve G/Ç sınırları uygular; bu nedenle bir VM’deki çekirdek paniği diğerine yayılamaz.

İki hipervizör mimarisi vardır:

Tip 1 — Bare-Metal Hipervizör

Araya giren bir ana bilgisayar işletim sistemi olmaksızın doğrudan fiziksel donanım üzerinde çalışır. Bu, tüm bir yazılım katmanını ortadan kaldırarak daha düşük gecikme ve daha yüksek verim sağlar. Örnekler: VMware ESXi, Microsoft Hyper-V, Xen, KVM (özel bir ana bilgisayarda çekirdek modülü olarak kullanıldığında).

Tip 2 — Barındırılan Hipervizör

Geleneksel bir işletim sistemi içinde süreç olarak çalışır. Ana bilgisayar işletim sistemi donanım erişimine aracılık ederek ek yük ekler. Geliştirici iş istasyonları için uygundur, üretim altyapısı için değil. Örnekler: Oracle VirtualBox, VMware Workstation, Parallels Desktop.

KVM (Kernel-based Virtual Machine) özel bir ilgiyi hak eder: Linux çekirdeğinin kendisini bir hipervizöre dönüştürdüğü için teknik olarak Tip 1 hipervizördür, ancak genellikle genel amaçlı bir Linux ana bilgisayarında dağıtılır ve bu da sınıflandırmayı bulanıklaştırır. KVM, bulut altyapısında baskın hipervizördür.

Sanallaştırmanın Temel Faydaları

• Güçlü izolasyon sınırı: Her VM’nin kendi çekirdeği vardır. Ele geçirilmiş bir konteyner potansiyel olarak ana bilgisayara kaçabilir; ele geçirilmiş bir VM, hipervizörün donanım tarafından zorlanan sınırı içinde tutulur.
• İşletim sistemi heterojenliği: Aynı fiziksel ana bilgisayarda aynı anda Windows Server 2019, Ubuntu 22.04 ve CentOS 7 çalıştırın.
• Öngörülebilir kaynak tahsisi: CPU sabitleme, NUMA’ya duyarlı bellek tahsisi ve özel depolama G/Ç kuyrukları, VM’lere belirleyici performans sağlar — gecikmeye duyarlı iş yükleri için kritiktir.
• Anlık görüntü ve canlı geçiş: Hipervizörler, tam VM durumunun atomik anlık görüntülerini ve fiziksel ana bilgisayarlar arasında neredeyse sıfır kesinti süresiyle canlı geçişi destekler.
• Eski iş yükü desteği: Belirli çekirdek sürümlerine, çekirdek modüllerine veya donanım sürücülerine bağımlı uygulamalar, bir VM içinde değiştirilmeden çalışabilir.

Sanallaştırma Kullanım Durumları

• Sunucu konsolidasyonu: Düşük kullanımlı düzinelerce fiziksel sunucuyu, daha az sayıda yüksek yoğunluklu ana bilgisayardaki VM’lerle değiştirin.
• Eski uygulama barındırma: Kullanım ömrü sona ermiş işletim sistemi sürümlerini (Windows Server 2003, RHEL 5) ağa maruz bırakmadan izole ortamda çalıştırın.
• Çok kiracılı bulut altyapısı: Genel bulut sağlayıcıları, müşteri iş yükleri arasında sert izolasyon uygulamak için hipervizörler kullanır. Bir VPS Hosting ortamı çalıştırıyorsanız, temel teknoloji neredeyse kesinlikle KVM veya Xen’dir.
• Güvenliğe duyarlı iş yükleri: PCI-DSS, HIPAA veya SOC 2 uyumluluğu gerektiren ortamlar, genellikle iş yükü katmanları arasında VM düzeyinde izolasyonu zorunlu kılar.
• GPU hızlandırmalı hesaplama: Donanım geçişi (PCIe passthrough / SR-IOV), bir VM’nin fiziksel bir GPU’nun doğrudan sahipliğini almasına olanak tanır — GPU Hosting platformlarının temelidir.

Konteynerizasyon Nedir?

Konteynerizasyon, bir uygulamayı çalışma zamanı bağımlılıklarıyla birlikte — kütüphaneler, yapılandırma dosyaları, ortam değişkenleri — konteyner imajı adı verilen bağımsız, çalıştırılabilir bir birim içinde paketler. Bir konteyner çalıştığında, ana bilgisayar işletim sistemi çekirdeğini paylaşır ancak Linux çekirdek ilkellerini kullanarak diğer süreçlerden izole edilir.

Konteynerlerin Arkasındaki Çekirdek İlkelleri

Konteynerler tek bir teknoloji değildir — birkaç Linux çekirdek özelliğinin bir bileşimidir:

• Ad alanları (Namespaces): Süreç düzeyinde izolasyon sağlar. Sekiz ad alanı türü vardır: pid (süreç kimlikleri), net (ağ yığını), mnt (dosya sistemi bağlama noktaları), uts (ana bilgisayar adı), ipc (süreçler arası iletişim), user (UID/GID eşlemesi), cgroup ve time. Her konteyner kendi ad alanı örneklerini alır, böylece diğer ad alanlarındaki süreçleri göremez veya onlarla etkileşime giremez.
• cgroup’lar (Kontrol Grupları): Süreç grubu düzeyinde kaynak sınırlarını — CPU payları, bellek sınırları, blok G/Ç bant genişliği ve ağ önceliği — uygular. cgroup’lar olmadan, tek bir konteyner tüm ana bilgisayar CPU’sunu veya belleğini tüketebilir.
• Birleşik dosya sistemleri (OverlayFS): Konteyner imajları katmanlar halinde oluşturulur. OverlayFS, salt okunur imaj katmanlarını üst üste koyar ve her çalışan konteyner için üstüne ince bir okuma-yazma katmanı ekler. Bu, konteynerler arasında imaj paylaşımını mümkün kılar ve disk alanı kullanımını önemli ölçüde azaltır.
• Seccomp ve AppArmor/SELinux: Bir konteyner sürecinin yapabileceği sistem çağrılarını kısıtlayarak çekirdek saldırı yüzeyini azaltır.

Konteyner Çalışma Zamanları ve OCI Standardı

Open Container Initiative (OCI), konteyner imaj formatları ve çalışma zamanları için taşınabilir standartlar tanımlar. Bu, Docker ile oluşturulan bir imajın değişiklik yapılmadan containerd, Podman veya cri-o ile çalıştırılabileceği anlamına gelir.

• Docker: En yaygın kullanılan geliştirici odaklı araç zinciri. Docker Engine, düşük seviyeli çalışma zamanı olarak containerd kullanır.
• containerd: Kubernetes tarafından doğrudan kullanılan, CNCF mezunu bir çalışma zamanı. Tam Docker daemon’ından daha yalındır.
• Podman: Docker’a daemon’sız, rootless bir alternatif. Her konteyner, çağıran kullanıcının alt süreci olarak çalışır ve Docker daemon’ını kök ayrıcalıklı bir saldırı yüzeyi olmaktan çıkarır.
• cri-o: Kubernetes için özel olarak tasarlanmış minimal OCI uyumlu bir çalışma zamanı.

Konteynerizasyonun Temel Faydaları

• Başlatma hızı: Bir konteyner milisaniyeler içinde başlar çünkü işletim sistemi önyükleme sırası yoktur — çekirdek zaten çalışmaktadır.
• İmaj taşınabilirliği: Bir konteyner imajı tam çalışma zamanı ortamını kapsar. “Benim makinemde çalışıyor” sorunu çözülmüş olur.
• Kaynak yoğunluğu: Konteynerler çekirdeği paylaştığından, yalnızca onlarca VM’yi destekleyecek donanımda yüzlerce konteyner çalıştırabilirsiniz.
• Değişmez altyapı: Konteyner imajları sürümlüdür ve değişmezdir. Geri alma, önceki imaj etiketini dağıtmak kadar basittir.
• Ekosistem entegrasyonu: Konteynerler, Kubernetes, Docker Swarm, Nomad ve her büyük CI/CD platformu için yerel dağıtım birimidir.

Konteynerizasyon Kullanım Durumları

• Mikro hizmet mimarisi: Her hizmet (kimlik doğrulama, ödemeler, bildirimler) kendi bağımlılık ağacıyla kendi konteynerinde çalışır, bağımsız olarak dağıtılabilir ve ölçeklendirilebilir.
• CI/CD boru hatları: Derleme ajanları her iş için yeni bir konteyner başlatır, temiz bir ortamda testleri çalıştırır ve ardından silinir — derlemeler arasındaki durum kirliliğini ortadan kaldırır.
• Geçici geliştirme ortamları: Geliştiriciler bir depoyu klonlar ve ana bilgisayar işletim sisteminden bağımsız olarak saniyeler içinde tam işlevsel bir yerel yığın elde etmek için docker compose up çalıştırır.
• Sunucusuz ve hizmet olarak işlev platformları: Çoğu FaaS platformu (AWS Lambda, Google Cloud Run) arka planda konteynerler veya mikro VM’ler kullanır.
• Durumsuz web uygulamaları: Herhangi bir örneğin herhangi bir isteği işleyebildiği yatay olarak ölçeklendirilen web katmanları, bir yük dengeleyicinin arkasındaki konteynerler için doğal bir uyumdur.

Sanallaştırma ve Konteynerizasyon: Karşılaştırmalı Analiz

Kritik Teknik Nüanslar ve Uç Durumlar

Konteyner Kaçış Sorunu

Konteynerler ana bilgisayar çekirdeğini paylaşır. runc konteyner kaçışı (CVE-2019-5736) veya cgroups ayrıcalık yükseltme gibi yamalanmamış herhangi bir çekirdek güvenlik açığı, potansiyel olarak kötü amaçlı bir konteynerin ana bilgisayarda root erişimi elde etmesine izin verebilir. Bu, konteynerizasyonun temel güvenlik ödünleşimidir. Farklı müşterilerin iş yüklerinin aynı ana bilgisayarda çalıştığı çok kiracılı ortamlarda, VM düzeyinde izolasyon doğru seçimdir.

Azaltıcı önlemler mevcuttur: konteynerleri root olmayan kullanıcı olarak çalıştırmak, kullanıcı ad alanı yeniden eşlemesini etkinleştirmek, seccomp profilleri uygulamak ve gVisor veya Kata Containers kullanmak (aşağıya bakın), ancak bunlar operasyonel karmaşıklık ekler.

Kata Containers: Boşluğu Kapatmak

Kata Containers, her konteyneri soyulmuş bir çekirdek ve minimal bir hipervizör (QEMU, Firecracker veya Cloud Hypervisor) kullanarak hafif bir VM içinde çalıştırır. Orkestratörün bakış açısından, standart bir OCI konteyneri gibi davranır. Güvenlik açısından, VM düzeyinde çekirdek izolasyonuna sahiptir. AWS Fargate ve Google Cloud Run’ın konteyner geliştirici deneyimini korurken güçlü çok kiracılı izolasyon elde etme yöntemi budur.

Windows Konteynerleri

Windows konteynerleri mevcut olmakla birlikte kritik bir kısıtlamaları vardır: Windows ana bilgisayar çekirdeği gerektirirler. Bir Windows konteyner imajı, bir VM aracısı olmadan Linux ana bilgisayarında çalıştırılamaz (Docker Desktop’ın macOS ve Windows’ta yaptığı tam olarak budur — bir Linux VM çalıştırır ve içinde Linux konteynerlerini yürütür). Bu, çapraz platform CI/CD planlarken ekipleri hazırlıksız yakalayan bir taşınabilirlik uç durumudur.

Konteynerlerde Kalıcı Durum

Konteynerler durumsuz ve geçici olacak şekilde tasarlanmıştır. Veritabanı verilerini, kullanıcı yüklemelerini veya uygulama günlüklerini bir konteynerin yazılabilir katmanında depolamak bir anti-pattern’dir — konteyner kaldırıldığında veriler kaybolur. Kalıcı durum, Docker birimleri, bağlama noktaları veya Kubernetes’te bir CSI (Container Storage Interface) sürücüsü gerektirir. Veritabanları, mesaj kuyrukları ve herhangi bir durumlu hizmet, VM’lerin sahip olmadığı (bir VM’nin diski doğası gereği kalıcıdır) açık birim yönetimi gerektirir.

cgroup v2 Olmadan Kaynak Çekişmesi

cgroup v1 kullanan eski Linux çekirdeklerinde, belirli kaynak muhasebesi hassas değildir. 512 MB bellek sınırıyla yapılandırılmış bir konteyner, paylaşılan çekirdek bellek önbellekleri aracılığıyla ana bilgisayar performansını etkileyebilir. Çekirdek 4.5+’ta mevcut olan ve modern dağıtımlarda varsayılan olan cgroup v2 (birleşik hiyerarşi), bu muhasebe boşluklarının çoğunu giderir. Konteynerleri 4.15’ten eski bir çekirdekte çalıştırıyorsanız, cgroup sürümünüzü doğrulayın ve sınırları buna göre ayarlayın.

VM Ek Yükü Her Zaman Dezavantaj Değildir

Sürekli ve yüksek kullanımla çalışan iş yükleri için — bir veritabanı sunucusu, bir mesaj aracısı, bir makine öğrenmesi eğitim işi — VM başına işletim sistemi ek yükü (minimal bir Linux işletim sistemi için tipik olarak 200–500 MB RAM) iş yükünün kendi alanına kıyasla ihmal edilebilir düzeydedir. Bu senaryolarda bir VM’nin izolasyon ve öngörülebilirlik faydaları ek yükü aşar. Konteynerler yoğunluk avantajlarını öncelikle kısa ömürlü, hafif veya yüksek oranda çoğaltılmış iş yükleri için sunar.

Sanallaştırma ve Konteynerizasyonu Birleştirme

En yaygın üretim mimarisi ikisi arasında bir seçim değildir — her ikisi de kasıtlı olarak katmanlanmıştır:

1. Tip 1 hipervizör çalıştıran fiziksel ana bilgisayar (KVM, ESXi), donanım düzeyinde çok kiracılılık ve kaynak bölümlendirmesi sağlar.
2. VM’ler, hipervizörün içinde çalışır; her biri kendi işletim sistemiyle güçlü iş yükü izolasyonu ve işletim sistemi düzeyinde esneklik sağlar.
3. Konteyner çalışma zamanı (containerd, Docker), her VM içinde çalışarak mikro hizmet dağıtımını, CI/CD’yi ve yüksek yoğunluklu uygulama barındırmayı mümkün kılar.
4. Kubernetes, VM filosu genelinde konteynerleri düzenler; zamanlama, ölçeklendirme, hizmet keşfi ve aşamalı dağıtımları yönetir.

Bu, her büyük bulut sağlayıcısı ve çoğu büyük ölçekli şirket içi dağıtım tarafından kullanılan mimaridir. Dedicated Servers katmanı, bu mimarinin tipik olarak başladığı yerdir — bare metal, hipervizör katmanı, CPU sabitleme ve NUMA topolojisi üzerinde tam kontrol sağlar.

Bu yığının üzerinde kontrol panelleri çalıştıran ekipler için, VPS Control Panels, VM yaşam döngüsü yönetiminin büyük bölümünü soyutlayarak bu katmanlı mimariyi derin hipervizör uzmanlığı olmadan işletmeyi pratik hale getirir.

VM’lerde Kubernetes: Neden Bare Metal Kubernetes Değil?

Kubernetes’i doğrudan bare metal üzerinde çalıştırmak mümkündür ancak operasyonel açıdan zorludur. Düğüm arızaları manuel donanım müdahalesi gerektirir. VM tabanlı Kubernetes düğümleri canlı olarak geçirilebilir, yükseltmelerden önce anlık görüntüleri alınabilir ve otomatik olarak değiştirilebilir. Hipervizör katmanının hafif performans ek yükü, sağladığı operasyonel dayanıklılık için neredeyse her zaman değerlidir.

Doğru Yaklaşımı Seçmek: Karar Çerçevesi

Mimari kararınıza rehberlik etmesi için bu matrisi kullanın:

VM’leri şu durumlarda seçin:

• Aynı ana bilgisayarda birden fazla farklı işletim sistemi türü çalıştırmanız gerekiyorsa
• İş yükleri sert çekirdek düzeyinde izolasyon gerektiriyorsa (uyumluluk, çok kiracılılık, güvenilmeyen kod)
• Konteynerleştirilemeyen eski uygulamalar barındırıyorsanız
• İş yükleri uzun süreli, durumlu ve kaynak yoğunsa (veritabanları, ERP sistemleri)
• Canlı geçiş, tam durum anlık görüntüleri veya donanım geçişi (GPU, SR-IOV NIC) gerekiyorsa

Konteynerleri şu durumlarda seçin:

• Tüm iş yükleri aynı işletim sistemi ailesinde çalışıyorsa (Linux üzerinde Linux)
• Mikro hizmet mimarisi oluşturuyor veya buna geçiş yapıyorsanız
• CI/CD boru hattı hızı ve ortam tekrarlanabilirliği önceliklerse
• Yatay ölçeklendirme ve hızlı dağıtım döngüleri gerekiyorsa
• Kaynak yoğunluğu ve maliyet verimliliği birincil kısıtlamalarsa

Her ikisini de (hibrit) şu durumlarda seçin:

• Farklı müşterilere hizmet veren çok kiracılı bir platform işletiyorsanız
• Bazı iş yükleri bulut yerel, bazıları eski ise
• Orkestrasyon için Kubernetes istiyorsanız ancak kiracı başına VM düzeyinde izolasyon istiyorsanız
• Uyumluluk gereksinimleriniz iş yükü izolasyonunu zorunlu kılarken geliştirme ekipleriniz konteyner iş akışlarına ihtiyaç duyuyorsa

Özel çekirdek yapılandırmaları gerektirmeyen web uygulamaları için, Shared Web Hosting, bu katmanlı altyapı üzerine inşa edilmiş yönetilen bir ortam sunar — VM’leri veya konteynerleri doğrudan yönetmenin operasyonel yükü olmadan standart PHP, Python veya Node.js uygulamaları için uygundur.

Uygulama yığınınız özel SSL sonlandırma, sertifika yönetimi veya konteynerleştirilmiş hizmetler genelinde HTTPS zorunluluğu içeriyorsa, dağıtımınızı düzgün yönetilen SSL Certificates ile eşleştirmek, TLS’nin tüm hizmet uç noktalarında tutarlı biçimde ele alınmasını sağlar.

Teknik Temel Kontrol Listesi

Bir mimariye bağlanmadan önce aşağıdakileri doğrulayın:

• İzolasyon gereksinimi: Tehdit modeliniz çekirdek düzeyinde izolasyon gerektiriyor mu? Evet ise, VM’ler veya Kata Containers kullanın.
• İşletim sistemi uyumluluğu: İş yükleriniz farklı işletim sistemi çekirdekleri gerektiriyor mu? VM’ler tek seçenektir.
• Başlatma gecikmesi: İş yükünüz saniyenin altında başlatma süresi gerektiriyor mu (otomatik ölçeklendirme, FaaS)? Konteynerler kazanır.
• Durum yönetimi: Durumlu konteynerler için açık birim stratejileri tasarladınız mı?
• Çekirdek sürümü: cgroup v2 çalıştırıyor musunuz? cat /proc/cgroups veya mount | grep cgroup2 ile doğrulayın.
• Güvenlik sertleştirme: Konteynerler için seccomp profilleri, root olmayan kullanıcılar ve salt okunur kök dosya sistemleri uyguladınız mı?
• Orkestrasyon: Birkaçtan fazla konteyner için Kubernetes veya Swarm isteğe bağlı değildir — manuel konteyner yönetimi ölçeklenmez.
• İmaj hijyeni: Konteyner imajlarınız minimal temel imajlardan (Alpine, distroless) mı oluşturuluyor? Şişirilmiş imajlar saldırı yüzeyini ve çekme sürelerini artırır.
• Uyumluluk eşlemesi: İzolasyon modelinizin belirli uyumluluk çerçevenizi (PCI-DSS, HIPAA, SOC 2) karşıladığını doğruladınız mı?
• Hibrit uygulanabilirlik: Her ikisini de çalıştırıyorsanız, iki soyutlama katmanını yönetmenin operasyonel karmaşıklığını hesaba kattınız mı?

SSS

VM ile konteyner arasındaki temel fark nedir?

Bir VM, tam bir işletim sistemi çekirdeği içerir ve donanımı taklit eden bir hipervizör üzerinde çalışır. Bir konteyner, ana bilgisayar işletim sistemi çekirdeğini paylaşır ve süreç düzeyinde izolasyon için Linux ad alanlarını ve cgroup’ları kullanır. VM’ler daha güçlü izolasyon sağlar; konteynerler daha yüksek yoğunluk ve daha hızlı başlatma sağlar.

Konteynerler VM’lerin tamamen yerini alabilir mi?

Hayır. Konteynerler, ana bilgisayardan farklı bir işletim sistemi çekirdeği çalıştıramaz, donanım tarafından zorlanan izolasyon sağlayamaz ve tam durum anlık görüntüleri veya canlı geçiş gerektiren iş yükleri için uygun değildir. VM’ler, çoklu işletim sistemi ortamları, uyumluluk açısından hassas çok kiracılılık ve eski uygulamalar için gerekli olmaya devam etmektedir.

Docker, konteynerizasyonla aynı şey midir?

Docker, konteynerizasyon ilkelleri (ad alanları, cgroup’lar, OverlayFS) üzerine inşa edilmiş bir araç zinciri ve imaj formatıdır. Konteynerizasyon, temel teknolojidir. containerd, Podman veya cri-o kullanarak Docker olmadan OCI uyumlu konteynerler çalıştırabilirsiniz.

Hangisi daha güvenlidir — VM’ler mi yoksa konteynerler mi?

VM’ler, hipervizörün iş yükleri arasında donanım düzeyinde izolasyon uygulaması nedeniyle varsayılan olarak daha güçlü bir güvenlik sınırı sağlar. Konteynerler ana bilgisayar çekirdeğini paylaşır, yani bir çekirdek güvenlik açığı potansiyel olarak ana bilgisayardaki tüm konteynerleri etkileyebilir. Ancak, sertleştirilmiş konteyner yapılandırmaları (seccomp, AppArmor, rootless Podman, Kata Containers) çoğu tehdit modeli için bu boşluğun büyük bölümünü kapatabilir.

VM’lerin içinde konteyner çalıştırmanın performans ek yükü nedir?

Pratikte, çoğu iş yükü için ek yük minimaldir. Hipervizör katmanı, donanım destekli sanallaştırma (Intel VT-x / AMD-V) ile yaklaşık %1–3 CPU ek yükü ekler. Bellek ek yükü daha önemli bir faktördür — her VM tam bir işletim sistemi alanı gerektirir (minimal bir Linux misafiri için 200–500 MB). CPU yoğun veya ağ yoğun iş yükleri için, varsayımlarda bulunmadan önce belirli yığınınızı kıyaslayın.