본문 바로가기
반응형

분류 전체보기2322

Pulumi × TypeScript로 구축하는 멀티 클라우드 IaC: 진짜 ‘코드로서의 인프라’란 무엇인가 이번은 DevOps 고급 자동화 주제로, **“Pulumi + TypeScript로 작성하는 멀티 클라우드 IaC 자동화”**에 대한 실전급 가이드입니다. Terraform이 아닌 Pulumi를 활용하여, 코드 수준에서 로직 분기와 리유저블 모듈화가 가능한 구조로 멀티 클라우드 인프라를 운영하는 방법을 다룹니다. TypeScript로 작성되므로 개발자 친화적인 경험과 테스트 주도 설계(TDD)도 가능합니다.📌 왜 Pulumi인가?Terraform과 달리 Pulumi는 다음과 같은 장점으로 “개발자 관점에서” 인프라를 관리할 수 있게 해줍니다.기능 Terraform Pulumi언어 HCL (DSL) TypeScript, Go, Python, C# 등조건문 / 반복문 제한적 (count, for_each).. 2025. 5. 28.
OPA 기반 GitOps 정책 제어 파이프라인: GitHub Actions + Argo CD + Gatekeeper 완전 통합 이번엔 DevOps 고급 자동화 주제로, 실제 MSA(Microservice Architecture) 기반 SaaS에서 사용되는 **“GitHub Actions + Argo CD + Open Policy Agent (OPA)로 구현하는 정책 기반 GitOps 배포 파이프라인”**에 대한 심화 가이드입니다. 단순한 YAML 선언을 넘어서, 실무 엔지니어가 규정 준수와 보안까지 코드화하여 배포를 통제하는 방법을 중심으로 구성하였습니다.⸻⸻📌 왜 정책 기반 GitOps인가?GitOps를 적용하면 배포는 Git에서 선언적으로 관리됩니다. 하지만 다음과 같은 문제는 여전히 존재합니다:문제 설명무분별한 자원 선언 신규 서비스나 Helm 차트에서 hostNetwork: true, privileged: true 등 .. 2025. 5. 28.
AWS Lambda에 KEDA 도입하기: EventBridge 기반 Serverless Auto-Scaler 완전 자동화 🧭 문제 정의: 서버리스도 결국 ‘스케일링’이 필요하다AWS Lambda는 기본적으로 이벤트 기반 자동 스케일링이 지원됩니다. 그러나 다음과 같은 상황에서는 세밀한 제어가 어렵거나 불가능합니다.문제 상세동시 실행 제한 계정 혹은 함수당 concurrency 제약이 존재함SLA 기준 없음 응답시간, 큐 백로그 등의 SLA에 따른 스케일 제어 불가비정형 이벤트 Kafka, Redis, Custom API 트리거 처리 어려움멀티 클라우드 연동 Lambda 외 외부 리소스 연계 자동화 어려움→ 해결책: Lambda 트리거를 EventBridge로 통합하고, 외부 SLA 지표 기반으로 KEDA를 통해 스케일 제어 + 예약 확장 + 이벤트 기반 오토화 가능⸻📐 전체 아키텍처+--------------------.. 2025. 5. 28.
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.
반응형

티스토리툴바