Dokumen dalam Google Cloud Well-Architected Framework: Perspektif jasa keuangan (FS) ini 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 kemampuan observasi tingkat lanjut ke dalam blueprint arsitektur Anda. Rekomendasi dalam dokumen ini selaras dengan pilar keandalan Well-Architected Framework.
Bagi lembaga keuangan, infrastruktur yang andal dan tangguh merupakan kebutuhan bisnis dan keharusan peraturan. Untuk memastikan workload FS di Google Cloud andal, Anda harus memahami dan memitigasi potensi titik kegagalan, men-deploy resource secara redundan, dan merencanakan pemulihan. Ketahanan operasional adalah hasil dari keandalan. Ketahanan adalah kemampuan untuk menyerap, beradaptasi, dan pulih dari gangguan. Ketahanan operasional membantu organisasi FS 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: zona, 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 di bawah mandat keandalan yang ketat oleh badan pengatur seperti Federal Reserve System di AS, 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 bertahan dari gangguan, pulih secara efektif, dan mempertahankan layanan penting. Hal ini memerlukan pendekatan yang harmonis untuk mengelola risiko teknologi dan dependensi pada pihak ketiga.
Persyaratan peraturan di sebagian besar wilayah hukum memiliki tema umum berikut:
- Keamanan cyber dan ketahanan teknologi: Memperkuat pertahanan terhadap ancaman cyber 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 untuk memulihkan secara efektif.
- Melindungi stabilitas keuangan: Memastikan kesehatan dan stabilitas sistem keuangan yang lebih luas.
Rekomendasi keandalan dalam dokumen ini dipetakan ke prinsip-prinsip inti berikut:
- Memprioritaskan deployment multi-zona dan multi-region
- Menghilangkan titik tunggal kegagalan (SPOF)
- Memahami dan mengelola ketersediaan gabungan
- Menerapkan strategi DR yang tangguh
- Memanfaatkan layanan terkelola
- Mengotomatiskan proses penyediaan dan pemulihan infrastruktur
Memprioritaskan deployment multi-zona dan multi-region
Untuk aplikasi jasa 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 masuk akal. Alasannya adalah ketika 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:
- Pilih resource yang memiliki cakupan lokasi 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. Layanan ini memberikan tujuan 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 kekritisannya. 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 otomatis VM yang gagal menggunakan grup instance terkelola (MIG).
- Distribusikan traffic secara merata ke 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 keseluruhan atau gabungan suatu 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 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 perantaian. 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 menggunakan pendekatan perantaian dan paralelisasi:
Dalam contoh sebelumnya, kedua layanan memiliki SLA 99%, yang menghasilkan ketersediaan gabungan berikut, bergantung pada pendekatan implementasi:
- Layanan berantai menghasilkan ketersediaan gabungan hanya 98% (0,99 × 0,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 layanan Google Cloud dengan SLA waktu beroperasi yang dapat membantu memenuhi tingkat waktu beroperasi keseluruhan yang diperlukan untuk stack aplikasi Anda.
Saat mendesain arsitektur, pertimbangkan konsekuensi antara ketersediaan, kompleksitas operasional, latensi, dan biaya. Meningkatkan jumlah angka sembilan ketersediaan umumnya memerlukan biaya lebih tinggi, tetapi hal ini membantu Anda memenuhi persyaratan peraturan.
Misalnya, ketersediaan 99,9% (tiga angka sembilan) berarti potensi periode nonaktif selama 86 detik dalam 24 jam. Sebaliknya, 99% (dua sembilan) berarti periode nonaktif selama 864 detik dalam periode yang sama, yang berarti 10 kali lebih banyak periode nonaktif daripada ketersediaan tiga sembilan.
Untuk layanan keuangan penting, opsi arsitektur mungkin terbatas. Namun, penting untuk mengidentifikasi persyaratan ketersediaan dan menghitung ketersediaan secara akurat. Melakukan penilaian tersebut akan 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 pemadaman layanan zona dan regional. Strategi disaster recovery (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 menyediakan replikasi sinkron antara zona dalam satu region secara default. Layanan tersebut mendukung batas waktu pemulihan (RTO) dan toleransi durasi kehilangan data (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 asinkron. Nilai dengan cermat pengaruh replikasi tersebut terhadap 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 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 Anda menggunakan resource regional atau zona, siapkan replikasi data ke region lain.
- Validasi bahwa rencana DR Anda efektif dengan menguji rencana tersebut secara rutin.
- Perhatikan RTO dan RPO serta korelasinya dengan toleransi dampak yang ditetapkan oleh peraturan keuangan di wilayah hukum Anda.
Untuk mengetahui informasi selengkapnya, lihat Merancang disaster recovery 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. Mereka menyediakan HA yang didukung oleh SLA. Sistem 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 akan 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 kontingensi untuk pengambilan data dan kelangsungan operasional jika hubungan dengan penyedia cloud berakhir. Perusahaan harus menilai kelayakan keluar sebelum membuat 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. Verifikasi apakah layanan tersebut didasarkan pada teknologi terbuka, seperti dukungan GKE untuk format Open Container Initiative (OCI) atau Managed Service untuk Apache Airflow.
Mengotomatiskan proses penyediaan dan pemulihan infrastruktur
Otomatisasi membantu meminimalkan kesalahan manusia serta 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.
- Mengurangi 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 rekayasa platform.