Kubernetes Storage 설명과 랜딩존(Backup & Recovery포함)

medires

아래는 Kubernetes Storage의 구조와 유형을 설명한 후, Azure Landing Zone 관점에서 스토리지 설계 시 고려해야 할 요소를 TA 실무 기준에서 정리한 내용입니다.

📦 1. Kubernetes Storage 설명

✅ 개요

Kubernetes에서 스토리지는 컨테이너와 분리된 외부 저장소로 취급되며, Pod가 재시작되더라도 데이터를 유지하기 위한 목적으로 사용됩니다.

Kubernetes는 스토리지를 다음 세 가지 계층으로 관리합니다:

계층설명

Volume	Pod 내에서 사용하는 저장소 공간 (Container 생명주기와 별도)
PersistentVolume(PV)	클러스터에 사전 정의된 스토리지 자원
PersistentVolumeClaim(PVC)	사용자가 요청한 스토리지 명세 (스토리지 크기, 접근모드 등)

✅ Kubernetes Storage 핵심 개념

용어설명

PV (Persistent Volume)	클러스터 관리자가 만든 실제 스토리지 객체. NFS, iSCSI, Azure Disk 등 연결 가능
PVC (Persistent Volume Claim)	개발자가 요청한 요구사항. PVC가 PV에 매칭되어 바인딩됨
StorageClass	어떤 종류의 스토리지를 사용할 것인지 정의 (예: SSD, Azure Disk, Standard HDD 등)
AccessMode	ReadWriteOnce, ReadOnlyMany, ReadWriteMany (RWX 등)
VolumeMode	Filesystem 또는 Block (특정 DB 등에 사용)
Dynamic Provisioning	PVC를 생성하면 자동으로 PV도 함께 생성 (StorageClass 기반)

✅ Kubernetes에서 지원하는 스토리지 유형 예시

유형예시설명

클라우드 스토리지	Azure Disk, AWS EBS, GCE PD	클라우드 네이티브 Block Storage
파일 기반 스토리지	NFS, Azure File, EFS	공유 폴더 형태, ReadWriteMany 지원
로컬 스토리지	HostPath, Local Volume	특정 노드에 종속됨 (고성능 캐시 등)
CSI (Container Storage Interface)	Ceph, Portworx, NetApp 등	외부 스토리지 공급자와 통합된 표준 인터페이스

✅ 실무 설계 시 고려사항

RWX 접근모드가 필요한 경우 Azure Disk는 불가 → Azure Files, NFS 등 사용
DB용 스토리지는 Block 기반 + 고성능 스토리지 클래스 설정
데이터 손실 방지를 위해 Volume은 StatefulSet과 함께 설계
백업 및 복구 연계: VolumeSnapshot / VolumeSnapshotClass 활용

☁️ 2. Kubernetes Storage 설계 – Azure Landing Zone 관점

✅ Landing Zone이란?

Azure Landing Zone은 조직이 클라우드 환경을 일관성 있게 설계하고 배포할 수 있는 아키텍처 템플릿입니다.
스토리지 관점에서는 Kubernetes + Azure의 연결이 아래와 같은 기준으로 정의됩니다.

✅ Azure Landing Zone에서 스토리지 설계 시 고려 포인트

항목설명

StorageClass 표준화	개발팀이 PVC를 생성할 때 사용할 수 있는 StorageClass 미리 정의 (예: azure-disk-premium, azurefile-csi)
Region/Zone 복제 정책	ZRS(Zonal), LRS(Local), GRS(Geo) 등 스토리지 복제 설정 통일
IAM 및 보안 정책	스토리지 계정 키 대신 AAD Pod Identity 또는 CSI Driver + Managed Identity 사용하여 보안 강화
Backup 정책	VolumeSnapshotClass 기반 자동 백업 및 보존 정책 구성
Monitoring/Logging 연계	Azure Monitor + Application Insights 연동하여 Disk IOPS, 사용량, 실패율 등 모니터링
Private Endpoint 적용	스토리지 계정에 Public Access 차단, VNet 통합 필수
Storage KPI 정의	RPO, RTO, IOPS, Throughput 등 스토리지 SLA 기준 명시

✅ 예시: Azure Kubernetes Service + Azure Disk

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azure-disk-premium
provisioner: disk.csi.azure.com
parameters:
  skuname: Premium_LRS
  kind: Managed
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

위와 같이 StorageClass를 정의하여 개발자들이 PVC 생성 시 명시적으로 선택하도록 유도
Storage KPI, 스냅샷, 가용성 영역은 Landing Zone Policy 또는 Blueprint에 명시

✅ TA 시험 포인트 정리

StorageClass와 PVC/PV 구조 명확히 이해
CSI vs In-tree Driver 비교 가능
Azure Disk와 Azure File의 RWX/RWO 차이 파악
VNet Integration + Private Endpoint 보안 설계
Landing Zone에서 Storage 전략을 문서화할 수 있어야 함
Azure Monitor로 스토리지 성능/오류 추적 구성 가능해야 함

StorageClass와 PVC/PV 구조를 설명해줘

ChatGPT의 말:

좋습니다! 아래는 Kubernetes에서 **StorageClass, PersistentVolume(PV), PersistentVolumeClaim(PVC)**의 구조와 동작 원리를 TA 실무 관점에서 정리한 설명입니다.

📘 StorageClass, PV, PVC 구조 설명

✅ 1. 전체 흐름 개요

Kubernetes의 스토리지는 다음과 같은 3단계 구조로 구성됩니다:

[StorageClass] ← (정책/유형 정의)
      ↑
[PersistentVolume] ← (관리자 정의 or 자동 생성)
      ↑
[PersistentVolumeClaim] ← (사용자가 요청)
      ↑
[Pod] ← (Volume mount 요청)

즉, 사용자는 PVC를 만들고, 그 PVC는 PV에 연결되고, 그 PV는 StorageClass의 정책을 따릅니다.

✅ 2. 구성 요소 설명

📌 A. StorageClass (SC)

스토리지의 **클래스(정책)**를 정의하는 객체.
어떤 종류의 디스크를 만들지, 어떤 프로비저너를 쓸지, 가용성 수준은 어떤지를 정의.

항목설명

provisioner	실제로 스토리지를 프로비저닝할 CSI 드라이버 (예: disk.csi.azure.com)
parameters	디스크 종류 (Premium_LRS, StandardSSD_LRS 등)
volumeBindingMode	즉시 생성(Immediate) or Pod 스케줄링 후 생성(WaitForFirstConsumer)
allowVolumeExpansion	디스크 확장 허용 여부

예시: Azure Disk Premium용 StorageClass

📌 B. PersistentVolume (PV)

클러스터에 존재하는 실제 스토리지 자원.
관리자 또는 동적 프로비저닝에 의해 생성.

항목설명

capacity	크기 (예: 10Gi)
accessModes	RWO / ROX / RWX (읽기쓰기 권한)
volumeMode	Filesystem 또는 Block
storageClassName	어떤 StorageClass 정책을 따르는지

📌 C. PersistentVolumeClaim (PVC)

사용자가 요청하는 스토리지 명세.
스토리지 크기, 접근 방식, StorageClass 지정.

항목설명

resources.requests.storage	요청 크기 (예: 5Gi)
accessModes	접근 모드 (예: ReadWriteOnce)
storageClassName	요청할 스토리지 클래스 지정

예시: PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-example
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: azure-disk-premium

📌 D. Pod 내 볼륨 연결

Pod에서는 PVC를 참조하여 실제 디스크를 컨테이너에 mount 합니다.

volumes:
  - name: data-volume
    persistentVolumeClaim:
      claimName: pvc-example

✅ 3. 실무 고려사항

항목고려 포인트

접근 모드	RWX(ReadWriteMany)가 필요한 경우 Azure Disk는 안 됨 → Azure Files, NFS 사용
Pod 스케줄링 연동	WaitForFirstConsumer 모드는 Pod의 노드에 따라 디스크 리전을 자동 선택함
동적 vs 정적 프로비저닝	대부분은 PVC → PV 자동 생성(Dynamic), 하지만 특수 환경에서는 사전 정의 필요
디스크 확장	allowVolumeExpansion: true로 SC에서 지정 필요 + kubectl patch pvc 가능
Snapshot/Backup	VolumeSnapshotClass와 연동하여 정기 백업 구성 가능

✅ 요약 (한줄 키워드)

개념키워드 요약

SC	디스크 유형/속성 정의
PV	실제 자원 (동적 or 정적 생성)
PVC	사용자 요청 사양 (크기/접근권한)
Pod	PVC를 참조해 mount
AccessMode	RWO / RWX 구분 (Azure Disk는 RWO만)
Dynamic Provisioning	PVC 생성 시 자동 PV 할당
volumeBindingMode	Pod 위치 기반 스토리지 최적화
CSI Driver	Azure, AWS 등 클라우드별 스토리지 플러그인

📘 [파트1] Kubernetes Storage 개요 문제 (객관식 중심)

📌 문항 1

Kubernetes에서 PersistentVolumeClaim(PVC)의 역할로 올바른 것은?

① 스토리지 공급자 CSI 드라이버를 설정한다
② 사용자가 요구하는 스토리지 사양을 정의한다
③ 특정 Pod에서만 마운트 가능한 로컬 디스크를 생성한다
④ 클러스터 전체 로깅을 담당한다
⑤ 스냅샷 기반 백업을 자동화한다

정답: ②
해설: PVC는 사용자가 요청하는 스토리지 용량, 접근 모드, StorageClass를 지정하는 추상화 객체입니다.

📌 문항 2

다음 중 StorageClass의 주요 속성이 아닌 것은?

① provisioner
② parameters
③ storageCapacity
④ volumeBindingMode
⑤ allowVolumeExpansion

정답: ③
해설: storageCapacity는 실제 PV의 속성이며, StorageClass에는 존재하지 않습니다.

📌 문항 3

PersistentVolume(PV)이 Pod에 마운트되기 위해 반드시 필요한 구성 요소는?

① configMap
② StorageClass
③ PersistentVolumeClaim
④ Ingress
⑤ StatefulSet

정답: ③
해설: Pod은 직접 PV를 참조하지 않고, PVC를 통해 바인딩된 PV를 참조합니다.

📌 문항 4

AccessMode가 ReadWriteMany(RWX)인 스토리지를 사용하려면 적절한 예시는?

① Azure Disk
② AWS EBS
③ HostPath
④ Azure File
⑤ CSI Block Volume

정답: ④
해설: Azure Disk는 RWO 전용이고, Azure File이나 NFS와 같은 공유 파일 기반 스토리지만 RWX 지원함.

📌 문항 5

다음 중 Kubernetes에서 **동적 스토리지 프로비저닝(Dynamic Provisioning)**을 사용하기 위한 필수 조건은?

① PV가 수동으로 먼저 생성되어 있어야 한다
② Pod에 직접 StorageClass를 지정해야 한다
③ PVC에서 StorageClassName을 명시해야 한다
④ VolumeSnapshot이 등록되어 있어야 한다
⑤ CSI 드라이버를 수동 컴파일해야 한다

정답: ③
해설: PVC가 특정 StorageClass를 참조하면, Kubernetes는 해당 SC에 정의된 provisioner로 PV를 자동 생성함.

🧪 [파트2] 장애 대응 기반 실무 시나리오 문제

📌 시나리오 문제 1

상황: 개발팀이 StatefulSet 기반의 Redis 클러스터를 배포하였고, Azure Disk를 StorageClass로 사용하고 있다.
문제: 노드 장애 발생 후, Redis Pod가 새로운 노드에서 계속 Pending 상태로 유지되고 있다.
원인으로 가장 가능성이 높은 것은?

① Azure Disk는 RWX이기 때문에 Pod가 어디서든 마운트 가능
② StatefulSet은 PVC를 자동 삭제하므로 디스크가 사라졌다
③ StorageClass의 volumeBindingMode가 Immediate로 되어 있어 스케줄링이 안 맞는다
④ Redis 이미지에 entrypoint 설정이 누락되었다
⑤ PVC가 동적이 아니라 정적 바인딩이다

정답: ③
해설: Azure Disk는 지역 종속적인 RWO 스토리지이므로 WaitForFirstConsumer 모드를 사용해야 Pod 스케줄링 이후 디스크가 할당된다.

📌 시나리오 문제 2

상황: NFS 기반 RWX 스토리지를 사용하는 Web App에서 자주 디스크 오류가 발생하며, I/O error, stale file handle이 로그에 출력된다.
질문: 이 문제를 해결하기 위한 조치로 가장 먼저 수행해야 할 것은?

① StorageClass를 Block 기반으로 변경한다
② DNS 캐시를 초기화한다
③ NFS 서버의 timeout 설정과 클라이언트의 hard 마운트 옵션을 점검한다
④ 스토리지 계정의 Access Key를 재발급한다
⑤ Web App 이미지를 재빌드한다

정답: ③
해설: stale file handle은 NFS 재연결/타임아웃 문제일 가능성이 높음. 서버/클라이언트 양쪽 timeout 및 마운트 옵션(timeo, soft, hard)을 점검해야 한다.

📌 시나리오 문제 3

상황: 개발팀이 PVC와 VolumeSnapshot을 이용해 디스크 스냅샷을 생성하고 복원하려 했지만, 복원된 볼륨으로 Pod가 시작되지 않는다.
가능한 원인은?

① PVC 이름이 Snapshot과 다르기 때문
② Pod이 Liveness Probe를 사용하지 않아서
③ VolumeSnapshotClass와 StorageClass가 호환되지 않음
④ CSI 드라이버 버전이 너무 높음
⑤ PV 용량이 줄어들었기 때문

정답: ③
해설: VolumeSnapshot은 특정 CSI 드라이버 및 StorageClass와 연동 호환성이 요구되므로, 맞지 않을 경우 복원 불가.

📌 시나리오 문제 4

상황: 특정 Pod가 항상 CrashLoopBackOff 상태이며, 로그에는 /data 경로가 존재하지 않는다고 나온다. 해당 Pod는 PVC를 마운트하여 /data를 사용하도록 되어 있다.
원인으로 가장 적절한 것은?

① PVC가 할당된 PV의 accessMode가 ReadOnlyMany로 설정됨
② StorageClass의 allowVolumeExpansion이 false임
③ PVC가 아직 Bound 상태가 아님
④ initContainer가 실패했기 때문
⑤ Pod가 Deployment로 배포되어 있음

정답: ③
해설: PVC가 Bound되지 않으면 Volume이 마운트되지 않고, /data 경로가 존재하지 않는다는 오류로 이어짐.

📌 시나리오 문제 5

상황: 운영 중인 MySQL StatefulSet에서 Azure Disk를 사용 중이고, 사용자가 디스크 성능이 낮다고 불만을 제기했다.
가장 먼저 점검해야 할 항목은?

① 로그 레벨
② Azure Disk의 SKU (Premium/Standard 여부)
③ Kubernetes 버전
④ RBAC 권한
⑤ Deployment 전략

정답: ②
해설: Azure Disk는 SKU에 따라 IOPS/Throughput이 다르므로, Standard HDD 사용 시 성능 저하가 발생할 수 있음.

아래는 Kubernetes Storage에서 실무에서 자주 사용하는 기법 또는 설정 패턴을 기반으로 한 문제들을 TA 시험 스타일로 추가 구성한 것입니다.
총 10문항이며, 정답과 해설 포함, 전부 실제 현업에서 자주 등장하는 기술을 기반으로 제작되었습니다.

📘 Kubernetes Storage 실무 활용 기반 문제 (10문항)

📌 문항 1

Kubernetes에서 Azure Disk를 사용하는 PVC의 크기를 기존 5Gi에서 10Gi로 확장하고자 한다. 필요한 조건으로 올바르지 않은 것은?

① StorageClass에 allowVolumeExpansion: true가 설정되어야 한다
② PVC의 상태가 Bound 상태여야 한다
③ 디스크를 사용하는 Pod가 반드시 실행 중이어야 한다
④ kubectl edit pvc 또는 kubectl patch pvc 명령으로 확장해야 한다
⑤ CSI 드라이버가 디스크 확장을 지원해야 한다

정답: ③
해설: 디스크 확장은 Pod의 실행 여부와 무관하며, PVC 상태와 StorageClass 설정 및 CSI 지원이 중요 요소입니다.

📌 문항 2

Azure Files를 StorageClass로 사용하는 경우 적합한 활용 시나리오는?

① 로그 파일 저장소로 사용되며 여러 Pod에서 동시에 읽기/쓰기가 필요함
② 데이터베이스의 고속 Random I/O를 요구하는 블록 저장소
③ 특정 노드에만 고정되어야 하는 로컬 디스크
④ 성능보다 저렴한 비용이 우선인 경우로, 백업에만 사용
⑤ 컨테이너 이미지 저장소용으로 활용

정답: ①
해설: Azure Files는 RWX를 지원하므로 여러 Pod가 동시에 접근 가능하여 공유 저장소용으로 이상적입니다.

📌 문항 3

StatefulSet으로 구성된 애플리케이션에서 PVC를 삭제하지 않고 Pod만 재생성할 경우, 예상되는 동작은?

① PV도 함께 삭제되어 데이터가 손실됨
② PVC는 삭제되나 Pod가 새롭게 생성되며 다시 PVC가 자동 생성됨
③ PVC는 그대로 유지되며, Pod가 다시 해당 PVC를 참조함
④ Pod는 PVC를 사용할 수 없어 CrashLoopBackOff 상태가 됨
⑤ Pod는 디스크 없이 시작되며 임시 볼륨을 생성함

정답: ③
해설: StatefulSet은 각 Pod에 고유 PVC를 바인딩하며, Pod만 삭제할 경우 PVC는 남아 있어 데이터 유지됨.

📌 문항 4

Azure Files 기반의 RWX PVC를 사용하는 Pod가 성능 저하를 겪고 있다. 아래 조치 중 가장 효과적인 접근은?

① accessMode를 ReadOnly로 변경
② mount 옵션에 cache=none을 적용
③ Azure Premium File Share SKU로 변경
④ Pod의 restartPolicy를 Always로 변경
⑤ CSI 드라이버를 직접 패치

정답: ③
해설: 기본 Azure Files는 성능이 제한적이므로, Premium File Share로 변경하여 IOPS/Throughput을 향상시킬 수 있음.

📌 문항 5

다음 중 Kubernetes에서 CSI Snapshot을 사용하는 목적으로 틀린 것은?

① PVC 백업 및 복구 시점 저장
② 테스트 환경을 원본과 동일하게 복제
③ Pod 간 볼륨 공유를 위한 용도
④ 데이터 무결성 유지 및 감사 대응
⑤ 자동화된 복원 작업에 활용

정답: ③
해설: Snapshot은 복제용이거나 백업 용도이며, Pod 간 공유 용도는 아님 (RWX 설정된 별도 볼륨 필요).

📌 문항 6

스토리지 사용량을 모니터링하고 경고 알림을 보내기 위해 연동할 수 있는 Azure 서비스는?

① Azure Backup Vault
② Azure Monitor + Prometheus Adapter
③ Azure Load Balancer
④ Azure DNS Private Zone
⑤ Azure Key Vault

정답: ②
해설: 스토리지의 성능/사용량 모니터링은 Azure Monitor, Prometheus, Grafana 등과 연계하여 경고 조건 기반 대응 가능.

📌 문항 7

Kubernetes에서 HostPath를 사용한 스토리지는 주로 어떤 목적에 사용되는가?

① 고가용성 DB의 운영 저장소
② 개발 환경에서 로컬 디스크 기반 로그 저장소
③ RWX 공유 볼륨
④ 클러스터 간 공유 디스크
⑤ CSI 기반의 볼륨 백업 기능

정답: ②
해설: HostPath는 특정 노드의 로컬 디렉토리를 사용하므로, 주로 테스트용 또는 임시 로그 저장소에 사용.

📌 문항 8

Azure에서 동적 PVC 생성을 위한 기본 구성 요소가 아닌 것은?

① StorageClass
② PersistentVolumeClaim
③ provisioner 드라이버
④ VolumeSnapshot
⑤ CSI Controller

정답: ④
해설: Snapshot은 백업을 위한 리소스이며, 동적 생성에는 StorageClass, PVC, provisioner 등이 필요함.

📌 문항 9

스토리지 장애 시 PVC를 새로운 디스크로 교체하려면 어떤 단계가 필요하지 않은가?

① 기존 PVC 삭제
② 새로운 PVC 생성
③ Pod 내 volume 이름 변경
④ 기존 Pod 재시작
⑤ 새로운 PVC가 이전 StorageClass와 동일해야 함

정답: ③
해설: Pod의 volume 이름은 YAML 내에서 고정되어 있어 변경하지 않고 PVC 참조만 바꾸면 됨.

📌 문항 10

다음 중 Pod가 스토리지를 사용하면서 겪을 수 있는 대표적인 운영 이슈가 아닌 것은?

① PVC가 Bound 되지 않음
② 스토리지 IOPS 부족
③ Pod의 volumeMount 경로 오타
④ accessMode 불일치
⑤ Service 이름이 잘못 지정됨

정답: ⑤
해설: 스토리지는 Service 구성과 무관하며, 주로 PVC 상태, mount 설정, 디스크 성능 문제가 연관됩니다.

아래는 Kubernetes Storage 실무 활용 기반 추가 10문항입니다.
이전과 동일하게 문제-정답-해설 구성이며, TA 실무에서 자주 출제되는 패턴으로 제작되었습니다.

📘 Kubernetes Storage 실무 문제 (추가 10문항)

📌 문항 11

Azure Disk를 사용하는 Kubernetes Pod가 재시작될 때 마다 디스크가 새로운 노드로 재마운트 되지 못하는 상황이 반복된다. 이 문제의 가장 유력한 원인은?

① accessMode를 ReadOnly로 설정함
② volumeMode가 Block으로 설정됨
③ 디스크의 Zone이 Pod가 스케줄된 노드와 다름
④ StorageClass가 잘못 지정됨
⑤ Pod에 initContainer가 없음

✅ 정답: ③
📝 해설: Azure Disk는 Zone 단위 리소스이므로, Pod가 다른 Zone 노드에 배치되면 재마운트가 실패할 수 있음.

📌 문항 12

Pod에 PVC가 제대로 바인딩되었지만, 실제 컨테이너 내에 파일이 보이지 않는다. 가장 먼저 점검해야 할 항목은?

① PVC의 size
② volumeMount 경로
③ accessMode
④ StorageClass
⑤ CSI 로그

✅ 정답: ②
📝 해설: PVC가 mount 되었더라도 컨테이너 내에서 volumeMount 경로가 잘못 설정되면 실제 사용 불가능.

📌 문항 13

Kubernetes에서 CSI 기반 Azure Disk의 성능이 급격히 저하될 때, 다음 중 조치로 부적절한 것은?

① 디스크 SKU를 Standard HDD에서 Premium SSD로 변경
② pod affinity를 활용하여 동일 Zone 내 Pod 유치
③ 동일 디스크를 여러 Pod가 공유하도록 RWX 모드 활성화
④ IOPS 향상을 위해 디스크 크기 확장
⑤ ReadOnly 모드로 연결하여 읽기 전용 처리

✅ 정답: ③
📝 해설: Azure Disk는 기본적으로 RWO 전용이며, 여러 Pod가 공유 불가하므로 RWX 목적에 적절하지 않음.

📌 문항 14

다음 중 StatefulSet이 스토리지를 사용할 때 일반 Deployment와 다르게 동작하는 점은?

① Pod 수 증가 시 동일한 PVC를 공유함
② Pod 삭제 시 자동으로 PVC도 삭제됨
③ Pod마다 고유한 PVC를 가진다
④ StorageClass는 필수 항목이다
⑤ Pod는 항상 같은 노드에서 실행된다

✅ 정답: ③
📝 해설: StatefulSet은 각 Pod에 고유 이름의 PVC를 자동 생성하여 영구 저장소 분리를 보장함.

📌 문항 15

Azure Files를 사용하는 StorageClass를 생성할 때, 다음 중 필수 구성 요소는?

① skuname, kind, cache
② location, type, accountType
③ provisioner, parameters, reclaimPolicy
④ nodeSelector, taints, tolerations
⑤ mountOptions, iops, tier

✅ 정답: ③
📝 해설: StorageClass에는 provisioner와 parameters(skuname, kind 등) 및 optional한 reclaimPolicy 등이 필수로 포함됨.

📌 문항 16

Pod의 로그 파일을 보존하기 위한 목적이라면 어떤 스토리지가 가장 적합한가?

① ephemeralVolume
② HostPath
③ Azure Disk
④ Azure Files (RWX)
⑤ EmptyDir

✅ 정답: ④
📝 해설: 로그 파일은 여러 Pod가 접근/기록할 수 있도록 **공유 저장소(RWX)**가 적합하며, Azure Files가 대표적.

📌 문항 17

Pod와 연결된 PVC가 Pending 상태에서 벗어나지 못하는 원인은?

① Pod가 실행 중이 아니어서
② StorageClass의 이름이 오타
③ Pod에서 volumeMount를 설정하지 않음
④ 디스크 크기가 너무 작음
⑤ 노드에 충분한 CPU가 없음

✅ 정답: ②
📝 해설: PVC가 PV와 바인딩되지 않는 가장 흔한 이유는 StorageClass 명 오타, 리소스 미존재 등 설정 오류임.

📌 문항 18

Kubernetes에서 디스크를 Snapshot으로 백업하고, 동일한 내용을 가진 PVC를 새로 만들고자 할 때 필요한 자원은?

① VolumeSnapshot, PVC
② PV, PVC, Secret
③ StorageClass, Service
④ Deployment, ConfigMap
⑤ Node, Toleration

✅ 정답: ①
📝 해설: CSI 기반 VolumeSnapshot은 새 PVC 생성 시 DataSource로 지정하여 기존 디스크 상태 복원 가능.

📌 문항 19

Pod 재시작 시 스토리지 마운트가 실패하며 mount failed 에러가 발생할 경우 우선적으로 점검할 요소는?

① CSI 로그 및 이벤트
② Azure Monitor 경고 알림
③ Storage Account SKU
④ PVC 요청 크기
⑤ Service 이름

✅ 정답: ①
📝 해설: CSI 기반 볼륨 마운트 실패는 kubelet 로그 및 CSI 에러 로그에서 원인을 확인 가능함.

📌 문항 20

Azure Files를 사용하는 경우 파일 시스템 기반 RWX 저장소로 사용하기 위해 권장되는 설정은?

① volumeBindingMode: Immediate
② skuname: Standard_LRS, kind: Fileshare
③ mountOptions: [“nobrl”]
④ parameters: usePrivateEndpoint=true
⑤ provisioner: azure-disk.csi.azure.com

✅ 정답: ③
📝 해설: nobrl 옵션은 파일 잠금 충돌을 줄이기 위해 RWX 공유시 권장 mount 옵션으로 사용됨.

스토리지는 시스템 아키텍처에서 매우 중요한 역할을 하며, 각각의 스토리지 유형은 성능, 용도, 비용, 가용성 측면에서 특성이 다릅니다.
아래는 스토리지 종류별 특성과 주요 용도, 그리고 상호 비교표입니다.

📘 스토리지 종류별 용도 및 특성

1. 블록 스토리지 (Block Storage)

대표 기술/서비스: Azure Disk, Amazon EBS, iSCSI, FC(Storage Area Network)
특징:
- 스토리지를 블록 단위로 관리하며, 로우 레벨 I/O 제어 가능
- 고성능, 빠른 읽기/쓰기, 저지연
- 일반적으로 VM, DB, 트랜잭션 시스템에 사용
용도:
- 고속 데이터베이스
- VM의 루트 디스크, OS 디스크
- 로그 저장

2. 파일 스토리지 (File Storage)

대표 기술/서비스: NFS, SMB, Azure Files, Amazon EFS
특징:
- 파일 단위 접근, 공유 가능 (RWX 지원)
- 운영체제의 파일 시스템처럼 mount하여 사용
- 여러 클라이언트에서 동시 접근 가능
용도:
- 로그 공유
- 컨테이너 공유 디렉토리 (ex. 여러 Pod가 동일 디렉토리 접근)
- 사내 문서 저장, 이미지 저장

3. 오브젝트 스토리지 (Object Storage)

대표 기술/서비스: Amazon S3, Azure Blob, Google Cloud Storage
특징:
- 파일을 오브젝트로 저장 (메타데이터 + 데이터 + 고유 ID)
- REST API 기반 접근, 글로벌 확장성
- 버전 관리, 수명주기 관리 용이
용도:
- 백업/아카이빙
- 미디어 파일, 로그 수집
- 웹 콘텐츠 저장 (이미지, 동영상, 정적 파일)

4. 로컬 스토리지 (Local/Host Storage)

대표 기술/서비스: HostPath (Kubernetes), 로컬 디스크
특징:
- 특정 노드의 디스크를 직접 mount
- 빠르지만 고가용성 보장 안됨
- 노드 장애 시 데이터 손실 위험
용도:
- 테스트 환경
- 임시 로그 저장
- 단일 노드 앱

5. 분산 스토리지 (Distributed Storage)

대표 기술/서비스: Ceph, GlusterFS, Longhorn, Portworx
특징:
- 여러 노드에 데이터 분산 저장
- 중복성, 확장성, 고가용성 보장
- 자체적으로 CSI 지원 가능
용도:
- 쿠버네티스 내 영속 볼륨 제공
- 대용량 비정형 데이터 처리
- 멀티AZ 또는 하이브리드 클러스터 환경

📊 스토리지 종류 비교표

구분성능가용성공유 접근주 사용처예시 서비스

블록 스토리지	매우 높음	중	❌	DB, VM OS, 고속 트랜잭션	Azure Disk, EBS
파일 스토리지	중~높음	중	⭕ RWX	로그, 문서, 여러 Pod 공유	Azure Files, NFS, EFS
오브젝트 스토리지	중	매우 높음	⭕ (API)	백업, 정적 자산, 미디어 파일	Azure Blob, Amazon S3
로컬 스토리지	높음	낮음	❌	테스트, 단일 노드, 캐시	HostPath, Local SSD
분산 스토리지	높음	매우 높음	⭕	쿠버네티스 영속 볼륨, 대용량 데이터	Ceph, Longhorn, Portworx

💡 클라우드/K8s 환경에서 선택 기준

고성능 DB → Block Storage (ex. Azure Disk)
Pod 간 공유 저장소 → File Storage (ex. Azure Files RWX)
백업/정적 파일 관리 → Object Storage (ex. Blob, S3)
하이브리드 + 고가용성 → Distributed Storage (ex. Ceph with Rook)
테스트/개발용 임시 디스크 → Local Storage

✅ TA 실무에서의 주요 고려 포인트

항목고려사항

고가용성	Zone/Region 중복 저장, Reclaim Policy
성능	Premium vs Standard, IOPS 측정
보안	Private Endpoint, Access Key, Encryption
자동화	CSI, PVC, VolumeSnapshot, Helm 연동
장애 대응	Pod 재스케줄 시 Volume 재마운트 처리 여부

아래는 Kubernetes + Azure 기반 스토리지 실전 시나리오형 문제 10문항과 장애 대응 중심의 분석 포인트입니다.
TA 실무역량 평가 관점에서 문제-정답-해설 3단 구성으로 제공하며, 실제 Azure 환경과 Kubernetes 연계 사례를 기반으로 제작했습니다.

📘 [Kubernetes + Azure Storage 실무 시나리오 기반 문제 10선]

✅ 문항 1

고객사는 Azure AKS 기반으로 웹 서비스를 운영하고 있으며, 웹 로그 데이터를 공유 스토리지에 저장하도록 구성했다. 최근 로그 데이터가 일부 누락되는 현상이 발생하고 있다. 이 경우 점검할 항목으로 적절하지 않은 것은?

① Azure Files의 RWX 사용 여부
② StorageClass의 mountOptions 설정
③ volumeMount 경로 누락 여부
④ Pod 간 affinity/anti-affinity 설정
⑤ Azure Storage Account의 Premium 설정 여부

정답: ⑤
해설: 로그 누락과는 성능보다 공유 접근(RWX) 및 mount 경로 충돌이 주요 원인일 수 있음. Premium 설정 여부는 성능과는 관련 있지만 직접적인 누락 원인은 아님.

✅ 문항 2

Azure Disk 기반 PVC를 사용하는 앱에서 노드 재시작 후 디스크 마운트가 실패하고 있다. 이 문제의 가능한 주요 원인은?

① ReadOnly 마운트 옵션이 설정됨
② Disk가 다중 Zone에 걸쳐 할당됨
③ VolumeSnapshot이 활성화 상태임
④ Disk와 Pod가 서로 다른 Zone에 존재
⑤ PVC의 accessMode가 RWX임

정답: ④
해설: Azure Disk는 Zone 단위 리소스로, Pod가 다른 Zone으로 스케줄링되면 attach/mount 실패 발생 가능.

✅ 문항 3

AKS 클러스터에 StatefulSet으로 배포된 Redis가 여러 번 재시작되며, 데이터가 유실되는 문제가 발생했다. 가장 가능성 높은 원인은?

① PVC의 reclaimPolicy가 Retain
② volumeMount 설정 누락
③ VolumeSnapshot 정책 없음
④ Pod 재시작 시 PVC가 삭제됨
⑤ Service가 headless로 구성되어 있음

정답: ④
해설: StatefulSet에서 PVC에 volumeClaimTemplates가 없거나 삭제 후 recreate 시 PVC가 제거될 수 있음. 이로 인한 데이터 유실 가능.

✅ 문항 4

AKS에 배포된 컨테이너가 mount failed 에러와 함께 시작하지 못하고 있다. CSI 로그를 확인한 결과, "disk not found" 오류가 발생했다. 가장 가능성 높은 원인은?

① volumeMode가 Block으로 설정됨
② reclaimPolicy가 Retain임
③ StorageClass가 존재하지 않음
④ 사용된 Disk가 삭제됨
⑤ podAffinity 설정이 없음

정답: ④
해설: CSI 로그에 디스크 미존재 오류가 발생한 경우, Azure Disk가 삭제되었거나 연결 실패한 상태일 가능성 높음.

✅ 문항 5

AKS 환경에서 Azure Files를 사용하는 공유 PVC를 구성하고자 한다. 필수 조건이 아닌 것은?

① accessMode: ReadWriteMany
② provisioner: file.csi.azure.com
③ mountOptions: [nobrl]
④ Storage Account Tier: Premium
⑤ VolumeBindingMode: Immediate

정답: ④
해설: Azure Files는 Standard Tier에서도 RWX 지원 가능하며, Premium은 필수는 아님. RWX 구조가 핵심.

✅ 문항 6

운영 중인 AKS에서 백업 솔루션과 연동하여, Redis PVC에 대해 주기적으로 스냅샷을 생성하고 복구 가능하게 구성하고자 한다. 올바른 절차 흐름은?

① PVC 생성 → VolumeSnapshotClass 생성 → VolumeSnapshot 생성
② PV 생성 → PVC 바인딩 → pod 실행
③ Deployment 생성 → VolumeMount 설정 → pod 실행
④ Azure Blob Storage 생성 → ConfigMap에 mount
⑤ Pod에 직접 디스크 mount → VolumeSnapshot 생성

정답: ①
해설: Kubernetes CSI 기반 스냅샷은 VolumeSnapshotClass → VolumeSnapshot → PVC 연결의 흐름을 따름.

✅ 문항 7

Azure Files로 구성된 PVC를 사용하는 Pod가 정상 실행되었으나, 파일시스템 내에서 파일 접근 시 I/O 에러가 간헐적으로 발생한다. 해결책으로 적절한 것은?

① Azure Disk로 변경
② mountOptions: [“nobrl”] 설정
③ reclaimPolicy를 Retain으로 변경
④ VolumeSnapshot 사용
⑤ accessMode를 ReadOnly로 변경

정답: ②
해설: nobrl 옵션은 Azure Files에서 파일 잠금 관련 I/O 에러를 방지하는 대표적 설정임.

✅ 문항 8

Azure Kubernetes 환경에서 오브젝트 스토리지(Azure Blob)를 Pod에서 직접 Mount 형태로 사용하려 한다. 다음 중 적절한 설계 방식은?

① CSI volume으로 Blob 컨테이너 직접 마운트
② Azure Files로 Blob 연결
③ Azure Disk를 Blob에 연결
④ BlobFuse2 CSI 드라이버 사용
⑤ Blob을 Pod의 EmptyDir로 Sync

정답: ④
해설: Azure Blob은 기본적으로 Mount 방식이 아닌 REST API 기반 접근이며, BlobFuse2 CSI 드라이버를 통해 Mount가 가능.

✅ 문항 9

스토리지에 민감한 워크로드가 포함된 AKS 환경에서 모든 볼륨의 스냅샷 및 복구를 자동화하려 한다. 고려해야 할 Kubernetes 리소스는?

① CronJob
② VolumeSnapshot & VolumeSnapshotClass
③ StatefulSet
④ Toleration
⑤ ConfigMap

정답: ②
해설: CSI 기반 VolumeSnapshot 리소스를 통해, 특정 주기로 스냅샷을 생성하고 필요 시 복구 가능.

✅ 문항 10

운영 중인 AKS 클러스터에서, 디스크 사용률이 급격히 증가하며 Pod의 I/O 지연 현상이 발생한다. 적절한 대응 방안은?

① 디스크 크기 확장
② StorageClass 변경
③ accessMode를 ReadOnly로 전환
④ volumeMode를 Block으로 변경
⑤ Pod 수 축소

정답: ①
해설: Azure Disk의 경우 디스크 크기에 따라 IOPS와 Throughput도 자동 증가하므로, 성능 확보를 위해 디스크 확장이 필요.

🔎 Kubernetes + Azure Storage 실무 대응 포인트 요약

항목핵심 고려사항

고가용성	Disk Zone → Node Zone 매칭, CSI 자동 failover
스냅샷	VolumeSnapshot 활용, 백업 정책 자동화
성능	디스크 SKU, 크기 확장 → 성능 향상
공유 저장소	Azure Files(RWX) + nobrl, 또는 BlobFuse2
마운트 이슈	CSI 로그 확인, PVC 상태 확인
삭제 이슈	reclaimPolicy 및 volumeBindingMode 확인

아래는 Kubernetes + Azure Storage 환경에서 사용되는 주요 개념과 실무 대응 요소를 요약한 **암기카드(Flashcards)**와 블로그/오픈북용 키워드 인덱스 정리본입니다.
TA 시험 대비 및 실무 대응 학습용으로 활용할 수 있도록 구성했습니다.

🧠 Kubernetes + Azure Storage 암기카드

번호키워드개념 요약

01	PVC (PersistentVolumeClaim)	Pod가 요청하는 스토리지의 사양/용량을 정의하는 객체
02	PV (PersistentVolume)	클러스터에서 관리하는 실제 스토리지 리소스
03	StorageClass	스토리지 프로비저닝 및 파라미터를 정의하는 객체
04	accessMode	ReadWriteOnce, ReadOnlyMany, ReadWriteMany
05	reclaimPolicy	Delete, Retain, Recycle – 볼륨 삭제 정책
06	Azure Disk	단일 Pod용 고성능 블록 스토리지, Zonal 리소스
07	Azure Files	RWX 공유 가능한 파일 스토리지
08	VolumeSnapshot	CSI 기반 볼륨 스냅샷 기능, 백업/복구에 활용
09	VolumeSnapshotClass	스냅샷 방식 및 CSI 드라이버 정의
10	CSI 드라이버	컨테이너 볼륨 연동을 위한 인터페이스 표준
11	BlobFuse2	Azure Blob Storage를 마운트 가능한 드라이버
12	mountOptions	nobrl, dir_mode, file_mode 등 파일시스템 옵션
13	VolumeBindingMode	Immediate, WaitForFirstConsumer – 스케줄링 정책
14	StatefulSet	각 Pod에 고유한 스토리지를 할당하는 컨트롤러
15	Azure Monitor	스토리지 IOPS, 처리량, 사용률 모니터링
16	스토리지 장애 대응	Zone 일치, CSI 로그 확인, accessMode/RWX 검토
17	Disk 확장	Azure Disk 확장은 IOPS/Throughput도 향상
18	Retain 정책	삭제된 PVC/PV의 데이터 보존 가능성 있음
19	VNet 연결	App에서 Storage 접근 시 VNet 통합 고려
20	KEDA + PVC	Azure Functions나 Event 기반 워크로드와 연계 가능

🔍 Kubernetes + Azure Storage 키워드 인덱스 (오픈북 검색용)

[Ctrl + F]로 빠르게 검색할 수 있도록 주요 키워드 정리

StorageClass 정의 PVC와 PV 차이 accessMode 종류 reclaimPolicy 유형 Azure Disk 특성 Azure Files 특징 RWX 설정 VolumeSnapshot 사용법 VolumeSnapshotClass 정의 StatefulSet 스토리지 연동 CSI 마운트 오류 해결 BlobFuse2 마운트 구성 AKS Volume 확장 스토리지 성능 모니터링 nobrl mount option Zone mismatch 대응 Immediate vs WaitForFirstConsumer 스냅샷 자동화 구성 Pod 재시작 시 PVC 유지 AKS 장애 시 디스크 이슈 분석

Azure 기반 랜딩존(Landing Zone) 구성 및 시스템 이관(On-Prem → Cloud) 시에는 백업(Backup) 및 복구(Recovery) 전략이 매우 중요합니다.
아래에 TA 시험 및 실무 설계 기준으로 알아야 할 핵심 내용을 요약해드립니다.

📌 1. 랜딩존 환경에서 Backup & Recovery의 중요성

🔹 랜딩존이란?

기업이 Azure로 클라우드 환경을 확장하거나 마이그레이션하기 위한 표준 아키텍처 템플릿
보안, 거버넌스, 네트워크, 리소스 그룹, 정책, 모니터링, 백업 등 기반 구성요소 포함

🔹 Backup & Recovery의 역할

이관 시점: 데이터 이전 중 오류, 재시도 가능성에 대비
운영 시점: SLA 보장, 장애 대응, 데이터 무결성 확보
DR 구성: 멀티 리전 복제 또는 스냅샷을 통한 빠른 서비스 복구

📌 2. 주요 백업 시나리오

시나리오설명

시스템 전체 이관	온프레미스 VM → Azure VM으로 이관 시, Recovery Services Vault 이용하여 이전 상태 스냅샷 보관
DB 이관	SQL, Oracle, Altibase 등의 DB는 백업 파일 + Point-In-Time 복구 기능 고려
Kubernetes 마이그레이션	PVC/VolumeSnapshot 활용 + Velero 같은 오픈소스 툴로 전체 상태 백업
파일 공유	Azure Files는 Geo-redundant 저장소(GRS) 설정 + 정기 스냅샷 구성
Blob 백업	Blob Lifecycle Policy, Soft Delete, Immutable Blob 등으로 백업 보존 가능

📌 3. Azure 백업 구성 요소

✅ Azure Backup

PaaS 형태의 백업 관리 서비스
VM, 파일, SQL DB, SAP HANA, Azure Blobs 등 지원
Recovery Services Vault에 모든 백업 메타데이터 저장

✅ Azure Site Recovery (ASR)

장애 대비 목적의 DR 구성 서비스
Region 간 VM 복제 및 Failover/Failback 기능
랜딩존 구성에서 DR Zone 연계에 활용

✅ VolumeSnapshot (Kubernetes)

CSI 기반 볼륨 스냅샷 기능
VolumeSnapshotClass 정의 → VolumeSnapshot 리소스로 백업/복구 가능

✅ Azure Blob Backup

Soft Delete / Versioning / Immutable Blob
Vault와 연동한 장기 보존도 가능

📌 4. 설계 시 고려사항

고려 요소설명

RTO (Recovery Time Objective)	장애 발생 후 복구 소요 시간 목표 (Ex: 30분 이내)
RPO (Recovery Point Objective)	데이터 손실 허용 범위, 마지막 백업 시점 기준 (Ex: 5분 이내)
백업 빈도	OS별, DB별, 워크로드별 일/시간 단위 자동화
암호화 및 보안	저장소 암호화, 백업 전송 중 암호화, Key Vault 통합
접근 제어	백업/복구 수행 권한은 RBAC + Conditional Access + Locking 사용
보존 주기	단기(7~~30일), 중기(3~~6개월), 장기(7년 이상) 정책 구분 설정
리전 고려	주 리전 장애를 대비한 Geo-Replication, ZRS 또는 GRS 구성

📘 예시 아키텍처 (랜딩존 + 백업 통합)

[On-Prem Server] │ │ 백업 → Azure Blob or Recovery Vault ↓ [Azure Landing Zone 구성] ├── Hub Network + Bastion + Firewall ├── Workload Subnet (AKS, VM, DB) ├── Recovery Services Vault (Backup & Snapshot 저장소) └── Site Recovery for DR (Cross-Region Replication)

✅ 실전 TIP (TA 시험/설계 관점)

RPO/RTO 값과 워크로드 중요도 매핑할 것
VM은 Azure Backup + Azure Site Recovery 동시 구성 가능
스토리지 클래스에 따라 스냅샷 지원 여부 다름 (Premium = 지원, 일부 Standard는 불가)
Blob은 Immutable Policy 설정을 통한 랜섬웨어 대응 가능
Recovery Vault는 30개 제한 있으므로 리소스 그룹별 적절한 분배 필요

📘 RPO/RTO 설계 기반 문제집 (정답+해설 포함)

✅ 문항 1

Azure에서 VM 백업 구성 시, RPO가 1시간이면 어떤 조건을 충족해야 하는가?
A. 백업은 하루 1회 이상 수행하면 충분하다
B. 장애 발생 시 1시간 이내 서비스가 복구되어야 한다
C. 마지막 백업 시점 기준으로 1시간 이내의 데이터만 손실 가능하다
D. Recovery Services Vault는 GRS로 구성되어야 한다
E. VM 재부팅 없이 백업 수행이 가능해야 한다

정답: C
해설:
RPO는 데이터 손실 허용 범위로, “마지막 백업 시점부터 현재까지의 데이터 중 몇 시간분을 잃어도 되는가”를 의미한다.

✅ 문항 2

업무 중요도가 높은 DB 서버의 RTO를 10분으로 설정한 경우, 백업 구성 외에 필수 고려사항은?
A. 백업 데이터의 장기보존 정책
B. 백업 대상 리소스를 GRS로 설정
C. DR 리전에 미리 Standby VM을 띄워둠
D. Soft Delete 활성화
E. 스냅샷 주기를 주 1회로 설정

정답: C
해설:
RTO는 장애 발생 후 서비스 재개까지 소요되는 시간이다. 10분 이내 복구가 필요하다면 미리 DR 환경을 준비해 두는 것이 필수다.

✅ 문항 3

RPO 5분, RTO 30분인 ERP 시스템에 가장 적합한 백업 전략은?
A. 일 1회 백업 + Cold Standby 구성
B. 5분 주기 트랜잭션 로그 백업 + ASR로 Warm Standby
C. 하루 3회 백업 + Blob Lifecycle 관리
D. Storage Snapshot 매일 1회 + Retain 정책
E. VM Level Image Backup 주 1회

정답: B
해설:
5분 이내 데이터 손실(RPO) + 30분 내 서비스 재가동(RTO)을 보장하려면 트랜잭션 백업과 Warm Standby 조합이 적절하다.

✅ 문항 4

On-Prem에서 Azure로 시스템을 마이그레이션하는 경우, 이관 중 백업 전략으로 적절한 것은?
A. 대상 VM만 백업하면 충분하다
B. 이관 후 백업 구성이 필요하므로 미리 구성하지 않아도 된다
C. Recovery Vault를 활용해 이전 VM 상태 백업 유지
D. Blob Storage에 백업된 상태이면 추가 백업은 필요 없다
E. 백업은 오직 시스템 종료 후 수행해야 한다

정답: C
해설:
마이그레이션 중 장애/롤백에 대비해 원본(On-Prem) 및 Azure 대상 VM 모두 백업해 두는 것이 중요하다.

✅ 문항 5

Azure Kubernetes 환경에서 StatefulSet의 PV가 손상되었을 때, RPO 최소화를 위한 조치는?
A. emptyDir로 임시 저장소 활용
B. VolumeSnapshot을 주기적으로 생성
C. StorageClass를 Delete 정책으로 설정
D. mount 옵션을 제거
E. CSI Controller 로그만 모니터링

정답: B
해설:
RPO를 줄이려면 주기적인 Snapshot으로 최신 데이터를 보존해야 한다.

✅ 문항 6 (시나리오형)

회사는 SLA 99.9%를 요구하는 고객 서비스를 Azure에 배포 중이다. RTO는 15분, RPO는 10분이다.
이 요건을 충족하기 위해 구성할 수 있는 백업 전략으로 적절한 것은?
A. Recovery Vault만 구성
B. GRS 설정된 Blob 백업만 구성
C. ASR로 DR 구축 + 10분 주기 백업
D. 스냅샷 주 1회 + Soft Delete 설정
E. RTO가 짧기 때문에 백업은 불필요

정답: C
해설:
재해 대비 시나리오에선 RTO를 위한 Standby 및 ASR, RPO를 위한 빈번한 백업이 모두 필요하다.

✅ 문항 7

다음 중 RTO와 RPO의 정의로 올바른 것은?
A. RTO는 백업이 수행되는 최대 간격이다
B. RPO는 서비스를 재시작할 수 있는 최소 시간이다
C. RTO는 시스템 복구까지 걸리는 시간이다
D. RPO는 서비스 SLA 가용성 기준이다
E. 둘 다 백업 보존 주기를 의미한다

정답: C
해설:
RTO는 서비스가 복구되기까지 걸리는 총 소요 시간을 의미한다. (RPO는 데이터 손실 허용 범위)

✅ 문항 8

RTO는 짧고 RPO는 길게 설정할 수 있는 예시는?
A. 금융거래 시스템
B. 회계 결산 시스템
C. 정기 리포트 생성 시스템
D. 실시간 API Gateway
E. IoT 센서 데이터 수집 플랫폼

정답: B
해설:
복구는 빠르게 되어야 하지만, 데이터가 일정 주기로 생성되는 시스템은 RPO를 길게 설정 가능하다.

✅ 문항 9

Azure에서 Recovery Services Vault를 사용할 때 고려할 사항으로 틀린 것은?
A. 지역별로 Vault는 30개까지만 생성 가능
B. 보존 주기와 암호화는 정책에 따라 설정 가능
C. Vault는 GRS가 기본 구성이다
D. 동일한 Vault에서 VM과 Blob을 동시에 백업할 수 있다
E. Vault는 Key Vault와 연동해 보안 강화 가능

정답: D
해설:
Vault는 VM 백업에 주로 사용되며, Blob Storage 백업은 별도의 방식으로 구성된다.

✅ 문항 10 (시나리오형)

AKS 기반 서비스에서 CSI 기반 PV에 문제가 발생해 복구 시 스냅샷이 존재하지 않았다. 이 문제로부터 얻는 교훈은?
A. Kubernetes는 기본적으로 백업을 보장한다
B. CSI Volume은 자동으로 백업되므로 설정 불필요하다
C. StorageClass에 Retain 설정이 필수다
D. RPO 보장을 위해 Snapshot 정책을 명시적으로 구성해야 한다
E. 볼륨 손실 시 복구가 불가능하므로 이중화는 필요 없다

정답: D
해설:
Kubernetes 환경에서는 수동 혹은 자동 스냅샷 설정 없이는 RPO를 보장할 수 없다.

📌 다음 추천

📄 Word / PDF 다운로드용 문제집
💡 암기카드 요약본 (RPO/RTO 핵심 포인트)
🧪 실습 시나리오 (ASR 구성 / Snapshot 생성 / 복구 테스트)
📘 문제 난이도별 분류 및 실전 CBT 모의시험 버전

요청 시 확장해드릴 수 있습니다. 어떤 형식이 더 필요하신가요? (예: 문서 다운로드, 정답 숨김용, YAML 샘플 등)

나의 말:

Azure Backup 서비스별 지원 Matrix 정리표

ChatGPT의 말:

Azure Backup 서비스는 다양한 리소스 유형에 따라 지원 범위가 다릅니다. 아래에 서비스별 지원 Matrix를 정리해 드립니다. TA 시험 및 실무 설계에 바로 활용할 수 있도록 리소스 유형, 지원 항목, 제한사항을 기준으로 구성하였습니다.

📘 Azure Backup 서비스별 지원 Matrix (정리표)

리소스 유형백업 가능 여부복구 가능 여부백업 방식주요 제한사항

Azure VM (IaaS)	✅ 지원	✅ 지원	이미지 기반 (Snapshot + Vault)	최대 1일 3회 제한 ASR과 병행 가능
Azure File Share	✅ 지원	✅ 지원	Snapshot 기반	Soft Delete 사용 권장 GRS 필수 아님
SQL Server (on Azure VM)	✅ 지원	✅ 지원	애플리케이션 수준 백업	SQL 인증 필요 System databases 백업 불가
SAP HANA (on Azure VM)	✅ 지원	✅ 지원	인앱 백업 에이전트 방식	SUSE/RedHat VM에서만 지원
Azure Blobs	❌ 직접 백업 불가	❌ 직접 복구 불가	Lifecycle, Soft Delete, Versioning 활용	별도 Vault 백업 없음
Azure Managed Disks	❌ 직접 백업 불가	❌ 직접 복구 불가	Snapshot 별도 구성	Snapshot은 자동 보존 아님
Azure Kubernetes (AKS)	❌ 직접 미지원	❌ 직접 미지원	VolumeSnapshot 사용 (CSI 필요)	Velero 등 외부 도구 필요
Azure Database for PostgreSQL / MySQL	✅ 자동 지원	✅ 자동 지원	내부 스케줄링 백업	보존 주기 변경 불가
Azure Database for SQL (PaaS)	✅ 자동 지원	✅ 자동 지원	PITR (Point-In-Time Restore)	최대 35일까지 보존
On-Prem 서버	✅ 지원	✅ 지원	MARS 에이전트 or DPM 이용	공용 IP 또는 VPN 필요

🔍 백업 유형 정리

백업 방식적용 서비스특징

Vault 기반 백업	Azure VM, File Share, SQL on VM 등	Recovery Services Vault에 메타데이터 저장
Application-aware Backup	SQL, SAP HANA	트랜잭션 일관성 보장
Snapshot 기반	File Share, Managed Disk, AKS Volume	빠른 복원, 일정 기간 보존
PaaS 내장 백업	Azure SQL DB, PostgreSQL	자동 백업 주기, 별도 구성 불필요
MARS Agent	On-Prem 서버	에이전트 기반 백업, Vault 연동

⚠️ 실무/설계 시 고려사항

Vault당 백업 항목 수 제한: Azure에서는 리소스/리전별 제한이 존재하므로 설계 시 고려해야 함
Snapshot 기반 백업은 장기보존 비적합
AKS 백업은 기본 미지원 → Velero, Kasten, Trilio 같은 서드파티 솔루션 사용
Blob은 백업 대신 Soft Delete + Immutable Storage로 보호
ASR과 Azure Backup은 동시 적용 가능 (예: VM 단위 DR 및 백업 분리)

🧩 보완 자료 요청 가능

📄 PDF 또는 Word 문서로 출력용 표 제공
🧪 서비스별 실습 예시 (Vault 설정, SQL 백업 구성, Velero AKS 백업 등)
📝 문제집 (Matrix 기반 문항 10제)
📘 암기카드 요약본

원하시는 형식이 있다면 말씀 주세요. 필요한 문제 구성 또는 YAML 예시도 함께 드릴 수 있습니다.

나의 말:

문제집 (Matrix 기반 문항 10제)

ChatGPT의 말:

다음은 **Azure Backup 서비스 지원 Matrix 기반 TA 문제집 (10문항)**입니다.
모든 문항은 정답 + 해설과 함께 제공되며, TA 역량시험에서 자주 나올 수 있는 형태로 구성했습니다.

📘 Azure Backup Matrix 기반 문제집 (10문항)

✅ 문항 1

Azure IaaS VM에 대한 백업 방식으로 적절한 것은?
A. Blob Storage Versioning
B. Azure Snapshot API
C. Recovery Services Vault 기반 이미지 백업
D. Azure SQL 자동 백업 기능
E. MARS Agent 직접 연결

정답: C
해설:
Azure VM은 Vault를 통해 이미지 기반 백업이 가능하며, VM 구성 정보와 데이터까지 포함함.

✅ 문항 2

Azure Blob Storage는 어떤 방식으로 백업/보호되는가?
A. Recovery Vault
B. File Sync
C. Soft Delete 및 Immutable 설정
D. Azure Files 기반 자동 백업
E. Azure Backup Center

정답: C
해설:
Blob은 직접적인 백업 기능이 없어 Soft Delete, Versioning, Immutable Storage로 보호한다.

✅ 문항 3

Azure Files 백업 구성 시 Vault 사용 여부는?
A. 사용할 수 없다
B. 사용은 가능하지만 권장되지 않는다
C. Snapshot 기반으로 Vault에 저장된다
D. Snapshot은 자동 보존되지 않는다
E. 백업 불가능한 리소스이다

정답: C
해설:
Azure Files는 Vault와 연동되며 Snapshot 기반 백업이 가능하다.

✅ 문항 4

On-Premise 서버를 Azure Backup으로 보호하기 위한 필수 구성은?
A. Azure VPN Gateway
B. Azure NetApp Files
C. MARS Agent 설치
D. AKS CSI Driver
E. Key Vault 백업 연동

정답: C
해설:
MARS Agent를 통해 Azure Vault와 연결되어 백업이 가능하다.

✅ 문항 5

AKS 클러스터의 Persistent Volume에 대한 백업 구성으로 옳은 것은?
A. Azure File Sync 자동 백업
B. Azure Vault에서 자동 스냅샷 생성
C. CSI 기반 VolumeSnapshot 수동 구성
D. MARS Agent를 활용한 자동 백업
E. Azure Blob Lifecycle 활용

정답: C
해설:
AKS는 기본 백업이 없으며, CSI 기반 Snapshot을 사용하여 PV 단위 백업을 구성해야 한다.

✅ 문항 6

다음 중 Azure VM 백업의 주요 제한사항으로 옳은 것은?
A. 백업 주기 1시간마다 설정 가능
B. 스냅샷은 최대 7일만 보존 가능
C. Recovery Vault당 100개의 VM만 가능
D. 하루 최대 3회 백업 지원
E. Vault는 GRS 필수

정답: D
해설:
Azure VM은 하루 최대 3회 백업이 가능하며, 더 빈번한 백업은 별도 구성 필요.

✅ 문항 7

Azure SQL PaaS의 백업 정책으로 올바른 설명은?
A. 수동 스냅샷 구성 필요
B. Azure Backup Vault로 구성
C. 기본 7일, 최대 35일 PITR 가능
D. Blob Versioning으로 구성
E. Azure Files와 동일한 정책 적용

정답: C
해설:
Azure SQL은 내장 자동 백업이 존재하며, 최대 35일까지 Point-In-Time Restore를 지원한다.

✅ 문항 8

Azure File Share 백업 시 Soft Delete가 중요한 이유는?
A. 지역간 복제를 위해
B. 백업 보존 비용 절감을 위해
C. Vault 연결이 불가능하므로 대안 필요
D. 사용자 삭제에 대한 복구를 지원
E. 고정된 백업 주기 때문

정답: D
해설:
Soft Delete는 실수로 삭제된 파일을 복구할 수 있는 기능이다.

✅ 문항 9

다음 중 Vault 기반 백업이 아닌 것은?
A. Azure VM
B. Azure File Share
C. SQL Server on Azure VM
D. Blob Storage
E. On-Prem 서버 (MARS Agent)

정답: D
해설:
Blob은 Vault 기반 백업을 직접 지원하지 않음.

✅ 문항 10

Azure에서 SAP HANA 백업을 구성할 때 필요한 전제조건은?
A. Azure NetApp Files 연동
B. 전용 SAP Vault 구성
C. SUSE/RedHat OS 기반의 VM
D. MARS Agent 설치
E. Azure CLI 전용 스크립트 사용

정답: C
해설:
SAP HANA 백업은 SUSE 또는 RedHat 기반 Azure VM에서만 지원된다.

📘 다음 확장 가능 항목

📄 Word/PDF 변환
🎯 난이도 표시 (상/중/하)
✅ 정답 숨김용 연습 버전
💡 실전 CBT용 랜덤 셔플 문제집
🗂️ 암기카드 요약본

요청 주시면 바로 제작해드리겠습니다. 어떤 형식으로 저장해드릴까요?

나의 말:

MARS Agent에 대해 간략히 설명해줘

ChatGPT의 말:

Azure에서 사용하는 **MARS Agent (Microsoft Azure Recovery Services Agent)**는 온프레미스 환경의 서버나 클라이언트를 Azure에 백업하기 위해 설치하는 에이전트 프로그램입니다. 주로 Vault 기반 백업이 직접 지원되지 않는 물리/가상 서버에 사용됩니다.

🧩 MARS Agent 핵심 정리

1. ✅ 주요 역할

온프레미스 시스템 → Azure Vault로 백업
파일/폴더 단위 백업 가능 (디스크 전체 이미지 백업은 불가)
Azure Portal을 통해 스케줄 설정, 보존 기간, 암호화 등 관리 가능

2. 🖥️ 적용 대상

적용 가능 대상예시

물리 서버	Windows Server 2012, 2016, 2019 등
가상 서버	Hyper-V, VMware 등
클라이언트 PC	Windows 10/11 Pro 등 (보안 백업 목적)

3. ⚙️ 기능 요약

항목내용

백업 범위	파일/폴더 단위
백업 대상	온프레미스 서버/PC
연결 방식	인터넷 통신 (공용망 또는 VPN)
암호화	백업 전 암호화, 키는 로컬에서만 보관
보존 기간	최대 99년 설정 가능
복원 기능	포털 또는 에이전트에서 직접 복원 가능

4. ❗ 제약사항

VM 단위 전체 백업은 Azure Backup Vault + VM Extension 필요
Linux는 미지원, Windows 기반 서버/클라이언트만 지원
DB, 앱 인식 백업 불가 (SQL 등은 별도 Azure Backup Agent 필요)
인터넷 연결 필요 (프록시 설정 가능)

🧠 요약 암기 문장 (TA용)

“MARS Agent는 온프레미스 서버/PC의 파일 단위 백업을 Azure Vault로 수행하는 Windows 전용 에이전트로, 복구 지점 기반 복구 및 강력한 암호화를 지원하지만 전체 VM 백업이나 DB 백업은 지원하지 않는다.”

필요하다면 다음도 도와드릴 수 있어요:

✅ MARS Agent 설치 및 Vault 등록 절차 (화면 캡처 포함)
📄 Word 문서/PDF 출력용 구성
🧪 관련 실전 문제 (예: VPN 경로 차단, 에이전트 복구 실패 등)

진행할까요?

나의 말:

이제 암기카드 요약본 부탁해

ChatGPT의 말:

다음은 Azure Backup + MARS Agent + RPO/RTO 등 백업 및 복구 관련 암기카드 요약본입니다.
TA 오픈북 시험 대비용으로 간결한 한 줄 키워드 요약 + Ctrl+F용 키워드 인덱스 구성입니다.

📘 암기카드 요약본 (한 줄 키워드 위주)

키워드설명 요약

Recovery Services Vault	Azure VM/File/SQL 등의 백업 메타데이터 저장소
MARS Agent	온프레미스 Windows 서버/PC → Azure Vault 백업용 에이전트
Vault 기반 백업	Azure VM, SQL on VM, File Share 등 지원, 하루 최대 3회
Soft Delete (Blob)	삭제 방지 기능, Blob은 백업 직접 미지원
Snapshot 기반 백업	AKS PV, File Share 등에 적용, 빠른 복구
Azure SQL 백업	자동 PITR, 최대 35일, Vault 불필요
AKS 백업	CSI Snapshot 사용, Velero 등 서드파티 도구 필요
On-Prem 백업 구성요소	MARS Agent, 인터넷 통신 또는 VPN 필요
SAP HANA 백업	SUSE/RedHat VM에서만 지원, 애플리케이션 인식 백업
Backup Center	백업 정책 및 상태 통합 관리 포털
RPO	데이터 손실 허용 한계 시간, 백업 주기 기준
RTO	복구 완료까지의 최대 시간 허용 범위
Blob Versioning	데이터 보호용, 백업 대체 X
Immutable Blob	변경 불가능한 상태로 보존, 보안 강화
SQL on Azure VM	Vault 기반 애플리케이션 백업 필요, SQL 인증 사용
파일 단위 복원	MARS Agent로 개별 파일 복원 가능
DPM / MABS	온프레미스 백업 솔루션, Vault 연동 가능
보존 기간 정책	최대 99년(MARS 기준), Vault 기반 설정
백업 암호화 키	로컬 생성, Azure에 저장되지 않음

🔍 Ctrl+F 검색용 키워드 인덱스

Recovery Services Vault, MARS Agent, Azure Backup, Soft Delete, Blob 백업, Snapshot Backup, Azure SQL 백업, AKS 백업, CSI Snapshot, Velero, On-Prem 백업 구성, SAP HANA Backup, Backup Center, RPO, RTO, Immutable Blob, Versioning, SQL 인증 백업, 파일 복원, 보존 정책, 암호화 키

📎 활용 팁

TA 시험 중 Backup 구성 설명, DR 설계, 이중화 요소, Vault 보존 정책, AKS Snapshot 구성 등이 키워드로 출제될 수 있습니다.
블로그나 문서에 붙여넣고 Ctrl+F로 “Vault”, “MARS”, “Snapshot” 등의 키워드를 검색해서 빠르게 찾도록 설계되었습니다.

필요 시 아래도 추가 가능:

📝 “Backup 설계 문제집 + 장애 대응 시나리오 문제 10제”
📄 이 카드 내용을 PDF/Word로 변환
📊 서비스별 백업 복구 Flow 도식화

원하시는 방식 알려주시면 바로 제작 도와드릴게요!

나의 말:

장애 대응 시나리오 문제 10제

ChatGPT의 말:

다음은 Backup & Recovery 장애 대응 시나리오 기반 문제 10문항입니다.
모든 문항은 실무 환경에서 발생 가능한 장애, 설정 실수, 복구 지연, RPO/RTO 충돌, 설계 미비점 등을 반영한 TA 직무역량 평가 수준으로 구성되어 있습니다.

📘 장애 대응 시나리오 기반 문제집 (10문항)

✅ 문제 1.

문제: Azure VM 백업을 Recovery Services Vault로 구성했으나, 최근 2일간 백업이 실패하고 있다. 백업 정책은 정상이며, 에이전트 오류는 없다. 가장 먼저 확인해야 할 항목은?

A. NSG 인바운드 포트 설정
B. 백업 Vault의 보존 정책
C. 스토리지 계정 접근 키
D. Managed Identity 권한
E. VM 이름 변경 여부

정답: D
해설:
백업 작업은 Managed Identity를 통해 Vault에 접근하므로, 권한 변경 시 백업 실패 가능.

✅ 문제 2.

문제: AKS 클러스터의 PVC를 백업 중 장애가 발생했다. CSI VolumeSnapshot은 생성되었지만 스냅샷 복원이 실패하고 있다. 가능한 원인은?

A. StorageClass의 reclaimPolicy가 Delete로 설정됨
B. PV가 ReadOnlyMany 타입
C. SnapshotController 미설치
D. PVC Label 누락
E. CSI Driver 업데이트 누락

정답: C
해설:
VolumeSnapshot 기능은 SnapshotController가 클러스터 내에 설치되어야 작동한다.

✅ 문제 3.

문제: 온프레미스 파일 서버에 MARS Agent를 설치해 Vault 백업을 구성했으나, 특정 폴더가 백업되지 않는다. 가장 가능성 높은 원인은?

A. NTFS 파일 권한 오류
B. Azure VPN 게이트웨이 오류
C. 스케줄 충돌
D. 백업 Vault가 GRS로 설정됨
E. 백업 로그가 삭제됨

정답: A
해설:
Agent는 로컬 시스템 권한으로 접근하며, 권한 없는 파일은 건너뛴다.

✅ 문제 4.

문제: RTO 30분, RPO 5분인 업무 시스템에 Azure Backup을 구성했으나, 실 장애 시 복구까지 2시간이 소요되었다. 가장 적절한 조치는?

A. Azure File Sync로 보완
B. 백업 보존 기간 확대
C. Snapshot 주기 단축
D. BCDR 시나리오 수정 및 DR Runbook 구성
E. Azure SQL Auto Backup 활성화

정답: D
해설:
복구 시간 초과는 BCDR 계획과 Runbook 설계가 부실하다는 의미. 설계 재검토가 필요.

✅ 문제 5.

문제: 백업 대상인 Azure File Share가 사용자가 실수로 삭제되었고 Soft Delete 기능이 비활성화 상태였다. 복구 가능한 방법은?

A. Vault 복원
B. Blob Lifecycle 정책 사용
C. Snapshot 복원
D. 복구 불가
E. Storage Account Rollback

정답: D
해설:
Soft Delete가 비활성화된 상태에서는 실수로 삭제된 데이터 복구가 불가능하다.

✅ 문제 6.

문제: Azure Backup Center에서 특정 VM의 복원 시, "Unregistered VM"이라는 오류 메시지가 발생한다. 이 때 가능한 조치는?

A. Vault 재등록
B. VM과 Vault의 지역 재설정
C. 백업 정책 재생성
D. PowerShell 기반 복구
E. Azure CLI로 복구 이력 조회

정답: D
해설:
삭제된 VM에 대해 복구 시, 포털이 인식 못하는 경우 PowerShell 기반 복구가 필요하다.

✅ 문제 7.

문제: SAP HANA가 설치된 Azure VM에서 백업이 지속 실패하고 있다. 가능한 원인은?

A. SUSE가 아닌 Windows 기반
B. Blob 접근 정책 미설정
C. Vault 보존 정책 설정 미흡
D. MARS Agent 설치 오류
E. Network Watcher 비활성화

정답: A
해설:
SAP HANA 백업은 RedHat/SUSE 기반의 VM에서만 지원된다. OS 호환 필수.

✅ 문제 8.

문제: AKS의 PVC 데이터를 복구하였으나, Pod가 PVC를 읽지 못하는 오류가 발생했다. 가장 가능성 높은 원인은?

A. StorageClass가 변경됨
B. PVC에 RWX 타입이 누락됨
C. Snapshot 복구 후 PVC 이름 충돌
D. CSI Plugin이 중복 설치됨
E. Pod의 ServiceAccount 권한 누락

정답: C
해설:
복구 후 PVC 이름이 기존과 충돌하거나 변경되면 Pod에서 자동 연결 실패가 발생할 수 있다.

✅ 문제 9.

문제: Azure Blob에 대한 백업 보호 정책을 구성하려고 한다. 가장 적절한 조합은?

A. Immutable + Snapshot
B. Vault + MARS Agent
C. Azure SQL 백업 적용
D. Soft Delete + MABS
E. NetApp Snapshot

정답: A
해설:
Blob은 Vault로 백업되지 않으므로 Immutable Blob과 Snapshot 설정이 일반적 보호 방식이다.

✅ 문제 10.

문제: 고객사 요구사항으로, RPO 10초, RTO 1분 수준의 백업 복구 구성을 요구하고 있다. Azure Backup의 한계로 적합하지 않은 경우 대안은?

A. Azure Site Recovery
B. Azure Backup Center
C. Soft Delete 주기 조정
D. Blob Versioning 주기 설정
E. Azure SQL LTR Backup

정답: A
해설:
초단위 복구는 Azure Site Recovery처럼 재해복구(DR) 설계 기반 서비스로 대응해야 한다.

필요 시 아래 추가 자료도 제공 가능합니다:

📄 Word/PDF 버전
📊 정답 숨김 연습용
🧠 암기카드 요약
🗂️ 서비스별 장애 대응 매트릭스 도식

원하시면 출력 형식 알려주세요!

나의 말:

암기카드 요약

ChatGPT의 말:

다음은 Backup & Recovery 장애 대응 시나리오 대비용 암기카드 요약본입니다.
TA 직무역량 시험 및 실무 오픈북 블로그용으로 구성하였습니다.

📘 암기카드 요약 (한 줄 핵심 위주)

키워드요약 설명

Managed Identity 권한 오류	백업 실패 시 가장 빈번한 원인, Vault 접근에 사용
SnapshotController 누락	AKS VolumeSnapshot 기능 오류 발생
NTFS 권한 문제	MARS Agent가 특정 폴더 건너뛰는 원인
RTO 초과 시 대응	DR Runbook 설계 및 BCDR 프로세스 보완 필요
Soft Delete 비활성화	Azure File 삭제 시 복구 불가 상태
PowerShell 복구	Unregistered VM 등 포털 복구 오류 시 대안
SAP HANA 백업 조건	RedHat/SUSE 기반 VM에서만 가능
PVC 이름 충돌	복구 후 Pod가 PVC 인식 실패할 수 있음
Blob 백업 방식	Vault 미지원, Snapshot + Immutable Blob으로 보호
초단위 RPO/RTO 대응	Azure Site Recovery 사용 (ASR) 필요

🧠 장애 대응 키워드 인덱스 (Ctrl+F 용)

Managed Identity, SnapshotController, NTFS 권한, RTO Runbook, Soft Delete, PowerShell 복구, SAP HANA Backup, PVC 충돌, Blob Snapshot, ASR

📎 활용 팁

시험 시 "복구 실패", "Snapshot 실패", "Vault 복원 안됨" 등의 키워드가 나올 경우 상기 키워드로 빠르게 접근.
실무 대응에서도 장애 Root Cause 파악 시 이 카드 참고.

필요하다면 아래와 같이 변환해드릴 수 있습니다:

📄 Word 또는 PDF 파일
🧪 정답 숨김 연습용 문항
🧩 장애 유형별 대응 전략 도식화
📊 서비스별 백업 지원 Matrix 카드

다음으로 어떤 분야로 확장할까요? (예: DR Runbook, Azure Site Recovery, Hybrid Backup 등)

'Migration & DR > 시스템 이관환경 및 Landing Zone 설계' 카테고리의 다른 글

Azure 랜딩존(Azure Landing Zone) 개념, 문제(클러스터링,스토리지,API Gateway) (0)	2025.07.18
(gpt)On-Premises DB를 Microsoft Azure로 마이그레이션 (0)	2025.07.18

medires 님의 블로그