AI/ML 워크로드 퀴즈

이 퀴즈는 Kubernetes에서 AI/ML 워크로드를 실행하는 방법에 대한 이해를 테스트합니다.

퀴즈 문제

1. Kubernetes에서 GPU를 사용하는 파드를 스케줄링할 때 필요한 리소스 요청 필드는 무엇인가요?

A. resources.requests.gpu B. resources.requests.nvidia.com/gpu C. resources.requests.k8s.io/gpu D. resources.requests.compute/gpu

정답 및 설명

정답: B. resources.requests.nvidia.com/gpu

설명: Kubernetes에서 GPU를 사용하는 파드를 스케줄링할 때 필요한 리소스 요청 필드는 resources.requests.nvidia.com/gpu입니다. 이는 NVIDIA GPU를 요청하는 표준 방법이며, 다른 GPU 공급업체는 자체 네임스페이스를 사용할 수 있습니다(예: amd.com/gpu).

GPU 리소스 요청 예시:

apiVersion: v1
kind: Pod
metadata:
  name: gpu-pod
spec:
  containers:
  - name: gpu-container
    image: nvidia/cuda:11.0-base
    resources:
      limits:
        nvidia.com/gpu: 1  # 1개의 GPU 요청
      requests:
        nvidia.com/gpu: 1  # 요청과 제한은 동일해야 함

GPU 리소스 특징:

1. 정수 할당: GPU는 정수 단위로만 할당할 수 있습니다(예: 1, 2, 3). 소수점 값(예: 0.5)은 지원되지 않습니다.

2. 요청과 제한 일치: GPU 리소스의 경우 requests와 limits는 동일해야 합니다.

3. 독점적 사용: 기본적으로 GPU는 컨테이너 간에 공유되지 않습니다. 각 GPU는 한 번에 하나의 컨테이너에만 할당됩니다.

4. 노드 레이블: GPU가 있는 노드는 일반적으로 nvidia.com/gpu 레이블로 표시됩니다.

GPU 사용을 위한 사전 요구 사항:

1. 노드에 GPU 하드웨어: 노드에 물리적 GPU가 설치되어 있어야 합니다.

2. GPU 드라이버: 노드에 적절한 GPU 드라이버가 설치되어 있어야 합니다.

3. NVIDIA Device Plugin: Kubernetes 클러스터에 NVIDIA Device Plugin이 설치되어 있어야 합니다.

4. 컨테이너 런타임 지원: 컨테이너 런타임이 GPU를 지원해야 합니다.

NVIDIA Device Plugin 설치:

# Helm을 사용한 설치
helm repo add nvdp https://nvidia.github.io/k8s-device-plugin
helm repo update
helm install nvidia-device-plugin nvdp/nvidia-device-plugin

# 또는 직접 설치
kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.13.0/nvidia-device-plugin.yml

GPU 리소스 확인:

# 노드의 GPU 리소스 확인
kubectl get nodes -o custom-columns=NAME:.metadata.name,GPU:.status.allocatable.nvidia\\.com/gpu

# GPU 사용 중인 파드 확인
kubectl get pods -A -o custom-columns=NAME:.metadata.name,GPU:.spec.containers[*].resources.limits.nvidia\\.com/gpu

다중 GPU 요청:

apiVersion: v1
kind: Pod
metadata:
  name: multi-gpu-pod
spec:
  containers:
  - name: multi-gpu-container
    image: nvidia/cuda:11.0-base
    resources:
      limits:
        nvidia.com/gpu: 4  # 4개의 GPU 요청
      requests:
        nvidia.com/gpu: 4

GPU 메모리 분할(NVIDIA MPS): NVIDIA Multi-Process Service(MPS)를 사용하면 여러 프로세스가 동일한 GPU를 공유할 수 있습니다. 이는 Kubernetes에서 기본적으로 지원되지 않으며, 사용자 정의 설정이 필요합니다.

다른 GPU 공급업체: 다른 GPU 공급업체는 자체 네임스페이스를 사용합니다:

• AMD GPU: amd.com/gpu

• Intel GPU: intel.com/gpu

다른 옵션들의 문제점:

• A. resources.requests.gpu: 이는 유효한 Kubernetes 리소스 필드가 아닙니다. GPU 리소스는 공급업체별 네임스페이스를 사용해야 합니다.

• C. resources.requests.k8s.io/gpu: 이는 유효한 Kubernetes 리소스 필드가 아닙니다. k8s.io 네임스페이스는 일반적으로 Kubernetes 코어 리소스에 사용됩니다.

• D. resources.requests.compute/gpu: 이는 유효한 Kubernetes 리소스 필드가 아닙니다.

2. Kubernetes에서 분산 TensorFlow 학습 작업을 실행하는 데 가장 적합한 리소스 유형은 무엇인가요?

A. Deployment B. StatefulSet C. Job D. TFJob (Kubeflow)

정답 및 설명

정답: D. TFJob (Kubeflow)

설명: Kubernetes에서 분산 TensorFlow 학습 작업을 실행하는 데 가장 적합한 리소스 유형은 TFJob입니다. TFJob은 Kubeflow 프로젝트의 일부로, TensorFlow 학습 작업을 Kubernetes에서 실행하기 위해 특별히 설계된 사용자 정의 리소스입니다.

TFJob의 주요 특징:

1. 분산 학습 지원: 여러 작업자(worker), 파라미터 서버(parameter server), 평가자(evaluator) 등 TensorFlow의 분산 학습 아키텍처를 지원합니다.

2. 자동 복구: 실패한 작업자를 자동으로 재시작합니다.

3. Gang 스케줄링: 모든 작업자가 동시에 스케줄링되도록 보장합니다.

4. TensorFlow 특화 기능: TensorFlow 분산 학습에 필요한 환경 변수 및 설정을 자동으로 구성합니다.

5. 모니터링 및 로깅: TensorFlow 작업의 상태 및 로그를 모니터링하는 기능을 제공합니다.

TFJob 예시:

apiVersion: kubeflow.org/v1
kind: TFJob
metadata:
  name: mnist-training
spec:
  tfReplicaSpecs:
    Worker:
      replicas: 3
      restartPolicy: OnFailure
      template:
        spec:
          containers:
          - name: tensorflow
            image: tensorflow/tensorflow:2.6.0
            command:
            - python
            - /opt/model/train.py
            - --batch_size=64
            - --learning_rate=0.001
            resources:
              limits:
                nvidia.com/gpu: 1
    PS:
      replicas: 1
      restartPolicy: OnFailure
      template:
        spec:
          containers:
          - name: tensorflow
            image: tensorflow/tensorflow:2.6.0
            command:
            - python
            - /opt/model/train.py
            - --batch_size=64
            - --learning_rate=0.001
    Chief:
      replicas: 1
      restartPolicy: OnFailure
      template:
        spec:
          containers:
          - name: tensorflow
            image: tensorflow/tensorflow:2.6.0
            command:
            - python
            - /opt/model/train.py
            - --batch_size=64
            - --learning_rate=0.001
            resources:
              limits:
                nvidia.com/gpu: 1

TFJob 구성 요소:

1. Chief: 주 작업자로, 모델 체크포인트 저장 및 요약 작성을 담당합니다.

2. Worker: 모델 학습을 수행하는 작업자입니다.

3. PS (Parameter Server): 모델 파라미터를 저장하고 업데이트합니다.

4. Evaluator: 모델 평가를 수행합니다.

TFJob 설치:

# Kubeflow 설치
kubectl apply -f https://raw.githubusercontent.com/kubeflow/kubeflow/master/kfctl_k8s_istio.yaml

# 또는 TFJob 컨트롤러만 설치
kubectl apply -f https://raw.githubusercontent.com/kubeflow/tf-operator/master/deploy/v1/tf-operator.yaml

TFJob 모니터링:

# TFJob 상태 확인
kubectl get tfjobs

# 특정 TFJob 세부 정보 확인
kubectl describe tfjob mnist-training

# TFJob 파드 확인
kubectl get pods -l tf-job-name=mnist-training

다른 리소스 유형과의 비교:

1. Deployment:

   • 장기 실행 서비스에 적합

   • 자동 복구 및 롤링 업데이트 지원

   • 분산 학습 작업의 조정 기능 부족

   • TensorFlow 특화 기능 없음

2. StatefulSet:

   • 안정적인 네트워크 식별자 및 영구 스토리지 제공

   • 순서가 지정된 배포 및 스케일링

   • 분산 학습 작업의 조정 기능 부족

   • TensorFlow 특화 기능 없음

3. Job:

   • 일회성 작업에 적합

   • 작업 완료 보장

   • 분산 학습 작업의 조정 기능 부족

   • TensorFlow 특화 기능 없음

4. TFJob:

   • TensorFlow 분산 학습에 최적화

   • 작업자, 파라미터 서버 등의 역할 정의

   • TensorFlow 특화 환경 변수 및 설정 자동 구성

   • 작업 완료 및 실패 처리 로직 내장

다른 ML 프레임워크를 위한 Kubeflow 연산자:

• PyTorchJob: PyTorch 학습 작업용

• MPIJob: Horovod와 같은 MPI 기반 분산 학습용

• XGBoostJob: XGBoost 학습 작업용

다른 옵션들의 문제점:

• A. Deployment: 장기 실행 서비스에 적합하며, 분산 TensorFlow 학습 작업의 특정 요구 사항을 처리하지 않습니다.

• B. StatefulSet: 상태 유지가 필요한 애플리케이션에 적합하지만, 분산 TensorFlow 학습 작업의 조정 기능이 부족합니다.

• C. Job: 일회성 작업에 적합하지만, 분산 TensorFlow 학습 작업의 특정 요구 사항을 처리하지 않습니다.

### 3. Kubernetes에서 AI/ML 워크로드를 위한 영구 스토리지를 구성할 때 가장 중요한 고려 사항은 무엇인가요?

A. 스토리지 용량 B. 스토리지 클래스 유형 C. 데이터 접근 패턴 및 처리량 요구 사항 D. 스토리지 프로비저너

정답 및 설명

정답: C. 데이터 접근 패턴 및 처리량 요구 사항

설명: Kubernetes에서 AI/ML 워크로드를 위한 영구 스토리지를 구성할 때 가장 중요한 고려 사항은 데이터 접근 패턴 및 처리량 요구 사항입니다. AI/ML 워크로드는 대량의 데이터를 처리하고, 다양한 접근 패턴(순차적 읽기, 무작위 읽기, 병렬 접근 등)을 가질 수 있으며, 높은 처리량이 필요한 경우가 많습니다. 이러한 요구 사항에 맞는 스토리지 솔루션을 선택하는 것이 성능과 효율성에 큰 영향을 미칩니다.

AI/ML 워크로드의 일반적인 데이터 접근 패턴:

1. 대규모 데이터셋 읽기: 학습 데이터셋은 수 GB에서 수 TB까지 클 수 있으며, 효율적인 읽기 성능이 중요합니다.

2. 병렬 접근: 여러 작업자가 동시에 데이터에 접근하는 분산 학습 시나리오가 일반적입니다.

3. 순차적 읽기: 전체 데이터셋을 순차적으로 읽는 배치 처리 작업이 있습니다.

4. 무작위 접근: 미니배치 학습이나 온라인 학습에서는 데이터셋의 무작위 부분에 접근합니다.

5. 체크포인트 저장: 학습 중간에 모델 체크포인트를 저장하는 쓰기 작업이 발생합니다.

AI/ML 워크로드에 적합한 스토리지 솔루션:

1. 분산 파일 시스템:

   • Amazon FSx for Lustre: 고성능 컴퓨팅 및 기계 학습 워크로드에 최적화된 고성능 파일 시스템

   • GlusterFS/Ceph: 오픈 소스 분산 파일 시스템으로 확장성과 병렬 접근 지원

   • HDFS: 대규모 데이터셋 처리에 적합한 Hadoop 분산 파일 시스템

2. 고성능 블록 스토리지:

   • AWS EBS io2/io2 Block Express: 높은 IOPS와 처리량을 제공하는 SSD 기반 블록 스토리지

   • GCP Persistent Disk SSD: 높은 IOPS와 처리량을 제공하는 SSD 기반 블록 스토리지

   • Azure Ultra Disk: 매우 높은 IOPS와 처리량을 제공하는 SSD 기반 블록 스토리지

3. 객체 스토리지:

   • Amazon S3: 대규모 데이터셋 저장에 적합한 확장성 높은 객체 스토리지

   • Google Cloud Storage: 대규모 데이터셋 저장에 적합한 확장성 높은 객체 스토리지

   • Azure Blob Storage: 대규모 데이터셋 저장에 적합한 확장성 높은 객체 스토리지

스토리지 구성 예시(FSx for Lustre):

# StorageClass 정의
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fsx-lustre
provisioner: fsx.csi.aws.com
parameters:
  subnetId: subnet-0eabfaa81fb22bcaf
  securityGroupIds: sg-068000ccf82dfba88
  deploymentType: SCRATCH_2
  automaticBackupRetentionDays: "0"
  dailyAutomaticBackupStartTime: "00:00"
  perUnitStorageThroughput: "200"
  dataCompressionType: "NONE"
mountOptions:
  - flock

---
# PersistentVolumeClaim 정의
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ml-dataset
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: fsx-lustre
  resources:
    requests:
      storage: 1200Gi

---
# 학습 작업에서 사용
apiVersion: kubeflow.org/v1
kind: TFJob
metadata:
  name: distributed-training
spec:
  tfReplicaSpecs:
    Worker:
      replicas: 4
      template:
        spec:
          containers:
          - name: tensorflow
            image: tensorflow/tensorflow:2.6.0-gpu
            command:
            - python
            - /opt/model/train.py
            volumeMounts:
            - name: dataset
              mountPath: /data
            resources:
              limits:
                nvidia.com/gpu: 1
          volumes:
          - name: dataset
            persistentVolumeClaim:
              claimName: ml-dataset

스토리지 선택 시 고려해야 할 성능 지표:

1. 처리량(Throughput): 초당 읽기/쓰기할 수 있는 데이터의 양(MB/s 또는 GB/s)

2. IOPS(Input/Output Operations Per Second): 초당 수행할 수 있는 I/O 작업 수

3. 지연 시간(Latency): I/O 요청에 대한 응답 시간

4. 병렬 접근 지원: 여러 클라이언트가 동시에 접근할 수 있는 능력

5. 확장성: 데이터 증가에 따른 성능 유지 능력

AI/ML 워크로드 유형별 권장 스토리지:

1. 대규모 분산 학습: FSx for Lustre, HDFS, Ceph

2. 단일 노드 학습: 고성능 SSD 블록 스토리지

3. 데이터 전처리: 분산 파일 시스템 또는 객체 스토리지

4. 모델 서빙: 고성능 SSD 블록 스토리지 또는 메모리 내 스토리지

스토리지 성능 테스트:

# FIO를 사용한 스토리지 성능 테스트
kubectl run fio-test --image=nixery.dev/shell/fio --restart=Never -- \
  fio --name=benchmark --directory=/data --direct=1 --rw=randread --bs=4k \
  --size=1G --numjobs=16 --runtime=60 --group_reporting

다른 옵션들의 문제점:

• A. 스토리지 용량: 중요하지만, 용량만으로는 AI/ML 워크로드의 성능 요구 사항을 충족할 수 없습니다.

• B. 스토리지 클래스 유형: 스토리지 클래스는 프로비저닝 방법을 정의하지만, 그 자체로 성능 특성을 완전히 결정하지는 않습니다.

• D. 스토리지 프로비저너: 프로비저너는 스토리지 생성 방법을 정의하지만, 워크로드의 성능 요구 사항을 직접적으로 해결하지는 않습니다.

4. Kubernetes에서 AI/ML 워크로드를 위한 리소스 할당 시 가장 효과적인 방법은 무엇인가요?

A. 모든 파드에 동일한 리소스 할당 B. 워크로드 특성에 따른 리소스 프로파일링 및 최적화 C. 항상 최대 리소스 요청 D. 리소스 요청 없이 배포

정답 및 설명

정답: B. 워크로드 특성에 따른 리소스 프로파일링 및 최적화

설명: Kubernetes에서 AI/ML 워크로드를 위한 리소스 할당 시 가장 효과적인 방법은 워크로드 특성에 따른 리소스 프로파일링 및 최적화입니다. AI/ML 워크로드는 학습, 추론, 데이터 전처리 등 다양한 단계에서 서로 다른 리소스 요구 사항을 가지며, 각 워크로드의 특성을 이해하고 그에 맞게 리소스를 할당하는 것이 성능과 비용 효율성을 최적화하는 데 중요합니다.

AI/ML 워크로드 리소스 프로파일링 방법:

1. 벤치마킹: 다양한 리소스 구성으로 워크로드를 실행하고 성능을 측정합니다.

2. 모니터링: 실제 리소스 사용량을 모니터링하여 패턴을 파악합니다.

3. 점진적 조정: 초기 추정치에서 시작하여 점진적으로 리소스를 조정합니다.

4. 자동 스케일링: 워크로드 요구에 따라 자동으로 리소스를 조정합니다.

AI/ML 워크로드 유형별 리소스 특성:

1. 모델 학습:

   • CPU: 데이터 전처리 및 피처 엔지니어링에 중요

   • GPU: 딥러닝 모델 학습에 필수적

   • 메모리: 대규모 데이터셋 및 모델 파라미터 저장에 필요

   • 스토리지: 데이터셋 및 체크포인트 저장에 필요

2. 모델 추론:

   • CPU: 간단한 모델 또는 배치 추론에 적합

   • GPU: 복잡한 모델 또는 실시간 추론에 유리

   • 메모리: 모델 로딩 및 입력/출력 처리에 필요

   • 지연 시간: 실시간 추론에 중요

3. 데이터 전처리:

   • CPU: 병렬 처리 능력이 중요

   • 메모리: 대규모 데이터셋 처리에 필요

   • 스토리지 I/O: 데이터 읽기/쓰기 성능이 중요

리소스 최적화 예시:

# 학습 작업 - GPU 및 높은 메모리 요구
apiVersion: kubeflow.org/v1
kind: TFJob
metadata:
  name: training-job
spec:
  tfReplicaSpecs:
    Worker:
      replicas: 4
      template:
        spec:
          containers:
          - name: tensorflow
            image: tensorflow/tensorflow:2.6.0-gpu
            resources:
              requests:
                cpu: 4
                memory: 16Gi
                nvidia.com/gpu: 1
              limits:
                cpu: 8
                memory: 32Gi
                nvidia.com/gpu: 1

---
# 추론 서비스 - 낮은 지연 시간 요구
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inference-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: inference
  template:
    metadata:
      labels:
        app: inference
    spec:
      containers:
      - name: inference
        image: tensorflow/serving:2.6.0-gpu
        resources:
          requests:
            cpu: 2
            memory: 4Gi
            nvidia.com/gpu: 1
          limits:
            cpu: 4
            memory: 8Gi
            nvidia.com/gpu: 1
        env:
        - name: TF_FORCE_GPU_ALLOW_GROWTH
          value: "true"

---
# 데이터 전처리 작업 - CPU 및 메모리 집약적
apiVersion: batch/v1
kind: Job
metadata:
  name: data-preprocessing
spec:
  template:
    spec:
      containers:
      - name: preprocessing
        image: python:3.9
        resources:
          requests:
            cpu: 8
            memory: 16Gi
          limits:
            cpu: 16
            memory: 32Gi

리소스 모니터링 및 최적화 도구:

1. Prometheus + Grafana: 리소스 사용량 모니터링 및 시각화

2. Kubernetes Metrics Server: 기본 리소스 메트릭 수집

3. NVIDIA DCGM Exporter: GPU 메트릭 수집

4. Vertical Pod Autoscaler: 리소스 요청 자동 조정

5. Horizontal Pod Autoscaler: 파드 수 자동 조정

리소스 최적화 전략:

1. GPU 공유: NVIDIA MPS 또는 시간 분할 스케줄링을 통해 여러 작업 간에 GPU 공유

2. 메모리 최적화: 모델 양자화, 지연 로딩, 메모리 효율적인 알고리즘 사용

3. 배치 처리: 추론 요청을 배치로 처리하여 처리량 향상

4. 자동 스케일링: 부하에 따라 리소스 자동 조정

5. 노드 어피니티: 특정 하드웨어 특성을 가진 노드에 워크로드 배치

GPU 메모리 최적화 예시:

apiVersion: v1
kind: Pod
metadata:
  name: gpu-memory-optimized
spec:
  containers:
  - name: tensorflow
    image: tensorflow/tensorflow:2.6.0-gpu
    env:
    - name: TF_FORCE_GPU_ALLOW_GROWTH
      value: "true"  # 필요한 만큼만 GPU 메모리 할당
    - name: TF_GPU_ALLOCATOR
      value: "cuda_malloc_async"  # 비동기 메모리 할당자 사용
    resources:
      limits:
        nvidia.com/gpu: 1

CPU 및 메모리 최적화 예시:

apiVersion: v1
kind: Pod
metadata:
  name: cpu-memory-optimized
spec:
  containers:
  - name: python
    image: python:3.9
    env:
    - name: OMP_NUM_THREADS
      value: "4"  # OpenMP 스레드 수 제한
    - name: MKL_NUM_THREADS
      value: "4"  # Intel MKL 스레드 수 제한
    resources:
      requests:
        cpu: 4
        memory: 8Gi
      limits:
        cpu: 8
        memory: 16Gi

다른 옵션들의 문제점:

• A. 모든 파드에 동일한 리소스 할당: 서로 다른 워크로드 특성을 고려하지 않아 리소스 낭비 또는 부족 문제가 발생할 수 있습니다.

• C. 항상 최대 리소스 요청: 비용 효율성이 떨어지고, 클러스터 리소스 활용도가 낮아집니다.

• D. 리소스 요청 없이 배포: 스케줄링 및 리소스 경합 문제가 발생할 수 있으며, 특히 GPU와 같은 제한된 리소스의 경우 적절한 할당이 중요합니다.

### 5. Kubernetes에서 AI/ML 모델 서빙을 위한 가장 적합한 방법은 무엇인가요?

A. 일반 Deployment 리소스 사용 B. KServe(이전의 KFServing) 또는 Seldon Core와 같은 전문 서빙 플랫폼 사용 C. StatefulSet 리소스 사용 D. CronJob 리소스 사용

정답 및 설명

정답: B. KServe(이전의 KFServing) 또는 Seldon Core와 같은 전문 서빙 플랫폼 사용

설명: Kubernetes에서 AI/ML 모델 서빙을 위한 가장 적합한 방법은 KServe(이전의 KFServing) 또는 Seldon Core와 같은 전문 서빙 플랫폼을 사용하는 것입니다. 이러한 플랫폼은 모델 서빙에 필요한 다양한 기능(모델 버전 관리, A/B 테스트, 카나리 배포, 자동 스케일링, 모니터링 등)을 제공하며, 다양한 ML 프레임워크를 지원합니다.

전문 모델 서빙 플랫폼의 주요 기능:

1. 다양한 ML 프레임워크 지원: TensorFlow, PyTorch, ONNX, scikit-learn 등 다양한 프레임워크로 학습된 모델 지원

2. 모델 버전 관리: 여러 버전의 모델을 관리하고 롤백 가능

3. 트래픽 분할: A/B 테스트, 카나리 배포 등을 위한 트래픽 분할 기능

4. 자동 스케일링: 요청 부하에 따른 자동 스케일링

5. 모니터링 및 로깅: 모델 성능, 지연 시간, 처리량 등의 모니터링

6. 전처리 및 후처리: 입력 데이터 전처리 및 출력 데이터 후처리 파이프라인

7. 배치 추론: 대량의 데이터에 대한 배치 추론 지원

8. 모델 설명 가능성: 모델 예측에 대한 설명 기능

KServe 예시:

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: sklearn-iris
spec:
  predictor:
    sklearn:
      storageUri: "gs://kserve-examples/models/sklearn/iris"
      resources:
        requests:
          cpu: 100m
          memory: 256Mi
        limits:
          cpu: 1
          memory: 1Gi

Seldon Core 예시:

apiVersion: machinelearning.seldon.io/v1
kind: SeldonDeployment
metadata:
  name: iris-model
spec:
  name: iris
  predictors:
  - name: default
    replicas: 1
    graph:
      name: classifier
      implementation: SKLEARN_SERVER
      modelUri: "gs://seldon-models/sklearn/iris"
      envSecretRefName: seldon-init-container-secret
    engineResources:
      requests:
        cpu: 100m
        memory: 256Mi
      limits:
        cpu: 1
        memory: 1Gi

고급 서빙 기능 예시:

1. 카나리 배포(KServe):

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: sklearn-iris
spec:
  predictor:
    canaryTrafficPercent: 20
    sklearn:
      storageUri: "gs://kserve-examples/models/sklearn/iris-v2"
    containers:
    - name: sklearn-v1
      image: kserve/sklearnserver:latest
      args:
      - --model_dir=/mnt/models
      - --model_name=sklearn-iris

1. 전처리 및 후처리 파이프라인(Seldon Core):

apiVersion: machinelearning.seldon.io/v1
kind: SeldonDeployment
metadata:
  name: iris-pipeline
spec:
  name: iris
  predictors:
  - name: default
    replicas: 1
    graph:
      name: preprocessor
      type: TRANSFORMER
      children:
      - name: model
        type: MODEL
        implementation: SKLEARN_SERVER
        modelUri: "gs://seldon-models/sklearn/iris"
        children:
        - name: postprocessor
          type: TRANSFORMER
          implementation: PYTHON
          modelUri: "gs://seldon-models/postprocessor"

1. 멀티 모델 서빙(KServe):

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: multi-model-example
spec:
  predictor:
    triton:
      storageUri: "gs://kserve-examples/models/triton/multi-model"

전문 서빙 플랫폼 설치:

# KServe 설치
kubectl apply -f https://github.com/kserve/kserve/releases/download/v0.8.0/kserve.yaml

# Seldon Core 설치 (Helm 사용)
helm install seldon-core seldon-core-operator \
  --repo https://storage.googleapis.com/seldon-charts \
  --namespace seldon-system \
  --create-namespace

모델 서빙 모니터링:

# KServe 서비스 상태 확인
kubectl get inferenceservices

# Seldon Core 서비스 상태 확인
kubectl get seldondeployments

일반 Deployment와 전문 서빙 플랫폼 비교:

기능	일반 Deployment	전문 서빙 플랫폼
기본 서빙	지원	지원
모델 버전 관리	수동 구현 필요	기본 지원
트래픽 분할	수동 구현 필요	기본 지원
자동 스케일링	HPA로 제한적 지원	고급 스케일링 지원
모니터링	수동 구현 필요	기본 지원
전처리/후처리	수동 구현 필요	기본 지원
배치 추론	수동 구현 필요	기본 지원
모델 설명 가능성	수동 구현 필요	기본 지원

다른 옵션들의 문제점:

• A. 일반 Deployment 리소스 사용: 기본적인 서빙은 가능하지만, 모델 버전 관리, 트래픽 분할, 고급 모니터링 등의 기능이 부족합니다.

• C. StatefulSet 리소스 사용: 상태 유지가 필요한 애플리케이션에 적합하지만, 모델 서빙에 필요한 특화된 기능이 부족합니다.

• D. CronJob 리소스 사용: 주기적인 배치 작업에 적합하며, 실시간 모델 서빙에는 적합하지 않습니다.

6. Kubernetes에서 AI/ML 워크로드를 위한 자동 스케일링 구성 시 가장 적합한 메트릭은 무엇인가요?

A. CPU 사용률 B. 메모리 사용률 C. GPU 사용률 D. 워크로드 특성에 따른 사용자 정의 메트릭

정답 및 설명

정답: D. 워크로드 특성에 따른 사용자 정의 메트릭

설명: Kubernetes에서 AI/ML 워크로드를 위한 자동 스케일링 구성 시 가장 적합한 메트릭은 워크로드 특성에 따른 사용자 정의 메트릭입니다. AI/ML 워크로드는 CPU, 메모리, GPU 사용률 외에도 요청 지연 시간, 큐 길이, 배치 크기 등 다양한 요소에 따라 스케일링이 필요할 수 있으며, 워크로드의 특성을 가장 잘 반영하는 메트릭을 선택하는 것이 중요합니다.

AI/ML 워크로드를 위한 자동 스케일링 메트릭 유형:

1. 리소스 기반 메트릭:

   • CPU 사용률

   • 메모리 사용률

   • GPU 사용률

2. 사용자 정의 메트릭:

   • 요청 지연 시간(Latency)

   • 요청 처리량(Throughput)

   • 큐 길이(Queue Length)

   • 배치 크기(Batch Size)

   • 모델 정확도(Model Accuracy)

   • 추론 시간(Inference Time)

3. 외부 메트릭:

   • 메시지 큐 길이(Kafka, RabbitMQ 등)

   • 데이터베이스 쿼리 지연 시간

   • API 게이트웨이 요청 수

AI/ML 워크로드 유형별 권장 메트릭:

1. 모델 추론 서비스:

   • 요청 지연 시간

   • 초당 요청 수(RPS)

   • 큐에 대기 중인 요청 수

2. 배치 처리 작업:

   • 작업 큐 길이

   • 처리 대기 중인 데이터 양

   • 작업 완료 시간

3. 스트리밍 처리:

   • 스트림 처리 지연 시간

   • 이벤트 처리 속도

   • 미처리 이벤트 수

Horizontal Pod Autoscaler(HPA) 예시:

# CPU 사용률 기반 HPA
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: inference-hpa-cpu
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: inference-service
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

---
# 사용자 정의 메트릭 기반 HPA
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: inference-hpa-custom
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: inference-service
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: inference_latency_milliseconds
      target:
        type: AverageValue
        averageValue: 100

---
# 외부 메트릭 기반 HPA
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: inference-hpa-external
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: inference-service
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: External
    external:
      metric:
        name: kafka_topic_lag
        selector:
          matchLabels:
            topic: inference-requests
      target:
        type: AverageValue
        averageValue: 100

사용자 정의 메트릭 수집 및 노출:

1. Prometheus Adapter: Prometheus에서 수집한 메트릭을 Kubernetes API로 노출

2. Custom Metrics API: 사용자 정의 메트릭을 Kubernetes API로 노출

3. External Metrics API: 외부 시스템의 메트릭을 Kubernetes API로 노출

Prometheus Adapter 설정 예시:

# Prometheus Adapter 구성
apiVersion: v1
kind: ConfigMap
metadata:
  name: adapter-config
  namespace: monitoring
data:
  config.yaml: |
    rules:
    - seriesQuery: 'inference_latency_milliseconds{namespace!="",pod!=""}'
      resources:
        overrides:
          namespace: {resource: "namespace"}
          pod: {resource: "pod"}
      name:
        matches: "inference_latency_milliseconds"
      metricsQuery: 'avg(<<.Series>>{<<.LabelMatchers>>})'

KEDA(Kubernetes Event-driven Autoscaling) 예시:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: inference-scaler
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: inference-service
  minReplicaCount: 1
  maxReplicaCount: 10
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus.monitoring.svc:9090
      metricName: inference_latency_milliseconds
      threshold: "100"
      query: avg(inference_latency_milliseconds{service="inference-service"})

GPU 사용률 기반 스케일링: GPU 사용률 기반 스케일링은 NVIDIA DCGM Exporter와 같은 도구를 사용하여 구현할 수 있습니다.

# NVIDIA DCGM Exporter 배포
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: dcgm-exporter
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: dcgm-exporter
  template:
    metadata:
      labels:
        app: dcgm-exporter
    spec:
      containers:
      - name: dcgm-exporter
        image: nvidia/dcgm-exporter:2.3.1-2.6.1-ubuntu20.04
        ports:
        - containerPort: 9400
          name: metrics
        securityContext:
          runAsNonRoot: false
          runAsUser: 0
        volumeMounts:
        - name: docker-socket
          mountPath: /var/run/docker.sock
      volumes:
      - name: docker-socket
        hostPath:
          path: /var/run/docker.sock

---
# GPU 사용률 기반 HPA
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: inference-hpa-gpu
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: inference-service
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Pods
    pods:
      metric:
        name: DCGM_FI_DEV_GPU_UTIL
      target:
        type: AverageValue
        averageValue: 70

자동 스케일링 전략 선택 시 고려 사항:

1. 워크로드 특성: 배치 처리, 실시간 추론, 스트리밍 처리 등

2. 성능 요구 사항: 지연 시간, 처리량, 정확도 등

3. 리소스 효율성: 비용 최적화, 리소스 활용도 등

4. 확장성: 부하 변동에 대한 대응 능력

5. 안정성: 급격한 스케일링으로 인한 서비스 중단 방지

다른 옵션들의 문제점:

• A. CPU 사용률: AI/ML 워크로드는 종종 GPU 바운드이거나 메모리 바운드일 수 있어, CPU 사용률만으로는 적절한 스케일링 결정을 내리기 어려울 수 있습니다.

• B. 메모리 사용률: 메모리 사용률은 일반적으로 워크로드 증가에 비례하여 증가하지 않을 수 있으며, 특히 모델 로딩 후에는 상대적으로 일정할 수 있습니다.

• C. GPU 사용률: GPU 사용률은 중요한 메트릭이지만, 모든 AI/ML 워크로드가 GPU를 사용하는 것은 아니며, 사용하더라도 GPU 사용률만으로는 서비스 품질을 완전히 반영하지 못할 수 있습니다.

### 7. Kubernetes에서 AI/ML 워크로드를 위한 네트워크 구성 시 가장 중요한 고려 사항은 무엇인가요?

A. 네트워크 정책 설정 B. 서비스 메시 구현 C. 분산 학습을 위한 고성능 네트워킹 및 토폴로지 인식 D. 외부 접근성 구성

정답 및 설명

정답: C. 분산 학습을 위한 고성능 네트워킹 및 토폴로지 인식

설명: Kubernetes에서 AI/ML 워크로드를 위한 네트워크 구성 시 가장 중요한 고려 사항은 분산 학습을 위한 고성능 네트워킹 및 토폴로지 인식입니다. 분산 AI/ML 워크로드는 노드 간에 대량의 데이터와 모델 파라미터를 교환해야 하므로, 네트워크 성능이 전체 학습 및 추론 성능에 큰 영향을 미칩니다. 또한, 네트워크 토폴로지를 인식하여 가까운 노드 간에 통신이 이루어지도록 하는 것이 지연 시간을 최소화하는 데 중요합니다.

분산 AI/ML 워크로드의 네트워크 요구 사항:

1. 높은 대역폭: 대량의 데이터 및 모델 파라미터 교환을 위한 높은 네트워크 대역폭

2. 낮은 지연 시간: 노드 간 빠른 통신을 위한 낮은 네트워크 지연 시간

3. RDMA(Remote Direct Memory Access) 지원: 메모리 간 직접 데이터 전송을 통한 CPU 오버헤드 감소

4. 토폴로지 인식: 네트워크 토폴로지를 고려한 파드 배치

5. GPU 직접 통신: GPU 간 직접 통신을 위한 NVIDIA GPUDirect RDMA와 같은 기술 지원

고성능 네트워킹 구성 예시:

# 고성능 네트워킹을 위한 노드 셀렉터 및 어피니티 설정
apiVersion: kubeflow.org/v1
kind: TFJob
metadata:
  name: distributed-training
spec:
  tfReplicaSpecs:
    Worker:
      replicas: 4
      template:
        spec:
          nodeSelector:
            network-type: high-performance
          affinity:
            podAntiAffinity:
              preferredDuringSchedulingIgnoredDuringExecution:
              - weight: 100
                podAffinityTerm:
                  labelSelector:
                    matchExpressions:
                    - key: tf-job-name
                      operator: In
                      values:
                      - distributed-training
                  topologyKey: kubernetes.io/hostname
            nodeAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                nodeSelectorTerms:
                - matchExpressions:
                  - key: topology.kubernetes.io/zone
                    operator: In
                    values:
                    - us-west-2a
          containers:
          - name: tensorflow
            image: tensorflow/tensorflow:2.6.0-gpu
            env:
            - name: TF_CONFIG
              valueFrom:
                configMapKeyRef:
                  name: tf-config
                  key: tf-config.json
            resources:
              limits:
                nvidia.com/gpu: 1

네트워크 토폴로지 인식 구성:

# 토폴로지 분산 제약 조건 설정
apiVersion: v1
kind: Pod
metadata:
  name: ml-worker
  labels:
    app: distributed-training
spec:
  topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: DoNotSchedule
    labelSelector:
      matchLabels:
        app: distributed-training
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        app: distributed-training
  containers:
  - name: ml-container
    image: ml-training:latest

고성능 네트워크 인터페이스 구성:

# Multus CNI를 사용한 고성능 네트워크 인터페이스 구성
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: sriov-net
spec:
  config: '{
    "cniVersion": "0.3.1",
    "name": "sriov-net",
    "type": "sriov",
    "ipam": {
      "type": "host-local",
      "subnet": "192.168.1.0/24",
      "rangeStart": "192.168.1.10",
      "rangeEnd": "192.168.1.200"
    }
  }'

---
apiVersion: v1
kind: Pod
metadata:
  name: ml-worker
  annotations:
    k8s.v1.cni.cncf.io/networks: sriov-net
spec:
  containers:
  - name: ml-container
    image: ml-training:latest
    resources:
      limits:
        intel.com/sriov: 1

RDMA 지원 구성:

# RDMA 지원을 위한 구성
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: rdma-net
spec:
  config: '{
    "cniVersion": "0.3.1",
    "name": "rdma-net",
    "type": "rdma",
    "ipam": {
      "type": "host-local",
      "subnet": "192.168.2.0/24"
    },
    "deviceID": "0000:03:00.0"
  }'

---
apiVersion: v1
kind: Pod
metadata:
  name: rdma-pod
  annotations:
    k8s.v1.cni.cncf.io/networks: rdma-net
spec:
  containers:
  - name: rdma-container
    image: rdma-app:latest
    securityContext:
      capabilities:
        add: ["IPC_LOCK"]
    volumeMounts:
    - name: rdma-devices
      mountPath: /dev/infiniband
  volumes:
  - name: rdma-devices
    hostPath:
      path: /dev/infiniband

NVIDIA GPUDirect RDMA 구성:

# NVIDIA GPUDirect RDMA 지원을 위한 구성
apiVersion: v1
kind: Pod
metadata:
  name: gpudirect-pod
spec:
  containers:
  - name: gpudirect-container
    image: nvidia/cuda:11.0-base
    command: ["sleep", "infinity"]
    resources:
      limits:
        nvidia.com/gpu: 1
    securityContext:
      capabilities:
        add: ["IPC_LOCK"]
    volumeMounts:
    - name: nvidia-dev
      mountPath: /dev/nvidia0
    - name: nvidia-uvm
      mountPath: /dev/nvidia-uvm
    - name: nvidia-uvm-tools
      mountPath: /dev/nvidia-uvm-tools
    - name: nvidia-modeset
      mountPath: /dev/nvidia-modeset
  volumes:
  - name: nvidia-dev
    hostPath:
      path: /dev/nvidia0
  - name: nvidia-uvm
    hostPath:
      path: /dev/nvidia-uvm
  - name: nvidia-uvm-tools
    hostPath:
      path: /dev/nvidia-uvm-tools
  - name: nvidia-modeset
    hostPath:
      path: /dev/nvidia-modeset

네트워크 성능 최적화 전략:

1. 노드 배치 최적화: 동일한 랙 또는 가까운 노드에 관련 파드 배치

2. 네트워크 인터페이스 최적화: SR-IOV, DPDK 등의 기술을 사용하여 네트워크 성능 향상

3. 네트워크 토폴로지 인식: 토폴로지 분산 제약 조건을 사용하여 네트워크 토폴로지를 고려한 파드 배치

4. 전용 네트워크 사용: AI/ML 워크로드를 위한 전용 네트워크 인터페이스 구성

5. MTU 최적화: 대형 패킷 전송을 위한 MTU(Maximum Transmission Unit) 최적화

네트워크 성능 테스트:

# iperf3를 사용한 네트워크 성능 테스트
kubectl run iperf3-server --image=networkstatic/iperf3 --port=5201 -- -s
kubectl expose pod iperf3-server --port=5201 --target-port=5201

kubectl run iperf3-client --image=networkstatic/iperf3 --rm -it -- -c iperf3-server -p 5201 -t 30

다른 옵션들의 문제점:

• A. 네트워크 정책 설정: 보안을 위해 중요하지만, AI/ML 워크로드의 성능에 직접적인 영향을 미치지 않습니다.

• B. 서비스 메시 구현: 마이크로서비스 아키텍처에 유용하지만, AI/ML 워크로드의 고성능 네트워킹 요구 사항을 충족하지 않습니다.

• D. 외부 접근성 구성: 모델 서빙에 중요하지만, 분산 학습의 성능에는 직접적인 영향을 미치지 않습니다.

8. Kubernetes에서 AI/ML 워크로드를 위한 보안 구성 시 가장 중요한 고려 사항은 무엇인가요?

A. 네트워크 정책 설정 B. 모델 및 데이터에 대한 접근 제어 및 암호화 C. 컨테이너 이미지 스캐닝 D. 파드 보안 정책 설정

정답 및 설명

정답: B. 모델 및 데이터에 대한 접근 제어 및 암호화

설명: Kubernetes에서 AI/ML 워크로드를 위한 보안 구성 시 가장 중요한 고려 사항은 모델 및 데이터에 대한 접근 제어 및 암호화입니다. AI/ML 워크로드는 종종 민감한 데이터와 지적 재산권이 있는 모델을 다루기 때문에, 이러한 자산을 보호하는 것이 가장 중요합니다. 데이터 유출이나 모델 도난은 심각한 비즈니스 및 규제 영향을 미칠 수 있습니다.

AI/ML 워크로드의 주요 보안 위험:

1. 데이터 유출: 학습 데이터, 추론 데이터 등의 민감한 정보 유출

2. 모델 도난: 지적 재산권이 있는 모델 파일 도난

3. 모델 오염: 적대적 공격을 통한 모델 성능 저하 또는 편향 주입

4. 추론 조작: 입력 데이터 조작을 통한 잘못된 예측 유도

5. 권한 상승: 과도한 권한을 통한 시스템 접근

모델 및 데이터 보안을 위한 주요 전략:

1. 접근 제어:

   • RBAC(Role-Based Access Control)을 통한 세분화된 권한 관리

   • 최소 권한 원칙 적용

   • 서비스 계정 분리

2. 암호화:

   • 저장 데이터 암호화(Encryption at Rest)

   • 전송 중 데이터 암호화(Encryption in Transit)

   • 모델 파일 암호화

3. 비밀 관리:

   • Kubernetes Secrets 또는 외부 비밀 관리 시스템 사용

   • API 키, 인증 토큰 등의 안전한 관리

4. 컨테이너 보안:

   • 최소 권한으로 컨테이너 실행

   • 읽기 전용 파일 시스템 사용

   • 루트가 아닌 사용자로 실행

RBAC 구성 예시:

# 모델 접근을 위한 역할 정의
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: model-reader
  namespace: ml-models
rules:
- apiGroups: [""]
  resources: ["secrets", "configmaps"]
  verbs: ["get", "list"]
  resourceNames: ["model-weights", "model-config"]

---
# 모델 접근 역할 바인딩
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: model-reader-binding
  namespace: ml-models
subjects:
- kind: ServiceAccount
  name: inference-service
  namespace: ml-models
roleRef:
  kind: Role
  name: model-reader
  apiGroup: rbac.authorization.k8s.io

암호화된 모델 저장 예시:

# 암호화된 모델 저장을 위한 Secret
apiVersion: v1
kind: Secret
metadata:
  name: model-weights
  namespace: ml-models
type: Opaque
data:
  model.h5: <base64-encoded-encrypted-model>

---
# 암호화된 모델을 사용하는 파드
apiVersion: v1
kind: Pod
metadata:
  name: inference-pod
  namespace: ml-models
spec:
  serviceAccountName: inference-service
  containers:
  - name: inference
    image: ml-inference:latest
    volumeMounts:
    - name: model-volume
      mountPath: /models
      readOnly: true
    env:
    - name: MODEL_ENCRYPTION_KEY
      valueFrom:
        secretKeyRef:
          name: model-encryption-keys
          key: key1
  volumes:
  - name: model-volume
    secret:
      secretName: model-weights

외부 비밀 관리 시스템 통합 예시(HashiCorp Vault):

# Vault Agent Injector를 사용한 비밀 주입
apiVersion: v1
kind: Pod
metadata:
  name: ml-training
  namespace: ml-workloads
  annotations:
    vault.hashicorp.com/agent-inject: "true"
    vault.hashicorp.com/agent-inject-secret-db-creds: "database/creds/ml-training-role"
    vault.hashicorp.com/role: "ml-training-role"
spec:
  serviceAccountName: ml-training
  containers:
  - name: training
    image: ml-training:latest

데이터 암호화 구성 예시:

# EBS 암호화를 사용한 PersistentVolume
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: encrypted-data
  namespace: ml-workloads
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: encrypted-storage
  resources:
    requests:
      storage: 100Gi

---
# 암호화된 스토리지 클래스
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: encrypted-storage
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
  encrypted: "true"
  kmsKeyId: arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab

컨테이너 보안 강화 예시:

# 보안 강화된 파드 구성
apiVersion: v1
kind: Pod
metadata:
  name: secure-ml-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 1000
    fsGroup: 1000
  containers:
  - name: ml-container
    image: ml-image:latest
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
        - ALL
    volumeMounts:
    - name: tmp
      mountPath: /tmp
    - name: model-output
      mountPath: /output
  volumes:
  - name: tmp
    emptyDir: {}
  - name: model-output
    persistentVolumeClaim:
      claimName: model-output-pvc

네트워크 정책 예시:

# ML 워크로드를 위한 네트워크 정책
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ml-network-policy
  namespace: ml-workloads
spec:
  podSelector:
    matchLabels:
      app: ml-inference
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: frontend
    - podSelector:
        matchLabels:
          app: api-gateway
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: monitoring
    ports:
    - protocol: TCP
      port: 9090
  - to:
    - namespaceSelector:
        matchLabels:
          name: logging
    ports:
    - protocol: TCP
      port: 8125

모델 및 데이터 보안을 위한 추가 전략:

1. 모델 서명 및 검증: 모델 파일에 디지털 서명을 적용하고 사용 전에 검증

2. 모델 버전 관리: 모델 버전 및 변경 사항 추적

3. 감사 로깅: 모델 및 데이터 접근에 대한 감사 로그 유지

4. 데이터 마스킹: 민감한 데이터 필드 마스킹

5. 차등 프라이버시: 개인 정보 보호를 위한 차등 프라이버시 기법 적용

다른 옵션들의 문제점:

• A. 네트워크 정책 설정: 중요하지만, 모델 및 데이터 자체의 보안을 직접적으로 보장하지는 않습니다.

• C. 컨테이너 이미지 스캐닝: 취약점 관리에 중요하지만, 모델 및 데이터 보안을 직접적으로 다루지 않습니다.

• D. 파드 보안 정책 설정: 컨테이너 실행 환경의 보안을 강화하지만, 모델 및 데이터 자체의 보안을 직접적으로 보장하지는 않습니다.

### 9. Kubernetes에서 AI/ML 워크로드를 위한 로깅 및 모니터링 구성 시 가장 중요한 지표는 무엇인가요?

A. 파드 및 노드 상태 B. 모델 성능 메트릭(정확도, 지연 시간 등) 및 리소스 사용량 C. API 호출 수 D. 네트워크 트래픽

정답 및 설명

정답: B. 모델 성능 메트릭(정확도, 지연 시간 등) 및 리소스 사용량

설명: Kubernetes에서 AI/ML 워크로드를 위한 로깅 및 모니터링 구성 시 가장 중요한 지표는 모델 성능 메트릭(정확도, 지연 시간 등) 및 리소스 사용량입니다. 이러한 지표는 모델의 품질, 서비스 수준 목표(SLO) 준수 여부, 리소스 효율성을 평가하는 데 필수적이며, 모델 성능 저하나 리소스 병목 현상을 조기에 감지하는 데 도움이 됩니다.

주요 모니터링 지표:

1. 모델 성능 메트릭:

   • 정확도(Accuracy): 모델 예측의 정확도

   • 정밀도(Precision): 양성으로 예측한 것 중 실제 양성의 비율

   • 재현율(Recall): 실제 양성 중 양성으로 예측한 비율

   • F1 점수: 정밀도와 재현율의 조화 평균

   • AUC-ROC: 이진 분류 모델의 성능 측정

   • 평균 제곱 오차(MSE): 회귀 모델의 오차 측정

2. 서비스 수준 메트릭:

   • 지연 시간(Latency): 요청에서 응답까지의 시간

   • 처리량(Throughput): 단위 시간당 처리된 요청 수

   • 오류율(Error Rate): 실패한 요청의 비율

   • 가용성(Availability): 서비스가 정상적으로 응답한 시간의 비율

3. 리소스 사용량:

   • CPU 사용률: 컨테이너 및 노드의 CPU 사용률

   • 메모리 사용률: 컨테이너 및 노드의 메모리 사용률

   • GPU 사용률: GPU 계산 및 메모리 사용률

   • 디스크 I/O: 스토리지 읽기/쓰기 성능

   • 네트워크 I/O: 네트워크 송수신 성능

모니터링 스택 구성 예시:

# Prometheus 구성
apiVersion: v1
kind: ConfigMap
metadata:
  name: prometheus-config
  namespace: monitoring
data:
  prometheus.yml: |
    global:
      scrape_interval: 15s
    scrape_configs:
    - job_name: 'kubernetes-pods'
      kubernetes_sd_configs:
      - role: pod
      relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_scrape]
        action: keep
        regex: true
    - job_name: 'ml-metrics'
      kubernetes_sd_configs:
      - role: pod
        selectors:
        - role: pod
          label: "app=ml-inference"
      relabel_configs:
      - source_labels: [__meta_kubernetes_pod_annotation_prometheus_io_path]
        action: replace
        target_label: __metrics_path__
        regex: (.+)
      - source_labels: [__address__, __meta_kubernetes_pod_annotation_prometheus_io_port]
        action: replace
        regex: ([^:]+)(?::\d+)?;(\d+)
        replacement: $1:$2
        target_label: __address__

---
# ML 서비스에서 메트릭 노출
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ml-inference
spec:
  replicas: 3
  selector:
    matchLabels:
      app: ml-inference
  template:
    metadata:
      labels:
        app: ml-inference
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "8080"
        prometheus.io/path: "/metrics"
    spec:
      containers:
      - name: inference
        image: ml-inference:latest
        ports:
        - containerPort: 8080
          name: http
        - containerPort: 9090
          name: metrics

사용자 정의 메트릭 노출 예시(Python):

from prometheus_client import start_http_server, Summary, Counter, Gauge, Histogram
import time
import random

# 메트릭 정의
INFERENCE_LATENCY = Histogram('inference_latency_seconds', 'Inference latency in seconds', 
                             ['model', 'version'])
INFERENCE_REQUESTS = Counter('inference_requests_total', 'Total number of inference requests', 
                            ['model', 'version', 'status'])
MODEL_ACCURACY = Gauge('model_accuracy', 'Model accuracy', 
                      ['model', 'version', 'dataset'])
GPU_MEMORY_USAGE = Gauge('gpu_memory_usage_bytes', 'GPU memory usage in bytes', 
                        ['device'])

# 메트릭 서버 시작
start_http_server(9090)

# 메트릭 업데이트 예시
def process_request(model_name, model_version, input_data):
    start_time = time.time()
    
    try:
        # 모델 추론 수행
        result = model.predict(input_data)
        
        # 지연 시간 기록
        latency = time.time() - start_time
        INFERENCE_LATENCY.labels(model=model_name, version=model_version).observe(latency)
        
        # 요청 수 증가
        INFERENCE_REQUESTS.labels(model=model_name, version=model_version, status="success").inc()
        
        # GPU 메모리 사용량 업데이트
        GPU_MEMORY_USAGE.labels(device="gpu0").set(get_gpu_memory_usage())
        
        return result
    except Exception as e:
        # 오류 요청 수 증가
        INFERENCE_REQUESTS.labels(model=model_name, version=model_version, status="error").inc()
        raise e

# 주기적으로 모델 정확도 업데이트
def update_model_accuracy():
    while True:
        accuracy = evaluate_model_accuracy()
        MODEL_ACCURACY.labels(model="image_classifier", version="v1", dataset="validation").set(accuracy)
        time.sleep(3600)  # 1시간마다 업데이트

Grafana 대시보드 구성 예시:

apiVersion: v1
kind: ConfigMap
metadata:
  name: ml-dashboard
  namespace: monitoring
  labels:
    grafana_dashboard: "1"
data:
  ml-dashboard.json: |
    {
      "title": "ML Model Monitoring",
      "panels": [
        {
          "title": "Inference Latency",
          "type": "graph",
          "datasource": "Prometheus",
          "targets": [
            {
              "expr": "histogram_quantile(0.95, sum(rate(inference_latency_seconds_bucket[5m])) by (le, model, version))",
              "legendFormat": "p95 - {{model}} - {{version}}"
            },
            {
              "expr": "histogram_quantile(0.50, sum(rate(inference_latency_seconds_bucket[5m])) by (le, model, version))",
              "legendFormat": "p50 - {{model}} - {{version}}"
            }
          ]
        },
        {
          "title": "Request Rate",
          "type": "graph",
          "datasource": "Prometheus",
          "targets": [
            {
              "expr": "sum(rate(inference_requests_total[5m])) by (model, version, status)",
              "legendFormat": "{{model}} - {{version}} - {{status}}"
            }
          ]
        },
        {
          "title": "Model Accuracy",
          "type": "gauge",
          "datasource": "Prometheus",
          "targets": [
            {
              "expr": "model_accuracy",
              "legendFormat": "{{model}} - {{version}} - {{dataset}}"
            }
          ],
          "options": {
            "min": 0,
            "max": 1,
            "thresholds": [
              { "color": "red", "value": 0 },
              { "color": "yellow", "value": 0.7 },
              { "color": "green", "value": 0.9 }
            ]
          }
        },
        {
          "title": "GPU Memory Usage",
          "type": "graph",
          "datasource": "Prometheus",
          "targets": [
            {
              "expr": "gpu_memory_usage_bytes",
              "legendFormat": "{{device}}"
            }
          ]
        }
      ]
    }

로깅 구성 예시:

# Fluent Bit 구성
apiVersion: v1
kind: ConfigMap
metadata:
  name: fluent-bit-config
  namespace: logging
data:
  fluent-bit.conf: |
    [SERVICE]
        Flush        5
        Daemon       Off
        Log_Level    info

    [INPUT]
        Name             tail
        Tag              kube.*
        Path             /var/log/containers/*.log
        Parser           docker
        DB               /var/log/flb_kube.db
        Mem_Buf_Limit    5MB
        Skip_Long_Lines  On
        Refresh_Interval 10

    [FILTER]
        Name                kubernetes
        Match               kube.*
        Kube_URL            https://kubernetes.default.svc:443
        Kube_CA_File        /var/run/secrets/kubernetes.io/serviceaccount/ca.crt
        Kube_Token_File     /var/run/secrets/kubernetes.io/serviceaccount/token
        Kube_Tag_Prefix     kube.var.log.containers.
        Merge_Log           On
        Merge_Log_Key       log_processed
        K8S-Logging.Parser  On
        K8S-Logging.Exclude Off

    [FILTER]
        Name         grep
        Match        kube.var.log.containers.ml-*
        Regex        log ERROR|WARN|INFO

    [OUTPUT]
        Name            es
        Match           kube.var.log.containers.ml-*
        Host            elasticsearch
        Port            9200
        Index           ml-logs
        Type            _doc
        Logstash_Format On
        Logstash_Prefix ml-logs
        Time_Key        @timestamp
        Replace_Dots    On
        Retry_Limit     False

모델 성능 모니터링을 위한 추가 도구:

1. MLflow: 실험 추적, 모델 버전 관리, 모델 레지스트리 제공

2. TensorBoard: TensorFlow 모델의 학습 과정 및 성능 시각화

3. Weights & Biases: 실험 추적, 모델 성능 비교, 하이퍼파라미터 최적화

4. Seldon Core Metrics: Seldon Core에서 제공하는 모델 서빙 메트릭

5. KServe Metrics: KServe에서 제공하는 모델 서빙 메트릭

모니터링 알림 구성 예시:

# Prometheus 알림 규칙
apiVersion: monitoring.coreos.com/v1
kind: PrometheusRule
metadata:
  name: ml-alerts
  namespace: monitoring
spec:
  groups:
  - name: ml.rules
    rules:
    - alert: HighInferenceLatency
      expr: histogram_quantile(0.95, sum(rate(inference_latency_seconds_bucket[5m])) by (le, model, version)) > 0.5
      for: 5m
      labels:
        severity: warning
      annotations:
        summary: "High inference latency"
        description: "Model {{ $labels.model }} version {{ $labels.version }} has p95 latency above 500ms"
    
    - alert: LowModelAccuracy
      expr: model_accuracy < 0.8
      for: 10m
      labels:
        severity: critical
      annotations:
        summary: "Low model accuracy"
        description: "Model {{ $labels.model }} version {{ $labels.version }} has accuracy below 80%"
    
    - alert: HighErrorRate
      expr: sum(rate(inference_requests_total{status="error"}[5m])) / sum(rate(inference_requests_total[5m])) > 0.05
      for: 5m
      labels:
        severity: critical
      annotations:
        summary: "High error rate"
        description: "Error rate is above 5%"

다른 옵션들의 문제점:

• A. 파드 및 노드 상태: 기본적인 시스템 상태 모니터링에 중요하지만, AI/ML 워크로드의 성능과 품질을 직접적으로 반영하지 않습니다.

• C. API 호출 수: 시스템 사용량을 측정하는 데 유용하지만, 모델 성능이나 리소스 효율성을 직접적으로 나타내지 않습니다.

• D. 네트워크 트래픽: 분산 학습이나 대규모 데이터 전송에 중요하지만, 모델 성능이나 품질을 직접적으로 반영하지 않습니다.

10. Kubernetes에서 AI/ML 워크로드를 위한 비용 최적화 전략으로 가장 효과적인 것은 무엇인가요?

A. 항상 최신 인스턴스 유형 사용 B. 모든 워크로드에 Spot 인스턴스 사용 C. 워크로드 특성에 따른 적절한 인스턴스 유형 선택 및 자동 스케일링 D. 모든 리소스에 대한 요청 및 제한 최소화

정답 및 설명

정답: C. 워크로드 특성에 따른 적절한 인스턴스 유형 선택 및 자동 스케일링

설명: Kubernetes에서 AI/ML 워크로드를 위한 비용 최적화 전략으로 가장 효과적인 것은 워크로드 특성에 따른 적절한 인스턴스 유형 선택 및 자동 스케일링입니다. AI/ML 워크로드는 학습, 추론, 데이터 전처리 등 다양한 단계에서 서로 다른 리소스 요구 사항을 가지며, 각 워크로드의 특성에 맞는 인스턴스 유형을 선택하고 필요에 따라 자동으로 스케일링하는 것이 비용 효율성을 최적화하는 데 중요합니다.

워크로드 특성별 인스턴스 유형 선택:

1. 모델 학습:

   • GPU 인스턴스: 딥러닝 모델 학습에 적합

   • 메모리 최적화 인스턴스: 대규모 데이터셋 처리에 적합

   • 컴퓨팅 최적화 인스턴스: 계산 집약적 알고리즘에 적합

2. 모델 추론:

   • GPU 인스턴스: 복잡한 모델 또는 실시간 추론에 적합

   • CPU 인스턴스: 간단한 모델 또는 배치 추론에 적합

   • 추론 최적화 인스턴스(AWS Inferentia, Google TPU 등): 추론에 특화된 인스턴스

3. 데이터 전처리:

   • 컴퓨팅 최적화 인스턴스: 병렬 처리에 적합

   • 메모리 최적화 인스턴스: 대규모 데이터셋 처리에 적합

   • 스토리지 최적화 인스턴스: I/O 집약적 작업에 적합

노드 그룹 구성 예시:

# 학습용 노드 그룹 (GPU 인스턴스)
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: ml-cluster
  region: us-west-2
nodeGroups:
  - name: training-ng
    instanceType: p3.2xlarge  # GPU 인스턴스
    minSize: 0
    maxSize: 10
    labels:
      workload-type: training
    taints:
      - key: workload-type
        value: training
        effect: NoSchedule
    tags:
      k8s.io/cluster-autoscaler/enabled: "true"
      k8s.io/cluster-autoscaler/ml-cluster: "owned"

  # 추론용 노드 그룹 (CPU 인스턴스)
  - name: inference-ng
    instanceType: c5.2xlarge  # 컴퓨팅 최적화 인스턴스
    minSize: 1
    maxSize: 20
    labels:
      workload-type: inference
    tags:
      k8s.io/cluster-autoscaler/enabled: "true"
      k8s.io/cluster-autoscaler/ml-cluster: "owned"

  # 데이터 전처리용 노드 그룹 (메모리 최적화 인스턴스)
  - name: preprocessing-ng
    instanceType: r5.2xlarge  # 메모리 최적화 인스턴스
    minSize: 0
    maxSize: 10
    labels:
      workload-type: preprocessing
    tags:
      k8s.io/cluster-autoscaler/enabled: "true"
      k8s.io/cluster-autoscaler/ml-cluster: "owned"

  # Spot 인스턴스 노드 그룹 (비용 효율적인 배치 작업용)
  - name: spot-ng
    instanceTypes: ["m5.xlarge", "m5a.xlarge", "m5n.xlarge"]
    minSize: 0
    maxSize: 20
    spot: true
    labels:
      workload-type: batch
    tags:
      k8s.io/cluster-autoscaler/enabled: "true"
      k8s.io/cluster-autoscaler/ml-cluster: "owned"

워크로드 배치 예시:

# 학습 작업 (GPU 노드에 배치)
apiVersion: batch/v1
kind: Job
metadata:
  name: training-job
spec:
  template:
    spec:
      nodeSelector:
        workload-type: training
      containers:
      - name: training
        image: training:latest
        resources:
          limits:
            nvidia.com/gpu: 1

# 추론 서비스 (CPU 노드에 배치)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: inference-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: inference
  template:
    metadata:
      labels:
        app: inference
    spec:
      nodeSelector:
        workload-type: inference
      containers:
      - name: inference
        image: inference:latest
        resources:
          requests:
            cpu: 1
            memory: 2Gi
          limits:
            cpu: 2
            memory: 4Gi

# 데이터 전처리 작업 (메모리 최적화 노드에 배치)
apiVersion: batch/v1
kind: Job
metadata:
  name: preprocessing-job
spec:
  template:
    spec:
      nodeSelector:
        workload-type: preprocessing
      containers:
      - name: preprocessing
        image: preprocessing:latest
        resources:
          requests:
            memory: 16Gi
          limits:
            memory: 32Gi

# 배치 추론 작업 (Spot 인스턴스에 배치)
apiVersion: batch/v1
kind: Job
metadata:
  name: batch-inference
spec:
  template:
    spec:
      nodeSelector:
        workload-type: batch
      tolerations:
      - key: spot
        operator: Exists
      containers:
      - name: batch-inference
        image: batch-inference:latest

자동 스케일링 구성 예시:

# 클러스터 오토스케일러 구성
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-config
  namespace: kube-system
data:
  config.yaml: |
    expendablePodsPriorityCutoff: -10
    scaleDownUtilizationThreshold: 0.5
    scaleDownUnneededTime: 5m
    scaleDownDelayAfterAdd: 5m
    scaleDownDelayAfterDelete: 0s
    scaleDownDelayAfterFailure: 3m
    maxNodeProvisionTime: 15m

# HPA 구성 (추론 서비스)
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: inference-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: inference-service
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: inference_latency_milliseconds
      target:
        type: AverageValue
        averageValue: 100

비용 최적화 전략:

1. 적절한 인스턴스 유형 선택:

   • 워크로드 특성에 맞는 인스턴스 유형 선택

   • 비용 대비 성능 분석을 통한 최적의 인스턴스 선택

   • 특화된 인스턴스(GPU, TPU 등) 활용

2. Spot 인스턴스 활용:

   • 내결함성이 있는 워크로드에 Spot 인스턴스 사용

   • 다양한 인스턴스 유형 지정으로 가용성 향상

   • 중단 허용 전략 구현

3. 자동 스케일링:

   • 클러스터 오토스케일러를 통한 노드 수 자동 조정

   • HPA를 통한 파드 수 자동 조정

   • 사용자 정의 메트릭 기반 스케일링

4. 리소스 요청 및 제한 최적화:

   • 실제 사용량에 기반한 리소스 요청 설정

   • Vertical Pod Autoscaler를 통한 리소스 요청 자동 조정

   • 리소스 사용량 모니터링 및 최적화

5. 작업 일정 최적화:

   • 비용이 저렴한 시간대에 배치 작업 실행

   • 우선순위가 낮은 작업은 저비용 리소스에 배치

   • 작업 큐 및 우선순위 설정

비용 모니터링 및 최적화 도구:

1. Kubecost: Kubernetes 클러스터의 비용 모니터링 및 최적화

2. AWS Cost Explorer: AWS 리소스 비용 분석

3. Google Cloud Cost Management: GCP 리소스 비용 분석

4. Azure Cost Management: Azure 리소스 비용 분석

5. Prometheus + Grafana: 사용자 정의 비용 대시보드 구성

다른 옵션들의 문제점:

• A. 항상 최신 인스턴스 유형 사용: 최신 인스턴스가 항상 비용 효율적이지는 않으며, 워크로드 특성에 맞는 인스턴스 선택이 더 중요합니다.

• B. 모든 워크로드에 Spot 인스턴스 사용: Spot 인스턴스는 중단될 수 있으므로, 중요하고 중단에 민감한 워크로드에는 적합하지 않습니다.

• D. 모든 리소스에 대한 요청 및 제한 최소화: 리소스 요청을 과도하게 최소화하면 성능 문제가 발생할 수 있으며, 워크로드 특성에 맞는 적절한 리소스 할당이 중요합니다.