GKE에서 WireGuard 충돌 및 MTU 불일치 버그 탐색
러블의 인프라 팀이 Google Kubernetes Engine(GKE)에서 발생한 클러스터 전체 네트워킹 문제를 디버깅하여 간헐적인 연결 실패를 해결했습니다. AI 에이전트를 사용해 Clickhouse 로그를 스캔한 결과, anetd 파드(Google의 Cilium 구현)가 6일 동안 파드당 약 120번(거의 시간당 한 번) 충돌한 것을 발견했습니다. 크래시 덤프에서 WireGuard 자체가 아닌 Google의 WireGuard 통합 코드에서 동시 맵 접근 패닉이 발생한 것으로 나타났습니다.
첫 번째 수정: 투명 암호화 비활성화
Google 지원팀에서 WireGuard 버그를 우회하기 위해 노드 간 암호화를 비활성화할 것을 권장했습니다. 팀이 변경 사항을 적용하고 모든 anetd 파드를 재시작했습니다. 충돌은 약 4시간 동안 멈췄지만, 사용자들이 Valkey(인메모리 데이터 저장소)에 대한 임의의 연결 실패를 보기 시작했습니다.
두 번째 버그: MTU 불일치
엔지니어 Erik이 tcpdump와 Wireshark로 패킷을 캡처했습니다. 결정적 증거는 "목적지 도달 불가 (단편화 필요)"였습니다. 원인은 다음과 같습니다:
- WireGuard가 활성화된 상태에서 클러스터 MTU는 1420바이트로 설정되었습니다(WireGuard의 80바이트 캡슐화 오버헤드 고려).
- WireGuard를 비활성화한 후, 구성은 표준 1500바이트로 되돌아갔어야 했지만 일부 노드가 재시작되지 않아 여전히 이전 1420 MTU를 사용했습니다.
- MTU가 일치하지 않는 노드를 통과하는 Valkey 연결이 간헐적으로 실패했습니다.
해결 방법
해결책: 모든 노드의 롤링 재시작을 통해 클러스터 전체에 일관된 MTU 구성을 적용했습니다. 이로 인해 단편화 오류가 제거되고 안정성이 복원되었습니다.
주요 시사점
- 첫 번째 버그는 Google의
anetd가 WireGuard를 통합한 부분에서 발생한 맵 접근의 동시성 버그로, GKE 구현에 특화된 문제입니다. - 암호화를 비활성화하면 패닉은 우회할 수 있지만, 전체 노드 롤아웃이 필요한 MTU 불일치가 발생합니다.
- AI 에이전트는 수백만 개의 로그 라인에서 anetd 충돌 패턴을 신속하게 파악하는 데 도움을 주었습니다.
📖 전체 소스 읽기: HN AI Agents
👀 See Also
월 50달러 미만으로 Claude Code와 Metabase를 활용한 완전한 BI 시스템 구축
Reddit 사용자가 Claude Code, BigQuery, 자체 호스팅 Metabase를 사용해 완전한 BI 시스템을 구축했습니다. 15,000달러짜리 전문가 견적을 3일 작업과 월 30달러의 클라우드 비용으로 대체했습니다.
신입 엔지니어가 AI로 성공하는 7가지 방법: 기본기 숙달, AI와 협업, 종단간 프로젝트 구축
IEEE Spectrum의 Lokesh Lagudu가 AI 시대에 새로 진입한 엔지니어를 위한 7가지 실용적인 조언을 제공합니다. 기본기, AI 협업, 프로젝트 기반 학습을 강조합니다.
AI 모델 선택 그만 묻기: 작업을 Haiku, Sonnet, Opus 계층으로 라우팅하세요
작업 유형별로 최소 세 가지 모델을 사용하세요: 읽기/요약에는 Haiku 등급, 코드 작성에는 Sonnet 등급, 다중 파일 리팩터와 디버깅에만 Opus 등급을 사용하세요. 한 사용자의 설정은 40%는 저렴한 모델, 35%는 중간, 25%는 최고 성능 모델에 할당하여 월 약 $30-40의 비용이 듭니다.
Opus 4.7, 프롬프트의 40%를 망가뜨렸다; 해결책은 CLAUDE.md와 스킬의 구조화였다
Opus 4.7이 출시된 후 6개 설정에서 약 40%의 프롬프트 성능이 저하되자, AI 책임자가 임시 프롬프트를 구조화된 Skill 파일, 계층적 CLAUDE.md, 그리고 별도의 메모리 파일로 대체하여 토큰 사용량을 22% 줄이고 반복 횟수를 3-4회에서 1-2회로 줄였습니다.