Artikel ini merangkum konsep utama dari course Essential Google Cloud Infrastructure: Core Services. Materi ini berfungsi sebagai referensi konseptual, bukan panduan provisioning. Detail fitur, batas layanan, harga, dan ketersediaan regional dapat berubah sehingga dokumentasi resmi Google Cloud tetap perlu dijadikan acuan.
Daftar Isi#
- 1. Hierarki resource dan IAM
- 2. Identitas dan service account
- 3. Storage dan database
- 4. Quota, label, dan billing
- 5. Cloud Monitoring
- 6. Cloud Logging dan Error Reporting
- 7. Cloud Trace dan Cloud Profiler
- 8. Referensi
1. Hierarki resource dan IAM#
Identity and Access Management (IAM) mengatur principal yang dapat melakukan tindakan tertentu terhadap resource Google Cloud. Hierarki resource secara umum terdiri dari:
- Organization sebagai tingkat teratas.
- Folder yang dapat disusun secara bertingkat.
- Project sebagai batas pengelolaan dan pengelompokan resource.
- Resource, seperti VM, bucket, database, dan service account.
Kebijakan dapat diwariskan dari tingkat yang lebih tinggi ke resource di bawahnya. Karena itu, kebijakan pada organization atau folder dapat memengaruhi project dan resource yang berada di dalamnya.
IAM menggunakan role-based access control. Permission tidak diberikan secara langsung; permission diberikan melalui role yang kemudian di-bind kepada principal. Principal dapat berupa pengguna, grup, service account, domain, atau identitas federasi yang didukung.
Allow policy dan deny policy#
Allow policy memberikan akses melalui role, sedangkan deny policy dapat membatasi principal agar tidak menggunakan permission tertentu. Deny policy dievaluasi sebelum allow policy. Deny yang cocok umumnya mengesampingkan allow yang berlaku, tetapi evaluasi tetap mengikuti permission yang didukung, kondisi, dan exception pada deny policy.
Pemberian akses sebaiknya mengikuti prinsip least privilege. Jika akses dikelola oleh beberapa pengguna, pemberian role kepada grup biasanya lebih mudah dipelihara daripada pemberian role satu per satu.
2. Identitas dan service account#
Google Workspace dan Cloud Identity dapat digunakan untuk pengelolaan identitas organisasi. Google Groups membantu mengelompokkan principal untuk pengelolaan akses. Jika organisasi sudah menggunakan Active Directory atau LDAP, Google Cloud Directory Sync dapat menyinkronkan data direktori ke direktori Google. Sinkronisasi tersebut bukan keseluruhan proses migrasi atau cutover autentikasi.
Google Cloud juga mendukung federasi identitas dan Single Sign-On (SSO). Pilihan yang tepat bergantung pada identity provider, kebijakan organisasi, dan kebutuhan aplikasi.
Service account#
Service account digunakan sebagai identitas workload atau komunikasi antarlayanan. Sebagai contoh, workload dapat menggunakan service account untuk membaca objek dari Cloud Storage atau mengakses layanan Google Cloud lain.
Untuk workload yang berjalan di Google Cloud, attached service account, impersonation, atau mekanisme identity-aware lain umumnya lebih sesuai daripada menyimpan kunci statis. Untuk workload eksternal yang didukung, Workload Identity Federation dapat digunakan. Long-lived service account key sebaiknya dihindari jika tersedia mekanisme yang lebih aman dan terkelola.
Service account juga merupakan resource yang dapat menerima role. Role yang diberikan kepada service account menentukan akses workload tersebut, sedangkan Service Account User memberi principal kemampuan untuk menggunakan atau memasang service account pada resource tertentu. Role ini tidak secara langsung memberikan seluruh permission service account kepada principal. Impersonation dapat membutuhkan permission atau role tambahan, seperti Service Account Token Creator.
Nama, deskripsi, dan konvensi service account sebaiknya menjelaskan tujuan penggunaannya. Identity-Aware Proxy (IAP) dapat dipertimbangkan untuk mengendalikan akses ke aplikasi berbasis HTTP(S) apabila sesuai dengan arsitektur aplikasi.
3. Storage dan database#
Google Cloud menyediakan layanan penyimpanan dan database dengan karakteristik berbeda. Pemilihan layanan perlu didasarkan pada model data, pola akses, konsistensi, availability, performa, skala, dan beban operasional.
| Layanan | Peran umum |
|---|---|
| Cloud Storage | Object storage untuk data tidak terstruktur, seperti file, backup, arsip, media, dan dataset. Interoperabilitas dengan object storage lain tidak berarti API dan semantiknya identik. |
| Filestore | Managed file storage yang dapat diakses melalui filesystem jaringan. Filestore berbeda dari object storage dan block storage. |
| Cloud SQL | Relational database terkelola untuk MySQL, PostgreSQL, dan SQL Server. Skalabilitas utama dilakukan secara vertikal; read replica membantu beban baca, bukan horizontal write scaling. |
| AlloyDB for PostgreSQL | Relational database terkelola yang kompatibel dengan PostgreSQL, dengan arsitektur dan karakteristik performa berbeda dari Cloud SQL. Kompatibilitas fitur dan ekstensi tetap perlu diverifikasi. |
| Cloud Spanner | Relational database terdistribusi dengan SQL, automatic sharding, skalabilitas horizontal, dan opsi replikasi regional atau multi-region. |
| Firestore | Document database NoSQL. Native mode dan Datastore mode memiliki karakteristik serta dukungan fitur yang berbeda. |
| Cloud Bigtable | Wide-column database untuk workload berskala besar dengan throughput tinggi dan pola akses yang sesuai. |
| Memorystore | In-memory data store terkelola dengan varian Redis, Valkey, dan opsi cluster. High availability, failover, dan kapasitas bergantung pada produk serta tier yang digunakan. |
| BigQuery | Data warehouse dan platform analitik untuk query terhadap dataset berukuran besar, bukan database transaksi umum. |
Layanan-layanan tersebut tidak saling menggantikan secara langsung. Perbandingan sebaiknya dilakukan berdasarkan kebutuhan aplikasi, bukan hanya berdasarkan label database atau klaim performa umum.
4. Quota, label, dan billing#
Quota#
Quota membatasi alokasi resource atau request API pada layanan dan scope tertentu. Jenis quota, nilai default, dan proses permintaan peningkatan berbeda menurut layanan.
Quota dapat mengurangi dampak penggunaan berlebihan atau kesalahan konfigurasi, tetapi bukan pengganti IAM, pengamanan credential, atau kontrol biaya. Quota juga bukan jaminan bahwa pengeluaran akan berhenti ketika batas billing tercapai.
Label#
Label adalah metadata key-value yang dapat digunakan untuk mengelompokkan resource yang mendukungnya. Konvensi label dapat mencakup tim, aplikasi, environment, pemilik resource, atau cost center.
Label membantu inventory, filtering, dan analisis biaya, tetapi dukungan label tidak seragam pada semua jenis resource. Data label yang tersedia pada laporan billing juga mengikuti dukungan resource dan konfigurasi export yang digunakan.
Budget dan billing alert#
Budget digunakan untuk memantau biaya aktual atau estimasi biaya terhadap ambang yang ditentukan. Budget menghasilkan notifikasi ketika threshold tercapai, tetapi tidak otomatis menghentikan resource atau membatasi pengeluaran.
Notifikasi dapat dikirim melalui email dan, dengan integrasi yang sesuai, Pub/Sub untuk diproses oleh automation terpisah. Automation semacam itu perlu dirancang, diuji, dan diperlakukan sebagai kontrol tambahan, bukan sebagai jaminan pencegahan overspend secara real time.
5. Cloud Monitoring#
Cloud Monitoring digunakan untuk mengumpulkan dan menyajikan metrics, membuat dashboard, melakukan uptime check, mengeksplorasi data, dan membuat alert policy.
Metric scope memiliki satu scoping project dan dapat mencakup project lain sebagai monitored project jika permission dan batas layanan yang diperlukan tersedia. Integrasi tertentu juga memungkinkan pemantauan resource dari lingkungan lain, termasuk AWS.
Metrics Explorer sesuai untuk investigasi ad hoc, sedangkan dashboard digunakan untuk metrics yang perlu dipantau secara berkelanjutan. Custom metrics dapat digunakan untuk mengirim informasi khusus aplikasi, misalnya jumlah pengguna aktif atau kapasitas sesi. Metric tertentu juga dapat menjadi input autoscaling pada Managed Instance Group.
Monitoring group dapat mengelompokkan resource berdasarkan kriteria tertentu. Group dapat digunakan pada filter dashboard dan kondisi alert yang didukung. Evaluasi populasi, seperti persentase VM yang mengalami kondisi tertentu, tetap bergantung pada aggregation dan konfigurasi alert policy.
Cloud Monitoring menerima banyak platform metrics secara otomatis. Ops Agent digunakan bila guest-level logs atau metrics dari sistem operasi diperlukan dan didukung oleh lingkungan tersebut.
6. Cloud Logging dan Error Reporting#
Cloud Logging mengumpulkan platform log, system log, dan application log. Log dapat dicari, difilter, dan ditinjau melalui Logs Explorer.
Retention ditentukan oleh log bucket dan konfigurasinya. Retention default yang umum tidak berarti semua log selalu disimpan dengan durasi yang sama. Log dapat dirouting melalui sink ke Cloud Storage, BigQuery, atau Pub/Sub, tetapi hanya entri yang memenuhi filter sink yang akan diekspor.
Logging terutama digunakan untuk pencarian, analisis, dan investigasi. Monitoring lebih berfokus pada metrics, deteksi kondisi, dan alerting.
Error Reporting mengelompokkan exception dan crash aplikasi dari sumber serta format yang didukung. Error Reporting bukan agregator universal untuk semua error layanan cloud. Deteksi dari stderr bergantung pada runtime, format error, dan integrasi yang berlaku; library atau API resmi dapat digunakan ketika konteks error yang lebih lengkap diperlukan.
7. Cloud Trace dan Cloud Profiler#
Cloud Trace digunakan untuk menganalisis latency pada distributed request melalui span dan propagation context. Trace membantu menunjukkan alur request antarlayanan dan mengidentifikasi bottleneck. Integrasi otomatis, SDK, dan OpenTelemetry dapat digunakan sesuai dukungan runtime dan arsitektur aplikasi.
Cloud Profiler menggunakan statistical sampling dengan overhead rendah untuk membantu menemukan hotspot CPU, wall time, heap, allocation, atau contention pada workload yang didukung. Profiler melengkapi Trace; Profiler menganalisis penggunaan resource pada code location, sedangkan Trace menganalisis perjalanan request.
8. Referensi#
- Essential Google Cloud Infrastructure: Core Services
- Resource hierarchy
- IAM overview
- Deny policies
- Service accounts
- Workload Identity Federation
- Google Cloud Directory Sync
- Cloud Identity
- Cloud Storage
- Cloud SQL
- AlloyDB
- Cloud Spanner
- Firestore
- Cloud Bigtable
- Memorystore
- BigQuery
- Quotas
- Labels
- Cloud Billing budgets
- Cloud Monitoring
- Cloud Logging
- Error Reporting
- Cloud Trace
- Cloud Profiler
