Seperti dijelaskan dalam Ketersediaan platform, infrastruktur Google Cloud dirancang untuk mendukung target ketersediaan sebesar 99,9% untuk beban kerja yang di-deploy di satu zona. Ketersediaan targetnya adalah 99,99% untuk deployment multi-zona dan 99,999% untuk deployment multi-region. Bagian dari panduan keandalan infrastruktur Google Cloud ini memberikan panduan deployment, contoh arsitektur, serta teknik desain yang dapat membantu melindungi beban kerja Anda dari kegagalan pada resource, zona, dan tingkat wilayah.
Hindari titik tunggal kegagalan
Aplikasi biasanya terdiri dari beberapa komponen yang saling bergantung, yang masing-masing dirancang untuk melakukan fungsi tertentu. Komponen-komponen ini biasanya dikelompokkan ke dalam beberapa tingkatan berdasarkan fungsi yang dijalankannya dan hubungannya dengan komponen lainnya. Misalnya, aplikasi penayangan konten mungkin memiliki tiga tingkat: tingkat web yang berisi load balancer dan server web; tingkat aplikasi dengan cluster server aplikasi; dan paket data untuk persistensi. Jika setiap komponen dari stack aplikasi ini bergantung pada satu resource infrastruktur, kegagalan resource tersebut dapat memengaruhi ketersediaan seluruh stack. Misalnya, jika tingkat aplikasi berjalan pada satu VM, dan jika VM mengalami error, seluruh stack tidak tersedia secara efektif. Komponen tersebut adalah titik tunggal kegagalan (SPOF).
Stack aplikasi mungkin memiliki lebih dari satu SPOF. Pertimbangkan stack aplikasi multitingkat yang ditunjukkan dalam diagram berikut:
Seperti yang ditunjukkan pada diagram sebelumnya, arsitektur contoh ini berisi satu load balancer, dua server web, satu server aplikasi, dan satu database. Load balancer, server aplikasi, dan database dalam contoh ini adalah SPOF. Kegagalan salah satu komponen ini dapat menyebabkan kegagalan permintaan pengguna ke aplikasi.
Untuk menghapus SPOF dalam stack aplikasi Anda, distribusikan resource di seluruh lokasi dan deploy resource redundan.
Mendistribusikan resource dan membuat redundansi
Tergantung pada persyaratan keandalan aplikasi, Anda dapat memilih dari arsitektur deployment berikut:
| Arsitektur | Rekomendasi beban kerja |
|---|---|
| Multi-region | Beban kerja yang penting bagi bisnis dan membutuhkan ketersediaan tinggi, seperti aplikasi media sosial dan retail. |
| Multizona | Beban kerja yang memerlukan ketahanan terhadap pemadaman layanan zona, tetapi dapat menoleransi periode nonaktif yang disebabkan oleh pemadaman layanan region. |
| Zona tunggal | Beban kerja yang dapat menoleransi periode nonaktif atau dapat di-deploy di lokasi lain jika diperlukan dengan upaya minimal. |
Pertimbangan biaya, latensi, dan operasional
Saat mendesain arsitektur terdistribusi dengan resource redundan, selain persyaratan ketersediaan aplikasi, Anda juga harus mempertimbangkan dampaknya terhadap kompleksitas operasional, latensi, dan biaya.
Dalam arsitektur terdistribusi, Anda menyediakan dan mengelola jumlah resource yang lebih tinggi. Volume traffic jaringan lintas lokasi lebih tinggi. Anda juga menyimpan dan mereplikasi lebih banyak data. Akibatnya, biaya resource cloud Anda dalam arsitektur terdistribusi lebih tinggi dan pengoperasian deployment semacam itu memerlukan kerumitan yang lebih besar. Untuk aplikasi yang penting bagi bisnis, keuntungan ketersediaan dari arsitektur terdistribusi mungkin lebih besar daripada peningkatan biaya dan kompleksitas operasional.
Untuk aplikasi yang tidak penting bagi bisnis, ketersediaan tinggi yang diberikan oleh arsitektur terdistribusi mungkin tidak penting. Aplikasi tertentu memiliki persyaratan lain yang lebih penting daripada ketersediaan. Misalnya, aplikasi komputasi batch memerlukan koneksi jaringan latensi rendah dan bandwidth tinggi di antara VM. Arsitektur zona tunggal mungkin sangat cocok untuk aplikasi semacam ini, dan juga dapat membantu Anda mengurangi biaya transfer data.
Arsitektur deployment
Bagian ini menampilkan opsi arsitektur berikut guna membangun infrastruktur bagi beban kerja Anda di Google Cloud:
- Deployment zona tunggal
- Deployment multi-zona
- Deployment multi-region dengan load balancing regional
- Deployment multi-region dengan load balancing global
Deployment zona tunggal
Diagram berikut menunjukkan arsitektur aplikasi zona tunggal dengan redundansi di setiap tingkat, untuk mencapai ketersediaan fungsi yang lebih tinggi yang dijalankan oleh setiap komponen:
Seperti ditunjukkan dalam diagram sebelumnya, contoh arsitektur ini mencakup komponen berikut:
- Load balancer HTTP/S eksternal regional untuk menerima dan merespons permintaan pengguna.
- Grup instance terkelola (MIG) zona sebagai backend untuk load balancer HTTP/S. MIG memiliki dua VM Compute Engine. Setiap VM menghosting instance server web.
- Load balancer internal untuk menangani komunikasi antara server web dan instance server aplikasi.
- MIG zona kedua sebagai backend untuk load balancer internal. MIG ini berisi dua VM Compute Engine. Setiap VM menghosting instance server aplikasi.
- Instance database Cloud SQL (edisi Enterprise) tempat aplikasi menulis dan membaca data. Database tersebut direplikasi secara manual ke instance database Cloud SQL kedua di zona yang sama.
Ketersediaan gabungan: Deployment zona tunggal
Tabel berikut menunjukkan ketersediaan setiap tingkat dalam diagram arsitektur zona tunggal sebelumnya:
| Resource | SLA |
|---|---|
| Load balancer eksternal | 99,99% |
| Tingkat web: VM Compute Engine dalam satu zona | 99,9% |
| Load balancer internal | 99,99% |
| Tingkat aplikasi: VM Compute Engine dalam satu zona | 99,9% |
| Instance Cloud SQL (edisi Enterprise) | 99,95% |
Resource infrastruktur Google Cloud yang tercantum dalam tabel sebelumnya dapat menyediakan ketersediaan gabungan dan perkiraan periode nonaktif bulanan maksimum sebagai berikut:
- Ketersediaan gabungan: 0,9999 x 0,999 x 0,9999 x 0,999 x 0,9995 = 99,73%
- Perkiraan periode nonaktif bulanan maksimum: Sekitar 1 jam 57 menit
Penghitungan ini hanya mempertimbangkan resource infrastruktur yang ditampilkan dalam diagram arsitektur sebelumnya. Untuk menilai ketersediaan aplikasi di Google Cloud, Anda juga harus mempertimbangkan faktor-faktor lain, seperti berikut ini:
- Desain internal aplikasi
- Proses dan alat DevOps yang digunakan untuk membangun, men-deploy, dan memelihara aplikasi, dependensinya, serta infrastruktur Google Cloud
Untuk mengetahui informasi selengkapnya, lihat Faktor yang memengaruhi keandalan aplikasi.
Pengaruh pemadaman layanan, dan panduan untuk pemulihan
Dalam arsitektur deployment zona tunggal, jika ada komponen yang gagal, aplikasi dapat memproses permintaan jika setiap tingkat berisi setidaknya satu komponen yang berfungsi dengan kapasitas yang memadai. Misalnya, jika instance server web gagal, load balancer meneruskan permintaan pengguna ke instance server web lainnya. Jika VM yang menghosting server web atau instance server aplikasi tidak bekerja, MIG akan memastikan bahwa VM baru dibuat secara otomatis. Jika database tidak bekerja, Anda harus mengaktifkan database kedua secara manual dan memperbarui instance server aplikasi agar dapat terhubung ke database.
Pemadaman layanan zona atau pemadaman layanan region akan memengaruhi VM Compute Engine dan instance database Cloud SQL dalam deployment zona tunggal. Pemadaman layanan zona tidak memengaruhi load balancer di arsitektur ini karena merupakan resource regional. Namun, load balancer tidak dapat mendistribusikan traffic karena tidak ada backend yang tersedia. Jika terjadi pemadaman layanan zona, Anda harus menunggu hingga Google menyelesaikan penonaktifan, lalu pastikan bahwa aplikasi berfungsi seperti yang diharapkan.
Bagian berikutnya menjelaskan pendekatan arsitektur yang dapat Anda gunakan untuk mendistribusikan resource di beberapa zona, yang membantu meningkatkan ketahanan aplikasi terhadap pemadaman layanan zona.
Deployment multi-zona
Dalam deployment zona tunggal, jika terjadi pemadaman layanan zona, aplikasi mungkin tidak dapat menyalurkan permintaan hingga masalah teratasi. Untuk membantu meningkatkan ketahanan aplikasi Anda terhadap pemadaman layanan zona, Anda dapat menyediakan beberapa instance resource zona (seperti VM Compute Engine) di dua zona atau lebih. Untuk layanan yang mendukung resource cakupan region (seperti bucket Cloud Storage), Anda dapat men-deploy resource regional.
Diagram berikut menunjukkan arsitektur lintas zona yang sangat tersedia, dengan komponen di setiap tingkat stack aplikasi yang didistribusikan di dua zona:
Seperti ditunjukkan dalam diagram sebelumnya, contoh arsitektur ini mencakup komponen berikut:
- Load balancer HTTP/S eksternal regional menerima dan merespons permintaan pengguna.
- MIG regional adalah backend untuk load balancer HTTP/S. MIG berisi dua VM Compute Engine di zona yang berbeda. Setiap VM menghosting instance server web.
- Load balancer internal menangani komunikasi antara server web dan instance server aplikasi.
- MIG regional kedua adalah backend untuk load balancer TCP. MIG ini memiliki dua VM Compute Engine di zona yang berbeda. Setiap VM menghosting instance server aplikasi.
- Instance Cloud SQL (edisi Enterprise) yang dikonfigurasi untuk HA adalah database untuk aplikasi. Instance database utama direplikasi secara sinkron ke instance database standby.
Ketersediaan gabungan: Deployment multi-zona
Tabel berikut menunjukkan ketersediaan setiap tingkat dalam diagram arsitektur zona ganda sebelumnya:
| Resource | SLA |
|---|---|
| Load balancer eksternal | 99,99% |
| Tingkat web: VM Compute Engine di zona terpisah | 99,99% |
| Load balancer internal | 99,99% |
| Tingkat aplikasi: VM Compute Engine di zona terpisah | 99,99% |
| Instance Cloud SQL (edisi Enterprise) | 99,95% |
Resource infrastruktur Google Cloud yang tercantum dalam tabel sebelumnya dapat menyediakan ketersediaan gabungan dan perkiraan periode nonaktif bulanan maksimum sebagai berikut:
- Ketersediaan gabungan: 0,9999 x 0,9999 x 0,9999 x 0,9999 x 0,9995 = 99,91%
- Perkiraan periode nonaktif bulanan maksimum: Sekitar 39 menit
Penghitungan ini hanya mempertimbangkan resource infrastruktur yang ditampilkan dalam diagram arsitektur sebelumnya. Untuk menilai ketersediaan aplikasi di Google Cloud, Anda juga harus mempertimbangkan faktor-faktor lain, seperti berikut ini:
- Desain internal aplikasi
- Proses dan alat DevOps yang digunakan untuk membangun, men-deploy, dan memelihara aplikasi, dependensinya, serta infrastruktur Google Cloud
Untuk mengetahui informasi selengkapnya, lihat Faktor yang memengaruhi keandalan aplikasi.
Pengaruh pemadaman layanan, dan panduan untuk pemulihan
Dalam deployment zona ganda, jika ada komponen yang gagal, aplikasi dapat memproses permintaan jika setidaknya ada satu komponen yang berfungsi dengan kapasitas yang memadai di setiap tingkat. Misalnya, jika instance server web gagal, load balancer akan meneruskan permintaan pengguna ke instance server web di zona lain. Jika VM yang menghosting server web atau instance server aplikasi tidak bekerja, MIG akan memastikan bahwa VM baru dibuat secara otomatis. Jika database Cloud SQL utama tidak bekerja, Cloud SQL akan otomatis mengalihkan ke instance database standby.
Diagram berikut menunjukkan arsitektur yang sama dengan diagram sebelumnya dan efek pemadaman layanan zona terhadap ketersediaan aplikasi:
Seperti yang ditunjukkan pada diagram sebelumnya, jika pemadaman layanan terjadi di salah satu zona, load balancer dalam arsitektur ini tidak akan terpengaruh karena merupakan resource regional. Pemadaman layanan zona dapat memengaruhi setiap VM Compute Engine dan salah satu instance database Cloud SQL. Namun, aplikasinya tetap tersedia dan responsif, karena VM berada di MIG regional dan database Cloud SQL dikonfigurasi untuk HA. MIG memastikan bahwa VM baru dibuat secara otomatis untuk mempertahankan jumlah minimum VM yang dikonfigurasi. Jika instance database Cloud SQL utama terpengaruh oleh pemadaman layanan zona, Cloud SQL akan otomatis gagal ke instance standby di zona lainnya. Setelah Google menyelesaikan pemadaman layanan, Anda harus memastikan bahwa aplikasi berjalan seperti yang diharapkan di semua zona tempat aplikasi di-deploy.
Jika kedua zona dalam arsitektur ini mengalami pemadaman layanan, maka aplikasi tidak akan tersedia. Load balancer akan tetap tersedia kecuali jika terjadi pemadaman layanan seluruh region. Namun, load balancer tidak dapat mendistribusikan traffic karena tidak ada backend yang tersedia. Jika terjadi pemadaman layanan multi-zona atau pemadaman layanan region, Anda harus menunggu Google menyelesaikan pemadaman layanan tersebut, lalu pastikan bahwa aplikasi berfungsi seperti yang diharapkan.
Bagian berikutnya menampilkan opsi arsitektur untuk melindungi aplikasi Anda dari pemadaman layanan multi-zona dan pemadaman layanan region.
Deployment multi-region dengan load balancing regional
Dalam deployment zona tunggal atau multi-zona, jika terjadi pemadaman layanan region, aplikasi tidak dapat menyalurkan permintaan hingga masalah teratasi. Untuk melindungi aplikasi Anda dari pemadaman layanan region, Anda dapat mendistribusikan resource Google Cloud di dua region atau lebih.
Diagram berikut menunjukkan arsitektur lintas-region yang sangat tersedia, dengan komponen di setiap tingkat stack aplikasi yang didistribusikan di beberapa region:
Seperti ditunjukkan dalam diagram sebelumnya, contoh arsitektur ini mencakup komponen berikut:
- Zona Cloud DNS publik dengan kebijakan perutean yang mengarahkan traffic ke dua region Google Cloud.
- Load balancer HTTP/S eksternal regional di setiap region untuk menerima dan merespons permintaan pengguna.
- Backend untuk setiap load balancer HTTP/S regional adalah MIG regional. Setiap MiG berisi dua VM Compute Engine di zona berbeda. Masing-masing VM ini menghosting instance server web.
- Load balancer internal di setiap region menangani komunikasi antara instance server web dan instance server aplikasi.
- Sepasang MIG regional kedua adalah backend untuk load balancer internal. Masing-masing MIG ini berisi dua VM Compute Engine di zona yang berbeda. Setiap VM menghosting instance server aplikasi.
- Aplikasi menulis data ke dan membaca dari instance Spanner multi-region. Konfigurasi multi-region yang digunakan dalam
arsitektur ini (
eur5) mencakup empat replika baca-tulis. Replika baca-tulis disediakan secara merata di dua region dan di zona terpisah. Konfigurasi Spanner multi-region juga menyertakan replika saksi di region ketiga.
Ketersediaan gabungan: Deployment multi-region dengan load balancing regional
Dalam deployment multi-region yang ditunjukkan dalam diagram sebelumnya, load balancer dan VM disediakan secara redundan di dua region. Zona DNS adalah resource global, dan instance Spanner adalah resource multi-region.
Untuk menghitung ketersediaan gabungan infrastruktur Google Cloud yang ditampilkan dalam arsitektur ini, pertama-tama kita harus menghitung ketersediaan gabungan resource di setiap region, lalu mempertimbangkan resource yang mencakup beberapa region. Gunakan proses berikut:
- Menghitung ketersediaan gabungan resource infrastruktur
per region; yaitu, tidak termasuk resource DNS dan database:
Resource dan SLA SLA Load balancer eksternal 99,99% Tingkat web: VM Compute Engine di zona terpisah 99,99% Load balancer internal 99,99% Tingkat aplikasi: VM Compute Engine di zona terpisah 99,99% Ketersediaan gabungan per region: 0,9999 x 0,9999 x 0,9999 x 0,9999 = 99,96%
Hitung ketersediaan gabungan resource infrastruktur dengan mempertimbangkan redundansi dual-region dari load balancer dan VM Compute Engine.
Ketersediaan teoretis adalah 1-(1-0,9996)(1-0,9996) = 99,999984%. Namun, ketersediaan sebenarnya yang dapat Anda harapkan terbatas pada ketersediaan target untuk deployment multi-region, yaitu 99,999%.
Hitung ketersediaan agregat semua resource infrastruktur, termasuk resource Cloud DNS dan Spanner:
- Ketersediaan gabungan: 0,99999 x 1 x 0,99999 = 99,998%
- Estimasi periode nonaktif bulanan maksimum: Sekitar 52 detik
Penghitungan ini hanya mempertimbangkan resource infrastruktur yang ditampilkan dalam diagram arsitektur sebelumnya. Untuk menilai ketersediaan aplikasi di Google Cloud, Anda juga harus mempertimbangkan faktor-faktor lain, seperti berikut ini:
- Desain internal aplikasi
- Proses dan alat DevOps yang digunakan untuk membangun, men-deploy, dan memelihara aplikasi, dependensinya, serta infrastruktur Google Cloud
Untuk mengetahui informasi selengkapnya, lihat Faktor yang memengaruhi keandalan aplikasi.
Pengaruh pemadaman layanan, dan panduan untuk pemulihan
Jika salah satu komponen dalam deployment multi-region ini gagal, tetapi setidaknya ada satu komponen yang berfungsi dengan kapasitas memadai di setiap tingkat, aplikasi akan tetap berfungsi. Misalnya, jika instance server web gagal, load balancer HTTP/S eksternal regional akan meneruskan permintaan pengguna ke instance server web lain di region tersebut. Demikian pula, jika salah satu instance server aplikasi tidak bekerja, load balancer internal akan mengirim permintaan ke instance server aplikasi lainnya. Jika ada VM yang error, MIG akan memastikan bahwa VM baru dibuat secara otomatis untuk mempertahankan jumlah minimum VM yang dikonfigurasi.
Pemadaman layanan di satu zona tidak memengaruhi load balancer, karena load balancer merupakan resource regional dan tahan terhadap pemadaman layanan zona. Gangguan zona dapat memengaruhi setiap VM Compute Engine. Namun, instance server web dan server aplikasi tetap tersedia, karena VM adalah bagian dari MiG regional. MIG memastikan bahwa VM baru dibuat secara otomatis untuk mempertahankan jumlah minimum VM yang dikonfigurasi. Instance Spanner dalam arsitektur ini menggunakan konfigurasi multi-region, yang tahan terhadap gangguan zona.
Untuk mengetahui informasi tentang cara kerja replikasi multi-region di Spanner, lihat Konfigurasi regional dan multi-region serta Menjelaskan konfigurasi multi-region Spanner.
Diagram berikut menunjukkan arsitektur multi-region yang sama seperti diagram sebelumnya dan efek pemadaman layanan satu region terhadap ketersediaan aplikasi:
Seperti yang ditunjukkan dalam diagram sebelumnya, meskipun pemadaman layanan terjadi di kedua zona di region mana pun, aplikasi tetap tersedia, karena stack aplikasi independen di-deploy di setiap region. Zona DNS mengarahkan permintaan pengguna ke region yang tidak terpengaruh oleh pemadaman layanan. Instance Spanner multi-region tahan terhadap pemadaman region. Setelah Google menyelesaikan pemadaman layanan tersebut, Anda harus memastikan bahwa aplikasi berjalan seperti yang diharapkan di region yang mengalami pemadaman layanan.
Jika salah satu region dalam arsitektur ini mengalami pemadaman layanan, aplikasi tidak akan tersedia. Tunggu hingga Google menyelesaikan pemadaman layanan. Kemudian, pastikan aplikasi berjalan seperti yang diharapkan di semua region tempat aplikasi di-deploy.
Untuk deployment multi-region, daripada menggunakan load balancer regional, Anda dapat mempertimbangkan untuk menggunakan load balancer global. Bagian berikutnya menampilkan arsitektur deployment multi-region yang menggunakan load balancer global dan menjelaskan manfaat serta risiko pendekatan tersebut.
Deployment multi-region dengan load balancing global
Diagram berikut menunjukkan deployment multi-region alternatif yang menggunakan load balancer global, bukan load balancer regional:
Seperti yang ditunjukkan pada diagram sebelumnya, arsitektur ini menggunakan load balancer HTTP/S eksternal global (dengan Cloud CDN diaktifkan) untuk menerima dan merespons permintaan pengguna. Setiap aturan penerusan dari load balancer menggunakan satu alamat IP eksternal; Anda tidak perlu mengkonfigurasi pencatatan DNS terpisah untuk setiap region. Backend untuk load balancer HTTP/S eksternal global adalah dua MIG regional. Load balancer merutekan permintaan ke region yang paling dekat dengan pengguna.
Semua komponen lain dalam arsitektur ini identik dengan arsitektur yang ditunjukkan dalam Deployment multi-region dengan load balancing regional.
Manfaat dan risiko load balancing global untuk deployment multi-region
Untuk melakukan load balancing pada traffic eksternal ke aplikasi yang didistribusikan di beberapa region, Anda dapat menggunakan load balancer global atau beberapa load balancer regional.
Berikut ini manfaat arsitektur yang menggunakan load balancing global:
- Anda hanya perlu mengelola satu load balancer.
- Load balancer global menggunakan satu alamat IP anycast untuk menyediakan load balancer di seluruh region Google Cloud.
- Load balancer global tahan terhadap pemadaman layanan region, dan menyediakan failover lintas region otomatis.
- Load balancer global mendukung fitur berikut, yang dapat membantu meningkatkan
keandalan deployment Anda:
- Edge caching menggunakan Cloud CDN
- Kemampuan untuk menggunakan bucket Cloud Storage yang sangat tahan lama sebagai backend
- Kebijakan keamanan Google Cloud Armor
Berikut ini risiko arsitektur yang menggunakan load balancing global:
- Perubahan konfigurasi yang salah pada load balancer global dapat membuat aplikasi tidak tersedia bagi pengguna. Misalnya, saat memperbarui frontend load balancer global, jika Anda tidak sengaja menghapus aturan penerusan, load balancer akan berhenti menerima permintaan pengguna. Efek risiko ini lebih rendah untuk arsitektur multi-region yang menggunakan load balancer regional, karena meskipun load balancer regional di salah satu region terpengaruh oleh error konfigurasi, dan load balancer di region lain akan terus berfungsi.
- Pemadaman layanan infrastruktur yang memengaruhi resource global dapat membuat load balancer global tidak tersedia.
Untuk mengurangi risiko ini, Anda harus mengelola perubahan pada load balancer global dengan cermat, dan mempertimbangkan penggunaan penggantian defense in depth jika memungkinkan. Untuk mengetahui informasi selengkapnya, lihat Rekomendasi untuk mengelola risiko pemadaman layanan resource global.
Ketersediaan gabungan: Deployment multi-region dengan load balancing global
Dalam deployment multi-region yang ditunjukkan dalam diagram sebelumnya, VM dan load balancer internal didistribusikan secara redundan di dua region. Load balancer eksternal adalah resource global, dan instance Spanner adalah resource multi-region.
Untuk menghitung ketersediaan gabungan deployment ini, pertama-tama kita menghitung ketersediaan gabungan resource di setiap region, lalu mempertimbangkan resource yang mencakup beberapa region.
- Menghitung ketersediaan gabungan resource infrastruktur
per region, tidak termasuk load balancer eksternal dan database:
Resource SLA Tingkat web: VM Compute Engine di zona terpisah 99,99% Load balancer internal 99,99% Tingkat web: VM Compute Engine di zona terpisah 99,99% Ketersediaan gabungan per region: 0,9999 x 0,9999 x 0,9999 = 99,97%
Menghitung ketersediaan gabungan resource infrastruktur dengan mempertimbangkan redundansi dual-region dari load balancer internal dan VM Compute Engine.
Ketersediaan teoretis adalah 1-(1-0,9997)(1-0,9997) = 99,999991%. Namun, ketersediaan sebenarnya yang dapat Anda harapkan terbatas pada ketersediaan target untuk deployment multi-region, yaitu 99,999%.
Hitung ketersediaan agregat semua resource infrastruktur, termasuk resource load balancer global dan Spanner:
- Ketersediaan gabungan: 0,99999 x 0,9999 x 0,99999 = 99,988%
- Estimasi periode nonaktif bulanan maksimum: Sekitar 5 menit 11 detik
Penghitungan ini hanya mempertimbangkan resource infrastruktur yang ditampilkan dalam diagram arsitektur sebelumnya. Untuk menilai ketersediaan aplikasi di Google Cloud, Anda juga harus mempertimbangkan faktor-faktor lain, seperti berikut ini:
- Desain internal aplikasi
- Proses dan alat DevOps yang digunakan untuk membangun, men-deploy, dan memelihara aplikasi, dependensinya, serta infrastruktur Google Cloud
Untuk mengetahui informasi selengkapnya, lihat Faktor yang memengaruhi keandalan aplikasi.
Pengaruh pemadaman layanan, dan panduan untuk pemulihan
Jika ada komponen dalam arsitektur ini yang gagal, aplikasi akan tetap berfungsi jika setidaknya ada satu komponen yang berfungsi dengan kapasitas yang memadai di setiap tingkat. Misalnya, jika instance server web gagal, load balancer HTTP/S eksternal global akan meneruskan permintaan pengguna ke instance server web lainnya. Jika ada instance server aplikasi yang mengalami error, load balancer internal akan mengirimkan permintaan ke instance server aplikasi lainnya. Jika ada VM yang tidak bekerja, MIG akan memastikan bahwa VM baru dibuat secara otomatis untuk mempertahankan jumlah minimum VM yang dikonfigurasi.
Jika terjadi pemadaman layanan di salah satu zona di region mana pun, load balancer tidak akan terpengaruh. Load balancer HTTP/S eksternal global tahan terhadap pemadaman layanan zona dan region. Load balancer internal adalah resource regional; yang tahan terhadap pemadaman layanan zona. Pemadaman layanan zona dapat memengaruhi setiap VM Compute Engine. Namun, instance server web dan server aplikasi tetap tersedia, karena VM adalah bagian dari MiG regional. MIG memastikan bahwa VM baru dibuat secara otomatis untuk mempertahankan jumlah minimum VM yang dikonfigurasi. Instance Spanner dalam arsitektur ini menggunakan konfigurasi multi-region, yang tahan terhadap gangguan zona.
Diagram berikut menunjukkan arsitektur multi-region yang sama seperti diagram sebelumnya dan efek pemadaman layanan satu region terhadap ketersediaan aplikasi:
Seperti yang ditunjukkan dalam diagram sebelumnya, meskipun pemadaman layanan terjadi di kedua zona di region mana pun, aplikasi tetap tersedia, karena stack aplikasi independen di-deploy di setiap region. Load balancing HTTP/S eksternal global merutekan permintaan pengguna ke aplikasi di region yang tidak terpengaruh oleh pemadaman layanan. Instance Spanner multi-region tahan terhadap pemadaman region. Setelah Google menyelesaikan pemadaman layanan, Anda harus memastikan bahwa aplikasi berjalan seperti yang diharapkan di region yang mengalami pemadaman layanan.
Untuk mengetahui informasi tentang cara kerja replikasi multi-region di Spanner, lihat Konfigurasi regional dan multi-region serta Menjelaskan konfigurasi multi-region Spanner.
Jika salah satu region dalam arsitektur ini mengalami pemadaman layanan, aplikasi tidak akan tersedia. Load balancer HTTP/S eksternal global tersedia, tetapi tidak dapat mendistribusikan traffic karena tidak ada backend yang tersedia. Tunggu hingga Google menyelesaikan pemadaman layanan. Kemudian, pastikan aplikasi berjalan seperti yang diharapkan di semua region tempat aplikasi di-deploy.
Deployment multi-region dapat membantu memastikan ketersediaan tinggi untuk aplikasi bisnis Anda yang paling penting. Untuk memastikan kelangsungan bisnis selama peristiwa kegagalan, selain men-deploy aplikasi di beberapa region, Anda harus mengambil langkah tambahan tertentu. Misalnya, Anda harus melakukan perencanaan kapasitas untuk memastikan bahwa kapasitas yang memadai dicadangkan di semua region atau risiko yang terkait dengan penskalaan otomatis darurat yang dapat diterima. Anda juga harus menerapkan praktik operasional untuk pengujian DR, mengelola insiden, memverifikasi status aplikasi setelah insiden, dan melakukan retrospektif.