Membangun Arsitektur Resilient SSR pada Next.js di Atas Cluster Kubernetes

Pukul 2 pagi, pagerDuty berdering nyaring di ponsel saya. Dashboard Grafana menyala merah menyala terang bak lampu darurat pesawat terbang. Latency aplikasi e-commerce yang kami tangani melonjak drastis hingga 4.2 detik, dan CPU pada cluster Kubernetes di AWS EKS menyentuh batas 98%. Tim frontend saling bersahutan di Discord, menyalahkan konfigurasi infrastruktur, sementara tim SRE berargumen bahwa kode Server-Side Rendering (SSR) dari Next.js terlalu boros memori dan menyiksa V8 Engine. Kejadian malam itu memaksa kami melakukan evaluasi total: apakah masalahnya ada di cara Next.js merender halaman, atau bagaimana kami mendesain strategi caching dan autoscaling di atas Kubernetes?

Mari kita bedah langsung dalam sebuah pertempuran arsitektural antara dua pendekatan ekstrem dalam mengelola beban render Next.js: Kubernetes Native Pod Scaling yang mengandalkan brute-force container, melawan Edge Cache & ISR (Incremental Static Regeneration) yang memindahkan beban komputasi jauh ke tepi jaringan menggunakan Cloudflare dan caching pintar.

[!WARNING] Mengandalkan pure SSR tanpa edge caching di aplikasi Next.js berskala besar adalah resep pasti untuk mengalami Cascading Failures saat flash sale.

Transisi dari kepanikan malam itu menuntun kami pada perdebatan sengit tentang bagaimana seharusnya sebuah aplikasi web modern diperlakukan di atas infrastruktur kontainer.

1. Pertarungan Filosofi: Dua Cara Pandang Berbeda dalam Memecahkan Masalah

Kubernetes menjanjikan orkestrasi kontainer yang otomatis, namun ia tidak tahu apa itu React, getServerSideProps, atau V8 Garbage Collection. Di satu sisi, kubu Pure SSR Pod Scaling berargumen bahwa setiap request haruslah dinamis, segar, dan dirender saat itu juga untuk menjamin konsistensi data pengguna. Mereka memperlakukan cluster K8s layaknya sekumpulan server tradisional yang siap di-spam dengan penambahan pod baru begitu CPU naik.

Di sisi lain, kubu Edge Caching & ISR memandang bahwa 80% konten web sebenarnya bersifat statis atau semi-dinamis. Mengapa harus membebani Node.js untuk merender ulang profil pengguna atau katalog produk yang sama ribuan kali dalam sedetik? Lebih baik manfaatkan CDN dan mekanisme Incremental Static Regeneration.

Perdebatan ini bukan sekadar teori akademis. Saat deadline peluncuran fitur baru menekan, pilihan filosofi ini menentukan apakah Anda akan tidur nyenyak atau terbangun karena Memory Leak.

2. Ronde 1: Ergonomi Menulis Kode & Pengalaman Konfigurasi Sehari-hari

Mari kita lihat bagaimana kedua pendekatan ini menyentuh keseharian seorang engineer. Ketika menggunakan pendekatan Kubernetes Native SSR, Anda harus berkutat dengan Dockerfile yang optimal untuk Node.js, memastikan standalone output Next.js aktif, dan menulis manifest Kubernetes yang panjang.

Berikut adalah contoh deployment manifest Kubernetes yang kami gunakan untuk pod Next.js dengan pengaturan resource yang ketat agar terhindar dari Out of Memory (OOM) Killer:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nextjs-ssr-app
  namespace: production
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nextjs-ssr
  template:
    metadata:
      labels:
        app: nextjs-ssr
    spec:
      containers:
      - name: web
        image: 123456789012.dkr.ecr.us-east-1.amazonaws.com/nextjs-app:v1.2.0
        resources:
          limits:
            cpu: "2"
            memory: 2Gi
          requests:
            cpu: "500m"
            memory: 512Mi
        ports:
        - containerPort: 3000
        env:
        - name: NODE_ENV
          value: "production"
        - name: PORT
          value: "3000"
        readinessProbe:
          httpGet:
            path: /api/health
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 10
        livenessProbe:
          httpGet:
            path: /api/health
            port: 3000
          initialDelaySeconds: 15
          periodSeconds: 20

Di sisi lain, pendekatan Edge Caching & ISR menuntut kedisiplinan dalam mengatur Cache-Control headers di dalam kode Next.js Anda atau memanfaatkan Cloudflare Worker. Anda tidak lagi hanya memikirkan container scaling, tetapi juga bagaimana cache invalidation bekerja.

[!TIP] Selalu gunakan opsi output: 'standalone' di next.js.config.js Anda agar ukuran image Docker bisa dipangkas secara drastis dari 1.2GB menjadi kurang dari 150MB.

3. Ronde 2: Ketahanan di Bawah Gempuran Beban Ekstrem

Kami melakukan pengujian beban menggunakan k6 untuk mensimulasikan 10.000 virtual users yang mengakses halaman produk secara bersamaan. Pertandingan di arena pengujian ini sangat brutal.

Ketika menggunakan Pure SSR di atas pod Kubernetes tanpa edge caching, grafik latensi meroket tajam. V8 Engine mengalami event loop blockage karena proses serialisasi React SSR yang memakan banyak CPU. Meskipun Horizontal Pod Autoscaler (HPA) bereaksi, waktu yang dibutuhkan Kubernetes untuk menjadwalkan (scheduling) pod baru memakan waktu 30 hingga 45 detik—waktu yang terlalu lama saat traffic surge sedang ganas-ganasnya.

Sebaliknya, ketika kami menerapkan strategi Edge Caching & ISR, traffic sebagian besar diserap oleh Cloudflare CDN. Pod Kubernetes kami hanya menerima 5% dari total request asli (yaitu request saat revalidation terjadi di background). Hasilnya? Latency P99 turun dari 3.800ms menjadi 45ms.

Berikut adalah contoh konfigurasi Custom Metric untuk HPA berbasis Prometheus (PrometheusAdapter) yang memonitor HTTP request latency dan request per second dan bukan sekadar CPU:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata: 
  name: nextjs-hpa
  namespace: production
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nextjs-ssr-app
  minReplicas: 3
  maxReplicas: 25
  metrics:
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "150"
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

4. Ronde 3: Konsumsi Sumber Daya Server & Efisiensi Biaya Nyata

Uang berbicara paling keras di akhir bulan. Infrastruktur Kubernetes tidak gratis; setiap node EC2 di AWS atau worker node di GCP dibayar per jam. Pendekatan Pure SSR memaksa Anda mempertahankan ukuran cluster yang besar secara permanen untuk menghadapi traffic spike mendadak, atau mengambil risiko aplikasi down.

Dengan memadukan Next.js ISR, S3 untuk penyimpanan asset statis, Redis untuk distributed caching, dan Cloudflare Edge, konsumsi RAM dan CPU di cluster Kubernetes kami terpangkas hingga 70%. Kami bahkan bisa menurunkan ukuran instance node dari t3.xlarge ke t3.medium, menghemat ribuan dolar biaya cloud tahunan.

[!IMPORTANT] Perhatikan batas memori kontainer Node.js (--max-old-space-size). Jika Anda tidak mengaturnya secara manual di Kubernetes, Node.js akan mencoba memakan seluruh alokasi RAM pod sebelum akhirnya di-terminate oleh kernel Linux.

5. Kapan Wajib Menggunakan Kubernetes Native SSR

Anda wajib memilih pendekatan Kubernetes Native dengan SSR murni jika aplikasi Anda adalah:

1. Dashboard internal enterprise yang memerlukan data real-time mutlak pada setiap klik dan tidak diindeks oleh mesin pencari.
2. Aplikasi dengan tingkat personalisasi yang sangat tinggi (hyper-personalized) di mana setiap pengguna melihat struktur halaman yang 100% berbeda dan tidak dapat di-cache.
3. Sistem finansial atau perbankan yang melarang keras penyimpanan data rendering di edge server pihak ketiga karena regulasi kepatuhan privasi data yang ketat.

6. Kapan Wajib Menggunakan Edge Caching & ISR

Sebaliknya, Anda wajib memeluk erat strategi Edge Caching & ISR jika bisnis Anda bergerak di bidang:

1. E-commerce berskala besar (seperti Tokopedia, Shopee, atau toko online menengah) dengan jutaan halaman produk katalog.
2. Portal berita, blog, atau media massa yang membutuhkan SEO prima, First Contentful Paint (FCP) yang instan, dan ketahanan terhadap lonjakan pembaca berita viral.
3. Website korporat atau landing page pemasaran yang trafiknya bisa meledak sewaktu-waktu akibat kampanye iklan televisi atau sosial media.

7. Keputusan Akhir: Rekomendasi Jujur untuk Tim Engineering

Setelah jatuh bangun menghadapi berbagai insiden dini hari, kesimpulan kami sangat jelas: Jangan mempertarungkan keduanya secara eksklusif, melainkan kombinasikan.

Gunakan arsitektur hibrida. Manfaatkan Kubernetes untuk mengelola layanan backend, API, dan proses Incremental Static Regeneration (ISR) di background, namun serahkan pengiriman halaman ke pengguna akhir melalui Edge Caching dan CDN global. Dengan cara ini, Anda mendapatkan fleksibilitas kontainer Kubernetes tanpa harus mengorbankan performa kecepatan render Next.js.

Arsitektur yang tangguh bukanlah arsitektur yang paling rumit, melainkan arsitektur yang bisa membuat Anda tidur nyenyak di malam hari meskipun jutaan request menghantam sistem secara bersamaan.