Layanan infrastruktur Google Cloud berjalan di berbagai lokasi di seluruh dunia. Lokasi dibagi menjadi domain gagal yang disebut region dan zona, yang merupakan fondasi dasar untuk mendesain infrastruktur yang andal bagi workload cloud Anda.
Domain kegagalan adalah resource atau sekelompok resource yang dapat gagal secara terpisah dari resource lainnya. VM Compute Engine mandiri adalah contoh resource yang merupakan domain kegagalan. Region atau zona Google Cloud adalah contoh domain gagal yang terdiri dari sekelompok resource. Jika didistribusikan secara redundan di seluruh domain gagal, aplikasi dapat mencapai tingkat ketersediaan gabungan yang lebih tinggi daripada yang diberikan oleh setiap domain gagal.
Bagian dari panduan keandalan infrastruktur Google Cloud ini menjelaskan elemen penyusun keandalan di Google Cloud dan pengaruhnya terhadap ketersediaan resource cloud Anda.
Region dan zona
Region adalah area geografis independen yang terdiri dari beberapa zona. Zona dan region adalah abstraksi logis dari resource fisik dasar. Region terdiri dari tiga zona atau lebih yang ditempatkan di tiga pusat data fisik atau lebih. Region Meksiko, Osaka, dan Montreal memiliki tiga zona yang ditempatkan di satu atau dua pusat data fisik. Region ini sedang dalam proses ekspansi ke setidaknya tiga pusat data fisik. Saat Anda merancang solusi di Google Cloud, pertimbangkan panduan di Lokasi cloud, SLA Google Cloud Platform, dan dokumentasi produk Google Cloud yang sesuai.
Ketersediaan platform
Infrastruktur Google Cloud dirancang untuk menoleransi dan memulihkan diri dari kegagalan. Google terus berinvestasi dalam pendekatan inovatif untuk mempertahankan dan meningkatkan keandalan Google Cloud. Kemampuan infrastruktur Google Cloud berikut membantu menyediakan platform yang andal untuk workload cloud Anda:
- Wilayah yang terpisah secara geografis untuk mengurangi dampak bencana alam dan pemadaman region terhadap layanan global.
- Redundansi dan replikasi perangkat keras untuk menghindari titik tunggal kegagalan.
- Migrasi langsung resource selama peristiwa pemeliharaan. Misalnya, selama pemeliharaan infrastruktur terencana, VM Compute Engine dapat dipindahkan ke host lain di zona yang sama dengan menggunakan migrasi langsung.
- Fondasi infrastruktur yang didesain agar aman untuk infrastruktur fisik dan software tempat Google Cloud dijalankan, serta kontrol keamanan operasional untuk melindungi data dan workload Anda. Untuk informasi selengkapnya, lihat Ringkasan desain keamanan infrastruktur Google.
- Jaringan backbone berperforma tinggi yang menggunakan pendekatan software-defined networking (SDN) canggih untuk pengelolaan jaringan, dengan layanan edge caching untuk menghasilkan performa yang konsisten dan dapat diskalakan dengan baik.
- Pemantauan dan pelaporan berkelanjutan. Anda dapat melihat status layanan Google Cloud di setiap lokasi dengan menggunakan Dasbor Google Cloud Service Health.
- Peristiwa Pengujian Pemulihan Bencana (DiRT) tahunan di seluruh perusahaan untuk memastikan layanan Google Cloud dan operasi bisnis internal terus berjalan selama bencana.
- Pendekatan pengelolaan perubahan yang menekankan keandalan di semua fase siklus proses pengembangan software untuk setiap perubahan pada platform dan layanan Google Cloud.
Infrastruktur Google Cloud dirancang untuk mendukung tingkat ketersediaan target berikut untuk sebagian besar workload pelanggan:
| Lokasi deployment | % Ketersediaan (waktu beroperasi) | Estimasi periode nonaktif maksimum |
|---|---|---|
| Single zone | 3 angka sembilan: 99,9% | 43,2 menit dalam 30 hari |
| Beberapa zona dalam satu region | 4 angka sembilan: 99,99% | 4,3 menit dalam 30 hari |
| Beberapa region | 5 angka sembilan: 99,999% | 26 detik dalam 30 hari |
Persentase ketersediaan dalam tabel sebelumnya adalah target. Perjanjian Tingkat Layanan (SLA) waktu aktif untuk layanan Google Cloud tertentu mungkin berbeda dengan target ketersediaan ini. Misalnya, SLA waktu aktif untuk instance Bigtable bergantung pada jumlah cluster, distribusinya di seluruh lokasi, dan kebijakan perutean yang Anda konfigurasi.
SLA waktu aktif minimum untuk instance Bigtable dengan cluster di tiga region atau lebih adalah 99,999% jika kebijakan perutean multi-cluster dikonfigurasi. Namun, jika kebijakan perutean cluster-cluster dikonfigurasi, maka SLA waktu aktif minimumnya adalah 99,9% terlepas dari jumlah cluster dan distribusinya.
Diagram di bagian ini menunjukkan instance Bigtable dengan berbagai ukuran cluster dan perbedaan konkret dalam SLA waktu aktifnya.
Cluster tunggal
Diagram berikut menunjukkan instance Bigtable satu cluster, dengan SLA waktu aktif minimum 99,9%:
Beberapa cluster
Diagram berikut menunjukkan instance Bigtable multi-cluster di beberapa zona dalam satu region, dengan perutean multi-cluster (SLA waktu aktif minimum: 99,99%):
Beberapa cluster
Diagram berikut menunjukkan instance Bigtable multi-cluster di tiga region, dengan perutean multi-cluster (SLA waktu aktif minimum: 99,999%):
Ketersediaan infrastruktur gabungan
Untuk menjalankan aplikasi di Google Cloud, Anda menggunakan resource infrastruktur seperti VM dan database. Resource infrastruktur ini, bersama-sama, membentuk stack infrastruktur aplikasi Anda.
Diagram berikut menunjukkan contoh stack infrastruktur di Google Cloud dan SLA ketersediaan untuk setiap resource dalam stack:
Contoh stack infrastruktur ini mencakup resource Google Cloud berikut:
- Load Balancer Aplikasi eksternal regional menerima dan merespons permintaan pengguna.
- Grup instance terkelola (MIG) regional adalah backend untuk Load Balancer Aplikasi eksternal regional. 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 internal. MIG ini memiliki dua VM Compute Engine di zona berbeda. Setiap VM menghosting instance dari server aplikasi.
- Instance Cloud SQL yang dikonfigurasi untuk HA adalah database untuk aplikasi. Instance database utama direplikasi secara sinkron ke instance database standby.
Ketersediaan agregat yang dapat Anda harapkan dari stack infrastruktur seperti contoh sebelumnya bergantung pada faktor-faktor berikut:
SLA Google Cloud
SLA waktu aktif pada layanan Google Cloud yang Anda gunakan dalam stack infrastruktur Anda memengaruhi ketersediaan gabungan minimum yang dapat Anda harapkan dari stack.
Tabel berikut menampilkan perbandingan SLA waktu beroperasi untuk beberapa layanan:
| Layanan komputasi | SLA Waktu Aktif Bulanan | Estimasi periode nonaktif maksimum dalam 30 hari |
|---|---|---|
| VM Compute Engine | 99,9% | 43,2 menit |
| Pod GKE Autopilot di beberapa zona | 99,9% | 43,2 menit |
| Layanan Cloud Run | 99,95% | 21,6 menit |
| Layanan Database | SLA Waktu Aktif Bulanan | Estimasi periode nonaktif maksimum dalam 30 hari |
|---|---|---|
| Instance Cloud SQL untuk PostgreSQL (edisi Enterprise) | 99,95% | 21,6 menit |
| Instance AlloyDB untuk PostgreSQL | 99,99% | 4,3 menit |
| Instance multi-region Spanner | 99,999% | 26 detik |
Untuk mengetahui SLA layanan Google Cloud lainnya, lihat Perjanjian Tingkat Layanan Google Cloud.
Seperti yang ditunjukkan tabel sebelumnya, layanan Google Cloud yang Anda pilih untuk setiap tingkat stack infrastruktur Anda secara langsung memengaruhi waktu aktif keseluruhan yang dapat Anda harapkan dari stack infrastruktur. Untuk meningkatkan perkiraan ketersediaan beban kerja yang di-deploy pada resource Google Cloud, Anda dapat menyediakan instance resource yang redundan, seperti yang dijelaskan di bagian berikutnya.
Redundansi resource
Redundansi resource berarti menyediakan dua instance resource atau lebih yang identik, dan men-deploy workload yang sama di semua resource dalam grup. Misalnya untuk menghosting tingkat web aplikasi, Anda dapat menyediakan MIG yang berisi beberapa VM Compute Engine identik.
ika Anda mendistribusikan sekelompok resource secara redundan di beberapa domain kegagalan—misalnya, dua zona Google Cloud—ketersediaan resource yang dapat Anda harapkan dari grup tersebut lebih tinggi daripada SLA waktu aktif setiap resource di grup. Ketersediaan yang lebih tinggi ini karena probabilitas setiap resource dalam grup gagal pada saat yang sama lebih rendah daripada probabilitas bahwa resource dalam domain kegagalan tunggal memiliki kegagalan terkoordinasi.
Misalnya, jika SLA ketersediaan untuk resource adalah 99,9%, probabilitas resource gagal adalah 0,001 (1 dikurangi SLA). Jika Anda mendistribusikan workload ke dua instance resource ini yang disediakan dalam domain kegagalan terpisah, probabilitas kedua resource gagal pada saat yang sama adalah 0,000001 (yaitu, 0,001 x 0,001) singkat ini. Probabilitas kegagalan ini menerjemahkan ketersediaanteoretis sebesar 99,9999% untuk kelompok dua resource. Namun, ketersediaan sebenarnya yang dapat Anda harapkan terbatas pada ketersediaan target lokasi deployment: 99,9% jika resource berada di satu zona Google Cloud, 99,99% untuk deployment multi-zona , dan 99,999% jika resources redundan didistribusikan di beberapa region.
Kedalaman stack
Kedalaman stack infrastruktur adalah jumlah tingkat (atau lapisan) yang berbeda dalam stack. Setiap tingkat dalam stack infrastruktur berisi resource yang menyediakan fungsi yang berbeda untuk aplikasi. Misalnya, tingkat tengah dalam stack tiga tingkat mungkin menggunakan VM Compute Engine atau cluster GKE untuk menghosting server aplikasi. Setiap tingkat dalam stack infrastruktur biasanya memiliki keterkaitan yang erat dengan tingkat yang berdekatan. Artinya, jika tingkat stack tidak tersedia, seluruh stack akan menjadi tidak tersedia.
Anda dapat menghitung ketersediaan gabungan yang diharapkan dari stack infrastruktur tingkat N dengan menggunakan formula berikut:
Misalnya, jika setiap tingkat dalam stack tiga tingkat dirancang untuk memberikan ketersediaan 99,9%, maka ketersediaan gabungan stack adalah sekitar 99,7% (0,999 x 0,999 x 0,999). Artinya, ketersediaan gabungan stack multi-tingkat lebih rendah daripada ketersediaan tingkat yang memberikan ketersediaan terendah.
Seiring peningkatan jumlah tingkat yang saling bergantung dalam stack, ketersediaan gabungan stack akan menurun, seperti yang ditunjukkan dalam tabel berikut. Setiap contoh stack dalam tabel memiliki jumlah tingkat yang berbeda dan setiap tingkat diasumsikan memberikan ketersediaan 99,9%.
| Tingkat | Stack A | Stack B | Stack C |
|---|---|---|---|
| Frontend | 99,9% | 99,9% | 99,9% |
| Tingkat aplikasi | 99,9% | 99,9% | 99,9% |
| Tingkat menengah | – | 99,9% | 99,9% |
| Tingkat data | – | – | 99,9% |
| Ketersediaan gabungan stack | 99.8% | 99.7% | 99.6% |
| Estimasi periode nonaktif maksimum stack dalam sebulan dalam 30 hari | 86 menit | 130 menit | 173 menit |
Ringkasan pertimbangan desain
Saat Anda mendesain aplikasi, pertimbangkan ketersediaan stack gabungan infrastruktur Google Cloud.
- Ketersediaan setiap resource Google Cloud di stack infrastruktur Anda memengaruhi ketersediaan stack gabungan. Saat Anda memilih layanan Google Cloud untuk mem-build stack infrastruktur, pertimbangkan SLA ketersediaan layanan tersebut.
- Untuk meningkatkan ketersediaan fungsi (misalnya, komputasi atau database) yang disediakan oleh suatu resource, Anda dapat menyediakan instance resource yang redundan. Saat mendesain arsitektur dengan resource redundan, selain manfaat ketersediaan, Anda juga harus mempertimbangkan potensi dampaknya terhadap kompleksitas operasional, latensi, dan biaya.
- Jumlah tingkat dalam stack infrastruktur (yaitu, kedalaman stack) memiliki hubungan terbalik dengan ketersediaan stack gabungan. Pertimbangkan hubungan ini saat Anda mendesain atau memodifikasi stack.
Untuk contoh penghitungan ketersediaan gabungan, lihat bagian berikut:
- Contoh penghitungan: Deployment zona tunggal
- Contoh penghitungan: Deployment multi-zona
- Contoh penghitungan: Deployment multi-region dengan load balancing regional
- Contoh penghitungan: Deployment multi-region dengan load balancing global
Cakupan lokasi
Cakupan lokasi resource Google Cloud menentukan sejauh mana kegagalan infrastruktur dapat memengaruhi resource. Sebagian besar resource yang Anda sediakan di Google Cloud memiliki salah satu cakupan lokasi berikut: zona waktu, regional, multi-region, atau global.
Cakupan lokasi beberapa jenis resource bersifat tetap; Artinya, Anda tidak dapat memilih atau mengubah ruang lingkup lokasi. Misalnya, jaringan Virtual Private Cloud (VPC) adalah resource global, dan virtual machine (VM) Compute Engine adalah resource zona. Untuk resource tertentu, Anda dapat memilih cakupan lokasi saat menyediakan resource. Misalnya, saat membuat cluster Google Kubernetes Engine (GKE), Anda dapat memilih untuk membuat cluster GKE zona atau regional.
Bagian berikut menjelaskan cakupan lokasi secara lebih mendetail.
Resource zona
Resource zonal di-deploy dalam satu zona di region Google Cloud. Berikut adalah contoh resource zona. Ini bukan merupakan daftar lengkap.
- VM Compute Engine
- Grup instance terkelola (MIG) zona
- Persistent disk menurut zona
- Cluster GKE zona tunggal
- Instance Filestore Basic dan Zonal
- Tugas Dataflow
- Instance Cloud SQL
- Cluster Dataproc di Compute Engine
Kegagalan di suatu zona dapat memengaruhi resource zona yang disediakan di dalam zona tersebut. Zona dirancang untuk meminimalkan risiko kegagalan berkorelasi dengan zona lain di region tersebut. Kegagalan di satu zona biasanya tidak memengaruhi resource di zona lain dalam region tersebut. Selain itu, kegagalan di suatu zona tidak selalu menyebabkan semua infrastruktur di zona tersebut menjadi tidak tersedia. Zona hanya menentukan batas yang diharapkan untuk efek kegagalan.
Untuk melindungi aplikasi yang menggunakan resource zona dari insiden zona, Anda dapat mendistribusikan atau mereplikasi resource di beberapa zona atau region. Untuk mengetahui informasi selengkapnya, lihat Mendesain infrastruktur yang andal untuk workload Anda di Google Cloud.
Resource regional
Resource regional di-deploy secara redundan di beberapa zona dalam satu region. Berikut adalah contoh resource regional. Ini bukan merupakan daftar lengkap.
- MIG Regional
- Bucket Cloud Storage Regional
- Persistent disk menurut region
- Cluster GKE regional dengan konfigurasi default (multi-zona)
- Subnet VPC
- Load Balancer Aplikasi eksternal regional
- Instance Spanner regional
- Instance Filestore Enterprise
- Layanan Cloud Run
Resource regional tahan terhadap insiden di zona tertentu. Gangguan region dapat memengaruhi beberapa atau semua resource regional yang disediakan dalam region tersebut. Pemadaman layanan tersebut dapat disebabkan oleh bencana alam atau kegagalan infrastruktur berskala besar.
Resource multi-region
Resource multi-region didistribusikan di berbagai region tertentu. Berikut adalah contoh resource multi-region. Ini bukan merupakan daftar lengkap.
- Bucket Cloud Storage multi-region dan dual-region
- Instance Spanner multi-region
- Instance Bigtable multi-cluster (multi-region)
- Key ring multi-region di Cloud Key Management Service
Untuk mengetahui daftar lengkap Layanan Google yang tersedia dalam konfigurasi multi-region, lihat Produk yang tersedia berdasarkan lokasi.
Resource multi-region tahan terhadap insiden di region dan zona tertentu. Pemadaman infrastruktur yang terjadi di beberapa region dapat memengaruhi ketersediaan beberapa atau semua resource multi-region yang disediakan di region yang terpengaruh.
Resource global
Resource global tersedia di semua lokasi Google Cloud. Berikut adalah contoh resource global. Ini bukan merupakan daftar lengkap.
Project. Untuk panduan dan praktik terbaik mengenai cara mengatur resource Google Cloud ke dalam folder dan project, lihat Menentukan hierarki resource untuk zona landing Google Cloud.
Jaringan VPC, termasuk rute terkait dan aturan firewall
Zona Cloud DNS
Load Balancer Aplikasi eksternal global
Key ring global di Cloud Key Management Service
Topik Pub/Sub
Secret di Secret Manager
Untuk daftar lengkap Layanan Google yang tersedia secara global, lihat Produk global.
Resource global tahan terhadap insiden zona dan regional. Resource ini tidak bergantung pada infrastruktur di region tertentu. Google Cloud memiliki sistem dan proses yang membantu meminimalkan risiko pemadaman infrastruktur global. Google juga terus memantau infrastruktur, dan dengan cepat menyelesaikan pemadaman layanan global.
Tabel berikut merangkum ketahanan relatif resource zona, regional, multi-region, dan global terhadap masalah aplikasi dan infrastruktur. Panduan ini juga menjelaskan upaya yang diperlukan untuk menyiapkan resource tersebut, dan rekomendasi untuk mengurangi dampak pemadaman layanan.
| Cakupan resource | Ketahanan | Rekomendasi untuk mengurangi dampak pemadaman infrastruktur |
|---|---|---|
| Zonal | Rendah | Deploy resource secara redundan di beberapa zona atau region. |
| Regional | Sedang | Deploy resource secara redundan di beberapa region. |
| Multi-region atau global | Tinggi | Kelola perubahan dengan hati-hati, dan gunakan penggantian defense-in-depth jika memungkinkan. Untuk informasi selengkapnya, lihat Rekomendasi untuk mengelola risiko gangguan layanan resource global. |
Rekomendasi untuk mengelola risiko gangguan layanan resource global
Untuk memanfaatkan ketahanan resource global terhadap gangguan layanan zona dan region, sebaiknya gunakan resource global tertentu dalam arsitektur Anda. Google merekomendasikan pendekatan berikut untuk mengelola risiko pemadaman resource global:
Manajemen perubahan yang cermat pada resource global
Resource global tahan terhadap kegagalan fisik. Konfigurasi untuk resource tersebut memiliki cakupan global. Dengan demikian, menyiapkan dan mengonfigurasi satu resource global lebih mudah daripada mengoperasikan beberapa resource regional. Namun, error kritis dalam konfigurasi resource global dapat menjadikannya sebagai titik tunggal kegagalan (SPOF). Misalnya, Anda dapat menggunakan load balancer global sebagai frontend untuk aplikasi yang didistribusikan secara geografis. Load balancing global sering kali merupakan pilihan yang tepat untuk aplikasi tersebut. Namun, error pada konfigurasi load balancer dapat menyebabkannya tidak tersedia di semua wilayah geografis. Untuk menghindari risiko ini, Anda harus mengelola perubahan konfigurasi pada resource global dengan hati-hati. Untuk mengetahui informasi selengkapnya, lihat Mengontrol perubahan pada resource global.
Penggunaan sumber daya regional sebagai penggantian defense-in-depth
Untuk aplikasi yang memiliki persyaratan ketersediaan yang sangat tinggi, penggantian defense-in-depth regional dapat membantu meminimalkan efek pemadaman resource global. Pertimbangkan contoh aplikasi yang didistribusikan secara geografis dan memiliki load balancing global sebagai frontend. Untuk memastikan aplikasi tetap dapat diakses meskipun load balancer global terpengaruh oleh pemadaman layanan global, Anda dapat men-deploy load balancer regional. Anda dapat mengonfigurasi klien agar memilih load balancer global, tetapi beralih ke load balancer regional terdekat jika load balancer global tidak tersedia.
Contoh arsitektur dengan resource zona, regional, dan global
Topologi cloud Anda dapat mencakup kombinasi resource zona, regional, dan global, seperti yang ditunjukkan pada diagram berikut. Diagram berikut menunjukkan contoh arsitektur untuk aplikasi multi-tingkat yang di-deploy di Google Cloud.
Seperti yang ditunjukkan pada diagram sebelumnya, load balancer HTTP/S eksternal global menerima permintaan klien. Load balancer mendistribusikan permintaan ke backend, yang merupakan MIG regional yang memiliki dua VM Compute Engine. Aplikasi yang berjalan di VM menulis data ke dan membaca dari database Cloud SQL. Database dikonfigurasi untuk memiliki ketersediaan tinggi (HA). Instance database utama dan standby disediakan di zona terpisah, dan database utama direplikasi secara sinkron ke database standby. Selain itu, database dicadangkan secara otomatis ke bucket multi-region di Cloud Storage.
Tabel berikut merangkum resource Google Cloud dalam arsitektur sebelumnya dan ketahanan setiap resource terhadap pemadaman zona dan region:
| Resource | Ketahanan terhadap gangguan layanan |
|---|---|
| Jaringan VPC | Jaringan VPC, termasuk rute terkait dan aturan firewall, merupakan resource global. Perangkat ini tahan terhadap gangguan zona dan region. |
| Subnet | Subnet VPC adalah resource regional. Perangkat ini tahan terhadap gangguan layanan zona. |
| Load balancer HTTP/S eksternal global | Load balancer HTTP/S eksternal global tahan terhadap gangguan layanan zona dan region. |
| MIG Regional | MIG regional tahan terhadap pemadaman zona. |
| VM Compute Engine | VM Compute Engine adalah resource zona. Jika terjadi gangguan layanan zona, setiap VM Compute Engine mungkin akan terpengaruh. Namun, aplikasi dapat terus melayani permintaan karena backend untuk load balancer adalah MIG regional, bukan VM mandiri. |
| Instance Cloud SQL | Deployment Cloud SQL dalam arsitektur ini dikonfigurasikan
untuk ketersediaan tinggi (HA); Artinya, deployment tersebut mencakup pasangan instance
database standby utama. Database utama direplikasi secara sinkron
ke database standby dengan menggunakan persistent disk regional.
|
| Bucket Cloud Storage multi-region | Data yang disimpan di bucket Cloud Storage multi-region tahan terhadap gangguan layanan satu region. |
| Persistent disk | Persistent disk dapat bersifat zonal atau regional. Persistent disk regional tahan terhadap pemadaman zona. Untuk mempersiapkan pemulihan dari gangguan layanan, Anda dapat menjadwalkan snapshot persistent disk dan menyimpan snapshot tersebut di bucket Cloud Storage multi-region. |