Files
obsidian/history/2026-07-21-osaka-apisix-etcd-fix.md
kaffa 06fc6040b4 osaka APISIX etcd 설정 오류 정정 및 실제 구성 반영
- osaka config.yaml의 죽은 etcd host(10.100.2.214) → mbp 정상 주소(100.115.154.78)로 수정
- osaka가 로컬 waf-etcd 대신 Patroni 공유 통합 etcd를 실사용 중임을 문서화
- mbp etcd 부트스트랩 플래그의 stale 4번째 멤버(etcd-hp2) 기록
- mbp raft 파티션 자연복구 사례 및 osaka APISIX 버전 지연(3.15.0, 최신 3.17.0) 기록
2026-07-21 15:33:12 +09:00

43 lines
3.3 KiB
Markdown

---
date: 2026-07-21
topic: osaka APISIX etcd 설정 오류 발견 및 정정, mbp etcd 멤버 raft 파티션 자연 복구
areas:
- infra/network/apisix.md
- infra/data/postgresql-ha.md
tags: [history, apisix, etcd, osaka]
---
osaka APISIX 버전 확인 과정에서 실제 실행 중인 설정을 점검하다가 두 가지 문제를 발견하고 정정했다.
## 발견 1: osaka는 로컬 `waf-etcd` 컨테이너를 쓰지 않는다
`/opt/waf-saas/docker-compose.yml`에는 로컬 `waf-etcd`(quay.io/coreos/etcd:v3.5.11) 컨테이너가 정의돼 있지만 **실제로는 기동돼 있지 않았다**. 살아있는 `config.yaml`은 Patroni DCS와 공유하는 [[../infra/data/postgresql-ha|외부 통합 etcd 클러스터]](nas/mbp/jp1)를 prefix `/apisix/osaka`로 사용 중이었다.
## 발견 2: config.yaml의 3번째 etcd host가 죽은 주소였다
`config.yaml`의 etcd host 목록:
```
192.168.9.100 (nas, 정상)
10.100.2.214 (죽은 주소 — 응답 없음)
10.253.101.233 (jp1, 정상)
```
`10.100.2.214`는 mbp의 `etcd-mbp` 컨테이너 자체의 `--initial-cluster` 부트스트랩 플래그에 남아있던 옛 4번째 멤버 `etcd-hp2`의 주소였다 (hp2 기반 etcd 멤버는 이미 클러스터에서 제거된 상태, `member/list`엔 3개만 존재). osaka config가 원본 부트스트랩 문자열을 그대로 베껴서 생긴 drift로 추정. 실제 3번째 멤버(`etcd-mbp`)의 올바른 주소는 `100.115.154.78`(Tailscale)인데 config엔 아예 없었다.
**조치**: `config.yaml``10.100.2.214``100.115.154.78`로 수정, `docker compose restart waf-apisix`로 적용. 재시작 후 로그에 `no route to host` 재발 없음, 라우트 11개 정상 로드, `ironclad.it.com` 200 응답 확인.
## 발견 3 (조사 중 지나가며 확인): mbp etcd 멤버가 일시적으로 raft 파티션 상태였다
조사 시점에 `etcd-mbp`(100.115.154.78)가 다른 2개 멤버와 raft 스트림이 끊겨 격리된 상태였다 (`failed to publish local member to cluster through raft ... request timed out` 반복, 로컬 `127.0.0.1:2379/health`조차 무응답). SSH(22번 포트)는 Tailscale로 정상 접속됐으나 raft 스트림만 끊겨 있었음 — 원인은 특정하지 못했으나 **재접속 시도 중 자연 복구**됨 (`established TCP streaming connection with remote peer` 로그, 이후 3노드 전부 정상). 클러스터는 nas+jp1 2/3 쿼럼으로 계속 정상 서비스 중이었어서 이 기간 동안 실제 장애는 없었음.
## 교훈
- APISIX 인스턴스가 여러 개(서울 K3s, 오사카, 서울 relay) 있고 etcd 백엔드도 로컬/K3s내부/외부통합으로 제각각이라, "이 인스턴스가 실제로 어떤 etcd를 쓰는지"는 `docker ps`/`config.yaml` 실물을 봐야 확실함 — 문서에 적힌 구성과 실제가 다를 수 있음
- 설정값에 여러 호스트 IP가 나열돼 있으면 그중 죽은 게 있는지 개별 헬스체크로 확인할 것. compose 파일에 정의된 서비스가 곧 실제로 쓰이는 서비스라고 가정하지 말 것
- 3노드 중 1노드가 조용히 파티션되어도 쿼럼(2/3)만 유지되면 겉으로는 정상 동작해서 알아채기 어려움 — 정기적으로 `member/list` + 각 멤버 개별 헬스체크 권장
## 참조
- [[../infra/network/apisix|APISIX 설정 및 운영]]
- [[../infra/data/postgresql-ha|PostgreSQL HA (Patroni) 및 통합 etcd]]