API Gateway คืออะไร มีอะไรบ้าง ต่างจาก Load Balancer ยังไง

ลองนึกภาพแอปสั่งอาหารที่เริ่มต้นจาก backend ตัวเดียว ทุกอย่างอยู่ในเซิร์ฟเวอร์เดียว หน้าแอปเรียก URL เดียวจบ พอแอปโตขึ้น ทีมก็แยกระบบออกเป็นห้า service: ข้อมูลผู้ใช้ ร้านอาหาร คำสั่งซื้อ การชำระเงิน และการติดตามไรเดอร์ วันหนึ่งคนเขียนหน้าแอปเปิดไฟล์ config แล้วเจอ URL ห้าชุด แต่ละ service ตรวจ login เองคนละแบบ บางตัวกันการยิงถี่ บางตัวไม่กัน และทุกครั้งที่ทีม backend ย้ายหรือแยก service ใหม่ หน้าแอปต้องแก้ตามทุกครั้ง

คำถามที่ตามมาคือ จะมีจุดเดียวไหมที่ให้หน้าแอปคุยด้วย แล้วจุดนั้นค่อยส่งต่อให้ service ที่ถูกตัว สั้นๆ: API Gateway คือประตูทางเข้าเดียวที่ตั้งอยู่หน้า backend หลาย service รับทุก request จาก client ตรวจสิทธิ์ จำกัดจำนวนครั้ง แล้วส่งต่อไปยัง service ที่ถูกต้อง วันนี้ Superdev Academy จะพาไปดูว่ามันทำงานอย่างไร มีหน้าที่อะไรบ้าง ต่างจาก Load Balancer และ Reverse Proxy ตรงไหน และจะลองเขียน gateway ตัวเล็กๆ ด้วย Node.js ให้เห็นกับตาว่ามันตอบ 429 เมื่อถูกยิงถี่เกินไปจริง

ถ้ายังไม่คุ้นกับคำว่า API หรือ Endpoint แนะนำให้อ่าน API คืออะไร ก่อน แล้วค่อยกลับมาต่อ บทความนี้จะง่ายขึ้นมาก

API Gateway คืออะไร

API Gateway คือเซิร์ฟเวอร์ตัวกลางที่ client ทุกตัว (แอปมือถือ เว็บ หรือระบบของพาร์ตเนอร์) ส่ง request มาหาที่เดียว แล้วตัว gateway เป็นคนตัดสินว่า request นั้นควรไปหา service ไหนข้างหลัง

Microsoft อธิบายไว้ในเอกสาร Azure Architecture Center ว่า API Gateway เป็น จุดเข้าแบบรวมศูนย์ (centralized entry point) ที่ทำหน้าที่เป็น Reverse Proxy ส่ง request ไปยัง service ที่เหมาะสม และรับงานที่ทุก service ต้องทำซ้ำกัน เช่น authentication, SSL termination และ rate limiting ส่วน AWS เรียก Amazon API Gateway ว่าเป็น "front door" ของแอปพลิเคชันที่เข้าถึงข้อมูลและ business logic ใน backend

พูดง่ายๆ คือมันเหมือนเคาน์เตอร์ต้อนรับของตึก คนมาติดต่อไม่ต้องรู้ว่าแผนกไหนอยู่ชั้นไหน แค่บอกเคาน์เตอร์ว่ามาทำอะไร เคาน์เตอร์ตรวจบัตร แล้วชี้ทางให้ถูกห้อง

API Gateway ทำงานอย่างไร

ถ้าเอาแอปสั่งอาหารเมื่อกี้มาใส่ gateway ไว้ข้างหน้า เส้นทางของ request หนึ่งตัวจะเป็นแบบนี้

1. หน้าแอปส่ง GET /orders ไปที่ URL เดียว คือ URL ของ gateway
2. gateway ตรวจว่า request นี้มี token หรือ API Key ที่ถูกต้องไหม ถ้าไม่มีก็ตอบ 401 กลับไปเลย ไม่ต้องรบกวน service ข้างหลัง
3. gateway เช็กว่า client รายนี้ยิงมาเกินโควตาหรือยัง ถ้าเกินก็ตอบ 429
4. gateway ดู path แล้วจับคู่กับกฎ routing ว่า /orders ต้องไปที่ orders-service
5. service ตอบกลับมา gateway จดลง log แล้วส่งคำตอบคืนให้หน้าแอป

สิ่งที่เปลี่ยนไปคือหน้าแอปรู้จักแค่ URL เดียว ส่วนการย้าย แยก หรือรวม service ข้างหลังกลายเป็นเรื่องของการแก้กฎใน gateway ไม่ใช่การปล่อยแอปเวอร์ชันใหม่

API Gateway มีหน้าที่อะไรบ้าง

หน้าที่ด้านล่างนี้เป็นหน้าที่หลักที่เอกสารของ Microsoft และ AWS พูดถึงตรงกัน ไม่ใช่ทุก gateway จะเปิดใช้ทุกข้อ และแต่ละผลิตภัณฑ์รองรับแต่ละข้อไม่เท่ากัน

Routing: ส่ง request ไปให้ถูก service

หน้าที่พื้นฐานที่สุด gateway ดู path, header หรือ host แล้วส่งต่อตามกฎ เช่น /users ไป users-service และ /orders ไป orders-service เอกสาร Gateway Routing pattern ของ Microsoft ระบุว่าการ routing แบบนี้ทำงานที่ Layer 7 (ชั้นของ HTTP) จึงตัดสินจาก URL หรือ header ได้

Authentication: ตรวจตัวตนครั้งเดียวที่หน้าประตู

แทนที่ทุก service จะเขียนโค้ดตรวจ token เอง gateway ตรวจให้ที่จุดเดียว Amazon API Gateway รองรับการตรวจสิทธิ์ผ่าน IAM policy, Lambda authorizer และ Amazon Cognito user pools ส่วนเรื่องการเก็บ API Key ฝั่งเซิร์ฟเวอร์ให้ปลอดภัย เรามีอธิบายไว้แยกใน บทความเรื่องเก็บ API Key ด้วย .env

Rate Limiting: กันการยิงถี่ แล้วตอบ 429

Rate Limiting (การจำกัดจำนวนครั้งที่เรียกได้ในช่วงเวลาหนึ่ง) ช่วยไม่ให้ client รายเดียวกินทรัพยากรทั้งระบบ สถานะที่ใช้บอกว่าโดนจำกัดคือ 429 Too Many Requests ซึ่งนิยามไว้ใน RFC 6585 และ RFC ฉบับนี้บอกว่าคำตอบอาจแนบ header Retry-After เพื่อบอก client ว่าควรรออีกนานเท่าไร

แต่ละเจ้าใช้วิธีนับต่างกัน AWS ระบุว่า Amazon API Gateway ใช้อัลกอริทึม token bucket และเมื่อ request เกินทั้งอัตราปกติและค่า burst ที่ตั้งไว้ client อาจได้รับ 429 กลับไป ส่วน NGINX ใช้ โมดูล limit_req ที่ทำงานแบบ leaky bucket และจุดที่หลายคนพลาดคือค่าเริ่มต้นของ limit_req_status คือ 503 ไม่ใช่ 429 ถ้าอยากให้ตอบ 429 ต้องตั้งเอง

Fun Fact: ความหมายของสถานะ 4xx/5xx อื่นๆ ที่ gateway ชอบตอบ เช่น 401, 502, 503 อ่านต่อได้ใน HTTP Status Code คืออะไร

TLS Termination: ถอดรหัส HTTPS ที่หน้าประตู

TLS Termination (หรือ SSL termination) คือให้ gateway เป็นคนจัดการใบรับรองและถอดรหัส HTTPS จาก client แล้วค่อยคุยกับ service ข้างหลังในเครือข่ายภายใน ข้อดีคือจัดการใบรับรองที่จุดเดียว ไม่ต้องติดตั้งในทุก service ถ้าต้องการให้ภายในเข้ารหัสด้วย ก็ใช้ Mutual TLS ซึ่ง Microsoft ระบุว่าเป็นอีกงานที่ย้ายมาไว้ที่ gateway ได้

Request/Response Transformation: ปรับหน้าตาข้อมูลระหว่างทาง

gateway บางตัวแก้ header, เปลี่ยน path หรือแปลงรูปแบบข้อมูลก่อนส่งต่อได้ เช่น เติม header ระบุตัวผู้ใช้ให้ service ข้างหลัง หรือรวมคำตอบจากหลาย service เป็นคำตอบเดียว ซึ่ง Microsoft เรียกแบบหลังว่า Gateway Aggregation pattern ช่วยลดจำนวน request ที่แอปต้องยิง

Logging และ Monitoring: เห็นทุก request ในที่เดียว

เพราะทุก request ผ่าน gateway มันจึงเป็นจุดที่ดีที่สุดในการเก็บ log และวัดผล Amazon API Gateway ส่ง access log และ execution log ไปที่ CloudWatch ได้ และตั้ง alarm ได้ ทำให้เห็นภาพรวมว่า endpoint ไหนช้า ใครโดน 429 บ่อย

ตัวอย่าง API Gateway: เขียนเองด้วย Node.js

อ่านทฤษฎีมาพอแล้ว มาลองของจริงกัน ตัวอย่างนี้ใช้แค่โมดูล node:http ที่มากับ Node.js ไม่ต้องติดตั้งแพ็กเกจเพิ่ม เราทดสอบบน Node.js v26.7.0, curl 8.4.0, macOS 14.3.1 เมื่อวันที่ 1 ตุลาคม 2026

ไฟล์แรกคือ service จำลองสองตัว ตัวหนึ่งตอบข้อมูลผู้ใช้ อีกตัวตอบคำสั่งซื้อ

// services.js — two tiny backend services
const http = require('node:http');

function service(name, port, payload) {
  http.createServer((req, res) => {
    res.writeHead(200, { 'Content-Type': 'application/json' });
    res.end(JSON.stringify({ service: name, path: req.url, data: payload }));
  }).listen(port, () => console.log(`${name} on :${port}`));
}

service('users-service', 4001, [{ id: 1, name: 'Nok' }]);
service('orders-service', 4002, [{ id: 101, item: 'Pad Thai' }]);

ไฟล์ที่สองคือตัว gateway ทำสี่อย่าง: ตรวจ API Key, จำกัด 3 request ต่อ 10 วินาที, routing ตาม path และเขียน log

// gateway.js — one entry point in front of two services
const http = require('node:http');

const routes = {
  '/users': 'http://localhost:4001',
  '/orders': 'http://localhost:4002',
};

const LIMIT = 3;            // requests allowed...
const WINDOW_MS = 10_000;   // ...per 10 seconds, per client
const hits = new Map();     // client -> { count, start }

function rateLimited(client) {
  const now = Date.now();
  const entry = hits.get(client);
  if (!entry || now - entry.start >= WINDOW_MS) {
    hits.set(client, { count: 1, start: now });
    return false;
  }
  entry.count += 1;
  return entry.count > LIMIT;
}

http.createServer((req, res) => {
  // 1) authentication: one check, for every service behind the gateway
  const key = req.headers['x-api-key'];
  if (key !== 'demo-key') {
    res.writeHead(401, { 'Content-Type': 'application/json' });
    return res.end(JSON.stringify({ error: 'missing or wrong x-api-key' }));
  }

  // 2) rate limiting: per API key
  if (rateLimited(key)) {
    res.writeHead(429, { 'Content-Type': 'application/json', 'Retry-After': '10' });
    return res.end(JSON.stringify({ error: 'Too Many Requests' }));
  }

  // 3) routing: match the path prefix, forward to the right service
  const prefix = Object.keys(routes).find((p) => req.url.startsWith(p));
  if (!prefix) {
    res.writeHead(404, { 'Content-Type': 'application/json' });
    return res.end(JSON.stringify({ error: 'no route' }));
  }

  const upstream = new URL(req.url, routes[prefix]);
  const proxyReq = http.request(upstream, { method: req.method, headers: req.headers }, (up) => {
    // 4) logging: one line per request, in one place
    console.log(`${req.method} ${req.url} -> ${routes[prefix]} ${up.statusCode}`);
    res.writeHead(up.statusCode, up.headers);
    up.pipe(res);
  });
  proxyReq.on('error', () => {
    res.writeHead(502, { 'Content-Type': 'application/json' });
    res.end(JSON.stringify({ error: 'Bad Gateway' }));
  });
  req.pipe(proxyReq);
}).listen(8080, () => console.log('gateway on :8080'));

เปิดสอง terminal รัน node services.js กับ node gateway.js แล้วลองยิงด้วย curl ผลที่ได้จริงจากเครื่องเราเป็นแบบนี้

$ curl -s localhost:8080/users -H "x-api-key: demo-key"
{"service":"users-service","path":"/users","data":[{"id":1,"name":"Nok"}]}

$ curl -s localhost:8080/orders -H "x-api-key: demo-key"
{"service":"orders-service","path":"/orders","data":[{"id":101,"item":"Pad Thai"}]}

$ curl -s -w ' %{http_code}\n' localhost:8080/users
{"error":"missing or wrong x-api-key"} 401

URL เดียวคือ localhost:8080 แต่ /users กับ /orders ไปถึงคนละ service และ request ที่ไม่มี key โดนตีกลับที่ gateway โดยไม่ถึง service เลย ต่อไปรอให้ครบ 10 วินาทีแล้วยิงรัวห้าครั้ง

$ for i in 1 2 3 4 5; do curl -s -o /dev/null -w "call $i: %{http_code}\n" localhost:8080/orders -H "x-api-key: demo-key"; done
call 1: 200
call 2: 200
call 3: 200
call 4: 429
call 5: 429

$ curl -si localhost:8080/orders -H "x-api-key: demo-key" | grep -E "HTTP|Retry"
HTTP/1.1 429 Too Many Requests
Retry-After: 10

สามครั้งแรกผ่าน ครั้งที่สี่เป็นต้นไปได้ 429 พร้อม Retry-After: 10 ตามที่ RFC 6585 แนะนำ ส่วน log ฝั่ง gateway มีครบห้าบรรทัดของ request ที่ส่งต่อสำเร็จ (สองครั้งแรก บวกสามครั้งที่ผ่านในลูป) ส่วน request ที่โดน 401 หรือ 429 ไม่ถึง service เลยจึงไม่มีในบรรทัดเหล่านี้

gateway on :8080
GET /users -> http://localhost:4001 200
GET /orders -> http://localhost:4002 200
GET /orders -> http://localhost:4002 200
GET /orders -> http://localhost:4002 200
GET /orders -> http://localhost:4002 200

ต้องบอกตรงๆ ว่าโค้ดนี้มีไว้ให้เห็นกลไก ไม่ใช่ให้เอาขึ้น production ตัวนับ rate limit เก็บในหน่วยความจำของ process เดียว ถ้ารัน gateway สองเครื่อง แต่ละเครื่องจะนับแยกกัน ระบบจริงจึงมักเก็บตัวนับไว้ในที่กลางอย่าง Redis หรือใช้ gateway สำเร็จรูป ถ้าอยากเห็นการทำ rate limiting แบบละเอียดขึ้นในภาษา Go อ่านต่อได้ที่ Golang The Series EP.164: Rate Limiting AI Requests

API Gateway มีตัวไหนบ้าง

ในงานจริงแทบไม่มีใครเขียน gateway เองตั้งแต่ศูนย์ ตัวที่เจอบ่อยมีทั้งแบบติดตั้งเองและแบบบริการบนคลาวด์

Kong API Gateway คืออะไร

Kong ระบุใน เอกสารของ Kong Gateway ว่าเป็น API gateway แบบ cloud-native ที่ตั้งอยู่หน้า RESTful API ใดก็ได้ และขยายความสามารถผ่านโมดูลและ plugin เช่น rate limiting หรือ authentication ติดตั้งได้ทั้งบนเครื่องของเราเองและใช้แบบ managed ผ่าน Konnect

AWS API Gateway คืออะไร

Amazon API Gateway คือบริการของ AWS สำหรับสร้าง เผยแพร่ ดูแล และป้องกัน API แบบ REST, HTTP และ WebSocket ใช้คู่กับ AWS Lambda บ่อยมาก จุดที่ควรรู้คือ REST API มี integration timeout ตั้งได้ตั้งแต่ 50 มิลลิวินาทีถึง 29 วินาที ถ้า service ข้างหลังตอบไม่ทัน gateway จะตอบกลับด้วยสถานะ 504 (ประเภท INTEGRATION_TIMEOUT ในเอกสาร AWS)

NGINX และ Reverse Proxy ทั่วไป

Microsoft จัด NGINX และ HAProxy ไว้ในกลุ่ม Reverse Proxy แบบ open source ที่เอามาทำหน้าที่ API Gateway ได้ เพราะรองรับ load balancing, SSL termination และ routing แบบ Layer 7 อยู่แล้ว ส่วนฝั่ง Azure มี Azure API Management และ Azure Application Gateway ให้เลือกตามงาน

API Gateway vs Load Balancer vs Reverse Proxy ต่างกันอย่างไร

สามคำนี้สับสนกันบ่อยที่สุด เพราะทั้งสามอย่างนั่งอยู่ระหว่าง client กับเซิร์ฟเวอร์เหมือนกัน วิธีแยกที่แม่นที่สุดคือดูว่าแต่ละตัวถูกออกแบบมาเพื่อตอบคำถามอะไร

• Reverse Proxy: กลไกพื้นฐาน คือเซิร์ฟเวอร์ที่รับ request แทน backend แล้วส่งต่อ เอกสาร NGINX บอกว่า proxy มักใช้เพื่อกระจายโหลดไปหลายเซิร์ฟเวอร์ แสดงเนื้อหาจากหลายเว็บ หรือส่ง request ต่อให้ application server ผ่านโปรโตคอลอื่นนอกจาก HTTP
• Load Balancer: ตอบคำถามว่า "เครื่องไหนว่าง" AWS อธิบาย Elastic Load Balancing ว่ากระจาย traffic ไปยังหลายเป้าหมาย ตรวจ health check และส่ง traffic ไปเฉพาะเป้าหมายที่ยังปกติ ปกติใช้กับ service เดียวกันที่รันหลายสำเนา
• API Gateway: ตอบคำถามว่า "request นี้คือใคร ได้สิทธิ์ไหม และต้องไป service ไหน" Kong เขียนไว้ตรงๆ ว่า API gateway คือ Reverse Proxy ที่ให้เราจัดการ ตั้งค่า และ route request ไปยัง API ได้ คือเป็น Reverse Proxy ที่เพิ่มงานระดับ API เข้าไป

สรุปความสัมพันธ์คือ API Gateway เป็น Reverse Proxy ชนิดหนึ่งเสมอ แต่ Reverse Proxy ไม่จำเป็นต้องเป็น API Gateway และสองหน้าที่นี้ซ้อนกันได้ เช่น Microsoft ระบุว่า Azure API Management ไม่ทำ load balancing เอง จึงควรใช้คู่กับ load balancer อย่าง Azure Application Gateway ในระบบจริงจึงเห็นได้ทั้งแบบ load balancer อยู่หน้า gateway หลายตัว และแบบ gateway ส่งต่อไปยัง load balancer ของแต่ละ service ลำดับไม่ได้ตายตัว ขึ้นกับสถาปัตยกรรม ถ้าอยากเห็นฝั่ง load balancing ลงมือจริงด้วย Go มีอธิบายไว้ใน Golang The Series EP.165 เช่นกัน

ระบบเล็กจำเป็นต้องมี API Gateway ไหม

จริงๆ แล้วยังไม่จำเป็น และหลายกรณีไม่ควรมีด้วย

ถ้าแอปของคุณมี backend ตัวเดียว หน้าแอปเรียก URL เดียวอยู่แล้ว การใส่ gateway เพิ่มคือการเพิ่มอีกหนึ่ง hop เพิ่มอีกหนึ่งระบบที่ต้องดูแล โดยไม่ได้แก้ปัญหาอะไร Microsoft เองเขียนไว้ใน Gateway Routing pattern ว่ารูปแบบนี้อาจไม่เหมาะเมื่อแอปเรียบง่ายและใช้แค่หนึ่งหรือสอง service

แต่ต้องรู้ด้วยว่า gateway มีราคาของมัน เอกสารเดียวกันเตือนว่า gateway อาจกลายเป็น single point of failure (จุดที่ถ้าล่มแล้วทั้งระบบล่ม) และอาจกลายเป็นคอขวดถ้ารับโหลดไม่ไหว ทางแก้คือรัน gateway หลายตัว ทำ load test และจำกัดไม่ให้ service ข้างหลังเปิดรับ request จากภายนอกโดยตรง ให้ทุกอย่างต้องผ่าน gateway เท่านั้น

สัญญาณที่บอกว่าถึงเวลาแล้วคือสิ่งที่เห็นในแอปสั่งอาหารตอนต้น: หน้าแอปต้องจำหลาย URL, ทุก service เขียนโค้ดตรวจ login ซ้ำกัน, และการย้าย service ทีหนึ่งต้องแก้หน้าแอปตาม

---

สรุป: API Gateway คืออะไร และควรเริ่มใช้เมื่อไหร่

API Gateway คือประตูทางเข้าเดียวหน้า backend หลาย service ทำหน้าที่ routing, ตรวจตัวตน, จำกัดจำนวนครั้งด้วย 429, ถอดรหัส TLS, ปรับข้อมูลระหว่างทาง และเก็บ log ไว้ในที่เดียว มันเป็น Reverse Proxy ชนิดหนึ่งที่เพิ่มงานระดับ API เข้าไป และทำงานคนละโจทย์กับ Load Balancer ที่ดูแลการกระจายโหลดไปหลายเครื่อง

ถ้าวันนี้ระบบของคุณยังมี backend ตัวเดียว ยังไม่ต้องรีบ แต่ลองเอาโค้ด gateway 57 บรรทัดข้างบนไปรันเล่น เพิ่ม route ที่สาม เปลี่ยนเพดาน rate limit แล้วดูว่า 429 เปลี่ยนตามยังไง พอวันที่แอปของคุณแตกเป็นหลาย service จริง คุณจะรู้ทันทีว่า gateway ตัวจริงอย่าง Kong หรือ Amazon API Gateway กำลังทำอะไรให้อยู่

ติดตามบทความและเทคนิคสำหรับคนเริ่มต้นสายโปรแกรมเมอร์ได้ที่ช่องทางของเรา

Facebook: Superdev Academy Thailand (https://www.facebook.com/superdev.academy.th)

YouTube: Superdev Academy Channel (https://www.youtube.com/@SuperdevAcademy)

Instagram: @superdevacademy (https://www.instagram.com/superdevacademy/)

TikTok: @superdevacademy (https://www.tiktok.com/@superdevacademy?lang=th-TH)