Serverless API Gateway: Mengelola Jutaan Request dengan AWS Lambda & API Gateway

1. Titik Awaters Masalah: Mengapa Arsitektur Lama Sering Ambruk di Produksi

Pukul tiga pagi, pagerDuty menyalak kencang. CPU utilization di cluster Nginx dan server PHP-FPM di balik load balancer melompat ke angka 99%. Bukan karena ada fitur baru yang canggih, melainkan karena kampanye flash sale mendadak yang dibagikan seorang influencer ternama. Ratusan ribu request HTTP menghantam endpoint /api/v1/checkout secara bersamaan. Koneksi database MySQL langsung exhausted, antrean pool Redis menumpuk, dan server web tradisional bertekuk lutut akibat kehabisan memori.

Sebagai arsitek infrastruktur, skenario ini adalah mimpi buruk klasik. Konfigurasi worker_connections di Nginx habis, proses PHP-FPM macet menunggu query database yang lambat, dan sistem gagal total. Kita sering lupa bahwa memelihara server konvensional ibarat menyalakan mesin diesel 24 jam penuh di garasi, meskipun tidak ada mobil yang lewat. Biaya operasional bengkak, dan saat lonjakan tiba, mesin tetap saja macet karena kapasitasnya terbatas.

Di sinilah kita mulai melirik pendekatan serverless menggunakan kombinasi AWS API Gateway dan AWS Lambda. Bayangkan sebuah pos pemeriksaan otomatis yang bisa melipatgandakan petugasnya secara instan dari satu orang menjadi sepuluh ribu orang dalam milidetik, lalu langsung pulang tanpa bayaran saat tidak ada orang lewat. Namun, memindahkan beban kerja ke awan tanpa desain yang matang justru akan mendatangkan masalah baru yang tidak kalah pelik. Mari kita bedah bagaimana arsitektur ini bekerja tanpa sihir.

2. Di Balik Layar: Bagaimana Sistem Ini Bekerja Tanpa Sihir

Banyak orang menganggap serverless adalah sihir hitam: Anda menulis kode, melemparnya ke awan, dan semuanya berjalan ajaib. Di balik layar, AWS API Gateway bertindak sebagai penjaga gerbang terdepan yang menghentikan serangan DDOS dasar, melakukan validasi payload, dan memetakan rute HTTP ke fungsi komputasi yang tepat.

Ketika sebuah request masuk dari browser atau aplikasi mobile melalui Cloudflare CDN, API Gateway menerima payload tersebut. Jika kita menggunakan HTTP APIs (API Gateway v2), request langsung dilempar ke AWS Lambda dengan latensi minimal. Lambda kemudian melakukan cold start—jika belum ada kontainer yang siap—menjalankan runtime Node.js atau Go, memproses logika bisnis, berinteraksi dengan database terkelola seperti Aurora Serverless atau DynamoDB, dan mengembalikan respons.

[!IMPORTANT] Jangan samakan API Gateway REST API (v1) dengan HTTP API (v2). Untuk performa tinggi dan efisiensi biaya, HTTP API menawarkan latensi hingga 60% lebih rendah dan harga sepertiga dari REST API.

Namun, sistem tanpa server bukan berarti tanpa batas. Tantangan terbesarnya adalah bagaimana kita mendesain routing yang cerdas dan mengelola rate limiting agar infrastruktur tidak kebanjiran, yang akan kita bahas dalam transisi berikut.

3. Pilihan Pendekatan & Kompromi yang Harus Diambil

Memilih arsitektur serverless menuntut kompromi. Ada dua pendekatan utama saat menghubungkan API Gateway ke Lambda: Proxy Integration dan Non-Proxy Integration (Custom Integration).

Dalam Proxy Integration, seluruh event HTTP (headers, query string, body) dilempar mentah-mentah ke Lambda. Ini sangat cepat dalam hal pengembangan karena Anda memiliki kontrol penuh di dalam kode backend (misalnya menggunakan Express.js di dalam Lambda). Sebaliknya, Non-Proxy Integration memungkinkan API Gateway memetakan parameter sebelum masuk ke Lambda menggunakan Apache Velocity Template Language (VTL). Walaupun ini memindahkan validasi ke level API Gateway dan menghemat eksekusi Lambda, VTL terkenal menyebalkan untuk ditulis dan di-debug.

Berikut perbandingan ringkas performa dan kompleksitasnya:

Memilih Proxy Integration dengan validasi menggunakan skema Zod atau Joi di dalam kode Lambda jauh lebih disukai oleh tim modern demi kecepatan iterasi. Mari kita siapkan lingkungan kerja untuk menguji teori ini.

4. Meracik Lingkungan: Persiapan & Prasyarat Lapangan

Sebelum kita menulis kode, pastikan kita menggunakan Infrastructure as Code (IaC) agar arsitektur dapat direplikasi dengan presisi. Kita akan menggunakan Serverless Framework atau AWS CDK. Di sini, kita pilih AWS CDK dengan TypeScript karena memberikan kekuatan type-checking dan integrasi IDE yang luar biasa.

Pastikan Anda telah menginstal AWS CLI, Node.js versi LTS, dan melakukan konfigurasi kredensial:

# Verifikasi instalasi AWS CLI dan CDK
aws --version
cdk --version

# Inisialisasi direktori project CDK baru
mkdir serverless-gateway-demo
cd serverless-gateway-demo
cdk init app --language typescript

Struktur direktori project kita harus bersih, memisahkan definisi infrastruktur CDK dari kode sumber Lambda itu sendiri. Dengan pondasi ini, mari kita bangun solusi yang tangguh.

5. Langkah Implementasi: Membangun Solusi yang Tangguh

Kita akan menulis kode CDK untuk mendefinisikan HTTP API, mengatur rute, mengaktifkan Throttling (Rate Limiting), dan menghubungkannya ke fungsi Lambda berbasis Node.js yang menangani backend API kita.

Buka file stack utama Anda (lib/serverless-gateway-demo-stack.ts) dan tulis konfigurasi berikut:

import * as cdk from 'aws-cdk-lib';
import { Construct } from 'constructs';
import * as lambda from 'aws-cdk-lib/aws-lambda';
import * as apigwv2 from 'aws-cdk-lib/aws-apigatewayv2';
import * as integrations from 'aws-cdk-lib/aws-apigatewayv2-integrations';

export class ServerlessGatewayDemoStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    // 1. Definisikan Fungsi Lambda Backend
    const apiLambda = new lambda.Function(this, 'ApiHandler', {
      runtime: lambda.Runtime.NODEJS_18_X,
      handler: 'index.handler',
      code: lambda.Code.fromAsset('lambda'),
      memorySize: 1024, // Alokasi memori yang cukup untuk performa CPU optimal
      timeout: cdk.Duration.seconds(10),
    });

    // 2. Buat HTTP API Gateway
    const httpApi = new apigwv2.CfnApi(this, 'HttpApi', {
      protocolType: 'HTTP',
      name: 'Production-Serverless-Gateway',
    });

    // 3. Integrasikan Lambda dengan API Gateway
    const integration = new integrations.HttpLambdaIntegration('LambdaIntegration', apiLambda);
    
    const httpApiIntegration = new apigwv2.CfnIntegration(this, 'ApiIntegration', {
      apiId: httpApi.ref,
      integrationType: 'AWS_PROXY',
      integrationUri: apiLambda.functionArn,
      payloadFormatVersion: '2.0',
    });

    // 4. Rute untuk Endpoint /api/v1/users
    new apigwv2.CfnRoute(this, 'ApiRoute', {
      apiId: httpApi.ref,
      routeKey: 'POST /api/v1/users',
      target: `integrations/${httpApiIntegration.ref}`,
    });

    // 5. Stage dengan Rate Limiting & Throttling
    new apigwv2.CfnStage(this, 'DefaultStage', {
      apiId: httpApi.ref,
      stageName: '$default',
      autoDeploy: true,
      defaultRouteSettings: {
        throttlingBurstLimit: 5000, // Batas lonjakan maksimum
        throttlingRateLimit: 10000, // Request per detik yang diizinkan
      },
    });
  }
}

[!TIP] Alokasi memori Lambda di AWS tidak hanya memengaruhi RAM, tetapi juga jatah vCPU secara linear. Memilih memori 1024MB seringkali memberikan eksekusi tercepat dan paling efisien biaya dibandingkan 128MB.

6. Membedah Baris Kode Krusial yang Kerap Menjebak

Menulis kode infrastruktur saja belum cukup. Di dalam kode handler Lambda (lambda/index.js), ada jebakan fatal yang sering menjebak para engineer pemula: menginisialisasi koneksi database di dalam handler function.

// JEBAKAN FATAL: Koneksi database dibuat di dalam handler
exports.handler = async (event) => {
  const db = await createDatabaseConnection(); // Gawat! Terbuat di setiap request
  const data = await db.query('SELECT * FROM users');
  return { statusCode: 200, body: JSON.stringify(data) };
};

[!WARNING] Jika Anda membuat koneksi database di dalam handler, setiap request baru akan membuka koneksi TCP baru ke MySQL atau PostgreSQL Anda. Akibatnya, database langsung max connections reached dalam hitungan detik saat trafik melonjak!

Cara yang benar adalah melakukan connection pooling di luar handler (global scope), sehingga koneksi tersebut dapat digunakan kembali (warm reuse) oleh eksekusi Lambda berikutnya:

// PRAKTIK BENAR: Inisialisasi di luar handler untuk connection reuse
const { Client } = require('pg');
const client = new Client({ /* config database */ });

let isConnected = false;

async function connectDb() {
  if (!isConnected) {
    await client.connect();
    isConnected = true;
  }
}

exports.handler = async (event) => {
  await connectDb(); // Menggunakan kembali koneksi yang ada jika Lambda 'warm'
  
  const body = JSON.parse(event.body);
  // Proses logika bisnis...
  
  return {
    statusCode: 200,
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ message: 'Success', data: body }),
  };
};

7. Bertahan di Bawah Tekanan: Skenario Traffic Nyata

Ketika lonjakan ribuan request per detik menghantam API Gateway, sistem keamanan dan pembatas beban kita diuji. API Gateway menangani layer rate limiting berdasarkan konfigurasi throttlingRateLimit yang kita buat di CDK tadi. Jika klien melampaui batas, API Gateway secara otomatis mengembalikan status HTTP 429 Too Many Requests tanpa menyentuh fungsi Lambda sama sekali.

Ini adalah penyelamat anggaran. Anda tidak perlu membayar biaya eksekusi Lambda untuk request spam atau bot jahat yang mencoba merusak sistem. Namun, bagaimana jika masalah justru datang dari dalam kode atau konfigurasi IAM yang terlalu longgar?

8. Jebakan Klasik & Cara Menghindarinya Sebelum Meledak

Selain masalah connection pooling, ada tiga jebakan klasik yang kerap membuat sistem serverless tumbang di produksi:

1. IAM Over-Privileging: Memberikan policy AdministratorAccess atau lambda:* pada execution role fungsi Lambda. Selalu terapkan prinsip least privilege. Berikan izin spesifik hanya ke tabel DynamoDB atau secret tertentu di AWS Secrets Manager.
2. Payload Size Limit: API Gateway memiliki batas keras payload sebesar 10MB untuk HTTP API. Jika Anda mengunggah file gambar besar langsung melalui API Gateway, sistem akan gagal. Gunakan pola Presigned URL S3 di mana API Gateway hanya memberikan izin token bagi klien untuk mengunggah langsung ke bucket S3.
3. Timeout Mismatch: API Gateway HTTP API memiliki batas integrasi maksimum 30 detik. Jika fungsi Lambda Anda butuh waktu 35 detik untuk memproses laporan berat, API Gateway akan mengembalikan 504 Gateway Timeout. Pindahkan tugas berat tersebut ke asynchronous worker menggunakan AWS SQS.

9. Uji Nyali: Mengukur Performa di Titik Batas

Sebelum merilis sistem ke publik, kita harus melakukan stress testing menggunakan tools seperti k6 atau Artillery. Jangan pernah berasumsi sistem aman sebelum diuji di bawah tekanan ekstrem.

Buat file skrip uji load-test.js menggunakan k6:

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '30s', target: 500 },  // Naikkan ke 500 user dalam 30 detik
    { duration: '1m', target: 2000 },  // Tahan di 2000 user per detik
    { duration: '30s', target: 0 },    // Turunkan perlahan
  ],
};

export default function () {
  const url = 'https://your-api-gateway-id.execute-api.us-east-1.amazonaws.com/api/v1/users';
  const payload = JSON.stringify({ name: 'LoadTest User', email: 'test@example.com' });
  const params = { headers: { 'Content-Type': 'application/json' } };

  const res = http.post(url, payload, params);
  
  check(res, {
    'status is 200': (r) => r.status === 200,
    'latency under 200ms': (r) => r.timings.duration < 200,
  });
  
  sleep(0.1);
}

Jalankan pengujian melalui terminal:

k6 run load-test.js

Perhatikan metrik p95 latency dan error rate pada laporan k6. Jika error rate melebihi 1%, saatnya mengevaluasi kembali kapasitas database atau menambah provisioned concurrency Lambda.

10. Catatan Lapangan & Checklist Sebelum Rilis

Sebagai penutup, mari kita tinjau kembali daftar periksa (checklist) operasional sebelum Anda menekan tombol deploy terakhir ke lingkungan produksi:

• Apakah API Gateway menggunakan protokol HTTP APIs (v2) untuk efisiensi biaya dan latensi terendah?
• Apakah seluruh koneksi database diinisialisasi di luar handler Lambda (Global Scope) untuk connection reuse?
• Apakah Rate Limiting dan Throttling telah dikonfigurasi pada level Stage API Gateway?
• Apakah Lambda Execution Role telah menerapkan prinsip Least Privilege?
• Apakah Anda telah menguji unggahan file besar menggunakan S3 Presigned URL alih-alih melalui payload API Gateway?
• Apakah CloudWatch Logs dan X-Ray Tracing sudah diaktifkan untuk memudahkan troubleshooting insiden pukul 3 pagi?

Dengan arsitektur yang teruji, Anda tidak perlu lagi khawatir pagerDuty berbunyi saat lonjakan trafik datang. Selamat merancang infrastruktur masa depan!