구름엔지니어만들기

[Datadog] Recovery 알람 제거 방법

miracle21 — Thu, 9 Apr 2026 12:46:33 +0900

Datadog monitor 로 알람을 추가할 때 "경고"나 "위험" 알람은 받지만 복구 알림은 받고싶지 않은 경우

알람 메세지를 조건별로 분리하면 복구 알림은 제외하고 온다.

위험 알람 예시:

{{#is_alert}}
[ALERT] 문제 발생
@slack-channel
{{/is_alert}}

경고 알람 예시:

{{#is_warning}}
[WARN] 경고 상태
@slack-channel
{{/is_warning}}

만약 복구 알림을 받아도 상관이 없다면 알람받을 채널을 분리하지 않으면 된다.

{{#is_alert}}
[ALERT] 문제 발생
{{/is_alert}}

{{#is_warning}}
[WARN] 경고 상태
{{/is_warning}}

@slack-channel

[Prometheus] GPU 서버에 HPA 설정 방법

miracle21 — Wed, 1 Apr 2026 14:20:35 +0900

1. 목적

GPU 사용률 기반 Pod AutoScaling을 구현하기 위해 메트릭 수집 및 모니터링 도구로 Prometheus와 Grafana를 선택했다.

단, 특정 GPU 서비스만 사용하기 위해서 namespace와 nodepool 설정이 추가적으로 들어간다.

2. 구성

GPU 메트릭을 수집하기 위한 Prometheus를 Kubernetes 환경에 구성하는 방식은 크게 2가지가 있다.

kube-prometheus-stack
Standalone Prometheus (Operator 미사용, 직접 prometheus.yml 관리)

수동 설정이 필요한 Standalone과 달리, kube-prometheus-stack은 지표 수집을 자동화할 수 있어서 kube-prometheus-stack 방식을 선택했다.

# kube-prometheus-stack 워크플로우
[GPU]
   ↓
[NVIDIA Driver + DCGM]              # 메트릭 추출
   ↓
dcgm-exporter (DaemonSet)           # 메트릭을 http 엔드포인트로 노출
   ↓
Service (ClusterIP)                 # 개별 exporter Pod에 대한 고정 접근 지점(IP) 제공
   ↓
ServiceMonitor (CRD)                # Prometheus에 수집할 대상을 지정
   ↓
Prometheus (Operator 관리)           # 메트릭 수집, 저장, PromQL 조회
   ↓
Prometheus Adapter                  # 데이터를 K8s Custom Metrics API 규격으로 변환
   ↓
Grafana / Alertmanager / HPA        # 시각화, 알림, 오토스케일에 활용

3. 기본 동작 구축

3-1. Helm repository 구성

NVIDIA 및 Prometheus 차트를 배포한다.

nvidia: GPU 메트릭 추출 도구인 DCGM Exporter 제공
prometheus-community: 메트릭 수집(Prometheus), 변환(Adapter) 도구 제공

helm repo add nvidia https://nvidia.github.io/gpu-operator
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update

3-2. NVIDIA DCGM Exporter 설치

노드에서 GPU 사용량 지표(DCGM_FI_DEV_GPU_UTIL)를 추출한다.

특정 namespace만 사용하는 nodepool에 대한 메트릭만 수집하기 위해서 nodeSelector 에 따로 명시를 했다.

# gpu-operator.yaml
driver:
  enabled: false

toolkit:
  enabled: false

devicePlugin:
  enabled: false

gfd:
  enabled: false

dcgmExporter:
  serviceMonitor:
    enabled: true
    additionalLabels:
      release: <서비스명>-prometheus

dcgm:
  nodeSelector:
    nodepool: <노드풀명>

operator:
  nodeSelector:
    nodepool: <노드풀명>

validator:
  nodeSelector:
    nodepool: <노드풀명>

node-feature-discovery:
  master:
    nodeSelector:
      nodepool: <노드풀명>
  gc:
    nodeSelector:
      nodepool: <노드풀명>
  worker:
    nodeSelector:
      nodepool: <노드풀명>

helm upgrade --install <서비스명>-dcgm nvidia/gpu-operator -n <네임스페이스> -f gpu-operator.yaml

3-3. Prometheus Stack 설치

수집된 데이터를 저장하고 쿼리할 수 있는 환경을 구축한다.

# prometheus-stack.yaml 
grafana:
  enabled: true

alertmanager:
  enabled: false

prometheus:
  prometheusSpec:
    serviceMonitorSelectorNilUsesHelmValues: false
    nodeSelector:
      nodepool: <노드풀명>

prometheusOperator:
  nodeSelector:
    nodepool: <노드풀명>

kube-state-metrics:
  nodeSelector:
    nodepool: <노드풀명>

prometheus-node-exporter:
  nodeSelector:
    nodepool: <노드풀명>

prometheusOperator:
  admissionWebhooks:
    patch:
      nodeSelector:
        nodepool: <노드풀명>

grafana.enabled: 그라파나를 사용하는 경우에는 true, 사용하지 않는 경우에는 false.

helm upgrade --install <서비스명>-prometheus prometheus-community/kube-prometheus-stack -n <서비스 네임스페이스> -f prometheus-stack.yaml

3-4. Prometheus Adapter 설정 및 설치

Prometheus Adapter 설정 파일을 생성(prometheus-adapter.yaml)한다.

prometheus:
  url: http://<prometheus-service-name>.<namespace>.svc.cluster.local
  port: 9090

nodeSelector:
  nodepool: <서비스 노드풀명>

rules:
  custom:
    - seriesQuery: 'DCGM_FI_DEV_GPU_UTIL{exported_pod!=""}'
      resources:
        overrides:
          exported_namespace: {resource: "namespace"}
          exported_pod: {resource: "pod"}
      name:
        matches: "DCGM_FI_DEV_GPU_UTIL"
        as: "gpu_utilization"
      metricsQuery: 'sum(<<.Series>>{<<.LabelMatchers>>}) by (<<.GroupBy>>)'

url: <prometheus-service-name>는 Helm 배포 시 생성된 Prometheus Service 이름 참고(예: <release-name>-kube-prom-prometheus)
seriesQuery: 'exported_pod' 라벨이 있는 DCGM 메트릭만 필터링하여 데이터 처리 효율 증가
resources.overrides: Prometheus의 라벨(exported_pod)을 K8s의 리소스(pod)로 매핑하여 HPA가 타겟을 인식하게 함
metricsQuery: sum(...) by (pod)를 통해 포드별 사용률을 합산하여 정확한 개별 부하 측정

Prometheus Adapter 를 설치해서, Prometheus에 저장된 지표를 Kubernetes API 서버가 이해할 수 있는 custom.metrics.k8s.io 형식으로 변환해 제공한다.

helm upgrade --install prometheus-adapter prometheus-community/prometheus-adapter -n <서비스 네임스페이스> -f prometheus-adapter.yaml

3-5. HPA 리소스 생성

HPA 파일 생성(hpa.yaml)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-<서비스명>
  namespace: <서비스 네임스페이스>
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: <서비스 deployment명>
  minReplicas: 1
  maxReplicas: 2
  metrics:
  - type: Pods
    pods:
      metric:
        name: gpu_utilization
      target:
        type: AverageValue
        averageValue: "60"

type: Pods / AverageValue: GPU는 K8s 표준 자원이 아니므로 %비율(Utilization) 대신 Prometheus가 주는 0~100 사이의 '값' 자체를 기준으로 삼음
averageValue: "60": GPU 평균 사용률이 60% 이상인 경우 Scale-out.

3-6. 검증

Custom Metrics API 지표를 확인하여 Prometheus Adapter가 데이터를 정상 변환 중인지 확인한다.

kubectl get --raw "/apis/custom.metrics.k8s.io/v1beta1/namespaces/<서비스 네임스페이스>/pods/*/gpu_utilization" | jq

위 명령 실행 시 숫자가 포함된 JSON 결과가 출력되어야 한다.

HPA 상태를 확인한다.

kubectl get hpa -n <서비스 네임스페이스>

Locust와 gRPC 연동 문제 해결(DEADLINE_EXCEEDED)

miracle21 — Sun, 1 Feb 2026 17:15:49 +0900

1. 개요

목표

Locust를 사용하여 gRPC 서비스에 대한 부하테스트 실행

Pod 구성

Locust Pod
- locustfile.py 를 통해 gRPC 호출하는 클라이언트
- my-service pod와 동일한 namespace와 image 사용
- 사용된 yaml: locust-deployment.yaml, locust-configmap.yaml
gRPC 서버
- 요청을 받는 대상 (my-service pod)

문제 상황

현상: Locust Pod에서 locustfile.py로 직접 gRPC 호출 시 DEADLINE_EXCEEDED 에러 발생(클라이언트 측 타임아웃).
특이점: Locust pod 내에서 my-service.py 스크립트는 정상 동작하나, locustfile.py는 서버 측에 로그조차 남기지 못함.

gRPC Recognize: <_MultiThreadedRendezvous of RPC that terminated with:
status = StatusCode.DEADLINE_EXCEEDED
details = "Deadline Exceeded"
debug_error_string = "UNKNOWN:Error received from peer {grpc_message:"Deadline Exceeded", grpc_status:4, ...}"

2. 원인 분석

원인
Locust(Gevent 기반)와 gRPC Python 라이브러리 간의 동시성 모델 비호환성으로 인한 충돌.

Gevent 환경에서는 모든 I/O가 Gevent 이벤트 루프에 통합되어야 함.
gRPC Python은 자체 스레드를 사용하므로 Gevent와 충돌이 발생하여 요청이 서버까지 도달하지 않음.

Locust vs gRPC Python 동작 비교

구분	Locust (Gevent 기반)	gRPC Python (스레드 기반)
동시성 모델	Gevent 라이브러리 기반	스레드 기반
작업 단위	Greenlet (코루틴)	스레드 (Thread)
동작 방식	비동기적 (작업 교차 수행)	동기적 (동시 실행)
I/O 처리	Gevent가 전체 관리	gRPC 내부 스레드가 처리

3. 해결 방안

방법 1. gRPC 호출을 subprocess로 분리

Locust 태스크 내에서 gRPC 호출을 직접 수행하지 않고, 정상 동작하는 별도의 스크립트를 subprocess로 실행.

@task
def recognize_audio(self):
    import subprocess
    result = subprocess.run(
        ["python", "/app/my-service.py", GRPC_HOST, AUDIO_FILE_PATH],
        capture_output=True, text=True
    )

방법 2. grpc.experimental.gevent.init_gevent() 사용

gRPC 채널 생성 전 호출하여 Gevent 루프와 호환되도록 설정.

import grpc.experimental.gevent
grpc.experimental.gevent.init_gevent()

4. 결론

Locust(Gevent)와 gRPC Python(스레드) 모델의 충돌이 원인이므로, 호출 로직을 별도 프로세스로 분리하거나 호환성 패치(init_gevent)를 적용하여 독립적인 네트워크 I/O 환경을 확보해야 함.

[kubernetes] 무중단배포 예시(readinessProbe)

miracle21 — Sun, 4 Jan 2026 18:56:05 +0900

전체 코드

apiVersion: apps/v1
kind: Deployment
metadata:
  name: service-deployment
  namespace: ns-service
spec:
  replicas: 20
  selector:
    matchLabels:
      app: service
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 100%
      maxUnavailable: 0
  template:
    spec:
      containers:
      - name: service
        image: <image_name>
        ports:
        - containerPort: 8080
          protocol: TCP
        readinessProbe:
          tcpSocket:
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 60
          failureThreshold: 30

무중단 배포를 위해 추가한 부분

1. strategy.rollingUpdate 추가

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 100%
      maxUnavailable: 0

maxSurge: 업데이트 중 기존 Replica 수보다 추가로 생성 가능한 Pod의 최대 수(또는 비율)을 지정
maxUnavailable: 업데이트 중 서비스 불가(Pod NotReady) 상태로 허용되는 최대 Pod 수(또는 비율)를 지정

maxSurge를 100%로 한 이유는, 20대의 pod가 하나씩 올라가고 내려가는 시간이 비효율적이라고 판단했다.

어차피 서비스가 완전히 올라가지 않으면 기존 pod 가 내려가지 않도록 maxUnavailable 를 0으로 설정했기에, 한 번에 모든 pod가 올라오도록 했다.

2. spec.containers.readinessProbe 추가

        readinessProbe:
          tcpSocket:
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 60
          failureThreshold: 30

tcpSocket.port: 지정한 포트(예: 8080)로 TCP 연결이 가능한지 확인
initialDelaySeconds: 컨테이너 시작 후 첫 Readiness 체크를 시작하기 전까지 기다리는 시간
periodSeconds: Readiness Probe를 주기적으로 실행하는 간격
failureThreshold: Probe가 연속으로 실패할 경우, 이 횟수 이상이면 Pod를 NotReady로 판단

readinessProbe는 컨테이너가 사용자 트래픽을 받을 준비가 되었는지 확인한다.

컨테이너가 정상적으로 실행 중인지 확인하는 livenessProbe랑 컨테이너 상태를 확인하는 방식이 다르다.

livenessProbe 없이 readinessProbe만 쓴 이유는, 반드시 신규 pod가 health check 가 되어야 예전 pod 가 내려가야 했기 때문이다.

컨테이너 시작 10초 후부터 60초 간격으로 8080 포트 TCP 연결을 확인하며, 30번 연속 실패 시 Pod 를 NotReady 로 판단하도록 했다. 서비스가 정상적으로 올라가는데 10~20분 정도 소요가 되기에 간격을 크게 접았다.

AWS Domain과 EKS Service DNS 간의 요청 응답 속도 비교

miracle21 — Thu, 11 Dec 2025 17:34:39 +0900

EKS 내부 서비스 간 통신 방식을 비교하기 위해 AWS Domain(ALB 경유) 방식과 EKS Service DNS(ClusterIP) 방식을 대상으로 성능 테스트를 진행했다.

일반적으로 클러스터 외부(ALB)로 나가는 것보다 내부 DNS(Service) 경로가 더 빠를 것이라고 예상할 수 있지만, 실제 결과는 반대였다.

구분	테스트 유저 수	테스트 시간	총 요청 수	요청률 (req/s)
ALB	20	120초	228	1.90
ALB	20	120초	229	1.92
DNS	20	120초	218	1.84
DNS	20	120초	219	1.83

1) 평균 응답 시간
EKS Service DNS는 ALB 대비 약 380~500ms 느림

2) 최대 응답 시간(Max)
EKS DNS 경로는 ALB 대비 최대 3,000ms 이상 지연 발생

3) 요청 처리량(req/s)
EKS DNS: 1.83 ~ 1.84 req/s

테스트 결과를 분석해보면,

ALB가 응답 속도·안정성 모두에서 더 우수한 성능을 보였다.
최대 응답 시간(Max) 차이가 큰 것으로 보아, 레이지 요청 처리나 내부 네트워크 큐잉에서 더 큰 지연이 발생한 것으로 추정된다.
EKS DNS는 클러스터 내부 DNS 라우팅을 거치며, 이 과정에서 추가적인 네트워크 홉과 큐잉 지연이 발생할 수 있다.

결론적으로는 EKS 내부 서비스 간 통신에서 단순히 내부 DNS가 더 빠를 것이라고 기대하기 어려웠다.

오히려 ALB(도메인 경유) 방식이 응답 속도와 안정성 모두에서 더 우수하게 나타났다.

이를 통해 서비스 환경마다 네트워크 구조와 트래픽 패턴이 다를 수 있으므로, 실제 환경에서 직접 테스트를 통해 최적의 통신 방식을 검증하는 것이 중요하다는 점을 느낄 수 있었다.

항목	ALB	EKS DNS
네트워크 경로	VPC 내부 ENI를 통해 서비스 파드에 직접 연결	CoreDNS → 서비스 IP → kube-proxy → 파드
요청 분산 방식	AWS ALB의 최적화된 로드 밸런싱	iptables 기반 Round-Robin(kube-proxy)
병목 및 큐잉 가능성	낮음	CoreDNS, iptables, 큐잉 등 병목 및 레이턴시 증가 가능성
최대 응답 시간 차이	비교적 낮게 유지 (레이지 요청 영향 적음)	레이지 요청 및 경로 지연 영향으로 Max latency 증가 가능
응답 속도 및 안정성	전반적으로 빠르고 안정적, 지연 최소화	내부 DNS 라우팅 영향으로 ALB 대비 느리고 변동성 있음

[Kubernetes] RBAC 설정

miracle21 — Fri, 5 Dec 2025 15:16:34 +0900

개념

K8s(Kubernetes)는 RBAC(Role-Based Access Control)을 통해 사용자(User) 또는 서비스 계정(ServiceAccount)에 리소스 접근 권한을 부여한다.

권한 구성

K8s 권한은 아래 3가지 원칙으로 구성한다.

최소 권한 원칙(Principle of Least Privilege) 적용
- 필요 최소한의 권한만 부여
- 모든 권한을 admin으로 주지 않도록 주의
네임스페이스별 격리
- 프로젝트나 서비스별로 네임스페이스를 분리하고 Role/RoleBinding으로 관리
서비스 계정 사용 권장
- 사람 계정(User) 보다는 서비스 계정(ServiceAccount)으로 권한 부여
- Pod가 권한을 사용해야 하는 경우 서비스 계정 연동

구성 원칙에 따라 네임스페이스 또는 클러스터 단위로 설정이 가능하다.

1. 네임스페이스 단위로 권한 부여

적용 범위: 특정 네임스페이스 내부 리소스에만 권한을 부여
사용 목적: 팀별 권한 분리, 환경별 접근 제한
주요 리소스 예시:
- Pods, Services, ConfigMaps, Secrets, Deployments, StatefulSets 등 네임스페이스 단위 리소스
주요 오브젝트:
- Role: 특정 네임스페이스 내 리소스에 대한 권한을 정의
- RoleBinding: Role을 사용자/서비스 계정에 연결 (네임스페이스 단위)
사용 사례:
- 개발팀에게 dev 네임스페이스 내 Pods와 ConfigMaps를 수정할 권한만 부여
- QA팀에게 qa 네임스페이스 내만 접근 가능하도록 제한
- 서비스 계정별 세밀한 권한 제어 가능 (예: 특정 애플리케이션만 ConfigMap 읽기 권한)

2. 클러스터 단위로 권한 부여

적용 범위: 클러스터 전체 또는 여러 네임스페이스에 걸친 권한 부여
사용 목적: 클러스터 관리, 모니터링/로깅, 전체 리소스 접근이 필요한 서비스 계정 설정
주요 리소스 예시:
- Nodes, PersistentVolumes, Namespaces, ClusterRoles 와 같은 클러스터 단위 리소스
- 네임스페이스 포함 가능: 모든 네임스페이스의 Pods, Deployments 등
주요 오브젝트:
- ClusterRole: 클러스터 전체 리소스 또는 특정 네임스페이스 포함 권한을 정의
- ClusterRoleBinding: ClusterRole을 사용자/서비스 계정에 연결 (클러스터 단위)
사용 사례:
- 클러스터 관리자가 모든 네임스페이스에서 리소스를 생성/삭제/조회 가능하도록 설정
- 모니터링 툴(prometheus 등)이 모든 네임스페이스의 Pod 상태를 조회하도록 설정
- CSI 드라이버가 모든 PersistentVolume을 관리할 수 있도록 설정

Helm 차트로 필요한 권한 확인하는 방법

$ helm template <release> <chart.tgz> -f <values.yaml> -n <namespace> > <output.yaml>

helm template : Helm Chart를 실제 클러스터에 적용하지 않고 YAML로 렌더링
<release> : 임의로 지정하는 release 이름
<chart.tgz> : 렌더링할 Helm Chart 패키지
-f <values.yaml> : 기본값을 덮어쓸 사용자 지정 values 파일
-n <namespace> : 리소스 네임스페이스 지정

예시:

$ helm template test krypton-4.16.0-gl1302195.tgz -f QA/zlm-MYS.yaml -n ns-krypton > test.yaml
$ cat test.yaml | grep -E "kind:|apiVersion:"

apiVersion: v1
kind: Secret
apiVersion: v1
kind: Secret
kind: ConfigMap
apiVersion: v1
kind: ConfigMap
apiVersion: v1
apiVersion: v1
kind: PersistentVolume
apiVersion: v1
kind: PersistentVolumeClaim
apiVersion: v1
kind: Service
apiVersion: apps/v1
kind: Deployment

=> secret, configmap, pv, pvc, service, deployment 관련 권한 필요.

권한 설정 예시

1. Role & RoleBinding

Role 생성 → ns-infra 네임스페이스에서 Pod를 조회, 생성, 삭제할 수 있는 권한 정의

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: ns-infra
  name: pod-manager
rules:
  - apiGroups: [""]
    resources: ["pods"]                                       # 파드
    verbs: ["get", "list", "watch", "create", "delete"]       # 조회, 생성, 삭제

+ Role 을 생성하지 않고 기본 ClusterRole을 사용해도 된다.

기본 ClusterRole

권한 수준	ClusterRole	범위	설명
최상위	cluster-admin	클러스터	모든 리소스, 모든 네임스페이스, 모든 동작 가능. 사실상 루트 권한.
네임스페이스 관리 가능	admin	네임스페이스	네임스페이스 내 대부분의 리소스 관리 가능(배포, 서비스, 시크릿 등). RoleBinding 생성 가능. 단, 네임스페이스 외 리소스에는 권한 없음.
읽기/쓰기 제한	edit	네임스페이스	네임스페이스 내 대부분 리소스 생성/수정 가능. RoleBinding 생성은 불가.
읽기 전용	view	네임스페이스	리소스 조회 가능(get, list, watch). 생성/수정/삭제 불가.
시스템용 최소 권한	system:discovery	클러스터	API 리소스 조회 가능. (kubectl api-resources 등에서 사용)
시스템용 제한 권한	system:basic-user	네임스페이스	로그인한 사용자에게 기본 조회 권한 제공

RoleBinding 생성 → 네임스페이스 ns-infra 내 서비스 계정 infra-sa에 Pod 관리 권한 부여

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-manager-binding
  namespace: ns-infra
roleRef:
  kind: Role
  name: pod-manager                          # ClusterRole 이름
  apiGroup: rbac.authorization.k8s.io
subjects:
  - kind: ServiceAccount                     # ServiceAccount 에 권한 부여
    name: infra-sa
    namespace: ns-infra                      # ServiceAccount는 namespace 명시 필요

+기본 ClusterRole을 사용하는 경우에는 ,roleRef.name에 ClusterRole 이름을 적으면 된다. (예: admin)

2. ClusterRole & ClusterRoleBinding

ClusterRole 생성 → 클러스터 전체에서 pods, services, nodes를 읽기 전용 권한 부여

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole                                 # 클러스터 전체 권한 정의
metadata:
  name: read-only-cluster
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "nodes"]
    verbs: ["get", "list", "watch"]                # 읽기 전용

ClusterRoleBinding 생성 → 1번에서 만든 ClusterRole을 특정 사용자에게 부여

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding                            # 클러스터 전체 권한 부여
metadata:
  name: read-only-cluster-binding
roleRef:
  kind: ClusterRole
  name: read-only-cluster                            # ClusterRole 이름
  apiGroup: rbac.authorization.k8s.io
subjects:
  - kind: User                                       # 사용자에게 권한 부여
    name: jane.doe@example.com
    apiGroup: rbac.authorization.k8s.io

테스트

배포 후 kubectl auth can-i 명령어로 특정 사용자/서비스 계정이 특정 리소스에 대해 특정 작업을 수행할 수 있는지 확인한다.

$ kubectl auth can-i <verb> <resource> [--namespace=<namespace>] [--as=<user>] [--list]

<verb>: 수행할 동작
- 예: get, list, watch, create, update, delete
<resource>: 리소스 종류
- 예: pods, deployments, configmaps
--namespace: 네임스페이스 단위 권한 확인 시 지정
--as: 다른 사용자/서비스 계정 권한으로 확인
--list: 해당 사용자/서비스 계정이 수행할 수 있는 모든 작업을 출력

특정 네임스페이스에 대한 모든 권한을 확인하는 방법:

$ kubectl auth can-i --list --namespace=<네임스페이스>

결과 예시:

Resources           Non-Resource URLs     Resource Names     Verbs
-----               -----------------     --------------     -----
pods                []                    []                  [get list watch create delete]
deployments.apps    []                    []                  [get list watch create update patch delete]
configmaps          []                    []                  [get list watch create update delete]

컬럼	의미
Resources	권한이 적용되는 리소스 종류 (pods, deployments.apps 등)
Non-Resource URLs	API 서버 경로(URL) 권한. (예: /healthz, /metrics)
Resource Names	특정 리소스 이름에만 적용되는 권한. 비워두면 네임스페이스 내 모든 리소스 대상
Verbs	허용되는 동작. (예: get, list, watch, create, update, delete, patch, *(모든동작허용))

[Signoz] Signoz 란?

miracle21 — Mon, 17 Nov 2025 10:54:48 +0900

개요

Signoz는 하나의 플랫폼에서 애플리케이션의 성능 모니터링(APM)과 로그, 트레이스를 통합하여 관찰 가능성을 제공하는 도구다.

복잡한 MSA(MicroService Architecture) 환경에서

1. 분리된 모니터링 툴로 인해 근본 원인 분석 지연.

2. 높은 상용 SaaS 비용과 벤더 종속성 문제 발생.

에 대한 해결책으로, 이러한 파편화된 관측 환경을 통합하고 성능 및 비용 효율성을 높이기 위해 만들어졌다.

SigNoz는 OpenTelemetry 네이티브 설계, ClickHouse 기반 단일 저장소를 기존 도구들의 차별점으로 삼는다.

특징	SigNoz	기존 도구 (Prometheus/Jaeger/Loki 조합)
OTel 네이티브	처음부터 내장 (벤더 종속성 제로)	OTel 통합 모델을 중심으로 구축되지 않음
통합 플랫폼	메트릭 + 트레이스 + 로그 (단일 UI/저장소)	개별 도구 및 분리된 저장소
데이터베이스	ClickHouse (컬럼형 OLAP)	Elasticsearch, Prometheus, Loki 등 이질적 저장소
상관관계	신호 간 네이티브 연결 (원클릭 전환)	수동 연결 필요 / 제한적

1) OpenTelemetry 네이티브 설계: 벤더 종속성 제로

OTel 표준 기반이라 독점 에이전트가 필요 없음
계측(Instrumentation)은 한 번만 하면 되고, 백엔드는 Datadog 등 OTel 지원 백엔드로 쉽게 갈아탈 수 있음

2) ClickHouse: 성능 & 비용 혁신

Elasticsearch 대비 로그 수집 속도 2.5배, 집계 쿼리 13배 빠름
컬럼형 저장 방식이라 압축률이 높고 스토리지 비용이 낮음
고카디널리티 데이터도 효율적으로 처리함

3) 통합 관측성 & 상관관계

메트릭/트레이스/로그가 모두 ClickHouse 하나에 저장됨
메트릭에서 이상 징후 확인 → 원클릭으로 해당 시간대의 트레이스 → 관련 로그로 이어지는 흐름이 자연스러움

4) 비용 모델 및 경제성

라이선스 비용이 없어서 상용 SaaS 대비 확실히 저렴함
단, ClickHouse를 직접 운영해야 하므로 운영 복잡성이 생김

SigNoz 구성요소

1. APM (Application Performance Monitoring)

APM은 애플리케이션의 성능 문제를 감지, 진단하고 사용자 경험을 보장하기 위한 모든 활동이다.

현대의 APM은 단순한 Health check를 넘어서, '왜 느린가?', '어떤 사용자가 영향을 받았는가?'를 추적하며, 관측 가능성(Observability)의 3요소를 기반으로 한다.

신호	역할	문제 해결
Metrics	징후 감지	언제 문제가 발생했는가? (ex. CPU 90%)
Traces	위치 식별	어디서 병목이 발생했는가? (ex. A->B 호출 5초)
Logs	원인 파악	왜 문제가 발생했는가? (ex. NullPointerException)

APM 툴은 이 세 가지 데이터를 수집하고, 서로 유기적으로 연관시켜 문제 해결 시간을 단축시킨다.

2. OTel (OpenTelemetry)

OpenTelemetry(OTel)는 로그, 메트릭, 트레이스 데이터를 생성, 수집, 전송하는 방식을 표준화하는 오픈소스 프레임워크다.

목적:

벤더 종속성(Vendor Lock-in) 해결
OTel 표준에 맞춰 한 번만 계측(Instrumentation)하면, 백엔드를 SigNoz, Datadog, Jaeger 등 원하는 툴로 자유롭게 변경 가능.

주요 구성 요소:

API & SDK: 애플리케이션 코드에 설치되어 데이터를 생성하는 라이브러리
Collector: 모든 데이터를 수신하는 관문(Gateway). 데이터 필터링, 가공, 샘플링 후 백엔드로 전송.
OTLP: OTel 컴포넌트 간 표준 통신 프로토콜.

3. ClickHouse

ClickHouse는 실시간 분석(OLAP)을 위해 설계된 오픈소스 컬럼 기반(Columnar) DBMS다.

역할:

수십억 건의 행을 몇 초 만에 처리하는 압도적인 성능으로 APM 데이터(로그, 메트릭, 트레이스)를 저장하고 실시간 집계/분석한다.

주요 차이점 (저장 방식):

RDBMS (MySQL 등): 행(Row) 기반. 트랜잭션(OLTP) 처리에 최적화. (예: 사용자 ID 1001의 모든 정보)
ClickHouse: 열(Column) 기반. 분석(OLAP)에 최적화. (예: 모든 사용자의 '응답 시간' 열만 읽음)

컬럼 기반의 장점:

속도: 분석에 필요한 열만 읽어 디스크 I/O를 획기적으로 줄입니다.
비용: 동일 타입 데이터가 연속 저장되어 압축률이 매우 높아(Elasticsearch 대비) 스토리지 비용이 절감됩니다.

신호	역할	문제 해결
Metrics	징후 감지	언제 문제가 발생했는가? (ex. CPU 90%)
Traces	위치 식별	어디서 병목이 발생했는가? (ex. A->B 호출 5초)
Logs	원인 파악	왜 문제가 발생했는가? (ex. NullPointerException)

데이터베이스 구조 유형 비교 ▼

데이터베이스 구조 유형 비교

구조	대표 시스템	저장 방식	기능
컬럼 기반 저장소 (Columnar)	ClickHouse \(OLAP)	데이터를 열(Column) 단위로 저장	대규모 데이터 분석/집계(GROUP BY, SUM), 높은 데이터 압축률
행 기반 저장소 (Row-Oriented)	MySQL, PostgreSQL (OLTP)	데이터를 행(Row) 단위로 저장	트랜잭션 처리(OLTP), 빠른 데이터 삽입/수정, 정형화된 데이터 관리
역 인덱스 구조	Elasticsearch	문서의 단어를 추출하여 "단어 → 문서 목록" 형태로 색인	전문(Full-text) 검색, 텍스트 기반 필터링 및 로그 탐색
키-값 저장소 (Key-Value)	Redis, DynamoDB	데이터 고유 키와 값(Key-Value) 쌍으로 저장	매우 빠른 읽기/쓰기, 캐싱, 세션 관리
문서 저장소 (Document)	MongoDB, Couchbase	데이터를 JSON 형태의 문서로 저장	구조가 유연(스키마리스), 복잡한 계층 구조 저장
그래프 저장소 (Graph)	Neo4j	데이터를 노드와 에지(관계) 형태로 저장	복잡한 관계 및 연결 패턴 분석, 소셜 네트워크, 추천 시스템
시계열 저장소 (Time-Series)	Prometheus, InfluxDB	데이터를 시간 순서대로 저장하고 인덱싱	시간 기반 추세 분석, 지속적으로 발생하는 메트릭 데이터 기록/집계

시스템 아키텍처 및 워크플로우

SigNoz는 OTel 표준을 기반으로 데이터를 수집, 처리, 저장, 시각화한다.

[애플리케이션 (OTel SDK)] → [SigNoz Collector] → [ClickHouse] → [SigNoz Backend] → [Web UI]

단계	구성 요소	역할
데이터 생성	App (OTel SDK)	애플리케이션 내에서 Metrics, Traces, Logs 데이터를 OTLP 표준으로 생성 및 전송.
데이터 수집	OTEL Agent	생성된 데이터를 가장 가까운 OTEL Collector (Agent 모드)로 내보냄.
수집 및 처리	OTel Collector	(관문 역할) 데이터 수신, 필터링, 샘플링(비용 제어), 일괄 처리(Batching) 수행.
데이터 저장	ClickHouse	Collector로부터 받은 모든 데이터(M/T/L)를 단일 저장소에 컬럼 기반으로 저장.
클러스터 관리	Zookeeper	(HA 구성 시) ClickHouse 클러스터의 분산 구성 및 데이터 복제 일관성을 관리.
조회 및 시각화	Query Service (Backend)	ClickHouse에서 데이터를 조회하여 API로 제공.
경고 및 알림	Alert Manager	임계값 초과 시 알림 생성 (Slack, Email 연동).
사용자	Web UI (Frontend)	API 데이터를 받아 대시보드로 시각화.

[Docker] Java 프로젝트를 Docker 이미지로 빌드하기

miracle21 — Mon, 13 Oct 2025 10:41:09 +0900

AWS EC2로 운영중이던 java 서비스를 EKS 로 전환해야하는 일이 있었다.

Maven 등의 빌드 도구가 필요한 java 서비스는 도커 이미지로 빌드하고 실행 환경을 만들면

빌드 환경과 서비스 실행 환경을 분리할 수가 있어서, Maven, JDK, 빌드 캐시 등의 불필요한 산출물들이 남지 않는다.

# 1단계: 빌드 환경 (Maven)
FROM maven:3.8.6-amazoncorretto-8 AS builder
WORKDIR /build
COPY service /build
RUN mvn clean package

# 2단계: 실행 환경 (Amazon Linux)
FROM amazonlinux:2 AS base
RUN yum update -y && \
    yum install -y java-1.8.0-openjdk && \
    yum clean all

# 3단계: 빌드 결과물만 복사해서 실행
COPY --from=builder /build/target/*.jar /app/app.jar
WORKDIR /app
CMD ["java", "-jar", "app.jar"]

위 코드처럼 첫 이미지는 빌드용 환경을 만들어서 jar 파일 빌드를 하고(AWS 환경에 최적화된 amazoncorretto 선택)

마지막 이미지는 실제 실행환경으로 사용할 베이스 이미지를 만들어서 빌드한 파일만 복사할 수 있다.

[Kubernetes] Fluentbit 로그 수집 방법(Sidecar vs DaemonSet)

miracle21 — Tue, 16 Sep 2025 16:20:56 +0900

EKS에서 fluentbit를 sidecar로 띄울때와 daemonset으로 띄울때의 설정을 다르게 줘야한다.

sidecar는 pod name을 바로 가져올 수 있지만, daemonset 은 기본적으로 노드 이름을 가져와서 설정을 따로 더 해줘야한다.

[sidecar] fluentbit-configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: fluentbit-config
  namespace: ns-app
data:
  fluent-bit.conf: |
    [SERVICE]
        Flush                     1
        Grace                     30
        Log_Level                 trace
        Daemon                    off

    [INPUT]
        Name                tail
        Log_Level           trace
        Path                /app.log
        Tag                 ${POD_NAME}
        Skip_Long_Lines     Off
        Refresh_Interval    10
        Read_from_Head      True
        DB                  /app.db

    [OUTPUT]
        Name                cloudwatch_logs
        Match               *
        region              ap-northeast-2
        log_group_name      /app
        log_stream_prefix   log-
        auto_create_group   true
        log_key             log

    [FILTER]
        Name                aws
        Match               ${POD_NAME}
        imds_version        v1

[daemonset] fluentbit-configmap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: fluentbit-config
  namespace: ns-app
data:
  fluent-bit.conf: |
    [SERVICE]
        Flush                     1
        Grace                     30
        Log_Level                 trace
        Daemon                    off

    [INPUT]
        Name                tail
        Log_Level           trace
        Path                /app.log
        Tag                 *
        Skip_Long_Lines     Off
        Refresh_Interval    10
        Read_from_Head      True
        DB                  /app.db

    [OUTPUT]
        Name                cloudwatch_logs
        Match               *
        region              ap-northeast-2
        log_group_name      /app
        log_stream_name     ${kubernetes['pod_name']}
        log_stream_prefix   log-
        auto_create_group   true
        log_key             log

    [FILTER]
        Name                aws
        Match               *
        imds_version        v1

    [FILTER]
        Name                kubernetes
        Match               *
        Kube_URL            https://kubernetes.default.svc:443

deployment는 sidecar나 daemonset이나 차이가 없다.

단, 볼륨 설정은 sidecar는 emptydir 로, daemonset은 hostpath 로 해야한다.

DaemonSet: 노드 로그를 수집하려면 Pod가 호스트 파일 시스템에 접근해야 하므로 hostpath 를 사용해야 함(emptydir 불가)
Sidecar: Pod 내부 로그를 수집하기 때문에 emptydir을 공유해서 로그를 전달

+ ${kubernetes['pod_name']} 으로 pod 이름을 가져오려면 RBAC 설정을 해야하는것 같다. 권한이 없어서 임시로 로그 이름에 pod 이름이 아예 추가가 되도록 설정하고, 로그파일 이름을 로그스트림 이름으로 가져가도록 했다. Daemonset 설정에서 어떤게 불필요한 코드인지 검증해보고 싶은데 기회가 되면 다시 수정할 예정이다.

host_name=$(hostname -f)
logfile="/logs/${host_name}-$(date +'%Y%m%d%H').log"

[Kubernetes] HPA 설정 커스터마이징(hpa behavior)

miracle21 — Thu, 7 Aug 2025 17:24:45 +0900

HPA(Horizontal Pod Autoscale)

CPU나 메모리 사용률을 기준으로 자동으로 파드 수를 조절할 수 있게 해주는 기능.

autoscaling/v1 과 autoscaling/v2 가 있는데,

autoscaling/v1 는 기본적인 CPU와 메모리 사용률 기준으로만 세팅이 가능하고 별다른 커스텀이 불가능하다.

다양한 메트릭 종류 및 스케일 인/아웃의 속도, 빈도, 조건에 대한 세밀한 조정이 필요하다면 v2를 사용해야한다.

항목	autoscaling/v1	autoscaling/v2
지원 메트릭 종류	리소스 (CPU, 메모리)	리소스 (CPU, 메모리) external 메트릭 (ALB 요청 수 등 클러스터 외부 메트릭) object 메트릭 (클러스터 내부 메트릭)
여러 메트릭 동시 지원	X	O

v2는 다양한 메트릭을 지원하지만, 기본으로 제공하는 CPU와 Memory 외에는

promethus나 datadog같은 메트릭 수집 도구가 있어야 사용 가능하다.

예를 들어, Datadog으로 AWS target group에 대한 request 수 대비 pod 스케일아웃/인을 하려면

timeseries 개수 대비 비용이 발생하므로 비용적인 측면도 고려해야한다.
(2개의 target group에 대한 request 수를 수집하려면 timeseries 가 2개로 계산됨)

기본 Scale In, Scale Out 동작 원리

아래와 같이 커스텀이 들어가지 않은 일반적인 HPA의 경우

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-test
  namespace: ns-test
spec:
  maxReplicas: 80
  minReplicas: 40
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: test-deployment
  targetCPUUtilizationPercentage: 70

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-test
  namespace: ns-test
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: test-deployment
  minReplicas: 2
  maxReplicas: 4
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60

스케일인/아웃은 기본 동작을 따른다.

	scaleUp	scaleDown
적용 대기 시간	없음	300초(5분)
감소/증가량 제한	없음	없음
평가 주기	약 15초	약 15초

1. Scale out

desiredReplicas(목표 파드 수) = 현재 파드 수 × 현재 리소스 사용률 ÷ 목표 사용률

예를 들어 현재 CPU 사용률이 150%고, CPU 사용률이 50%가 넘는 경우 스케일 아웃되도록 설정했다.

현재 파드수가 5라면,

5 × 150 ÷ 50 = 15

15대로 증가하게 된다.

즉, 스케일아웃은 기본적으로 5분 동안의 desiredReplicas 중에서, 가장 큰 값으로 파드 수를 감소시킨다.
(예: 5분간 desiredReplicas 가 5~8개를 왔다갔다 한다면 그 중에서 가장 큰 값인 8대로 감소)

2. Scale in

desiredReplicas(목표 파드 수) = 현재 파드 수 × 현재 평균 리소스 사용률 ÷ 목표 사용률

예를 들어 현재 평균 CPU 사용률이 35%고, CPU 사용률 기준이 70%인 경우, 현재 파드수가 10이라면,

10 × 35 / 70 = 5

파드 5대로 줄어든다.

기본적으로 5분간 리소스가 지속적으로 낮아야 스케일인이 된다.

즉, 스케일인은 기본적으로 15초마다 메트릭을 확인해서 desiredReplicas 에 맞는 파드 수로 증가시킨다.
(예: 체크할 때 당시의 desiredReplicas 에 맞게 증가)

세부적인 설정 커스터마이징

v2 기준 behavior 필드로 스케일 업/다운의 속도를 제어할 수 있다

예를들어,

1. test-deployment 의 cpu 평균 사용률 70% 초과 시 스케일 아웃

2. test-deployment 의 memory 평균 사용률 70% 초과 시 스케일 아웃

하는 HPA가 있다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa
  namespace: ns-test
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: test-deployment
  minReplicas: 10
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 70

여기서 스케일인/아웃 속도, 빈도, 조건에 대한 설정 추가를 할수있다(behavior 필드 추가).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa
  namespace: ns-test
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: test-deployment
  minReplicas: 10
  maxReplicas: 20
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 300       # 5분간 리소스 초과를 유지해야 스케일업
      policies:
        - type: Percent
          value: 50                         # 한 번에 현재 파드 수의 50% 증가 가능
          periodSeconds: 60                 # 60초마다 한 번 적용
        - type: Pods
          value: 4                          # 한 번에 최대 4개 증가
          periodSeconds: 60                 # 60초마다 한 번 적용
      selectPolicy: Max                     # Percent와 Pods 중 더 큰 쪽 적용
    scaleDown:
      stabilizationWindowSeconds: 600       # 10분 동안 기준 이하 유지돼야 스케일인
      policies:
        - type: Percent
          value: 25                         # 한 번에 25% 이하로만 감소
          periodSeconds: 60                 # 60초에 한 번 평가