Membangun Arsitektur Resilien dengan Next.js SSR di Atas Kluster Kubernetes

Dalam 15 menit ke depan, kita akan merakit sebuah stack production-grade dari nol sampai berjalan mulus. Lupakan sejenak teori-teori abstrak di luar sana; kemarin malam saya baru saja bergadang karena pod Next.js di cluster production tiba-tiba OOM (Out of Memory) tepat saat kampanye flash sale dimulai. Jadi, hari ini kita akan langsung masuk ke dapur kerja nyata untuk membangun arsitektur yang tahan banting, mengatur manajemen memory leak pada Node.js runtime SSR, merangkai edge caching di balik Cloudflare, hingga melatih Horizontal Pod Autoscaler (HPA) agar bernapas lega merespons lonjakan request rate.

1. Menu Kita Hari Ini & Alat yang Perlu Disiapkan

Pernahkah Anda mendapati aplikasi web berbasis Server-Side Rendering (SSR) berjalan sangat gesit di local machine, namun mendadak megap-megap begitu dilempar ke Kubernetes dengan beban ribuan pengguna bersamaan? Masalahnya jarang terletak pada kodenya saja, melainkan bagaimana kita meracik siklus hidup proses Node.js di dalam container yang terbatas resource-nya.

Sebelum mulai meracik, pastikan di atas meja kerja kita sudah tersedia:

• Kluster Kubernetes (v1.28+) dengan Metrics Server terpasang.
• Docker CLI dan akses kubectl yang sudah terhubung ke kluster.
• CLI Wrangler atau akses dashboard Cloudflare untuk pengaturan Edge Caching.
• Aplikasi Next.js dengan custom server.js atau memanfaatkan build standalone bawaan Next.js.

[!IMPORTANT] Jangan pernah menjalankan Next.js production menggunakan npm start di dalam container. Kita wajib menggunakan mode output: 'standalone' agar footprint memori lebih ramping dan dependensi node_modules terisolasi dengan presisi.

Mari kita mulai perjalanan merakit fondasi ini agar tidak ada lagi cerita server tumbang di tengah malam.

2. Peta Jalan Singkat: Apa yang Sedang Kita Rakit

Agar kita memiliki bayangan utuh sebelum mengetikkan baris perintah pertama, peta jalan kita hari ini terbagi menjadi tiga lapis pertahanan utama:

1. Lapis Pertama (Runtime & Memory): Menjinakkan karakteristik V8 engine pada Node.js agar tidak mengalami memory leak saat melakukan render halaman yang kompleks secara terus-menerus.
2. Lapis Kedua (Edge & CDN): Meredam hantaman traffic langsung ke origin server dengan mendistribusikan cache di Cloudflare Edge Workers dan Cache Rules.
3. Lapis Ketiga (Autoscaling): Mengonfigurasi Kubernetes HPA bukan sekadar membaca penggunaan CPU, melainkan memantau kustom metrik request rate per detik agar pod baru lahir sebelum pod lama kehabisan napas.

Dengan alur yang terstruktur rapi ini, mari kita langsung eksekusi langkah pertama di terminal kita.

3. Langkah 1: Mempersiapkan Fondasi & Environment

Langkah awal yang paling krusial adalah memastikan Dockerfile kita memperlakukan runtime Node.js dengan penuh hormat. Node.js secara default tidak tahu batasan memori container Kubernetes kecuali kita memberitahunya secara eksplisit.

Buka editor teks Anda, buat file Dockerfile di root direktori project Next.js Anda, dan masukkan racikan berikut:

# Tahap 1: Build dependency dan aplikasi Next.js
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Tahap 2: Runtime production yang ramping dan aman
FROM node:20-alpine AS runner
WORKDIR /app

ENV NODE_ENV=production
# Batasi V8 heap maksimum secara eksplisit agar tidak menabrak limit cgroups Kubernetes
ENV NODE_OPTIONS="--max-old-space-size=1536"

RUN addgroup --system --gid 1001 nodejs
RUN adduser --system --uid 1001 nextjs

COPY --from=builder /app/public ./public
COPY --from=builder --chown=nextjs:nodejs /app/.next/standalone ./
COPY --from=builder --chown=nextjs:nodejs /app/.next/static ./.next/static

USER nextjs

EXPOSE 3000
ENV PORT=3000
ENV HOSTNAME="0.0.0.0"

CMD ["node