Automasi Infrastruktur Kubernetes dan Terraform untuk Skalabilitas Web Multi-Cloud

1. Konteks Industri & Analisis Akar Masalah

Dalam lanskap enterprise modern, infrastruktur web tidak lagi cukup hanya dengan berjalan; infrastruktur harus resilien, dapat diskalakan secara otomatis, dan portabel lintas cloud provider (multi-cloud). Pertumbuhan lalu lintas pengguna yang eksponensial sering kali menyingkap kerapuhan arsitektur monolitik tradisional. Sebelum adopsi infrastruktur deklaratif berbasis Terraform dan orkestrasi kontainer Kubernetes, tim infrastruktur menghadapi masalah klasik: Configuration Drift (perbedaan konfigurasi antara lingkungan development, staging, dan production), Single Point of Failure (SPOF) pada penyedia cloud tunggal, serta lambatnya waktu pemulihan (Recovery Time Objective) saat terjadi kegagalan hardware.

Analisis akar masalah menunjukkan bahwa manajemen infrastruktur manual melalui UI console cloud provider atau skrip bash imperatif menciptakan dokumentasi yang usang dan rentan terhadap kesalahan manusia (human error). Ketika terjadi lonjakan traffic mendadak—misalnya pada event flash sale e-commerce—server web berbasis Nginx/Apache yang dikonfigurasi secara statis sering mengalami kehabisan memori (Out of Memory / OOM Killer), kegagalan koneksi database MySQL/MariaDB, serta bottleneck pada antrean pesan (message queue).

Kondisi Sebelum vs Sesudah Penerapan:

• Sebelum: Provisioning server memakan waktu berhari-hari, konfigurasi server tidak konsisten, pemulihan bencana manual, dan penskalaan sumber daya reaktif yang sering terlambat merespons lonjakan load.
• Sesudah: Seluruh infrastruktur didefinisikan sebagai kode (Infrastructure as Code), provisi multi-cloud terjadi dalam hitungan menit, sistem auto-scaling Kubernetes merespons metrik kustom secara real-time, dan pembaruan sistem berjalan tanpa downtime melalui strategi rolling update.

2. Konsep Inti & Deep Dive Arsitektur

Arsitektur multi-cloud berbasis Terraform dan Kubernetes memisahkan lapisan manajemen infrastruktur fisik/virtual dari lapisan orkestrasi aplikasi. Terraform bertindak sebagai declarative orchestrator untuk membangun pondasi (VPC, Subnet, Managed Kubernetes Cluster seperti AWS EKS dan GCP GKE, serta Object Storage S3/MinIO), sementara Kubernetes mengelola siklus hidup aplikasi (Pod, Service, Ingress Controller seperti Nginx/Traefik, dan Horizontal Pod Autoscaler).

+-----------------------------------------------------------------------+
|                        MULTI-CLOUD ENVIRONMENT                        | 
|                                                                       | 
|  +---------------------------+       +-----------------------------+  |
|  |     AWS Cloud (Primary)   |       |    GCP Cloud (Secondary)    |  |
|  |                           |       |                             |  |
|  |  +---------------------+  |       |  +-----------------------+  |  |
|  |  |     AWS EKS Cluster |  |       |  |     GCP GKE Cluster   |  |  |
|  |  |  +---------------+  |  |       |  |  +-----------------+  |  |  |
|  |  |  | Nginx Ingress |  |  |       |  |  | Nginx Ingress   |  |  |  |
|  |  |  +---------------+  |  |       |  |  +-----------------+  |  |  |
|  |  |  | App Pods      |  |  |       |  |  | App Pods        |  |  |  |
|  |  |  +---------------+  |  |       |  |  +-----------------+  |  |  |
|  |  +---------------------+  |       |  +-----------------------+  |  |
|  +---------------------------+       +-----------------------------+  |
|                ^                                    ^                 |
|                |       Global DNS & Cloudflare      |                 |
|                +-----------------+------------------+                 |
|                                  |                                    |
|                        +-------------------+                          | 
|                        | Terraform Remote  |                          |
|                        | State (S3 + Lock) |                          | 
|                        +-------------------+                          |
+-----------------------------------------------------------------------+

Alur data dimulai dari pengguna global yang mengakses aplikasi melalui Cloudflare CDN & WAF. Cloudflare merutekan traffic ke Ingress Controller Kubernetes di AWS atau GCP berdasarkan kebijakan latency-based routing atau failover. Di dalam klaster, request diteruskan ke backend (Go/Node/PHP-FPM) yang berkomunikasi dengan database terdistribusi dan Redis caching cluster, sementara aset statis dilayani langsung dari Object Storage (S3/MinIO).

3. Perbandingan Komparatif / Analisis Pendekatan

Untuk merancang sistem multi-cloud yang optimal, berikut adalah analisis perbandingan antara pendekatan tradisional (Virtual Machine tunggal) dan pendekatan modern (Kubernetes + Terraform Multi-Cloud):

[!WARNING] Kompleksitas operasional Kubernetes multi-cloud menuntut pemahaman mendalam tentang manajemen jaringan (overlay network), sinkronisasi state database, dan strategi keamanan lintas cloud. Jangan terburu-buru mengadopsi multi-cloud jika beban kerja belum memerlukan redundansi tingkat tinggi.

4. Prasyarat Sistem & Persiapan Lingkungan

Sebelum menjalankan kode terraform dan manifes kubernetes, pastikan toolchain berikut terinstal pada mesin control plane atau environment CI/CD Anda:

• Terraform: Versi >= 1.5.0
• Kubectl: Versi sesuai dengan minor version klaster (misal v1.28)
• Helm: Versi 3.x (untuk manajemen package Kubernetes)
• Cloud CLI: AWS CLI v2 dan Google Cloud SDK terkini dengan hak akses IAM yang memadai.

Verifikasi instalasi dengan perintah terminal:

terraform -version
kubectl version --client
helm version
aws --version
gcloud --version

Pastikan kredensial akses cloud telah diekspor sebagai variabel lingkungan:

export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
export GOOGLE_APPLICATION_CREDENTIALS="/path/to/gcp-key.json"

5. Panduan Implementasi Langkah demi Langkah

Langkah 1: Konfigurasi State Terraform yang Aman (Backend S3 + DynamoDB Lock)

Buat direktori terraform/backend untuk menginisialisasi penyimpanan state terpusat.

# terraform/backend/main.tf
terraform {
  required_version = ">= 1.5.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_s3_bucket" "terraform_state" {
  bucket        = "enterprise-terraform-state-store-2024"
  force_destroy = false

  lifecycle {
    prevent_destroy = true
  }
}

resource "aws_s3_bucket_versioning" "enabled" {
  bucket = aws_s3_bucket.terraform_state.id
  versioning_configuration {
    status = "Enabled"
  }
}

resource "aws_s3_bucket_server_side_encryption_by_default" "default" {
  bucket = aws_s3_bucket.terraform_state.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256"
    }
  }
}

resource "aws_dynamodb_table" "terraform_locks" {
  name         = "enterprise-terraform-locks"
  billing_mode = "PAY_PER_REQUEST"
  hash_key     = "LockID"

  attribute {
    name = "LockID"
    type = "S"
  }
}

output "s3_bucket_name" {
  value = aws_s3_bucket.terraform_state.id
}

output "dynamodb_table_name" {
  value = aws_dynamodb_table.terraform_locks.id
}

Langkah 2: Provisioning Infrastruktur EKS dengan Terraform

Buat file konfigurasi utama untuk AWS EKS cluster.

# terraform/eks/main.tf
terraform {
  required_version = ">= 1.5.0"
  backend "s3" {
    bucket         = "enterprise-terraform-state-store-2024"
    key            = "eks/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "enterprise-terraform-locks"
    encrypt        = true
  }
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 2.23"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.1.2"

  name = "enterprise-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["us-east-1a", "us-east-1b", "us-east-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway   = true
  single_nat_gateway   = false
  enable_dns_hostnames = true

  tags = {
    Environment = "production"
    Terraform   = "true"
  }
}

module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "19.16.0"

  cluster_name    = "enterprise-production-cluster"
  cluster_version = "1.28"

  vpc_id                   = module.vpc.vpc_id
  subnet_ids               = module.vpc.private_subnets
  control_plane_subnet_ids = module.vpc.private_subnets

  eks_managed_node_groups = {
    general = {
      min_size     = 2
      max_size     = 10
      desired_size = 3

      instance_types = ["t3.xlarge"]
      capacity_type  = "ON_DEMAND"

      disk_size = 50

      tags = {
        Environment = "production"
      }
    }
  }

  enable_irsa = true

  tags = {
    Environment = "production"
    Terraform   = "true"
  }
}

Langkah 3: Manifest Kubernetes untuk Web Application & Custom Auto-Scaling

Buat file k8s/app-deployment.yaml yang mendefinisikan deployment aplikasi web (Node.js/Go backend) beserta Horizontal Pod Autoscaler (HPA) berbasis metrik kustom (misal: jumlah request per detik / CPU utilization).

apiVersion: apps/v1
kind: Deployment
metadata:
  name: enterprise-web-app
  namespace: production
  labels:
    app: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web-app
  template:
    metadata:
      labels:
        app: web-app
    spec:
      containers:
      - name: web-app
        image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/enterprise-web:v1.2.0
        ports:
        - containerPort: 8080
          name: http
        resources:
          requests:
            cpu: "500m"
            memory: "512Mi"
          limits:
            cpu: "2"
            memory: "2Gi"
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 20
        env:
        - name: NODE_ENV
          value: "production"
        - name: DB_HOST
          value: "mysql.production.svc.cluster.local"
        - name: REDIS_HOST
          value: "redis.production.svc.cluster.local"
---
apiVersion: v1
kind: Service
metadata:
  name: web-app-service
  namespace: production
  labels:
    app: web-app
spec:
  type: ClusterIP
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: web-app
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: enterprise-web-app
  minReplicas: 3
  maxReplicas: 50
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 0
      policies:
      - type: Percent
        value: 100
        periodSeconds: 15
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 10
        periodSeconds: 60

6. Bedah Kode & Penjelasan Detail Baris Kunci

1. backend "s3" pada Terraform: Baris ini memastikan bahwa file state Terraform disimpan secara aman di S3 AWS, bukan di mesin lokal developer. Penggunaan dynamodb_table mencegah race condition (konflik state saat dua engineer menjalankan terraform apply secara bersamaan).
2. enable_irsa = true (IAM Roles for Service Accounts): Fitur krusial pada modul EKS ini mengizinkan pod Kubernetes untuk mengasumsikan peran IAM AWS secara spesifik tanpa perlu menanamkan kunci AWS (AWS_ACCESS_KEY_ID) di dalam environment container, meningkatkan keamanan secara masif.
3. resources.requests dan resources.limits pada K8s Pod: requests menentukan jaminan minimal sumber daya yang dialokasikan oleh Kubernetes Scheduler untuk menempatkan pod ke Node yang sesuai. limits adalah batas maksimal yang diizinkan agar satu pod tidak memonopoli seluruh sumber daya node dan menyebabkan kernel melakukan OOM Kill.
4. behavior.scaleUp pada HPA v2: Pengaturan kustom ini memaksa klaster untuk langsung melipatgandakan jumlah pod hingga 100% setiap 15 detik saat ambang batas CPU terlampaui, memitigasi risiko latensi tinggi akibat lonjakan traffic yang agresif.

7. Skenario Produksi & Studi Kasus Dunia Nyata

Dalam studi kasus implementasi e-commerce skala besar dengan transaksi 50.000 request per detik (RPS), arsitektur ini diuji melalui simulasi chaos engineering.

Ketika salah satu ketersediaan Availability Zone (AZ us-east-1a) mengalami pemadaman total, Cloudflare Load Balancer otomatis mendeteksi kegagalan health check dan mengalihkan seluruh traffic masuk ke AZ cadangan (us-east-1b dan us-east-1c). Di dalam klaster Kubernetes, Horizontal Pod Autoscaler membaca lonjakan antrean dan menambah jumlah pod aplikasi dari 20 menjadi 150 pod dalam waktu kurang dari 45 detik. Cluster Autoscaler mendeteksi kekurangan kapasitas node fisik dan secara otomatis mem-provisioning instance EC2 tambahan melalui integrasi Terraform/AWS Auto Scaling Group, memastikan transaksi pelanggan tetap berjalan mulus tanpa satu pun data yang korup.

8. Common Pitfalls, Anti-Patterns & Solusi

• Anti-Pattern 1: Menyimpan Secret di dalam Terraform State Plaintext. Solusi: Selalu enkripsi state S3 dengan KMS, gunakan AWS Secrets Manager atau HashiCorp Vault untuk injeksi rahasia runtime ke dalam Kubernetes Secrets.
• Anti-Pattern 2: Menentukan limits CPU yang Terlalu Ketat pada Node. Solusi: Untuk aplikasi web backend berbasis Go atau Node.js yang melakukan komputasi berat sesaat, pembatasan CPU limit yang terlalu ketat memicu CPU throttling. Lebih baik atur request yang akurat dan biarkan limit sedikit lebih longgar atau dihilangkan jika menggunakan QoS Burstable.
• Anti-Pattern 3: Menggunakan latest Tag pada Docker Image di Produksi. Solusi: Selalu gunakan immutable semantic versioning tags (misal: v1.2.0) untuk memastikan rollbacks dapat dilakukan dengan presisi tinggi.

9. Benchmark, Metrik Kinerja & Tuning Performa

Pengujian performa dilakukan menggunakan tool k6 untuk mensimulasikan beban beban tinggi terhadap endpoint API web.

// load-test.js
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 1000 }, // Ramp-up ke 1000 users
    { duration: '5m', target: 5000 }, // Tahan di 5000 users
    { duration: '2m', target: 0 },    // Ramp-down
  ],
  thresholds: {
    http_req_duration: ['p(99)<250'], // 99% request harus di bawah 250ms
    http_req_failed: ['rate<0.01'],  // Error rate di bawah 1%
  },
};

export default function () {
  const res = http.get('https://api.enterprise-production.com/v1/products');
  check(res, {
    'status is 200': (r) => r.status === 200,
    'response time < 200ms': (r) => r.timings.duration < 200,
  });
  sleep(1);
}

Hasil Tuning Lanjutan:

• Mengoptimalkan parameter sysctl pada node Linux (misal: net.core.somaxconn = 65535) untuk menampung antrean TCP connection yang masif pada Nginx Ingress Controller.
• Mengaktifkan Keep-Alive Connections pada Nginx dan PHP-FPM untuk mereduksi overhead pembukaan socket TCP baru secara berulang.

10. Checklist Penerapan Produksi & Kesimpulan

Gunakan checklist berikut sebelum merilis arsitektur ke lingkungan produksi penuh:

• State Terraform diamankan dengan enkripsi KMS dan terkunci via DynamoDB.
• Konfigurasi IRSA aktif dan tidak ada kredensial hardcoded pada manifes Kubernetes.
• Liveness dan Readiness Probe dikonfigurasi dengan benar untuk mencegah traffic masuk ke pod yang belum siap.
• HPA (Horizontal Pod Autoscaler) telah diuji dengan simulasi load test minimal 2x dari peak traffic harian.
• Kebijakan Network Policies diterapkan untuk membatasi komunikasi antar-namespace di dalam klaster.
• Sistem monitoring (Prometheus & Grafana) dan log aggregation (FluentBit/Elasticsearch) aktif memantau metrik secara real-time.

Dengan memadukan prinsip Declarative Infrastructure dari Terraform dan elastisitas orkestrasi Kubernetes, organisasi Anda kini memiliki fondasi web enterprise yang tangguh, otomatis, dan siap menghadapi skala global tanpa kompromi pada keamanan dan performa.