[k8s] OpenShift 비용 최적화: 실제 청구서와 예상 비용 불일치 분석

OpenShift 비용 최적화: 실제 청구서와 예상 비용 불일치 분석

안녕하세요, 13년차 서버실 지킴이입니다. 오늘은 OpenShift 비용 최적화라는, 생각해보면 모든 인프라 엔지니어들의 영원한 숙제 같은 이야기를 해볼까 합니다. 특히 클라우드 환경에서 OpenShift(오픈시프트)를 운영하시는 분들이라면, 매달 날아오는 청구서를 보고 한숨 쉬어본 경험, 분명 있으실 거예요. 저도 그랬거든요.

처음 OpenShift를 도입하고 예상 비용을 산정했을 때와, 실제로 청구서에 찍힌 금액을 받아봤을 때의 그 괴리감이란... 😅 이건 마치 홈랩에 새 장비를 들여놓고 전력 소비량을 예상했는데, 막상 한 달 전기요금 고지서를 보고 깜짝 놀라는 것과 비슷하죠. 오늘은 제가 직접 겪었던 OpenShift 비용 불일치 삽질 경험을 솔직하게 공유하고, 어떻게 이 문제를 해결해나갔는지 그 과정을 보여드리려고 합니다. 클라우드 비용 관리, 특히 Kubernetes 비용과 OpenShift 청구서 분석에 관심 있으신 분들이라면 끝까지 읽어주세요!

OpenShift 클라우드 환경 아키텍처 다이어그램: 복잡하게 얽힌 구성 요소와 각 영역에서 발생하는 비용 흐름을 한눈에.

OpenShift 비용, 왜 그렇게 복잡할까요?

사실 OpenShift는 Kubernetes(쿠버네티스)를 기반으로 하는 엔터프라이즈 컨테이너 플랫폼이에요. 단순히 VM(가상 머신) 몇 대 돌리는 것과는 차원이 다르게 복잡한 비용 구조를 가지고 있더라고요. 크게 보면 몇 가지 축으로 나눌 수 있습니다.

• 라이선스 (Subscription): Red Hat OpenShift 자체에 대한 라이선스 비용이에요. 보통 코어(Core) 수나 노드(Node) 수에 따라 책정되죠.
• 인프라 (Infrastructure): OpenShift 클러스터가 올라가는 클라우드 자원 비용입니다. 이게 사실 가장 예측하기 어려운 부분 중 하나더라고요.
  • 컴퓨트 (Compute): Control Plane(컨트롤 플레인) 노드와 Worker Node(워커 노드)의 CPU, Memory 사용량에 따른 비용이에요.
  • 스토리지 (Storage): Persistent Volume(영구 볼륨)과 같은 데이터 저장 공간 비용. IOPS(초당 입출력 작업 수)나 용량에 따라 가격이 천차만별이더라고요.
  • 네트워크 (Network): 클러스터 내부 및 외부와의 통신에 사용되는 데이터 전송 비용인데, 특히 Egress(외부 송신 트래픽)가 주범입니다.
• 부가 서비스 (Add-on Services): 클라우드 제공사의 로드밸런서(Load Balancer), 관리형 데이터베이스(Managed Database), 모니터링 도구 등 OpenShift와 연동되는 다양한 서비스 비용이에요.

이 모든 요소들이 유기적으로 연결되어 있어서, 한두 가지만 보고 비용을 예측하기가 정말 어렵더라고요. 특히 클라우드 환경에서는 사용량에 따라 실시간으로 요금이 변동되니, Kubernetes 비용 예측이 더욱 까다로울 수밖에 없어요.

실제 청구서와 예상 비용, 어디서 어긋났나? 삽질 경험담

제가 운영하는 OpenShift 클러스터에서 OpenShift 청구서를 받아보고 '어라?' 했던 몇 가지 사례를 공유해볼게요.

사례 1: 스토리지 비용 예상치 못한 증가

처음엔 Persistent Volume Claim (PVC, 영구 볼륨 요청)을 만들 때 '넉넉하게' 요청해두는 게 좋다고 생각했어요. 나중에 부족해서 확장하는 것보다야 낫다고 봤거든요. 예를 들어, 10GB만 필요한데 100GB짜리 PVC를 요청하는 식이었어요.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-app-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi # 넉넉하게 100GB 요청
  storageClassName: standard-ssd

근데 이걸 모든 애플리케이션에 적용하다 보니, 실제 사용량은 10%도 안 되는데 청구서에는 100% 용량에 대한 비용이 꼬박꼬박 붙고 있었어요. 당황하지 않을 수 없었습니다. 😱 게다가 자동으로 생성되는 스냅샷(Snapshot) 정책을 제대로 관리하지 못해서, 불필요한 스냅샷들이 쌓여 용량을 잡아먹고 있었더라고요.

사례 2: 네트워크 비용, 무시무시한 Egress!

클라우드에서 네트워크 비용의 주범은 항상 Egress(외부 송신 트래픽)예요. 내부에서 아무리 데이터를 주고받아도 비용이 거의 발생하지 않지만, 클러스터 외부로 나가는 데이터는 칼같이 요금이 매겨지죠. 저희 시스템에서는 특정 서비스가 외부 API와 통신하는 양이 많았는데, 이걸 간과했어요.

또 하나는 불필요한 Ingress(인그레스, 외부 트래픽 진입점) 라우팅이었어요. 특정 PoC(개념 증명) 환경에서 불필요하게 외부로 노출된 서비스가 있었고, 여기에 공격성 트래픽이나 스캐닝 트래픽이 유입되면서 Egress가 발생했던 경우도 있었어요. 아, 진짜 머리 아프더라고요. 😫

사례 3: 컴퓨트 자원, 워커 노드 스케일링의 오해

처음에는 '오토스케일링(Autoscaling)이 알아서 잘 해주겠지!' 하는 막연한 기대를 했었어요. 하지만 OpenShift의 Cluster Autoscaler(클러스터 오토스케일러)나 Horizontal Pod Autoscaler(수평 Pod 오토스케일러)를 제대로 설정하지 않으면, 불필요하게 많은 워커 노드(Worker Node)가 유지되거나 Pod(파드)가 과하게 스케일 아웃(Scale Out)될 수 있어요. 특히 새벽 시간처럼 트래픽이 거의 없는 시간에도 워커 노드 수가 줄지 않고 계속 유지되면서 비용이 낭비되고 있었더라고요.

apiVersion: autoscaling.k8s.io/v1
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 1
  maxReplicas: 5
  targetCPUUtilizationPercentage: 50 # CPU 사용률이 50%를 넘으면 Pod 증가

targetCPUUtilizationPercentage를 너무 낮게 잡거나, minReplicas를 실제 필요한 것보다 높게 설정해두는 실수를 범했어요. 이런 미세한 설정 오류가 장기적으로 큰 비용 낭비로 이어지더라고요.

OpenShift 콘솔의 리소스 모니터링 대시보드: Pod, PVC, 네트워크 사용량을 통해 비용 관련 지표를 확인하는 화면.

OpenShift 비용 최적화를 위한 실전 전략

이런 삽질들을 겪으면서 얻은 교훈과 최적화 방법을 공유해봅니다. 💡

1. 스토리지 비용 최적화

• StorageClass (스토리지 클래스) 정책 검토: 클라우드 제공사마다 다양한 스토리지 타입을 제공해요. 애플리케이션의 요구사항(성능, 내구성)에 맞춰 가장 저렴하면서도 적합한 StorageClass를 선택하는 게 중요해요. 예를 들어, 고성능 SSD가 필요 없는 워크로드에는 HDD 기반 스토리지를 쓰는 거죠.
• PVC (Persistent Volume Claim) 사용량 모니터링: Prometheus(프로메테우스)나 Grafana(그라파나) 같은 모니터링 툴을 활용해서 실제 PVC 사용량을 주기적으로 확인하고, 필요 이상으로 프로비저닝된 볼륨은 줄여야 해요.
• Snapshot (스냅샷) 정책 자동화 및 관리: 불필요한 스냅샷이 쌓이지 않도록 명확한 보존 정책을 세우고, 자동화된 스크립트로 관리하는 게 필수적이에요.

2. 네트워크 비용 최적화

• Egress (외부 송신) 트래픽 분석: 어떤 서비스가 얼마나 많은 외부 트래픽을 발생시키는지 정확히 파악하는 게 중요해요. 클라우드 제공사의 네트워크 모니터링 도구나 클러스터 내부의 네트워크 플로우(Flow) 모니터링 툴(예: OpenShift Network Observability Operator)을 활용하면 됩니다.
• 내부 트래픽 최적화: 가능한 한 클러스터 내부에서 통신하도록 설계하고, 서비스 메쉬(Service Mesh, 예: Istio)를 활용해 내부 트래픽 라우팅을 최적화할 수 있어요.
• CDN (콘텐츠 전송 네트워크) 활용 검토: 정적 콘텐츠 전송에 많은 Egress 비용이 발생한다면, CDN을 도입하여 비용을 절감할 수 있어요.

3. 컴퓨트 자원 비용 최적화

• Cluster Autoscaler (클러스터 오토스케일러) 및 HPA (수평 Pod 오토스케일러) 정교화: 워크로드 패턴에 맞춰 minReplicas, maxReplicas, targetCPUUtilizationPercentage 등을 섬세하게 조정해야 해요. 특히 야간이나 주말처럼 유휴 시간이 긴 워크로드의 경우, minReplicas를 0으로 설정하여 완전히 스케일 다운(Scale Down)되도록 하는 것도 효과적이에요.
• Resource Request/Limit (자원 요청/제한) 정교화: Pod에 필요한 CPU, Memory를 정확하게 예측하여 requests와 limits를 설정하는 게 중요해요. 너무 과하게 잡으면 자원 낭비, 너무 적게 잡으면 OOMKilled(메모리 부족으로 인한 종료) 같은 문제가 생기거든요.
• 클라우드 비용 관리 도구 활용: Red Hat Advanced Cluster Management (RHACM) for Kubernetes의 비용 관리 기능이나 클라우드 제공사의 비용 관리 대시보드를 적극적으로 활용하여 클러스터 전체의 비용 가시성을 확보하는 게 중요해요.

비용 가시성 확보: OpenShift 비용 관리 도구 활용

OpenShift 환경에서 비용을 효과적으로 관리하려면 무엇보다 '가시성(Visibility)'이 중요해요. 어디서 돈이 새고 있는지 알아야 막을 수 있겠죠? 제가 추천하는 방법은 다음과 같습니다.

1. Kube-state-metrics (쿠베 스테이트 메트릭스): Kubernetes API 오브젝트의 상태를 메트릭으로 노출해줘요. Pod의 requests, limits 설정 같은 정보를 알 수 있죠.
2. Prometheus (프로메테우스) + Grafana (그라파나): kube-state-metrics나 cAdvisor(컨테이너 어드바이저) 등을 통해 수집된 데이터를 Prometheus로 저장하고, Grafana로 시각화하면 클러스터 전체의 리소스 사용량과 추이를 한눈에 파악할 수 있어요.
3. Red Hat Advanced Cluster Management (ACM) for Kubernetes의 비용 관리 기능: RHACM은 멀티 클러스터 환경을 관리하는 데 특화되어 있는데, 여기에 비용 관리(Cost Management) 기능이 포함되어 있어 클러스터별, 네임스페이스(Namespace)별, 심지어 Pod별 비용을 추정할 수 있도록 도와줘요. 이건 정말 유용하더라고요.

⚠️ 주의사항 & 트러블슈팅: 최적화하다가 성능 저하?!

클라우드 비용 관리를 한다고 너무 무리하게 자원을 줄이다 보면, 오히려 서비스 안정성이나 성능에 문제가 생길 수 있어요. 제가 경험했던 대표적인 사례는 다음과 같습니다.

• 너무 빡빡한 Resource Limit 설정: Pod의 Memory Limit(메모리 제한)을 너무 낮게 설정했다가, 순간적인 트래픽 증가로 메모리 사용량이 폭증하면서 OOMKilled(메모리 부족으로 인한 종료)가 발생해 Pod가 재시작되는 문제가 있었어요. 결국 애플리케이션 장애로 이어졌죠.
• Cluster Autoscaler의 aggressive한 설정: 유휴 노드를 너무 빨리 줄이도록 설정했더니, 갑자기 트래픽이 몰려 Pod가 스케줄링(Scheduling)될 때 필요한 워커 노드가 부족해서 서비스 지연이 발생했어요.

비용 최적화는 단순히 절감만이 목표가 아니라, 최소한의 비용으로 최대한의 가치를 얻는 것이에요. 따라서 비용과 성능 사이의 적절한 균형점을 찾는 게 정말 중요해요. 트래픽 패턴, 애플리케이션의 특성, SLA(서비스 수준 협약) 등을 종합적으로 고려하여 신중하게 접근해야 해요. ✅

Grafana 대시보드: OpenShift 클러스터의 리소스 사용량 및 최적화 전후 예상 비용 변화를 보여주는 시각화 자료.

마무리: 지속적인 모니터링과 정책 업데이트가 핵심

OpenShift 비용 최적화는 한 번 설정하고 끝나는 작업이 아니에요. 서비스가 진화하고 트래픽 패턴이 변하듯, 비용 구조도 계속 변하기 마련이죠. 따라서 지속적인 모니터링과 주기적인 정책 업데이트가 필수적이에요.

저도 여전히 홈랩에서 다양한 OpenShift 환경을 구축하고 비용 효율적인 운영 방안을 실험하고 있어요. 이 글을 통해 클라우드 비용 관리의 어려움을 겪고 계신 분들에게 조금이나마 도움이 되었기를 바랍니다. 다음 글에서는 OpenShift 환경에서 비용 관리 도구를 더 심층적으로 활용하는 방법에 대해 다뤄볼까 합니다. 기대해주세요! 🎉

OpenShift 비용 최적화 전략 인포그래픽: 스토리지, 네트워크, 컴퓨트 자원별 핵심 최적화 팁을 아이콘과 함께 요약.

📚 함께 읽으면 좋은 글

• 쿠버네티스 비용 최적화 5가지 핵심 전략 - 클라우드 비용 폭탄 방지
• OpenTelemetry K8s 분산 추적: 13년차 삽질 & 활용 사례
• Calico 네트워크 정책 베스트 프랙티스: 프로덕션 환경 보안 강화 체크리스트
• AWS 비용 최적화와 아키텍처 개선 1년 회고: 13년차 엔지니어의 삽질 노트
• Cloudflare Workers & R2 비용 최적화: 숨겨진 과금 피하는 실전 전략