Arsitektur ini menyediakan framework dan deployment referensi untuk membantu Anda mengembangkan strategi pencadangan BigQuery. Framework yang direkomendasikan ini dan otomatisasinya dapat membantu organisasi Anda melakukan hal berikut:
- Patuhi tujuan pemulihan dari bencana organisasi Anda.
- Memulihkan data yang hilang karena kesalahan manusia.
- Mematuhi peraturan.
- Meningkatkan efisiensi operasional.
Cakupan data BigQuery dapat mencakup (atau mengecualikan) folder, project, set data, dan tabel. Arsitektur yang direkomendasikan ini menunjukkan cara mengotomatiskan operasi pencadangan berulang dalam skala besar. Anda dapat menggunakan dua metode pencadangan untuk setiap tabel: snapshot BigQuery dan ekspor BigQuery ke Cloud Storage.
Dokumen ini ditujukan untuk arsitek, engineer, dan petugas tata kelola data cloud yang ingin menentukan dan mengotomatiskan kebijakan data di organisasi mereka.
Arsitektur
Diagram berikut menunjukkan arsitektur pencadangan otomatis:
Alur kerja yang ditampilkan dalam diagram sebelumnya mencakup fase berikut:
- Cloud Scheduler memicu operasi ke layanan dispatcher melalui pesan Pub/Sub, yang berisi cakupan data BigQuery yang disertakan dan dikecualikan. Proses dijalankan sesuai jadwal menggunakan ekspresi cron.
- Layanan dispatcher, yang dibuat di Cloud Run, menggunakan BigQuery API untuk mencantumkan tabel yang berada dalam cakupan BigQuery.
- Layanan dispatcher mengirimkan satu permintaan untuk setiap tabel ke layanan konfigurator melalui pesan Pub/Sub.
Layanan konfigurator Cloud Run menghitung kebijakan cadangan tabel dari salah satu opsi yang ditentukan berikut:
- Kebijakan tingkat tabel, yang ditentukan oleh pemilik data.
- Kebijakan penggantian, yang ditentukan oleh petugas tata kelola data, untuk tabel yang tidak memiliki kebijakan yang ditentukan.
Untuk mengetahui detail tentang kebijakan pencadangan, lihat Kebijakan pencadangan.
Layanan konfigurator mengirimkan satu permintaan untuk setiap tabel ke layanan berikutnya, berdasarkan kebijakan pencadangan yang dihitung.
Bergantung pada metode pencadangan, salah satu layanan Cloud Run kustom berikut mengirimkan permintaan ke BigQuery API dan menjalankan proses pencadangan:
- Layanan untuk snapshot BigQuery mencadangkan tabel sebagai snapshot.
- Layanan untuk ekspor data mencadangkan tabel sebagai ekspor data ke Cloud Storage.
Jika metode pencadangan adalah ekspor data tabel, sink log Cloud Logging akan memproses peristiwa penyelesaian tugas ekspor untuk mengaktifkan eksekusi asinkron langkah berikutnya.
Setelah layanan pencadangan menyelesaikan operasinya, Pub/Sub akan memicu layanan pemberi tag.
Untuk setiap tabel, layanan pemberi tag mencatat hasil layanan cadangan dan memperbarui status cadangan di lapisan metadata Cloud Storage.
Produk yang digunakan
Arsitektur referensi ini menggunakan produk Google Cloud berikut:
- BigQuery: Data warehouse perusahaan yang membantu Anda mengelola dan menganalisis data dengan fitur bawaan seperti analisis geospasial machine learning, dan business intelligence.
- Cloud Logging: Sistem pengelolaan log real-time dengan penyimpanan, penelusuran, analisis, dan pemberitahuan.
- Pub/Sub: Layanan pesan asinkron dan skalabel yang memisahkan layanan yang menghasilkan pesan dari layanan yang memproses pesan tersebut.
- Cloud Run: Platform komputasi serverless yang memungkinkan Anda menjalankan container langsung di atas infrastruktur Google yang skalabel.
- Cloud Storage: Penyimpanan objek berbiaya rendah tanpa batas untuk berbagai jenis data. Data dapat diakses dari dalam dan luar Google Cloud, serta direplikasi di seluruh lokasi untuk redundansi.
- Cloud Scheduler: Penjadwal tugas cron tingkat perusahaan yang terkelola sepenuhnya yang memungkinkan Anda menyiapkan unit tugas terjadwal untuk dijalankan pada waktu yang ditentukan atau interval reguler.
- Datastore: Database NoSQL yang sangat skalabel untuk aplikasi web dan seluler Anda.
Kasus penggunaan
Bagian ini memberikan contoh kasus penggunaan yang dapat Anda gunakan untuk arsitektur ini.
Otomatisasi pencadangan
Misalnya, perusahaan Anda mungkin beroperasi di industri yang diatur dan menggunakan BigQuery sebagai data warehouse utama. Meskipun perusahaan Anda mengikuti praktik terbaik dalam pengembangan software, peninjauan kode, dan rekayasa rilis, masih ada risiko kehilangan data atau kerusakan data karena kesalahan manusia. Dalam industri yang diatur, Anda harus meminimalkan risiko ini sebanyak mungkin.
Contoh kesalahan manusia ini meliputi:
- Penghapusan tabel secara tidak sengaja.
- Kerusakan data karena logika pipeline data yang salah.
Jenis kesalahan manusia ini biasanya dapat diatasi dengan fitur time travel, yang memungkinkan Anda memulihkan data hingga tujuh hari yang lalu. Selain itu, BigQuery juga menawarkan periode fail-safe, selama periode tersebut data yang dihapus akan disimpan di penyimpanan fail-safe selama tujuh hari lagi setelah periode perjalanan waktu usai. Data tersebut tersedia untuk pemulihan darurat melalui Cloud Customer Care. Namun, jika perusahaan Anda tidak menemukan dan memperbaiki error tersebut dalam jangka waktu gabungan ini, data yang dihapus tidak dapat lagi dipulihkan dari status stabil terakhirnya.
Untuk mengurangi hal ini, sebaiknya jalankan pencadangan rutin untuk setiap tabel BigQuery yang tidak dapat direkonstruksi dari data sumber (misalnya, data historis atau KPI dengan logika bisnis yang berkembang).
Perusahaan Anda dapat menggunakan skrip dasar untuk mencadangkan puluhan tabel. Namun, jika Anda perlu mencadangkan ratusan atau ribuan tabel secara rutin di seluruh organisasi, Anda memerlukan solusi otomatisasi yang skalabel yang dapat melakukan hal berikut:
- Menangani batas Google Cloud API yang berbeda.
- Memberikan framework standar untuk menentukan kebijakan pencadangan.
- Memberikan transparansi dan kemampuan pemantauan untuk operasi pencadangan.
Kebijakan pencadangan
Perusahaan Anda mungkin juga mewajibkan kebijakan pencadangan ditentukan oleh grup orang berikut:
- Pemilik data, yang paling memahami tabel dan dapat menetapkan kebijakan pencadangan tingkat tabel yang sesuai.
- Tim tata kelola data, yang memastikan bahwa kebijakan penggantian diterapkan untuk mencakup tabel apa pun yang tidak memiliki kebijakan tingkat tabel. Kebijakan penggantian memastikan bahwa set data, project, dan folder tertentu dicadangkan untuk mematuhi peraturan retensi data perusahaan Anda.
Dalam deployment untuk arsitektur referensi ini, ada dua cara untuk menentukan kebijakan pencadangan untuk tabel, dan keduanya dapat digunakan bersama:
Konfigurasi pemilik data (terdesentralisasi): kebijakan pencadangan tingkat tabel, yang dilampirkan secara manual ke tabel.
- Pemilik data menentukan file JSON tingkat tabel yang disimpan di bucket umum.
- Kebijakan manual lebih diutamakan daripada kebijakan penggantian saat solusi menentukan kebijakan pencadangan tabel.
- Untuk mengetahui detail dalam deployment, lihat Menetapkan kebijakan pencadangan tingkat tabel.
Konfigurasi default organisasi (terpusat): kebijakan penggantian, yang hanya berlaku untuk tabel yang tidak memiliki kebijakan yang dilampirkan secara manual.
- Tim tata kelola data menentukan file JSON pusat di Terraform, sebagai bagian dari solusi.
- Kebijakan penggantian menawarkan strategi pencadangan default di tingkat folder, project, set data, dan tabel.
- Untuk mengetahui detail dalam deployment, lihat Menentukan kebijakan pencadangan penggantian.
Pencadangan versus replikasi
Proses pencadangan membuat salinan data tabel dari titik waktu tertentu, sehingga dapat dipulihkan jika data hilang atau rusak. Pencadangan dapat dijalankan sebagai peristiwa satu kali atau berulang (melalui kueri atau alur kerja terjadwal). Di BigQuery, pencadangan titik waktu dapat dilakukan dengan snapshot. Anda dapat menggunakan snapshot untuk menyimpan salinan data setelah periode perjalanan waktu tujuh hari dalam lokasi penyimpanan yang sama dengan data sumber. Snapshot BigQuery sangat membantu untuk memulihkan data setelah kesalahan manusia yang menyebabkan kehilangan atau kerusakan data, bukan memulihkan dari kegagalan regional. BigQuery menawarkan Sasaran Tingkat Layanan (SLO) sebesar 99,9% hingga 99,99%, bergantung pada edisi.
Sebaliknya, replikasi adalah proses berkelanjutan untuk menyalin perubahan database ke database sekunder (atau replika) di lokasi yang berbeda. Di BigQuery, replikasi lintas region dapat membantu menyediakan redundansi geografis dengan membuat salinan data hanya baca di region Google Cloud sekunder, yang berbeda dengan region data sumber. Namun, replikasi lintas-region BigQuery tidak dimaksudkan untuk digunakan sebagai disaster recovery plan untuk skenario pemadaman layanan seluruh region. Untuk ketahanan terhadap bencana regional, pertimbangkan untuk menggunakan pemulihan dari bencana yang dikelola BigQuery.
Replikasi lintas region BigQuery menyediakan salinan data hanya baca yang sinkron di region yang dekat dengan konsumen data. Salinan data ini memungkinkan penggabungan yang ditempatkan berdekatan dan menghindari traffic dan biaya lintas-regional. Namun, dalam kasus kerusakan data karena kesalahan manusia, replikasi saja tidak dapat membantu pemulihan, karena data yang rusak otomatis disalin ke replika. Dalam kasus tersebut, pencadangan titik waktu (snapshot) adalah pilihan yang lebih baik.
Tabel berikut menunjukkan ringkasan perbandingan metode pencadangan dan replika:
| Metode | Frekuensi | Lokasi penyimpanan | Kasus penggunaan | Biaya |
|---|---|---|---|---|
| Pencadangan (Snapshot atau ekspor Cloud Storage) |
Satu kali atau berulang | Sama seperti data tabel sumber | Memulihkan data asli, di luar periode perjalanan waktu | Snapshot dikenai biaya penyimpanan untuk perubahan data dalam snapshot saja Ekspor dapat dikenai biaya penyimpanan standar Lihat Pengoptimalan biaya |
| Replikasi lintas-region | Terus-menerus | Eksternal | Membuat replika di region lain Migrasi satu kali antar-region |
Mengakibatkan biaya penyimpanan data
di replika Mengakibatkan biaya replikasi data |
Pertimbangan desain
Bagian ini memberikan panduan yang perlu Anda pertimbangkan saat menggunakan arsitektur referensi ini untuk mengembangkan topologi yang memenuhi persyaratan spesifik Anda terkait keamanan, keandalan, pengoptimalan biaya, efisiensi operasional, dan performa.
Keamanan, privasi, dan kepatuhan:
Deployment ini menggabungkan langkah-langkah keamanan berikut dalam desain dan penerapannya:
- Setelan ingress jaringan untuk Cloud Run hanya menerima traffic internal, untuk membatasi akses dari internet. Hal ini juga hanya mengizinkan pengguna dan akun layanan yang diautentikasi untuk memanggil layanan.
- Setiap layanan Cloud Run dan langganan Pub/Sub menggunakan akun layanan terpisah, yang hanya memiliki izin yang diperlukan. Tindakan ini mengurangi risiko yang terkait dengan penggunaan satu akun layanan untuk sistem dan mengikuti prinsip hak istimewa terendah.
Untuk pertimbangan privasi, solusi ini tidak mengumpulkan atau memproses informasi identitas pribadi (PII). Namun, jika tabel sumber telah mengekspos PII, pencadangan yang diambil dari tabel tersebut juga akan menyertakan data yang diekspos ini. Pemilik data sumber bertanggung jawab untuk melindungi PII apa pun dalam tabel sumber (misalnya, dengan menerapkan keamanan tingkat kolom, penyamaran data, atau penerusan). Cadangan hanya aman jika data sumber aman. Pendekatan lainnya adalah memastikan bahwa project, set data, atau bucket yang menyimpan data cadangan dengan PII yang terekspos memiliki kebijakan Identity and Access Management (IAM) yang diperlukan yang membatasi akses hanya untuk pengguna yang diberi otorisasi.
Sebagai solusi tujuan umum, deployment referensi tidak selalu mematuhi persyaratan spesifik industri tertentu.
Keandalan
Bagian ini menjelaskan fitur dan pertimbangan desain untuk keandalan.
Mitigasi kegagalan dengan perincian
Untuk membuat cadangan ribuan tabel, Anda mungkin akan mencapai batas API untuk produk Google Cloud yang mendasarinya (misalnya, batas operasi snapshot dan ekspor untuk setiap project). Namun, jika pencadangan satu tabel gagal karena kesalahan konfigurasi atau masalah sementara lainnya, hal itu tidak akan memengaruhi eksekusi secara keseluruhan dan kemampuan untuk mencadangkan tabel lain.
Untuk mengurangi potensi kegagalan, deployment referensi memisahkan langkah-langkah pemrosesan dengan menggunakan layanan Cloud Run yang terperinci dan menghubungkannya melalui Pub/Sub. Jika permintaan cadangan tabel gagal pada langkah layanan tag akhir, Pub/Sub hanya akan mencoba ulang langkah ini dan tidak mencoba ulang seluruh proses.
Dengan membagi alur menjadi beberapa layanan Cloud Run, bukan beberapa endpoint yang dihosting dalam satu layanan Cloud Run, Anda dapat memberikan kontrol terperinci atas setiap konfigurasi layanan. Tingkat konfigurasi bergantung pada kemampuan layanan dan API yang digunakan untuk berkomunikasi. Misalnya, layanan dispatcher dieksekusi sekali per operasi, tetapi memerlukan waktu yang cukup lama untuk mencantumkan semua tabel dalam cakupan pencadangan BigQuery. Oleh karena itu, layanan dispatcher memerlukan setelan waktu tunggu dan memori yang lebih tinggi. Namun, layanan Cloud Run untuk snapshot BigQuery dijalankan sekali per tabel dalam satu operasi, dan selesai dalam waktu lebih singkat daripada layanan dispatcher. Oleh karena itu, layanan Cloud Run memerlukan kumpulan konfigurasi yang berbeda di tingkat layanan.
Konsistensi data
Konsistensi data di seluruh tabel dan tampilan sangat penting untuk mempertahankan strategi cadangan yang andal. Karena data terus diperbarui dan diubah, pencadangan yang diambil pada waktu yang berbeda mungkin akan merekam status set data Anda yang berbeda. Cadangan dalam status yang berbeda dapat menyebabkan inkonsistensi saat Anda memulihkan data, terutama untuk tabel yang termasuk dalam set data fungsional yang sama. Misalnya, memulihkan tabel penjualan ke titik waktu yang berbeda dengan tabel inventaris yang sesuai dapat menyebabkan ketidakcocokan dalam stok yang tersedia. Demikian pula, tampilan database yang menggabungkan data dari beberapa tabel dapat sangat sensitif terhadap inkonsistensi. Memulihkan tampilan ini tanpa memastikan bahwa tabel yang mendasarinya berada dalam status yang konsisten dapat menyebabkan hasil yang tidak akurat atau menyesatkan. Oleh karena itu, saat Anda mendesain kebijakan dan frekuensi pencadangan BigQuery, Anda harus mempertimbangkan konsistensi ini dan memastikan bahwa data yang dipulihkan secara akurat mencerminkan status set data Anda di dunia nyata pada waktu tertentu.
Misalnya, dalam deployment untuk arsitektur referensi ini, konsistensi data dikontrol melalui dua konfigurasi berikut di kebijakan pencadangan. Konfigurasi ini menghitung waktu snapshot tabel yang tepat melalui perjalanan waktu, tanpa harus mencadangkan semua tabel secara bersamaan.
backup_cron: Mengontrol frekuensi pencadangan tabel. Stempel waktu awal operasi digunakan sebagai titik referensi untuk penghitungan perjalanan waktu untuk semua tabel yang dicadangkan dalam operasi ini.backup_time_travel_offset_days: Mengontrol jumlah hari di masa lalu yang harus dikurangi dari titik referensi dalam waktu (waktu mulai berjalan), untuk menghitung versi perjalanan waktu yang tepat dari tabel.
Pemulihan cadangan otomatis
Meskipun arsitektur referensi ini berfokus pada otomatisasi pencadangan dalam skala besar, Anda juga dapat mempertimbangkan untuk memulihkan cadangan ini secara otomatis. Otomatisasi tambahan ini dapat memberikan manfaat yang serupa dengan otomatisasi cadangan, termasuk peningkatan efisiensi dan kecepatan pemulihan, dengan lebih sedikit periode nonaktif. Karena solusi ini melacak semua parameter dan hasil cadangan melalui layanan tag, Anda dapat mengembangkan arsitektur serupa untuk menerapkan operasi pemulihan dalam skala besar.
Misalnya, Anda dapat membuat solusi berdasarkan pemicu on-demand yang mengirim cakupan data BigQuery ke layanan dispatcher, yang mengirim satu permintaan per tabel ke layanan konfigurator. Layanan konfigurator dapat mengambil histori pencadangan yang Anda inginkan untuk tabel tertentu. Layanan konfigurator kemudian dapat meneruskannya ke layanan pemulihan snapshot BigQuery atau layanan pemulihan Cloud Storage untuk menerapkan operasi pemulihan sebagaimana mestinya. Terakhir, layanan tag dapat menyimpan hasil operasi ini di penyimpanan status. Dengan demikian, framework pemulihan otomatis dapat memanfaatkan tujuan desain yang sama dengan framework cadangan yang dijelaskan dalam dokumen ini.
Pengoptimalan biaya
Framework arsitektur ini menyediakan kebijakan cadangan yang menetapkan parameter berikut untuk pengoptimalan biaya secara keseluruhan:
- Metode pencadangan: Framework ini menawarkan dua metode pencadangan
berikut:
- Snapshot BigQuery, yang dikenai biaya penyimpanan berdasarkan data yang diperbarui dan dihapus dibandingkan dengan tabel dasar. Oleh karena itu, snapshot lebih hemat biaya untuk tabel yang hanya dapat ditambahkan atau memiliki pembaruan terbatas.
- BigQuery Export ke Cloud Storage, yang dikenai biaya penyimpanan standar. Namun, untuk tabel besar yang mengikuti pendekatan pemotongan dan pemuatan, lebih hemat biaya untuk mencadangkannya sebagai ekspor dalam class penyimpanan yang lebih murah.
- Akhir masa berlaku snapshot: Time to live (TTL) ditetapkan untuk satu snapshot tabel, agar tidak menimbulkan biaya penyimpanan untuk snapshot tanpa batas waktu. Biaya penyimpanan dapat meningkat dari waktu ke waktu jika tabel tidak memiliki masa berlaku.
Efisiensi operasional
Bagian ini menjelaskan fitur dan pertimbangan untuk efisiensi operasional.
Kebijakan pencadangan yang terperinci dan skalabel
Salah satu sasaran framework ini adalah efisiensi operasional dengan menskalakan output bisnis sekaligus menjaga input bisnis tetap relatif rendah dan dapat dikelola. Misalnya, output adalah sejumlah besar tabel yang dicadangkan secara rutin, sedangkan input adalah sejumlah kecil kebijakan dan konfigurasi pencadangan yang dikelola.
Selain mengizinkan kebijakan pencadangan di tingkat tabel, framework ini juga mengizinkan kebijakan di tingkat set data, project, folder, dan global. Artinya, dengan beberapa konfigurasi di tingkat yang lebih tinggi (misalnya, tingkat folder atau project), ratusan atau ribuan tabel dapat dicadangkan secara rutin, dalam skala besar.
Kemampuan observasi
Dengan framework otomatisasi, Anda harus memahami status proses. Misalnya, Anda akan dapat menemukan informasi untuk kueri umum berikut:
- Kebijakan pencadangan yang digunakan oleh sistem untuk setiap tabel.
- Histori pencadangan dan lokasi pencadangan setiap tabel.
- Status keseluruhan dari satu operasi (jumlah tabel yang diproses dan tabel yang gagal).
- Error fatal yang terjadi dalam satu operasi, dan komponen atau langkah proses tempat error tersebut terjadi.
Untuk memberikan informasi ini, deployment menulis log terstruktur ke Cloud Logging pada setiap langkah eksekusi yang menggunakan layanan Cloud Run. Log mencakup input, output, dan error, beserta checkpoint progres lainnya. Sink log merutekan log ini ke tabel BigQuery. Anda dapat menjalankan sejumlah kueri untuk memantau operasi dan mendapatkan laporan untuk kasus penggunaan observabilitas umum. Untuk mengetahui informasi selengkapnya tentang log dan kueri di BigQuery, lihat Melihat log yang dirutekan ke BigQuery.
Pengoptimalan performa
Untuk menangani ribuan tabel pada setiap operasi, solusi ini memproses permintaan pencadangan secara paralel. Layanan dispatcher mencantumkan semua tabel yang disertakan dalam cakupan pencadangan BigQuery dan menghasilkan satu permintaan pencadangan per tabel pada setiap operasi. Hal ini memungkinkan aplikasi memproses ribuan permintaan dan tabel secara paralel, bukan secara berurutan.
Beberapa permintaan ini mungkin awalnya gagal karena alasan sementara seperti mencapai batas Google Cloud API yang mendasarinya atau mengalami masalah jaringan. Hingga permintaan selesai, Pub/Sub akan otomatis mencoba lagi permintaan dengan kebijakan percobaan ulang backoff eksponensial. Jika ada error fatal seperti tujuan pencadangan yang tidak valid atau izin yang tidak ada, error tersebut akan dicatat ke dalam log dan eksekusi permintaan tabel tertentu akan dihentikan tanpa memengaruhi keseluruhan operasi.
Batas
Kuota dan batas berikut berlaku untuk arsitektur ini.
Untuk snapshot tabel, hal berikut berlaku untuk setiap project operasi pencadangan yang Anda tentukan:
- Satu project dapat menjalankan hingga 100 tugas snapshot tabel serentak.
- Satu project dapat menjalankan hingga 50.000 tugas snapshot tabel per hari.
- Satu project dapat menjalankan hingga 50 tugas snapshot tabel per tabel per hari.
Untuk mengetahui detailnya, lihat Snapshot tabel.
Untuk tugas ekspor (ekspor ke Cloud Storage), hal berikut berlaku:
- Anda dapat mengekspor hingga 50 TiB data per hari dari sebuah project secara gratis, dengan menggunakan gabungan slot bersama.
- Satu project dapat menjalankan hingga 100.000 ekspor per hari. Untuk memperpanjang batas ini, buat reservasi slot.
Untuk mengetahui informasi selengkapnya tentang cara memperpanjang batas ini, lihat Tugas ekspor.
Sehubungan dengan batas serentak, arsitektur ini menggunakan Pub/Sub untuk mencoba ulang permintaan yang gagal secara otomatis karena batas ini, hingga permintaan tersebut ditayangkan oleh API. Namun, untuk batas lain pada jumlah operasi per project per hari, hal ini dapat dimitigasi dengan permintaan penambahan kuota, atau dengan menyebarkan operasi pencadangan (snapshot atau ekspor) ke beberapa project. Untuk menyebarkan operasi di seluruh project, konfigurasikan kebijakan pencadangan seperti yang dijelaskan di bagian deployment berikut:
- Menentukan kebijakan pencadangan penggantian
- Mengonfigurasi project operasi pencadangan tambahan
- Menetapkan kebijakan pencadangan tingkat tabel
Deployment
Untuk men-deploy arsitektur ini, lihat Men-deploy otomatisasi pencadangan BigQuery yang skalabel.
Langkah selanjutnya
- Pelajari BigQuery lebih lanjut:
- Untuk mengetahui lebih banyak tentang arsitektur referensi, diagram, dan praktik terbaik lainnya, jelajahi Pusat Arsitektur Cloud.
Kontributor
Penulis: Karim Wadie | Cloud Engineer Strategis
Kontributor lainnya:
- Chris DeForeest | Site Reliability Engineer
- Eyal Ben Ivri | Cloud Solutions Architect
- Jason Davenport | Developer Advocate
- Jaliya Ekanayake | Engineering Manager
- Muhammad Zain | Cloud Engineer Strategis