Saya menggambarkan
wawancara pengkodean yang khas sebelumnya. Selain pengkodean, hampir selalu ada pertanyaan tentang desain sistem. (Besar) Desain Sistem. Dalam kasus wawancara pada SRE, ini adalah binatang yang bahkan lebih menarik (seperti untuk saya) - NALSD. Desain sistem besar non-abstrak. Perbedaan utama antara SWE dan SRE tepatnya dalam huruf-huruf ini "NA".
Apa bedanya, dan bagaimana mempersiapkannya? Mari kita lihat sebuah contoh. Sebagai contoh, kami akan mengambil sesuatu yang sangat material, sesuatu yang tidak seorang pun akan meminta wawancara nyata (di Google) :)
Misalnya - mari kita merancang perpustakaan. Untuk buku kertas, yang biasa. Seluruh teks di bawah ini ditulis dalam satu duduk dalam waktu sekitar satu jam untuk secara kasar menunjukkan apa yang dapat Anda lakukan, dan apa yang penting untuk dilakukan. Jadi maafkan saya untuk kebingungan, tapi saya pikir begitu (dan karena itu ada).
Pertanyaan NALSD: Desain perpustakaan umum.
Pertama, kami tertarik pada karakteristik beban, atau kami membuat asumsi sendiri yang masuk akal. Karena ini adalah pertanyaan tentang sistem yang dapat diskalakan, ini adalah kota minimum satu juta orang. Ada baiknya mempertimbangkan opsi - satu gedung besar, atau perpustakaan distrik plus penyimpanan. Sepertinya saya yang terakhir lebih masuk akal. Apalagi kalau bukan kota, tapi kota.
Jadi, kami akan fokus saat ini pada sistem satu kota (dengan beberapa pemesanan, kami dapat menerapkan mekanisme serupa di tingkat yang lebih tinggi untuk penskalaan ke banyak kota). Jadi, kota ini sejuta orang. Kami membulatkan angka untuk kenyamanan estimasi - biarlah ada 1 juta pembaca. Pembaca akan membaca kapan saja tanpa tergantung satu sama lain. Jadi kita bisa mengetahuinya sebagai proses Poisson sederhana. Tetapi penghitungan "dalam pelarian" biasanya akan sulit, jadi ambil langkah penyederhanaan lainnya dan ambil saja 1% pembaca ingin mengambil buku sehari. Secara total, untuk perhitungan lebih lanjut, kami mengambil 10.000 buku per hari.
Tugas kami adalah menyediakan kemungkinan untuk menerbitkan 10.000 buku sehari (ditambah pengembalian 10.000 buku yang sama pada hari lain di masa depan, omong-omong) di kota dengan populasi satu juta. Pada titik ini, pertanyaan tentang perpustakaan-mono atau distrik sudah hilang (ngomong-ngomong, untuk seluruh juta menjadi pembaca potensial, mereka harus dapat pergi ke perpustakaan dalam jumlah waktu yang wajar, jika tidak keinginan untuk mengambil buku pasti akan jatuh pada batas waktu). Jadi, kita perlu mengevaluasi kapasitas masing-masing perpustakaan setempat. Adalah hak untuk melakukan ini dengan mempertimbangkan kepadatan dan jangkauan populasi, tetapi karena ini tidak banyak mempengaruhi sistem itu sendiri, untuk kesederhanaan perhitungan, kami akan menganggap bahwa kami menempatkannya secara merata. Tapi ini tetap tidak berarti bagaimana kita bisa membagikannya. Jelas, menempatkan 10.000 perpustakaan dengan satu buku secara merata di seluruh kota tidak masuk akal, jadi Anda perlu memahami apa yang masuk akal. Kami pergi ke level di bawah.
Jadi, satu perpustakaan. Agar masuk akal, sebagian besar dari mereka yang datang harus menemukan buku yang mereka butuhkan. Ini berarti bahwa kita harus menyimpan catatan dan perkiraan pertanyaan paling populer dan menyiapkan buku-buku ini. Maka, kita perlu menjaga bermacam-macam pada prinsipnya. Begitu saja, saya akan mengatakan bahwa perpustakaan lokal harus memiliki setidaknya 1.000 item, yang paling atas dalam banyak salinan, lebih banyak yang teratas, yang lebih sedikit. Rata-rata buku di perpustakaan kami dibaca dari 3 hari hingga 2 minggu (pada kenyataannya, karakteristiknya tergantung pada buku, analisis terpisah diperlukan di sini), kami mengambilnya sama dengan rata-rata minggu dan melanjutkan. Artinya, buku yang diambil hilang selama sekitar satu minggu, sehingga buku-buku teratas perlu ditebar selama seminggu (maka mereka akan mulai pulih dari pengembalian).
Mari kita ambil faktor inflasi rata-rata 6. Jadi kapasitas penyimpanan dimulai dari 6.000 buku. Kurang berarti bahwa ini hanya puncak kecil, yang masih dapat membantu dalam beberapa kasus (misalnya, sebuah pulau dengan "senja" di supermarket dekat ruang bermain anak-anak), tetapi kami akan membiarkannya di luar untuk saat ini.
Dalam keadaan "keseimbangan", mereka kembali dan mengambil kira-kira sama sehari, plus atau minus pencar, tetapi kita masih membutuhkan kemampuan untuk menerima peningkatan jumlah jumlah pengembalian puncak (misalnya, karena sinkronisasi eksternal seperti liburan atau perubahan mode). Itu benar - untuk disimulasikan. Tapi di sini dan sekarang kita akan mengambil yang ketiga sebagai penyangga. Secara total, kami mendukung 6.000 buku yang tersedia untuk penerbitan, ditambah tempat untuk 2.000 cadangan lainnya.
Jadi, kami membutuhkan unit yang dapat menyimpan 8000 buku. Pengisian ulang setiap hari sangat mahal, yang berarti untuk satu atau dua minggu. Dua minggu, 6.000 buku, dengan bias pengembalian ini sekitar 300 hari. Pada saat pembukaan, kami dapat mencetak semua 8000 buku untuk membuat awal 2000 yang beredar sebelum yang pertama kembali. 2000 selama 3 hari = sekitar 600 buku per hari, ditambah buffer = 800 buku per hari.
Mari kita perkirakan batas bandwidth dan penyimpanan. Satu buku membutuhkan rata-rata 2 sentimeter ruang linear, 8000 buku - 160 meter. putar 4 kali secara vertikal, 40 meter. Kami masuk ke rak 5 meter, kami mendapat 8 rak dari 4 rak sepanjang 5 meter. Seorang pustakawan (atau pustakawan-robo) akan dapat bekerja dengan dua rak, mengekstraksi satu buku akan memakan waktu hingga 5 detik untuk mencapainya, 5 detik untuk keluar atau meletakkan buku, mundur 5 detik, dengan total 15 detik. 4 pustakawan akan memberi kami sekitar 15 buku per menit maksimum, yaitu sekitar 900 buku per jam dari gudang kira-kira.
Kami menambahkan waktu untuk memproses permintaan (10-an), pencarian (5-an), masuk ke sistem penerimaan dan penerbitan (2s) => 400 buku per jam. Sehingga penyimpanan pada puncaknya dapat menerbitkan-menerima 400 buku per jam, oleh karena itu 800 buku per hari dapat dijangkau dalam 2 jam kerja.
Sekarang kami mempertimbangkan karakteristik lain: untuk memberikan 400 buku per jam oleh 4 orang, perlu menampung 100 orang di ruang tunggu dalam antrian di depan jendela pemrosesan, dan agar orang-orang ini tidak membuat keramaian di pintu masuk dan keluar. Artinya, grup masuk harus melewati 400 orang per jam di kedua arah. Ternyata pembatas utama bahkan tidak akan penyimpanan, tetapi kapasitas aula dan kelompok pintu masuk.
Ini berarti bahwa akan dimungkinkan untuk menemukan rasio penyimpanan dan ruang yang optimal dengan perhitungan yang lebih akurat.
Jadi, dengan unit diurutkan, kami kembali ke level di atas. Kami memperkirakan total muatan di perpustakaan sekitar 10.000 buku per hari, kami menghitung satu unit pada 800 buku per hari, yaitu, kami membutuhkan 12,5 unit. Dengan distribusi geografis di sekitar kota, satu atau dua unit alternatif (di perbatasan kota) atau bahkan 3-4 (di dalam) akan dapat dijangkau oleh masing-masing pembaca, yang memungkinkan Anda sedikit memuluskan puncak lalu lintas dan / atau meningkatkan permintaan untuk posisi tertentu.
Kita juga tahu bahwa setiap saat perpustakaan dapat ditutup (kebakaran, inspeksi sanitasi, mengecat pegangan lemari es atau yang lainnya), dengan peningkatan jumlahnya, kemungkinan dua jatuh dari kehidupan bertepatan, jadi kita membutuhkan unit cadangan untuk setiap 5-6 unit. Secara total, 15 unit harus memastikan kinerja yang diperlukan, asalkan mereka mempertahankan perkiraan stok di gudang mereka.
Untuk mempertahankan perkiraan stok, kami perlu memperbarui satu atau dua kali seminggu (kami pikir di atas dua) sekitar setengah dari bermacam-macam untuk mengikuti tren dan sebagainya. Ini berarti bahwa setiap unit perlu mengangkut dan mengekspor 4.000 buku setiap dua minggu. Dengan setiap impor dan ekspor, 4.000 buku yang sama ini harus dihapus dari repositori dan kemudian yang lain diletakkan di sana. Pada 400 buku per jam, memperbarui bermacam-macam akan memakan waktu 10 jam pada beban maksimum. Yang, tampaknya, masih tidak terlalu buruk, sekali lagi, dengan pemuatan massal, banyak hal akan berjalan lebih cepat, namun, mempertahankan bermacam-macamnya membutuhkan waktu 5 kali lebih banyak daripada bekerja dengan penduduk.
Buku rata-rata (2cm * 20cm * 30cm) adalah sekitar 1,5l, yaitu 4000 buku = 6 meter kubik. Mudah masuk ke dalam satu gazelle. Berat satu meter kubik kertas adalah 600 kg, yaitu 6 meter kubik adalah 3,6 ton. Daya dukung rusa adalah satu setengah ton, jadi tiga rusa akan diperlukan. Ditambah satu cadangan. Kami memiliki 15 unit, diperbarui setiap 2 minggu, dengan distribusi yang merata kami berada di batasnya, kami harus menambahkan gazelle lain.
Dan kami tidak punya waktu untuk memikirkan di mana dan di mana gazelle ini diangkut, sehingga gudang pemasok dan titik-titik pembongkaran buku yang kehilangan relevansi muncul pada diagram ...
Jadi waktu sudah habis. Apa yang tidak biasa pada pertanyaan NALSD? Skalabilitas harus dalam Desain Sistem Besar. Yang utama adalah
konkret .
Saya membuat banyak asumsi dan asumsi di atas, tetapi semua perkiraan selanjutnya didasarkan pada yang sebelumnya. Untuk angka, saya juga mencoba memberikan "cara mengevaluasi dengan benar", namun, sangat mudah untuk melupakannya, Anda lelah dan melupakannya. Masih sangat mudah untuk tetap dengan beberapa nomor dari memori, tanpa penjelasan ... Tapi karena desainnya konkret, jika ada asumsi yang ternyata salah, maka bisa diperbaiki dan baru saja diceritakan nanti.
Seperti yang saya ingat sekarang, dalam wawancara saya dengan perkiraan saya mengambil IOPS dari disk 600, hanya karena saya baru-baru ini mengoptimalkannya dan bekerja keras dengan satu array, di mana _array_ membagikan 600 IOPS ... Orang yang diwawancarai bertanya kepada saya sedikit terkejut kemudian - 600 IOPS ke disk? : DSelama wawancara, pewawancara dapat memperbaiki asumsi Anda. Atau tambahkan semacam pembatasan (yang tidak Anda ketahui, tidak pikirkan, tidak tanya, atau hanya perubahan TK yang biasa saja). Pada saat yang sama, karena Anda beroperasi secara eksklusif dengan nomor-nomor tertentu, ini hanya pembaruan sepele dari angka-angka itu.
Jika penyesuaian asumsi menyebabkan desain ulang sistem, ini adalah kesalahan desain, atau penyesuaian yang salah, atau melampaui penerapan sistem, yang juga bukan situasi yang jarang terjadi dalam kehidupan nyata. Penting untuk tidak melewatkan momen seperti itu, dan mengevaluasi angka yang diterima untuk kenyataan baik selama tahap desain dan dengan penyesuaian apa pun.
Sebagai SRE, kami berkewajiban untuk berpikir dalam hal penskalaan sistem nyata di bawah batasan nyata perangkat keras nyata. Mungkin ada
algoritma yang sangat baik yang menukar biaya waktu yang sangat besar dengan sejumlah kecil memori ... Tapi tetap saja, Anda tidak dapat meletakkan petabyte RAM pada satu inti prosesor dalam kondisi nyata. Jadi jika kita memiliki petabyte RAM, maka kita memiliki setidaknya sepuluh ribu prosesor. Atau dua puluh. Atau tiga puluh. Dan kita harus mencari yang optimal, bukan global, tetapi di sini dan sekarang, dalam kondisi yang diberikan.
Anda tidak perlu mengingat angka pastinya, tetapi Anda harus memiliki gagasan tentang urutannya: IOPS yang sama, yang dimiliki HDD sekitar seratus, dan SSD memiliki ratusan ribu. Tetapi ratusan ribu ini sejalan dengan rasio biaya satu terabyte HDD dengan biaya satu terabyte SSD sebagai satu banding tiga menjadi empat. Dan ini tidak termasuk harness - tempat di rak, pisau untuk mereka, port pada sakelar dan hal-hal lain yang berhenti menjadi satu sen ketika tagihan masuk ke petabyte.
Sekarang bersandar sedikit di kursi Anda, santai, dan mencoba merancang sistem untuk memasok telur ayam segar dengan berlangganan.
Jika ada keinginan untuk berbagi dengan rekan-rekan berbahasa Inggris, ada
pilihan dalam bahasa Inggris (dan juga dalam
hub bahasa Inggris ).