Di dunia digital-first saat ini, harapan akses data yang tidak terganggu tidak lagi merupakan kemewahan – itu adalah kebutuhan. Apakah Anda menjalankan aplikasi penting, melayani konten multimedia ke audiens global, atau hanya menyimpan cadangan file pribadi, keandalan penyimpanan cloud Anda secara langsung mempengaruhi segalanya dari produktivitas ke kepercayaan. Untuk sebagian besar penyedia cloud, keandalan diukur dalam hal persentase uptime – 99.9%, 99.99%, atau bahkan Namun, di balik kesepakatan tingkat layanan yang dipoles ini (SLA) ada realitas yang tajam: benar. - kemampuan untuk mengakses data Anda kapan saja, di mana saja, tanpa penundaan atau gangguan yang tidak terduga - tetap sulit. bahkan awan terpusat yang paling kuat rentan terhadap hal yang mereka coba mengurangi: kegagalan. five nines continuous performance Keandalan bukanlah sesuatu yang Anda harapkan - itu adalah sesuatu yang Anda desain untuk. Dari gangguan di seluruh wilayah hingga rute jaringan yang salah dikonfigurasi, kami telah melihat berulang kali bahwa infrastruktur terpusat, tidak peduli seberapa diperkuat, tidak dapat melarikan diri dari keterbatasan strukturalnya sendiri. Dari gangguan di seluruh wilayah hingga rute jaringan yang salah dikonfigurasi, kami telah melihat berulang kali bahwa infrastruktur terpusat, tidak peduli seberapa diperkuat, tidak dapat melarikan diri dari keterbatasan strukturalnya sendiri. Blog ini mengeksplorasi mengapa arsitektur terdesentralisasi Sia berada dalam posisi yang unik untuk mengatasi keterbatasan ini. Dalam bagian berikutnya, kami akan membandingkan desain ini dengan model penyimpanan tradisional, memecahkan skenario kegagalan dunia nyata, dan menunjukkan bagaimana desentralisasi tidak hanya lebih aman - itu lebih dapat diandalkan. Prestasi melalui resiliensi Karena di masa depan penyimpanan cloud, keandalan bukanlah sesuatu yang Anda harapkan – itu adalah sesuatu yang Anda desain untuk. Dasar yang rapuh dari awan terpusat Untuk semua janji mereka tentang "lima sembilan" uptime, platform penyimpanan cloud tradisional telah berulang kali membuktikan betapa rapuh infrastruktur terpusat dapat ketika dihadapkan dengan ekstrem lingkungan, kesalahan manusia, atau kesalahan internal. terlepas dari redundansi yang diklaim oleh hyperscale seperti AWS, Google Cloud, dan Microsoft Azure, studi kasus dunia nyata menceritakan kisah yang berbeda - satu di mana jutaan pengguna dapat kehilangan akses dalam satu saat, dan seluruh bisnis dihentikan karena satu titik kegagalan. Mungkin contoh yang paling dramatis dari kerentanan cloud ditemukan dalam kebakaran pusat data – insiden yang dapat langsung menonaktifkan seluruh zona layanan cloud. Pada bulan Agustus 2022, ledakan listrik di pusat data Council Bluffs Google melukai tiga pekerja dan mengganggu layanan inti seperti Search dan Maps. Setahun kemudian di Paris, kegagalan multi-kluster di zona europe-west9-a Google Cloud dimulai dengan penetrasi air - itu sendiri sebagai hasil dari kegagalan sistem pendinginan yang membanjiri ruang baterai dan menyalakan kebakaran. Insiden ini mencerminkan kebakaran OVHcloud 2021 yang sekarang terkenal di Strasbourg, yang benar-benar menghancurkan pusat data SBG2 dan sebagian merusak yang lain di kampus yang sama. Many customers had no disaster recovery plans in place, and entire websites were lost without backups. Di luar api, gelombang panas telah terbukti menjadi ancaman yang tidak terduga tetapi semakin meningkat. pada bulan Juli 2022, suhu rekor melebihi 40 ° C (104 ° F) di London menghancurkan kedua pusat data Google dan Oracle secara offline karena kegagalan sistem pendinginan. Google harus secara proaktif menutup bagian-bagian awan untuk mencegah kerusakan perangkat keras - pengakuan yang menakjubkan bahwa cuaca saja dapat mengganggu ketersediaan layanan. Namun, tidak semua gangguan lahir dari bencana fisik — beberapa adalah bencana digital yang menunggu untuk terjadi. pada Februari 2024, Google Cloud menderita gangguan lain ketika kegagalan penyimpanan metadata regional mengambil wilayah US-West1 offline selama hampir tiga jam. Demikian pula, pembaruan rutin oleh CrowdStrike pada Juli 2024 memicu kecelakaan luas sistem Microsoft Windows, menyebabkan ribuan penerbangan dibatalkan dan kerugian produktivitas besar di seluruh industri. Ketika jaringan pengiriman konten (CDN) seperti Fastly mengalami kesalahan konfigurasi pada tahun 2021, itu menyebabkan gangguan global, mempengaruhi Reddit, Spotify, dan media berita utama dalam hitungan detik. Performa Berkelanjutan Dengan Desain Di mana penyedia cloud terpusat membangun benteng yang semakin besar untuk melindungi dari kegagalan, Sia menghindari masalah sepenuhnya dengan menolak model benteng. alih-alih bertaruh semuanya pada ketahanan dari satu wilayah atau fasilitas, Sia mendistribusikan data Anda secara global, ke puluhan node yang dioperasikan secara independen, menggunakan matematika – bukan pemasaran – untuk menjamin keandalan. Pengunduran diri yang memberikan Redundansi sering dilihat sebagai langkah keamanan — cara untuk melindungi dari kegagalan. tetapi pada Sia, itu jauh lebih dari itu. Redundansi adalah apa yang memungkinkan kinerja berkelanjutan. Secara default, Sia membagi setiap file menjadi 30 fragmen terenkripsi menggunakan pengkodean penghapusan. Hanya 10 fragmen yang dibutuhkan untuk sepenuhnya merekonstruksi file. Ini berarti jaringan dapat mentolerir tidak hanya gangguan, tetapi kinerja variabel dari masing-masing host — semuanya sambil mempertahankan akses yang lancar. Redundansi bukanlah kegagalan - itu adalah dasar dari kinerja berkelanjutan. Sebaliknya, awan tradisional bergantung pada replikasi file penuh di beberapa wilayah.Jika satu wilayah gagal, akses melambat atau berhenti – dan penyimpanan tambahan tidak berarti kecepatan yang lebih baik. Retrieval pathways bervariasi secara dinamis berdasarkan ketersediaan host dan kondisi jaringan – tidak ada failover, tidak ada bottlenecks, tidak ada jendela downtime. Dan sementara awan terpusat juga dapat menggunakan penghapusan pengkodean secara internal, semua infrastruktur mereka masih dikelola oleh penyedia tunggal. Host Sia, sebaliknya, dioperasikan secara independen – seringkali oleh individu atau bisnis yang berbeda. Menggunakan Sia seperti membagi data Anda di 30 awan yang berbeda secara default. Resistensi tanpa gangguan Dalam kebanyakan lingkungan cloud, ketika sesuatu rusak, kinerja menderita. bahkan dengan sistem failover di tempat, gangguan sering menyebabkan kecepatan yang menurun, akses yang terganggu, atau total downtime sementara infrastruktur bermasalah untuk pulih. Arsitektur Sia bekerja berbeda. Ketika host yang menyimpan sebagian dari data Anda offline - baik karena kegagalan, pemeliharaan, atau ketidakstabilan - file Anda tetap dapat diakses sepenuhnya. Tidak ada spin loading, tidak ada sinkronisasi, tidak ada peringatan. jaringan terus mengambil fragmen yang diperlukan dari host yang tersisa, secara dinamis memilih opsi yang paling cepat tersedia. Sementara itu, di latar belakang, perangkat lunak penyewa mulai secara otonom memulihkan redundansi penuh dengan mengunggah potongan-potongan baru ke host yang sehat. Sia tidak hanya pulih dari kegagalan - ia bekerja melalui itu. Alih-alih bereaksi terhadap kegagalan setelah itu terjadi, Sia memperlakukan churn sebagai perilaku yang diharapkan – satu yang jaringan dibangun untuk menangani dengan sopan. Tidak ada satu titik kegagalan Platform cloud terpusat rentan terhadap kegagalan kaskad karena mereka bergantung pada kontrol terpusat. router yang salah dikonfigurasi, penyebaran perangkat lunak yang rusak, atau masalah daya di satu fasilitas dapat menyebar ke berbagai wilayah – menendang layanan yang bergantung pada jutaan orang. Arsitektur Sia menghilangkan risiko ini dengan desain. tidak ada node master. tidak ada wilayah pusat. tidak ada otoritas istimewa yang dapat secara tidak sengaja mengambil sistem offline. sebaliknya, data Anda didistribusikan ke puluhan host independen di seluruh dunia - masing-masing menyimpan hanya fragmen terenkripsi. Jika satu host gagal, sistem terus berjalan. Jika sepuluh host gagal, itu masih terus berjalan. Tidak ada kebutuhan untuk "kegagalan" karena tidak ada jalur tunggal untuk memulai. Tidak ada area. tidak ada node master. tidak ada bottleneck. hanya akses yang tidak dapat dihentikan. Kekurangan ketergantungan pusat ini tidak hanya meningkatkan toleransi kesalahan - itu Anda tidak menunggu wilayah untuk kembali online. Anda tidak terjebak oleh gateway yang berlebihan atau layanan pemulihan administrator manusia. Anda menarik data dari mana saja yang paling cepat – terus menerus. prevents performance blackouts Desain untuk keandalan, bukan hanya berharap untuk itu Ketika kita berbicara tentang “keandalan cloud”, kita seringkali dijual janji – SLA didukung oleh denda keuangan, persentase uptime yang cemerlang, dan reputasi merek. tetapi seperti yang telah kita lihat, bahkan penyedia cloud terbesar tidak dapat melarikan diri dari kerentanan yang datang dengan sentralisasi. Apakah itu kebakaran, gelombang panas, atau kesalahan perangkat lunak, model cloud tradisional selalu beberapa kegagalan yang bercabang jauh dari gangguan global. Alih-alih mengasumsikan infrastruktur akan bertahan dan mempersiapkan bencana ketika tidak, Sia mengasumsikan kegagalan tidak dapat dihindari – dan membangun sistem yang terus bekerja. Tidak ada server istimewa, tidak ada ketergantungan regional, tidak ada vendor lock-in. hanya infrastruktur yang dapat diperbaiki sendiri, terdesentralisasi yang membuat data Anda dapat diakses karena tidak ada aktor tunggal yang memiliki kekuatan untuk membuatnya tidak dapat diakses. Performa yang berterusan Ini lebih dari keuntungan teknis. Ini adalah perubahan dalam cara kita berpikir tentang ketahanan digital. alih-alih membangun dinding yang lebih tinggi dan moats yang lebih dalam, Sia memecah-belah pertahanannya. Ini mendistribusikan kepercayaan. Dan dengan melakukannya, itu mendefinisikan ulang bagaimana penyimpanan cloud yang dapat diandalkan bisa terlihat di dunia di mana downtime tidak lagi dapat diterima. Karena organisasi menghadapi gangguan yang meningkat, biaya yang meningkat, dan persyaratan kepatuhan yang lebih ketat, desentralisasi telah menjadi lebih dari layak — itu lebih baik. , bahkan ketika hal-hal salah, maka saatnya kita berhenti merancang sekitar kepercayaan dan mulai merancang sekitar kepastian. Hanya bekerja Dengan Sia, kinerja berkelanjutan bukanlah tujuan, itu adalah jaminan. sumber Data Center Knowledge. (2022, 9 Agustus). Kebakaran pusat data — Google menderita ‘incident listrik’, 3 cedera. Data Center Knowledge. https://www.datacenterknowledge.com/hyperscalers/data-center-fire-google-suffers-electric-incident-3-cedera Claburn, T. (2023, 26 April). Google Cloud meluncur di Eropa di tengah kebocoran air, kebakaran. https://www.theregister.com/2023/04/26/google_cloud_outage/ OVH telah menghancurkan pusat data Strasbourg (SBG2). Data Center Knowledge. https://www.datacenterknowledge.com/uptime/fire-has-destroyed-ovh-s-strasbourg-datacenter-sbg2 Bloomberg News. (2022, 20 Juli). Google, pusat data Oracle dipukul secara offline oleh panas London. Data Center Knowledge. https://www.datacenterknowledge.com/cooling/google-oracle-data-centers-knocked-offline-by-london-heat Millward, W. (2024, 5 Desember). 10 pemadaman awan terbesar 2024. CRN. https://www.crn.com/news/cloud/2024/the-10-biggest-cloud-outages-of-2024 Barrett, B. (2021, 8 Juni). Bagaimana sebuah perusahaan yang tidak jelas mengambil potongan-potongan besar internet. WIRED. https://www.wired.com/story/fastly-cdn-internet-outages-2021/

This story contains new, firsthand information uncovered by the writer.

Audio ini diproduksi dalam bahasa asli cerita!

Terlalu panjang; Untuk membaca

Make resilience your competitive advantage

Sia Redefines Cloud Reliability dengan Performa Berkelanjutan oleh Desain

About Author

KOMENTAR

HANG TAG

ARTIKEL INI DISAJIKAN PADA

Related Stories

Invest With Purpose: Interview with Arian Adeli, CEO at Rivo Trading

Building an API-Powered Platform

THE BEGINNING OF THE SEARCH FOR THE KEY AND THE COAT.

How to Fetch Large Data Files Through GitHub API

Invest With Purpose: Interview with Arian Adeli, CEO at Rivo Trading

Building an API-Powered Platform

THE BEGINNING OF THE SEARCH FOR THE KEY AND THE COAT.

How to Fetch Large Data Files Through GitHub API

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps