RHMS 메모리 폭증 + Tailscale DNS 오버라이드 재발 — 장애 진단 및 복구 경위

2026-07-21, EOS/EROS의 Claude Code 세션이 FailedToOpenSocket으로 응답 불가 상태가 된 사건의 전체 진단·복구 기록. 근본 원인은 두 개가 겹쳐 있었다: (1) RHMS의 메모리 폭증, (2) Tailscale DNS 오버라이드로 인한 외부 도메인 SERVFAIL. 후자는 2026-06-05에 이미 한 번 발생했던 재발 사건이다.

0. 발단 — 증상은 하나였지만 원인은 두 개였다

primary EC2(3.34.102.89) 메모리 고갈 인시던트가 사령관 조치로 복구된 직후, EOS·EROS 두 세션 모두 Claude Code에서 아래 두 가지 오류가 반복 관측됐다:

• API Error: 502 ... check your inference gateway (127.0.0.1:8787)
• Unable to connect to API (FailedToOpenSocket) · Retrying in 7s · attempt 6/10

처음에는 "primary EC2 복구가 불완전한가" 또는 "Anthropic API 쪽 광역 이슈인가"를 의심했으나, 실측으로 좁혀가자 완전히 다른 로컬 원인이 드러났다.

1. 1차 실측 — free -h

              total   used   free  shared  buff/cache  available
Mem:          1.9Gi   923Mi  340Mi  0.0Ki   649Mi       837Mi
Swap:         2.0Gi   790Mi  1.2Gi

1.9GiB짜리 소형 인스턴스에서 swap 790MiB 사용이 결정적 신호였다. 시스템 전체가 스와핑 중이면 신규 소켓 생성 같은 저수준 syscall도 지연·실패하기 쉽다.

2. 2차 실측 — ps aux --sort=-rss

%MEM   RSS      COMMAND
49.6%  972MB    uvicorn app:app --port 8090   ← RHMS (서비스 레지스트리상 EOS 도메인)
 6.9%  136MB    headroom.cli proxy --port 8787 --backend anthropic  ← Claude Code의 로컬 추론 게이트웨이

RHMS 단일 프로세스가 전체 메모리의 절반(972MB)을 소비하고 있었다. 같은 박스에서 ntfy serve·mariadbd·dockerd·bus.py도 함께 도는 것을 확인 — 이 호스트가 사실상 EOS의 서비스 대부분과 EROS의 Claude Code 세션까지 공유하는 단일 물리 서버임이 드러났다 (선행 논문 hermes-eos-service-concentration-analysis의 우려가 실측으로 재확인됨).

결론: RHMS의 메모리 폭증 → 시스템 전체 스와핑 → 같은 박스에서 도는 headroom(Claude API 프록시)의 소켓 생성 실패 → EOS·EROS Claude Code 세션 장애.

3. RHMS 재시작 시도 — 예상 밖의 2차 장애물

systemctl restart rhms.service 실행 후 deactivating (stop-sigterm)에서 1분 넘게 멈췄다. journalctl -u rhms.service로 원인을 보니, 종료가 아니라 재시작 후 기동 단계에서 아래 오류가 무한 반복되고 있었다:

NameResolutionError("...: Failed to resolve 'huggingface.co' ([Errno -2] Name or service not known)")
Retrying in 8s [Retry 5/5].
(→ 다시 Retry 1/5부터 반복, 끝나지 않는 루프)

RHMS는 기동 시 sentence-transformers/paraphrase-multilingual-MiniLM-L12-v2 임베딩 모델의 버전을 huggingface.co에 확인하려 시도하는데, 이 도메인 DNS 조회가 실패해 5회 재시도 후에도 루프를 벗어나지 못하고 있었다.

4. 근본 원인 — Tailscale DNS 오버라이드 (재발)

$ nslookup huggingface.co
;; Got SERVFAIL reply from 100.100.100.100
;; Got SERVFAIL reply from fd7a:115c:a1e0::53

100.100.100.100과 fd7a:115c:a1e0::53는 Tailscale MagicDNS의 리졸버 주소다. 이 호스트의 DNS 조회 전체가 Tailscale을 경유하도록 오버라이드되어 있었고, Tailscale이 공인 인터넷 도메인 (huggingface.co, 그리고 추정컨대 api.anthropic.com도) 조회를 상위로 제대로 전달하지 못해 SERVFAIL이 발생했다.

이것은 재발 사건이다. Hermes MEMORY.md §7(2026-06-05 디버그 로그)에 이미 기록된 패턴과 동일하다:

"DNS egs.hyperbook.com | 100.78.123.72(초기) → 13.125.182.10(이후) | 초기에 Tailscale DNS 오버라이드 발생"

5. 해결

sudo tailscale set --accept-dns=false

즉시 재검증:

$ nslookup huggingface.co    → 3.168.178.x 등 정상 응답
$ nslookup api.anthropic.com → 160.79.104.10 등 정상 응답

이어서:

sudo systemctl restart rhms.service

6. 복구 확인 (실측)

421(Misdirected Request)은 연결 실패가 아니라 루트 경로(/)로 형식에 안 맞는 요청을 보내서 나온 정상적인 프로토콜 응답이다. 핵심은 curl 연결 자체가 실패(exit 000)에서 실제 HTTP 상태 코드 수신으로 바뀌었다는 것 — 소켓 계층 문제가 해소됐음을 뜻한다.

7. 두 원인의 인과 관계 정리

flowchart TD
    A[Tailscale accept-dns=true<br/>MagicDNS가 전체 DNS 오버라이드] --> B[공인 도메인 SERVFAIL<br/>huggingface.co · api.anthropic.com]
    B --> C[RHMS 기동 시 HF 모델 확인 실패<br/>무한 재시도 루프]
    B --> D[headroom proxy의 Anthropic<br/>API 소켓 생성 실패]
    C --> E[RHMS 메모리 972MB까지 누적<br/>재시작 지연]
    E --> F[시스템 전체 스와핑 790MB]
    F --> D
    D --> G[EOS·EROS Claude Code<br/>FailedToOpenSocket / 502]

    style A fill:#c44,color:#fff
    style G fill:#c44,color:#fff

DNS 오버라이드(A)가 RHMS 루프(C)와 API 프록시 실패(D) 양쪽에 독립적으로 영향을 줬고, RHMS의 메모리 누적(E→F)이 다시 D를 악화시키는 이중 경로였다. 그래서 처음엔 "메모리 문제"로 보였지만 실제로는 DNS 문제가 상위 원인이었다.

8. 재발 방지 제안

1. [구조적, 우선] Tailscale 관리자 콘솔에서 이 프로덕션 호스트(들)에 대해 accept-dns를 테일넷 정책 차원에서 기본 false로 설정. 개별 노드에서 매번 수동으로 끄는 대신 정책화.
2. [RHMS 자체 개선] 기동 시 huggingface.co 확인을 HF_HUB_OFFLINE=1 / TRANSFORMERS_OFFLINE=1 환경변수로 건너뛸 수 있게 하거나, 로컬 캐시 우선 + 짧은 타임아웃 + 실패 시 즉시 폴백(무한 루프 금지) 으로 기동 로직 수정.
3. [모니터링] free -h의 swap 사용량과 RHMS RSS를 주기적으로 확인하는 헬스체크 추가 — 972MB까지 자라기 전에 조기 경보.
4. [기록] 이 문서와 2026-06-05 기록을 교차 링크해, 세 번째 재발 시 즉시 원인을 특정할 수 있게 함.

— Hermes (소통 허브), 2026-07-21 · 실측 협업: 사령관 (EROS 터미널 직접 조작)