Ini adalah penyimpangan singkat dalam seri artikel saat ini tentang cara menghindari memperkenalkan layanan untuk berbagai entitas. Pembicaraan yang menarik saat makan malam memicu pemikiran yang saya putuskan untuk dituliskan.

Hukum Amdahl

Pada tahun 1967, Gene Amdahl menentang komputasi paralel. Dia berpendapat bahwa pertumbuhan produktivitas terbatas karena hanya sebagian tugas yang dapat diparalelkan. Ukuran sisa "bagian berurutan" berbeda dalam tugas yang berbeda, tetapi selalu ada di sana. Argumen ini kemudian dikenal sebagai hukum Amdal.

Jika Anda membuat grafik "akselerasi" tugas tergantung pada jumlah prosesor paralel yang dialokasikan untuknya, Anda akan melihat yang berikut:


Ini adalah grafik asimtotik untuk fragmen yang tidak dapat diparalelkan ("bagian berurutan"), oleh karena itu ada batas atas untuk akselerasi maksimum

Dari Amdal ke USL

Yang menarik tentang hukum Amdal adalah bahwa pada tahun 1969 sebenarnya ada sangat sedikit sistem multiprosesor. Rumus didasarkan pada prinsip lain: jika bagian berurutan dalam tugas sama dengan nol, maka ini bukan satu tugas, tetapi beberapa.

Neil Gunther memperluas hukum Amdahl berdasarkan pengamatan pengukuran kinerja banyak mesin dan mengembangkan Hukum Skalabilitas Universal (USL). Ini menggunakan dua parameter: satu untuk "kompetisi" (yang mirip dengan bagian berurutan), dan yang kedua untuk "inkonsistensi" (ketidakkonsistenan). Inkonsistensi terkait dengan waktu yang dihabiskan untuk mengembalikan konsistensi, yaitu pandangan umum tentang dunia prosesor yang berbeda.

Dalam satu CPU, negosiasi overhead terjadi karena caching. Ketika satu inti memodifikasi baris cache, ia memberi tahu kernel lain untuk mengambil baris ini dari cache. Jika semua orang membutuhkan saluran yang sama, mereka menghabiskan waktu memuatnya dari memori utama. (Ini adalah deskripsi yang sedikit disederhanakan ... tetapi dalam kata-kata yang lebih tepat, masih ada biaya negosiasi).

Semua node database dikenakan biaya koordinasi karena algoritma yang cocok dan menyimpan urutan data. Hukuman dibayarkan ketika mengubah data (seperti dalam kasus basis data transaksional) atau ketika membaca data dalam kasus repositori yang akhirnya disepakati.

Efek USL

Jika Anda membangun bagan USL tergantung pada jumlah prosesor, garis hijau akan muncul:


Garis ungu menunjukkan bahwa hukum Amdahl akan diprediksi

Perhatikan bahwa garis hijau mencapai puncak dan kemudian menurun. Ini berarti bahwa ada sejumlah node di mana kinerja maksimum. Tambahkan lebih banyak prosesor - dan kinerja berkurang . Saya melihat ini dalam pengujian stres nyata.

Orang sering ingin menambah jumlah prosesor dan meningkatkan produktivitas. Ada dua cara untuk melakukan ini:

1. Kurangi bagian berurutan
2. Mengurangi biaya persetujuan

USL dalam kelompok manusia?

Mari kita coba analoginya. Jika "tugas" komputasi adalah sebuah proyek, maka kita dapat mewakili jumlah orang dalam proyek sebagai jumlah "prosesor" yang melakukan pekerjaan.

Dalam hal ini, bagian sekuensial adalah bagian dari pekerjaan yang hanya dapat dilakukan secara berurutan, langkah demi langkah. Ini mungkin menjadi topik untuk artikel mendatang, tetapi sekarang kami tidak tertarik pada esensi dari bagian berurutan.

Kami sepertinya melihat analogi langsung dengan biaya rekonsiliasi. Terlepas dari waktu yang dihabiskan anggota tim untuk memulihkan pandangan umum tentang dunia, biaya penyelarasan hadir.

Untuk lima orang di sebuah ruangan, biaya ini minimal. Gambar lima menit dengan spidol di papan tulis seminggu sekali atau lebih.

Untuk tim besar di beberapa zona waktu, denda dapat tumbuh dan diresmikan. Dokumen dan penelusuran. Presentasi untuk tim dan sebagainya.

Dalam beberapa arsitektur, rekonsiliasi tidak begitu penting. Bayangkan sebuah tim dengan karyawan di tiga benua, tetapi masing-masing bekerja pada satu layanan yang menggunakan data dalam format yang ditentukan secara ketat dan membuat data dalam format yang ditentukan dengan ketat. Mereka tidak membutuhkan konsistensi sehubungan dengan perubahan dalam proses, tetapi mereka membutuhkan konsistensi terhadap perubahan dalam format.

Terkadang alat dan bahasa dapat mengubah biaya rekonsiliasi. Salah satu argumen yang mendukung pengetikan statis adalah membantu mengetik dalam sebuah tim. Intinya, tipe dalam kode adalah mekanisme untuk menerjemahkan perubahan dalam model dunia. Dalam bahasa yang diketik secara dinamis, kita memerlukan artefak sekunder (tes unit atau pesan obrolan), atau kita perlu membuat batasan di mana beberapa departemen sangat jarang mengembalikan konsistensi dengan yang lain.

Semua metode ini bertujuan mengurangi biaya koordinasi. Ingat bahwa penskalaan berlebihan menyebabkan penurunan throughput. Jadi, jika Anda memiliki biaya koordinasi yang tinggi dan terlalu banyak orang, maka tim secara keseluruhan bekerja lebih lambat. Saya melihat tim di mana kami bisa memotong setengah orang dan bekerja dua kali lebih cepat. USL dan biaya rekonsiliasi sekarang membantu untuk memahami mengapa hal ini terjadi - ini lebih dari sekedar pembuangan sampah. Ini tentang mengurangi overhead pertukaran model mental.

Dalam The Loop of Fear, saya merujuk pada basis kode di mana pengembang tahu tentang perlunya perubahan skala besar, tetapi takut tidak sengaja membahayakan. Ini berarti bahwa tim yang kelebihan inflasi belum mencapai konsensus. Tampaknya sangat sulit untuk berdamai setelah kehilangan itu. Ini berarti bahwa mustahil untuk mengabaikan biaya koordinasi.

USL dan layanan microser

Menurut pendapat saya, USL menjelaskan minat pada layanan mikro. Dengan membagi sistem besar menjadi bagian yang lebih kecil dan lebih kecil yang digunakan secara terpisah satu sama lain, Anda mengurangi bagian berurutan dari pekerjaan tersebut. Dalam sistem besar dengan sejumlah besar peserta, bagian berurutan tergantung pada jumlah upaya untuk mengintegrasikan, menguji, dan menyebarkan. Keuntungan dari layanan microser adalah bahwa mereka tidak memerlukan pekerjaan integrasi, pengujian integrasi, atau keterlambatan dalam penyebaran yang disinkronkan.

Tetapi biaya pencocokan berarti Anda mungkin tidak mendapatkan akselerasi yang diinginkan. Mungkin analogi ini sedikit tegang di sini, tapi saya pikir mungkin untuk mempertimbangkan perubahan antarmuka antara layanan-layanan mikro yang memerlukan rekonsiliasi antar tim. Jika ini terlalu banyak, maka Anda tidak akan mendapatkan manfaat yang diinginkan dari layanan microser.

Apa yang harus dilakukan?

Saran saya: lihat arsitektur, bahasa, alat, dan tim yang digunakan. Pikirkan di mana waktu hilang untuk rekonsiliasi ketika orang membuat perubahan pada model sistemik dunia.

Cari celahnya . Kesenjangan antara batas internal sistem dan perpecahan dalam tim.

Gunakan lingkungan untuk mengkomunikasikan perubahan sehingga proses rekonsiliasi berlangsung untuk semua orang, bukan secara individu.

Lihatlah komunikasi tim Anda. Berapa banyak waktu dan upaya yang diperlukan untuk memastikan konsistensi? Mungkin membuat perubahan kecil dan mengurangi kebutuhan untuk itu?