Azure Storage I/O performans problemləri (Throttle, gecikmə və tier optimallaşdırması)

Azure Storage hesabınızda (Blob/File/Table/Queue) əməliyyatların yavaşıdığını və ya throttling (məhdudlaşdırma) hadisələrinin baş verdiyini müşahidə edirsiniz. Əlamətlər: – Tətbiqiniz bloblara/ fayl paylaşımına yazarkən və oxuyarkən yüksək gecikmə (latency) yaranır, əvvəllər <10 ms olan əməliyyatlar indi 100 ms-lərlə ölçülür. – Azure Storage-dən (məsələn, Azure Table və ya Cosmos Table API) məlumat oxuyarkən tez-tez ServerBusy və ya 503 xətaları alırsınız – yəni sorğular boğulur. – Azure un Metrics göstəricilərində “E2E Latency” (End-to-End gecikmə) və “Server Latency” arasındakı fərq artıb. Xüsusilə uzaq müştərilərdə (on-prem və ya fərqli regiondan qoşulan) E2E gecikmə çox yüksək, ancaq Server latency nisbətən aşağıdır. – Throttling əlamətləri: Storage hesabının monitorinq loglarında və ya Azure Monitor Alerts-də sürətli ardıcıllıqla çox sayda Throttle hadisəsi (Status code 429 və ya xətalar) görülür. Bu, Azure Storage-in tələbləri limitlərə görə ləngitdiyi deməkdir.

Mümkün kök səbəblər:

• Azure Storage hədəf limitlərinə çatma (throttling): Hər bir Azure Storage hesabının müəyyən məhsuldarlıq hədəfləri var (məsələn, bir blob üçün saniyədə ~60 MB yazma, hər hesaba x əməliyyat/saniyə, hər partition key üçün 2000 tələbs/saniyə və s.). Müştərilər bu hədəflərə yaxınlaşdıqda və ya aşdıqda, Azure Storage sorğuları boğmağa başlayır – bu da gecikməni artırır. Yəni, throttle hadisəsi performans hədəflərinin keçildiyinin göstəricisidir. Xüsusilə tək bir blob və ya partition üzərinə çox yüksək yüklənmə bu limitləri tez tetikleyir.
• Yüksək şəbəkə gecikməsi (client-side latency): Əgər müştəri Azure Storage-a uzaqdan (fərqli regiondan və ya internet üzərindən) qoşulursa, fiziki məsafə və şəbəkə xətləri ümumi gecikməyə əhəmiyyətli təsir edə bilər. Belə hallarda Server Latency (Azure datacenter içində obyektin işləmə müddəti) kiçik olsa da, ümumi E2E Latency böyük olur (məsələn, müştəri ilə server arasındakı 43 ms gecikmə sırf şəbəkədə gedir). On-premises müştərilərlə eyni regiondakı müştərilərin gecikməsini müqayisə etdikdə bu fərq aydın görülür – uzaq müştəridə E2E gecikmə xeyli yüksəkdir, serverin daxili işləmə müddəti isə eyni qalır.
• Storage hesabının tier-i və növü: Standart tier (HDD əsaslı) storage istifadə olunursa, o, Premium (SSD əsaslı) storage qədər I/O tələbatını ödəyə bilməyə bilər. Məsələn, Standart Azure Blob Storage eyni anda məhdud sayda IOPS və throughput təmin edir. Əgər çox yüksək tranzaksiya həcminiz varsa, Premium Blob Storage hesabına keçməmək throttling-ə səbəb ola bilər. Həmçinin, blob-ların Hot/Cool/Archive tier-ləri fərqli performans xarakteristikalarına malikdir: Archive tierindəki verilənlərə çıxış çox yavaşdır (öncə rehidratasiya tələb olunur), Cool tier isə daha yüksək gecikməli ola bilər (baxmayaraq ki, Hot ilə eyni performans hədəflərinə sahibdir, ilk bayta gecikmə bir az arta bilər).
• Metadata əməliyyatlarının həddi (xüsusilə Azure Files): Azure File Share-lərdə metadata IOPS limiti var (~12K metadata IOPS/share). Kataloq siyahılama, fayl açıb bağlama kimi əməliyyatlar bu limiti aşarsa, metadata throttling baş verə bilər. Hətta ümumi IOPS yerində qalsa belə, metadata-aid əməliyyatlar boğula bilər.
• Klient tərəfdə suboptimal istifadə: Məsələn, eyni anda çoxlu paralel request-lər göndərən bir tətbiq düzgün exponential backoff tətbiq etmir. Throttling baş verəndə yenidən cəhdlər arasındakı gecikməni tənzimləmirsə, bu, durumu daha da ağırlaşdırır (qartopu təsiri ilə).
• Şəbəkə bant genişliyi və ya NVA limitləri: Storage gecikməsinin bir səbəbi də, xüsusilə VM-lərin storage-ə eyni VNet-dən çıxışı zamanı, şəbəkə bantının dolması və ya aradakı firewall/NVA-nın throughput-u məhdudlaşdırması ola bilər. Bu halda Azure Storage özü deyil, yol üzərindəki infrastruktur gecikmə yaradır.

Diaqnostika üsulları:

Azure Monitor (Storage Insights) vasitəsi ilə Storage hesabınızın metrikalarını təhlil edin. Xüsusilə nəzər yetirin: – Success E2E Latency və Success Server Latency metrikaları. Bunların ortalamasını müqayisə edin. Azure tövsiyə edir ki, performans təhqiqatına bu iki metrikdən başlayın. E2E latency – müştərinin sorğu göndərməsindən tam cavabı almasına qədər keçən vaxtdır; Server latency – bunun içində yalnız Azure Storage-in daxili emal müddətidir. Qrafikdə E2E (mavi) ilə Server (çəhrayı) arasında böyük fərq varsa, deməli, gecikmənin əsas hissəsi şəbəkə ötürülməsi və ya müştəri tərəfindəndir. Məsələn, birinci qrafikdə uzaq müştəri üçün E2E ~43.9 ms, server latency ~1.4 ms kimi görünə bilər, ikinci qrafikdə eyni region müştərisi üçün E2E cəmi 0.17 ms artıqdır (yəni demək olar ki, server vaxtına bərabərdir). Bu, şəbəkə gecikməsinin rolunu açıq göstərir. – Throttling indikatorları: Azure Storage monitorinq loglarında “ServerBusyError” və ya 429 status kodu sayını izləyin. Azure Monitor Metrics’də Transaction metri üçün Response Type filtrini tətbiq etməklə Throttle və ya Server Timeout tipli cavabların sayını görə bilərsiniz (yeni Storage Metrics sistemində). Azure Files üçün xüsusi Success with Throttling metrikaları da mövcuddur. Məsələn, Success with Metadata Throttling artıbsa, bu o deməkdir ki, metadata əməliyyatları throttle edilib – yəni file share-in metadata IOPS limiti aşılıb və sorğular məhdudlaşdırılır. – Capacity və Throughput metrikaları: Storage hesabının ümumi istifadə həcmi (Capacity) çox yüksəkdirsə və ya saniyədə əməliyyat sayı (Total Requests) qəfil artıbsa, performansa təsir edə bilər. Azure Storage-in Scalability and Performance Targets sənədinə baxaraq sizin ssenari üçün limitlərin nə olduğunu öyrənin. Məsələn, standart bir general-purpose v2 hesabı bir regionda saniyədə maksimum ~20,000 read/write əməliyyatı hədəfinə malikdir; partition başına isə ~2000-ə yaxın. Metrics-də görürsünüzsə ki, Transaction Count bu səviyyələrə çatır, throttle gözləniləndir. – ServerTimeout və Network Error-lar: Application Insights kimi monitorinqdə yığılan loglarda “StorageException: Operation Timeout” və ya “Server busy. Throttling” mesajları görünürmü? Bu, müştəri tərəfdə də təsdiq edir ki, problem throttling/timeout-dur. – Azure Storage Logging (Analytics): Klassik Azure Storage Analytics logs aktivdirsə, oradan hər sorğunun cavab kodunu və duration-nu çıxarmaq olar. Orada x-ms-throttle-error kodları və ya uzun server tərəf emal vaxtları (ServerLatency) qeyd edilibsə, faydalı ola bilər.

Bundan əlavə, əgər Azure VM-ləriniz storage-ə çıxırsa, həmin VM-lərin network bandwidth monitorinqini yoxlayın (məsələn, Bytes Sent/Received metrics). Bəlkə də sadəcə şəbəkə kartının limitinə çatılır (məs., D seriyası VM-lər üçün şəbəkə bant limitləri var). Eyni zamanda, yol üzərində Azure Firewall və ya NVAdan istifadə edirsinizsə, onların metrics-lərinə baxın – CPU/droplar var mı?

Həll yolları:

• Premium Storage-a keçid və ya storage hesabının tipini optimallaşdırma: Yüksək I/O tələbatı varsa, standart storagedansa Premium Block Blob Storage hesabından istifadə etmək performansı artıracaq. Premium blok blob storage SSD-lər üzərində qurulub və yüksək throughput/IOPS təklif edir, həmçinin throttle limitləri daha yüksəkdir. Oxşar şəkildə, Azure Files üçün standart share əvəzinə Premium File Share (əvvəlki adı Files SSD) istifadə etmək gecikməni və throttle imkanını yaxşılaşdırır. Microsoft bildirir ki, yüksək tranzaksiya və aşağı gecikmə tələbləri üçün premium storage hesabları uyğun seçimdir.
• Hot/Cool tier seçimi: Əgər blob-larınız hal-hazırda Cool tier-dədirsə və tez-tez oxunursa, onları Hot tier-ə gətirmək latency-i azalda bilər (Cool tier əsasən eyni performansa malik olsa da, bəzi hallarda ilk bayta bir az daha gec erişim ola bilər, üstəlik Cool-dan tez-tez istifadə etmək iqtisadi cəhətdən də ziyanadır). Archive tier-dən tez çıxış tələb edən veriləniz varsa, öncə onları Hot və ya Cool tier-ə rehidratasiya etməlisiniz – bu proses özü saatlar çəkə bilər, yəni Archive tier performans üçün deyil, ancaq ucuz saxlama üçündür. Tiering optimallaşdırması o deməkdir ki, verilənizin istilik dərəcəsinə (istifadə tezliyinə) uyğun düzgün tier seçin.
• Hədəf limitlər daxilində dizayn: Storage hesabının partitioning-dən düzgün faydalanın. Məsələn, Azure Blob-larda eyni blob-a aramsız çox yazmaqdansa, paralel yazmaları müxtəlif blob-lara paylayın (hətta sonra birləşdirə bilərsiniz). Azure Table-da eyni partition key üzərində sorgu yükü yüksəkdirsə, məlumatları bir neçə partition key-ə bölmək throttle-u azalda bilər. Microsoft-un performans checklistində qeyd olunduğu kimi, block blob yükləmələrində bloku böyük göndərmək throughput-u artırır və partition limitlərinə ilişməmək üçün faydalıdır (256KB-dan böyük blok göndərmək High-Throughput mode-u aktiv edir).
• Coğrafi yaxınlıq və şəbəkə optimallaşdırması: Müştəriləri storage hesabına mümkün qədər yaxın yerləşdirin. Yəni, storage hesabını tətbiqlərinizin olduğu Azure regionunda saxlayın. Əgər həm on-prem, həm də Azure mühitlərindən eyni dataya çıxış lazımdırsa, bəlkə regionlar üzrə ayrı storage account-lar qurub object replication istifadə edəsiniz ki, hər regionda yerli sürətli oxu olsun. Web kontenti son istifadəçilərə çatdırırsınızsa (məsələn, blob-dan statik fayllar), Azure CDN və ya Azure Front Door vasitəsilə cache-ləmə global gecikməni azaldacaq. Həmçinin, ExpressRoute və ya VPN üzərindən qoşulan on-prem müştərilər üçün, bağlantının keyfiyyətini ölçün – paket itkisi və jitter də latency-yə təsir edir. Azure Network Watcher və ya digər alətlərlə link keyfiyyətini test edin, ehtiyac olarsa, şəbəkə avadanlığında optimallaşma aparın.
• Throttle halında geri çəkilmə (backoff) tətbiqi: Əgər throttle hadisələri qaçınılmazdırsa (məsələn, qısa zamanda partlayış kimi yük gəlir), müştəri tətbiqinin bunu idarə etməsi vacibdir. Azure Storage client SDK-ları adətən avtomatik retry məntiqi ilə gəlir – ekspansial gecikmə (exponential backoff) ilə yenidən cəhd edirlər. Bu konfiqurasiyaları gözdən keçirin: bəlkə, həddən artıq aqressiv edilib. Çox tez-tez retry etmək əvəzinə, bir az aralıq verin ki, storage hesabı özünü toparlasın. Məsələn, ilk throttle-da 1 saniyə, sonra 2 saniyə kimi artan gecikmə ilə maksimum 3-5 dəfə cəhd məqbuldur. Bu, həm orta gecikməni azaldar (heç olmazsa bəziləri ikinci cəhddə uğrayar), həm də storage-ə düşən təzyiqi azaldar.
• Metadata əməliyyatlarının azaldılması: Xüsusilə Azure Files-də metadata throttling aşkar olunubsa, onu yüngülləşdirmək üçün addımlar atın. Məsələn, bir dizində eyni anda minlərlə fayl yaradılıb silinirsə, bunu bir neçə ayrı dizinə bölüşdürün. Və ya Azure Files Metadata Caching funksiyasını aktiv edin (SSD file share-lər üçün mövcuddur) ki, tez-tez təkrarlanan open/close əməliyyatları cache-dən xidmət edilsin. Həmçinin, workload-ı bir neçə fayl share-ə bölmək (shard) effektiv ola bilər – beləcə, hər share-in metadata IOPS limiti ayrı-ayrılıqda tətbiq olunur.
• Yerli disk-cache imkanlarından faydalanın: Azure Blob və Azure Files üçün müştəri tərəfində caching tətbiq oluna bilər. Məsələn, Azure VM içində blob-fuse və ya Azure File sync agent istifadə olunursa, onların caching parametrlərini optimallaşdırın ki, eyni faylın təkrar oxunuşları yerli cache-dən getsin. Bu, həm gecikməni azaldar, həm də storage-a gedən IOPS-u azaldar.
• Storage account-ları bölüşdürün: Tək bir storage hesabı limitə yaxın işləyirsə və optimizasiya yetmirsə, datanı bir neçə storage account arasında paylamağı düşünün. Məsələn, 1 hesab əvəzinə 2 hesab istifadə etməklə nəzəri olaraq throughput hədəflərini ikiqat artırmış olarsınız (çünki hər hesab öz limitləri ilə işləyir). Təbii ki, bu, tətbiqinizi də modifikasiya etməyi tələb edə bilər (məsələn, datanın hansı account-a getdiyini anlamaq üçün).
• İş yükünə uyğun Service seçimləri: Bəlkə də Azure Storage əvəzinə xüsusi xidmət daha uyğundur: misal üçün, çox yüksək sorğu həcmi və aşağı gecikmə üçün Azure Cosmos DB Table API (və ya Azure Cache) istifadəsi. Yaxud analitik oxunuşlar üçün Azure Data Explorer kimi xidmətlər. Bu, daha böyük arxitektura qərarıdır, ancaq bəzən performans tələblərini qarşılamaq üçün data doğasını nəzərə almaq lazımdır.

Bütün bu tədbirlərdən sonra, Azure Monitor metriklərini yenidən dəyərləndirin. Gözləntilər: – Throttling event sayları azalmalıdır (ideal halda 0 olmalıdır). Məsələn, öncə saatda 1000+ throttle alan bir hesab, Premium-a keçdikdən və load bölündükdən sonra heç throttle almaya bilər. – Average E2E Latency azalmalıdır. Əgər böyük hissəsi şəbəkə ilə bağlı idisə, onu həll etmək (region yaxınlığı, CDN) fərqi misillərlə azaldar – yuxarıdakı nümunədə uzaq müştərinin 43ms-lik gecikməsi, yaxınlaşdırdıqda <5ms-ə enə bilər. – Server Latency stabil qalmalıdır və ya bir qədər azalmalıdır (məsələn, premium storage istifadəsində server processing latency bir qədər aşağı olur). Əsas budur ki, E2E və Server latency qrafikləri bir-birinə yaxınlaşsın, yəni əlavə gecikmə komponentləri aradan qalxmış olsun. – Throughput artmalıdır: Əgər throttle ucbatından throughput məhdudlaşırdısa, indi eyni müddətdə daha çox əməliyyat icra edə bildiyinizi görəcəksiniz. Məsələn, əvvəl saniyədə 5000 req-də boğulurdusa, indi 10-15 min req/saniyə işləyə bilir. Nəticə etibarilə, tətbiqinizin storage ilə bağlı əməliyyatları daha sürətli tamamlanacaq, timeout və ya yavaşıma şikayətləri azalacaq, sistem hədəf limitlərinə uyğun stabil işləyəcək.