Azure 상식

AKS 성능 개선에 대한 이해

ktzzang0601 2025. 8. 19. 10:53

1. Node Pool 분산 배치 - 가용성과 성능의 기본

 (1) 멀티 AZ 구성

  • 목적: 특정 Zone 장애 시 서비스 전체 중단을 방지
  • 구성 방법
az aks nodepool add \
    --resource-group MyRG
    --cluster-name MyAKS \
    --name np-app \
    --zones 1 2 3 \
    --node-count 3
  • 주의
    • 단일 Zone에 Node Pool을 구성하면 해당 Zone 장애 시 모든 Pod가 중단될 수 있음
    • 다중 Zone 배치 시 네트워크 지연(latency)과 데이터 동기화 방식 고려 필요

2. Worker Node 자원 컨트롤 - 안정적인 워크로드 운영

 (1) Requests / Limits 설정

  • Requests: Pod 스케줄링 시 반드시 보장되는 자원
  • Limits: 컨테이너가 사용할 수 있는 최대 자원
  • 설정 예시
resources:
    requests:
        cpu: 500m
        memory: 1Gi
    limits:
        cpu: 1000m
        memory: 1.5Gi

3. Worker Node 부하 분산과 무중단 업그레이드

 (1) Pod 분산 배치 (Pod Topology Spread Constraints)

topologySpreadConstraints:
- maxSkew: 1
  topologyKey: topology.kubernetes.io/zone
  whenUnsatisfiable: DoNotSchedule
  labelSelector:
      matchLabels:
        app: my-service
  • 목적: Pod가 특정 Node나 Zone에 쏠리지 않게 분산
  • 핵심 개념
    - 분산(Spreading): 같은 애플리케이션의 여러 Pod를 서로 다른 노드/존에 골고루 퍼뜨려 장애 한 번에 전부 죽지 않게 하자
    - 근접성(Affinity): 같이 붙여두면 좋은 애들(예: 앱 Pod ↔ 캐시 Pod)을 가깝게 놓아 지연을 줄이자.
    - 분리(Anti-affinity): 서로 떨어뜨려야 안전한 애들(예: 동일 앱의 복제본)을 같은 노드에 몰아넣지 말자.
  • 실행
    - 고가용성/재해복구: 복제본을 서로 다른 노드/가용영역에 분산 → 노드/존 장애에도 서비스 지속.
    - 성능: 앱 Pod를 캐시/DB 프록시 Pod와 가까이(같은 노드/같은 존) 배치 → 지연(Latency) 감소.
    - 비용/자원 활용: Spread로 핫스팟과 과부하를 피하고, 필요 시 ScheduleAnyway로 유연성 확보.
  • 주의사항
    - 노드 라벨 확인: 토폴로지 키는 실제 노드 라벨로 존재해야 합니다.
    • 존: topology.kubernetes.io/zone
    • 호스트: kubernetes.io/hostname
    • Bash 예시> kubectl get nodes --show-labels | grep topology.kubernetes.io/zone
    maxSkew 설정: 너무 빡빡하면(예: maxSkew: 0) 스케줄 실패가 잦아요. 1~2 정도로 시작하세요.
    - whenUnsatisfiable 선택:
    • 엄격한 HA가 필요하면 DoNotSchedule.
    • 일단 배치가 중요하면 ScheduleAnyway.

       - labelSelector 일치: Spread는 선택자에 매칭되는 Pod끼리 균등 비교합니다. 라벨 불일치로 효과 없어진 경우가 흔해요.

       - 노드/존 수 부족: 3존에 고르게 퍼뜨리려면 실제로 3존에 스케줄 가능한 노드가 있어야 해요. 없으면 스케줄 실패 → 노드 증설이나 제약 완화 필요.

       - 다른 조건과의 충돌: nodeSelector/affinity/taints 등과 함께 쓰면 충돌로 스케줄이 막힐 수 있어요. 점진적으로 제약을 더하세요.

       - 오토스케일러: CA(HPA/Cluster Autoscaler)와 함께 쓰면 분산 제약을 만족시키기 위해 특정 존의 노드만 늘어나는 현상이 생길 수 있어요. 의도에 맞는지 확인하세요.

 

 (2) Cluster Autoscaler

  • Node Pool별 최소/최대 노드 수 지정
az aks nodepool update \
  --resource-group MyRG \
  --cluster-name MyAKS \
  --name np-app \
  --enable-cluster-autoscaler \
  --min-count 2 \
  --max-count 10

 

 (3) Pod 배치 전략 - Taint & Toleration

  • 의미 : 노드에 Taint를 설정하여, 특정 파드 외에는 다른 pod 스케줄 배치를 막는 설정
  • 종류 :
    - NoSchedule : 오염을 관용하지 않는 Pod는 절대 스케줄링되지 않음.
    PreferNoSchedule : 가능한 한 스케줄하지 않으려고 하지만, 불가피하면 스케줄될 수 있음 (soft)
    NoExecute : 새 Pod가 스케줄되지 않을 뿐 아니라, 이미 올라와 있는 Pod도 퇴출(evict)됨, 
                            단, TolerationSeconds 설정으로 "얼마나 버틸지" 조절 가능.

 (4) Node Pool 무중단 업그레이드 절차 

  1. 컨트롤 플레인 업그레이드
  2. 임시 Node Pool(newagentpool) 추가
  3. 기존 Node Pool AutoScaling 비활성화
  4. 기존 Node Pool Pod 스케줄링 비활성화(Cordon) + Drain
  5. 임시 Node Pool로 Pod 이동 및 정상 동작 확인
  6. 기존 Node Pool 업그레이드
  7. 기존 Node Pool Autoscaling 활성화
  8. 기존 Node Pool Pod 스케줄링 활성화
  9. 임시 Node Pool Pod 스케줄링 비활성화 + Drain
  10. 서비스 정상 확인 후 임시 Node Pool 삭제

4. 네트워크 & 스토리지 성능 최적화

 (1) Network Policy 적용

  • 목적
    - Pod간 불필요한 트래픽 차단
    - 마이크로서비스 간 최소 권한 통신 모델 적용 (Zero Trust)
  • 옵션
옵션 특징
Azure NPM (network policy manager) - Azure Native 관리, Calico 보다 설정 단순
- AKS 네트워크 플러그인 azure일 때 사용 가능
Calico - 오픈 소스, 기능 유연성 높음
- azure / kubenet 네트워크 플러그인 모두 지원
  • 예시 정책
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-frontend-to-backend
  namespace: app
spec:
  podSelector:
    matchLabels:
      role: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend

 

 (2) Storage 최적화

  • AKS 환경에서는 스토리지 선택이 워크로드 특성에 따라 성능·비용에 직접 영향.
    시나리오 권장 스토리지 이유
    랜덤 읽기/쓰기 파일 Azure Files SMB/NFS
    대규모 순차 엑세스 Azure Blob Storage 대용량 스트리밍·분석에 최적, 저비용
    고 IOPS 필요 Premium SSD 높은 성능, 저지연
  • SAS 토큰을 통한 Blob 직접 접근
    장점: WAS 서버 부하 감소, 네트워크 홉 최소화
    - 예시
az storage blob generate-sas \
  --account-name mystorage \
  --container-name mycontainer \
  --name bigfile.mp4 \
  --permissions r \
  --expiry 2025-08-20T00:00:00Z
  • Access Key는 계정 전체 권한을 부여하므로 최소 권한 원칙에 위배됨.
  • Premium SSD는 가격이 높으므로, 필요한 워크로드에만 적용.

5. 참고 문서