Isolasi beban kerja dengan shuffle-sharding

Saat ini, Amazon Route 53 meng-hosting banyak bisnis terbesar di dunia dan situs web paling populer, tetapi awalnya sangat sederhana sekali.

Tanyakan penyedia DNS apa saja tantangan terbesar dan jawabannya adalah menangani serangan penolakan layanan secara terdistribusi (DDoS). DNS dibangun di atas protokol UDP, yang berarti bahwa permintaan DNS dapat dipalsukan di sebagian besar belantara liar internet. Karena DNS juga merupakan infrastruktur vital, kombinasi ini menjadikannya target atraktif bagi aktor-aktor jahat yang mencoba memeras bisnis, “booters” yang bertujuan memicu gangguan karena berbagai alasan, dan pembuat gangguan sesekali yang tampaknya tidak menyadari mereka melakukan kejahatan serius dengan konsekuensi pribadi nyata. Apa pun alasannya, setiap hari ada ribuan serangan DDoS yang dilakukan terhadap banyak domain.

Salah satu pendekatan untuk mengurangi serangan ini adalah dengan menggunakan volume besar kapasitas server. Meskipun penting untuk memiliki dasar kapasitas yang baik, pendekatan ini tidak benar-benar ampuh. Setiap server ditambahkan penyedia berbiaya ribuan dolar, tetapi penyerang dapat menambahkan lebih banyak klien palsu untuk mencuri uang jika mereka menggunakan botnet yang tercemar. Untuk penyedia, menambah volume besar kapasitas server adalah strategi kalah.

Pada saat kami membangun Amazon Route 53, yang paling canggih untuk pertahanan DNS adalah peralatan jaringan khusus yang dapat menggunakan berbagai trik untuk “menggosok” trafik dengan kecepatan sangat tinggi. Kami memiliki banyak peralatan ini di Amazon untuk layanan DNS internal yang ada milik kami, dan kami berbicara dengan vendor perangkat keras tentang apa lagi yang tersedia. Kami dapati bahwa membeli cukup peranti untuk mencakup penuh tiap-tiap domain Route 53 akan menelan biaya puluhan juta dolar dan memperpanjang jadwal selama beberapa bulan untuk pengiriman, pemasangan, dan operasional. Itu tidak sesuai dengan urgensi rencana kami atau dengan upaya kami untuk berhemat, jadi kami tidak pernah mempertimbangkannya dengan serius. Kami harus menemukan cara memanfaatkan sumber daya untuk melindungi hanya domain yang benar-benar mengalami serangan. Kami beralih ke prinsip lama bahwa kebutuhan adalah sumber dari penemuan. Kebutuhan kami adalah untuk dengan cepat membangun layanan DNS uptime 100% kelas dunia dengan sumber daya yang sederhana. Penemuan kami adalah shuffle sharding.

Shuffle sharding sederhana tapi kuat. Bahkan lebih kuat dari yang kita sadari. Kami telah menggunakannya berulang-ulang, dan menjadi pola inti yang memungkinkan AWS memberikan layanan multi-tenant hemat biaya yang memberi pengalaman single-tenant kepada setiap pelanggan.

Untuk melihat cara kerja shuffle sharding, pertama-tama pertimbangkan bagaimana suatu sistem dapat dibuat lebih terukur dan tangguh melalui sharding biasa. Bayangkan sebuah sistem atau layanan terukur horizontal yang terdiri dari delapan pekerja. Gambar berikut mengilustrasikan pekerja dan permintaan mereka. Pekerja dapat berupa server, atau antrian, atau database, apa pun “itu” yang membentuk sistem Anda.

Tanpa sharding (pecahan), armada pekerja menangani semua pekerjaan. Setiap pekerja harus dapat menangani permintaan apa pun. Ini bagus untuk efisiensi dan redundansi. Jika seorang pekerja gagal, tujuh lainnya dapat menyerap pekerjaan, sehingga kapasitas kendur yang relatif sedikit diperlukan dalam sistem. Namun, masalah besar muncul jika kegagalan dapat dipicu jenis permintaan tertentu, atau oleh banjir permintaan, seperti serangan DDoS. Dua gambar berikut ini menunjukkan gencarnya serangan semacam itu.

Masalah ini akan menyingkirkan pekerja pertama yang terdampak, tetapi kemudian terus mengalir melalui pekerja lain saat pekerja yang tersisa mengambil alih. Masalah ini dapat dengan cepat mengambil semua pekerja, dan seluruh layanan.

Lingkup dampak untuk kegagalan semacam ini adalah “segala sesuatu dan semua orang.” Seluruh layanan ambruk. Tiap pelanggan terkena dampak. Seperti yang kita katakan dalam rekayasa ketersediaan: Ini tidak optimal.

Dengan sharding biasa kita bisa melakukan yang lebih baik. Jika kita membagi armada menjadi 4 bagian pekerja, kita dapat menukar efisiensi dengan cakupan dampak. Dua gambar berikut ini menunjukkan bagaimana sharding dapat membatasi dampak serangan DDoS.

Pada contoh ini, setiap shard memiliki dua pekerja. Kami membagi sumber daya, seperti domain pelanggan, di seluruh shard. Kami masih memiliki redundansi, tetapi karena hanya ada dua pekerja per shard, kami harus menjaga lebih banyak kapasitas kendur dalam sistem untuk menangani setiap kegagalan. Dengan begitu, ruang lingkup dampak sangat jauh berkurang.

Di dunia sharding ini, lingkup dampak berkurang dengan jumlah shard. Di sini dengan empat shard, jika seorang pelanggan menemui masalah, maka shard yang menampungnya mungkin terkena dampak, juga semua pelanggan lain di shard itu. Namun, shard itu hanyalah seperempat dari keseluruhan layanan. Dampak 25 persen jauh lebih baik dari dampak 100 persen. Dengan shuffle sharding, kita dapat melakukan lebih baik secara eksponensial.

Dengan shuffle sharding kami menciptakan shard virtual dua pekerja masing-masing, dan kami menetapkan pelanggan atau sumber daya kami, atau apa pun yang ingin kami isolasi, ke salah satu shard virtual tersebut.

Gambar berikut menunjukkan contoh tata letak shuffle sharding dengan delapan pekerja dan delapan pelanggan, yang masing-masing ditetapkan untuk dua pekerja. Biasanya kami memiliki lebih banyak pelanggan daripada pekerja, tetapi lebih mudah diikuti jika kami menjaga segala sesuatu tetap dalam jumlah lebih kecil. Kami akan fokus pada dua pelanggan—pelanggan pelangi dan pelanggan mawar.

Dalam contoh kami, kami memasangkan pelanggan pelangi untuk pekerja pertama dan pekerja keempat. Kombinasi dua pekerja tersebut menjadi shuffle shard pelanggan. Pelanggan lain akan ke shard virtual berbeda, dengan dua pekerja mereka sendiri. Sebagai contoh, pelanggan mawar juga dipasangkan dengan pekerja pertama, tetapi pekerja lainnya adalah pekerja kedelapan.

Jika pelanggan pelangi yang dipasangkan dengan pekerja satu dan empat menemui masalah (seperti permintaan beracun, atau membanjirnya permintaan), masalah itu akan berdampak pada shard virtual, tetapi tidak akan sepenuhnya berdampak pada shuffle shard lainnya. Bahkan, paling banyak salah satu pekerja shuffle shard lain akan terdampak. Jika pemohon toleran kesalahan dan dapat mengatasinya (dengan mencoba lagi misalnya), layanan dapat berlanjut tanpa gangguan bagi pelanggan atau sumber daya pada sisa shard, seperti ditunjukkan gambar berikut.

Dengan kata lain, meskipun semua pekerja yang melayani pelangi mungkin mengalami masalah atau serangan, pekerja lain tidak terpengaruh sama sekali. Untuk pelanggan, ini berarti meskipun pelanggan mawar dan pelanggan bunga matahari masing-masing berbagi pekerja dengan pelangi, mereka tidak terpengaruh. Pelanggan mawar bisa mendapatkan layanan dari pekerja delapan, dan bunga matahari bisa mendapatkan layanan dari pekerja enam, seperti yang terlihat pada gambar berikut.

Ketika masalah terjadi, kita masih bisa kehilangan seperempat dari seluruh layanan, tetapi cara pelanggan atau sumber daya ditetapkan berarti bahwa lingkup dampak dengan shuffle sharding jauh lebih baik. Dengan delapan pekerja, terdapat 28 kombinasi unik dari dua pekerja, yang berarti terdapat 28 kemungkinan shuffle shard. Jika terdapat ratusan atau lebih pelanggan, dan kami memasangkan setiap pelanggan ke shuffle shard, maka lingkup dampak masalah hanyalah 1/28. Ini artinya 7 kali lebih baik dari sharding biasa.

Sangat menarik untuk melihat bahwa jumlahnya menjadi lebih baik secara eksponensial dengan semakin banyak pekerja dan pelanggan yang Anda miliki. Sebagian besar tantangan penskalaan menjadi lebih sulit di dimensi tersebut, tetapi shuffle sharding menjadi lebih efektif. Faktanya, dengan pekerja yang cukup, akan ada lebih banyak shuffle shard daripada pelanggan, dan setiap pelanggan dapat diisolasi.

Bagaimana semua ini membantu Amazon Route 53? Dengan Route 53, kami memutuskan untuk mengatur kapasitas kami menjadi total 2048 server nama virtual. Server-server ini virtual karena tidak sesuai dengan server fisik yang menampung Route 53. Server-server ini dapat dipindahkan untuk membantu mengelola kapasitas. Kami kemudian menetapkan setiap domain pelanggan ke shuffle shard dari empat server nama virtual. Dengan angka-angka itu, yang mengejutkan ada 730 miliar kemungkinan shuffle shard. Banyak sekali kemungkinan shuffle shard sehingga kami dapat menetapkan shuffle shard unik untuk setiap domain. Sebenarnya, kami dapat melangkah lebih jauh, dan memastikan bahwa tidak ada domain pelanggan yang akan berbagi lebih dari dua server nama virtual dengan domain pelanggan lainnya.

Hasilnya mencengangkan. Jika domain pelanggan ditargetkan untuk serangan DDoS, empat server nama virtual yang ditetapkan untuk domain itu akan meningkatkan trafik, tetapi tidak ada domain pelanggan lain yang akan melihatnya. Kami tidak mundur ke pelanggan target yang kurang beruntung. Shuffle Sharding berarti kami dapat mengidentifikasi dan mengisolasi pelanggan target ke kapasitas serangan khusus. Selain itu, kami juga mengembangkan lapisan milik kami sendiri dari pemilah trafik AWS Shield. Namun, shuffle sharding sangat jauh berbeda yaitu memastikan bahwa pengalaman pelanggan Route 53 secara keseluruhan lancar, bahkan jika peristiwa ini terjadi.

Kami melanjutkan penanaman shuffle sharding di banyak sistem kami yang lain. Selain itu, kami telah menghasilkan penyempurnaan, seperti shuffle sharding rekursif, di mana kami memilah item di berbagai lapisan, sehingga mengisolasi pelanggan dari pelanggan. Shuffle sharding sangat mudah beradaptasi. Merupakan cara cerdas mengatur sumber daya yang ada. Biasanya juga tanpa biaya tambahan, jadi ini merupakan peningkatan besar yang bisa didorong dengan kesederhanaan dan ekonomi.

Jika Anda tertarik untuk menggunakan shuffle sharding sendiri, lihat pustaka Route 53 Infima sumber terbuka kami. Library ini mencakup beberapa implementasi shuffle sharding berbeda yang dapat digunakan untuk menetapkan atau mengatur sumber daya.

Coba beberapa prinsip yang telah Anda pelajari di sini dengan laboratorium praktik langsung.