Selama hampir 20 tahun, Google telah menyediakan sistem skala besar dan rumit yang tak terbayangkan yang sensitif terhadap permintaan pengguna. Mesin pencari Google menemukan jawaban untuk pertanyaan apa pun dalam sepersekian detik, Google memetakan dengan akurasi tertinggi mencerminkan lanskap terestrial, dan Google mail tersedia dalam mode 365/24/7 dan, pada dasarnya, telah menjadi penyimpanan cloud publik pertama. Apakah sistem ini sempurna? Tidak, mereka juga gagal, rusak dan menjadi usang, seperti peralatan lainnya. Kami tidak memperhatikannya. Masalahnya adalah bahwa selama lebih dari sepuluh tahun, Google telah mengembangkan teknologi Rekayasa Keandalan Situs yang unik, yang memastikan operasi tanpa gangguan dan pengembangan progresif sistem perangkat lunak dari segala kompleksitas. Buku ini adalah gudang pengalaman yang diakumulasikan oleh Google selama bertahun-tahun, karya kolektif banyak spesialis luar biasa dan sumber daya yang tak terpisahkan bagi setiap insinyur yang ingin mengembangkan dan memelihara produk apa pun dengan kualitas tertinggi dan paling efisien.
SRE Google dalam hal SRE
Pusat data Google (pusat data) sangat berbeda dari pusat data tradisional dan "peternakan" server kecil. Perbedaan-perbedaan ini menimbulkan masalah tambahan dan peluang tambahan. Bab ini membahas tantangan dan peluang khusus untuk pusat data Google dan memperkenalkan terminologi yang akan digunakan di seluruh buku ini.
PeralatanSebagian besar sumber daya komputasi Google terletak di pusat data yang dirancang oleh perusahaan, yang memiliki sistem catu daya sendiri, sistem pendingin, jaringan internal, dan peralatan komputasi [Barroso et al., 2013]. Tidak seperti pusat data biasa yang disediakan oleh penyedia untuk pelanggan mereka, semua pusat data Google dilengkapi dengan hal yang sama1. Untuk menghindari kebingungan antara perangkat keras server dan perangkat lunak server, dalam buku ini kami menggunakan terminologi berikut:
- mesin (komputer) - unit peralatan (atau, mungkin, mesin virtual);
- server - unit perangkat lunak yang mengimplementasikan layanan.
Server apa pun dapat dijalankan pada mesin, oleh karena itu kami tidak mengalokasikan komputer tertentu untuk program server tertentu. Misalnya, kami tidak memiliki mesin khusus yang menjalankan server mail. Alih-alih, sumber daya dialokasikan oleh sistem manajemen kluster Borg kami.
Kami memahami bahwa penggunaan istilah "server" semacam itu tidak standar. Lebih umum untuk menetapkan dua konsep sekaligus: program yang melayani koneksi jaringan, dan pada saat yang sama mesin yang menjalankan program tersebut, tetapi ketika kita berbicara tentang kekuatan komputasi Google, perbedaan antara keduanya adalah signifikan. Segera setelah Anda terbiasa dengan interpretasi kami terhadap kata "server", akan menjadi lebih jelas bagi Anda mengapa penting untuk menggunakan terminologi khusus semacam itu tidak hanya secara langsung di Google, tetapi di seluruh buku ini.
Dalam gbr. 2.1 mendemonstrasikan konfigurasi pusat data Google.
- Lusinan mobil diletakkan di rak.
- Rak berdiri dalam barisan.
- Satu atau lebih baris membentuk sebuah cluster.
- Biasanya di gedung pusat data (DPC), atau pusat data, beberapa cluster berada.
- Beberapa gedung pusat data yang berdekatan satu sama lain membentuk kampus.
Di dalam setiap pusat data, semua mesin harus dapat berkomunikasi secara efektif satu sama lain, jadi kami membuat saklar virtual sangat cepat (switch) dengan puluhan ribu port. Ini dimungkinkan dengan menghubungkan ratusan sakelar yang dikembangkan oleh Google menjadi "pabrik" berdasarkan topologi jaringan Clos [Clos, 1953], yang disebut Jupiter [Singh et al., 2015]. Pada konfigurasi maksimumnya, Jupiter mendukung throughput 1,3 Pb / s antar server.
Pusat data terhubung satu sama lain menggunakan jaringan backbone B4 global kami [Jain et al., 2013]. B4 memiliki arsitektur jaringan yang dapat dikonfigurasi perangkat lunak dan menggunakan protokol komunikasi terbuka OpenFlow. B4 menyediakan bandwidth lebar untuk sejumlah sistem dan menggunakan kontrol lebar saluran yang fleksibel untuk memaksimalkan nilai rata-rata [Kumar et al., 2015].
Perangkat lunak sistem yang "mengatur" peralatan
Perangkat lunak yang menyediakan manajemen dan administrasi peralatan kami harus mampu menangani sistem besar. Kegagalan perangkat keras adalah salah satu masalah utama yang dipecahkan dengan bantuan perangkat lunak. Mengingat sejumlah besar komponen perangkat keras dalam sebuah cluster, mereka sering terjadi. Di setiap cluster, ribuan mesin biasanya gagal dalam setahun dan ribuan hard drive gagal. Jika Anda mengalikan angka ini dengan jumlah cluster yang beroperasi di seluruh dunia, hasilnya mengejutkan. Karena itu, kami ingin mengisolasi pengguna dari masalah seperti itu, dan tim yang terlibat dalam layanan kami juga tidak ingin terganggu oleh masalah perangkat keras. Setiap kampus pusat data memiliki tim yang bertanggung jawab untuk mendukung peralatan dan infrastruktur pusat data.
Manajemen mesin
Borg (Gambar 2.2) adalah sistem manajemen cluster terdistribusi [Verma et al., 2015], mirip dengan Apache Mesos. Borg mengelola pekerjaan tingkat cluster.
Borg bertanggung jawab untuk meluncurkan pekerjaan pengguna. Tugas-tugas ini dapat berupa menjalankan layanan atau proses batch secara konstan seperti MapReduce [Dean dan Ghemawat, 2004]. Mereka dapat terdiri dari beberapa (kadang-kadang ribuan) tugas yang identik (tugas) - baik untuk alasan keandalan, dan karena satu proses, sebagai suatu peraturan, tidak dapat memproses semua lalu lintas cluster. Ketika Borg memulai tugas, ia menemukan mesin untuk melakukan tugasnya dan memerintahkan mereka untuk memulai program server. Borg kemudian memantau status tugas-tugas ini. Jika tugas tidak berfungsi dengan benar, tugas itu dihancurkan dan dinyalakan kembali, mungkin di komputer lain.
Karena tugas didistribusikan secara bebas di antara mesin, kami tidak dapat menggunakan alamat IP dan nomor port untuk mengaksesnya. Masalah ini diselesaikan dengan tingkat abstraksi tambahan: saat memulai tugas, Borg mengalokasikan nama untuk tugas dan angka (indeks) untuk setiap tugas menggunakan layanan penamaan Borg (BNS). Alih-alih menggunakan alamat IP dan nomor port, proses lain mengasosiasikan dengan tugas-tugas Borg dengan nama BNS mereka, yang kemudian mengubah BNS ke alamat IP dan nomor port. Misalnya, jalur BNS dapat berupa string seperti / bns / <cluster> / <user> / <task_name> / <task_number>, yang kemudian diterjemahkan (biasanya dikatakan "diizinkan" pada jaringan) dalam format <alamat IP>: <port> .
Borg juga bertanggung jawab untuk mengalokasikan sumber daya untuk penugasan. Setiap tugas harus menunjukkan sumber daya apa yang diperlukan untuk menyelesaikannya (misalnya, tiga inti prosesor, 2 GB RAM). Dengan menggunakan daftar persyaratan untuk semua tugas, Borg dapat secara optimal mendistribusikan tugas antar mesin, dengan mempertimbangkan pertimbangan toleransi kesalahan juga (misalnya, Borg tidak akan memulai semua tugas dari satu tugas di rak yang sama, karena sakelar rak ini akan menjadi titik kritis jika terjadi kegagalan) tugas).
Jika suatu tugas mencoba untuk mengambil lebih banyak sumber daya daripada yang diminta, Borg menghancurkannya dan kemudian memulai kembali (karena biasanya lebih disukai memiliki tugas yang terkadang macet dan dimulai ulang daripada yang tidak memulai ulang sama sekali).
Penyimpanan
Untuk akses yang lebih cepat ke data, tugas dapat menggunakan disk mesin lokal, tetapi kami memiliki beberapa opsi untuk mengatur penyimpanan persisten di cluster (dan bahkan data yang disimpan secara lokal pada akhirnya akan dipindahkan ke penyimpanan cluster). Mereka dapat dibandingkan dengan Lustre dan Sistem File Terdistribusi Hadoop (HDFS) - sistem file berkerumun dengan implementasi open source.
Penyimpanan memberi pengguna kemampuan untuk dengan mudah dan andal mengakses data yang tersedia untuk cluster. Seperti yang ditunjukkan pada gambar. 2.3, repositori memiliki beberapa lapisan.
1. Lapisan terendah disebut D (dari disk, meskipun level D menggunakan hard drive tradisional dan flash drive). D adalah file server yang berjalan di hampir semua mesin cluster. Namun, pengguna yang ingin mengakses data mereka tidak ingin mengingat di mesin mana mereka disimpan, sehingga lapisan berikutnya terhubung di sini.
2. Above layer D adalah layer Colossus, yang menciptakan sistem file dalam cluster yang menawarkan semantik biasa dari sistem file, serta replikasi dan enkripsi. Colossus adalah penerus GFS, Sistem File Google (Ghemawat et al., 2003).
3. Selanjutnya, ada beberapa layanan seperti basis data yang dibangun di atas tingkat Colossus.
- Bigtable [Chang et al., 2006] adalah sistem basis data non-relasional (NoSQL) yang mampu bekerja dengan basis data berukuran petabyte. Bigtable adalah database terdistribusi jarang, toleran-kesalahan, multi-dimensi, tertata yang diindeks oleh baris, kolom, dan kunci waktu; setiap nilai basis data adalah array byte yang tidak diinterpretasikan secara arbitrer. Bigtable juga mendukung replikasi antar pusat data.
- Spanner [Corbett et al., 2012] menawarkan antarmuka seperti SQL untuk pengguna yang membutuhkan integritas dan konsistensi data saat mengakses dari mana saja di dunia.
- Beberapa sistem basis data lain tersedia, seperti Blobstore. Mereka semua memiliki kekuatan dan kelemahan mereka sendiri (lihat bab 26).
Jaringan
Jaringan Google dikelola dalam beberapa cara. Seperti yang disebutkan sebelumnya, kami menggunakan jaringan yang dapat dikonfigurasi perangkat lunak berbasis OpenFlow. Alih-alih router pintar, kami menggunakan sakelar konyol yang tidak begitu mahal dalam kombinasi dengan pengontrol pusat (duplikat), yang menghitung sebelumnya rute terbaik di jaringan. Ini memungkinkan Anda untuk menggunakan peralatan switching yang lebih sederhana, membebaskannya dari pencarian rute yang menghabiskan waktu.
Bandwidth jaringan harus dialokasikan dengan benar. Sebagai Borg membatasi sumber daya komputasi tugas dapat digunakan, demikian juga Bandwidth Enforcer (BwE) mengelola bandwidth yang tersedia untuk memaksimalkan throughput rata-rata. Optimalisasi bandwidth tidak hanya terkait dengan biaya: manajemen lalu lintas terpusat memecahkan sejumlah masalah yang sangat sulit untuk diselesaikan dengan kombinasi routing yang didistribusikan dan manajemen lalu lintas konvensional (Kumar, 2015).
Beberapa layanan memiliki pekerjaan yang berjalan di beberapa cluster yang terletak di berbagai belahan dunia. Untuk mengurangi waktu tunda sistem terdistribusi global, kami ingin mengarahkan pengguna ke pusat data terdekat yang memiliki kapasitas yang sesuai untuk ini. Penyeimbang Beban Perangkat Lunak Global (GSLB) kami melakukan penyeimbangan beban pada tiga tingkat:
- penyeimbangan muatan geografis untuk kueri DNS (misalnya, ke www.google.com ), dijelaskan di bab 19;
- memuat penyeimbangan di tingkat layanan pengguna (misalnya, YouTube atau Google Maps);
- load balancing di tingkat Remote Procedure Call (RPC), dijelaskan pada Bab 20.
Pemilik layanan menentukan nama simbolis untuk mereka, daftar alamat server BNS dan kinerja yang tersedia di setiap situs (biasanya diukur dalam kueri per detik - kueri per detik, QPS). Selanjutnya, GSLB merutekan lalu lintas ke alamat BNS yang ditentukan.
Perangkat lunak sistem lainnya
Ada komponen penting lainnya untuk perangkat lunak pusat data.
Layanan kunciChubby Lock Service [Burrows, 2006] menyediakan API yang mirip dengan sistem file untuk melayani kunci. Chubby menangani kunci pada semua pusat data. Ia menggunakan protokol Paxos untuk secara asinkron mengakses Konsensus (lihat bab 23).
Chubby juga memainkan peran penting dalam memilih penyihir. Jika untuk beberapa layanan lima replika tugas disediakan untuk tujuan meningkatkan keandalan, tetapi pada saat tertentu hanya satu dari mereka yang melakukan pekerjaan nyata, maka Chubby digunakan untuk memilih replika ini.
Chubby sangat bagus untuk data yang membutuhkan keandalan penyimpanan. Untuk alasan ini, BNS menggunakan Chubby untuk menyimpan rasio jalur BNS ke alamat IP: pasangan port.
Pemantauan dan PeringatanKami ingin memastikan bahwa semua layanan berfungsi dengan baik. Karena itu, kami meluncurkan banyak contoh program pemantauan Borgmon (lihat bab 10). Borgmon secara teratur menerima nilai tolok ukur dari layanan yang dipantau. Data ini dapat digunakan segera untuk pemberitahuan atau disimpan untuk pemrosesan dan analisis selanjutnya, misalnya, untuk membuat grafik. Pemantauan tersebut dapat digunakan untuk tujuan seperti:
- menyiapkan peringatan untuk masalah mendesak;
- perbandingan perilaku: apakah pembaruan perangkat lunak mempercepat server;
- penilaian sifat perubahan konsumsi sumber daya dari waktu ke waktu, yang diperlukan untuk perencanaan kapasitas.
Infrastruktur perangkat lunak kami
Arsitektur perangkat lunak kami dirancang sehingga dimungkinkan untuk menggunakan sumber daya perangkat keras sistem secara paling efisien. Seluruh kode kami adalah multi-utas, sehingga satu tugas dapat dengan mudah menggunakan beberapa inti. Untuk mendukung dasbor, pemantauan dan debugging, setiap server menyertakan implementasi server HTTP sebagai antarmuka di mana informasi diagnostik dan statistik untuk tugas tertentu disediakan.
Semua layanan Google "berkomunikasi" menggunakan infrastruktur panggilan prosedur jarak jauh (RPC) yang disebut Stubby. Ada versi open source, disebut gRPC (lihat
grpc.io ). Seringkali, panggilan RPC dibuat bahkan untuk rutinitas di program lokal. Ini memungkinkan Anda untuk mengubah orientasi program ke panggilan server lain untuk mencapai modularitas yang lebih besar atau seiring dengan pertumbuhan kode server asli. GSLB dapat melakukan penyeimbangan beban RPC dengan cara yang sama seperti untuk antarmuka layanan eksternal.
Server menerima permintaan RPC dari ujung depan dan mengirimkan RPC ke backend. Menggunakan istilah tradisional, frontend disebut klien, dan backend disebut server.
Data ditransfer ke dan dari RPC menggunakan protokol serialisasi - yang disebut buffer protokol, atau, secara singkat, protobuf. Protokol ini mirip dengan Apache's Thrift dan memiliki beberapa keunggulan dibandingkan XML dalam hal membuat serialisasi data terstruktur: lebih sederhana, tiga hingga sepuluh kali lebih kompak, 20 hingga 100 kali lebih cepat dan lebih unik.
Lingkungan pengembangan kami
Kecepatan pengembangan produk sangat penting bagi Google, jadi kami menciptakan lingkungan khusus yang memanfaatkan sebagian besar infrastruktur kami [Morgenthaler et al., 2012].
Dengan pengecualian pada beberapa grup yang produknya open source, dan karenanya menggunakan repositori terpisah mereka sendiri (misalnya, Android dan Chrome), insinyur perangkat lunak Google bekerja dalam satu repositori umum [Potvin, Levenberg, 2016]. Pendekatan ini memiliki beberapa aplikasi praktis yang penting untuk proses produksi kami.
- Jika seorang insinyur menemukan masalah dalam komponen di luar proyeknya, ia dapat memperbaiki masalahnya, mengirimkan perubahan yang diajukan ("daftar perubahan" - daftar perubahan, CL) kepada pemilik untuk dipertimbangkan dan kemudian menerapkan perubahan yang dilakukan di cabang utama program.
- Perubahan pada kode sumber dalam proyek insinyur sendiri memerlukan pertimbangan - melakukan audit (tinjauan). Semua perangkat lunak melewati tahap ini sebelum diadopsi.
Ketika perangkat lunak sedang dirakit, permintaan perakitan dikirim ke server pusat data khusus. Bahkan membangun proyek besar pun cepat karena Anda dapat menggunakan beberapa server untuk kompilasi paralel. Infrastruktur semacam itu juga digunakan untuk pengujian berkelanjutan. Setiap kali daftar perubahan baru (CL) muncul, tes dijalankan dari semua perangkat lunak yang dapat dipengaruhi secara langsung atau tidak langsung oleh perubahan itu. Jika kerangka kerja mendeteksi bahwa perubahan mengganggu operasi bagian lain dari sistem, itu memberi tahu pemilik perubahan ini. Beberapa proyek menggunakan sistem push-on-green (“mengirim dengan sukses”), yang menurutnya versi baru secara otomatis dikirim ke operasi komersial setelah melewati tes.
Shakespeare: contoh layanan
Untuk menunjukkan bagaimana Google mengembangkan layanan di lingkungan industri, pertimbangkan contoh layanan hipotetis yang berinteraksi dengan teknologi Google. Misalkan kami ingin menawarkan layanan yang memungkinkan Anda untuk menentukan di mana karya Shakespeare kata yang telah Anda sebutkan terjadi.
Kami dapat membagi sistem menjadi dua bagian.
- Komponen pemrosesan batch yang membaca semua teks Shakespeare, membuat indeks dan menulisnya ke Bigtable. Tugas ini (lebih tepatnya, tugas) dilakukan sekali atau, mungkin, kadang-kadang (setelah semua, beberapa teks Shakespeare baru mungkin muncul!).
- Aplikasi front-end yang memproses permintaan pengguna akhir. Tugas ini selalu berjalan, karena kapan saja, pengguna dari zona waktu apa pun mungkin ingin mencari melalui buku-buku Shakespeare.
Komponen pemrosesan batch akan menjadi layanan MapReduce, yang pekerjaannya dibagi menjadi tiga fase.
1. Pada fase Pemetaan, teks-teks Shakespeare dibaca dan dipecah menjadi kata-kata yang terpisah. Bagian pekerjaan ini akan diselesaikan lebih cepat jika beberapa proses kerja (tugas) diluncurkan secara paralel.
2. Pada fase Acak, entri diurutkan berdasarkan kata.
3. Pada fase Reduce, tupel formulir (kata, list_products) dibuat.
Setiap tuple ditulis sebagai string dalam Bigtable, kuncinya adalah kata.
Minta Siklus Hidup
Dalam gbr. 2.4 menunjukkan bagaimana permintaan pengguna dilayani. Pertama, pengguna mengklik tautan shakespeare.google.com di browser. Untuk mendapatkan alamat IP yang sesuai, perangkat pengguna menerjemahkan ("menyelesaikan") alamat menggunakan server DNS (1). Kueri DNS akhirnya berakhir di server DNS Google, yang berinteraksi dengan GSLB. Melacak beban lalu lintas semua server front-end berdasarkan wilayah, GSLB memilih alamat IP mana dari server yang akan kembali ke pengguna.
Browser terhubung ke server HTTP di alamat yang ditentukan. Server ini (disebut Google Frontend atau GFE) adalah server proxy "terbalik" yang terletak di ujung koneksi TCP klien (2). GFE mencari layanan yang diperlukan (misalnya, itu bisa berupa layanan pencarian, peta, atau - dalam kasus kami, layanan Shakespeare). Berkali-kali mengakses GSLB, server menemukan server front-end Shakespeare yang tersedia dan mengaksesnya melalui panggilan prosedur jarak jauh (RPC), mentransmisikan permintaan HTTP yang diterima dari pengguna (3).
Server Shakespeare mem-parsing permintaan HTTP dan membuat "protokol buffer" (protobuf) yang berisi kata-kata yang bisa ditemukan. Sekarang, server front-end Shakespeare harus menghubungi server back-end Shakespeare: yang pertama menghubungi GSLB untuk mendapatkan alamat BNS dari instance yang sesuai dan diturunkan dari yang kedua (4). Selanjutnya, server backend Shakespeare menghubungi server Bigtable untuk menerima data yang diminta (5).
Hasilnya ditulis ke protobuf respons dan dikembalikan ke server backend Shakespeare. Backend melewati protobuf dengan hasil layanan ke server front-end Shakespeare, yang membuat dokumen HTML dan mengembalikannya sebagai respons kepada pengguna.
Seluruh rangkaian peristiwa ini berjalan dalam sekejap mata - hanya dalam beberapa ratus milidetik! Karena banyak komponen yang terlibat, ada banyak tempat di mana kesalahan potensial dapat terjadi; khususnya, kegagalan dalam GSLB dapat mengacaukan semua pekerjaan dan menyebabkan kehancuran. Google, , ( ), , . ,
www.google.com , .
, - 100 (QPS). , 3470 QPS, 35 . , 37 , N + 2.
: 1430 QPS , 290 — , 1400 — 350 — . - , : , , . N + 2 , 17 , 16 — — . , , ( ), — N + 2 N + 1. : GSLB - , 20 % , . 2–3 .
- Bigtable, . - Bigtable, , , Bigtable . , Bigtable , . Bigtable , , .
, . , , .
»Informasi lebih lanjut tentang buku ini dapat ditemukan di
situs web penerbit»
Isi»
KutipanKupon diskon 20% untuk Habrozavitel - Rekayasa Keandalan Situs