Dokumen dalam Google Cloud Framework yang Dirancang dengan Baik: Perspektif FSI memberikan ringkasan prinsip dan rekomendasi untuk mendesain, men-deploy, dan mengoperasikan beban kerja industri jasa keuangan (FSI) yang andal di Google Cloud. Dokumen ini membahas cara mengintegrasikan praktik keandalan dan kemampuan observasi tingkat lanjut ke dalam cetak biru arsitektur Anda. Rekomendasi dalam dokumen ini selaras dengan pilar keandalan dari Framework yang Dirancang dengan Baik.
Bagi lembaga keuangan, infrastruktur yang andal dan tangguh merupakan kebutuhan bisnis dan keharusan peraturan. Untuk memastikan workload FSI di Google Cloud dapat diandalkan, Anda harus memahami dan mengurangi potensi titik kegagalan, men-deploy resource secara redundan, dan merencanakan pemulihan. Ketahanan operasional adalah hasil dari keandalan. Resiliensi adalah kemampuan untuk menyerap, beradaptasi dengan, dan pulih dari gangguan. Ketahanan operasional membantu organisasi FSI memenuhi persyaratan peraturan yang ketat. Hal ini juga membantu menghindari bahaya yang tidak dapat ditoleransi bagi pelanggan.
Elemen penyusun keandalan utama di Google Cloud adalah region, zona, dan berbagai cakupan lokasi resource cloud: 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 FSI 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, badan pengatur menekankan ketahanan operasional, yang sangat penting bagi stabilitas keuangan dan perlindungan konsumen. Ketahanan operasional adalah kemampuan untuk menahan gangguan, memulihkan diri secara efektif, dan mempertahankan layanan penting. Hal ini memerlukan pendekatan yang terpadu untuk mengelola risiko teknologi dan ketergantungan pada pihak ketiga.
Persyaratan peraturan di sebagian besar wilayah hukum 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 meng-outsource layanan kepada penyedia teknologi informasi dan komunikasi (ICT).
- Kelangsungan bisnis dan respons insiden: Perencanaan yang andal untuk mempertahankan operasi penting selama gangguan dan untuk memulihkan secara efektif.
- Melindungi stabilitas keuangan: Memastikan kesehatan dan stabilitas sistem keuangan secara keseluruhan.
Rekomendasi keandalan dalam dokumen ini dipetakan ke prinsip inti berikut:
- Membuat prioritas deployment multi-zona dan multi-region
- Menghilangkan titik tunggal kegagalan (SPOF)
- Memahami dan mengelola ketersediaan gabungan
- Menerapkan strategi DR yang andal
- Memanfaatkan layanan terkelola
- Mengotomatiskan proses penyediaan dan pemulihan infrastruktur
Membuat prioritas deployment multi-zona dan multi-region
Untuk aplikasi layanan keuangan yang 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 layanan 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 jika satu lokasi gagal, lokasi lain mungkin menerima jumlah traffic tambahan yang sangat tinggi.
Pertimbangkan rekomendasi berikut untuk membangun ketahanan terhadap pemadaman layanan zona dan region:
- Lebih memilih resource yang memiliki cakupan lokasi yang lebih luas. Jika memungkinkan, gunakan resource regional, bukan resource zona, dan gunakan resource multiregional atau global, bukan resource regional. Pendekatan ini membantu menghindari kebutuhan untuk memulihkan operasi dengan menggunakan cadangan.
- Di setiap region, manfaatkan tiga zona, bukan dua. Untuk menangani pengalihan, sediakan kapasitas 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. Layanan ini memberikan tujuan titik pemulihan (RPO) antar-region yang mendekati 0.
- Mendistribusikan traffic pengguna di seluruh region dengan menggunakan Cloud DNS, dan men-deploy load balancer regional di setiap region. Load balancer global adalah opsi lain yang dapat Anda pertimbangkan, bergantung pada persyaratan dan tingkat kekritisan Anda. 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 satu titik 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 dengan menggunakan grup instance terkelola (MIG).
- Mendistribusikan traffic secara merata di seluruh resource yang tersedia dengan menerapkan load balancing.
- Gunakan konfigurasi HA untuk database seperti Cloud SQL.
- Tingkatkan ketersediaan data dengan 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
Perhatikan bahwa ketersediaan keseluruhan atau gabungan sistem dipengaruhi oleh ketersediaan setiap tingkat atau komponen sistem. Jumlah tingkat dalam stack aplikasi memiliki hubungan terbalik dengan ketersediaan stack gabungan. Pertimbangkan rekomendasi berikut untuk mengelola ketersediaan gabungan:
Hitung ketersediaan gabungan stack multi-tingkat menggunakan formula tier1_availability × tier2_availability × tierN_availability.
Diagram berikut menunjukkan penghitungan 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 individual.
Diagram berikut menunjukkan dua layanan, A dan B, yang di-deploy dengan menggunakan pendekatan penggabungan dan paralelisme:
Dalam contoh sebelumnya, kedua layanan memiliki SLA sebesar 99%, yang menghasilkan ketersediaan gabungan berikut, bergantung pada pendekatan penerapan:
- Layanan berantai menghasilkan ketersediaan gabungan sebesar 98% (.99 × .99).
- Layanan yang diparalelkan menghasilkan ketersediaan gabungan yang lebih tinggi sebesar 99,99% karena setiap layanan berjalan secara independen dan setiap layanan tidak terpengaruh oleh ketersediaan layanan lainnya. Formula untuk layanan paralel gabungan 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 tumpukan aplikasi Anda.
Saat mendesain arsitektur, pertimbangkan kompromi antara ketersediaan, kompleksitas operasional, latensi, dan biaya. Meningkatkan jumlah sembilan ketersediaan umumnya memerlukan biaya yang lebih besar, tetapi tindakan ini membantu Anda memenuhi persyaratan peraturan.
Misalnya, ketersediaan 99,9% (tiga sembilan) berarti potensi periode nonaktif selama 86 detik dalam satu hari 24 jam. Sebaliknya, 99% (dua sembilan) berarti periode nonaktif 864 detik selama periode yang sama, yang 10 kali lebih banyak daripada periode nonaktif dengan ketersediaan tiga sembilan.
Untuk layanan keuangan penting, opsi arsitektur mungkin terbatas. Namun, penting untuk mengidentifikasi persyaratan ketersediaan dan menghitung ketersediaan secara akurat. Melakukan penilaian seperti ini membantu Anda menilai implikasi keputusan desain terhadap arsitektur dan anggaran Anda.
Menerapkan strategi DR yang andal
Buat rencana yang jelas untuk berbagai skenario bencana, termasuk gangguan tingkat zona dan regional. Strategi pemulihan dari bencana (DR) yang jelas memungkinkan Anda memulihkan diri 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 menyediakan replikasi sinkron antara zona dalam satu region secara default. Layanan tersebut mendukung batas waktu pemulihan (RTO) dan toleransi jumlah data yang hilang (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-region atau global, Anda harus menentukan strategi replikasi. Strategi replikasi biasanya bersifat asinkron. Menilai 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 Anda 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 saat replikasi data sangat penting.
Pertimbangkan rekomendasi berikut:
- Gunakan layanan penyimpanan multiregional terkelola untuk data.
- Ambil snapshot data di persistent disk dan simpan snapshot di lokasi multi-region.
- Saat Anda menggunakan resource regional atau zona, siapkan replikasi data ke region lain.
- Pastikan rencana DR Anda efektif dengan menguji rencana tersebut secara rutin.
- Pahami RTO dan RPO serta korelasinya dengan toleransi dampak yang ditetapkan oleh peraturan keuangan di wilayah hukum 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:
- Menggunakan layanan terkelola di Google Cloud. Layanan ini menyediakan HA yang didukung oleh SLA. Layanan ini juga menawarkan mekanisme pencadangan bawaan dan fitur ketahanan.
- 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 layanan 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 memiliki strategi dan rencana darurat 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 mengganti penyedia tanpa gangguan operasional.
- Pastikan layanan yang Anda pilih mendukung ekspor data ke format terbuka seperti CSV, Parquet, dan Avro. Verifikasi apakah layanan tersebut didasarkan pada teknologi terbuka, seperti dukungan GKE untuk format Open Container Initiative (OCI) atau Cloud Composer 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 Infrastructure as Code (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 memicu tindakan perbaikan secara otomatis sebagai respons terhadap masalah yang diamati melalui log audit.
- Tingkatkan kapasitas resource cloud Anda selama failover menggunakan penskalaan otomatis.
- Terapkan kebijakan dan pelindung secara otomatis untuk persyaratan peraturan di seluruh topologi cloud Anda selama deployment layanan dengan menerapkan rekayasa platform.