본문 바로가기
반응형

전체 글2287

Git 커밋도 없이 배포된다: Argo CD Image Updater로 완전 자동 GitOps 구축하기 ⸻🧭 왜 GitOps의 자동화를 다시 고민해야 하는가GitOps는 인프라 및 애플리케이션 상태를 Git에 저장하고, Git의 변경이 곧 배포로 이어지는 구조입니다. 그러나 대부분의 GitOps 환경에서는 다음과 같은 병목이 존재합니다: • CI 파이프라인에서 버전 태그를 업데이트하기 위해 YAML을 수정하고 커밋해야 함 • 자동 빌드 후에도 운영자가 Git에 수동 커밋 → PR → 리뷰 → 배포 트리거즉, GitOps는 선언적이지만 실질적으로 버전 추적과 배포 간의 자동화가 단절된 구조로 운영됩니다. 이를 해결하는 핵심 툴이 Argo CD Image Updater입니다.⸻🔧 핵심 구성 요소와 흐름 요약구성 요소 설명Argo CD Kubernetes 배포 상태를 Git 기준으로 동기화Image Upda.. 2025. 5. 28.
SLA 기반 자동 스케일링 아키텍처 완전 해부: KEDA + Prometheus + OpenSLO + Slack 연동 ⸻🧭 배경과 문제의식서비스 확장이 클라우드 시대의 기본 전제가 되면서, “사용자 수에 따라 늘었다 줄었다 하는 자동 스케일링”은 누구나 구현합니다.그러나 문제는 대부분 **리소스 기반(HPA: CPU/Memory)**으로 제한되고 있으며, 다음과 같은 한계를 갖습니다. • 리소스 사용률은 “지표”이지 “서비스 품질”이 아님 • CPU 80% 이상이어도 실제 서비스는 정상이거나, 반대로 40%여도 응답 지연이 발생할 수 있음 • 진짜 기준은 “사용자가 체감하는 SLA”여야 함 (예: 평균 응답속도, 에러율, 큐 적체량)“지표가 아니라 **SLO(SLI 기반 목표)**를 기준으로 스케일링할 수는 없을까?”→ 이 문제에 정면 대응하는 것이 KEDA + Prometheus + OpenSLO 기반 SLA 중심 .. 2025. 5. 28.
쿠버네티스 기반의 실시간 장애 전파 및 자동 복구 시스템 설계: Prometheus + Alertmanager + Webhook + GitOps Rollback 통합 아키텍처🧭 배경대규모 마이크로서비스 환경에서 가장 큰 리스크는 무중단 서비스 유지입니다. 단일 컴포넌트가 장애를 일으키면 다음과 같은 연쇄 작용이 발생합니다: • 사용자 응답 지연 또는 오류 전파 • APM·Sentry 로그 증가 → 운영비용 상승 • 고객 이탈 및 SLA 위반 리스크이러한 장애 상황에서 단순 Slack 알림만 받고 사람이 개입하던 기존 방식은 한계가 있습니다.✅ 목표: “알림이 아닌 자동 조치가 우선되는 구조”⸻🔧 핵심 아키텍처 구성요소구성 요소 역할Prometheus 메트릭 수집 및 실시간 모니터링Alertmanager 경보 평가 및 라우팅Webhook Receiver 자동 복구 .. 2025. 5. 28.
GitOps로 운영되는 멀티 클러스터 환경의 CI/CD 파이프라인 아키텍처: Argo CD + Kustomize + Cluster Gateway 완전정복⸻🧭 문제 인식대기업, 글로벌 SaaS, 금융사 등에서 단일 Kubernetes 클러스터로는 지역 장애, 트래픽 분산, 조직 분리 등 다양한 요구사항을 수용할 수 없습니다. 이에 따라 멀티 클러스터 구성이 대세가 되었고, 이와 함께 GitOps 기반의 일관된 배포 전략이 필요해졌습니다.기존에는: • kubectl로 클러스터마다 수동 배포 • 클러스터 ID/네트워크/네임스페이스가 달라 YAML 재사용 어려움 • 롤백·변경 추적이 불가능하거나 매우 복잡이러한 문제는 Argo CD + Kustomize + GitOps + Cluster Gateway 기반 구조로 해결할 수 있습니다.⸻🔧 핵심 구성 요소구성 요소 역할Argo CD G.. 2025. 5. 28.
SLA 기반 리소스 자동 스케일링 시스템: KEDA + Prometheus + Custom Autoscaler의 완전한 설계 🎯 문제 인식전통적인 CPU 사용률 기반의 HPA(Horizontal Pod Autoscaler)는 서비스 수준 목표(SLO, SLA)를 만족시키기에 충분하지 않은 경우가 많습니다. 예를 들어: • 처리량은 낮지만 응답 속도가 느려지는 경우 • 큐 길이는 증가하지만 Pod 수는 그대로인 경우이러한 시나리오에서 CPU만을 기준으로 한 자동 스케일링은 효과적이지 않습니다.실리콘밸리의 실전 DevOps 팀은 이러한 문제를 SLA 기반 메트릭에 따라 동적으로 스케일링하는 구조로 해결합니다. 그 중심에는 KEDA, Prometheus, Custom Metrics Adapter가 존재합니다.⸻⚙️ 아키텍처 구성!KEDA 아키텍처이 아키텍처는 다음과 같은 흐름으로 구성됩니다: 1. 애플리케이션에서 메트릭을 Prom.. 2025. 5. 28.
무중단 데이터 마이그레이션 자동화: 온라인 스키마 변경 with gh-ost + Argo Workflows 🎯 주제 개요대규모 시스템 운영 중 가장 민감하고 위험한 작업 중 하나는 운영 중인 데이터베이스의 스키마 변경입니다.단일 ALTER TABLE도 잘못하면 서비스 전체가 멈추고, 트래픽 피크 시간대에는 쿼리 Lock으로 대란이 발생할 수 있습니다.이때 실리콘밸리의 대형 SaaS 기업들은 다음 전략을 사용합니다: • gh-ost: Lock 없이 MySQL 스키마 변경 • Argo Workflows: 선언형 데이터 마이그레이션 실행 자동화 • GitOps + Slack Notification까지 연계한 안전한 전체 파이프라인 구성⸻🧱 핵심 아키텍처 구성Git Commit (ALTER 정의) ↓Argo Workflows Job 실행 ↓gh-ost 실행 (Lock-free schema change).. 2025. 5. 28.
Helm + GitOps + SecretOps: 프로덕션 등급 Kubernetes 배포를 위한 완전체 구성 전략 🎯 주제 요약현대 DevOps에서는 단순히 YAML을 배포하는 것이 아니라, • Helm으로 템플릿화하고 • GitOps(예: Argo CD)로 상태 관리하며 • SecretOps(예: Sealed Secrets, Vault, SOPS 등)로 민감 정보 처리를 분리해야“재현성 + 보안 + 변경 추적 + 팀 협업”이 가능한 안정적인 운영 체계를 만들 수 있습니다.⸻⚙️ 핵심 구성 요소구성요소 역할Helm 파라미터화된 배포 템플릿 정의Argo CD Git 저장소 기준의 선언적 배포 및 상태 SyncBitnami Sealed Secrets / SOPS 보안 정보 Git 추적 및 복호화 연동Kustomize 환경별 overlay 적용 가능 (선택 사항)⸻🧱 실전 디렉토리 구조 예시├── charts/│ .. 2025. 5. 28.
Pact · Spring Cloud Contract · Kafka Contract 테스트 · GitHub Actions 통합 자동 계약 테스트 끝판왕 가이드:서론: 왜 계약 테스트인가 • 서비스 간 불일치 방지: REST·gRPC·메시지 큐로 연결된 마이크로서비스 간 스펙 충돌 없이 안전 보장 • 통합 테스트 비용 절감: 실제 환경 프로비저닝 없이 소비자·제공자 계약으로 상호 검증 • CI 단계 전면 통합: 계약 위반 시 PR 차단 → 배포 파이프라인 중단 • Event-Driven 환경 지원: Kafka, RabbitMQ 등 메시지 버스 계약도 자동화실리콘밸리·심천 IT기업 톱티어 팀들은 Pact(HTTP & 메시지), Spring Cloud Contract, Pact-Kafka를 결합해, 계약 정의→게시→검증→배포 전 자동화된 Contract-First 워크플로우를 설계합니다.⸻아키텍처 개관Consumer Repo .. 2025. 5. 27.
반응형

티스토리툴바