AWS: Inilah yang salah dalam pemadaman komputasi awan besar kami
Cloud

AWS: Inilah yang salah dalam pemadaman komputasi awan besar kami

Amazon Web Services (AWS) jarang mati secara tiba-tiba, tetapi Anda dapat mengharapkan penjelasan terperinci saat pemadaman besar terjadi.

Pemadaman besar terbaru AWS terjadi pada pukul 07:30 PST pada hari Selasa, 7 Desember, berlangsung selama lima jam dan memengaruhi pelanggan yang menggunakan antarmuka aplikasi tertentu di Wilayah AS-EAST-1, termasuk pelanggan utama seperti Disney+, Venmo, Robinhood, dan lainnya. Dalam cloud publik skala AWS, pemadaman selama lima jam adalah insiden besar.

Laporan khusus

Mengelola Multicloud

Mengelola Multicloud

Lebih mudah dari sebelumnya bagi perusahaan untuk mengambil pendekatan multicloud, karena AWS, Azure, dan Google Cloud Platform semuanya berbagi pelanggan. Berikut ini adalah masalah, vendor, dan alat yang terlibat dalam pengelolaan banyak cloud.

Baca selengkapnya

Menurut penjelasan AWS tentang apa yang salah, sumber pemadaman adalah kesalahan dalam jaringan internalnya yang menampung “layanan dasar” seperti pemantauan aplikasi/layanan, Layanan Nama Domain (DNS) internal AWS, otorisasi, dan bagian dari Bidang kontrol jaringan Elastic Cloud 2 (EC2). DNS penting dalam kasus ini karena merupakan sistem yang digunakan untuk menerjemahkan nama domain yang dapat dibaca manusia ke alamat internet numerik (IP).

MELIHAT: Memiliki satu penyedia cloud adalah dekade terakhir

Jaringan internal AWS menopang bagian dari jaringan AWS utama yang terhubung dengan sebagian besar pelanggan untuk memberikan layanan konten mereka. Biasanya, ketika jaringan utama ditingkatkan untuk memenuhi lonjakan permintaan sumber daya, jaringan internal harus ditingkatkan secara proporsional melalui perangkat jaringan yang menangani terjemahan alamat jaringan (NAT) antara dua jaringan.

Namun, pada hari Selasa minggu lalu, penskalaan lintas jaringan tidak berjalan mulus, dengan perangkat AWS NAT di jaringan internal menjadi “kewalahan”, memblokir pesan terjemahan antar jaringan dengan efek knock-on yang parah untuk beberapa layanan yang dihadapi pelanggan yang , secara teknis, tidak terkena dampak langsung.

“Pada pukul 07:30 PST, aktivitas otomatis untuk menskalakan kapasitas salah satu layanan AWS yang dihosting di jaringan AWS utama memicu perilaku tak terduga dari sejumlah besar klien di dalam jaringan internal,” kata AWS dalam postmortemnya.

“Ini menghasilkan lonjakan besar aktivitas koneksi yang membebani perangkat jaringan antara jaringan internal dan jaringan AWS utama, yang mengakibatkan penundaan komunikasi antara jaringan ini.”

Penundaan memicu latensi dan kesalahan untuk layanan dasar yang berbicara di antara jaringan, memicu lebih banyak lagi upaya koneksi yang gagal yang pada akhirnya menyebabkan “masalah kemacetan dan kinerja yang terus-menerus” pada perangkat jaringan internal.

Dengan koneksi antara dua jaringan yang diblokir, tim operasi internal AWS dengan cepat kehilangan visibilitas ke layanan pemantauan real-time dan terpaksa mengandalkan log peristiwa masa lalu untuk mencari tahu penyebab kemacetan. Setelah mengidentifikasi lonjakan kesalahan DNS internal, tim mengalihkan lalu lintas DNS internal dari jalur yang diblokir. Pekerjaan ini selesai dua jam setelah pemadaman awal pada 09:28 PST.

Ini mengurangi dampak pada layanan yang dihadapi pelanggan tetapi tidak sepenuhnya memperbaiki layanan AWS yang terpengaruh atau membuka blokir kemacetan perangkat NAT. Selain itu, tim operasi internal AWS masih kekurangan data pemantauan waktu nyata, yang kemudian memperlambat pemulihan dan pemulihan.

Selain kurangnya visibilitas waktu nyata, sistem penerapan internal AWS terhambat, sekali lagi memperlambat perbaikan. Penyebab utama ketiga dari respons yang tidak optimal adalah kekhawatiran bahwa perbaikan untuk komunikasi jaringan internal-ke-utama akan mengganggu layanan AWS lain yang menghadap pelanggan yang tidak terpengaruh.

“Karena banyak layanan AWS di jaringan AWS utama dan aplikasi pelanggan AWS masih beroperasi secara normal, kami ingin sangat berhati-hati saat membuat perubahan untuk menghindari dampak beban kerja yang berfungsi,” kata AWS.

Jadi, layanan pelanggan AWS apa yang terpengaruh?

Pertama, jaringan AWS utama tidak terpengaruh, jadi beban kerja pelanggan AWS “tidak terpengaruh secara langsung”, kata AWS. Sebaliknya, pelanggan terpengaruh oleh layanan AWS yang mengandalkan jaringan internalnya.

Namun, efek langsung dari kesalahan jaringan internal sangat luas untuk layanan AWS yang dihadapi pelanggan, yang memengaruhi semuanya, mulai dari komputasi, layanan penampung, dan distribusi konten hingga database, virtualisasi desktop, dan alat pengoptimalan jaringan.

Bidang kontrol AWS digunakan untuk membuat dan mengelola sumber daya AWS. Pesawat kontrol ini terpengaruh karena di-host di jaringan internal. Jadi, sementara instans EC2 tidak terpengaruh, EC2 API yang digunakan pelanggan untuk meluncurkan instans EC2 baru terpengaruh. Latensi dan tingkat kesalahan yang lebih tinggi adalah dampak pertama yang dilihat pelanggan pada pukul 07.30 PST.

MELIHAT: Keamanan cloud pada tahun 2021: Panduan bisnis untuk alat penting dan praktik terbaik

Dengan hilangnya kemampuan ini, pelanggan mengalami masalah dengan Amazon RDS (layanan database relasional) dan platform data besar Amazon EMR, sementara pelanggan dengan layanan virtualisasi desktop terkelola Amazon Workspaces tidak dapat membuat sumber daya baru.

Demikian pula, Elastic Cloud Balancers (ELB) AWS tidak terpengaruh secara langsung, tetapi karena ELB API terpengaruh, pelanggan tidak dapat menambahkan instans baru ke ELB yang ada secepat biasanya.

Route 53 (CDN) API juga terganggu selama lima jam, mencegah pelanggan mengubah entri DNS. Ada juga kegagalan login ke AWS Console, latensi yang memengaruhi Amazon Secure Token Services untuk layanan identitas pihak ketiga, penundaan ke CloudWatch, dan gangguan akses ke bucket Amazon S3, tabel DynamoDB melalui VPC Endpoints, dan masalah saat menjalankan fungsi Lambda tanpa server.

Insiden 7 Desember memiliki setidaknya satu ciri dengan pemadaman besar yang terjadi kali ini tahun lalu: itu menghentikan AWS untuk berkomunikasi dengan cepat dengan pelanggan tentang insiden tersebut melalui AWS Service Health Dashboard.

“Penurunan pada sistem pemantauan kami menunda pemahaman kami tentang peristiwa ini, dan kemacetan jaringan mengganggu alat Dasbor Kesehatan Layanan kami dari kegagalan yang tepat ke wilayah siaga kami,” AWS menjelaskan.

Selain itu, pusat kontak dukungan AWS bergantung pada jaringan internal AWS, sehingga staf tidak dapat membuat kasus baru dengan kecepatan normal selama gangguan lima jam.

AWS mengatakan akan merilis versi baru dari Service Health Dashboard awal 2022, yang akan berjalan di beberapa wilayah untuk “memastikan kami tidak mengalami keterlambatan dalam berkomunikasi dengan pelanggan.”

Pemadaman awan memang terjadi. Google Cloud telah berbagi tarif dan Microsoft pada bulan Oktober harus menjelaskan pemadaman delapan jamnya. Meskipun jarang terjadi, pemadaman adalah pengingat bahwa cloud publik mungkin lebih andal daripada pusat data konvensional, tetapi ada yang salah, terkadang menjadi bencana besar, dan dapat memengaruhi sejumlah besar layanan penting.

“Akhirnya, kami ingin meminta maaf atas dampak peristiwa ini bagi pelanggan kami,” kata AWS. “Meskipun kami bangga dengan rekam jejak ketersediaan kami, kami tahu betapa pentingnya layanan kami bagi pelanggan kami, aplikasi dan pengguna akhir mereka, dan bisnis mereka. Kami tahu peristiwa ini berdampak pada banyak pelanggan dengan cara yang signifikan. Kami akan melakukan semua yang kami bisa. untuk belajar dari acara ini dan menggunakannya untuk meningkatkan ketersediaan kami lebih jauh.”

Posted By : hasil hk