서버가 멈춰도 서비스는 이어지게,
장애는 고객보다 먼저 보이게 운영해 왔습니다.
모플 Infra Engineer 인턴 2023.11–2024.06 / 이후 Data Engineer 2024.06–2025.11 · h0422ys@naver.com · github.com/VertexToEdge
| # | 사례 | 문제 → 결과 | 공고 업무 | 쪽 |
|---|---|---|---|---|
| 01 | 모니터링·알람 구축 | 장애 포인트 식별 시간 30분 → 5분 [실측] | 모니터링·장애 관리 | 02 |
| 02 | 단일 장애 지점 제거 | 컴포넌트 하나만 멈춰도 서비스 중단 → 5개 핵심 컴포넌트 이중화 · 서버실 3곳 연결 | 온프레미스 구축·운영 | 03 |
| 03 | 운영 작업 자동화 | 재배치는 담당자 1명만 가능 → 재배치 CLI 자동화, 부재 중 동료가 재배치 수행 | 서버 운영 | 04 |
| 04 | 장시간 쿼리 무한 대기 장애 | 10분 넘는 쿼리만 응답 없음 → 커널 keepalive 튜닝, 재발 없음 [관찰] | 장애 관리 | 05 |
| 05 | 장애 전환 버그 수정 | 리더 교체 후 전 레플리카 접속 실패 → upstream 수정 머지 | 장애 관리 | 06 |
장애를 고객 문의로 알던 팀이, 알람으로 먼저 알게 됐습니다.
문제
모니터링이 없어 장애를 고객 문의로 알았습니다. 장애가 나면 담당 엔지니어들이 모여 SSH로 서버마다 접속해 로그를 뒤졌습니다.
영향
- 장애마다 6명 팀의 제품 개발 시간이 빠져나감
- 특정 컴포넌트 장애는 그 담당자만 대응 가능
해결 · 도구보다 필요한 정보부터
- 담당자별로 장애 때 무엇을 확인하는지 인터뷰
- Prometheus(지표) · Loki(로그) ·
Grafana(대시보드·알람) 구축 - 담당자별 확인 정보를 대시보드와 알람 규칙에 표준화
As-is → To-be · 장애 포인트 식별 시간 [실측]
하나만 멈춰도 서비스가 멈추는 구조를, 이중화와 서버실 간 연결로 바꿨습니다.
문제
MariaDB · PostgreSQL · HDFS · Redis · Airflow가 각각 단일 장애 지점이었고, 서버실 3곳의 워크로드가 분리돼 서버실을 넘는 이중화가 어려웠습니다.
| 결정 지점 | 검토한 대안 | 선택 | 기준 |
|---|---|---|---|
| 서버실 연결 방식 | Kubernetes 멀티클러스터 + Calico CNI (문서·아키텍처 조사, k3s PoC) | 기존 워크로드 유지 + 네트워크 계층부터 분리 | 팀 학습 곡선 인수인계 비용 |
| VPN 솔루션 | IPSec 기반 DMVPN(FRR) PoC | WireGuard 기반 MeshVPN(Netmaker) PoC 후 채택 | 인수인계 유지보수 용이성 종합 비용 |
| PostgreSQL 이중화 | — | 새 데이터웨어하우스의 일관성 전략 수립 | 가장 까다로웠던 트레이드오프 |
결과
- 5개 핵심 컴포넌트 이중화 · 서버실 3곳 간 오버레이 네트워크 · VPN 2종 PoC 비교
- AI 추론용 워크스테이션 서버 8대 운영 · Airflow로 자원 할당·워크플로우 관리, PLG로 상태 모니터링
기술 선정 기준
도입 후보는 추상적인 장단점이 아니라 작은 PoC로 리소스 모델, 장애 진단 경로, 네트워크 동작, 운영 전환 비용을 함께 검증합니다.
담당자만 할 수 있던 재배치를, 부재 중에도 동료가 이어받게 만들었습니다.
문제
컴포넌트마다 이중화 방식과 연결 규칙이 달랐습니다. MQTT는 HA에 고정 포트가 필요했고, 리버스 프록시(Caddy)는 keepalived로 이중화해야 했습니다. 노드 간 재배치는 내부 구조를 아는 한 사람만 할 수 있었습니다.
해결 · 원하는 배치를 선언하면 도구가 구성을 계산, 서버 간 마이그레이션은 CLI 명령 1개로 자동화
입력
컴포넌트별 이중화 개수
가용 영역(서버실)별 할당
계산
고정 IP · 포트포워딩
컴포넌트 간 external 설정
출력
즉시 배포 가능한 docker-compose 파일
마이그레이션 절차 문서
선택과 대안
- 수작업 절차 문서화: 통신 구조를 숙지해야 하는 부담이 남아 제외
- Golang: 팀에 Go 사용자가 없어 Python 선택
검증 [관찰]
본인 휴가 중 동료가 서버 간 마이그레이션을 대신 수행했습니다.
운영 기준
검증된 구성을 사람이 반복하지 않고 도구가 재현하게 만들면 운영 작업의 속인성이 사라집니다.
쿼리는 끝났는데 응답이 오지 않던 장애를, 연결 계층까지 좁혀 해결했습니다.
01 문제
약 10분 이상 걸리는 PostgreSQL 쿼리에서만 간헐적으로 결과가 안 돌아옴. 서버는 쿼리 완료, 클라이언트는 무한 대기.
02 원인
TCP 세션 비교: 서버엔 없고 클라이언트에만 남음 → 연결 계층 문제. 쿼리 시간 조절로 재현:
idle 약 10분 < keepalive 기본 7,200초.
03 제약과 선택
timeout 장비는 제어 권한 없음. 앱 타임아웃은 대기만 끊을 뿐 → keepalive probe를 먼저 보냄.
04 조치 · 세 계층 모두 적용
- 접속 문자열 keepalive 활성화
tcp_keepalive_time7,200초 → 300초- 컨테이너 network namespace에도 동일 sysctl
전역 설정 부하 검토 [추정]
상시 세션 약 50개 기준 약 0.33 pps
05 결과 [관찰]
장시간 쿼리 정상 반환, 동일 장애 재발 없음.
검증 기준
설정 뒤 동작 조건까지 확인. SO_KEEPALIVE가 꺼져 있으면 커널 값을 낮춰도 probe가 안 나가고, 컨테이너는 호스트 설정만으로 적용을 보장할 수 없음.
이중화한 구성이 장애 순간에 멈추는 버그를, 원인 라이브러리까지 추적해 고쳤습니다.
문제
Netmaker를 HA로 운영하던 중, 설정 저장소인 분산 DB rqlite의 리더를 종료하자 새 리더는 선출됐는데 레플리카 전부가 죽은 리더에게만 계속 접속을 시도했습니다.
원인 → 조치
Netmaker 코드가 아니라 DB 연결을 맡은 구버전 gorqlite 라이브러리의 버그. gorqlite 업그레이드와 InitRqliteDatabase() 호출 방식 수정 (+5 / −3).
결과
gravitl/netmaker#2799 머지 (2024-02) · v0.23.0 릴리스 포함