Dokumen dalam Google Cloud Framework Arsitektur yang Baik: Perspektif layanan keuangan (FS) memberikan ringkasan prinsip dan rekomendasi untuk mendesain, men-deploy, dan mengoperasikan workload FS yang andal di Google Cloud. Dokumen ini membahas cara mengintegrasikan praktik keandalan dan observabilitas tingkat lanjut ke dalam cetak biru arsitektur Anda. Rekomendasi dalam dokumen ini selaras dengan pilar keandalan Framework Arsitektur yang Baik.
Bagi lembaga keuangan, infrastruktur yang andal dan tangguh adalah kebutuhan bisnis dan keharusan peraturan. Untuk memastikan workload FS di Google Cloud andal, Anda harus memahami dan mengurangi potensi titik kegagalan, men-deploy resource secara redundan, dan merencanakan pemulihan. Ketahanan operasional adalah hasil dari keandalan. Ketahanan operasional adalah kemampuan untuk menyerap, beradaptasi, dan pulih dari gangguan. Ketahanan operasional membantu organisasi FS memenuhi persyaratan peraturan yang ketat. Ketahanan operasional juga membantu menghindari kerugian yang tidak dapat ditoleransi bagi pelanggan.
Elemen penyusun utama keandalan di Google Cloud adalah region, zona, dan berbagai cakupan lokasi resource cloud resources: zonal, regional, multi-regional, global. Anda dapat meningkatkan ketersediaan dengan menggunakan layanan terkelola, mendistribusikan resource, menerapkan pola ketersediaan tinggi, dan mengotomatiskan proses.
Persyaratan peraturan
Organisasi FS beroperasi berdasarkan mandat keandalan yang ketat dari lembaga pengatur seperti Federal Reserve System di Amerika Serikat, European Banking Authority di Uni Eropa, dan Prudential Regulation Authority di Inggris Raya. Secara global, regulator menekankan ketahanan operasional, yang sangat penting untuk stabilitas keuangan dan perlindungan konsumen. Ketahanan operasional adalah kemampuan untuk menahan gangguan, pulih secara efektif, dan mempertahankan layanan penting. Hal ini memerlukan pendekatan yang selaras untuk mengelola risiko teknologi dan dependensi pada pihak ketiga.
Persyaratan peraturan di sebagian besar yurisdiksi memiliki tema umum berikut:
- Keamanan siber dan ketahanan teknologi: Memperkuat pertahanan terhadap ancaman siber dan memastikan ketahanan sistem IT.
- Pengelolaan risiko pihak ketiga: Mengelola risiko yang terkait dengan layanan outsourcing kepada penyedia teknologi informasi dan komunikasi (ICT).
- Kelangsungan bisnis dan respons insiden: Perencanaan yang kuat untuk mempertahankan operasi penting selama gangguan dan pulih secara efektif.
- Melindungi stabilitas keuangan: Memastikan kesehatan dan stabilitas sistem keuangan yang lebih luas.
Rekomendasi keandalan dalam dokumen ini dipetakan ke prinsip inti berikut:
- Memprioritaskan deployment multi-zona dan multi-region
- Menghilangkan titik tunggal kegagalan (SPOF)
- Memahami dan mengelola ketersediaan gabungan
- Menerapkan strategi DR yang kuat
- Memanfaatkan layanan terkelola
- Mengotomatiskan proses penyediaan dan pemulihan infrastruktur
Memprioritaskan deployment multi-zona dan multi-region
Untuk aplikasi layanan keuangan penting, sebaiknya gunakan topologi multi-region yang didistribusikan di setidaknya dua region dan di tiga zona dalam setiap region. Pendekatan ini penting untuk ketahanan terhadap pemadaman zona dan region. Peraturan sering kali menetapkan pendekatan ini, karena jika terjadi kegagalan di satu zona atau region, sebagian besar yurisdiksi menganggap gangguan parah pada zona kedua sebagai konsekuensi yang mungkin terjadi. Alasannya adalah ketika satu lokasi gagal, lokasi lain mungkin menerima traffic tambahan yang sangat tinggi.
Pertimbangkan rekomendasi berikut untuk membangun ketahanan terhadap pemadaman zona dan region:
- Pilih resource yang memiliki cakupan lokasi yang lebih luas. Jika memungkinkan, gunakan resource regional, bukan resource zona, dan gunakan resource multi-regional atau global, bukan resource regional. Pendekatan ini membantu menghindari kebutuhan untuk memulihkan operasi menggunakan cadangan.
- Di setiap region, manfaatkan tiga zona, bukan dua. Untuk menangani failover, sediakan kapasitas berlebih sepertiga lebih banyak dari perkiraan.
- Minimalkan langkah-langkah pemulihan manual dengan menerapkan deployment aktif-aktif seperti contoh berikut:
- Database terdistribusi seperti Spanner menyediakan redundansi dan sinkronisasi bawaan di seluruh region.
- Fitur HA Cloud SQL menyediakan topologi yang hampir aktif-aktif, dengan replika baca di seluruh zona. Fitur ini menyediakan batas titik pemulihan (RPO) antar-region yang mendekati 0.
- Distribusikan traffic pengguna di seluruh region menggunakan Cloud DNS, dan deploy load balancer regional di setiap region. Load balancer global adalah opsi lain yang dapat Anda pertimbangkan, bergantung pada persyaratan dan tingkat kepentingannya. Untuk mengetahui informasi selengkapnya, lihat Manfaat dan risiko load balancing global untuk deployment multi-region.
- Untuk menyimpan data, gunakan layanan multi-region seperti Spanner dan Cloud Storage.
Menghilangkan titik tunggal kegagalan
Distribusikan resource di berbagai lokasi dan gunakan resource redundan untuk mencegah titik tunggal kegagalan (SPOF) memengaruhi seluruh stack aplikasi.
Pertimbangkan rekomendasi berikut untuk menghindari SPOF:
- Hindari men-deploy hanya satu server aplikasi atau database.
- Pastikan pembuatan ulang VM yang gagal secara otomatis menggunakan grup instance terkelola (MIG).
- Distribusikan traffic secara merata di seluruh resource yang tersedia dengan menerapkan load balancing.
- Gunakan konfigurasi HA untuk database seperti Cloud SQL.
- Tingkatkan ketersediaan data menggunakan persistent disk regional dengan replikasi sinkron.
Untuk mengetahui informasi selengkapnya, lihat Mendesain infrastruktur yang andal untuk workload Anda di Google Cloud.
Memahami dan mengelola ketersediaan gabungan
Perlu diketahui bahwa ketersediaan gabungan atau keseluruhan sistem dipengaruhi oleh ketersediaan setiap tingkat atau komponen sistem. Jumlah tingkat dalam stack aplikasi memiliki hubungan terbalik dengan ketersediaan gabungan stack. Pertimbangkan rekomendasi berikut untuk mengelola ketersediaan gabungan:
Hitung ketersediaan gabungan stack multi-tingkat menggunakan rumus ketersediaan_tingkat1 × ketersediaan_tingkat2 × ketersediaan_tingkatN.
Diagram berikut menunjukkan perhitungan ketersediaan gabungan untuk sistem multi-tingkat yang terdiri dari empat layanan:
Dalam diagram sebelumnya, layanan di setiap tingkat memberikan ketersediaan 99,9%, tetapi ketersediaan gabungan sistem lebih rendah, yaitu 99,6% (0,999 × 0,999 × 0,999 × 0,999). Secara umum, ketersediaan gabungan stack multi-tingkat lebih rendah daripada ketersediaan tingkat yang memberikan ketersediaan terendah.
Jika memungkinkan, pilih paralelisasi daripada penggabungan. Dengan layanan yang diparalelkan, ketersediaan end-to-end lebih tinggi daripada ketersediaan setiap layanan.
Diagram berikut menunjukkan dua layanan, A dan B, yang di-deploy menggunakan pendekatan penggabungan dan paralelisasi:
Dalam contoh sebelumnya, kedua layanan memiliki SLA 99%, yang menghasilkan ketersediaan gabungan berikut, bergantung pada pendekatan implementasi:
- Layanan yang digabungkan menghasilkan ketersediaan gabungan hanya 98% (.99 × .99).
- Layanan yang diparalelkan menghasilkan ketersediaan gabungan yang lebih tinggi, yaitu 99,99%, karena setiap layanan berjalan secara independen dan layanan individual tidak terpengaruh oleh ketersediaan layanan lainnya. Rumus untuk layanan yang diparalelkan dan digabungkan adalah 1 − (1 − A) × (1 − B).
Pilih Google Cloud layanan dengan SLA waktu aktif yang dapat membantu memenuhi tingkat waktu aktif keseluruhan yang diperlukan untuk stack aplikasi Anda.
Saat mendesain arsitektur, pertimbangkan aspek untung rugi antara ketersediaan, kompleksitas operasional, latensi, dan biaya. Meningkatkan jumlah angka sembilan ketersediaan umumnya memerlukan biaya yang lebih besar, tetapi hal ini membantu Anda memenuhi persyaratan peraturan.
Misalnya, ketersediaan 99,9% (tiga angka sembilan) berarti potensi waktu nonaktif 86 detik dalam satu hari 24 jam. Sebaliknya, 99% (dua angka sembilan) berarti waktu nonaktif 864 detik selama periode yang sama, yang 10 kali lebih banyak waktu nonaktif daripada dengan tiga angka sembilan ketersediaan.
Untuk layanan keuangan penting, opsi arsitektur mungkin terbatas. Namun, penting untuk mengidentifikasi persyaratan ketersediaan dan menghitung ketersediaan secara akurat. Melakukan penilaian tersebut membantu Anda menilai implikasi keputusan desain terhadap arsitektur dan anggaran.
Menerapkan strategi DR yang kuat
Buat rencana yang jelas untuk berbagai skenario bencana, termasuk pemadaman zona dan regional. Strategi pemulihan dari bencana (DR) yang jelas memungkinkan Anda pulih dari gangguan dan melanjutkan operasi normal dengan dampak minimal.
DR dan ketersediaan tinggi (HA) adalah konsep yang berbeda. Dengan deployment cloud, secara umum, DR berlaku untuk deployment multi-region dan HA berlaku untuk deployment regional. Arketipe deployment ini mendukung mekanisme replikasi yang berbeda.
- HA: Banyak layanan terkelola yang menyediakan replikasi sinkron antar- zona dalam satu region secara default. Layanan tersebut mendukung batas waktu pemulihan (RTO) dan batas titik pemulihan (RPO) nol atau mendekati nol. Dukungan ini memungkinkan Anda membuat topologi deployment aktif-aktif yang tidak memiliki SPOF.
- DR: Untuk workload yang di-deploy di dua region atau lebih, jika Anda tidak menggunakan layanan multi-regional atau global, Anda harus menentukan strategi replikasi. Strategi replikasi biasanya bersifat asinkron. Nilai dengan cermat bagaimana replikasi tersebut memengaruhi RTO dan RPO untuk aplikasi penting. Identifikasi operasi manual atau semi-otomatis yang diperlukan untuk failover.
Untuk lembaga keuangan, pilihan region failover mungkin dibatasi oleh peraturan tentang kedaulatan data dan residensi data. Jika Anda memerlukan topologi aktif-aktif di dua region, sebaiknya pilih layanan multi-regional terkelola, seperti Spanner dan Cloud Storage, terutama jika replikasi data sangat penting.
Pertimbangkan rekomendasi berikut:
- Gunakan layanan penyimpanan multi-regional terkelola untuk data.
- Ambil snapshot data di persistent disk dan simpan snapshot di lokasi multi-region.
- Saat menggunakan resource regional atau zona, siapkan replikasi data ke region lain.
- Validasi bahwa rencana DR Anda efektif dengan menguji rencana secara teratur.
- Perhatikan RTO dan RPO serta korelasinya dengan toleransi dampak yang ditetapkan oleh peraturan keuangan di yurisdiksi Anda.
Untuk mengetahui informasi selengkapnya, lihat Merancang pemulihan dari bencana untuk pemadaman infrastruktur cloud.
Memanfaatkan layanan terkelola
Jika memungkinkan, gunakan layanan terkelola untuk memanfaatkan fitur bawaan untuk pencadangan, HA, dan skalabilitas. Pertimbangkan rekomendasi berikut untuk menggunakan layanan terkelola:
- Gunakan layanan terkelola di Google Cloud. Layanan ini menyediakan HA yang didukung oleh SLA. Layanan ini juga menawarkan mekanisme pencadangan dan fitur ketahanan bawaan.
- Untuk pengelolaan data, pertimbangkan layanan seperti Cloud SQL, Cloud Storage, dan Spanner,
- Untuk hosting komputasi dan aplikasi, pertimbangkan grup instance terkelola (MIG) Compute Engine dan cluster Google Kubernetes Engine (GKE). MIG regional dan cluster regional GKE tahan terhadap pemadaman zona.
- Untuk meningkatkan ketahanan terhadap pemadaman region, gunakan layanan multi-regional terkelola.
- Identifikasi kebutuhan rencana keluar untuk layanan yang memiliki karakteristik unik dan tentukan rencana yang diperlukan. Regulator keuangan seperti FCA, PRA, dan EBA mewajibkan perusahaan untuk memiliki strategi dan rencana kontingensi untuk pengambilan data dan kelangsungan operasional jika hubungan dengan penyedia cloud berakhir. Perusahaan harus menilai kelayakan keluar sebelum menandatangani kontrak cloud dan harus mempertahankan kemampuan untuk mengubah penyedia tanpa gangguan operasional.
- Pastikan layanan yang Anda pilih mendukung ekspor data ke format terbuka seperti CSV, Parquet, dan Avro. Pastikan apakah layanan tersebut didasarkan pada teknologi terbuka, seperti dukungan GKE untuk format Open Container Initiative (OCI) atau Managed Service untuk Apache Airflow yang dibangun di Apache Airflow.
Mengotomatiskan proses penyediaan dan pemulihan infrastruktur
Otomatisasi membantu meminimalkan kesalahan manusia dan membantu mengurangi waktu dan resource yang diperlukan untuk merespons insiden. Penggunaan otomatisasi dapat membantu memastikan pemulihan yang lebih cepat dari kegagalan dan hasil yang lebih konsisten. Pertimbangkan rekomendasi berikut untuk mengotomatiskan cara Anda menyediakan dan memulihkan resource:
- Minimalkan kesalahan manusia dengan menggunakan alat infrastruktur sebagai kode (IaC) seperti Terraform.
- Kurangi intervensi manual dengan mengotomatiskan proses failover. Respons otomatis juga dapat membantu mengurangi dampak kegagalan. Misalnya, Anda dapat menggunakan Eventarc atau Workflows untuk otomatis memicu tindakan perbaikan sebagai respons terhadap masalah yang diamati melalui log audit.
- Tingkatkan kapasitas resource cloud Anda selama failover menggunakan penskalaan otomatis.
- Terapkan kebijakan dan batasan secara otomatis untuk persyaratan peraturan di seluruh topologi cloud Anda selama deployment layanan dengan mengadopsi platform engineering.