MyAI(마이아이)개발 · 제품 · 운영 학습 노트

Cloud와 Kubernetes: AWS · Google Cloud · Azure · 국내 Cloud

3대 Cloud는 서비스 이름은 다르지만 같은 문제를 푸는 같은 모양의 부품을 가지고 있다. 이름을 외우기보다 대응 관계를 먼저 잡는다.

3대 Cloud 대응표

영역 AWS Google Cloud Azure
VM Amazon EC2 Compute Engine Azure Virtual Machines
Managed Kubernetes Amazon EKS GKE AKS
Serverless Container Amazon ECS (Express Mode, Fargate) Cloud Run Azure Container Apps
Functions AWS Lambda Cloud Run functions Azure Functions
Object Storage Amazon S3 Cloud Storage Azure Blob Storage
서울 Region ap-northeast-2 asia-northeast3 Korea Central

고르는 기준

설계 기준: Well-Architected

AWS Well-Architected Framework는 6개 Pillar로 설계를 점검한다.

Pillar 질문
Operational Excellence 운영하고 관측하고 개선할 수 있는가
Security 정보, 시스템, 자산을 보호하는가
Reliability 장애에서 회복하고 수요 변화에 대응하는가
Performance Efficiency 자원을 효율적으로 쓰는가
Cost Optimization 비용 대비 가치가 최대인가
Sustainability 에너지와 자원 사용을 줄이는가

Pillar 사이에는 Trade-off가 있다. 예를 들어 Multi-Region은 Reliability를 올리지만 Cost와 운영 복잡도를 올린다. Google Cloud와 Azure도 비슷한 Architecture Framework를 제공한다.

국내 Cloud와 공공 시장

사업자 확인한 내용
네이버클라우드 Ncloud Kubernetes Service. SourceCommit · SourceBuild · SourceDeploy · SourcePipeline으로 CI/CD 구성 가능
NHN Cloud NHN Kubernetes Service(NKS), Deploy 서비스. 2022-12 공공기관용 NHN Cloud CSAP 인증 취득(자사 안내)
KT Cloud 네이버클라우드·NHN Cloud와 함께 국내 공공 Cloud '빅3'로 보도(2024-02). 2026-03 자체 개발한 'kt cloud PLATFORM'(Kubernetes 기반으로 OpenStack 재구성)의 CSAP 인증 획득 보도
카카오클라우드 카카오엔터프라이즈 운영. Managed Kubernetes인 Kubernetes Engine 제공. 전신 '카카오 i 클라우드'가 Kubernetes 기반 IaaS로 CSAP 사후심사를 통과했다고 2022-06 보도

CSAP(클라우드 서비스 보안인증) 은 「클라우드컴퓨팅 발전 및 이용자 보호에 관한 법률」에 근거해 공공기관에 공급되는 Cloud의 정보보호 기준 준수를 인증하는 제도다.

flowchart LR
    R[요구사항] --> P{공공기관 고객인가?}
    P -->|예| C[필요한 CSAP 등급 확인]
    P -->|아니오| G{해외 사용자 비중이 큰가?}
    G -->|예| H[Global Cloud + Multi-Region 검토]
    G -->|아니오| K[서울 Region: Global 또는 국내 Cloud]

Container: 한 번 Build, 여러 번 배포

Container Image는 실행 환경까지 묶은 불변 Artifact다. 같은 Image를 Dev → Staging → Production으로 승격하면 "내 PC에서는 됐는데" 문제가 줄어든다.

FROM node:22-slim
WORKDIR /app
COPY package*.json ./
RUN npm ci --omit=dev
COPY . .
USER node
CMD ["node", "server.js"]

Dockerfile 옆에 .dockerignore를 둔다.

node_modules
.env
.git

COPY . .는 Build Context 전체를 Image에 넣는다. .dockerignore가 없으면 로컬 node_modules가 npm ci 결과를 덮어써 운영 Image에 다른 의존성이 들어가고, .env의 Secret과 .git 이력이 Image Layer에 그대로 남는다. Build Context가 작아져 Build도 빨라진다.

Kubernetes 핵심 개념

개념 역할
Pod Container 실행 단위
Deployment 원하는 Pod 수와 버전, Rolling Update 관리
Service Pod 묶음에 안정적인 내부 주소 제공
Ingress / Gateway API 외부 HTTP Traffic을 Service로 연결
ConfigMap / Secret 설정과 민감 정보 주입
HorizontalPodAutoscaler 부하에 따라 Pod 수 조절

최소 Manifest: Deployment + Service

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      terminationGracePeriodSeconds: 30
      containers:
        - name: web
          image: registry.example.com/web@sha256:<digest>
          ports:
            - containerPort: 8080
          lifecycle:
            preStop:
              sleep:
                seconds: 5
          readinessProbe:
            httpGet:
              path: /healthz/ready
              port: 8080
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /healthz/live
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 10
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              memory: 512Mi
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080
빠뜨린 것 일어나는 일
readinessProbe 없음 Container가 시작되자마자 Ready로 간주된다. 아직 초기화 중인 Pod로 Traffic이 가서 Rolling Update 때마다 Error가 튄다
resources.requests 없음 Scheduler가 필요한 자원을 모른 채 한 Node에 Pod를 몰아넣는다. Node 자원이 부족해지면 사용량이 요청량을 넘는 Pod부터 Evict되는데, 요청량이 0인 Pod(BestEffort)가 가장 먼저 대상이 된다
replicas: 1 그 Pod가 재시작 · Evict되거나 Node를 비울(Drain) 때마다 받아 줄 Pod가 없다. Rollout도 새 Pod 하나의 Readiness에만 기대므로 Probe가 부정확하면 곧바로 중단이다

Kubernetes 버전과 수명 (2026-09-28 기준)

Ingress NGINX 은퇴

Kubernetes 프로젝트는 널리 쓰이던 Ingress NGINX Controller의 은퇴를 2025-11에 발표했다. Best-effort 유지보수는 2026-03까지였고, 이후에는 Release, Bugfix, 보안 수정이 없다. 권장 경로는 Gateway API 또는 다른 Ingress Controller로의 이전이며, 변환 도구 Ingress2Gateway 1.0이 2026-03에 나왔다.

나쁜 예 / 좋은 예

나쁜 예: Service 2개, 개발자 3명인데 Kubernetes Cluster를 직접 구성하고
        Upgrade 계획 없이 2년째 같은 버전을 쓴다.
좋은 예: Serverless Container로 시작하고, Service 수·Traffic·팀이 커져
        공통 운영이 필요해질 때 Managed Kubernetes로 옮긴다.

Kubernetes가 필요해지는 신호

참고 자료