Dalam postingan kali ini, kami ingin membagikan detail gangguan layanan yang terjadi di wilayah Virginia Utara (US-EAST-1) pada tanggal 25 November 2020.
Amazon Kinesis mengumpulkan, memproses, dan menganalisis data streaming secara real time. Selain digunakan langsung oleh pelanggan, ini terlibat dalam sejumlah layanan AWS. Layanan ini juga mengalami pemadaman. Pemicu (bukan penyebab utama) dari peristiwa ini adalah penambahan kapasitas layanan yang relatif kecil, yang dimulai pada pukul 02.44 WIB dan berakhir pada pukul 03.47 WIB.
Tentang perangkat Kinesis
Kinesis menggunakan sejumlah besar kelompok sel "ujung belakang" (sel) yang memproses aliran data. Ini adalah kuda kerja Kinesis. Mereka bertanggung jawab untuk distribusi, akses, dan penskalaan untuk streaming. Aliran didistribusikan oleh server front-end ke server back-end menggunakan sharding. Kluster backend "memiliki" banyak pecahan dan menyediakan penskalaan dan isolasi kesalahan yang konsisten. Pekerjaan front-end dalam kasus kami kecil, tapi penting. Ini bertanggung jawab untuk mengautentikasi, membatasi, dan merutekan permintaan ke pecahan utas yang benar pada cluster backend.
Kami menambahkan kapasitas baru ke armada alat berat front-end. Setiap server front-end membentuk cache data, termasuk keanggotaan dan pemilik shard (di antara cluster back-end), membentuk apa yang disebut peta-beling. Ini memperoleh informasi ini dengan mengirimkan permintaan ke layanan yang menyediakan informasi keanggotaan dan mengambil data konfigurasi dari DynamoDB.
Selain itu, setiap server terus memproses pesan dari server ujung depan Kinesis lainnya. Untuk melakukan ini, utas dibuat di OS setiap mesin front-end untuk setiap server front-end. Ketika kapasitas baru ditambahkan, server yang sudah beroperasi di taman frontend mempelajari tentang anggota baru dan membuat aliran yang sesuai. Setiap server front-end yang ada membutuhkan waktu hingga satu jam untuk mengetahui tentang mesin baru.
Diagnostik dan pemecahan masalah
Pada 5:15 PST, pesan kesalahan pertama muncul saat menulis dan mengambil catatan Kinesis. Tim kami segera mulai mempelajari log. Kecurigaan segera jatuh pada kapasitas baru, tetapi beberapa kesalahan sama sekali tidak terkait dengan mesin baru dan, kemungkinan besar, tidak akan pergi ke mana pun, bahkan jika kami menghapus semua kapasitas baru.
Namun demikian, sebagai tindakan pencegahan, kami tetap mulai menghapusnya, di sepanjang jalan mencoba menemukan penyebab kesalahan lainnya. Variasi mereka yang luas memperlambat diagnosis kami. Kami melihat bug di setiap aspek dari semua jenis panggilan yang dilakukan oleh anggota lama dan baru dari armada mesin front-end, dan ini membuatnya cukup sulit untuk memisahkan efek samping dari akar penyebabnya.
Pada 07:51 PST, kami telah mempersempit tersangka menjadi hanya beberapa kandidat dan menentukan bahwa salah satu penyebab yang paling mungkin memerlukan restart front-end lengkap. Tim Kinesis tahu betul bahwa proses ini harus lambat dan detail.
Faktanya adalah bahwa mengisi kartu shard bersaing dengan pemrosesan permintaan masuk untuk sumber daya server front-end. Dengan demikian, membuat server front-end kembali online terlalu cepat akan menciptakan konflik antara dua proses dan menyisakan terlalu sedikit untuk memproses permintaan yang masuk. Hasilnya dapat diprediksi: peningkatan tingkat kesalahan dan peningkatan latensi. Selain itu, server front-end yang lambat dapat dianggap sebagai tanda tidak sehat, yang dapat menyebabkan server tersebut dihapus dari daftar server yang tersedia, yang selanjutnya akan memperlambat proses pemulihan.
Semua solusi yang mungkin melibatkan mengubah konfigurasi setiap server front-end dan memulai ulang. Sementara kandidat utama kami untuk sumber masalah kami (masalah yang tampaknya menekan memori) tampak menjanjikan, jika kami salah, kami berisiko menggandakan waktu pemulihan karena kami harus memperbaiki ulang dan memulai kembali semuanya. Untuk mempercepat restart, bersamaan dengan penyelidikan, kami mulai membuat perubahan pada konfigurasi server front-end, memungkinkan Anda untuk menerima data langsung dari penyimpanan metadata pada saat boot, dan bukan dari front-end tetangga.
alasan utama
Pada pukul 9:39 malam PST, kami akhirnya dapat mengonfirmasi akar penyebab kecelakaan itu. Ternyata itu tidak ada hubungannya dengan memori. Penambahan kapasitas baru mengarah pada fakta bahwa pada semua server front-end, jumlah utas melebihi jumlah maksimum yang dimungkinkan, yang diizinkan oleh konfigurasi sistem. Karena batas terlampaui, cache (kartu pecahan) tidak dapat dibuat. Akibatnya, server front-end tidak dapat meneruskan permintaan ke cluster back-end.
Kami tidak ingin meningkatkan batas utas di OS tanpa pengujian awal, dan karena kapasitas tambahan telah dihapus pada saat itu, kami memutuskan bahwa risiko melebihi batas sistem pada jumlah utas minimal dan terus memulai ulang server. Kelompok pertama frontend baru mulai menerima lalu lintas Kinesis pada pukul 10:07 PST.
Taman mesin front-end terdiri dari ribuan server, dan untuk alasan yang dijelaskan di atas, kami dapat menambahkan server dengan kecepatan tidak lebih dari beberapa ratus per jam. Kami terus perlahan menambahkan lalu lintas ke frontend, mencatat penurunan terus-menerus pada kesalahan layanan Kinesis sejak tengah hari. Layanan benar-benar pulih kembali pada pukul 22:23 PST.
Apa yang telah kami pelajari
Kami telah belajar beberapa pelajaran dari insiden Kinesis dan berencana untuk melakukan koreksi dalam waktu dekat.
- , CPU . , , , . , . , .
- .
- , . , .
- -. - AWS ( CloudWatch) , -.
- (cellularization) ( , ). ( -) . Kinesis , , , . / , , .
Kecelakaan itu juga memengaruhi beberapa layanan yang menggunakan Kinesis.
Amazon Cognito menggunakan Kinesis Data Streams untuk mengumpulkan dan menganalisis pola akses API. Meskipun informasi ini sangat berguna untuk pengoperasian layanan Cognito, informasi ini tidak dijamin akan dikirimkan (upaya terbaik) . Data di-buffer secara lokal untuk membantu layanan mengatasi penundaan atau ketidaktersediaan layanan dalam waktu singkat di layanan Kinesis Data Streams.
Sayangnya, tidak tersedianya Kinesis Data Stream yang berlarut-larut mengungkapkan bug laten dalam kode buffering yang menyebabkan server web Cognito mulai memblokir buffer Kinesis Data Stream. Akibatnya, konsumen Cognito menghadapi kerusakan API dan peningkatan latensi untuk Kumpulan Pengguna dan Pangkalan Identitas Cognito. Pengguna eksternal tidak dapat mengautentikasi atau mendapatkan kredensial AWS sementara.
Pada tahap awal pemadaman, tim Cognito mencoba mengurangi dampak bug Kinesis dengan menambahkan kapasitas tambahan dan dengan demikian meningkatkan kemampuan buffering panggilan ke Kinesis. Pada awalnya, ini memberi efek positif pada layanan, tetapi pada 7:01 PST, tingkat kesalahan meningkat secara signifikan. Secara paralel, tim bekerja untuk mengurangi ketergantungan Cognito pada Kinesis. Pada 10:15, solusi ini diterapkan dan tingkat kesalahan mulai menurun. Pada pukul 12.15, tingkat kesalahan telah turun secara signifikan, dan pada pukul 14.18 PST, Cognito berfungsi normal. Untuk mencegah masalah ini terulang kembali, kami memodifikasi server web Cognito. Mereka sekarang dapat mentolerir kesalahan API Kinesis tanpa menghabiskan buffer mereka (yang menyebabkan masalah pengguna).
CloudWatchmenggunakan Kinesis Data Streams untuk memproses metrik dan log. Mulai pukul 5:15 pagi, CloudWatch mengalami peningkatan kesalahan dan latensi untuk PutMetricData dan PutLogEvents API, dan peringatan diberlakukan
INSUFFICIENT_DATA. Sementara beberapa metrik CloudWatch terus diproses selama pemadaman, kebanyakan dari mereka menjadi korban berbagai kesalahan dan peningkatan latensi.
Pada pukul 17:47 PST, tanda-tanda pemulihan pertama muncul saat Kinesis Data Stream membaik, dan pada pukul 22:31 metrik dan peringatan CloudWatch telah pulih sepenuhnya. Pada jam-jam berikutnya, pemrosesan metrik dan log yang tertunda terus berlanjut. Sementara CloudWatch berjuang dengan bug, klien internal dan eksternal tidak dapat mengirimkan data metrik ke CloudWatch. Akibatnya, ada celah dalam data metrik CloudWatch.
Saat ini, layanan CloudWatch mengandalkan Kinesis untuk mengumpulkan metrik dan log, tetapi timnya akan segera menerapkan perubahan setelah CloudWatch akan menyimpan data selama tiga jam di penyimpanan lokal. Perubahan ini akan memungkinkan pengguna dan layanan yang terkait dengan metrik CloudWatch (termasuk Penskalaan Otomatis) untuk langsung mengakses metrik yang baru dikumpulkan (dalam penyimpanan data CloudWatch lokal). Ide ini telah diterapkan di wilayah AS-TIMUR-1, dan dalam beberapa minggu mendatang kami berencana untuk meluncurkannya secara global.
Dua layanan lagi menjadi sandera masalah dengan metrik CloudWatch:
- Pertama, autoscaling kebijakan berdasarkan metrik CloudWatch menunjukkan latency sampai 05:47, titik di mana CloudWatch mulai bangkit kembali.
- -, Lambda. - CloudWatch. Lambda, , , CloudWatch . 6:15 PST , , -. : . 10:36 PST , .
Peristiwa CloudWatch dan EventBridge mengalami peningkatan kesalahan API dan latensi dalam pemrosesan peristiwa dari pukul 5:15 ET. Setelah meningkatkan ketersediaan, Kinesis EventBridge melanjutkan pengiriman acara baru kepada penerima, sambil memproses simpanan acara di sepanjang jalan.
Layanan Kontainer Elastis (ECS) dan Layanan Kubernetes Elastis (EKS) menggunakan EventBridge dalam alur kerja internal mereka untuk mengelola cluster dan tugas klien. Ini memengaruhi penyediaan cluster baru, menunda penskalaan yang sudah ada, dan memengaruhi de-provisioning tugas. Pada 16:15 PST, sebagian besar masalah ini telah diselesaikan.
Pemberitahuan pelanggan
Selain kesulitan dengan layanan, di awal kejadian, kami mengalami penundaan tertentu dalam mengkomunikasikan informasi tentang status layanan kepada pelanggan.
Kami memiliki dua cara untuk berkomunikasi dengan pelanggan selama acara operasional:
- Dasbor Kesehatan Layanan - Dasbor yang dapat diakses publik untuk memperingatkan masalah operasional yang besar;
- Personal Health Dashboard - untuk pemberitahuan langsung kepada pelanggan yang terpengaruh.
Selama acara seperti ini, kami biasanya memposting informasi ke Dasbor Kesehatan Layanan. Namun, dalam kasus ini, di awal kerusakan, kami tidak dapat memperbarui informasi di Dasbor Kesehatan Layanan, karena alat yang digunakan untuk menerbitkan pembaruan digunakan oleh Cognito yang mengalami crash.
Kami memiliki metode fallback untuk memperbarui Dasbor Kesehatan Layanan dengan dependensi layanan minimal. Ini berfungsi sebagaimana mestinya, tetapi kami mengalami beberapa penundaan saat menerbitkan informasi ke Dasbor Kesehatan Layanan di awal acara. Intinya adalah bahwa alat cadangan ini jauh lebih tidak otomatis dan kurang familiar bagi operator helpdesk.
Untuk memastikan pengiriman pembaruan tepat waktu ke semua pelanggan yang terpengaruh, tim dukungan memanfaatkan Personal Health Dashboard untuk memberi tahu mereka tentang potensi masalah layanan. Kami juga memasang spanduk global dengan informasi terkini di Dasbor Kesehatan Layanan untuk memastikan bahwa pengguna mendapat informasi lengkap tentang insiden tersebut. Hingga akhir kerusakan, kami terus menggunakan kombinasi Dasbor Kesehatan Layanan (dengan ringkasan pada spanduk global dan detail tentang cara kerja layanan tertentu) dan Dasbor Kesehatan Pribadi, tempat kami berusaha agar pelanggan yang terpengaruh oleh masalah dengan layanan tetap mutakhir. Berdasarkan pengalaman kami, kami telah memperkenalkan latihan wajib dengan sistem fallback untuk memposting pesan ke Dasbor Kesehatan Layanan dalam pelatihan teknisi dukungan reguler kami.
...
Akhirnya, saya ingin meminta maaf atas dampak negatif kejadian ini terhadap pelanggan kami. Kami bangga dengan ketersediaan tinggi Amazon Kinesis dan sangat menyadari betapa pentingnya layanan AWS ini dan lainnya bagi pelanggan kami, aplikasi / pengguna akhir mereka, dan bisnis mereka. Kami akan melakukan yang terbaik untuk belajar dari kejadian ini dan menggunakannya untuk lebih meningkatkan aksesibilitas.
PS
Baca juga di blog kami: