GitAIOps – Cpt6, 엔터프라이즈를 위한 기반 정비

Log on Me

Activities / Study / GitAIOps

GitAIOps – Cpt6, 엔터프라이즈를 위한 기반 정비

Kubernetes, AWS, Terraform, Linux 운영 경험을 정리한 기술 블로그입니다.

JongJin Kim GitAIOps

Summary

  • 시나리오상, 서비스가 성장하며 동작/보안/안정성 이슈 발생(API정합성,비밀키노출,트래픽전체전환)
  • state의 중앙저장(Valkey) / GCP Secret Manager(민감정보 외부저장) / Canary (트래픽 점진 전환) 으로 개선
  • 상황에 따라 로드되는 AI에이전트의 3단계 지식 수준: CLAUDE.md(작업 규칙), .claude/memory(컨텍스트), claude-context/(현재 아키텍처)

Thoughts

  • 지난 챕터들 대비 특별히 떠오르는 생각이 없어서 skip..
    • Redis(Valkey)를 관리형으로만 써봤지 직접 구성해본적은 없었는데 구성 및 적용은 자연어로 쉽게가능
    • 복잡한 구성이나 트러블 슈팅도 가능할지 > 시간지나고 모델 성능이 올라오고 더 많은 추론/컨텍스트를 사용할 수 있다면 가능할 듯

—

6장. 엔터프라이즈를 위한 기반 정비

  • 서비스가 성장하며 발생한 3가지 문제점
    • API 응답 지연: 개별 pod의 독립적인 메모리에 데이터 저장 (지연이 아니라 오동작이여하지않나..)
    • 비밀번호 평문저장: k8s secret은 암호화 아님, 인코딩이기에 누구나 디코딩 가능
    • 한번에 버전 전환: preview가 정상이여도 운영에서 문제 발생 시, 전체 영향
  • 개선 방향
    • Valkey: pod간 상태 공유
    • Google Secret Manager: 민감정보를 외부에서 관리
    • Canary: 트래픽 점진적 배포

6.1 Pod 간 상태 공유: Valkey 캐시

  • 현재 Notiflex의 /id는 in-memory atomic counter로 ID를 사용
  • 1개면 문제 없으나 2개 이상 시 각 pod가 독립적인 카운터를 갖게되어 중복 발생
  • pod 간 상태 공유를 위한 중앙 저장소 필요

6.1.1 클로드 코드에게 캐시 도구 물어보기

  • cc에게 자연어로 pod간 데이터를 어떻게 공유할 수 있을까 질문
    • redis의 오픈소스 포크인 valkey 사용권장. atomic 한 증가연산, pod재시작과 별개의 영속성, 경량

pod간 데이터를 어떻게 공유할 수 있을까

6.1.2 다른 도구는 없는지 비교해보기

  • cc에게 자연어로 다른 캐시도구들과 비교해줘 질문
    • Valkey, Redis, Memcached, DragonflyDB와의 비교
    • 라이센스(redis), 기능부족(memcached), 성숙도(Dragonfly) 등의 이유로 현재 문제에 Valkey가 최적대안

다른 캐시도구들과 비교해줘

6.1.3 Valkey 설치하고 앱 연동하기

  • cc에게 자연어로 Valkey 구성해줘 요청
    • Bitnami heml chart 기반으로 Valkey 단일 instance 구성
    • 단순 구성시 놓쳤을 리소스 문제, 구성 이후 동작확인까지 자체적 진행 완료

Valkey 구성해줘

6.2 시크릿 관리: Google Secret Manager

  • 현재 비밀번호는 k8s secret으로 관리
  • k8s secret은 base64 인코딩, 암호화가 아니므로 외부에서 관리

6.2.1 클로드 코드에게 시크릿 관리 방법 물어보기

  • cc에게 자연어로 시크릿 관리방법을 알려줘 질문
    • GKE에서 자체적으로 지원하고, SSOT로 동작할 수 있음을 근거로 GCP Secret Manager 권장

시크릿 관리방법을 알려줘

6.2.2 다른 도구는 없는지 비교해보기

  • cc에게 자연어로 다른 관리 방법과 비교 요청
    • CSI Driver + Secret Manager 외에 Sealed Secrets,External Secrets Operator, k8s secret 존재
    • Sealed Secrets은 암호화 키관리의 문제, ESO는 멀티클라우드 지원이라 현재 부적합 등의 이유로 GCP Secret Manager 권장

다른 관리 방법과 비교

6.2.3 Secret Manager 설정하기

  • cc에게 자연어로 google secret manager 구성해줘 요청
    • Secret Manager API 활성화>클러스터내 pod의 CPU 요구량 감소>WI 활성화>비밀번호 Secret Manager 저장>WI바인딩>비밀번호 볼륨 마운트하여 앱에서 사용
    • 일련의 과정을 단계별 자동으로 수행하여 구성 및 동작 테스트 완료

google secret manager 구성해줘

6.3 점진적 배포: Canary

  • 기존 Blue/Green 배포로 무중단 배포는 가능해졌지만 한번에 전환시 모든 고객에게 영향을 줌
  • Canary를 통해 일부 트래픽만 전환하여 문제 없는지 확인, 장애시 소수만 영향받고 롤백

6.3.1 클로드 코드에게 더 안전한 배포 방법 물어보기

  • cc에게 자연어로 Blue/Green 보다 더 안전한 배포 방식 질문
    • Canary 배포를 통해 일부만 노출, 리소스 효율, 동일한 rollouts에서 구성등의 이득이 있음

Blue/Green 보다 더 안전한 배포 방식

6.3.2 다른 도구는 없는지 비교해보기

  • cc에게 자연어로 Canary, Blue/Green 과 다른 방식들을 비교해줘 요청

Canary, Blue/Green 과 다른 방식들을 비교해줘

6.3.3 Canary 배포 설정하기

  • cc에게 자연어로 Canary 배포로 변경 요청

Canary 배포로 변경

  • rollout의 Events 에서 Canary 수행기록 조회

6.4 마무리: claude-context/로 현재 아키텍처 정리하기

  • 4장에서는 메모리에 로컬 작업 컨텍스트, 5장에서는 ADR로 영구 결정 기록, 6장에서는 현재 시스템 구성 상황 정리
  • cc에 claude-context/에 현재 아키텍처 상태 정리. 존재하는 컴포넌트, 연결 상태 및 설정 상태 기록 요청

claude-context/에 현재 아키텍처 상태 정리. 존재하는 컴포넌트, 연결 상태 및 설정 상태 기록

  • 클로드 코드의 3단계 지식 상태
파일역할로드 시점
CLAUDE.md항상 지켜야 할 규칙매 세션 전문 로드
.claude/memory/개별 결정의 이유와 작업 컨텍스트인덱스만 로드, 필요할 때 참조
claude-context/현재 아키텍처의 전체 그림CLAUDE.md에서 참조 시 로드
  • CLAUDE.md: 팀의 작업 스타일 문서
  • .claude/memory/: 개인의 작업 노트
  • claude-context/: 팀을 위한 시스템 현황도 (ADR포함)

6.5 6장 가드레일 살펴보기

서브챕터유형참조 파일역할
6.1 탐색/비교탐색과 비교decision-guides/ch6/6.1-cache.mdValkey 추천 + Redis/Memcached 비교
6.1 실행실행prompt-guardrails/ch6/6.1-valkey.mdHelm 설치 + 앱 연동
6.2 탐색/비교탐색과 비교decision-guides/ch6/6.2-secret-management.mdCSI Driver 추천 + Sealed Secrets 비교
6.2 실행실행prompt-guardrails/ch6/6.2-secret.mdWorkload Identity + CSI + Secret Manager
6.3 탐색/비교탐색과 비교decision-guides/ch6/6.3-canary-vs-bluegreen.mdCanary 추천 + Blue/Green 비교
6.3 실행실행prompt-guardrails/ch6/6.3-canary.mdStrategy 변경 + 점진적 배포 테스트
6장 마무리실행prompt-guardrails/ch6/6.4-architecture-context.mdclaude-context/architecture.md 신설 + 3층 지식 구조 정리
Leave A Comment