[Claude] App of Apps 패턴, 카프카/템포/크론잡, GitAIOps

안녕하세요. AI 시대에 개발자가 알아야 할 인프라 구성 배포 with 클로드 코드 책을 읽고 학습한 내용을 정리했습니다.

 

이전 실습을 통해 관측 가능성을 구축하면서 클러스터 안에서 무슨 일이 일어나는지 한 화면에서 볼 수 있게 되었습니다. 

 

7장. [Enterprise] 규모 확장

스토리 : 대형 고객사 계약! 전용 환경 요청 → 인프라 확장과 테넌트 분리

멀티 노드풀로 워크로드를 분리하고, App of Apps 패턴으로 여러 앱을 체계적으로 관리합니다. Namespace 기반 멀티테넌시로 테넌트를 격리합니다.


7.1 성장통: SMB 구조의 한계

지금까지 구조에는 두 가지 문제가 있습니다.

 

1. 리소스 경합

- 프로메테우스가 메트릭을 수집하면서 CPU를 많이 쓰면 같은 노드에 있는 Notiflex API의 응답이 느려집니다. 

- 모니터링 때문에 서비스가 느려지는 상황이 생깁니다. 카프카를 추가하면 메모리 경합까지 심해집니다.

 

2. 격리 불가 

- 대형 고객사가 요구하는 것은 자신의 데이터가 다른 고객과 섞이지 않고 자신의 워크로드가 다른 고객의 영향을 받지 않는 것입니다.

- 네임스페이스 하나에 모든 리소스가 모여 있는 구조로는 불가능합니다.

 

1) 노드풀 분리 : 역할별로 노드를 나눕니다. API는 API 전용 노드에서 모니터링은 모니터링 전용 노드에서 실행합니다. 

2) 테넌트 분리 : 고객별로 네임스페이스를 나누고 리소스를 격리합니다.

 

ArgoCD 애플리케이션이 이미 여러개인데 앞으로 테넌트와 카프카까지 추가되면 관리가 번거로워집니다. Apps of Apps 패턴으로 체계를 잡습니다. 

 

7.2 워크로드별 노드 배치: 멀티 노드풀

지금은 default-pool(e2-medium 2대)에 모든 워크로드가 올라가 있습니다. API 트래픽이 몰리면 프로메테우스가 같은 노드에서 CPU를 경합하고 카프카까지 추가하면 메모리까지 부족해집니다.

 

[프롬프트]

워크로드별로 노드를 분리할 수 있어? API는 API 전용 노드에만 올리고 싶어.

 

클로드 코드가 추천한 nodeSelector로 결정합니다. 

 

[프롬프트]

역할별 노드풀을 만들어줘.

 

7.3 다수 앱 관리: App of Apps 패턴 + Sync Wave

지금까지 만든 ArgoCD 애플리케이션을 세어봅니다. Notiflex API, kube-prometheus-stack, Loki + Fluent Bit, Argo Rollouts 그리고 Valkey, 앞으로 카프카, 템포(Tempo) 그리고 테넌트별 배포까지 추가되면 더 늘어납니다. 

 

[프롬프트]

ArgoCD에서 앱이 여러 개인데 관리가 힘들어. 한번에 관리하는 방법 없어?

 

 

[프롬프트]

App of Apps 패턴 적용해줘

 

 

[프롬프트]

앱 설치에 순서가 있어야할 거 같아. 설정해줘.

 

7.4 멀티테넌시: Namespace 격리

Notiflex는 B2B 알림 SaaS 입니다. 여러 기업 고객(테넌트)에게 서비스를 제공하려면 테넌트 간 데이터와 리소스를 격리해야 합니다. 대형 고객사가 요구하는 것은 '우리 데이터가 다른 고객과 섞이면 안된다'는 것입니다.

 

[프롬프트]

고객별로 환경을 분리하려면 어떻게 해?

 

 

[프롬프트]

멀티 테넌시 구성해줘.

 

💡 마무리: `settings.local.json`으로 권한 분리 체험

.claude/settings.local.json은 클로드 코드의 동작을 기술적으로 제어합니다. 명령을 차단하거나 실행 전 승인을 요구할 수 있습니다.

 

[프롬프트]

.claude/settings.local.json을 만들어서 위험한 명령은 차단하고 비용드는 명령은 승인받게해줘.

 

[프롬프트]

엔터프라이즈 네임스페이스의 notiflex-api를 kubectl로 지워줘.

 

[프롬프트]

방금 만든 settings.local.json 되돌려줘.

 

[프롬프트]

/update-docs

 

8. [Enterprise] 고도화

스토리 : 서비스 간 호출이 꼬이고, 배치가 밀린다

Kafka로 이벤트 기반 아키텍처를 도입하고, Tempo로 분산 트레이싱을 구축합니다. CronJob으로 주기적 배치 작업을 자동화합니다.

8.1 이벤트 드리븐: Kafka

지금 Notiflex는 클라이언트가 POST 요청을 보내면 API가 알림을 직접 처리하고 끝나야 응답을 반환합니다. 알림 발송이 오래 걸리면 API 응답도 느려집니다. 그리고 요청이 몰리면 타임아웃이 발생합니다.

 

[프롬프트]

요청이 몰리면 API가 느려지는데 비동기로 처리할 수 있어?

[프롬프트]

카프카 설치해줘

8.2 분산 트레이싱: Tempo

API에서 카프카를 거쳐 Consumer로 이어지는 흐름이 생겼습니다. 알림이 안 갔을 때 어디서 막혔는지 추적하기 어렵습니다. API가 카프카에 발행을 실패했는지 카프카에는 들어갔는데 Consumer가 소비를 못했는지 로그를 Pod별로 뒤져야합니다.

 

요청 처리 경로를 추적할 분산 트레이싱 도구로 어떤 걸 쓸지 먼저 물어봅니다.

 

[프롬프트]

요청이 어디서 느린지 어떻게 알 수 있어?

 

[프롬프트]

템포 설치하고 트레이싱 설정해줘

 

8.3 배치 자동화: CronJob

시스템이 복잡해졌습니다. API -> 카프카 -> Consumer로 이어지는 흐름에서 API가 정상 응답하는지 주기적으로 확인하고 싶습니다. 

 

[프롬프트]

APi 헬스체크를 주기적으로 자동 실행하고 싶은데 어떻게 만들어?

$

[프롬프트]

크롭잡을 만들어줘

💡 마무리: `command-guardrails/`로 위험 작업 절차 정리

'어떤 순서로, 무엇을 확인하고, 어떻게 실행하는지'를 정리한 것이 command-guqrdrails/ 입니다.

 

[프롬프트]

command-guardrails/에 위험 작업 실행 절차를 작성해줘.
카프카 토픽 삭제, 크론잡 수동 실행, 테넌트 네임스페이스 삭제 같은 작업이야.

 

[프롬프트]

/update-docs

 

9장. [종합] GitAIOps: 살아있는 운영 표준의 탄생

스토리 : 돌아보니, 이 모든 기록이 운영 표준이 되어 있었다

지금까지 쌓인 저장소 구조, 코드, 설정, 문서를 돌아봅니다. Git + AI + Ops가 어떻게 연결되었는지 분석하고, 다음 단계를 제안합니다.

9.1 AI에게 저장소 분석 시키기

 

[프롬프트]

지금까지 구성한 notiflex-platform 저장소를 분석해줘

[프롬프트]

커밋 히스토리도 분석해줘

 

[프롬프트]

클러스터 상태도 보여줘

9.2 쌓인 것들을 돌아보기

[프롬프트]

지금까지 쌓인 것들 돌아봐줘

[프롬프트]

자원은 어떻게 쓰이고있어?

9.3 기대하지 않았던 효과

전통적인 운영 문서는 별도의 wiki나 confluence에 작성됩니다. 작성 시점에는 정확하지만 시간이 지나면 코드와 괴리가 생깁니다. 

notiflex-platform의 문서는 코드와 같은 저장소에 있습니다. /update-docs가 코드 변경과 동시에 문서를 갱신합니다. 문서가 코드와 함께 살아 있습니다. 

 

살아있는 문서와 AI가 읽는 문서가 결합하면 기존 구조에서 새로운 산출물을 만들 수 있습니다. 

9.4 GitAIOps의 출현

 

[프롬프트]

Git, AI, Ops 연결을 분석해줘

9.5 마무리: 다음 단계

 

[프롬프트]

다음 단계 제안해줘

 

[프롬프트]

/update-docs