본문 바로가기

DevOps61

퍼센타일 지표(p50, p90)로 보는 성능과 모니터링 웹 서비스나 API를 운영하다 보면 “응답 시간이 평균 200ms” 같은 말을 흔히 합니다. 하지만 **평균값(mean)**만으로는 사용자 경험을 제대로 설명할 수 없습니다. 실제로는 일부 요청이 아주 느릴 수 있고, 그 극단적인 요청들이 서비스 만족도를 크게 떨어뜨리기도 합니다.이때 자주 쓰이는 지표가 바로 **퍼센타일(percentile)**입니다. 그중에서도 가장 많이 언급되는 것이 p50, p90, p95, p99입니다.1. 퍼센타일이란 무엇인가?퍼센타일은 데이터를 정렬했을 때 특정 비율에 해당하는 지점을 말합니다.p50 (50th percentile): 중앙값(median). 절반의 요청이 이 값보다 빠르고, 절반은 더 느립니다.p90 (90th percentile): 요청 중 90%는 이 값보.. 2025. 9. 24.

isito 와 cilium path 정책 차이 1.패턴 매칭 방식Cilium - 정규식 지원http:path: "/api/v[0-9]+/users/[a-zA-Z0-9-]+" # 정규식path: ".*\\.(jpg|png|gif)$" # 파일 확장자Istio - Glob 패턴만operation: paths: ["/api//users/"] # 와일드카드만정규식 지원하지 않음2. 정책 우선순위 처리Cilium - 순서대로 첫 매칭ingress:rules: http:path: "/admin" # 먼저 매칭되면 허용path: "/admin/.*" # 두 번째 규칙은 무시됨Istio - DENY > ALLOW복수 정책이 있어도 DENY가 우선ALLOW: "/admin"DENY: "/admin/*"결과: DENY 승리3.헤더 및 조건부 매칭Cilium - 정규식.. 2025. 9. 24.

istio vs cilium 정책 차이 레이어/역할Istio: 서비스 메쉬의 L7(HTTP/gRPC) 중심 접근제어 + mTLS/JWT 인증/인가. AuthorizationPolicy(ALLOW/DENY/CUSTOM/AUDIT), PeerAuthentication(mTLS), RequestAuthentication(JWT)로 앱 레벨 보안/정책을 다룸. Sidecar 모드에선 Envoy 사이드카가, Ambient에선 L4 정책은 ztunnel, L7은 waypoint가 집행한다. IstioCilium: CNI + eBPF 기반 L3/L4(커널 레벨) 정책이 기본. 확장 리소스인 CiliumNetworkPolicy/ClusterwideNetworkPolicy로 L3/L4는 eBPF로, **L7(HTTP/gRPC/Kafka/DNS)**은 노드 로.. 2025. 9. 24.

GitHub Composite Action + ArgoCD: GitOps CI/CD 파이프라인 완성하기 최근 많은 팀이 GitOps 기반 배포를 도입하면서 ArgoCD를 활용하고 있습니다. 하지만 CI 단계(빌드, 테스트, 이미지 푸시)는 여전히 GitHub Actions에서 담당하는 경우가 많습니다.이때 유용하게 활용할 수 있는 것이 Composite Action입니다. 반복적인 빌드/배포 로직을 하나로 묶어 재사용할 수 있고, ArgoCD와 결합하면 완전 자동화된 GitOps 파이프라인을 구현할 수 있습니다.1. GitHub Composite Action이란?정의: 여러 Step을 조합해 하나의 Action처럼 사용할 수 있는 GitHub Actions 기능 (using: composite).장점공통 빌드/배포 로직을 표준화리포지토리/팀 전체에서 재사용유지보수 및 관리 용이형태: .github/acti.. 2025. 9. 8.

gitops와 app of apps 가 kubernetes 운영시 필요한 이유 1. 왜 GitOps가 필요한가?일반적인 서버 운영: 개발자가 코드를 수정 → 서버에 들어가서 수동으로 설정/배포.문제: 사람이 직접 서버를 만지다 보면 설정이 달라지거나, 누가 언제 뭘 바꿨는지 추적이 안 됨.GitOps 방식: “배포와 운영의 모든 상태를 Git에 적어두고, 쿠버네티스가 자동으로 따라가게 하는 것”.즉, Git = 진실의 원천(Single Source of Truth).코드 바꾸듯이 YAML(쿠버네티스 설정)을 수정 → Git에 올리면 → 자동으로 클러스터 반영.결과: 이력 관리, 협업, 롤백이 훨씬 쉬워짐.👉 비유: “노트에 모든 요리 레시피(서버 상태)를 적어놓고, 요리사는 그 레시피만 보고 자동으로 요리를 만드는 것”.2. App of Apps가 왜 필요한가?EKS 같은 환경에.. 2025. 9. 8.

kubernetes 셀프서비스 backstage 도입여부 환경 개발자들이 yaml 안건드리고 배포할수 있는 환경을 만들고싶어서 github으로 구현할지 backstage로 할지 고민을 하고 있습니다. 다음과 같은 조건을고려해서 도입여부를결정하였습니다. 1. Backstage가 필요 없는 경우팀 규모가 작다개발자 10명 이하 + 서비스 20개 이하 온보딩은 문서(Markdown/Notion)로도 1일 이내에 충분히 가능.DevOps 병목이 크지 않다새 서비스 생길 때 DevOps 1명이 직접 Helm/CI/CD 넣어주는 게 몇 시간 안 걸린다.개발자 요청 건수가 적어서 반복 부담이 크지 않다.서비스 표준화가 이미 잘 돼 있다Template repo, reusable GitHub Actions, Helm 차트가 있어서 복붙으로도 80% 커버 가능.👉 이런 .. 2025. 9. 8.

GitHub Actions · AWS OIDC · Reusable Workflow · Terraform IaC 정리 여러 서비스 리포에서 공통으로 사용하는 Reusable Workflow를 구축하고, AWS OIDC 인증을 통해 ECR에 이미지를 푸시하도록 구성했습니다.처음에는 workflow not found / id-token: none 오류 등 삽질이 있었는데, 최종적으로 Access 설정 + Permissions + IAM Role 신뢰 정책을 Terraform으로 관리하면서 안정화했습니다.이번 글에서는 문제 원인 → 해결 방법 → Terraform 코드까지 정리합니다.1. workflow not found 오류원인서비스 레포에서 아래와 같이 호출했지만:uses: orgname/repository-ci-templates/.github/workflows/aws-ecr-deploy.yml@main GitHub에서 .. 2025. 9. 4.

Terraform에서 AWS SSM Parameter Store 활용하기 erraform으로 인프라를 관리하다 보면, 슬랙 웹훅이나 API 키처럼 민감한 값을 tfvars에 넣고 싶을 때가 많습니다.하지만 이는 보안/ISMS 측면에서 지적될 가능성이 높기 때문에, 보통은 AWS SSM Parameter Store나 Secrets Manager를 이용해 관리합니다.이번 글에서는 SSM Parameter Store를 사용하여 Terraform 코드에서 안전하게 값을 가져오는 방법을 정리했습니다.1. SSM Parameter Store에 값 저장하기먼저 Slack Webhook을 SSM에 SecureString 타입으로 저장합니다.aws ssm put-parameter \ --name "/argocd/notifications/test_slack_webhook" \ --type .. 2025. 9. 4.

ArgoCD Slack Notifications : Webhook vs Token 방식 비교 1. 들어가며ArgoCD는 GitOps 방식으로 Kubernetes 애플리케이션을 관리할 수 있는 강력한 도구입니다.하지만 운영 환경에서는 단순히 배포만 잘 된다고 끝이 아니죠. 애플리케이션의 동기화(Sync) 성공/실패 상태를 빠르게 알림으로 받아볼 수 있어야 합니다.ArgoCD는 이를 위해 Slack Notifications 기능을 제공합니다.이번 글에서는 EKS 환경에서 Slack 알림을 설정하는 방법과, 실제로 적용해본 Webhook 방식과 Token 방식의 차이점을 정리해보겠습니다.2. Webhook 방식 적용기저희는 먼저 Webhook 방식을 적용했습니다.Webhook은 Slack에서 제공하는 Incoming Webhook URL을 사용해 메시지를 보내는 방식으로, 설정이 간단하고 빠릅니다.주.. 2025. 9. 1.

EKS 환경에서 ArgoCD Notifications와 Slack 연동하기 이 글에서는 AWS EKS 클러스터 환경에서 ArgoCD Notifications를 설정하고, 애플리케이션 동기화 성공/실패 시 Slack으로 알림을 보내는 방법을 다룹니다. 공식 ArgoCD Helm 차트(v8.3.1)를 기반으로 진행했으며, 실제 환경에서 발생한 문제와 해결 과정을 정리했습니다.초기 문제 상황ArgoCD Notifications를 Slack과 연동하면서 아래와 같은 문제를 겪었습니다.argocd-notifications-cm ConfigMap에서 서비스 설정 누락Slack 알림 전송 시 "not_authed" 에러 발생Terraform으로 리소스 정의 시 metadata 블록 누락으로 검증 오류 발생Notifications Controller에서 과도한 로그 출력해결 과정1. Terr.. 2025. 9. 1.

ArgoCD 배포 시 실패한 Pod는 삭제됐는데 ReplicaSet은 남아있다? 괜찮은 걸까? 쿠버네티스 환경에서 ArgoCD로 애플리케이션을 배포하다 보면, 실패한 Pod는 삭제됐는데 ReplicaSet(RS)은 계속 남아 있는 상황을 접할 수 있습니다. 처음에는 “이거 뭔가 잘못된 거 아닌가?” 싶지만, 사실은 정상적인 동작입니다. 이번 글에서는 왜 이런 현상이 발생하는지, ReplicaSet을 어떻게 관리해야 하는지 정리해 보겠습니다.1. ReplicaSet이 남는 이유Deployment의 기본 동작 원리쿠버네티스에서 Deployment(또는 Argo Rollouts)는 직접 Pod를 생성하지 않습니다. 대신 ReplicaSet을 생성하고, ReplicaSet이 파드를 관리합니다. 따라서 파드가 실패해 삭제되더라도 ReplicaSet은 그대로 남아 있으며, 필요 시 새 파드를 다시 만들 준비.. 2025. 8. 29.

Argo CD CLI login 트러블슈팅 (ALB/Ingress, gRPC-Web, Windows) 내부 ALB(HTTP :8080) 뒤의 Argo CD에 Windows에서 CLI로 로그인하려다 context deadline exceeded 를 만난 분들을 위한 실전 메모입니다.포인트만 요약하면:CLI 플래그: --grpc-web --plaintext (+ 필요시 --skip-test-tls)Ingress 경로: /grpc, /api, / 를 Prefix로 각각 백엔드 argocd-server:80에 포워딩ALB 주석: backend-protocol-version=HTTP1, 헬스체크 /api/version서버 URL: configs.cm.url 을 외부에서 접속하는 실제 URL로프록시 우회: NO_PROXY 에 ALB 호스트 추가 배경 환경Kubernetes: v1.33Argo CD: v3.1.x (.. 2025. 8. 29.

이전 1 2 3 4 ··· 6 다음

티스토리툴바