Flyway, Incident, Audit까지 묶어 운영 플랫폼으로 다듬기

Kubernetes Cluster Infra RCA Platform 개발 기록 9편

---

지난 글에서는 React 19, TypeScript, Vite, Bootstrap 5 기반으로 Web Console을 다시 구성한 과정을 적었다.

이번에는 구조 전환 이후에 정리한 운영 기능을 다룬다.

Spring Boot와 React로 바꾸고 나니 장애가 끝난 뒤의 기록을 어떻게 남길지 정해야 했다.

report를 만드는 기능은 있었지만, 사용자 행동을 추적하고 플랫폼 자체 상태를 확인할 기능도 필요했다.

Flyway, incident, audit, metric, retention을 이 단계에서 함께 정리했다.

---

Flyway로 DB migration 관리하기

Spring Boot로 통합하면서 DB migration은 Flyway가 맡도록 바꿨다.

DB에 저장하는 정보는 다음과 같았다.

• cluster
• node agent
• evidence request
• evidence bundle
• RCA report
• incident
• action request
• audit event
• user session

모두 운영 기록이므로 schema가 바뀌어도 기존 데이터를 이어서 사용할 수 있어야 했다.

초기 Python/Alembic schema를 Spring Boot로 옮기면서 이 승계 방법을 먼저 검토했다.

기존 Alembic DB를 사용하는 경우에는 해당 schema를 baseline으로 인정하고, 이후 변경부터 Flyway로 관리하는 방향을 잡았다.

기존 DB:
Alembic schema
  -> baseline

새 구조:
Flyway migration
  -> 이후 schema 변경 관리

기존 DB를 버리고 새로 시작하지 않아도 되도록 전환 경로를 둔 것이다.

---

Incident 개념이 필요했던 이유

처음에는 RCA report를 개별 결과로 다뤘다.

그런데 같은 장애에서 여러 report가 나올 수 있었다.

같은 노드의 storage, kubelet, runtime 문제가 시간상 이어지는 경우가 그 예다.

report가 여러 개여도 하나의 incident로 묶어서 볼 필요가 있었다.

여러 evidence signal
  -> 시간상 인접
  -> causal rule로 연결
  -> 하나의 incident로 묶기

incident에서는 신호가 발생한 순서와 뒤따른 문제를 함께 볼 수 있게 했다.

여러 report를 오가며 확인하던 root cause 후보와 장애 흐름을 한곳에서 따라가도록 한 것이다.

---

Audit event를 남겨야 하는 이유

사용자 행동을 나중에 추적할 수 있도록 audit 대상을 정했다.

cluster 등록, report export, action request, approval, 삭제처럼 운영 정보나 상태에 영향을 주는 기능이 대상이었다.

남겨야 할 기록은 다음과 같았다.

• 누가 로그인했는가
• 누가 cluster를 등록했는가
• 누가 report를 조회했는가
• 누가 export를 다운로드했는가
• 누가 action을 승인하거나 거절했는가
• 누가 cluster를 삭제했는가

문제가 생겼을 때 당시의 조회와 변경을 확인하기 위한 기록이다.

RCA 결과뿐 아니라 이 도구를 사용하는 과정도 추적해야 한다고 봤다.

---

Metric과 observability

플랫폼 자체가 느려지거나 멈춘 경우도 확인할 수 있어야 했다.

Micrometer, Actuator, Prometheus metric으로 플랫폼 상태를 볼 수 있게 정리했다.

확인하려던 metric은 다음과 같다.

• Agent offline 상태
• heartbeat lag
• evidence 수집 시간
• RCA report 생성 시간
• analysis queue 상태
• dead-letter 발생 여부
• LLM 호출 결과
• notification 실패 여부

이 값으로 Agent 중단, report 생성 지연, 플랫폼 처리 지연을 구분하려고 했다.

---

Retention policy가 필요한 이유

evidence, report, incident, audit event는 실행할수록 쌓인다.

그대로 두면 DB 용량이 계속 늘어나므로 retention policy를 정리했다.

삭제 기준을 날짜 하나로 정하지는 않았다.

열린 incident, 승인 대기 action, report가 참조하는 evidence를 지우면 기록 사이의 연결이 깨질 수 있었다.

먼저 참조가 끝났는지 확인하고, 그다음 보존 기간을 적용하는 방향으로 검토했다.

지워도 되는 데이터
  -> 참조가 끝난 오래된 evidence
  -> 만료된 session
  -> 닫힌 incident 관련 오래된 데이터

지우면 안 되는 데이터
  -> 열린 incident
  -> 승인 대기 action
  -> report와 연결된 evidence

저장 기간과 데이터 사이의 참조 관계를 함께 봐야 했다.

---

Codex를 어떻게 활용했는가

운영 기능의 우선순위는 직접 정했다.

incident로 묶을 기준, audit 대상, 확인할 metric, retention에서 보존할 데이터도 직접 검토했다.

반복 구현과 테스트 보강에는 Codex를 활용했다.

사람:
운영 기능 우선순위 결정
incident 개념 설계
audit 대상 판단
metric 기준 결정
retention 안전 기준 검토

Codex:
Flyway migration 초안 작성
repository 테스트 보강
audit event 반복 구현
metric endpoint 정리
문서 초안 작성

Codex로 migration과 반복 코드를 작성하는 시간을 줄였다.

삭제 가능한 기록과 남겨야 할 기록의 구분은 직접 검토했다.

---

이 단계에서 중요했던 점

이 단계에서는 장애가 끝난 뒤에도 사용할 수 있는 기록을 만드는 데 집중했다.

당시 근거와 판단, 사용자 행동을 다시 확인할 수 있어야 했다.

이를 위해 다음 기준을 정리했다.

1. DB schema는 Flyway로 관리한다
2. 기존 Alembic schema 승계도 고려한다
3. 개별 report를 incident 흐름으로 묶는다
4. 중요한 사용자 행동은 audit event로 남긴다
5. 플랫폼 자체 metric을 제공한다
6. retention policy로 데이터를 안전하게 정리한다
7. Codex는 구현을 돕지만 운영 판단은 사람이 한다

특히 4번과 5번을 함께 봤다.

사용자의 행동을 추적하는 audit과 플랫폼 상태를 보는 metric이 모두 필요했기 때문이다.

---

마무리

Flyway로 DB 변경을 관리하고, incident로 관련 신호를 묶었다.

중요한 사용자 행동은 audit에 남기고, 플랫폼 metric과 retention 기준도 정리했다.

당시 남은 작업은 실제 장애 시나리오를 늘리고, Agent evidence가 RCA report로 이어지는 데모를 보강하는 것이었다.

다음에는 시나리오별로 evidence 수집과 incident 구성이 어떻게 동작하는지 보여주려고 했다.