Kong의 PG 의존·5초 Reload를 끝낸다, Apache APISIX

이번 글의 주제는 Apache APISIX 입니다. 한마디로 정의하면 "OpenResty(Nginx + LuaJIT) 위에서 동작하면서 설정 저장소로 PostgreSQL/Cassandra가 아닌 etcd v3를 쓰는, ASF Top-Level 프로젝트로 졸업한 클라우드 네이티브 API 게이트웨이"입니다. Kong이 수천 개 라우트에서 5초 이상 걸리는 설정 reload, Tyk의 Redis 의존, Spring Cloud Gateway의 JVM 풋프린트, AWS API Gateway의 요청당 $3.5/M 단가와 클라우드 락인을 한 자리에서 처리합니다. 이 글은 단순 기능 나열이 아니라 왜 OpenResty 진영이 etcd 기반 게이트웨이를 새로 짤 수밖에 없었는지, radix-tree 라우팅·플러그인 우선순위·xRPC·DP/CP 분리라는 아키텍처 선택의 의미, 운영하면서 실제로 마주친 shared dict 폭주·plugin priority 충돌·etcd 절단 시 동작까지 풀어낸 정리본입니다.

30초 요약 — APISIX는 OpenResty 위에 radix-tree 기반 sub-microsecond 라우터와 etcd v3 watch 기반 push-식 설정 동기화를 얹은 게이트웨이입니다. 라우트 1만 개 변경이 ms 단위로 모든 워커에 반영되며, 100+ 내장 플러그인을 우선순위로 체인합니다. xRPC 프레임워크로 HTTP 외에 Redis·MQTT·PostgreSQL·Dubbo 프로토콜도 처리하고, DP/CP 분리(Standalone) 모드로 etcd 없이 파일 기반 운영도 가능합니다. 비용은 — Lua 학습 곡선, etcd 운영 부담, 그리고 Wasm/Java/Go runner의 100µs+ 추가 latency.

---

1. Apache APISIX 기술이란?

왜 필요한지 — Kong·Tyk·Spring Cloud Gateway·AWS APIGW의 한계

"마이크로서비스 앞에 게이트웨이 한 대만 두자"는 전략은 다음 한계 중 하나에 반드시 부딪힙니다.

• Kong의 PostgreSQL/Cassandra 의존과 reload 지연 — Kong은 PostgreSQL에 라우트·플러그인 설정을 저장하고, 각 노드가 polling으로 가져옵니다. 라우트 1천 개를 넘어가면 설정 변경 후 모든 노드에 반영되기까지 5~30초가 걸리고, DB-less mode로 도망쳐도 declarative config 한 덩어리를 재로드해야 해 부분 업데이트가 어렵습니다. PG가 다운되면 cluster 전체가 사실상 read-only가 됩니다.
• Tyk의 Redis 의존 — analytics·rate limit·token storage가 Redis. Redis가 절단되면 게이트웨이 동작이 광범위하게 깨집니다. open-source 버전은 multi-cluster·고급 GraphQL 등에서 enterprise 라이선스 게이팅이 있습니다.
• Spring Cloud Gateway의 JVM 풋프린트 — Spring 진영에서는 자연스럽지만, 단순 라우팅 한 노드에 700MB~1.5GB RAM을 쓰고 GC pause가 P99에 그대로 박힙니다. Reactive Netty 위라도 LuaJIT 게이트웨이의 1ms대 P99에는 미치지 못합니다.
• AWS API Gateway의 가격·락인 — REST API 기준 백만 요청당 $3.5(첫 333M), 거기에 데이터 전송·캐시 비용 별도. 일 100M 요청이면 월 $10K가 게이트웨이만으로 나갑니다. 온프렘·하이브리드·중국·한국 자체망에서는 쓸 수 없고, 사설 도메인·KMS·IAM 모두 AWS에 묶입니다.
• NGINX OSS 단독 — nginx -s reload는 graceful이지만 worker fork·shared dict 재초기화가 일어나 1분에 수십 번 호출하기 어렵습니다. 동적 upstream·라우트·인증·rate-limit을 모두 OSS로 짜려면 OpenResty + 자체 코드 + 자체 컨트롤 플레인을 직접 만들어야 합니다.
• Envoy 단독 — xDS·gRPC·Listener·Cluster·Filter 추상화가 우아하지만 그 자체로 게이트웨이가 아닙니다. xDS 컨트롤 플레인(go-control-plane·Istio Pilot·Contour)이 필요하고, 인증/요금제/문서/포털 같은 API 제품 기능은 다른 도구로 묶어야 합니다.
• Cloud SaaS Gateway(Apigee·Mulesoft) — 기능은 풍부하지만 라이선스 단가가 높고 데이터·정책이 외부에 박힙니다. 한국 금융권·공공처럼 망분리 환경은 채택 불가.

기술 정의

Apache APISIX는 2019년 중국 API7.ai(전 도커 차이나 팀)에서 시작해 2019년 6월 ASF Incubator 진입, 2020년 7월 ASF Top-Level Project로 졸업한 OpenResty 기반 동적 API 게이트웨이입니다. 데이터 플레인은 OpenResty(Nginx + LuaJIT), 컨트롤 플레인은 etcd v3 cluster, 그리고 별도 컴포넌트로 apisix-dashboard·apisix-ingress-controller·API7 Portal/Devportal이 있습니다. 라우트·플러그인·SSL·Consumer·Service Discovery 모든 것이 etcd에 저장되고 모든 워커가 watch로 즉시 반영합니다. 라이선스 Apache 2.0, 사용처는 Tencent·Bilibili·Airwallex·NASA JPL·WPS·Honor·vivo·Wise·Zoom·HuggingFace 등.

핵심 키워드는 다음 6개입니다.

• etcd v3 watch 기반 push 동기화 — 모든 워커가 etcd에 long-lived watch 연결을 유지. 변경이 ms 단위로 전파되며 polling 부하가 0.
• Radix-tree 라우터 — 경로 매칭이 라우트 수와 무관하게 sub-microsecond. 1만 개 라우트에서도 매칭 비용이 거의 일정.
• 플러그인 우선순위 체인 — 100+ 내장 플러그인이 priority 정수로 실행 순서가 결정. 동일 단계(access/header_filter/log)에서 정확한 순서 제어.
• xRPC 프레임워크 — HTTP·HTTPS 외에 Redis(RESP)·MQTT·PostgreSQL·Dubbo·gRPC-web·Kafka 프록시. 게이트웨이에서 멀티 프로토콜.
• DP/CP 분리(Standalone/Decoupled) — etcd 없이 YAML 파일만으로 운영하는 standalone 모드, 또는 control plane(API7-CP)이 데이터 플레인에 push하는 분리 모드 지원.
• Multi-runtime 플러그인 — Lua가 표준이지만 Wasm(proxy-wasm), Java/Go/Python runner를 통해 다른 언어로도 플러그인 작성 가능.

---

2. Apache APISIX 기술 특징

특징설명

etcd watch push 동기화	설정 변경 → etcd revision 증가 → 모든 워커가 watch로 즉시 수신. P99 전파 지연 1초 미만. polling 부하 0.
Radix-tree 라우팅	매칭 비용이 라우트 수와 무관(1K vs 10K vs 100K 거의 동일). host·method·remote_addr·query·header 다중 차원 매칭.
100+ 내장 플러그인	JWT/OIDC/OAuth2/key-auth, limit-req/conn/count, prometheus/opentelemetry/skywalking, response-rewrite/proxy-rewrite, fault-injection 등.
플러그인 우선순위	각 플러그인이 정수 priority 보유. 같은 단계(access·header_filter·log)에서 priority 큰 순서로 실행. 동일 priority 시 알파벳 순.
다중 서비스 디스커버리	DNS·Consul·Nacos·Eureka·K8s service·Apollo. discovery_type 단일 게이트웨이에서 혼용 가능.
SSL/SNI 동적 관리	cert-manager 통합, 멀티 cert(SNI)와 와일드카드 cert 동시 운영. ssl 객체에 cert/key 저장하면 즉시 적용. ALPN, TLS 1.3, mTLS.
xRPC 멀티 프로토콜	HTTP/1.1·HTTP/2·HTTP/3(QUIC)·gRPC·gRPC-web·Dubbo·Redis(RESP)·MQTT·PostgreSQL wire. L4 stream + L7 위임 모두.
Standalone 모드	etcd 없이 YAML 파일만으로 운영. GitOps·정적 환경·작은 팀에 적합. 파일 변경 watch로 hot reload.
K8s Ingress Controller	apisix-ingress-controller가 ApisixRoute/Upstream/Tls CRD를 etcd에 변환. Gateway API v1.0 호환 진행.
Wasm/Java/Go 플러그인	proxy-wasm ABI 지원, plugin-runner-java/go/python으로 외부 프로세스 플러그인. Lua 외 언어로 비즈니스 로직 작성.
Observability 1급	prometheus·OpenTelemetry·SkyWalking·Datadog·Loki·Zipkin·HTTP/Kafka/Splunk/Syslog 로그 플러그인. trace context propagation 자동.
성능	단일 노드 100K+ QPS, P99 latency < 1ms(플러그인 없음). 라우트 1만 개에서도 매칭 비용 일정. RSS 메모리 50~150MB.

---

3. Apache APISIX 동작방식

구성 요소

컴포넌트역할

APISIX (Data Plane)	OpenResty 기반 워커 프로세스. 트래픽 처리·플러그인 실행·라우팅·로깅을 모두 담당. master 1 + worker N 구조.
etcd v3 cluster	Routes/Upstreams/Services/Consumers/SSLs/Plugins 모든 객체의 단일 진실 소스. 3노드 권장, 5노드도 가능.
apisix-dashboard	Web UI(React + Go API). etcd에 직접 read/write. RBAC·SSO·OIDC 통합. 운영자가 시각적으로 라우트 관리.
apisix-ingress-controller	K8s CRD(ApisixRoute/Upstream/Tls/Consumer)를 watch하고 etcd 객체로 변환. Gateway API 호환 progress.
plugin-runner	Java/Go/Python 외부 프로세스 플러그인 호스트. APISIX와 unix domain socket으로 통신. Lua 외 언어로 비즈니스 플러그인 작성용.
Admin API (port 9180)	RESTful 관리 API. Dashboard·CI/CD·Terraform provider가 호출. X-API-KEY 헤더로 인증.
Control API (port 9090)	로컬 진단·healthcheck·플러그인 metadata 조회 API. 외부 노출 금지(127.0.0.1 바인딩).

데이터 흐름

1. 운영자가 Admin API(또는 Dashboard·Ingress CRD)에 라우트/업스트림 변경을 PUT.
2. Admin API가 etcd에 객체를 write하고 revision이 증가.
3. 모든 APISIX 워커가 유지하던 etcd watch 스트림으로 변경 이벤트 수신(평균 ms 이내).
4. 각 워커가 shared dict + per-worker LRU 캐시를 갱신하고 radix-tree를 부분 재구성.
5. 이후 들어온 요청은 갱신된 라우팅·플러그인 체인으로 처리. 다운타임/연결 끊김 0.

요청 처리 흐름은 OpenResty의 페이즈를 그대로 따릅니다.

1. init / init_worker — 부팅 시 1회. etcd watch 등록·plugin 등록.
2. ssl_certificate — SNI에 따라 cert/key 동적 선택.
3. access — 라우트 매칭 → consumer 식별 → access 단계 플러그인(JWT·rate-limit·IP-restriction) 우선순위 순 실행.
4. balancer — upstream(roundrobin·chash·ewma·least_conn) 노드 선택, healthcheck 결과 반영.
5. header_filter — 응답 헤더 단계 플러그인(response-rewrite·CORS) 실행.
6. body_filter — 응답 바디 변형(필요 시) 실행. 큰 바디에는 stream 처리.
7. log — 비동기 log 플러그인(prometheus·OpenTelemetry·HTTP·Kafka·Loki) 실행. 응답 latency에 영향 없음.

---

4. Apache APISIX 구성 및 흐름도

단계별 설명

아래는 외부 클라이언트가 APISIX를 통해 내부 마이크로서비스를 호출하는 일반 시나리오입니다.

[Client]
   |  HTTPS / HTTP/2 / gRPC
   v
+--------------------------------------------------------------+
| APISIX Data Plane (OpenResty + LuaJIT)                       |
|  ssl_certificate -> SNI -> 동적 cert 선택                    |
|  access -> radix-tree 매칭 -> consumer 식별                  |
|         -> [auth] -> [rate-limit] -> [transform] -> ...      |
|  balancer -> upstream(roundrobin/chash/ewma) + healthcheck   |
|  header_filter / body_filter -> [response-rewrite] [cors]    |
|  log -> prometheus / otel / kafka / loki (비동기)            |
+--------------------------------------------------------------+
   |
   |  watch (long-lived gRPC)
   v
+--------------------------------------+
| etcd v3 cluster (3~5 nodes, Raft)    | <-- Admin API / Dashboard /
|  /apisix/routes/*                    |     Ingress Controller PUT
|  /apisix/upstreams/*                 |
|  /apisix/ssls/*  /consumers/*  ...   |
+--------------------------------------+
   |
   v
[Upstream services] - K8s pods / VMs / external

실제 처리 흐름 — "JWT 인증 + rate-limit + Prometheus 메트릭" 라우트

1. 운영자가 PUT /apisix/admin/routes/100로 /api/v1/orders → order-service upstream을 등록. plugins로 jwt-auth·limit-count·prometheus 활성.
2. etcd에 객체 저장 → revision +1 → 모든 APISIX 워커가 watch로 수신 → radix-tree 갱신.
3. 클라이언트가 GET /api/v1/orders를 Authorization: Bearer ...로 호출.
4. access 단계: jwt-auth(priority 2510) 먼저 실행 → consumer "user_42" 매칭 → limit-count(priority 1002) 실행 → 1분당 60회 카운트 확인 → 통과.
5. balancer: order-service upstream에서 chash(소비자 키 기준)로 동일 사용자를 동일 pod에 라우팅.
6. upstream 응답 도착 → header_filter 실행 → log 단계에서 prometheus 메트릭(apisix_http_status·apisix_http_latency) 업데이트.
7. Grafana가 APISIX의 /apisix/prometheus/metrics 엔드포인트(별도 9091 포트)를 스크랩.

---

5. Apache APISIX 설치 방법

5-1. 로컬/단일 노드 (Docker Compose)

git clone https://github.com/apache/apisix-docker.git
cd apisix-docker/example
docker compose -p docker-apisix up -d

# 기동 확인
curl -s http://127.0.0.1:9080/  # 데이터 플레인 (트래픽 포트)
curl -s http://127.0.0.1:9180/apisix/admin/routes \
     -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1"

참고: 디폴트 admin key는 절대 운영에 그대로 쓰지 말 것. conf/config.yaml의 deployment.admin.admin_key를 32자 랜덤으로 교체하고 etcd ACL 별도 설정 필요.

5-2. Kubernetes (Helm)

helm repo add apisix https://charts.apiseven.com
helm repo update

# etcd + APISIX + dashboard + ingress-controller 한 번에
helm install apisix apisix/apisix \
  --namespace apisix --create-namespace \
  --set ingress-controller.enabled=true \
  --set dashboard.enabled=true \
  --set etcd.replicaCount=3 \
  --set service.type=LoadBalancer

kubectl -n apisix get pods
kubectl -n apisix get svc apisix-gateway

5-3. Standalone 모드 (etcd 없이 YAML)

# conf/config.yaml
deployment:
  role: traditional
  role_traditional:
    config_provider: yaml   # etcd 대신 파일

# conf/apisix.yaml (이 파일을 watch)
routes:
  - id: 1
    uri: /hello
    upstream:
      type: roundrobin
      nodes:
        "127.0.0.1:8080": 1
#END

주의 — Standalone 모드는 파일 끝에 반드시 #END가 있어야 inotify가 변경을 감지합니다. 이거 빠뜨려서 "왜 reload가 안 되지" 30분 날린 사례 다수.

---

6. Apache APISIX 사용 방법

코드/설정 — 라우트 + JWT + rate-limit + Prometheus

# 1) Upstream 등록
curl -X PUT http://127.0.0.1:9180/apisix/admin/upstreams/order-svc \
  -H "X-API-KEY: $ADMIN_KEY" -d '
{
  "type": "roundrobin",
  "discovery_type": "kubernetes",
  "service_name": "default/order-service:8080",
  "checks": {
    "active": { "http_path": "/healthz", "healthy": {"successes":2}, "unhealthy": {"http_failures":3} }
  }
}'

# 2) Consumer + JWT 키 등록
curl -X PUT http://127.0.0.1:9180/apisix/admin/consumers/user42 \
  -H "X-API-KEY: $ADMIN_KEY" -d '
{
  "username": "user42",
  "plugins": {
    "jwt-auth": { "key": "user42-key", "secret": "REPLACE_WITH_LONG_SECRET" }
  }
}'

# 3) 라우트 등록 (JWT + 1분 60회 + Prometheus)
curl -X PUT http://127.0.0.1:9180/apisix/admin/routes/100 \
  -H "X-API-KEY: $ADMIN_KEY" -d '
{
  "uri": "/api/v1/orders*",
  "methods": ["GET", "POST"],
  "upstream_id": "order-svc",
  "plugins": {
    "jwt-auth": {},
    "limit-count": { "count": 60, "time_window": 60, "rejected_code": 429, "key_type": "var", "key": "consumer_name" },
    "prometheus": {}
  }
}'

# 4) JWT 발급
curl -G "http://127.0.0.1:9080/apisix/plugin/jwt/sign" \
  --data-urlencode "key=user42-key"
# eyJ0eXAiOiJK... 토큰을 받음

# 5) 호출
curl -H "Authorization: Bearer eyJ0eXAi..." \
  http://127.0.0.1:9080/api/v1/orders

운영 시 고려사항 — 실전에서 반드시 챙겨야 할 것

• Admin API 분리·차단 — 9180 포트는 절대 외부 노출 금지. NetworkPolicy/SG로 운영 VPC 안에서만, admin_key는 32자 랜덤. 가능하면 mTLS 추가.
• etcd 3노드 + 별도 디스크 — etcd가 다운되면 신규 라우트 변경이 전파되지 않습니다(기존 캐시는 유지). 3노드 이상, fsync 안정한 SSD, defrag 주기 설정 필수.
• worker 프로세스 수 — nginx_config.worker_processes: auto로 두면 vCPU 수만큼. 컨테이너에서는 CFS quota를 인식하지 못해 over-provisioning 됩니다. 명시적으로 limits.cpu와 동일하게 박을 것.
• shared_dict 크기 — nginx_config.http.lua_shared_dict의 plugin-info·limit-count·prometheus-metrics가 라우트 수 많아지면 빠르게 가득 참. 기본 10MB → 64MB~256MB로.
• 로그 플러그인의 sample-rate — HTTP/Kafka로 모든 요청 로그를 보내면 backend가 죽습니다. batch_max_size·inactive_timeout·buffer_duration 튜닝, 1~10% 샘플링.
• upstream healthcheck 분리 — passive만 켜면 fail-open 위험, active 추가하되 너무 자주 찌르면 upstream에 부하. 5~10초 간격이 무난.
• HTTPS 인증서 렌더링 — cert-manager가 만드는 Secret을 ApisixTls CRD가 watch. cert 회전 시 worker 메모리 잠시 두 배. 큰 cert 수백 개일 때 reload 비용 고려.
• 플러그인 priority 충돌 — 커스텀 플러그인 만들 때 기존 플러그인과 priority가 겹치면 알파벳순 정렬에 의존하게 됨. 의도 명확히 numeric으로 박을 것(예: auth는 2500대, transform은 1000대, limit는 1000~1500대).
• Prometheus 메트릭 cardinality 폭발 — prefer_name 옵션 안 끄면 라벨이 라우트 ID 기준으로 들어가는데, dynamic route ID가 많으면 series 폭발. disable 또는 별도 mapping rule.
• graceful shutdown — SIGQUIT(또는 quit) 보내야 in-flight 요청 종료 후 종료. K8s preStop hook에 apisix quit 후 sleep 권장.
• 업그레이드 호환성 — 메이저 버전(2.x → 3.x) 시 etcd 키 prefix 변경(/apisix는 동일하지만 plugin_metadata 구조 변경). 마이그레이션 스크립트 사전 시연 필수.

---

7. Apache APISIX 자주 쓰는 명령어 & 트러블슈팅

자주 쓰는 명령어

명령어설명

apisix start | stop | quit | reload	기동/종료/우아한 종료/설정 재적용. quit는 in-flight 요청 끝까지.
apisix init	conf/config.yaml을 nginx.conf로 렌더링만. 기동 전 설정 검증용.
apisix test	nginx -t 와 동일. 설정 문법 검증.
apisix version	실행 중 버전 확인. CI에서 이미지 태그 검증용.
curl :9090/v1/healthcheck	Control API. 모든 upstream의 헬스 상태(active/passive 통합) JSON.
curl :9090/v1/schema	현재 워커가 인식 중인 라우트/upstream/플러그인 schema 덤프. drift 디버깅.
curl :9091/apisix/prometheus/metrics	Prometheus scrape 엔드포인트. 9091은 별도 포트로 분리.
etcdctl --endpoints=$E get --prefix /apisix	etcd에 저장된 모든 APISIX 객체 덤프. 백업·문제 분석.
kubectl logs -n apisix -l app=apisix --tail=200	데이터 플레인 로그. error_log + access_log 둘 다.
PUT /apisix/admin/routes/{id} -H "X-API-KEY:..."	라우트 생성/갱신. PATCH는 부분 업데이트, DELETE는 삭제.
GET /apisix/admin/plugins/list	현재 활성 플러그인 목록 + priority. 충돌 확인용.

실전 트러블슈팅 사례 — 직접 겪은 5가지

증상원인 & 해결

Admin API에서 PUT은 200인데 트래픽엔 안 반영	Standalone 모드 + apisix.yaml 끝에 #END가 빠짐. 또는 etcd watch 연결이 idle timeout으로 끊김. 해결: curl :9090/v1/schema로 워커가 보고 있는 실제 설정 확인. etcd 쪽은 LB의 idle_timeout을 watch보다 길게.
특정 시간대 P99 latency가 50ms→500ms 튐	log 플러그인이 동기 HTTP로 모든 요청을 외부 SaaS에 전송. Backend가 느려지면 log 큐가 차고 access 단계까지 영향. 해결: batch-requests로 묶고 buffer_duration·inactive_timeout·sample-rate 적용.
shared dict full 경고 후 limit-count가 fail-open	lua_shared_dict plugin-limit-count 10m이 너무 작음. consumer 수가 늘면서 키가 폭발. 해결: 64MB~256MB로 증가, 그래도 부족하면 policy: redis로 외부 Redis 사용.
업스트림 변경 후 5분간 502	DNS 기반 service discovery에서 dns_resolver TTL이 너무 길고, K8s 서비스 IP가 바뀜. 해결: discovery_type: kubernetes로 전환(API 서버 watch 사용), 또는 dns_resolver_valid를 5~10초로 단축. active healthcheck 같이 켜기.
롤링 업데이트 중 502 일부 발생	Pod가 SIGTERM 받자마자 종료 → APISIX의 in-flight upstream 연결 RST. 해결: K8s preStop hook에 sleep 15(EndpointSlice 전파 대기) → apisix quit. terminationGracePeriodSeconds 60.
커스텀 Lua 플러그인이 worker 한쪽에서만 동작	init 단계에서 module local 변수에 상태를 저장하면 워커 간 공유 안 됨. 해결: ngx.shared.DICT(워커 간 공유) 또는 etcd watch로 상태 동기. 절대 file/메모리에 의존 금지.
Prometheus 메트릭 fetch가 30초 넘게 timeout	동적 라우트가 수만 개라 series cardinality 폭발. prefer_name: false이거나 default_buckets가 너무 세분. 해결: 라벨 차원 줄이기, latency_buckets 정수 5~7개로, 또는 OpenTelemetry 메트릭으로 전환(push 모델).
etcd 절단 후 신규 라우트 PUT이 실패	etcd quorum 깨지면 Admin API write 실패. 데이터 플레인은 캐시로 계속 동작. 해결: etcd 3노드(가능하면 5노드), defrag 주기, snapshot count, network/disk 격리. 비상 시 standalone 모드 fallback도 미리 시연.

---

8. Apache APISIX 활용방안

언제 쓰면 좋은가

• K8s + 다중 마이크로서비스 + 라우트 수천 개 — ingress-nginx의 동적 한계, Kong의 reload 지연을 피하려는 팀.
• HTTP 외 프로토콜이 섞인 환경 — gRPC + Dubbo + MQTT + Redis 동시 처리. xRPC로 단일 게이트웨이.
• 망분리·온프렘·하이브리드 — 클라우드 SaaS API 게이트웨이 못 쓰는 금융·공공·중국 시장.
• OpenResty/Lua 자산이 있는 팀 — 기존 Lua 코드·노하우를 그대로 플러그인으로 옮길 수 있음.
• API 마켓플레이스/포털 — API7 Devportal과 결합해 외부 개발자에게 키 발급·요금제·문서 제공.

대안 기술 비교

대상핵심 차이APISIX가 우월한 점상대가 우월한 점

Kong	PostgreSQL/Cassandra 또는 DB-less. 같은 OpenResty 기반.	etcd push로 ms 단위 reload, 100+ OSS 플러그인, xRPC.	생태계 성숙(Konnect SaaS·Insomnia), 영어권 자료 많음.
Tyk	Go 기반, Redis 의존. Open Core.	Apache 2.0 100% OSS, 라우팅 성능, 플러그인 수.	Go 친화 운영, dashboard UX, GraphQL 깊이.
NGINX OSS / NGINX Plus	바닐라 NGINX. Plus는 동적 reload·API 지원.	컨트롤 플레인·플러그인·인증·관측을 한 번에. 추가 코딩 불필요.	단순함, 작은 환경에서의 운영 부담 최소.
Envoy + xDS(Istio Gateway·Contour)	L4/L7 프록시 + 컨트롤 플레인 분리.	즉시 사용 가능한 게이트웨이 기능, 대시보드, 컨슈머 모델.	서비스 메시 통합, WASM·xDS 표준, 대규모 메시.
Spring Cloud Gateway	Java/Reactor 기반. Spring 생태계 통합.	P99 latency, 메모리 풋프린트, 다중 언어 친화.	Spring 자산 재활용, Java 팀의 운영 친숙도.
AWS API Gateway / Apigee	관리형 SaaS.	단가, 락인 없음, 온프렘/하이브리드 지원, 무제한 플러그인.	완전 관리형, 다른 클라우드 서비스 통합 1급.
Pingora	Cloudflare가 만든 Rust 비동기 HTTP 프록시 프레임워크.	즉시 운영 가능한 게이트웨이, 컨트롤 플레인, 100+ 플러그인.	메모리 안전성, 트릴리언 RPS 검증, 커스텀 빌드 자유도.

언제 쓰면 안 되는가

• 한두 개 라우트만 필요한 단순 환경 — NGINX OSS로 끝. APISIX는 etcd 운영 부담만 추가.
• 운영팀에 OpenResty/Lua 경험이 전혀 없고 도입 시간도 없을 때 — 트러블슈팅 시 ngx.* API와 LuaJIT 특성을 모르면 stuck. Kong/Tyk 같은 대안의 한국어 자료가 더 많을 수 있음.
• 풀-매니지드 서비스가 강하게 요구되는 PoC/스타트업 — Cloudflare API Gateway, AWS API Gateway가 시간 절약. 단가 임계점(보통 월 $5K+) 넘으면 APISIX로 이전 검토.
• 풀 서비스 메시(트래픽 mTLS·라우팅 + 사이드카) 자체가 목적 — Linkerd/Istio가 더 적합. APISIX는 north-south 게이트웨이가 주력.
• 하드웨어 리소스가 극단적으로 적은 임베디드/엣지 — etcd cluster + APISIX 풋프린트가 부담. Caddy·Traefik가 가벼움.

실전 활용 사례

• Airwallex(핀테크) — 글로벌 결제 API 게이트웨이로 APISIX. 라우트 수천 개, 다중 리전, 자체 플러그인으로 PCI-DSS 컴플라이언스.
• NASA JPL — 위성 데이터 API 노출에 사용. xRPC로 다중 프로토콜 처리.
• Tencent / Bilibili / WPS / vivo / Honor — 중국 대형 사용자. 일 수백 억 요청 수준.
• HuggingFace — 일부 인프라에서 LLM 추론 API 게이팅·rate-limit·관측에 활용.
• Wise(전 TransferWise) — 마이크로서비스 게이트웨이로 Spring Cloud Gateway에서 APISIX로 마이그레이션 사례 공개.