ktzzang0601 님의 블로그

AKS GPU Sharing에 관한 고찰

ktzzang0601 — Tue, 26 Aug 2025 01:05:08 +0900

1. 개요

Azure에서 GPU를 활용하기 위해서는 기본적으로 VM 1대에 GPU 1개를 매칭하여 사용하며, 하나의 GPU를 여러대의 VM이 사용할 수 없다.
다만, 컨테이너 환경에서는 GPU 자원을 쉐어링 할 수 있는데, AKS에서 GPU 사용 요건과 사용 방식에 대해 알아 보자.

2. AKS에서 GPU 활용 조건

GPU 지원 VM 노드풀 사용
NVIDIA Device Plugin for Kubernetes
- 쿠버네티스에서 GPU 리소스를 스케줄링하려면 반드시 nvidia-device-plugin DaemonSet을 배포해야 함.
- 이 플러그인이 GPU 리소스를 nvidia.com/gpu라는 형태로 노출시켜, Pod이 요청할 수 있도록 해줌
NVIDIA 드라이버 및 CUDA 라이브러리
- GPU 노드풀에는 NVIDIA 드라이버가 설치되어야 하며, CUDA/cuDNN 버전은 컨테이너 이미지 내부와 호환되어야 함.
- 즉, 컨테이너 내부 CUDA 버전과 VM에 설치된 드라이버 버전이 호환되어야 여러 컨테이너에서 GPU 활용이 가능
- AKS는 NVIDIA GPU Operator 또는 VM 확장 기능을 통해 자동 설치 가능.
QoS 설정은 반드시 Guaranteed(requests == limits).

3. 하드웨어적 Sharing 기법 - Multi Instance GPU(MIG)

NVIDIA Multi-Instance GPU(MIG)는 최신 NVIDIA GPU(A100, H100 등)에서 제공하는 하드웨어 기반 가상화 기술입니다. MIG는 단일 물리 GPU를 최대 7개의 완전 격리된 독립 GPU 인스턴스로 분할할 수 있습니다. 각 인스턴스는 자체 메모리, 컴퓨팅 코어, 캐시를 포함하며, 서로 간의 작업 간섭 없이 독립적으로 동작합니다. 이를 통해 여러 워크로드를 동시에 운영하면서도 예측 가능한 서비스 품질(QoS)을 보장할 수 있습니다. 또한, GPU 인스턴스 단위의 성능 모니터링과 관리가 가능해 GPU 자원의 효율적 배분과 안정성 확보에 탁월합니다.
MIG는 Ampere 이상(A100, A30)과 Hopper 이상(H100/H200 등)에서 지원됩니다. 드라이버 요구사항은 대략 A100/A30 = CUDA 11 / R450+, H100 = CUDA 12 / R525+
MIG는 한 개의 물리 GPU를 여러 개의 독립 인스턴스(MIG slice) 로 하드웨어 분할하는 기술임 따라서 같은 노드 안의 단일 GPU를 여러 Pod/컨테이너가 나눠 쓰게 해주지만, 여러 노드가 한 GPU를 공유하는 건 아님. NVIDIA 공식 가이드도 “단일 물리 GPU에서 여러 GPU 인스턴스가 병렬 실행”이라고 명시
MIG 자원을 쿠버네티스에 노출하는 방식은 두 가지 전략 중 하나를 선택
- single: 모든 MIG 인스턴스를 nvidia.com/gpu 로 노출
- mixed: 프로파일별 자원명으로 노출(예: nvidia.com/mig-1g.5gb)
AKS는 MIG 호환 VM 사이즈(예: A100 계열 NDv4, H100 Standard_NC40ads_H100_v5 등)로 MIG 노드풀을 만들 수 있고, 만들 때 GPU instance profile(예: MIG1g, MIG2g 등)을 지정합니다. 단, 적용한 profile은 노드풀 생성 후 변경 불가이고, Azure Linux 노드이미지에선 현재 미지원
GPU는 limits에만 지정해도 되고, 그러면 request = limit 으로 간주되며 requests를 지정하려면 limits와 반드시 동일해야 함
QOS 관점에서 GPU만 limits를 걸어도 CPU/메모리를 지정하지 않으면 BestEffort가 됩니다. 안정적인 스케줄/축출 회피가 필요하면 CPU/메모리도 requests=limits로 맞춰 Guaranteed를 권장
GPU Operator를 쓰면 드라이버/디바이스 플러그인/GFD 등을 자동 배포하며 MIG Manager가 노드의 MIG 구성을 관리합니다. 다만 AKS에서는 MIG 프로파일은 노드풀 생성 시 고정(런타임 변경 불가) 제한이 있으니 설계 시에 결정

4. 소프트웨어적 Shareing 기법 - NVIDIA Multi-Process Service(MPS)

NVIDIA Multi-Process Service(MPS)는 소프트웨어 레벨에서 여러 CUDA 프로세스를 동시에 실행시켜 GPU 이용률을 높이는 기술입니다. MPS는 단일 GPU 내에서 다중 프로세스의 작업을 병렬 처리할 수 있도록 하여 GPU의 자원 활용을 극대화하지만, 하드웨어 자원 격리 측면에서는 MIG에 비해 제한적입니다. 따라서 격리가 엄격히 요구되는 환경보다는 GPU 활용률 향상이 목표인 경우 적합하며, GPU idle 시간을 줄여 효율 극대화, latency 줄일 수 있음
다만, 하드웨어 자원 분리는 없기 때문에 (메모리·SM 등 격리 X, soft sharing임) 워크로드 간 간섭이 발생할 수 있어 안정성이 중요한 멀티 테넌트 환경에는 부적합
MIG에 비해 Pod 및 워크로드 수의 제한이 없으며, 대부분 (Kepler 이후 Tesla, T4, V100 포함) GPU 사용이 가능한 VM에서 활용 가능함.

5. 활용 방법

먼저 MIG로 GPU를 하드웨어 분할(예: A100 한 장을 1g.5gb × 7로 쪼갬) 후 그 안에서 다시 MPS를 켜면, 해당 MIG slice를 여러 프로세스가 소프트웨어 레벨로 공유할 수 있음
즉 GPU를 다중 사용자 또는 다중 워크로드 환경에서 효율적으로 운영하기 위해서는 하드웨어 기반의 MIG, 소프트웨어 병렬 처리용 MPS, 그리고 Kubernetes 자원 정책을 함께 고려하는 통합적 접근이 필수
(참고) Time‑slicing: 디바이스 플러그인 옵션으로 시간 분할 공유(오버서브스크립션) 가능. MIG 프로파일 자원에도 적용 가능. 격리는 MIG보다 약하지만 활용도는 높음

6. 참고 문서

GPU VM이란? https://learn.microsoft.com/ko-kr/azure/databox-online/azure-stack-edge-gpu-overview-gpu-virtual-machines#gpu-vm-deployment
GPU 공유 : https://learn.microsoft.com/ko-kr/azure/databox-online/azure-stack-edge-gpu-sharing
GPU 마이그레이션 : https://learn.microsoft.com/ko-kr/azure/virtual-machines/migration/sizes/n-series-migration

AKS 장애 대응 - Node Not Ready, POD Pending 등 이슈 원인 파악 및 해결 방안

ktzzang0601 — Mon, 25 Aug 2025 22:58:56 +0900

1. 개요

AKS는 작업자 노드의 상태를 지속적으로 모니터링하고 비정상상태가 되면 노드를 자동 복구하며 두 가지 이중화된 방법으로 상태를 체크합니다..
status 업데이트: kubelet이 주기적으로 Node의 리소스 상태를 API 서버에 업데이트
Lease 객체: kubelet이 10초마다 Lease 객체를 갱

2. 자동 복구 방법

AKS가 5분 이상 비정상으로 유지되는 노드를 식별하는 경우 다음 작업을 수행
- AKS가 노드를 다시 부팅
- 부팅 후 노드가 비정상이라면 AKS는 노드를 이미지로 다시 설치
- 이미지 설치 후 노드가 비정상이고 Linux 노드인 경우 AKS가 노드를 다시 배포
- 위 과정은 최대 3회 다시 시도

3. 자동 복구가 수행되지 않는 경우

네트워크 구성 오류로 노드 상태가 들어오지 않을 때
노드가 처음에 정상 노드로 등록하지 못한 경우
노드에 다음 taint중 하나가 있는 경우 : node.cloudprovider.kubernetes.io/shutdownToBeDeletedByClusterAutoscaler
노드가 업그레이드 중인 경우

4. Node Not Ready 원인 및 대응 방법

상황 :
- kubectl get nodes 에 NotReady 표기
- kubectl describe node 의 Conditions에서 Ready=False, NetworkUnavailable=True, MemoryPressure=True, DiskPressure=True, PIDPressure=True 등 확인
원인 및 대응 방법

A. kubelet/컨테이너 런타임 장애
1. ssh를 통해 해당 node에 접속
2. 아래 명령어들을 이용해 kubelet, 컨테이너 런타임 장애여부 확인

journalctl -u kubelet -n 200 --no-pager
journalctl -u containerd -n 200 --no-pager
sudo systemctl status kubelet containerd

3. 컨테이너 런타임 프로세스 재시작

sudo systemctl restart containerd kubelet

B. 리소스 부족
1. kubectl describe node의 Pressure=True 확인 Memory/PID Pressure: 과소요 파드 제한/리소스쿼터 도입, 문제 파드 축출. 필요 시 노드풀 스케일아웃.
2. DiskPressure: 이미지/컨테이너 정리

sudo crictl images
sudo crictl rmi --prune

sudo du -sh /var/lib/containerd/* /var/lib/kubelet/* 2>/dev/null

C. 네트워크/CNI 문제
1. NetworkUnavailable=True, kubelet이 API 서버로 Heartbeat 실패
2. 아래 명령어(CoreDNS, konnectivity 예시)를 이용해 장애 여부 확인

kubectl -n kube-system get pods -l k8s-app=kube-dns

kubectl -n kube-system get pods | grep konnectivity

3.    CNI/시스템 파드 재시작, 노드 재부팅, 노드 교체, UDR/NSG 변경 여부 점검

D. 시간 동기화/인증 토큰 문제
1.    노드 시간이 크게 틀어진 경우 API 인증 실패 가능성이 존재, node에 접속 후
2.    아래 명령어를 이용해 시간 확인

timedatectl status

3.    NTP 동기화 복구, kubelet 재시작

E. 노드가 cordon/drain 상태로 방치
1.    NotReady,SchedulingDisabled 또는 kubectl get nodes에 SchedulingDisabled
2.    아래 명령어를 통해 node를 uncordon으로 설정 혹은 필요시 drain

kubectl uncordon <NODE>

kubectl drain <NODE> --ignore-daemonsets --delete-emptydir-data

5. POD Pending 원인 및 대응 방법

상황 :
- 스케줄러가 아직 파드를 어떤 노드에도 배치하지 못한 상태. (이미 스케줄된 뒤 컨테이너 풀/이미지 문제는 보통 ContainerCreating/ImagePullBackOff로 보입니다.)

A. 리소스 부족
1. 아래 명령어로 리소스 부족 확인

kubectl describe pod

2.    진단 결과에 따른 대응
o   스케일 아웃: 노드 풀 증가
o   리소스 요청 조정: requests/limits 현실화, 우선순위 검토
o   pod 수 제한(kubelet의 maxPods)에 걸리면 노드 타임/설정 변경

B. 스케줄링 제약 불일치
1.    nodeSelector/nodeAffinity/topologySpreadConstraints/podAntiAffinity가 현실과 안 맞음, 또는 taint/toleration 미스매치
2.    아래 명령어로 진단

kubectl describe pod <POD> | sed -n '/Events:/,$p'

3.    진단 결과에 따른 대응
o   label/taint 정합성 수정
o   제약 완화 또는 노드풀에 해당 특성 라벨 부여/증설

C. 스토리지 대기(PVC Pending)
1.    파드가 Pending, PVC가 Bound되지 않음
2.    아래 명령어로 진단

kubectl get pvc

kubectl describe pvc <PVC>

3.    진단 결과에 따른 대응
o   StorageClass 오타
o   존 불일치
o   용량, I/O 제한
o   디스크/SCI 문제
o   리소스 쿼터 부족

6. Pod Pending 해결 방안 풀이

AKS 클러스터 내에서 Pod가 Pending 상태가 되는 것은 일반적으로 스케줄러가 해당 Pod를 적절한 노드에 할당하지 못하는 것을 의미합니다. 특히 노드가 준비되지 않은 상태일 때, Pod Pending이 자주 발생하는데, 이는 클러스터 운영에 심각한 영향을 줄 수 있으므로 원인 분석과 신속한 대응이 필요합니다.
첫째, 노드 자체가 정상적으로 준비되지 않아서 스케줄러가 Pod를 할당하지 못하는 경우입니다. 이때 노드가 `NotReady` 상태이거나, 클러스터 노드 그룹에서 노드 생성 지연, OS 또는 에이전트 문제 등으로 초기화가 완료되지 않은 상황일 수 있습니다. 이에 대한 대응으로는 해당 노드의 상태를 `kubectl get nodes` 등으로 확인하고, AKS 노드 풀 상태를 모니터링하며 필요하면 노드를 재시작하거나, 문제가 지속 시 노드 풀을 재구성하거나 교체하는 조치가 필요합니다.
둘째, 리소스 부족 문제입니다. 클러스터 내 가용 노드가 있지만, CPU, 메모리, GPU 등 자원 부족으로 인해 스케줄링이 불가능하여 Pod가 Pending 상태에 머무는 경우입니다. 특히 제한된 리소스를 가진 노드 풀에서 고리소스 요구 Pod가 다수 배포될 때 흔하게 발생합니다. 대응 방법으로는 리소스 요청(Request)과 제한(Limit)을 적절히 설계하고, 필요 시 노드 풀에 노드를 추가하거나 HPA(Horizontal Pod Autoscaler), Cluster Autoscaler를 활용해 클러스터 확장 정책을 적용하는 것이 효과적입니다.
셋째, 스케줄링 제약 조건(Scheduling Constraints)으로 인해 노드에 Pod가 할당되지 못하는 경우입니다. 예를 들어, Pod에 설정된 노드 셀렉터(NodeSelector), 노드 친화성(Node Affinity), taint 및 toleration 정책과 같은 배치 제한 조건들이 노드와 맞지 않으면 스케줄러가 매칭을 못해 Pending 상태가 됩니다. 이 경우 Pod 및 노드의 라벨(Label), taint, toleration 설정을 점검하고 불필요하거나 잘못된 제약 조건을 제거하거나 수정해야 합니다.
넷째, 네트워크 또는 스토리지 등의 외부 종속성 문제로 인해 Pod가 정상적으로 스케줄링되지 못하는 경우입니다. 예를 들어, Azure Disk, Azure Files와 같이 외부 볼륨 프로비저닝이 지연되거나 실패하면 Pod가 Pending 상태에 머무르게 됩니다. 이런 상황에선 PersistentVolume, PersistentVolumeClaim 상태를 점검하고, 적절한 스토리지 클래스와 프로비저닝 정책을 확인하는 것이 필요합니다.
마지막으로, 클러스터 구성 또는 제어 평면(Control Plane) 문제로 노드 상태 갱신이 늦거나, API 서버와 노드 에이전트 간 통신 장애가 발생하는 경우도 있습니다. 이 경우에는 클러스터 상태 대시보드 확인, Azure 모니터링 로그 및 이벤트 분석, 필요한 경우 Azure 지원팀과 협력하여 문제 원인을 규명하고 해결해야 합니다.
따라서, AKS에서 노드 준비 실패로 인한 Pod Pending 문제에 대응하기 위해서는 먼저 노드 상태 및 클러스터 리소스 현황을 정확히 파악하고, 스케줄링 제약 조건을 점검하며, 외부 종속성과 클러스터 상태까지 종합적으로 분석하는 체계적인 접근이 필요합니다. 이러한 과정을 통해 적절한 노드 재구성, 클러스터 확장, 배치 제약 완화, 외부 리소스 문제 해결 조치를 시행하여 안정적인 AKS 운영을 유지할 수 있습니다.

7. 참고 문서

노드 준비 안됨 현상 https://learn.microsoft.com/ko-kr/troubleshoot/azure/azure-kubernetes/availability-performance/node-not-ready-basic-troubleshooting
노드 자동 복구 https://learn.microsoft.com/ko-kr/azure/aks/node-auto-repair
Pod 스케줄러 오류 https://learn.microsoft.com/ko-kr/troubleshoot/azure/azure-kubernetes/availability-performance/troubleshoot-pod-scheduler-errors
https://hjin9445s-organization.gitbook.io/archive/work/undefined/cds

AKS의 이슈상황 원인과 대응방안 + Pod Lifecycle

ktzzang0601 — Mon, 25 Aug 2025 22:31:28 +0900

1. POD FAILED 현상

OOMKilled / Memory cgroup 초과
Evicted(DiskPressure/EphemeralStorage/MemoryPressure)
DeadlineExceeded (Job activeDeadlineSeconds 초과)
Exit code ≠ 0 (프로세스 조기 종료, entrypoint 오타, 권한 문제)

2. POD FAILED 해결 방안

OOMKilled: resources.requests/limits 합리화, 메모리 leak 점검, VPA/HPA 도입, GC/힙 옵션 조정
Evicted: 노드 DiskPressure해소(이미지/컨테이너/워킹디렉 정리), ephemeral-storage requests/limits 및 emptyDir.sizeLimit 설정, 노드풀 디스크/사이즈 증설
Job 실패: backoffLimit, activeDeadlineSeconds, 재시도 간격 재설계. 반복 실패면 InitContainer로 프리체크, 종속 서비스 준비(health/endpoint) 확인
Exit code ≠ 0 : 권한·엔트리포인트: securityContext, command/args 검증, 실행 비사용자(shell) 문제 해결

3. BackOff 계열(CrashLoopBackOff, ImagePullBackOff, ErrImagePull 등등..)

CrashLoopBackOff
a. 원인 : 어플리케이션 예외/의존 미준비/잘못된 CMD, liveness probe 오탐 등
b. 대응방법 :
- Startup, Readness, Liveness Probe 분리
- InitContainer로 의존 리소스(DB 등) 준비 확인
- 애플리케이션 종료 신호 처리(SIGTERM)와 graceful shutdown 구성
ImagePullBackOff / ErrImagePull
a. 원인 : 레지스트리 인증, 네트워크 혹은 이미지 태그 오타
b. 대응방법 :
- ACR 사용 시 AKS-ACR 연결(Managed Identity attach-acr), 또는 imagePullSecrets 설정
- 프록시/NSG/DNS 확인, 사설 레지스트리면 프라이빗 엔드포인트/방화벽 예외
- 태그 고정(immutable), imagePullPolicy: IfNotPresent 적절히 사용
CreateContainerConfigError / CreateContainerError
a. pod pending과 동일한 대응을 통해 예방 가능

4. (추가) Nodegroup Scale-in시 고려할 Pod Lifecycle 설정

Scale-in 시 연결 드레이닝, 데이터 무결성 보장이 중요합니다.
핵심 체크리스트는 아래와 같습니다.
- Pod Disruption Budget(PDB): 과도한 동시 축출 방지Copy
- preStop hook + terminationGracePeriodSecondsCopy
-> preStop에서 LB 등록 헤제/세션 종료/큐 flush
-> SIGTERM 후 readiness가 자동 false되지만, 어플리케이션 자체 graceful 필요
readinessProbe 엄격화: 종료 직전 트래픽 유입 차단 속도를 높이고 정상 동작 중에만 Ready 유지
PDB + HPA 조합: 축출 가능한 파드 수와 자동 확장 균형 맞추기
safe-to-evict 어노테이션: 스케일인 시 지우면 안되는 파드에 다음과 같이 safe-to-evict 어노테이션 추가
빈약한 스테이트풀 방지: StatefulSet은 PodManagementPolicy=Parallel와 PodAntiAffinity로 분산, 스토리지는 RWO/PV 바인딩 존 일치.

5. 참고 문서

Azure Kubernetes Service에서 Pod 스케줄러 오류 문제 해결 https://learn.microsoft.com/ko-kr/troubleshoot/azure/azure-kubernetes/availability-performance/troubleshoot-pod-scheduler-errors
AKS 클러스터에서 OOMKilled 문제 해결 https://learn.microsoft.com/ko-kr/troubleshoot/azure/azure-kubernetes/availability-performance/troubleshoot-oomkilled-aks-clusters
노드 준비 안 됨 오류의 기본 문제 해결 https://learn.microsoft.com/ko-kr/troubleshoot/azure/azure-kubernetes/availability-performance/node-not-ready-basic-troubleshooting
Pod가 CrashLoopBackOff 모드 상태에 중단됨 https://learn.microsoft.com/ko-kr/troubleshoot/azure/azure-kubernetes/create-upgrade-delete/pod-stuck-crashloopbackoff-mode
https://hjin9445s-organization.gitbook.io/archive/work/undefined/cds

6. 추가 검색 내용

① OOMKilled (메모리 초과로 프로세스 KILL)

원인

컨테이너 memory.limit 초과 → 커널 OOMKiller가 프로세스를 SIGKILL(137)로 종료.
애플리케이션 메모리 누수, JVM/Node/Go 등 런타임 힙/네이티브 메모리/DirectBuffer 과다.
캐시/버퍼(파일 캐시)·tmpfs 사용 등도 cgroup 메모리 사용량에 포함되어 limit에 닿음.

진단

kubectl describe pod <pod>: Last State: Terminated, Reason: OOMKilled 확인.
kubectl logs <pod> --previous로 직전 크래시 직전 로그 확인.
메트릭: kubectl top pod, APM/프로파일러(Heap/Alloc 곡선이 지속 증가하면 누수 의심).
JVM은 -XX:+HeapDumpOnOutOfMemoryError로 덤프 확인, Node.js는 –max-old-space-size와 heap snapshot, Go는 pprof(net/http/pprof) 등.

해결/예방

리소스 합리화
- requests는 실제 95~~99퍼센타일 사용량 근거로 잡고, limits는 requests의 1.2~~1.5배(메모리는 너무 타이트하게 잡지 않기).
- 메모리는 스로틀링이 없고 바로 OOM이므로 충분한 헤드룸(20~30%) 확보.
VPA/HPA
- HPA는 보통 CPU 중심(또는 외부 지표), 메모리는 변동/버스트가 크면 HPA 신호로 쓰기 위험.
- VPA는 최소 추천(“Off” 모드) 으로 켜서 요청값을 주기적으로 조정. HPA와 동시에 “자동 적용”은 충돌 우려 → 한쪽은 추천/관측용으로 운용.
런타임/GC 튜닝(언어별 핵심)
- JVM: -XX:+UseContainerSupport(JDK 8u191+), -XX:MaxRAMPercentage=60 등으로 힙이 컨테이너 제한을 존중. -Xms/-Xmx를 limit보다 여유 있게. -XX:+ExitOnOutOfMemoryError로 조기 실패, -XX:MaxDirectMemorySize도 관리.
- Node.js: --max-old-space-size=<MB> 지정(컨테이너 limit 기준 여유 있게).
- Go: GOGC 조정(예: 100→150), 메모리 재사용 패턴 점검, pprof로 hot path 추적.
- Python: tracemalloc, MALLOC_ARENA_MAX=2 등으로 arena 폭주 억제.
코드 측면: 캐시 상한, large object 재분할, 스트리밍 처리, 연결/버퍼 누수, goroutine/쓰레드 누수 제거.

② Evicted (노드 DiskPressure로 퇴거)

원인

노드의 nodefs(루트 디스크) 혹은 imagefs(컨테이너 레이어/이미지 디스크)가 임계치 이하로 남음 → kubelet이 Eviction 정책에 따라 Pod 축출.
주범: 컨테이너 로그 과다, emptyDir 무제한 사용, 이미지 누적, 워킹 디렉터리 대용량 쓰기.

진단

kubectl describe pod <pod> 이벤트에 Evicted + DiskPressure 메시지.
kubectl describe node <node>에서 Conditions: DiskPressure=True.
노드 진입(예: kubectl debug node/<node> --image=nicolaka/netshoot) 후 /var/lib/containerd, /var/log/containers, /var/lib/kubelet 용량 확인.

해결/예방 (우선순위순)

즉시 압력 해소
- 불필요 이미지/컨테이너/죽은 Pod 로그 정리(운영 표준 작업으로 스크립트화).
- 로그 레벨 하향, 애플리케이션 로그 로테이션(파일에 쓸 경우) 적용.
리소스 한도 명시
- ephemeral-storage requests/limits로 컨테이너 임시 저장소 상한을 명확히:
- emptyDir 용량 제한:
노드/런타임 레벨 설정
- kubelet eviction 임계값(기본값 유지 권장, 필요시 완화는 신중): 메모리/디스크 가용률 임계치.
- 컨테이너 로그 로테이션(kubelet):
  containerLogMaxSize, containerLogMaxFiles를 적정선으로(예: 10Mi, 5).
용량 확장/구조 개선
- 노드풀 디스크/사이즈 증설(특히 /var/lib/containerd가 작을 때).
- 이미지 다이어트(멀티스테이지, alpine/distroless, 불필요 레이어 제거).
- 대용량 임시파일은 오브젝트 스토리지/외부 볼륨으로 오프로딩.

③ Job 실패 (backoffLimit, activeDeadlineSeconds 등)

원인

작업 자체 실패(종속 서비스 준비 전 시작, 입력 데이터 불완전, 권한/네트워크 문제).
재시도/시간 제한 정책이 워크로드 특성에 맞지 않음 → 불필요한 반복 실패, 장시간 점유.

진단

kubectl describe job <job>: .status.failed, conditions 확인.
kubectl get pods -l job-name=<job> -o wide + 실패한 Pod 로그/exit code 확인.
실패 패턴(즉시 실패 vs 오래 걸리다 timeout vs 간헐 성공)을 분리.

해결/설계 팁

재시도/시간 제한 재설계
종속성 프리체크(InitContainer)
- DB/큐/HTTP 엔드포인트 준비 확인 후 본 컨테이너 실행:
PodFailurePolicy(고급)
- 특정 exit code는 즉시 실패로 간주하거나 재시도 제외 등 세밀 제어(지원 버전에서).
Idempotency & 체크포인트
- 같은 입력 재처리에도 안전하도록 설계, 중간 산출물은 외부 스토리지에 체크포인트.
리소스/네트워크
- Job이 CPU/메모리/IO 부족으로 지연되면 요청 상향.
- 대량 출력은 PVC/오브젝트 스토리지 사용, stdout 과다로그 금지.
스케줄링
- 많은 Job 동시 제출 시 parallelism 제한, 큐잉 시스템 도입.
- startingDeadlineSeconds(CronJob)로 지연 시작 방지.

④ Exit code ≠ 0 (권한/엔트리포인트/커맨드 등)

원인

실행 파일 권한/소유자 문제, 잘못된 엔트리포인트/인자, 셸 기능 필요하지만 sh -c 없이 실행, 잘못된 아키텍처 이미지, shebang 누락·CRLF 라인엔딩 등.
securityContext로 비루트 사용자 실행 시, 파일/포트/디렉터리 권한 미흡.
마운트한 볼륨이 바이너리를 가려버리는 경로 충돌.

진단

Pod 로그의 에러 메시지 + 종료 코드 표:
- 126 실행 권한/실행 불가, 127 명령 없음, 137 OOM/SIGKILL, 139 세그폴트, 1 일반 에러.
kubectl exec로 컨테이너 진입 → ls -l, file ./app, ldd ./app, 권한/의존 확인.
kubectl describe pod의 command/args, securityContext 확인.

해결/예방

엔트리포인트/인자 검증
- 스크립트는 #!/bin/sh + chmod +x + LF 줄바꿈 유지.
securityContext 정렬
- 애플리케이션이 쓰기 필요한 경로(/tmp, /app/data 등)는 writable 볼륨으로 마운트:
아키텍처/의존성
- ARM 노드에 amd64 이미지(또는 반대)면 exec format error → 멀티아키 이미지 사용.
- 네이티브 라이브러리 의존(예: glibc vs musl) 맞추기.
경로 충돌 방지
- volumeMount가 /app을 덮어 이미지 내 바이너리를 가리지 않는지 확인.

① CrashLoopBackOff

컨테이너가 시작하자마자 비정상 종료(exit≠0) → kubelet이 지수적 back-off(수초→수분 상한)로 재시도하는 상태.

주된 원인

앱 예외/환경 값 누락/잘못된 command / args/엔트리포인트 스크립트 오류
의존 서비스(DB, MQ, API) 준비 전 시작 → 초기화 실패 후 즉시 종료
livenessProbe 오탐(초기 기동이 긴 서비스인데 너무 이른 검사)
종료 시그널(SIGTERM) 미처리 → 다음 기동에서 락/캐시/포트 충돌로 재크래시

진단 포인트

kubectl describe pod <pod> 이벤트: Back-off restarting failed container
직전 크래시 로그: kubectl logs <pod> -c <container> --previous
종료 코드/시그널: Last State: Terminated (ExitCode, Reason)
프로브 실패 이력: describe 이벤트에 Liveness probe failed / Readiness probe failed

해결/예방

A. 프로브 분리/튜닝

startupProbe 통과 전에는 livenessProbe가 동작하지 않음(초기 오탐 방지).
readiness는 트래픽 유입 제어, liveness는 진짜 장애만 재시작.

B. 의존성 프리체크(InitContainer)
C. 정상 종료/그레이스풀 셧다운

앱이 SIGTERM 수신 시 커넥션 종료, 워커 중단, 임시파일 정리하도록 구현.

D. 커맨드/엔트리포인트 가드
E. 기타

컨테이너가 너무 빨리 죽는 경우 재현을 위해 liveness 임시 비활성화 후 원인 파악
로그/메트릭 수집기(APM, 프로파일러)로 초기화 경로 예외 포착
Job성 작업이면 Deployment 대신 Job + backoffLimit 사용(잘못된 재시작 루프 방지)

② ImagePullBackOff / ErrImagePull

이미지 풀 실패. ErrImagePull은 즉시 오류, 그 다음부터 back-off로 재시도하며 ImagePullBackOff.

주된 원인

인증 실패(프라이빗 레지스트리/ACR 권한 없음)
네트워크/DNS/프록시/방화벽(ACR Private Endpoint/DNS 설정 누락 포함)
이미지 참조 오류(리포지토리/태그 오타, 삭제된 태그)
Docker Hub 레이트 리밋/미러 필요

진단 포인트

kubectl describe pod 이벤트의 정확한 에러 메시지:
- unauthorized: authentication required
- manifest unknown
- dial tcp ... i/o timeout(네트워크)
서비스어카운트에 연결된 imagePullSecrets 유효성:
kubectl get sa <sa> -o yaml
레지스트리 FQDN DNS/443 연결성: 디버그 파드에서 nslookup, curl -I https://<registry>

해결/예방

A. 인증 구성

AKS ↔ ACR(Managed Identity)
AKS 클러스터 MI에 ACR AcrPull 권한을 부여(예: --attach-acr).
운영 점검 포인트: 클러스터(혹은 노드풀) MI의 AcrPull 역할 바인딩과 ACR 방화벽/네트워크 규칙.
이미지 풀 시크릿(기타 레지스트리)

B. 네트워크/DNS

프록시 환경이면 노드(컨테이너 런타임) 에 프록시 설정 필요(파드 내부 프록시 설정과 별개).
ACR Private Endpoint 사용 시:
- 노드 VNet에 privatelink.azurecr.io(및 데이터/토큰 FQDN)용 Private DNS 링크
- NSG/방화벽에서 443 허용, 라우팅이 사설 IP로 향하는지 확인

C. 이미지 참조 안정화

latest 지양, 태그 고정 + 불변(tag immutability) 또는 digest 고정:

Docker Hub는 조직 계정/미러/캐시 레지스트리 검토

D. 빠른 확인

같은 네임스페이스에서 작은 테스트 파드로 pull 시도해 에러 메시지 비교
이벤트 나열: kubectl get events --sort-by=.lastTimestamp

③ CreateContainerConfigError / CreateContainerError

스케줄링은 됐는데 컨테이너 생성 단계에서 실패.

CreateContainerConfigError: 컨테이너 설정이 잘못됨(볼륨/CM/Secret/환경 참조 오류 등)
CreateContainerError: 런타임가 컨테이너 생성 자체를 실패(OCI runtime, 보안 프로필, 마운트 문제 등)

주된 원인

존재하지 않는 ConfigMap/Secret/PVC 참조(이름 오타/네임스페이스 불일치/키 누락)
volumeMounts ↔ volumes 불일치, subPath 대상이 파일/디렉터리와 안 맞음
PodSecurity(Restricted)/Seccomp/AppArmor/Capabilities 정책으로 거부
읽기 전용 루트(readOnlyRootFilesystem: true)인데 앱이 /tmp 등 쓰기 시도
잘못된 UID/GID로 권한 부족, 또는 존재하지 않는 사용자로 실행

진단 포인트

kubectl describe pod 이벤트의 상세 메시지:
예) configmap "app-cm" not found, secret key "password" not found,
MountVolume.SetUp failed, Error: container has runAsNonRoot and image has non-numeric user
리소스 존재 확인:
- kubectl get cm/secret/pvc <name> -n <ns>
- 키 확인: kubectl get secret <name> -o yaml(base64 decode)
보안 거부 로그: 이벤트에 denied by policy/seccomp/apparmor 표기

해결/예방 스니펫

A. CM/Secret 정확 매칭
B. subPath/마운트 정합
C. 보안 컨텍스트/쓰기 경로
D. PodSecurity 정책과의 합의

Restricted 수준 네임스페이스면 hostPath/특권/NET_RAW 등 차단.
→ 매니페스트에서 금지 기능 제거/대체, 혹은 정책-네임스페이스 레벨 조정.

E. PVC 관련(경계)

PVC 미바인드면 보통 Pod가 Pending으로 멈춥니다.
CreateContainerConfigError라면 마운트/경로/권한 구성 오류 가능성에 초점.

F. 사전 검증/디버깅

로컬 스키마 검증: kubeconform/kubectl apply --dry-run=client -f ...
이벤트 타임라인: kubectl get events --sort-by=.lastTimestamp
에페메럴 디버그 컨테이너로 마운트/권한 확인:
kubectl debug -it pod/<pod> --target=<container> --image=nicolaka/netshoot

Azure Virtual Network 암호화

ktzzang0601 — Mon, 25 Aug 2025 18:37:00 +0900

1. 의미

Azure Virtual Networks의 기능으로 가상 네트워크 암호화를 사용하면 DTLS 터널을 만들어 Azure Virtual Machines 간에 트래픽을 원활하게 암호화 및 암호 해독할 수 있음.
가상 네트워크 암호화를 사용하면 동일한 가상 네트워크 내에서 Virtual Machines와 Virtual Machine Scale Sets 간의 트래픽을 암호화할 수 있습니다. 가상 네트워크 암호화는 지역적으로 피어링된 가상 네트워크와 전역적으로 피어링된 가상 네트워크 간의 트래픽을 암호화

2. 주요 제약사항

암호화는 가상 네트워크의 가상 머신 간의 트래픽에만 적용됩니다. 트래픽은 개인 IP 주소에서 개인 IP 주소로 암호화
가상 네트워크에서 암호화를 사용하도록 설정한 후에는 기존 가상 머신의 시작/중지가 필요
내부 부하 분산 장치의 경우, 부하 분산 장치 뒤에 있는 모든 가상 머신은 지원되는 가상 머신 SKU에 있어야 합니다
AllowUnencrypted는 일반 공급에서 유일하게 지원되는 적용입니다. DropUnencrypted 적용은 향후 지원될 예정
암호화가 사용하도록 설정된 가상 네트워크는 Azure DNS Private Resolver, Application Gateway 및 Azure Firewall을 지원하지 않습니다
Azure ExpressRoute 게이트웨이가 있는 가상 네트워크에서는 가상 네트워크 암호화를 사용하도록 설정해서는 안 됩니다.
Azure Private Link 서비스로 구성된 가상 네트워크는 Virtual Network 암호화를 지원하지 않으므로 이러한 Virtual Network에서는 Virtual Network 암호화를 사용하도록 설정해서는 안 됨.
부하 분산 장치에 대한 연결 실패를 방지하기 위해 내부 부하 분산 장치의 백 엔드 풀에는 네트워크 인터페이스 보조 IPv4 구성이 포함되어서는 안 됨.
Azure 기밀 컴퓨팅 VM SKU가 있는 가상 네트워크에서는 Virtual Network 암호화를 사용하도록 설정하면 안 됩니다.
지역 피어링, 글로벌 피어링을 통한 가상 머신 간 트래픽에서 지원됩니다.
Azure CNI(일반 또는 오버레이 모드), Kubenet 또는 BYOCNI를 사용하는 AKS에서 지원됩니다. 노드 및 Pod 트래픽이 암호화됩니다.
Azure CNI 동적 Pod IP 할당(podSubnetId 지정)을 사용하여 AKS에서 부분적으로 지원됩니다. 노드 트래픽은 암호화되지만 Pod 트래픽은 암호화되지 않습니다.
AKS 관리 컨트롤 플레인에 대한 트래픽이 가상 네트워크에서 송신되므로 가상 네트워크 암호화 범위에 포함되지 않습니다. 그러나 이 트래픽은 항상 TLS를 통해 암호화됩니다.

3. 추가 암호화 설계

외부 인터넷 -> WAF 구간 : mTLS 및 SSL/TLS 1.2버전 이상 통신 암호화 적용
WAF -> F/W 구간 : SSL/TLS 1.2버전 이상 통신 암호화 적용
MSA Service <-> 타 시스템 호출 구간 : SSL/TLS 1.2버전 이상 통신 암호화 적용
Application : Always Encrypted + Dynamic Data Masking 동시 사용
DBMS - SQL Management Instance : TDE(Transparent data encryption)을 이용한 스토리지 암호화
Azure Files : CMK 기반의 SSE 지원 설정 혹은 Key Vault + MI 권한 설정 관리를 통한 암호화
Azure Blob Storage : Azure Key Vault에 저장된 CMK를 사용하여 암호화

4. 네트워크 암호화

Azure VPN Gateway는 IPsec/IKE 기반 암호화 터널을 사용하며, 내부적으로 AES256/SHA2/PFS 같은 알고리즘을 조합한다
ExpressRoute → 기본은 암호화 없음. 필요 시
- MACsec(L2) : ExpressRoute Direct서 포트 단 암호화(BYOK, Key Vault 보관).
- IPsec over ER : VPN over ExpressRoute(끝단 간 L3 암호화) 조합 가능.
Virtual Network Encryption (VNE) → 동일 VNet/피어링 간 VM↔VM 트래픽을 DTLS로 암호화. 특정 VM SKU/Accelerated Networking 요구, 일부 네트워크 리소스와 비호환.
Azure Files: 기본적으로 SMB 3.x + 암호화 필수(암호화 미지원 클라이언트 연결 거부)

5. 참고 문서

Azure Virtual Network 암호화란? https://learn.microsoft.com/ko-kr/azure/virtual-network/virtual-network-encryption-overview

PV/PVC with Azure File 구성시 필요한 Network 설정

ktzzang0601 — Mon, 25 Aug 2025 11:13:58 +0900

1. Azure File + PV/PVC 구성 개요

Kubernetes 환경에서 **Persistent Volume(PV)**과 **Persistent Volume Claim(PVC)**를 Azure File 스토리지로 구성하려면,
단순히 YAML로 PV/PVC를 정의하는 것뿐만 아니라 네트워크 설정이 반드시 뒷받침되어야 합니다.
Azure File은 SMB(서버 메시지 블록) 프로토콜을 사용하므로, 네트워크 라우팅, DNS, 방화벽(NSG) 규칙 등이 제대로 설정되어 있어야 정상적으로 마운트됩니다.
PV (Persistent Volume)
클러스터 관리자가 프로비저닝한 스토리지 리소스로, 스토리지의 실제 물리적/클라우드 리소스에 대한 추상화 레이어.
PVC (Persistent Volume Claim)
개발자/애플리케이션이 요청하는 스토리지 요구사항. PV에 매칭되어 바인딩됨.
Azure File
Azure Storage 계정에서 제공하는 SMB 3.0 기반 네트워크 파일 공유 서비스. Kubernetes에서는 csi.azure.com 드라이버를 통해 접근.

2. 네트워크 설정의 핵심 포인트

(1) 접근 경로

Azure File은 퍼블릭 엔드포인트 또는 **프라이빗 엔드포인트(Private Endpoint)**로 접근 가능.
보안 강화를 위해 AKS 클러스터와 같은 VNet 내부에 Private Endpoint 구성 권장.

(2) DNS 해석

Private Endpoint 사용 시, Azure Storage의 FQDN({storageaccount}.file.core.windows.net)이 Private IP로 해석되도록 Azure Private DNS Zone 설정 필요.
Private DNS Zone 링크: privatelink.file.core.windows.net
AKS VNet과 DNS Zone을 연결(VNet Link)해야 함.

(3) 네트워크 라우팅

AKS 노드 → Azure File Storage까지의 경로 확인.
VNet이 피어링된 경우, PEERING 설정에서 "Allow forwarded traffic" 및 "Allow gateway transit" 활성화 필요.
On-prem과 연결 시 ExpressRoute 또는 VPN Gateway 사용 가능.

(4) 방화벽(NSG) 규칙

SMB 포트(445/TCP) 허용.
Azure File에 접근하는 서브넷에서 Outbound 445/TCP가 막혀 있으면 마운트 불가.
Private Endpoint 사용 시에도 해당 포트 허용 필요.

(5) 스토리지 방화벽

Storage Account의 "방화벽 및 가상 네트워크" 설정에서 AKS 서브넷 허용.
Private Endpoint 사용 시 Public Access 차단 가능.

(6) 인증

Azure File PV/PVC는 Storage Account Key 또는 Azure AD 기반 SMB 인증 지원.
Storage Account Key를 Secret로 저장 후 PV/PVC YAML에 참조.
Azure AD 인증 시, AKS 노드가 Azure File 리소스에 접근 가능한 Managed Identity 권한 필요.

3. PV/PVC + Azure File 네트워크 구성 절차 (Private Endpoint 기준)

Storage Account 생성
- Performance: Standard (HDD) 또는 Premium (SSD)
- Account kind: StorageV2
- File shares 기능 활성화.
Private Endpoint 생성
- Target sub-resource: file
- 연결할 VNet/Subnet 지정.
- Private DNS Zone(privatelink.file.core.windows.net)에 자동 등록되도록 설정.
Private DNS Zone 구성
- privatelink.file.core.windows.net Zone 생성.
- Private Endpoint의 Private IP가 A 레코드로 등록되어야 함.
- AKS VNet과 DNS Zone을 링크.
NSG 설정
- AKS 노드 서브넷에 Outbound 445/TCP 허용.
- 필요 시 Inbound SMB 규칙도 설정(특정 상황에서만).
스토리지 방화벽 설정
- Public access 차단.
- Private Endpoint 서브넷만 허용.
인증 구성
- Storage Account Key를 Kubernetes Secret에 저장.
- 또는 Managed Identity에 Azure File Data SMB Share Contributor 권한 부여.

4. 주요 용어 정리

PV (Persistent Volume)	클러스터에서 사용할 수 있는 스토리지 리소스의 추상화 객체
PVC (Persistent Volume Claim)	사용자가 요청하는 스토리지 요구사항, PV에 바인딩
Azure File	SMB 기반 클라우드 파일 공유 서비스
Private Endpoint	VNet 내부에서 Azure 서비스에 Private IP로 연결
Private DNS Zone	Private Endpoint 연결 시 서비스 FQDN을 Private IP로 해석하는 DNS Zone
NSG (Network Security Group)	Azure 네트워크의 방화벽 역할
SMB (Server Message Block)	파일 공유를 위한 네트워크 프로토콜
Storage Account Key	Storage Account 인증을 위한 키
Managed Identity	Azure 리소스에 부여되는 인증 아이덴티티
Azure CSI Driver	Kubernetes에서 Azure 스토리지를 사용하기 위한 Container Storage Interface 드라이버

5. 관련 문서

원본 게시글 : https://seongduck.tistory.com/488
AKS(Azure Kubernetes Service)에서 Azure Files CSI(Container Storage Interface) 드라이버 사용 https://learn.microsoft.com/ko-kr/azure/aks/azure-files-csi

Azure Storage 암호화

ktzzang0601 — Mon, 25 Aug 2025 08:38:37 +0900

1. Azure Storage 암호화 개요

Azure는 저장 데이터(At Rest)와 전송 데이터(In Transit) 모두에 대해 암호화를 제공합니다. 이 암호화는 서버측에서 자동으로 적용되거나, 필요에 따라 사용자가 클라이언트측에서 직접 수행할 수도 있습니다. 또한 ES-256 같은 강력한 암호화 알고리즘과 Key Vault를 통한 중앙 집중형 키 관리 기능을 제공해 기업이 보안과 규정 준수를 동시에 달성할 수 있습니다.

2. 미사용 데이터 암호화

미사용 데이터 암호화는 디스크, Blob, File, Table, SQL Database, Cosmos DB 등 다양한 스토리지 서비스에 적용됩니다.
- 서버측 암호화(SSE): Azure가 저장 전에 자동으로 암호화하고, 읽을 때 자동 복호화
- 클라이언트측 암호화: 업로드 전에 사용자가 직접 암호화
서비스별 주요 특징

3. 전송 중 데이터 암호화

TLS(전송 계층 보안): 클라이언트와 서버 간 및 모든 클라우드-클라이언트 통신 보호. PFS 지원.
ex> Azure Storage와 REST API를 사용할 때 HTTPS만 허용하도록 설정하면 중간자 공격을 방지할 수 있습니다.
PFS(Perfect Forward Secrecy): 세션 키 보호
MACsec: 데이터센터 간 네트워크 링크 암호화
SMB 3.0: 파일 공유 전송 암호화 (Windows Server 2012+).
VPN Gateway(IPsec/IKE, 사이트 간/지점 연결 암호화) / SSH(비대칭키) / RDP(TLS): 안전한 원격 접속 및 데이터 전송
데이터 링크 계층: MACsec(IEEE 802.1AE)로 데이터센터 간 링크 암호화, 기본 적용.
Azure Storage 접근 시 HTTPS 필수 설정 및 SAS 토큰 사용시 HTTPS 강제 기능

4. 키 관리 전략

Azure Key Vault는 암호화 키, 비밀, 인증서를 안전하게 저장하고 접근을 제어합니다.
- 서비스 관리 키(SMK): Azure에서 자동 관리
- 고객 관리 키(CMK): BYOK(Bring Your Own Key) 지원
- HYOK(Host Your Own Key): 고객의 하드웨어에서 완전 관리
Key Vault를 활용하면 키를 주기적으로 순환하고, HSM(Hardware Security Module)에서 안전하게 생성 및 저장할 수 있습니다.

5. 보안 모범 사례

보안 전송 강제 적용
- 스토리지 계정에서 ‘Secure Transfer Required’를 켜고 HTTPS만 허용하세요.
BYOK 적용 시 주기적 키 순환
- 데이터 보호와 규정 준수를 위해 키를 주기적으로 변경해야 합니다.
모니터링 및 감사 활성화
- Azure Monitor와 함께 Key Vault 진입 시도를 로깅하면 보안 위협을 신속히 탐지할 수 있습니다.

6. 미사용 데이터 암호화 (At Rest Encryption)

대상: 디스크, Blob, Table Storage, SQL DB, Cosmos DB, Data Lake 등 저장된 모든 데이터.
기술: 기본적으로 AES-256 사용.
암호화 모델
1. 서비스 관리 키 (Microsoft 관리) – 편리하지만 고객 제어 낮음.
2. 고객 관리 키 (BYOK) – Key Vault로 직접 관리.
3. 고객 제어 하드웨어 키 (HYOK) – 자체 하드웨어에서 관리, 제한적 지원.
• 클라이언트 쪽 암호화: Azure 외부에서 암호화 후 업로드. 키는 고객이 완전 제어.
• 서버 쪽 암호화: Azure가 데이터 저장 시 자동 암호화·해독.
• 서비스별 특징
- Disk Encryption: 관리 디스크·스냅샷 모두 암호화.
- Storage Service Encryption(SSE): Blob·File 저장 전 자동 암호화.
- Azure SQL:
* TDE(투명 데이터 암호화) – 서버 쪽, 기본 활성화.
* Always Encrypted – 클라이언트 쪽, 민감 데이터 보호.
* CLE(셀·열 수준 암호화) – 더 세밀한 단위 암호화.
- Cosmos DB: 기본 암호화 + 선택적 CMK 이중 암호화.
- Data Lake: 기본 자동 암호화, 키 직접 관리 가능.

7. 키 관리 (Azure Key Vault)

역할: 암호화 키 보관·관리·액세스 제어.
특징
- HSM 기반, Microsoft는 키 열람 불가.
- 고객이 키 생성·가져오기·순환 가능.
- Microsoft Entra 계정 기반 권한 부여.
- 장점: 하드웨어·패치·운영 부담 제거, 보안성·관리 편의성 향상.

8. 참고 문서

미사용 데이터에 대한 Azure Storage 암호화 https://learn.microsoft.com/ko-kr/azure/storage/common/storage-service-encryption
Azure 암호화 개요 https://learn.microsoft.com/ko-kr/azure/security/fundamentals/encryption-overview

Azure Monitoring 활용시 LogData 효율적 관리에 대해

ktzzang0601 — Sun, 24 Aug 2025 11:46:26 +0900

1. Azure Monitor 및 기본 개념 정리

(1) Azure Monitor
• Azure 전반의 리소스 상태, 성능, 보안 이벤트를 수집·분석하는 플랫폼 서비스
• 메트릭과 로그 두 가지 데이터 형식 지원

(2) Log Analytics
• Azure Monitor 로그 데이터를 저장하고 Kusto Query Language(KQL)로 분석하는 서비스
• 데이터 수집, 저장, 쿼리에 따라 비용 부과

(3) Diagnostic Settings
• 어떤 리소스에서 어떤 종류의 로그를 어디로 보낼지 설정하는 기능
• 예: Log Analytics, Storage Account, Event Hub

(4) Retention Policy (보존 정책)
• 로그 데이터를 저장하는 기간을 지정
• 저장기간이 길수록 비용 증가, 짧게 하면 비용 절감

(5) Sampling (샘플링)
• Application Insights에서 모든 요청·트랜잭션 로그를 수집하지 않고 일부만 수집하는 기능
• 트래픽이 많은 서비스에서 비용 절감에 효과적

(6) Basic Logs vs Analytic Logs
• Basic Logs: 장기간 저장, 검색 빈도가 낮은 로그 (저렴)
• Analytic Logs: 쿼리·분석이 많은 로그 (비쌈)

(7) Archive Tier
• 장기간 사용하지 않는 로그를 저비용 저장소에 보관하는 방식
• 검색 시 복원 시간이 필요

2. 최적화 개요

(1) 수집 단계에서 절감
• Diagnostic Settings에서 불필요한 로그 카테고리 제외
• Application Insights에서 Sampling 설정 적용 (예: 100% → 20%)

(2) 저장 단계에서 절감
• Retention Policy로 저장기간 단축 (예: 90일 → 30일)
• 자주 쓰지 않는 데이터는 Archive Tier로 이동

(3) 분석 단계에서 절감
• 쿼리 실행 횟수 최소화
• 동일한 쿼리를 반복 실행 시 쿼리 결과 캐싱 또는 Export 기능 활용

(4) 로그 형식 구분
• 자주 분석하는 데이터: Analytic Logs
• 거의 조회하지 않는 데이터: Basic Logs로 설정

(5) 외부 저장소 연계
• 장기 보관 필요 시 Log Analytics가 아닌 Azure Storage에 보관 → 저렴한 저장 비용 + 규제 준수 가능

3. 세부 내용 설명

(1) 수집할 로그 데이터량 최적화

필요한 데이터만 수집하세요. 수집 대상 및 조건을 신중히 설정해 불필요한 로그를 줄여야 합니다.
→ 예: 진단 설정(Diagnostic setting), 데이터 수집 규칙(Data Collection Rule, DCR)을 통해 특정 이벤트/로그 수준만 수집하도록 제한
테이블별 Basic Logs 플랜 활용
디버깅 또는 드문 쿼리에만 필요한 테이블은 Basic Logs 플랜으로 설정해 데이터 수집 비용을 낮출 수 있습니다. 단, 일부 기능 제한이 있습니다.

(2) 가격 모델 및 티어 활용

**Commitment 티어 (예약량 기반 요금제)**로 전환 시, 데이터 수집량이 많을 때 단가를 낮출 수 있습니다. 기본은 페이-애즈-유-고(Pay-as-you-go)
데이터 보관 기간 최적화
기본 보존 기간 이후 장기 보존이 필요하지 않다면 데이터를 자동으로 삭제해 저장 공간과 비용을 줄이세요

(3) 모니터링 및 알림 기반 관리

Log Analytics Workspace Insights를 통해 로그 수집량 트렌드를 시각화하고, 어떤 솔루션이나 테이블이 과다 수집의 주범인지를 파악할 수 있습니다
Alert (알림) 설정으로 이상 전송량 대응
예시: 하루 50GB 이상 로그가 수집되면 알림을 받도록 설정하여 비용 예측력을 높이고, 필요 시 즉시 대응할 수 있습니다
Azure Advisor 비용 최적화 권장사항 적용
Advisor가 자동으로 제안하는 ‘Basic Logs 사용’, ‘프리미엄 요금제 전환’ 등 권고사항을 알림으로 설정해 놓으면, 실시간으로 비용 절감 기회를 놓치지 않을 수 있습니다

(4) 데이터 분석 기반 원인 탐지

Usage 테이블
워크스페이스별, 솔루션별, 테이블별 수집된 청구 대상(billable) 데이터 양을 분석할 수 있습니다. 예시 쿼리도 제공되어 있습니다
_IsBillable, _BilledSize 컬럼 활용
실제 과금이 발생하는 개별 로그 항목 및 사이즈를 상세 분석해, 어떤 이벤트가 비용을 유발하는지 구체적으로 확인할 수 있습니다
자원, 리소스 그룹, 컴퓨터 단위 분석
어느 리소스나 VM이 로그를 많이 생성하고 있는지 단위별 분석해 수집 전략을 세울 수 있어요

(5) 쿼리 최적화 및 성능 관리

쿼리 최적화는 직접적인 수집 사이징보다는 간접적인 비용 절감에 도움이 됩니다.효율적인 쿼리는 CPU, 멀티스레드 활용, 메모리 등 자원 소비를 줄여 전체 처리 비용을 절감시키고, 쿼리 지연이나 스로틀링도 방지합니다

4. 요약

전략 영역	수행 지침 요약
수집량 최적화	필요한 데이터만 수집, Basic Logs 플랜 적용(빠른 분석 필요시 Analytic)
가격 모델 활용 및 티어 조정	Commitment 이용, 불필요 보존기간 줄임(보유 정책 조정)
모니터링 및 알림 설정	Workspace 인사이트, 데이터 사용량 알림
원인 분석 기반 개선	Usage 테이블, 상세 쿼리 분석(저/고빈도 조회 로그 분석), 리소스별 검토
쿼리 최적화	효율적인 KQL 작성으로 처리 비용 절감, 샘플링 기법으로 일부 로그 수집
외부 저장소 Export	규제 준수 및 비용 절감을 위해 외부 저장 방법도 추가 고려 사항

5. 참고 문서

[Azure Monitor Logs cost calculations and options] Azure 문서+9Microsoft Learn+9Microsoft Learn+9
[Best practices for Azure Monitor Logs] (비용 관리 및 운영 · 수집 최적화 관련) Microsoft Learn
[Analyze usage in a Log Analytics workspace] (Usage 분석 및 알림 설정) Microsoft Learn+1
[Optimize log queries in Azure Monitor] (쿼리 성능 최적화) Microsoft Learn+1

Azure Native 보안과 네트워크 보안 서비스 이해

ktzzang0601 — Sun, 24 Aug 2025 10:41:04 +0900

1. Azure Native 보안이란?

Azure에서 기본적으로 제공하는 보안 관련 기능 및 서비스를 의미
NSG → Firewall → WAF/DDoS → Private Link/Bastion 같은 네트워크 계층 보안과, Defender for Cloud, Sentinel 같은 운영/모니터링 서비스가 유기적으로 맞물려 클라우드에서 기본적으로 제공되는 End-to-End 보안 프레임워크

2. Azure 보안의 핵심 사상

클라우드 내장 보안(Platform-level Security)
Azure 인프라 전반에 걸쳐 MS가 기본 제공하는 보안 기능 (네트워크, 데이터, ID, 애플리케이션 보안 포함).
Zero Trust 기반
“아무도 신뢰하지 않는다(never trust, always verify)” 원칙으로, 네트워크 경계뿐 아니라 사용자·디바이스·애플리케이션 모두 지속적으로 검증.
통합 관리
Azure Security Center(현재는 Microsoft Defender for Cloud) 같은 서비스로 보안 posture를 모니터링하고 권고사항 제공.
자동화 & 위협 인텔리전스
Microsoft의 글로벌 위협 인텔리전스 기반으로 보안 로그/이벤트를 자동 분석해 대응.

3. 네트워크 서비스 종류와 특징

(1) 네트워크 보안 그룹 (NSG, Network Security Group)

VM, Subnet 수준에서 인바운드/아웃바운드 트래픽을 제어하는 방화벽 룰.
L3/L4 기반 (IP, 포트, 프로토콜).
기본적인 "보안 그룹"으로 AWS의 SG와 유사.

(2) Azure Firewall

Fully managed 방화벽 서비스 (stateful firewall).
L3~L7 트래픽 필터링 가능.
FQDN 필터링, Application rule, Threat Intelligence 기반 차단 지원.
고가용성 및 확장 자동 제공.
아웃바운드·인바운드 트래픽 필터링

(3) Web Application Firewall (WAF)

Application Gateway WAF: L7 로드밸런서 + WAF 기능 (OWASP Top 10 공격 방어).
Azure Front Door WAF: 글로벌 CDN + WAF (전 세계 트래픽 보호).
SQL Injection, XSS 등 웹 공격 방어.

(4) DDoS Protection

기본 제공(Free) + 표준(Advanced) 버전.
L3/L4 네트워크 공격 자동 완화.
Standard 버전은 Adaptive Tuning, 공격 분석 리포트, SLA 제공.
대규모 분산 서비스 거부 공격(DDOS) 방어

(5) Private Link & Service Endpoints

Azure 서비스에 대한 비공개 연결 제공.
인터넷 노출 없이 VNet 내부에서만 서비스 접근 가능.

(6) Azure Bastion

Public IP 없이도 포털 기반으로 안전하게 VM에 RDP/SSH 접속 가능.
Jump server 없이도 관리 가능 → 원격 접속 보안 강화.

(7) Azure DDoS + Threat Intelligence + Sentinel

Azure Sentinel: 클라우드 기반 SIEM/SOAR → 로그 수집, 위협 탐지, 자동화 대응.
Threat Intelligence 통합: 글로벌 위협 데이터로 정책 강화.

(8) Azure Sentinel

SIEM(Security Information and Event Management) + SOAR(Security Orchestration, Automation and Response) 기능 제공
온·오프프레미스, 멀티클라우드, SaaS 애플리케이션의 보안 이벤트를 수집·분석
머신러닝 기반 위협 감지, 자동 대응

(9) Microsoft Defender for Identity

온프레미스 AD 환경과 Azure AD 간 계정·인증 위협 탐지
의심스러운 로그인 패턴, 권한 상승 시도 감지

(10) Microsoft Defender for Endpoint

엔드포인트 보안 → 악성코드, 랜섬웨어, 취약점 보호
침입 방지, 위협 사냥(Threat Hunting) 가능

(11) Azure Key Vault

비밀 값(Secrets), 암호화 키(Keys), 인증서(Certificates) 안전 저장
CMK(Customer Managed Key) 사용 가능

(12) Microsoft Entra ID (Azure AD) 보안 기능

조건부 액세스(Conditional Access)
MFA(Multi-Factor Authentication)
ID 보호(ID Protection)

(13) Azure Policy + Blueprints

조직 전체 리소스에 보안 규칙 강제 적용
• 예: 특정 지역에만 리소스 생성 허용, 암호화 필수화

(14) Azure DDoS + Threat Intelligence + Sentinel

Azure Sentinel: 클라우드 기반 SIEM/SOAR → 로그 수집, 위협 탐지, 자동화 대응.
Threat Intelligence 통합: 글로벌 위협 데이터로 정책 강화.

4. 참고링크

Azure 보안 개요 : https://learn.microsoft.com/ko-kr/azure/security/fundamentals/overview
Azure Network 보안 개요 : https://learn.microsoft.com/ko-kr/azure/networking/security/network-security?toc=%2Fazure%2Ffirewall%2Ftoc.json&bc=%2Fazure%2Ffirewall%2Fbreadcrumb%2Ftoc.json

Support VM OS SKU 및 Migration 방법

ktzzang0601 — Sun, 24 Aug 2025 09:43:33 +0900

1. Azure Migrate 이란?

Azure Migrate는 Azure로의 마이그레이션을 결정, 계획 및 실행하는 데 도움이 되는 서비스입니다. Azure Migrate를 사용하면 최상의 마이그레이션 방법을 찾고, Azure 준비 상태 및 Azure에서 워크로드를 호스트하는 비용을 평가하고, 가동 중지 시간 및 위험을 최소화하여 마이그레이션을 수행할 수 있습니다. Azure Migrate는 Azure Data Box를 사용하여 서버, 데이터베이스, 웹앱, 가상 데스크톱 및 대규모 오프라인 마이그레이션을 지원합니다.

2. VMware To Azure Migration 방식

Agentless (권장/기본, VMware 전용)
- vCenter + VMware 스냅샷/CBT로 증분 복제. 게스트 OS에 설치 없음. 대규모(최대 300~500대 동시)까지 스케일아웃 어플라이언스로 확장. 일부 제한(예: VMDK 이름에 비-ASCII 문자가 있으면 미지원)
Agent (대안)
- 각 서버에 Mobility Service를 설치해 블록 단위로 거의 연속 복제. 온프레미스 VMware는 물론 물리 서버·타 클라우드(AWS/GCP) 이전에도 사용. 포트/구성요소(복제 어플라이언스/프로세스 서버/443·9443 등) 요건이 있음.

3. 제약 사항

설정	Agentless	Agent
Azure 권한	Azure Migrate 프로젝트를 만들고, Azure Migrate 어플라이언스를 배포할 때 만든 Microsoft Entra 앱을 등록하기 위한 권한이 필요합니다.	Azure 구독에 대한 기여자 권한이 필요합니다.
복제	스케일 아웃 어플라이언스를 사용하여 여러 vCenter Server(하나의 어플라이언스에서 검색됨)에서 최대 500개의 VM을 동시에 복제할 수 있습니다. 포털에서 복제할 머신을 한 번에 10대까지 선택할 수 있습니다. 더 많은 머신을 복제하려면 10대 일괄 처리를 추가합니다.	복제 어플라이언스의 크기를 스케일링하면 복제 용량을 늘릴 수 있습니다.
어플라이언스 배포	Azure Migrate 어플라이언스는 온-프레미스에 배포됩니다.	Azure Migrate 복제 어플라이언스는 온-프레미스에 배포됩니다.
Site Recovery 호환성	호환 가능합니다.	Site Recovery를 사용하여 머신 복제를 설정한 경우 마이그레이션 및 현대화 도구로 복제할 수 없습니다.
대상 디스크	관리 디스크	관리 디스크
디스크 제한	OS 디스크: 2TB 데이터 디스크: 32TB 최대 디스크: 60	OS 디스크: 2TB 데이터 디스크: 32TB 최대 디스크: 63
통과 디스크	지원되지 않음	지원됨
UEFI 부팅	지원	지원
연결	공용 인터넷 개인 피어링을 사용하는 ExpressRoute Microsoft 피어링을 사용하는 ExpressRoute 사이트 간 VPN	공용 인터넷 개인 피어링을 사용하는 ExpressRoute Microsoft 피어링을 사용하는 ExpressRoute 사이트 간 VPN

4. 배포 단계

과업	세부 정보	Agentless	Agent
Azure Migrate 어플라이언스 배포	VMware VM에서 실행되는 경량 어플라이언스입니다. 해당 어플라이언스는 머신을 검색 및 평가하고 에이전트 없는 마이그레이션을 사용하여 머신을 마이그레이션하는 데 사용됩니다.	필수. 평가를 위해 어플라이언스를 이미 설정한 경우 에이전트 없는 마이그레이션에 동일한 어플라이언스를 사용할 수 있습니다.	필수 아님. 평가를 위해 어플라이언스를 설정한 경우 해당 어플라이언스를 그대로 두거나 평가가 완료된 경우 제거할 수 있습니다.
서버 평가 도구 사용	Azure Migrate: 서버 평가 도구를 사용하여 머신을 평가합니다.	평가는 선택 사항입니다.	평가는 선택 사항입니다.
마이그레이션 도구 사용	Azure Migrate 프로젝트에 마이그레이션 및 현대화 도구를 추가합니다.	필수	필수
마이그레이션을 위해 VMware 준비	VMware 서버 및 VM에 대한 설정을 구성합니다.	필수	필수
VM에 Mobility Service 설치	Mobility Service는 복제하려는 각 VM에서 실행됩니다.	필요하지 않음	필수
복제 어플라이언스 배포	복제 어플라이언스는 에이전트 기반 마이그레이션에 사용되며 VM에서 실행되는 Mobility Service와 마이그레이션 및 현대화 도구 간에 연결됩니다.	필요하지 않음	필수
VM 복제. VM 복제를 사용하도록 설정.	복제 설정을 구성하고 복제할 VM을 선택	필수	필수
테스트 마이그레이션 실행	테스트 마이그레이션을 실행하여 모든 것이 예상대로 작동하는지 확인합니다.	필수	필수
전체 마이그레이션 실행	VM 마이그레이션.	필수	필수

5. Agentless 추가 특징

vCenter에 연결해 게스트 OS에 에이전트 설치 없이 VMware VM을 Azure로 복제/마이그레이션하는 방식
전용 복제 어플라이언스(어플라이언스/게이트웨이) 를 배포 → vCenter와 스토리지에서 스냅샷 기반 증분 복제 수집 → Azure로 전송 → 테스트 마이그레이션 후 컷오버
검색이 완료되면 검색된 서버를 그룹으로 수집하고 그룹별로 평가를 실행

6. Agentless 동작 흐름

발견(Discovery): vCenter 등록 → 인벤토리/성능 수집
평가(Assessment): 목표 Azure VM Size/SKU·디스크·비용 산정
복제(Replication): 초기 전체 → 이후 증분 복제(CBT)
테스트 마이그레이션: 다운타임 없이 검증 환경 부팅
마이그레이션(컷오버): 짧은 정지 후 전환, 최종 동기화

7. Agent 방식 제약 사항 상세 내용

(1) 지원 운영체제 (Windows + Linux)

Azure Migrate의 agent 기반(Migration and Modernization 툴) 마이그레이션 방식은 다양한 OS를 지원합니다.

Windows: Azure Migrate는 UEFI 기반 머신을 Azure Generation 2 VM으로 마이그레이션하며, BIOS 기반 머신은 Generation 1 VM으로 마이그레이션됩니다 TECHCOMMUNITY.MICROSOFT.COM+6Microsoft Learn+6Reddit+6Reddit+9Microsoft Learn+9Microsoft Learn+9.
지원되는 OS 목록:
- Windows Server: 2025, 2022, 2019, 2016, 2012, 2012 R2 (단, EOS 버전은 안정성 보장 안 됨)
- Windows 10 / 11 (Pro, Enterprise)
- Linux 분포:
  - SUSE: Enterprise Server 15 SP1–SP6, 12 SP4
  - Ubuntu Server: 16.04 LTS, 18.04 LTS, 20.04 LTS, 22.04 LTS
  - RHEL: 6.x, 7.x (7.0–7.8), 8.0–8.1, 9.x
  - CentOS Stream
  - Oracle Linux: 6, 7.7, 7.7‑CI, 8, 9
- 모든 경우에 대해 agentless/agent 기반 VMware 및 agentless Hyper‑V 방식 모두 지원

주의: Windows Server 2003, 2008, 2012, 2012 R2와 같이 EOS(End of Support)된 운영체제는 Azure Migrate가 일관되고 안정적인 결과를 보장하지 않으며, 마이그레이션 전 업그레이드를 강력히 권고합니다

(2) 물리 서버 (또는 OS-불특정 머신) 마이그레이션에서의 OS 제약

agent 기반 방식은 물리 서버 마이그레이션에도 활용되는데, 이 경우 다음과 같은 OS 및 스토리지 관련 제약사항이 존재합니다:

파일 시스템 및 파티션:
- Windows: NTFS만 지원
- Linux: ext4, xfs, btrfs 지원
  — ZFS, UFS, ReiserFS, DazukoFS 등은 지원하지 않거나 특별 마운트 절차 필요
- 예: ReiserFS는 명시적으로 “지원되지 않음”으로 언급됨
디스크/볼륨 제약:
- UEFI Secure Boot: 지원되지 않음
- OS 디스크 크기: Gen 1 VM 최대 2 TB / Gen 2 VM 최대 4 TB. 데이터 디스크는 최대 32 TB까지 지원
- 디스크 수: 최대 63개까지
- 암호화된 디스크/볼륨: 마이그레이션 대상에서 제외됨
- 공유 디스크 클러스터: 지원되지 않음
- NFS, iSCSI, 페어링 NIC, IPv6, PV 드라이버 등: 여러 항목에서 제약 눈에 띔
  - 예: iSCSI 대상 머신은 agentless 마이그레이션에선 지원되지 않음.
  - 멀티패스 IO는 Windows 서버에서 특정 조건 하에서만 지원
VM 설정 제한:
- BitLocker 활성화된 경우 복제 체크 실패 → BitLocker 비활성화 필요
- VM 이름 조건: 1~63자, 영문·숫자·하이픈만 허용

8. WAAgent (WALinuxAgent)란?

정식 이름: Microsoft Azure Linux Agent (WALinuxAgent, 줄여서 waagent)
역할: Linux VM이 Azure 플랫폼과 통신할 수 있도록 해주는 핵심 에이전트, Azure 위에서 Linux VM이 정상적으로 동작하고 관리될 수 있도록 해주는 에이전트
기능:
1. VM 초기화: Azure Fabric에서 VM을 부팅할 때, 호스트에서 전달된 구성(Hostname, SSH 키, 사용자 계정 등)을 OS에 적용
2. 네트워킹: DHCP 클라이언트 역할을 하여 VM 네트워크 설정 관리
3. 스토리지 관리: Azure에서 제공하는 리소스 디스크를 자동으로 마운트하고 스왑 공간 구성
4. 확장(Extensions) 관리: Azure Backup, Monitoring, Security 확장 에이전트 등을 설치하고 관리
5. 상태 보고: VM의 상태/헬스 정보를 Azure Control Plane에 전달
6. 마이그레이션 시 필수 역할: 복제/스냅샷/에이전트 기반 마이그레이션에서 VM이 Azure와 통신하기 위해 필요
7. Azure Migrate (agent 기반)일 경우 Linux VM을 온프레미스 → Azure로 옮길 때, 마이그레이션 후 VM이 Azure 환경에 맞게 네트워킹/스토리지/헬스 리포팅 가능하도록 구성하며, 마이그레이션 전 해당 Linux VM에 waagent가 설치되어 있어야, 복제 후 부팅이 정상적으로 됨
8. Azure VM 운영 VM Insights, Log Analytics, Security Extensions 같은 관리 도구들이 모두 waagent를 통해 배포·실행되며, 없으면 VM이 Azure Portal에서 “Provisioning failed” 상태가 되거나, IP/디스크 설정이 안 잡히는 문제 발생 가능.

9. 참고 문서

VMware 마이그레이션 옵션 선택 https://learn.microsoft.com/ko-kr/azure/migrate/server-migrate-overview?view=migrate-classic

Dockerfile 기본 개념 및 레이어 구성 원리

ktzzang0601 — Sat, 23 Aug 2025 03:08:04 +0900

1. 개념

도커 이미지(Docker Image)를 자동으로 만드는 설계도(스크립트)
Dockerfile은 텍스트 파일로, 어떤 베이스 이미지를 쓰고, 어떤 패키지/파일/설정을 넣을지, 마지막에 어떻게 실행할지를 단계별로 적어놓은 문서입니다.
Docker는 이 파일을 읽어 위에서 아래로 순차 실행하면서 이미지를 빌드합니다.

2. 기본 명령

실제 파일 변화를 만드는 명령: RUN, COPY, ADD → 읽기 전용 FS 레이어가 생성
메타데이터/구성 변경 중심: ENV, WORKDIR, USER, EXPOSE, VOLUME, LABEL, ENTRYPOINT, CMD, ARG 등
파일 내용을 늘리지는 않지만 이미지 구성(메타데이터) 는 바뀌고, 빌드 캐시 키에도 영향을 줍니다.
FROM 은 새 빌드 단계(stage) 를 시작합니다(멀티 스테이지에서 중요). 따라서 어떤 단계에서든 그 단계가 바뀌면 그 뒤의 모든 단계 캐시가 무효화되고 다시 빌드됩니다(계단식 무효화).

3. 빌드 캐쉬가 동작하는 방식

Docker/BuildKit은 “명령 + 입력(컨텍스트, 이전 레이어 해시 등)” 으로 캐시 키를 만들고, 같으면 재실행 없이 이전 레이어를 재사용합니다.
파일 복사(COPY/ADD) 는 복사되는 파일의 내용 해시가 바뀌면 캐시 무효.
ARG/ENV 값 변경 도 이후 단계 캐시를 깨뜨립니다.
네트워크 의존 RUN(예: apt-get) 결과도 캐싱되지만, 베이스 이미지 업데이트 등은 --pull(베이스 최신화) 또는 --no-cache(모든 캐시 무시) 같은 옵션으로 제어합니다.

4. Best Practice

- 변동이 적은 것 → 위로, 자주 바뀌는 것 → 아래로
  - 의존성 설치(자주 안 바뀜) 레이어를 먼저 만들고, 소스 코드 COPY 등 자주 바뀌는 단계는 뒤로 배치 → 캐시 적중률↑
- RUN 묶기 vs 가독성
  - 불필요한 레이어를 줄이려고 RUN 을 과도하게 한 줄로 합치기보다, 의미 단위로 적절히 묶되 레이어 수를 관리하세요.- - 패키지 매니저는 한 레이어에서 갱신/설치를 끝내고 캐시 파일 삭제까지 마무리
- .dockerignore 적극 사용
  - node_modules, .git, 빌드 산출물 등 캐시를 자주 깨뜨리는 불필요 파일을 빌드 컨텍스트에서 제외.
- ADD 대신 COPY
  - URL 자동 다운로드/압축 해제 등 암묵적 동작이 있는 ADD 대신, 예측 가능한 COPY 를 기본으로.
- 멀티 스테이지 빌드 로 최종 이미지 슬림화
  - 빌드 도구·헤더 등 개발용 레이어는 중간 단계에 남기고, 최종 스테이지는 실행 파일만 가져갑니다.
- BuildKit 고급 마운트
  - 캐시가 이미지에 포함되지 않도록
- 버전 고정 & 재현성
  - 패키지 버전을 고정(pinning)해 캐시 안정성을 높이고 “어제와 오늘 빌드가 다른” 상황을 줄입니다.
- VOLUME 주의
  - VOLUME /data 를 선언하면 해당 경로의 이후 변경은 컨테이너 볼륨에 매핑됩니다. VOLUME 선언 이전에 넣은 파일은 런타임에 보이지 않을 수 있으니 순서를 신중히.
- 베이스 이미지 최신화
  - 태그가 같은데 내용이 바뀐 경우를 대비해 정기적으로 --pull 로 베이스를 갱신하거나, digest(sha256:...) 고정을 검토하세요.
- 레이어/캐시 청소
  - 개발 환경 용량이 불어나면 docker system df, docker system prune, (BuildKit) docker builder prune 로 캐시/중간 레이어를 정리.

5. 레이어 구성 원리

Dockerfile의 각 RUN, COPY, ADD 명령은 새로운 레이어(layer) 를 만듭니다.
레이어는 캐시로 재사용 가능하고, 불변이라서 한 번 만들어지면 바뀌지 않습니다.
레이어를 많이 나누게 되면 얻는 이점/단점
- 캐시 효율 증대
- 문제 원인 추적이 쉬움
- 이미지 레이어 수가 늘어나면 저장/전송할 때 관리해야 할 블롭(blob)이 많아져서 오버헤드가 조금 생김.
- 불필요한 파일 누적 위험
레이어를 적게 묶어서 만드는 이점/단점
- 이미지 크기 최적화
- 전송/저장 효율 증대 : 레이어 수가 적어서 속도 저장 효율 올라감
- 캐시 효율이 떨어짐
- 가독성이 낮음

6. Dockerfile 주요 명령어 개념 및 예시

`FROM`: 베이스 이미지 지정 (ex: `FROM ubuntu:20.04`)
`RUN`: 이미지 빌드 시 실행할 커맨드 (ex: `RUN apt update && apt install -y nginx`)
`COPY`, `ADD`: 로컬 파일을 이미지 안으로 복사
`ENV`: 환경 변수 설정
`EXPOSE`: 컨테이너에서 서비스할 포트 명시
`CMD` 또는 `ENTRYPOINT`: 컨테이너 시작 시 실행할 명령어
RUN 명령어에서 여러 명령 병합 방법
- 여러 개 명령을 한 줄에서 실행할 때는 `&&`로 체이닝하여 이전 명령 성공 시 다음 명령 실행
예) `RUN apt update && apt install -y nginx`
- `\` (백슬래시) 사용해 여러 줄로 나눠 가독성 개선 가능
컨테이너 실행 흐름
1. Dockerfile 작성 (설치 및 설정 명령어 포함)
2. `docker build` 명령으로 이미지 생성 (Dockerfile대로 순차적 실행)
3. `docker run` 명령으로 이미지를 실행해 컨테이너 상태 시작
4. 컨테이너 안에서 앱 또는 서비스 동작

7. 결론

Dockerfile은 컨테이너 이미지 만드는 레시피
`RUN`은 이미지 만드는 동안 실행할 명령어 입력 (명령어 묶는 기법은 `&&`가 일반적)
빌드하면 `RUN` 명령어 순서대로 실행되며 이미지가 만들어짐
이미지를 기반으로 컨테이너를 실행해 서비스 구동하는 구조입니다.

8. 참고 문서

DockerFile image layer 구성 https://docs.docker.com/get-started/docker-concepts/building-images/understanding-image-layers/