카테고리 없음

성덕이의 티티티

seongduck 2025. 8. 28. 01:07

Azure RBAC

1. 개요

  • Azure RBAC이란,  Azure 역할 기반 액세스 제어(Role Based Access Controll)의 약자로 Azure 리소스에 대한 액세스를 세밀하게 관리할 수 있는 Azure Resource Manager 기반의 권한 부여 시스템이다.
  •  Azure RBAC 데이터는 고객이 액세스하는 위치에 관계없이 리소스에 적시에 액세스할 수 있도록 하는 글로벌 데이터입니다.

 

2. 구성 및 역할별 권한 

  • 역할 할당은 보안 주체(Security Principle), 역할 정의(Role Definition), 범위(Scope) 3가지 요소로 구성된다. 
요소 설명 예시
Role(역할) 수행 가능한 허용 작업(액션) 집합 Owner, Contributor, Reader, Custom Role 등
Principal(주체) 권한을 부여받는 엔터티 사용자(User), 그룹(Group), 서비스 주체(SP), 관리형 ID
Scope(범위) 권한이 적용되는 Azure 리소스의 계층/구간 구독, 리소스 그룹, VM, Storage Account 등
  • 보안주체 : 엑세스를 요청하는 관리ID로서, 사용자/그룹/서비스 주체/리소스 가 있다.
  • 역할 정의 : 역할 정의는 기존 제공 역할(Built-in)과 사용자 지정 역할(Custom)이 있으며, 역할이 서로 충돌할 경우  더 넓은 권한을 가진 역할이 우선시됩니다. 즉, 사용자에게 할당된 역할 중 가장 광범위한 권한을 가진 역할이 적용된다.  
  • 예를 들어, 사용자에게 Reader 역할과 특정 리소스에 대한 Contributor 역할을 모두 할당했다면, Contributor 권한이 적용된다. 이는 Azure RBAC의 기본 동작이며, 여러 역할 할당 시에도 동일하게 적용된다.
  • 범위 : 관리 그룹> 구독> 리소스 그룹> 리소스 등 4개 수준에서 범위를 지정할 수 있습니다. 범위는 부모-자식 관계로 구조화되어 있으며, 하위 수준은 상위 수준의 역할 권한을 상속합니다
  • 기존 제공되는 관리그룹에 따른 역할과 지원되는 작업 목록입니다. 
  • Azure 역할 이름  만들기 이름 바꾸기 이동** DELETE 액세스 권한 할당 정책 할당 읽기
    Owner(소유자) O O O O O O O
    Contributor (기여자) O O O O     O
    Management Group
    Contributor*    		 O O O O     O
    Reader (읽기 권한자)             O
    Management Group
    Reader*    		             O
    Resource Policy
    Contributor    		           O  
    User Access Administrator
    		         O O  
  • *: 이러한 역할을 통해 사용자는 관리 그룹 범위에서만 지정된 작업을 수행할 수 있습니다.
    **: 구독 또는 관리 그룹을 이동하기 위해 루트 관리 그룹에 대한 역할을 할당할 필요가 없습니다.

3. 최소 권한의 법칙 (Principle of Least Privilege)

  • 정의 : 사용자에게 필요한 작업 수행에 필요한 최소 권한만 부여하여, 혹시 모를 권한 오용이나 보안 침해 사고 발생 시 피해 범위를 최소화하는 원칙입니다.
  • 예시 : 가상 머신을 관리하는 팀원에게는 가상 머신 관리자 역할을, 데이터베이스를 관리하는 팀원에게는 데이터베이스 관리자 역할을 부여하여 각 팀원이 자신의 업무에 필요한 권한만 갖도록 하는 것입니다
  • 최소 권한의 법칙을 지키면서, 필요한 경우 가장 광범위한 역할 적용 방식을 활용하여 사용자의 효율성을 높일 수 있습니다. 예를 들어, 특정 사용자에게 여러 리소스 그룹에 대한 관리자 권한이 필요하다면, 관리 그룹 차원에서 관리자 역할을 할당하여 각 리소스 그룹마다 역할을 개별적으로 할당하는 것보다 더 효율적으로 관리할 수 있습니다. 
  • 또한 역할 할당 시 Scope를 좁힐수록 보안상 안전

4. 상위 권한 우선 적용 원칙

  • Built-in 역할과 사용자 지정 역할이 충돌하는 경우, 더 넓은 권한을 가진 역할이 우선 적용됩니다. 즉  더 높은 범위의 역할 할당이 이미 액세스 권한을 부여하므로 하위 범위에서 중복 역할을 포함합니다.
  • 예를 들어, Custom 역할에 'Microsoft.Compute/virtualMachines/write' 권한과 'Microsoft.Storage/storageAccounts/write' 권한이 모두 포함되어 있고, Built-in 역할에는 'Microsoft.Compute/virtualMachines/write' 권한만 포함되어 있다면, Custom 역할이 우선 적용됩니다. 반대로, Built-in 역할에 'Microsoft.Compute/*' 와 같이 더 넓은 범위의 권한이 정의되어 있다면 Built-in 역할이 우선 적용됩니다.

 

5. 거부 할당 정책 우선 적용

  • ‘거부 할당’은 역할 할당과 마찬가지로 액세스를 거부하기 위해 특정 범위에서 사용자, 그룹 또는 서비스 주체에게 거부 작업 세트를 연결합니다. 
  • 거부 할당은 역할 할당이 사용자에게 액세스 권한을 부여하더라도 특정 Azure 리소스 작업을 사용자가 수행할 수 없도록 차단합니다.(Allow 정책보다 우선 적용)

6. 참고 문서

 

Azure Storage (account)서비스 및 Blob Storage tier 정보

1. 개요

  • Azure Storage 란, 최신 데이터 스토리지 시나리오를 위한 Microsoft의 클라우드 스토리지 서비스입니다.

 

2. Azure Storage 이점

  • 내구성 및 고가용성. 중복성은 일시적인 하드웨어 오류 발생 시 데이터를 안전하게 보호합니다. 또한 로컬 재해 또는 자연 재해로 인한 장애를 방지할 수 있도록 데이터 센터 또는 지리적 영역에서 데이터를 복제하도록 선택할 수도 있습니다. 이러한 방식으로 복제된 데이터는 예기치 않은 중단이 발생할 경우 항상 사용 가능한 상태로 유지됩니다.
  • 보안. Azure Storage 계정에 기록된 모든 데이터는 서비스에 의해 암호화됩니다. Azure Storage는 데이터에 액세스할 수 있는 사용자를 자세히 제어할 수 있습니다.
  • 확장 가능. Azure Storage는 오늘날의 애플리케이션에 대한 데이터 저장소 및 성능 요구 사항을 충족하기 위해 대규모로 확장할 수 있도록 설계되었습니다.
  • 관리형 서비스. 하드웨어 유지 관리, 업데이트 및 중요한 문제를 Azure에서 처리합니다.
  • 접근 용이성. Azure Storage의 데이터는 HTTP 또는 HTTPS를 통해 전 세계 어디에서든 액세스할 수 있습니다. Microsoft는 완성도 높은 REST API뿐만 아니라 .NET, Java, Node.js, Python, Go 등 기타 다양한 언어로 Azure Storage용 클라이언트 라이브러리를 제공합니다. Azure Storage는 Azure PowerShell 또는 Azure CLI에서 스크립트를 지원합니다. 또한 Azure Portal 및 Azure Storage Explorer는 데이터 작업을 위한 쉬운 시각적 솔루션을 제공합니다.

 

3. Azure Storage 종류 및 특징

기능 설명 사용하는 경우
Azure Files 산업 표준 SMB(서버 메시지 블록) 프로토콜, NFS(네트워크 파일 시스템) 프로토콜 및 Azure Files REST API를 통해 어디에서든지 액세스할 수 있는 완전 관리형 클라우드 파일 공유를 제공합니다.
Azure 파일 공유를 Windows, Linux 및 macOS의 클라우드 또는 온-프레미스 배포에 동시에 탑재할 수 있습니다.		 - 이미 기본 파일 시스템 API를 사용하는 클라우드로 애플리케이션을 “리프트 앤 시프트”하여 Azure에서 실행 중인 다른 애플리케이션과 해당 애플리케이션 간에 데이터를 공유하려는 경우
- 온-프레미스 파일 서버 또는 NAS 장치를 바꾸거나 추가할 경우
- 여러 가상 머신에서 액세스해야 하는 개발 및 디버깅 도구를 저장할 경우.
Azure NetApp Files 고급 데이터 관리 기능을 필요로 하는 가장 까다로운 고성능의 대기 시간이 짧은 워크로드를 처리할 수 있는 완전 관리형의 고가용성, 엔터프라이즈급 NAS 서비스를 제공합니다. - POSIX 규격 Linux 및 Windows 애플리케이션, SAP HANA, 데이터베이스, HPC(고성능 컴퓨팅) 인프라 및 앱, 엔터프라이즈 웹 애플리케이션과 같이 마이그레이션하기 어려운 워크로드 배포
- 단일 서비스에서 NFSv3, NFSv4.1 및 SMB3.1.x를 비롯한 여러 파일 스토리지 프로토콜에 대한 지원이 필요하므로 코드 변경 없이 다양한 애플리케이션 리프트 앤 시프트 시나리오 사용
- 온프레미스 NetApp, AKS CSI와 연계가 가능하며, Window,Linux 모두 지원 가능
Azure Blob 구조화되지 않은 데이터를 블록 Blob에서 대규모로 저장 및 액세스할 수 있도록 합니다.(텍스트 및 이진 데이터에 대한 확장성이 뛰어난 개체 저장소)
또한 엔터프라이즈 빅 데이터 분석 솔루션을 위한 Azure Data Lake Storage도 지원합니다.		 - 애플리케이션에서 스트리밍 및 임의 액세스 시나리오를 지원
- 어디에서든 애플리케이션 데이터에 액세스 가능(글로벌 서비스)
- Azure에서 엔터프라이즈 Data Lake를 빌드하고 빅 데이터 분석을 수행 가능
Azure Elastic SAN Azure Elastic SAN은 SAN 배포, 스케일링, 관리 및 구성을 간소화하는 동시에 고가용성과 같은 기본 클라우드 기능을 제공하는 완전히 통합된 솔루션입니다. - iSCSI(internet Small Computer Systems Interface) 프로토콜을 통해 액세스하는 여러 유형의 컴퓨팅 리소스(예: SQL, MariaDB, Azure 가상 머신 및 Azure Kubernetes Services)와 상호 운용 가능한 대규모 스토리지로 사용 가능
Azure (Managed) 디스크 연결된 가상 하드 디스크에서 데이터를 영구적으로 저장 및 액세스할 수 있습니다.( Azure VM용 블록 수준 스토리지 볼륨 ) - 기본 파일 시스템 API를 사용하는 응용 프로그램을 데이터를 영구 디스크에 읽고 쓰도록 전환시
- 가상 머신 외부에서 액세스할 필요가 없는 데이터를 디스크가 연결된 컴퓨터에 저장 가능
Azure 컨테이너 스토리지 Azure Container Storage는 Kubernetes와 통합되고 컨테이너용으로 기본적으로 빌드되는 볼륨 관리, 배포 및 오케스트레이션 서비스입니다. - Kubernetes 클러스터에서 실행되는 상태 저장 애플리케이션의 데이터를 저장하기 위해 영구 볼륨을 동적으로 자동으로 프로비전하려고 합니다.
Azure 큐 응용 프로그램 구성 요소 간의 비동기 메시지 큐를 허용합니다.
Azure에서는 Storage 큐 및 Service Bus 큐의 두 가지 큐 유형을 지원
 - 응용 프로그램 구성 요소를 분리하고 비동기 메시징을 사용하여 서로 통신 가능
- Storage 큐는 Azure Storage 인프라의 일부로 수많은 메시지를 저장합니다. 전 세계 어디서나 인증된 호출을 통해 HTTP 또는 HTTPS를 사용하여 메시지에 액세스할 수 있으며, 큐 메시지의 크기는 최대 64KB입니다. 비동기적으로 처리할 작업의 백로그를 만드는 데 일반적으로 사용
- Service Bus 큐는 더 폭넓은 Azure 메시징 인프라의 일부이며, 큐뿐 아니라 게시/구독과 여러 고급 통합 패턴도 지원
Azure 테이블 클라우드에 구조화된 NoSQL 데이터를 저장하는 서비스로, 스키마 없이 디자인된 키/특성 저장소를 제공합니다. - 웹 응용 프로그램의 사용자 데이터, 주소록, 장치 정보 및 서비스에 필요한 다른 유형의 메타데이터를 비롯한 유연한 데이터 집합을 저장 가능
Azure 관리형 Lustre HPC(고성능 컴퓨팅) 및 AI 워크로드를 위한 완전 관리형 종량제 파일 시스템을 제공합니다. 작업을 간소화하고, 설치 비용을 절감하고, 복잡한 유지 관리를 제거하도록 설계되었습니다. - 높은 처리량과 짧은 대기 시간이 필요한 HPC 워크로드를 실행하며, 초고성능 대역폭, 병렬 I/O 최적화
- 기본 인프라를 관리할 필요 없이 클라우드에서 Lustre 워크로드를 실행하는 완전 관리
- Azure Blob과 연계 (데이터 tiering)가 가능하며, Linux 중심(Window 불가)

 

 

4. Blob 데이터를 위한 엑세스 계층

  1. 4-1. 핫 액세스 계층 (Hot Access Tier):
    • 장점: 가장 높은 성능을 제공하며, 자주 액세스하는 데이터에 적합합니다. 데이터 읽기/쓰기 속도가 빠르고 지연 시간이 낮습니다.
    • 단점: 다른 계층에 비해 저장 비용이 높습니다.
    • CRUD 작업: 모든 CRUD 작업이 빠르고 효율적으로 수행됩니다.
    • 사용 사례: 자주 사용되는 파일, 이미지, 로그 데이터 등에 적합합니다.
  2. 4-2. 쿨 액세스 계층 (Cool Access Tier):
    • 장점: 핫 계층보다 저렴한 저장 비용을 제공하며, 덜 자주 액세스하는 데이터에 적합합니다.
    • 단점: 핫 계층보다 데이터 읽기/쓰기 속도가 느리고 지연 시간이 길 수 있습니다. 또한 최소 30일 동안 저장해야 합니다.
    • CRUD 작업: 핫 계층보다 속도가 느릴 수 있지만, 대부분의 CRUD 작업이 여전히 가능합니다.
    • 사용 사례: 백업 데이터, 재해 복구 데이터 등에 적합합니다.
  3. 4-3. 콜드 액세스 계층 (Cold Access Tier):
    • 장점: 쿨 계층보다 더 저렴한 저장 비용을 제공하며, 드물게 액세스하는 데이터에 적합합니다.
    • 단점: 데이터 읽기/쓰기 속도가 느리고 지연 시간이 매우 길 수 있습니다. 복원 작업이 필요할 수 있습니다. 또한 최소 90일 동안 저장해야 합니다.
    • CRUD 작업: 데이터 읽기/쓰기 속도가 매우 느리므로, 데이터 복원 작업이 필요할 수 있습니다.
    • 사용 사례: 보관 데이터, 규정 준수 데이터 등에 적합합니다.
  4. 44-4. 보관 액세스 계층 (Archive Access Tier):
    • 장점: 가장 저렴한 저장 비용을 제공하며, 장기간 보관해야 하는 데이터에 적합합니다.
    • 단점: 데이터 읽기/쓰기 속도가 가장 느리고 지연 시간이 가장 깁니다. 데이터 복원 작업이 필요하며, 복원 시간이 몇 시간 이상 걸릴 수 있습니다. 또한 최소 180일 동안 저장해야 합니다.
    • CRUD 작업: 데이터 읽기/쓰기 속도가 매우 느리므로, 데이터 복원 작업이 필요합니다.
    • 사용 사례: 장기 보관 데이터, 규제 준수 데이터 등에 적합합니다. 

5. Blob의 엑세스 계층 설정 및 유의사항

  • 액세스 계층은 언제든지 변경 가능하며, 필요에 따라 핫, 쿨, 콜드 계층 간에는 즉시 전환할 수 있습니다. 다만, 계층에 필요한 최소 일수가 경과하기 전에 Blob을 삭제하거나, 덮어쓰거나, 다른 계층으로 이동하면 조기 삭제 위약금이 부과됩니다.
  • LRS, GRS 또는 RA-GRS에 대해 구성된 스토리지 계정만 보관 계층으로 Blob 이동을 지원합니다. 보관 계층은 ZRS, GZRS 또는 RA-GZRS 계정에 대해 지원되지 않습니다.
  • 스토리지 계정에 대한 기본 온라인 액세스 계층을 설정합니다. 개별 Blob에 대한 설정을 명시적으로 다시 지정하지 않는 한, 계정의 Blob은 이 액세스 계층을 상속합니다.
  • 업로드 시 Blob의 계층을 명시적으로 설정하여. 핫, 쿨, 콜드 또는 보관 계층으로 Blob을 만들 수 있습니다.
  • Blob 계층 설정 작업을 통해 기존 Blob의 계층을 변경합니다. 일반적으로 이 작업은 더 핫한 계층에서 더 쿨한 계층으로 이동하는 데 사용합니다.
  • Blob 복사 작업을 통해 Blob을 복사합니다. 일반적으로 이 작업은 더 쿨한 계층에서 더 핫한 계층으로 이동하는 데 사용합니다.
  • 새 범용 v2 스토리지 계정에 대한 기본 액세스 계층은 기본적으로 핫 계층으로 설정됩니다. 스토리지 계정을 만들 때나 만든 후에 기본 액세스 계층 설정을 변경할 수 있습니다.
  • 레거시 Blob Storage 계정을 만드는 경우 스토리지 계정을 만들 때 기본 액세스 계층 설정을 핫 또는 쿨로 지정해야 합니다. 스토리지 계정이 만들어지면 해당 계정에 대한 기본 액세스 계층 설정을 변경할 수 있습니다.
  • 보관 계층의 Blob이 포함된 스토리지 계정에 대한 중복 구성을 변경하려면 먼저 보관된 모든 Blob을 핫, 쿨 또는 콜드 계층으로 다시 리하이드레이션해야 합니다. 리하이드레이션 작업에는 많은 비용과 시간이 소요될 수 있으므로 가능하면 보관된 Blob이 포함된 스토리지 계정에 대한 중복 구성을 변경하지 않는 것이 좋습니다.
  • 계정이 LRS에 대해 구성되어 있는 동안 보관 계층으로 이동된 Blob이 없는 한 LRS에서 GRS로의 스토리지 계정 마이그레이션이 지원됩니다. 계정이 LRS가 된 시점으로부터 14일 이내에 업데이트를 수행하고 계정이 LRS로 설정된 동안 Blob이 보관 계층으로 이동되지 않은 경우 계정을 GRS로 다시 이동할 수 있습니다.
  • 수명 주기 관리 정책을 사용하여 보관된 Blob을 온라인 계층으로 리하이드레이션할 수 없습니다. 프리미엄 블록 Blob 스토리지 계정에 저장된 데이터는 Blob 계층 설정 또는 Azure Blob Storage 수명 주기 관리를 사용하여 핫, 쿨, 콜드 또는 보관으로 계층화할 수 없습니다. 데이터를 이동하려면 URL API에서 블록 배치 또는 이 API를 지원하는 AzCopy 버전을 사용하여 블록 Blob 스토리지 계정에서 다른 계정의 핫 계층으로 Blob을 동기식으로 복사해야 합니다. URL에서 블록 배치 API는 서버에서 데이터를 동기적으로 복사합니다. 이는 모든 데이터를 원래 서버 위치에서 대상 위치로 이동하면 호출이 완료된다는 의미입니다.

6. 스토리지 구성시 복제 전략(중복도)

  • Azure 스토리지 계정에서 데이터를 보호하기 위한 저장 옵션은 LRS, GRS, ZRS, GZRS 총 4가지가 있습니다. 각각의 특징과 적용되는 스토리지 및 지역, 기타 내용을 자세히 설명하면 다음과 같습니다.
 LRS (로컬 중복 스토리지):
 
  • 특징: 기본 지역 내 단일 데이터 센터에서 데이터를 세 번 동기적으로 복제합니다. 가장 저렴한 옵션이지만, 단일 데이터 센터 장애 시 데이터 손실 위험이 있습니다. 서버 랙 및 드라이브 오류에 대한 기본 보호 기능이 포함된 최저 비용 옵션이며, 중요하지 않은 시나리오에 권장됩니다.
  • 적용 스토리지: 범용 v2, Blob Storage, File Storage, Queue Storage, Table Storage
  • 적용 지역: 모든 Azure 지역
  • 기타: 데이터 손실 위험을 감수할 수 있는 경우, 비용 효율적인 옵션입니다. 
     
2. GRS (지역 중복 스토리지):
 
  • 특징: 기본 지역과 쌍을 이루는 보조 지역에 데이터를 동기적으로 세 번 복제합니다. 기본 지역과 보조 지역 모두 단일 데이터 센터 장애 시 데이터 손실 위험이 있습니다. 백업 시나리오에 권장됩니다.
  • 적용 스토리지: 범용 v2, Blob Storage
  • 적용 지역: 쌍을 이루는 보조 지역 (예: 동아시아와/동아시아2)
  • 기타: 기본 지역 장애 시 보조 지역으로 자동 장애 조치(failover)됩니다. 보조 지역은 읽기 전용으로 접근 가능합니다.
     
3. ZRS (영역 중복 스토리지):
 
  • 특징: 기본 지역 내 3개의 가용성 영역에 데이터를 동기적으로 복제합니다. 가용성 영역은 물리적으로 격리되어 있어, 한 영역의 장애가 다른 영역에 영향을 주지 않습니다. 데이터 센터 수준 오류에 대한 보호 기능이 있는 중간 옵션입니다. 따라서 LRS보다 높은 내구성을 제공합니다. 
  • 적용 스토리지: 범용 v2, Blob Storage, File Storage
  • 적용 지역: 특정 Azure 지역 (예: 미국 동부, 미국 서부)
  • 기타: 낮은 지연 시간과 높은 가용성이 필요한 경우 적합합니다.
     
4. GZRS (지역 영역 중복 스토리지):
 
  • 특징: 기본 지역의 3개 가용성 영역과 보조 지역에 데이터를 동기적으로 복제합니다. 기본 지역과 보조 지역 모두 장애 발생 시에도 데이터 손실 위험이 낮습니다. GRS와 ZRS의 제품이 모두 포함된 최적의 데이터 보호 솔루션입니다.
  • 적용 스토리지: 범용 v2, Blob Storage
  • 적용 지역: 특정 Azure 지역 (예: 미국 동부, 미국 서부)
  • 기타: 높은 수준의 내구성과 가용성을 요구하는 경우 적합합니다.

 

7. Storage Account 핵심

  • Storage Account 생성시 표준 스토리지는 Blob 및 Azure file 등 사용가능
  • 프리미엄은 전용으로만 사용가능
  • 프리미엄은 LRS, ZRS 만지원되고 표준은 다됨
  • NFS 은 프리미엄으로만 사용 가능
  • 백업 정책 중 유의사항은 Azure Files는 RA-GRS(읽기 액세스 지역 중복 스토리지) 또는 RA-GZRS(읽기 액세스 지역 영역 중복 스토리지)를 지원하지 않습니다.
  • GRS 또는 GZRS를 활용하는 경우 보조 지역으로 장애 조치(failover)가 이루어지지 않는 한 보조 지역의 데이터에 읽기 또는 쓰기 권한을 할 수 없습니다. 보조 지역에 대한 읽기 액세스의 경우 RA-GRS(읽기 액세스 지역 영역 중복 스토리지) 또는 RA-GZRS(읽기 액세스 지역 영역 중복 스토리지)를 사용하도록 스토리지 계정을 구성합니다

8. 참고 문서

 

Azure Blob Storage Life Cycle 관리

1. 개요 

  • Azure Blob Storage를 사용하면 데이터 볼륨이 증가하고 사용 패턴이 진화하는 경우에도 조직에서 데이터 스토리지 요구 사항을 효율적으로 관리하고 크기를 조정할 수 있습니다. Blob 수명 주기 관리를 사용하면 고객은 데이터를 쿨 계층으로 자동 전환하거나 더 이상 필요하지 않은 경우 만료하는 규칙 기반 정책을 구현하여 비용을 사전에 최적화할 수 있습니다.

2. 관리 정책 작업 범위

  • Blob의 현재 버전, Blob의 이전 버전 또는 Blob 스냅샷이 일정 기간 동안 액세스 또는 수정되지 않는 경우, 이러한 개체를 더 쿨한 저장소 계층으로 전환하여 비용을 최적화합니다.
  • Blob에 액세스할 때 즉시 쿨에서 핫으로 다시 전환합니다.
  • Blob의 현재 버전, Blob의 이전 버전 또는 수명 주기가 끝나면 Blob 스냅샷을 삭제합니다.
  • 필터로 이름 접두사 또는 블롭 인덱스 태그를 사용하여 전체 스토리지 계정, 선택된 컨테이너, 또는 블롭 하위 집합에 규칙을 적용합니다.

3. 관리 정책 특징

  • 수명 주기 관리 정책은 범용 v2, 프리미엄 블록 Blob 및 Blob Storage 계정의 블록 Blob 및 추가 Blob에 대해 지원됩니다.
  • 수명 주기 관리는 $logs 및 $web 컨테이너와 같은 시스템 컨테이너에 영향을 주지 않습니다.
  • 프리미엄 블록 Blob 스토리지 계정에서는 계층화가 아직 지원되지 않습니다. 다른 모든 계정의 경우 계층화는 블록 Blob에서만 허용되며 추가 및 페이지 Blob에는 허용되지 않습니다.
  • 수명 주기 관리 정책은 전체적으로 읽거나 써야 합니다. 부분 업데이트는 지원되지 않습니다.
  • 각 규칙에는 최대 10개의 대/소문자 구분 접두사 및 최대 10개의 Blob 인덱스 태그 조건이 있을 수 있습니다.
  • 수명 주기 관리 정책을 사용하여 암호화 범위를 사용하는 Blob의 계층을 보관 계층으로 변경할 수 없습니다.
  • 수명 주기 관리 정책의 삭제 작업은 변경할 수 없는 컨테이너의 모든 Blob에서 작동하지 않습니다. 변경할 수 없는 정책을 사용하면 개체를 만들고 읽을 수 있지만 수정하거나 삭제할 수는 없습니다. 
  • 수명 주기 관리는 시스템 컨테이너(예: $logs$web containers)에 영향을 주지 않습니다.

4. 이벤트 구성(여건/활동/필터) 및 구성별 설명

  • 이벤트 구성
    규칙 요소 설명
    Conditions(여건) 조건은 만들기 시간, 마지막으로 수정한 시간 및 마지막으로 액세스한 시간(액세스 시간 추적을 사용하는 경우)의 세 가지 Blob 속성을 기반으로 합니다.
    Actions(활동) 작업은 연결된 조건을 충족하는 필터링된 Blob에 적용됩니다. Blob 계층을 쿨 계층으로 변경하거나 Blob을 삭제하는 등 규칙당 하나 이상의 작업을 정의해야 합니다.
    Filters(필터) 필터는 경로 접두사 및 Blob 태그를 사용하여 스토리지 계정 내의 Blob 하위 집합으로 규칙 작업을 제한합니다. 필터가 두 개 이상 정의된 경우 논리 AND는 모든 필터에서 실행됩니다. 필터를 사용하여 포함할 Blob을 지정할 수 있습니다. 필터는 제외할 Blob을 지정할 방법을 제공하지 않습니다.
  • 활동 조건 유형
    Condition Type 설명
    daysAfterModificationGreaterThan Integer 마지막으로 수정한 시간 Blob 이후의 기간(일)입니다. Blob의 현재 버전에 대한 작업에 적용됩니다.
    daysAfterCreationGreaterThan Integer 생성 시간 이후의 기간(일)입니다. Blob의 현재 버전, 이전 버전의 Blob 또는 Blob 스냅샷에 대한 작업에 적용됩니다.
    daysAfterLastAccessTimeGreaterThan Integer 마지막 액세스 시간 이후 또는 경우에 따라 정책을 사용하도록 설정된 날짜 이후의 기간(일)입니다. 액세스 추적을 사용하도록 설정된 경우 Blob의 현재 버전에 대한 작업에 적용됩니다.
    daysAfterLastTierChangeGreaterThan Integer 마지막 Blob 계층 변경 시간 이후의 기간(일)입니다. 보관 계층으로 반환되기 전에 리하이드레이션된 Blob이 핫, 쿨 또는 콜드 계층에 보관되는 최소 기간(일)입니다. tierToArchive 작업에만 적용됩니다.
  • Action 상세 설명
    활동 설명
    TierToCool - Blob을 쿨 액세스 계층으로 설정합니다.
    - 추가 블롭, 페이지 블롭 또는 프리미엄 블록 블롭 저장소 계정의 블롭에서는 지원되지 않습니다.
    TierToCold - Blob을 콜드 액세스 계층에 설정합니다.
    - 추가 블롭, 페이지 블롭 또는 프리미엄 블록 블롭 저장소 계정의 블롭에서는 지원되지 않습니다.
    TierToArchive - 보관 액세스 계층에 Blob을 설정합니다.
    - Blob을 다시 하이드레이션해도 Blob의 마지막으로 수정된 또는 마지막 액세스 시간 속성이 업데이트되지 않습니다. 따라서 이 작업은 리하이딩된 Blob을 보관 계층으로 다시 이동할 수 있습니다. 이러한 상황이 발생하지 않도록 하려면 이 작업에 조건을 추가 daysAfterLastTierChangeGreaterThan 합니다.
    - 이 작업은 추가 블롭, 페이지 블롭 또는 프리미엄 블록 Blob 저장소 계정에 있는 블롭에서 지원되지 않습니다. 또한 암호화 범위를 사용하는 Blob이나 영역 중복 스토리지(ZRS), 지역 영역 중복 스토리지(GZRS) / 읽기 액세스 지역 영역 중복 스토리지(RA-GZRS)에 대해 구성된 계정의 Blob에서는 지원되지 않습니다.
    enableAutoTierToHotFromCool
    (쿨에서 핫으로 자동 계층화 활성화)    		 - Blob이 쿨 계층으로 설정된 경우 이 작업은 Blob에 액세스할 때 해당 Blob을 핫 계층으로 자동으로 이동합니다.
    - 이 작업은 daysAfterLastAccessTimeGreaterThan 실행 조건과 함께 사용할 때만 사용할 수 있습니다.
    - 이 작업은 규칙에서 이 작업을 사용하도록 설정하기 전에 쿨 계층으로 설정된 Blob에는 영향을 주지 않습니다.
    - 이 작업은 Blob을 30일마다 쿨에서 핫으로 한 번만 이동합니다. 이 보호 조치는 계정에 청구되는 여러 초기 삭제 처벌로부터 보호하기 위해 시행됩니다.
    - 이전 버전 또는 스냅샷에서는 지원되지 않습니다.
    Delete - Blob을 삭제합니다.
    - 변경할 수 없는 컨테이너에 있는 페이지 Blob 또는 Blob은 지원되지 않습니다.
  • 필터 파라미터 유형
필터 유형 설명 필수
blobTypes 미리 정의된 열거형 값의 배열 Blob의 형식( blockblob 또는 appendBlob) O
prefixMatch 문자열 배열 이러한 문자열은 일치시킬 접두사입니다. X
blobIndexMatch 사전 값의 배열 이러한 값은 일치시킬 Blob 인덱스 태그 키 및 값 조건으로 구성 X

 

5. 비용 최적화를 위한 설정

  • 이벤트, 메트릭 및 로그를 사용하여 실행되는 Azure Blob Storage 수명 주기 관리 정책을 모니터링할 수 있는데, 수명 주기 관리 실행이 완료되면 알림을 받도록 설정한다. 즉  이벤트가 트리거될 때 Event Grid 서비스는 해당 이벤트에 대한 데이터를 구독 엔드포인트로 보내어 비용 최적화 설정을 수행한다.
  • Blob Storage 관련 이벤트
    이벤트 이름 설명
    Microsoft.Storage.BlobCreated - Blob 생성 또는 교체 시 트리거됩니다.
    - 특히 이 이벤트는 클라이언트가 Blob REST API에서 사용할 수 있는 PutBlob, PutBlockList 또는 CopyBlob 작업을 사용할 때, 그리고 블록 Blob이 완전히 커밋될 때 트리거됩니다.
    - CopyBlob 기능이 사용되는 계정에서 클라이언트가 작업을 사용하는 경우, CopyBlob 작업은 약간 다르게 작동합니다. 이 경우 Microsoft.Storage.BlobCreated 이벤트는 블록 Blob이 완전히 커밋될 때가 아니라 CopyBlob 작업이 시작될 때 트리거됩니다.
    Microsoft.Storage.BlobDeleted - Blob 삭제 시 트리거됩니다.
    - 특히 해당 이벤트는 클라이언트가 DeleteBlob Blob REST API에서 사용할 수 있는 작업을 호출하는 경우 트리거됩니다.
    Microsoft.Storage.Blob Tier 변경됨 - Blob 액세스 계층이 변경될 때 트리거됩니다. 특히 클라이언트가 Blob REST API에서 사용할 수 있는 Set Blob Tier 작업을 호출하면 이 이벤트는 계층 변경이 완료된 후에 트리거됩니다.
    Microsoft.Storage.AsyncOperationInitiated - 보관에서 핫 또는 쿨 계층으로 데이터를 이동하거나 복사하는 작업이 시작될 때 트리거됩니다. 특히 이 이벤트는 클라이언트가 Set Blob Tier API를 호출하여 보관 계층의 Blob을 핫 또는 쿨 계층으로 이동하는 경우 또는 클라이언트가 Copy Blob API를 호출하여 보관 계층의 Blob에서 핫 또는 쿨 계층의 Blob으로 데이터를 복사하는 경우 트리거됩니다.

6. Azure Event Driven 정리

  • Azure에서 말하는 이벤트 기반(Event-Driven) 아키텍처는 특정 상태 변화(이벤트)가 발생했을 때 이를 트리거(trigger)로 하여 서비스나 애플리케이션이 동작하는 구조를 의미
서비스
역할
자주 쓰이는 패턴
전달 방식
보관·재생
결론
Event Grid
Azure/앱에서 발생한 이벤트(상태 변화)를 구독자에게 푸시
Blob 업로드 알림→함수 트리거, 리소스 생성/태깅 자동화, IoT MQTT Pub/Sub
푸시형 Pub/Sub (HTTP & MQTT 브로커)
이벤트 자체 보관 X(짧은 재시도/Dead-letter), 스트림 재생 X
“무언가 발생했다”에 빠르게 반응하는 오케스트레이션에 최적.
Event Hubs
디바이스/앱/로그의 연속 스트림을 대량 수집
테레메트리/클릭스트림/로그→(Spark/ADX/ASA) 실시간 처리
풀형 스트림(소비자가 오프셋 관리, 파티션/컨슈머 그룹)
보존(시간/용량) + 재생 가능(리플레이)
“많이, 빠르게, 끊임없이 들어오는 데이터”의 빅데이터 파이프라인.
Service Bus
엔터프라이즈 메시징(큐/토픽, 순서/세션/거래/지연/필터)
주문·결제·워크플로, 사내 시스템 간 신뢰 전송
브로커 저장 후 소비자 준비되면 전달
DLQ/중복감지/세션/FIFO로 신뢰성↑
“유실·중복·순서에 민감한 업무 메시지”에 적합.

7. 참고 문서

VNet 구성시 Inbound/Outbound 구성방법 및 네트워크 흐름

1. Azure Inbound/Outbound 기본 원리 

  • Azure Vnet에서 Private Instance 구성시에도 Public IP를 부여하거나, 로드밸런서를 이용하여 Inbound 트래픽을 허용
  • Outbound 트래픽은 Azure NAT Gateway를 통해 프라이빗 서브넷의 모든 인스턴스를 제어하여, 완벽한 프라이빗 상태를 유지하도록 기능 
    조건 카테고리 교통 방향 사용된 연결 방법
    인스턴스 수준 공용 IP가 있는 NAT Gateway 및 VM VM(서브넷 1) 인바운드
    아웃바운드    		 인스턴스 수준 공용 IP
    NAT 게이트웨이
    가상 머신 확장 집합(서브넷 1) 인바운드
    아웃바운드    		 NA
    NAT 게이트웨이
    VM(서브넷 2) 인바운드
    아웃바운드    		 NA
    NAT 게이트웨이
    표준 공용 로드밸런서가 있는 NAT Gateway 및 VM

    		 VM 및 가상 머신 확장 집합(서브넷 1) 인바운드
    아웃바운드    		 로드 밸런서
    NAT 게이트웨이
    VM(서브넷 2) 인바운드
    아웃바운드    		 NA
    NAT 게이트웨이
    인스턴스 수준 공용 IP와 표준 공용 로드 밸런서가 함께 구성된 NAT Gateway 및 VM


    		 VM(서브넷 1) 인바운드
    아웃바운드    		 인스턴스 수준 공용 IP
    NAT 게이트웨이
    가상 머신 확장 집합(서브넷 1) 인바운드
    아웃바운드    		 로드 밸런서
    NAT 게이트웨이
    VM(서브넷 2) 인바운드
    아웃바운드    		 NA
    NAT 게이트웨이

2. Azure NAT Gateway 란?

  • Azure NAT Gateway는 완벽하게 관리되고 복원력이 뛰어난 네트워크 주소 변환(NAT) 완전 관리형 분산 서비스입니다.
  • Azure NAT Gateway를 사용하면 프라이빗 서브넷의 모든 인스턴스가 인터넷으로 아웃바운드로 연결되도록 허용하면서도 완벽한 프라이빗 상태를 유지할 수 있습니다.
  • 인터넷에서 요청하지 않은 인바운드 연결은 NAT Gateway를 통해 허용되지 않습니다. 아웃바운드 연결에 대한 응답 패킷으로 도착하는 패킷만 NAT Gateway를 통과할 수 있습니다.
  • 기본적으로 동적 SNAT 포트 기능을 제공하여 아웃바운드 연결을 자동으로 확장하고 SNAT 포트 고갈 위험을 줄입니다.
  • 기존 아웃바운드 구성이 있는 서브넷에 NAT 게이트웨이를 추가하면 아웃바운드 연결에 다운타임이 발생하지 않습니다
  • 여러 개의 NAT 게이트웨이를 단일 서브넷에 연결할 수 없으며, 여러 가상 네트워크에 NAT 게이트웨이를 걸쳐 있도록 구성할 수 없습니다.
  • NAT 게이트웨이는 부하 분산 장치, 인스턴스 수준 공용 IP 주소, Azure Firewall을 포함한 기타 아웃바운드 연결 방법보다 우선합니다.
  • NAT 게이트웨이 리소스가 배포될 때 영역을 선택하지 않으면 기본적으로 NAT 게이트웨이는 영역 없음(No-Zone)에 배치됩니다. NAT 게이트웨이가 영역 없음 에 배치되면 Azure에서 리소스를 자동으로 영역에 배치합니다. Azure가 NAT 게이트웨이에 어떤 영역을 선택하는지는 알 수 없습니다. NAT 게이트웨이가 배포된 후에는 영역 구성을 변경할 수 없습니다. 영역 없음 NAT 게이트웨이 리소스는 영역, 영역 없음 또는 영역 중복의 공용 IP 주소에 연결할 수 있습니다. => 즉 No-Zone NAT Gateway에는 Zonal / No-zone / Zone-redundant 모든 형태의 공용 IP(Basic SKU -> Standard SKU만 가능)가 연결 가능
  • NAT 게이트웨이를 Azure Firewall 서브넷에 직접 구성하여 Azure Firewall과 통합하게 되면, 피어링된 모든 스포크 가상 네트워크에 대해 허브 가상 네트워크에서 아웃바운드 연결을 제공할 수 있습니다.

3. 핵심 요약

  • Inbound Traffic은 기본적으로 VM P.IP 할당, LB, Application Gateway 이렇게 3가지가 가능하다.
  • Outbound Traffic 은 NAT gateway(9.30이후) 와 방화벽을 통해서만 가능하다.

4. 참고 문서

Azure Saving Plan, Reserved Instance을 활용한 비용절감 방안 이해

1. Reserved Instance란(예약구매)?

  • 예약을 선택하면 일정 기간 동안 특정 Azure 지역에서 특정 형식의 컴퓨팅 인스턴스 또는 인스턴스 제품군을 사용하겠다고 약정하는 것입니다.
  • 예를 들어, 일본 동부 지역에서 1년 동안 D2v4 가상 머신을 사용하기로 약정할 수 있습니다. Azure 절약 플랜에는 특정 기간 동안 모든 Azure 지역의 적합 컴퓨팅 서비스에 대한 특정 시간당 지출을 약속하는 것이 포함됩니다. 예를 들어, 3년 동안 시간당 5달러를 지출하기로 약속할 수 있습니다.
  • 예약은 지정된 컴퓨팅 서비스 및 지역 조합에만 적용됩니다.
  • 인스턴스 형식, 인스턴스 패밀리 또는 지역에 대한 예상되는 변경 없이 지속적으로 실행되고 매우 안정적인 워크로드가 있는 경우 예약을 선택합니다. 완전히 활용되면 예약을 통해 가장 큰 절약 효과(3년 약정 기준 최대 65%)를 얻을 수 있습니다.

2.  Saving Plan

  • Azure 절약 플랜은 EA(기업계약), MCA(Microsoft 고객 계약) 또는 MPA(Microsoft 파트너 계약) 계약이 있는 조직에서 사용할 수 있는 할인 전략입니다.
  • 절약 플랜 요금은 MCA 및 MPA 고객의 경우 USD로, EA 고객의 경우 현지 통화로 가격이 책정되며, 매 시간마다 약정 금액까지 적합한 컴퓨팅 사용량이 할인되고 시간당 약정을 소실하는 데 사용됩니다.
  • 약정 금액이 사용되면 나머지 사용량은 고객의 종량제 요금으로 청구되며, 모든 시간에서 사용되지 않은 약정은 손실됩니다.
  •  안정적이고 예측 가능한 워크로드를 대상으로 하는 Azure Reserved Instance과 달리 Azure 절약 플랜은 동적 및/또는 진화하는 워크로드를 대상으로 합니다. 즉 일관된 컴퓨팅 지출이 있지만 서로 다른 리소스를 사용하여 Azure 예약을 실행할 수 없는 경우 Saving Plan을 채택합니다.

3. 비용 절감에 대한 추가 적용 방식

  1. Reserved Instance 혜택은 Saving Plan보다 더 제한적이고 일반적으로 할인율이 더 높기 때문에 Azure는 Reserved Instance 혜택을 먼저 적용됩니다. 
  2. 청구 시스템은 가능한 한 가장 유익한 방식으로 절약 플랜을 신속하게 적용하는 임무를 맡고 할인율이 가장 큰 사용량부터 요금제 혜택이 적용됩니다
  3. 범위 옵션
    -     리소스 그룹 범위 - 선택한 리소스 그룹의 적합 리소스에 혜택을 적용합니다.
    - 구독 범위 - 선택한 구독의 적합 리소스에 혜택을 적용합니다.
    - 관리 그룹 - 관리 그룹 및 청구 범위 모두에 있는 모든 구독의 적합 리소스에 혜택을 적용합니다.
    - 공유 범위 - EA 등록 또는 MCA 청구 프로필에 있는 구독 내의 적합 리소스에 혜택을 적용합니다.
    • 구독이 다른 등록/청구 프로필로 이동되면 더 이상 구독에 혜택이 적용되지 않습니다.
    • EA 고객의 경우 공유 범위에는 등록에 여러 Microsoft Entra 테넌트가 포함될 수 있습니다.
  4. 범위 처리 순서
    -     리소스 그룹 범위가 포함된 절약 플랜
    - 구독 범위가 포함된 절약 플랜.
    - 관리 그룹 범위가 포함된 절약 플랜
    - 범위가 공유된 절약 플랜.

4. 추가 비용 절감 방안

  • VM Right Sizing : 자동 종료 설정(Auto-shutdown), Automation + Runbook(Azure Automation 계정에서 “Start/Stop VMs during off-hours” 솔루션을 배포하고, Runbook으로 일정 자동화 가능) 을 통한 비용 절감
  • AVD(Azure Virtual Desktop) 환경은 스케줄에 따른 VM 수 조정을 통해 비용 최적화 가능. Automate된 상태로 유지되는 워크로드에 매우 효과적임.

5. 참고 문서

Azure VMSS의 특징과 Ochestration 모드 분석

1. VMSS란?

  • Virtual Machine Scale Set(이하 확장 집합) 의 약자로, 부하 분산된 여러 VM의 그룹을 만들고 관리할 수 있는 구성 세트입니다.(AWS Auto Scaling Group)

2. VMSS의 장점

  • 손쉬운 여러 VM 만들기 및 관리
    • 애플리케이션을 실행하는 VM을 많이 사용하는 경우 환경 전체에서 일관된 구성을 유지해야 합니다. 신뢰할 수 있는 애플리케이션 성능을 위해 VM 크기, 디스크 구성, 기본 OS 이미지, 애플리케이션 설치가 모든 VM에서 일치해야 합니다.
    • 기본 4계층 트래픽 분산에는 Azure 부하 분산 장치를 사용하고, 고급 7계층 트래픽 분산 및 TLS 종료에는 Azure Application Gateway를 사용하도록 지원합니다.
  • 고가용성 및 애플리케이션 복원력 제공
    • 여러 인스턴스를 실행 중 VM 인스턴스 중 하나에 문제가 있는 경우, 고객은 중단을 최소화하면서 다른 VM 인스턴스 중 하나를 통해 애플리케이션에 계속 액세스합니다.
    • 추가 가용성을 위해 가용성 영역을 사용하여 단일 데이터 센터 또는 여러 데이터 센터 내에서 VM 인스턴스를 확장 집합에 자동으로 배포할 수 있습니다. 가용성 영역 VM을 배포하면 데이터 센터 오류로부터 보호할 수 있습니다. 확장 집합은 데이터 센터 오류로부터 보호할 수 없습니다.
  • 리소스 수요 변화에 따라 자동으로 애플리케이션 크기 조정
    • 자동 크기 조정 옵션은 수요가 낮을 때 애플리케이션을 실행하는 불필요한 VM 인스턴스의 수를 최소화하는 한편, 수요가 증가하고 추가 VM 인스턴스가 자동으로 추가될 때 고객이 허용 가능한 수준의 성능을 계속 확보할 수 있습니다. 
  • 대규모 작업
    • 확장 집합은 Azure Compute Gallery(이전의 Shared Image Gallery)를 통해 표준 마켓플레이스 이미지 및 사용자 지정 이미지에 대해 최대 1,000개의 VM 인스턴스를 지원합니다. 관리되는 이미지를 사용하여 확장 집합을 만드는 경우에는 VM 인스턴스가 600개로 제한됩니다.
  • 비용 효율적인 서비스
    • 확장 집합을 사용하는 데 추가 비용은 없습니다. 확장 집합에서 사용하는 컴퓨팅, 네트워크 및 스토리지 리소스에 따라 요금이 청구됩니다.

3. 가용성 집합(Availability Sets)과의 비교

  • 가용성 집합은 관련 VM을 동시에 중단하는 상관 관계 오류가 발생할 가능성을 줄이는 VM의 논리적 그룹화입니다. 가용성 집합은 안정성을 높이기 위해 다른 장애 도메인에 VM을 배치하는데, 특히 가용성 영역을 지원하지 않는 경우에 특히 유용합니다.
  • 가용성 집합은 여러 장애 도메인에 영향을 줄 수 있는 데이터 센터 네트워크 오류와 같은 특정 공유 인프라 오류에 여전히 취약하여, VMSS를 권장

4. 오케스트레이션 모드

  • 해당 옵션은 VMSS 오케스트레이션 섹션에서 설정하며, 유연한 모드(Flexible)와 균일한(Uniform) 모드를 선택할 수 있으며, 확장에서 용량 수동 업데이트, 자동 크기 조정, 크기 조정 프로필 없음(균일한 모드에선 비활성화)을 선택할 수 있다.
  • 유연한 오케스트레이션은 동일하거나 혼합된 가상 머신 유형을 사용하여 고가용성 및 확장성을 위해 최적화된 모드로 기본적인 권장 모드이다. 이 모드의 주요 장점 중 하나는 확장 집합 자식 가상 머신 대신 표준 Azure IaaS VM을 통해 오케스트레이션 기능을 제공한다는 것입니다. 즉, 균일 오케스트레이션에서 사용하는 Virtual Machine Scale Set VM API 대신 유연 오케스트레이션 인스턴스를 관리할 때 모든 표준 VM API를 사용할 수 있습니다
  • 균일한 오케스트레이션은 동일한 가상 머신 인스턴스를 사용하는 대규모 워크로드에 최적화되었습니다. 미리 정의된 가상 머신 프로필을 사용하여 확장 집합 내에서 동일한 인스턴스를 배포하여 일관성을 보장한다는 장점이 있지만, 표준 Azure IaaS VM API 명령, Azure Resource Manager 태그 지정, RBAC, Azure Backup 또는 Azure Site Recovery와의 호환성이 부족하다는 단점이 있다.

5. Flexible Ochestration, Uniform Ochestration, Availability Sets 간 비교표 (참고) 

카테고리 기능 확장 집합에 대한 Flexible 오케스트레이션에서 지원 확장 집합에 대한 Uniform 오케스트레이션에서 지원 가용성 집합에서 지원
기본 설정 가상 머신 유형 표준 Azure IaaS VM(Microsoft.compute/virtualmachines) 확장 집합 특정 VM(Microsoft.compute/virtualmachinescalesets/virtualmachines) 표준 Azure IaaS VM(Microsoft.compute/virtualmachines)
최대 인스턴스 수(FD 보장 사용) 1000 100 200
지원되는 SKU 모든 SKU 모든 SKU 모든 SKU
VM, NIC, 디스크에 대한 모든 컨트롤 예 Virtual Machine Scale Sets VM API를 사용한 제한된 제어 예
RBAC 사용 권한 필요 컴퓨팅 Virtual Machine Scale Sets 쓰기, 컴퓨팅 VM 쓰기, 네트워크 컴퓨팅 Virtual Machine Scale Sets 쓰기 해당 없음
테넌트 간 공유 이미지 갤러리 예 예 예
가속된 네트워킹 예 예 예
스폿 인스턴스 및 가격 책정 예, 스폿 및 일반 우선 순위 인스턴스를 모두 사용할 수 있습니다 예, 인스턴스는 모두 스폿이거나 모두 정상이어야 합니다 아니요, 일반 우선 순위 인스턴스만 해당됩니다.
혼합 운영 체제 예, Linux 및 Windows는 동일한 Flexible 확장 집합에 상주할 수 있습니다. 아니요, 인스턴스는 동일한 운영 체제입니다 예, Linux 및 Windows는 동일한 가용성 집합에 상주할 수 있습니다.
디스크 유형 관리 디스크만, 모든 스토리지 유형 관리형 디스크와 비관리형 디스크 관리형 디스크와 비관리형 디스크. Ultra 디스크는 지원되지 않습니다.
고객 관리 키로 디스크 서버 쪽 암호화 예 예 예
쓰기 가속기 예 예 예
근접 배치 그룹 예, 가용성 영역 하나를 사용하거나 없는 경우. 배포 후에는 변경 불가.  예, 가용성 영역 하나를 사용하거나 없는 경우. 모든 인스턴스를 배포 중지한 후 변경 가능 예
Azure 전용 호스트 예 예 예
관리 ID 사용자 할당 ID 전용1 시스템 할당 또는 사용자 할당 N/A(개별 인스턴스에서 관리 ID를 지정할 수 있음)
그룹에 기존 VM 추가/제거 예 아니요 아니요
Service Fabric 아니요 예 아니요
Azure Kubernetes Service(AKS) / AKE 아니요 예 아니요
사용자 데이터 예 예 개별 VM에 대해 UserData를 지정할 수 있습니다.
VM NIC 및 디스크를 삭제하거나 유지하는 옵션 예 아니요(항상 삭제) 예
Ultra Disks 예 예 아니요
자동 조정 및 인스턴스 오케스트레이션 집합의 VM 나열 예 예 예, AvSet의 VM을 나열
자동 크기 조정(수동, 메트릭 기반, 일정 기반) 예 예 아니요
VM 인스턴스를 삭제할 때 NIC 및 디스크 자동 제거 예 예 아니요
업그레이드 정책(Virtual Machine Scale Set) 자동, 롤링, 수동 자동, 롤링, 수동 해당 없음
자동 OS 업데이트(Virtual Machine Scale Set) 아니요 예 해당 없음
게스트 보안 패치 중 예 아니요 예
종료 알림(Virtual Machine Scale Set) 예 예 해당 없음
애플리케이션 상태 모니터링 애플리케이션 상태 확장 애플리케이션 상태 확장 또는 Azure Load Balancer 프로브 애플리케이션 상태 확장
인스턴스 복구(Virtual Machine Scale Set) 예 예 해당 없음
인스턴스 보호 예 예 아니요
규모 감축 정책 예 예 아니요
VMSS 인스턴스 보기 가져오기 아니요 예 해당 없음
VM Batch 작업(모두 시작, 모두 중지, 하위 집합 삭제 등) 예 예 아니요
고가용성 가용성 SLA 장애 도메인에 분산된 인스턴스의 경우 99.95%; 여러 영역으로 분산된 인스턴스의 경우 99.99% 단일 배치 그룹에서 FD>1을 초과하는 경우 99.95%, 여러 영역에 분산된 인스턴스의 경우 99.99% 99.95%
가용성 영역 1, 2 또는 3개의 가용성 영역에 인스턴스를 지정합니다. 1, 2 또는 3개의 가용성 영역에 인스턴스를 지정합니다. 지원되지 않음
특정 가용성 영역으로 VM 할당 예 아니요 아니요
장애 도메인 – 최대 분산(Azure는 최대 확산 인스턴스) 예 예 아니요
장애 도메인 – 고정 분산 2~3 FD(지역 최대 FD 수에 따라 다름); 영역 배포의 경우 1 2, 3, 5 FD, 영역 배포의 경우 1, 5 2~3 FD(지역 최대 FD 수에 따라 다름)
특정 장애 도메인에 VM 할당 예 아니요 아니요
업데이트 도메인 사용 중단됨(FD로 FD를 수행한 플랫폼 유지 관리) 5 업데이트 도메인 최대 20개의 업데이트 도메인
유지 보수 수행 VM API를 사용하여 각 인스턴스에 대한 유지 관리 트리거 예 해당 없음
용량 예약 예 예 예
네트워킹 기본 아웃바운드 연결 아니요, 명시적 아웃바운드 연결이 있어야 합니다. 예 예
Azure Load Balancer 표준 SKU 예 예 예
애플리케이션 게이트웨이 예 예 예
InfiniBand 네트워킹 아니요 예, 단일 배치 그룹만 해당 예
기본 LB 아니요 예 예
네트워크 포트 전달 예(개별 인스턴스에 대한 NAT 규칙) 예(NAT 풀) 예(개별 인스턴스에 대한 NAT 규칙)
백업 및 복구 Azure 백업 예 아니요 예
Azure 사이트 복구 예(PowerShell을 통해) 아니요 예
Azure 경고 예 예 예
VM 인사이트 개별 VM에 설치할 수 있습니다. 예 예

 

6. 애플리케이션 변경시 VMSS 변경 절차

  • Azure Virtual Machine Scale Set(VMSS)는 애플리케이션이나 인스턴스 구성을 변경할 때 다음과 같은 절차로 VM 인스턴스들이 업데이트됩니다
    1. 새 이미지 템플릿 준비
      먼저 변경된 애플리케이션(새 코드, OS 패치 등)을 포함한 새로운 VM 이미지를 준비합니다.
      • 기존 이미지를 업데이트 하거나 새로운 이미지를 만듭니다.
    2. VMSS 모델 업데이트
      생성한 최신 이미지(또는 앱 변경 사항이 반영된 매개변수)를 VMSS에 등록합니다.
      • Azure Portal, CLI, PowerShell 등에서 새 이미지를 VMSS 모델에 적용합니다.
    3. 업그레이드 정책 적용
      VMSS의 업그레이드 모드(Manual, Automatic, Rolling)를 선택합니다. 
      • Automatic(자동): 새 인스턴스가 자동으로 단계별로 업그레이드됩니다. 스케일 세트는 종료되는 가상 머신의 순서를 보장하지 않습니다. 스케일 세트는 업그레이드를 위해 모든 가상 머신을 동시에 종료할 수 있습니다. 구성 및 설정을 변경하는 동안 인스턴스 가동 시간에 대해 걱정하지 않아도 되는 DevTest 시나리오에 가장 적합합니다.
      • Manual(수동): 관리자가 직접 업그레이드 시작하며, 수동 업그레이드 정책 모드를 사용하면 확장 집합 인스턴스를 언제 업데이트할지 선택할 수 있습니다. 확장 집합 모델이 변경되어도 기존 가상 머신에는 아무런 변화가 자동으로 발생하지 않습니다. 확장 집합에 추가된 새 인스턴스는 사용 가능한 최신 업데이트 모델을 사용합니다. 수동 업그레이드 정책 모드는 인스턴스가 언제, 어떻게 업데이트되는지에 대한 제어력을 높여야 하는 워크로드에 가장 적합합니다.
      • Rolling: 지정한 비율·수에 따라 점진적으로 인스턴스를 재생성합니다.  롤링 업그레이드 정책 모드를 사용하면 확장 세트가 일괄적으로 업데이트를 수행합니다. 또한 일괄 크기, 최대 정상 비율, 비정상 인스턴스 우선순위 지정, 가용 영역 전체에 걸친 업그레이드 활성화 등의 설정을 통해 업그레이드를 더욱 효과적으로 제어할 수 있습니다. 롤링 업그레이드 정책 모드는 일정 수의 인스턴스를 항상 사용할 수 있어야 하는 프로덕션 워크로드에 가장 적합합니다. 롤링 업그레이드는 가용성과 가동 시간을 저해하지 않고 인스턴스를 최신 모델로 업그레이드하는 가장 안전한 방법입니다. Flexible Orchestration을 사용하는 가상 머신 확장 집합에서 롤링 업그레이드 정책 모드를 사용하는 경우 확장 집합은 애플리케이션 상태를 모니터링하기 위해 애플리케이션 상태 확장 기능 도 사용해야 합니다. Uniform Orchestration을 사용하는 가상 머신 확장 집합에서 롤링 업그레이드 정책 모드를 사용하는 경우 확장 집합에도 상태 프로브가 있어야 하거나 애플리케이션 상태 확장을 사용하여 애플리케이션 상태를 모니터링해야 합니다.
    4. 인스턴스 업데이트 실행
      정책에 따라, 기존 VM 인스턴스가 새 이미지 또는 변경 사항으로 교체(재배포, 재부팅, 교체 등)됩니다.
      • 구체적으로, 각 VM 인스턴스가 순차적(혹은 병렬)으로 신규 인스턴스로 교체되며, 서비스 중단 없이 가용성 그룹을 고려하여 롤링 방식으로 진행됩니다.
    5. 상태 확인 및 마감
      모든 인스턴스가 정상적으로 새 이미지/애플리케이션으로 배포된 것을 확인합니다.

7. 참고 문서

Azure DNS Private Resolver 에 대한 이해 및 구성

1. Azure DNS 개요 

  • Azure DNS(Domain Name System, 서비스 이름을 해당 IP 주소로 변환)는 Microsoft Azure 인프라를 사용하여 애플리케이션에 대한 DNS 호스팅, 확인 및 부하 분산을 제공하며, 인터넷 연결 DNS 도메인과 프라이빗 DNS 영역을 모두 지원하며 다음과 같은 서비스를 제공합니다.
  • Azure 퍼블릭 DNS는 DNS 도메인에 대한 호스팅 서비스입니다. Azure에 도메인을 호스트하면 다른 Azure 서비스와 동일한 자격 증명, API, 도구 및 대금 청구를 사용하여 DNS 레코드를 관리할 수 있습니다. 다만, Azure 공용 DNS를 사용하여 도메인 이름을 직접 구입할 수 없고, 연간 요금의 경우 App Service 도메인 또는 타사 도메인 이름 등록자를 사용하여 도메인 이름을 구매할 수 있는 한계가 있다.
  • Azure 프라이빗 DNS는 가상 네트워크에 대한 DNS 서비스입니다. Azure Private DNS는 사용자 지정 DNS 솔루션을 구성할 필요 없이 가상 네트워크의 도메인 이름을 관리하고 확인합니다. 뿐만 아니라, 프라이빗 DNS 영역을 사용하면 배포 중에 Azure에서 제공한 이름 대신 고유한 사용자 지정 도메인 이름을 사용할 수 있습니다. 그리고 프라이빗 DNS 영역을 만들 때 Azure는 영역 데이터를 전역 리소스로 저장하는데, 즉 프라이빗 영역은 단일 VNet 또는 지역에 종속되지 않아 하나의 VNet에서 서비스가 중단된 경우 프라이빗 영역을 계속 사용할 수 있는 장점이 있습니다.
  • Azure DNS Private Resolver는 VM 기반 DNS 서버를 배포하지 않고 온-프레미스 환경에서 Azure DNS 프라이빗 영역을 쿼리하거나 그 반대로 쿼리할 수 있는 서비스입니다. 
  • Azure Traffic Manager는 DNS 기반 트래픽 부하 분산 장치입니다. 이 서비스를 사용하면 글로벌 Azure 지역에서 공용 연결 애플리케이션에 트래픽을 배포할 수 있습니다.  https://learn.microsoft.com/ko-kr/azure/traffic-manager/traffic-manager-overview

 

2. Azure DNS Private Resolver 이점

  • 유지 관리가 필요 없음: VM 또는 하드웨어 기반 솔루션과 달리 Private Resolver 프로그램에는 소프트웨어 업데이트, 취약성 검사 또는 보안 패치가 필요하지 않습니다. Private Resolver 프로그램 서비스는 완전히 관리됩니다.
  • 비용 절감: Azure DNS Private Resolver는 다중 테넌트 서비스이며 여러 VM 기반 DNS 해결 프로그램을 사용하고 라이선스를 부여하는 데 필요한 비용의 일부만 사용하게 됩니다.
  • 고가용성: Azure DNS Private Resolver 서비스에는 기본 제공 고가용성 기능이 있습니다. 서비스는 가용성 영역을 인식하므로 훨씬 적은 활동으로 DNS 솔루션의 고가용성 및 중복성을 달성할 수 있습니다.
  • DevOps 친화적: 기존 DNS 솔루션은 모든 DNS 변경에 대해 수동 구성이 필요한 경우가 많으므로 DevOps 워크플로와 통합하기 어렵습니다. Azure DNS 프라이빗 해결 프로그램은 DevOps 워크플로와 쉽게 통합할 수 있는 완전한 기능의 ARM 인터페이스를 제공합니다.
  • TCP/UDP 53 포트를 이용한 양방향 DNS 쿼리를 처리합니다.

3. Azure DNS Private Resolver 구성

  • DNS private resolver 에서 '만들기' 를 추가하여 만드는데(25.08.05), 반드시 Vnet을 설정해 줘야 한다.
  • 기본 정보 입력 후 Inbound Endpoint, Outbound Endpoint, Ruleset 탭에서 각각에 맞는 정보들을 구성한다. 즉 DNS private resolver 구성을 위해서는 Inbound Endpoint Subnet, Outbound Endpoint Subnet을 생성해야 한다.
  • 결론적으로 On-prem에서 Azure 내부 도메인 질의를 할 때는 Inbound Endpoint Subnet을 거쳐 Private DNS Zone으로 트래픽이 흘러간다.
  • 이와는 반대로 Azure 내부에서 On-prem으로 도메인 질의를 할 때 DNS Forwarding Rulesets에 DNS 쿼리를 처리한 후Outbound Endpoint Subnet을 거쳐 On-prem 내의 DNS서버에 해당 도메인을 질의하여 타겟 IP로 트래픽이 최종적으로 흘러간다.
  • 인바운드 엔드포인트에 할당된 IP 주소는 정적 또는 동적일 수 있습니다. 정적을 선택하면 서브넷에서 예약된 IP 주소를 선택할 수 없습니다. 동적 IP 주소를 선택하면 서브넷에서 사용 가능한 다섯 번째 IP 주소가 할당됩니다. 예를 들어 10.10.0.4는 10.10.0.0/28 서브넷(.0, .1, .2, .3, .4)의 다섯 번째 IP 주소입니다. 인바운드 엔드포인트가 다시 프로비저닝되면 이 IP 주소가 변경될 수 있지만 일반적으로 서브넷의 5번째 IP 주소가 다시 사용됩니다. 인바운드 엔드포인트가 다시 프로비전되지 않는 한 동적 IP 주소는 변경되지 않습니다. 다음 예제에서는 고정 IP 주소를 지정합니다.
  • 아웃바운드 엔드포인트는 또한 Private Resolver 프로그램이 배포되는 프라이빗 가상 네트워크 주소 공간의 일부입니다. 아웃바운드 엔드포인트는 서브넷과 연결되지만 인바운드 엔드포인트와 같은 IP 주소로 프로비저닝되지 않습니다. 아웃바운드 엔드포인트가 있는 동일한 서브넷에는 다른 리소스가 있을 수 없습니다. 
  • 이에 대한 추가 설명은 다른 블로그 정보를 참고해서 전달드립니다. (출처 : https://blog.naver.com/quiett20/223733339440)

 

4. (참고) DNS Forwarding Rulesets (DNS 전달 규칙 집합)

  • DNS 전달 규칙 집합이란? 특정 DNS 네임스페이스에 대한 쿼리에 답변하기 위해 하나 이상의 사용자 지정 DNS 서버를 지정하는 규칙
  • 해당 메뉴에서 새로운 구성을 "만들기" 해보면, 기본 구성시 private resolver와 Outbound Endpoint를 등록하고, 규칙(Rules, 도메인 쿼리 규칙 및 목적지 등록), Virtual network link(DNS 요청을 할 서버 연결)를 등록하도록 되어있다.
  • DNS 쿼리 요청을 하기 위해서는 반드시 해당 Vnet에서 Azure DNS Private Resolver 혹은 Azure Private DNS Zone에서 RuleSet에 해당 VNet이 Virtual Network Link 형태로 연결되어 있어야 합니다.
  • 다만, 여러 Vnet에서 DNS Forwarding Ruleset에 등록할 때 유의점은, 해당 Ruleset에 Private Resolver Endpoint 규칙이  있을 경우, Inbound Endpoint가 프로비전된 VNet(위에서는 Hub Vnet)에 그 규칙 모음집을 연결하게 되면, DNS 확인 루프가 발생할 수 있으니 조심해야 한다!!!
  • 또한 기본 DNS 서버 IP가 168.63.129.16이므로, 해당 IP는 Rulesets에 목적지 DNS서버로 등록될 수 없다.

5. 필수 네트워크 설정

(1) 서브넷 구성

  • Hub VNet 내 /28 이상 CIDR의 전용 서브넷 2개 생성
    • Inbound-subnet
    • outbound-subnet

⚠️ 서브넷은 최소 /28 주소 공간 또는 최대 /24 주소 공간이어야 합니다.

 

(2) 포트 및 방화벽

  • 포트 53 (TCP/UDP) 양방향 허용
  • On-Prem 방화벽에서 Azure DNS Private Resolver의 IP 범위(CIDR) 오픈
    (Control Plane이 여러 DNS 서버와 연동될 수 있으므로 CIDR 단위 허용 권장)
  • NSG(Network Security Group)에서 불필요한 외부 접근 차단

(3) 라우팅

  • ExpressRoute 또는 VPN 경로에 대상 CIDR 등록
  • VNet Peering 시 Allow Gateway Transit 설정 필요

6. 구성 절차

  • 1단계. 리소스 그룹 & Hub VNet 생성
    • 리전 선택(예: Korea Central)
    • /28 이상 서브넷 2개 생성 (inbound-subnet, outbound-subnet)
    2단계. DNS Private Resolver 생성
    • 리소스 그룹 선택
    • 위치: Hub VNet과 동일 리전
    • inbound-subnet / outbound-subnet 지정
    3단계. Inbound Endpoint 생성
    • inbound-subnet 선택
    • On-Prem DNS가 참조할 Private IP 자동 할당
    4단계. Outbound Endpoint 생성
    • outbound-subnet 선택
    • 외부 DNS 서버(On-Prem)로 포워딩할 규칙 적용
    5단계. DNS 포워딩 규칙 세트 작성
    • 예: corp.local → On-Prem DNS 10.10.1.10
    • 필요 시 Azure Private DNS Zone 연결
    6단계. NSG 규칙 적용
    • TCP/UDP 53 허용 (필요한 IP 범위만)
    • 관리 IP 대역만 허용해 보안 강화

7. 참고 문서

Azure Monitoring 개요 및 구성 분석

1. Azure Monitoring 개요

  • Azure Monitor는 클라우드 및 온-프레미스 환경에서 모니터링 데이터를 수집 및 분석하여 적절하게 대응하는 포괄적인 모니터링 솔루션입니다. 여러 Azure 및 비 Azure 구독 및 테넌트의 시스템의 모든 계층 및 구성 요소에서 데이터를 수집하고 집계합니다. 데이터를 상호 연결하고, 분석하고, 시각화하고/또는 응답할 수 있는 일반적인 도구 집합에서 사용할 수 있도록 공통 데이터 플랫폼에 저장합니다. 다른 Microsoft 및 비 Microsoft 도구를 통합할 수도 있습니다.
  • 모니터링 되는 리소스의 데이터 원본(메트릭,로그,추적,변경)을 수집하여, 데이터 플랫폼에 저장합니다. 이를 인사이트를 통해 시각화하고, 분석하며, 상황에 따라 대응하기도 하며, 다른 시스템과 함께 작동하는 통합 기능을 제공하기도 합니다.
  • 기본구성은 아래와 같습니다
    • Metrics(메트릭): 특정 시점의 시스템 상태를 숫자 값으로 표현한 실시간에 가까운 데이터입니다.
    • Logs(로그): 이벤트, 추적, 성능 데이터 등 다양한 형식의 기록 데이터로서 구조화되거나 자유 형식일 수 있습니다.
    • Traces(분산 추적): 요청의 경로 분석 데이터
    • Changes(변경 내용): 애플리케이션과 리소스에서 발생한 일련의 이벤트

2. Insights(인사이트)

  • 일부 Azure 리소스 공급자에는 사용자 지정된 모니터링 환경을 제공하고 최소한의 구성이 필요한 큐레이팅된 시각화가 있습니다. 인사이트는 크고, 확장 가능하고, 큐레이팅된 시각화입니다.
  • 종류
    카테고리 설명
    Application Insights Application Insights는 웹 애플리케이션의 가용성, 성능 및 사용량을 모니터링합니다.
    Container Insights 컨테이너 인사이트는 Azure Kubernetes Service에서 호스팅되는 관리되는 Kubernetes 클러스터에 배포된 컨테이너 워크로드의 성능 가시성을 모니터링합니다. 메트릭 API를 통해 Kubernetes에서 사용할 수 있는 컨트롤러, 노드, 컨테이너의 컨테이너 로그 및 메트릭을 수집합니다. Kubernetes 클러스터에서 모니터링을 사용하도록 설정하면, 이러한 메트릭 및 로그가 Linux용 Log Analytics 에이전트의 컨테이너화된 버전을 통해 자동으로 수집됩니다.
    VM Insights VM 인사이트는 Azure VM을 모니터링합니다. Windows 및 Linux VM의 성능과 상태를 분석하고 외부 프로세스에 대한 서로 다른 프로세스 및 상호 연결된 종속성을 식별합니다. 이 솔루션에는 온-프레미스 또는 다른 클라우드 공급자에 호스트되는 VM의 성능 및 애플리케이션 종속성 모니터링에 대한 지원이 포함됩니다.
    Network Insights 네트워크 인사이트는 구성할 필요 없이 배포된 모든 네트워크 리소스에 대한 상태 및 메트릭의 토폴로지를 통해 포괄적이고 시각적인 표현을 제공합니다. 또한 연결 모니터, NSG(네트워크 보안 그룹)에 대한 흐름 로깅, 트래픽 분석 및 기타 진단 기능과 같은 네트워크 모니터링 기능에 액세스할 수 있습니다.

3. Visualize(시각화)

  • 차트 및 표 같은 시각화는 모니터링 데이터를 요약하여 여러 대상에게 보여주는 효과적인 도구입니다. Azure Monitor는 모니터링 데이터를 시각화하는 고유 기능이 있으며 다른 Azure 서비스를 사용하여 모니터링 데이터를 여러 대상 그룹에 게시합니다. Power BI 및 Grafana는 공식적으로 Azure Monitor 제품의 일부가 아니지만 핵심 통합이며 Azure Monitor 스토리의 일부입니다.
  • 종류(https://learn.microsoft.com/en-us/azure/azure-monitor/visualize/best-practices-visualize)
    카테고리 설명
    Azure Dashboard Azure 대시보드에서는 다양한 종류의 데이터를 Azure Portal의 단일 창으로 결합할 수 있습니다. 필요에 따라 대시보드를 다른 Azure 사용자와 공유할 수 있습니다. 모든 로그 쿼리 또는 메트릭 차트의 출력을 Azure 대시보드에 추가할 수 있습니다. 예를 들어 메트릭 그래프, 활동 로그 표, Application Insights의 사용량 차트, 로그 쿼리를 나타내는 타일이 조합된 대시보드를 만들 수 있습니다.
    Azure Workbooks 통합 문서는 데이터 분석 및 Azure Portal에서 풍부한 시각적 보고서 생성을 위한 유연한 캔버스를 제공합니다. 이를 사용하여 여러 데이터 원본의 데이터를 쿼리할 수 있습니다. 통합 문서는 하나의 시각화에서 여러 데이터 집합의 데이터를 결합하고 상관 관계를 지정하여 시스템을 시각적으로 쉽게 표현할 수 있습니다. 통합 문서는 대화형이며 실시간으로 데이터를 업데이트하여 팀 간에 공유할 수 있습니다. Insights와 함께 제공되는 통합 문서를 사용하거나, 템플릿 라이브러리를 활용하거나, 직접 만듭니다.
    Power BI Power BI는 다양한 데이터 원본에서 대화형 시각화를 제공하는 비즈니스 분석 서비스입니다. 조직 내부 및 외부의 다른 사람들이 데이터를 사용할 수 있도록 하는 효과적인 수단입니다. Azure Monitor에서 자동으로 로그 데이터를 가져오도록 Power BI를 구성하여 이러한 시각화를 활용할 수 있습니다.
    Grafana Grafana는 뛰어난 운영 대시보드를 제공하는 개방형 플랫폼입니다. 모든 버전의 Grafana에는 Azure Monitor 메트릭 및 로그를 시각화하는 Azure Monitor 데이터 원본 플러그 인이 포함되어 있습니다. Azure Managed Grafana도 Azure Monitor 및 Azure Data Explorer와 같은 Azure 네이티브 데이터 저장소에 대해 이 환경을 최적화합니다. 이러한 방식으로 구독의 모든 리소스에 쉽게 연결하고 친숙한 Grafana 대시보드에서 모든 결과 모니터링 데이터를 볼 수 있습니다. 또한 Azure Monitor 메트릭 및 로그에서 Grafana 대시보드에 차트를 고정하는 기능을 지원합니다.
    Grafana에는 Dynatrace, New Relic 및 AppDynamics와 같은 비 Microsoft APM(애플리케이션 성능 관리) 도구에 대한 인기 있는 플러그 인 및 대시보드 템플릿이 있습니다. 이러한 리소스를 사용하여 이러한 다른 도구에서 수집한 상위 스택의 다른 메트릭과 함께 Azure 플랫폼 데이터를 시각화할 수 있습니다. 또한 단일 창에서 다중 클라우드 모니터링을 위한 AWS(Amazon Web Services) CloudWatch 및 GCP(Google Cloud Platform) BigQuery 플러그 인이 있습니다.

4. Analyze(분석)

카테고리 설명
Azure Monitor Explorer Azure Portal에서 Azure Monitor 메트릭 탐색기 사용자 인터페이스를 사용하여 리소스의 상태 및 사용률을 조사합니다. 메트릭 탐색기를 사용하면 차트를 그리고, 추세 간 상관 관계를 시각적으로 표시하고, 메트릭 값의 급등 및 급락을 조사할 수 있습니다. 메트릭 탐색기에는 차원 및 필터링을 적용하고 차트를 사용자 지정하는 기능이 포함되어 있습니다. 이러한 기능을 통해 시각적으로 직관적인 방식으로 필요한 데이터를 정확하게 분석할 수 있습니다.
Log Analytics Azure Portal에서 Log Analytics 사용자 인터페이스를 사용하면 수집된 데이터를 신속하게 검색, 통합 및 분석할 수 있도록 Azure Monitor에서 수집한 로그 데이터를 쿼리할 수 있습니다. 테스트 쿼리를 만든 후 Azure Monitor 도구를 사용하여 데이터를 직접 분석하거나 시각화 또는 경고 규칙과 함께 사용할 쿼리를 저장할 수 있습니다. Log Analytics 작업 영역은 강력한 분석 엔진과 다양한 KQL(Kusto 쿼리 언어)을 사용하여 Azure Data Explorer를 기반으로 합니다. Azure Monitor 로그는 간단한 로그 쿼리에 적합한 Kusto 쿼리 언어 버전과 집계, 조인 및 스마트 분석과 같은 고급 기능을 사용합니다. 빠르고 쉽게 KQL을 시작할 수 있습니다. 참고: "Log Analytics"라는 용어는 Azure Monitor 로그 데이터 플랫폼 저장소 및 해당 저장소에 액세스하는 UI 모두를 의미하는 데 사용됩니다. 2019년 이전에는 "Log Analytics"라는 용어가 둘 다를 참조했습니다. 인터넷의 다양한 블로그 및 설명서에서 해당 프레이밍을 사용하여 콘텐츠를 찾는 것은 여전히 일반적입니다.
Change Analysis(Classic) 변경 분석(클래식)은 구독의 리소스 변경 내용을 확인하고 사용자가 어떤 변경으로 인해 문제가 발생했는지 이해할 수 있도록 진단 도구에 대한 데이터를 제공하는 구독 수준 Azure 리소스 공급자입니다. Azure Portal의 변경 분석(클래식) 사용자 인터페이스를 사용하면 라이브 사이트 문제, 중단 또는 구성 요소 오류의 원인을 파악할 수 있습니다. 변경 분석(클래식)은 Azure Resource Graph 를 사용하여 인프라 계층에서 애플리케이션 배포까지 다양한 유형의 변경 내용을 검색합니다.

 

5. Respond(대응)

  • 효과적인 모니터링 솔루션은 개인 또는 팀이 문제를 파악할 필요 없이 중요한 이벤트에 사전 대응합니다. 응답은 관리자에게 보내는 텍스트 또는 전자 메일이거나 오류 조건을 수정하려는 자동화된 프로세스일 수 있습니다.
  • Azure Monitor 경고는 위험 조건을 알리고 정정 작업을 수행할 수 있습니다. 경고 규칙은 메트릭 또는 로그 데이터를 기반으로 할 수 있습니다.
  • 자동 크기 조정을 사용하면 애플리케이션의 부하를 처리하기 위해 실행 중인 리소스 수를 동적으로 제어할 수 있습니다. Azure Monitor 메트릭을 사용하여 부하가 증가할 때 리소스를 자동으로 추가하거나 유휴 상태인 리소스를 제거할 시기를 결정하는 규칙을 만들 수 있습니다. 최소 및 최대 인스턴스 수와 리소스를 늘리거나 줄이는 시기에 대한 논리를 지정하여 비용을 절감하고 성능을 높일 수 있습니다. 

6. Integrate(통합)

  • Azure Monitor를 다른 시스템과 통합하거나 모니터링 데이터를 사용하는 사용자 지정 솔루션을 빌드해야 할 수 있습니다. 이러한 Azure 서비스는 Azure Monitor와 함께 작동하여 통합 기능을 제공합니다. 다음 다이어그램과 표에서는 몇 가지 가능한 통합만 보여 줍니다.
  • 종류
    카테고리 설명
    Event Hubs Azure Event Hubs는 스트리밍 플랫폼 및 이벤트 수집 서비스입니다. 실시간 분석 공급자나 일괄 처리/스토리지 어댑터를 사용하여 데이터를 변환하고 저장할 수 있습니다. Event Hubs를 사용하여 AZURE Monitor 데이터를 SIEM(보안 정보 및 이벤트 관리) 및 모니터링 도구로 스트리밍합니다.
    Azure Storage 감사 또는 규정 준수를 위해 더 저렴하고 장기적인 모니터링 데이터 보관을 위해 Azure Storage로 데이터를 내보냅니다.
    Azure Native Integrations Partners(호스팅 및 관리 파트너) 많은 외부 파트너가 Azure Monitor와 통합됩니다. 또한 Azure Monitor는 다양한 모니터링 공급자와 협력하여 상호 운용성을 용이하게 하기 위해 Azure 호스팅 버전의 제품을 제공합니다. 예를 들어 Elastic, Datadog, Logz.io 및 Dynatrace가 있습니다.
    Azure Monitor Rest API Azure Monitor에서 메트릭과 로그를 읽고 쓸 수 있는 여러 API가 제공되며, 생성된 경고에 액세스할 수도 있습니다. 또한 경고를 구성하고 검색할 수 있습니다. API를 사용하면 Azure Monitor와 통합되는 사용자 지정 솔루션을 빌드할 수 있는 무한한 가능성이 열립니다.
    Azure Logic Apps Azure Logic Apps는 코드가 거의 또는 전혀 없이 다양한 시스템 및 서비스와 통합되는 워크플로를 사용하여 작업 및 비즈니스 프로세스를 자동화하는 데 사용할 수 있는 서비스입니다. Azure Monitor에서 메트릭 및 로그를 읽고 쓰는 작업을 사용할 수 있습니다. Logic Apps를 사용하여 응답을 사용자 지정하고 Azure Monitor 경고에 대한 응답으로 다른 작업을 수행할 수 있습니다. Azure Monitor 인프라에서 아직 기본 제공 메서드를 제공하지 경우 다른 더 복잡한 작업을 수행할 수도 있습니다.
    Azure Functions Azure Logic Apps와 마찬가지로 Azure Functions는 프로세스 모니터링 데이터를 전처리 및 게시하고 일반적인 Azure Monitor 경고 범위를 벗어나 복잡한 작업을 수행할 수 있는 기능을 제공합니다. 그러나 Azure Functions는 코드를 사용하므로 Logic Apps보다 유연성이 더 강합니다.
    Azure DevOps 및 GitHub Azure Monitor Application Insights를 사용하면 모니터링 데이터가 포함된 작업 항목 통합을 생성할 수 있습니다. 추가 옵션에는 릴리스 주석 및연속 모니터링이 포함됩니다.

7. 참고 문서

 

Azure Monitoring을 활용한 Auto Scaling 개요

1. Auto Scaling 개요

  • Autoscale은 애플리케이션의 부하에 따라 리소스를 자동으로 추가 및 제거할 수 있는 서비스입니다.
  • 애플리케이션에 더 높은 부하가 발생하면 자동 크기 조정은 증가된 부하를 처리하기 위해 리소스를 추가합니다. 부하가 낮으면 자동 크기 조정이 리소스 수를 줄여 비용을 낮춥니다. CPU 사용량, 큐 길이, 사용 가능한 메모리와 같은 메트릭을 기반으로 애플리케이션을 크기 조정할 수 있습니다. 일정에 따라 크기를 조정할 수도 있습니다. 메트릭과 일정은 규칙에서 설정됩니다. 규칙에는 애플리케이션을 실행하는 데 필요한 최소 수준의 리소스와 초과하지 않는 최대 리소스 수준이 포함됩니다.
  • 자동 크기 조정은 스케일 인 및 스케일 아웃 또는 수평으로 확장됩니다. 수평 크기 조정은 리소스 인스턴스 수를 늘리거나 줄이는 수평적 크기 조정입니다. 예를 들어 가상 머신 확장 집합의 경우 스케일 아웃한다는 것은 더 많은 가상 머신을 추가하는 것을 의미합니다. 스케일 인이란 가상 머신을 제거하는 것입니다. 수평적 스케일링은 부하를 처리하기 위해 많은 수의 VM을 실행할 수 있으므로 클라우드 상황에서 유연합니다.
  • 자동 크기 조정은 수직 크기 조정을 지원하지 않습니다. 대조적으로 스케일 업과 스케일 다운 또는 수직적 스케일링은 동일한 수의 리소스 인스턴스를 일정하게 유지하지만 메모리, CPU 속도, 디스크 공간 및 네트워크 측면에서 더 많은 용량을 제공합니다. 수직적 스케일링은 더 큰 하드웨어의 가용성에 따라 제한되며 결국 상한에 도달하게 됩니다. 하드웨어 크기 가용성은 Azure에서 지역별로 다릅니다. 수직적 스케일링은 확장 프로세스 중에 VM을 다시 시작해야 할 수도 있습니다.
  • 예측 자동 크기 조정은 머신 러닝을 사용하여 주기적인 워크로드 패턴으로 가상 머신 스케일 세트를 관리하고 확장하는 데 도움이 됩니다. 과거 CPU 사용 패턴을 기반으로 가상 머신 확장 집합의 전체 CPU 부하를 예측합니다. 그런 다음 확장 집합은 예측된 수요를 충족하도록 제 시간에 스케일 아웃될 수 있습니다.
  • 시간 혹은 메트릭 기반으로 규칙을 설정하고, 규칙에 대한 작업을 설정할 수 있습니다. 작업의 종류로는 크기 조정, 웹후크, 이메일 등이 있습니다.
  • Azure Monitor 자동 스케일링은 Azure Virtual Machine Scale Sets, Azure Cloud Services, Azure App Service의 Web Apps 기능 및 Azure API Management에만 적용됩니다.

2. Auto Scaling 상세 조건

  • 하나의 리소스에는 하나의 자동 스케일링 설정만 있을 수 있습니다.
  • 자동 스케일링 설정에는 하나 이상의 프로필이 있을 수 있으며, 각 프로필에는 하나 이상의 자동 스케일링 규칙이 있을 수 있습니다.
  • 자동 크기 조정 설정은 인스턴스 크기를 수평적으로 조정합니다. 즉, 인스턴스를 늘려 규모를 확장하고 인스턴스 수를 줄여 규모를 감축합니다.
  • 자동 크기 조정 설정에는 최대, 최소 및 기본 인스턴스 값이 있습니다.
  • 자동 크기 조정 작업에서는 항상 규모 확장 또는 규모 감축에 대해 구성된 임계값에 도달했는지 확인하여 크기를 조정할 연관된 메트릭을 읽습니다. Azure Monitor 자동 크기 조정 공통 메트릭에서 자동 크기 조정을 통해 크기를 조정할 수 있는 메트릭 목록을 볼 수 있습니다.
  • 모든 임계값은 인스턴스 수준에서 계산됩니다. 예를 들어 "인스턴스 수가 2일 때 평균 CPU가 80% >인 경우 한 인스턴스씩 스케일 아웃합니다." 이는 모든 인스턴스의 평균 CPU가 80%를 초과하는 경우 스케일 아웃을 의미합니다.
  • 모든 자동 스케일링 실패는 활동 로그에 기록됩니다. 그런 다음, 자동 스케일링 오류가 있을 때마다 메일, SMS 또는 웹후크를 통해 알림을 받을 수 있도록 활동 로그 경고를 구성할 수 있습니다.
  • 마찬가지로, 모든 성공한 스케일링 작업도 활동 로그에 게시됩니다. 다음으로, 성공적인 자동 스케일링 작업이 있을 때마다 메일, SMS 또는 웹후크를 통해 알림을 받을 수 있도록 활동 로그 경고를 구성할 수 있습니다. 또한 크기 조정 설정의 알림 탭을 통해 성공적인 크기 조정 작업에 대한 알림을 받도록 전자 메일 또는 웹후크 알림을 구성할 수도 있습니다.

3. Auto Scaling 모범 사례

4. 참고 문서

Azure 메세지 서비스

. 개요

  • 이벤트 메세지를 전달하는 Azure 서비스로는 크게 Azure Event Grid, Azure Event Hubs, Azure Service Bus 및 Azure Relay 4가지가 있다.

2. Azure Event Grid

3. Azure Event Hub

  • Azure Event Hubs는 짧은 대기 시간으로 어떤 원본에서 어떤 대상으로든 초당 수백만 개의 이벤트를 스트리밍할 수 있는 클라우드의 네이티브 데이터 스트리밍 서비스입니다. Event Hubs는 Apache Kafka와 호환됩니다. 코드 변경 없이 기존 Kafka 워크로드를 실행할 수 있습니다.
  • Event Hubs는 Azure를 기반으로 빌드하는 모든 이벤트 스트리밍 솔루션의 기본 이벤트 수집 계층입니다. Azure 내부 및 외부의 데이터 및 분석 서비스와 통합되어 다음과 같은 사용 사례를 제공하는 완전한 데이터 스트리밍 파이프라인을 빌드합니다.
  • Event Hubs는 AMQP(고급 메시지 큐 프로토콜), Apache Kafka 및 HTTPS 프로토콜을 기본적으로 지원하는 다중 프로토콜 이벤트 스트리밍 엔진입니다. Apache Kafka를 지원하므로 코드를 변경하지 않고도 Kafka 워크로드를 Event Hubs로 가져올 수 있습니다. 직접 Kafka 클러스터를 설정, 구성 또는 관리할 필요가 없고, Azure에 기본 제공되지 않는 Kafka-as-a-Service 제품을 사용할 필요도 없습니다.
  • Event Hubs의 Azure 스키마 레지스트리는 이벤트 스트리밍 애플리케이션의 스키마를 관리하기 위한 중앙 집중식 리포지토리를 제공합니다. 스키마 레지스트리는 모든 Event Hubs 네임스페이스와 함께 무료로 제공됩니다. 스키마 레지스트리는 Kafka 애플리케이션 또는 Event Hubs SDK 기반 애플리케이션과 통합됩니다.
  • Event Hubs는 Azure Stream Analytics와 통합하여 실시간 스트림 처리를 지원합니다. 기본 제공 노코드 편집기를 사용하면 코드를 작성하지 않고도 끌어서 놓기 기능으로 Stream Analytics 작업을 개발할 수 있습니다.
  • Azure Data Explorer는 고성능을 제공하고 거의 실시간으로 대량의 데이터를 분석할 수 있는 빅 데이터 분석을 위한 완전 관리형 플랫폼입니다. Event Hubs를 Azure Data Explorer와 통합하면 스트리밍 데이터의 거의 실시간 분석 및 탐색을 수행할 수 있습니다.
  • Event Hubs를 사용하면 실시간으로 스트림을 수집, 버퍼링, 저장, 처리하여 실행 가능한 인사이트를 얻을 수 있습니다. Event Hubs는 분할된 소비자 모델을 사용합니다. Event Hubs를 사용하여 여러 애플리케이션에서 스트림을 동시에 처리할 수 있으며 처리 속도를 제어할 수 있습니다. 또한 Event Hubs를 Azure Functions와 통합하여 서버리스 아키텍처를 구현할 수 있습니다.
  • 이벤트 허브 상세 정보 링크 : https://learn.microsoft.com/ko-kr/azure/event-hubs/event-hubs-about

4. Azure Service Bus

  • Azure Service Bus는 메시지 큐와 게시-구독 토픽이 있는 완전 관리형 엔터프라이즈 메시지 브로커입니다. Service Bus는 애플리케이션과 서비스를 서로 분리하는 데 사용되며, 다음과 같은 이점을 제공합니다.
      - 경쟁하는 작업자 간에 작업 부하 분산
      - 서비스 및 애플리케이션 경계에서 데이터 및 제어를 안전하게 라우팅하고 전송
      - 높은 수준의 안정성이 필요한 트랜잭션 작업 조정
  • 서비스 버스 상세 정보 링크 : https://learn.microsoft.com/ko-kr/azure/event-hubs/azure-event-hubs-apache-kafka-overview

5. Azure Relay

  • Azure Relay 서비스를 사용하면 회사 네트워크에서 실행되는 서비스를 퍼블릭 클라우드에 안전하게 공개할 수 있습니다. 방화벽에서 포트를 열거나 회사 네트워크 인프라를 강제로 변경하지 않고도 이 작업을 수행할 수 있습니다.
  • 데이터 전송 패턴은 다음과 같습니다
    1. 온-프레미스 서비스에서 아웃바운드 포트를 통해 릴레이 서비스에 연결합니다.
    2. 특정 주소에 연결된 통신용 양방향 소켓을 만듭니다.
    3. 다음으로, 클라이언트에서 해당 주소를 대상으로 하는 릴레이 서비스에 트래픽을 전송하여 온-프레미스 서비스와 통신할 수 있습니다.
    4. 그런 다음, 릴레이 서비스에서 클라이언트 전용 양방향 소켓을 통해 온-프레미스 서비스에 데이터를 릴레이합니다. 클라이언트는 온-프레미스 서비스에 직접 연결할 필요가 없습니다. 즉 서비스의 위치를 인식할 필요가 없습니다. 그리고 온-프레미스 서비스는 방화벽에서 인바운드 포트를 열 필요가 없습니다.
  • 릴레이 상세 정보 링크 : https://learn.microsoft.com/ko-kr/azure/azure-relay/relay-what-is-it

6. 참고 문서

AKS AutoScaling에 대한 이해

1. AKS node pool 개념

  • Azure Kubernetes Service(AKS)에서 Node Pool이란 Kubernetes 클러스터에서 컨테이너화된 애플리케이션을 실행하는 가상 머신들을 그룹화하여 관리하는 집합입니다. 노드 풀은 크게 시스템 노드 풀과 사용자 노드 풀로 나뉘는데, 시스템 노드 풀은 CoreDNS 및 metrics-server와 같은 중요 시스템 Pod를 호스트하는 기본 목적을 제공합니다. 사용자 노드 풀의 기본 목적은 애플리케이션 Pod를 호스트하는 것입니다. 하지만 AKS 클러스터에 풀을 하나만 포함하려는 경우 시스템 노드 풀에 애플리케이션 Pod를 예약할 수 있습니다. 모든 AKS 클러스터에는 노드가 두 개 이상 있는 시스템 노드 풀이 하나 이상 포함되어야 합니다.

2. AKS Node Pool의 자동 크기 조정 원리 - VMSS 자동 크기 조정 + Kubernetes Horizontal Pod Autoscaling

  • 기본적으로 노드 풀 설정 시 스케일링 방법을 설정할 수 있는데, 자동 크기 조정과 수동 방식 두가지가 있으며, 자동 크기 조정의 경우에는 최소 노드 갯수, 최대 노드 갯수를 지정하여 배포할 노드 수량의 범위를 설정합니다
  • AKS의 AutoScaling  원리는 기본적으로 VMSS AutoScaling 규칙에 기반하여 동작합니다. VMSS AutoScaling은 기본적으로 호스트 메트릭(CPU 사용량, 메모리 사용량)과 일정 혹은 규칙을 기반으로 자동 크기 조정 프로필을 갱신하여 VM 갯수를 관리하나, AKS에서는 이와 더불어 리소스 사용량 및 파드의 스케줄링 요구를 기반으로 노드를 자동으로 추가하거나 제거합니다.
  • 즉 Node Pool의 AutoScaling에 핵심 원리는  Horizontal Pod Autoscaling 이다. 각 주기마다, 컨트롤러 매니저는 각 HorizontalPodAutoscaler 정의에 지정된 메트릭에 대해 리소스 사용률을 질의하여  HorizontalPodAutoscaler가 대상으로 하는 각 파드에 대한 리소스 메트릭 API에서 메트릭을 가져온다. 그런 다음, 목표 사용률 값이 설정되면, 컨트롤러는 각 파드의 컨테이너에 대한 동등한 자원 요청을 퍼센트 단위로 하여 사용률 값을 계산한다. 대상 원시 값이 설정된 경우 원시 메트릭 값이 직접 사용된다. 그리고, 컨트롤러는 모든 대상 파드에서 사용된 사용률의 평균 또는 원시 값(지정된 대상 유형에 따라 다름)을 가져와서 원하는 레플리카의 개수를 스케일하는데 사용되는 비율을 생성한다.
  • AKS에서도 Virtual Machine Scale Sets (VMSS)를 이용하여 워커 노드 자동 크기 조정(오토스케일링)을 할 수 있는데, 클러스터 자동 크기 조정 기능을 활성화하고 노드 풀의 최소 및 최대 노드 수를 설정해야 합니다. 클러스터 자동 크기 조정기는 노드 풀의 노드 수를 자동으로 조정하여 워크로드의 요구 사항을 충족하지만, 노드 풀 크기를 직접 조작하는 것은 권장하지 앟기 때문에 HPA (Horizontal Pod Autoscaler)와 결합하여 사용한다.
  • AKS에서는 클러스터 전체 자동 크기 조정기 프로필의 기본값을 변경하여 클러스터 자동 크기 조정기의 세부 정보를 구성할 수 있습니다. 예를 들어 10분 후 노드 사용량이 저조하면 스케일 다운 이벤트가 발생합니다. 15분마다 실행되는 워크로드가 있는 경우 15분 또는 20분 후에 사용량이 저조한 노드를 스케일 다운하도록 자동 크기 조정기 프로필을 변경할 수 있습니다. 클러스터 자동 크기 조정기를 사용하도록 설정하면 다른 설정을 지정하지 않는 한 기본 프로필이 사용되며, 노드 풀별로 자동 크기 조정기 프로필을 설정할 수는 없습니다.
  • HPA 설정
    - kubectl autoscale deployment <디플로이먼트명> --cpu-percent=<목표 CPU 사용률> --min=<최소 파드 수> --max=<최대 파드 수>
  • Node Autoscaler (Cluster Autoscaler)
    - Node Pool 단위로 활성화 (--enable-cluster-autoscaler)
  • 프로필 설정 상세 내용
    설정 설명 기본값
    scan-interval 스케일 업 또는 다운을 위해 클러스터를 다시 평가하는 빈도입니다. 10초
    scale-down-delay-after-add 스케일 업 후 스케일 다운 평가가 다시 시작되기 전까지의 경과 시간입니다. 10분
    scale-down-delay-after-delete 노드 삭제 후 스케일 다운 평가가 다시 시작되기 전까지의 경과 시간입니다. scan-interval
    scale-down-delay-after-failure 스케일 다운 실패 후 스케일 다운 평가가 다시 시작되기 전까지의 경과 시간입니다. 3분
    scale-down-unneeded-time 불필요한 노드를 스케일 다운하기 전까지의 경과 시간입니다. 10분
    scale-down-unready-time 준비되지 않은 노드를 스케일 다운하기 전까지의 경과 시간입니다. 20분
    ignore-daemonsets-utilization 스케일 다운에 대한 리소스 사용률을 계산할 때 DaemonSet Pod가 무시되는지 여부입니다. false
    daemonset-eviction-for-empty-nodes DaemonSet Pod가 빈 노드에서 정상적으로 종료되는지 여부입니다. false
    daemonset-eviction-for-occupied-nodes DaemonSet Pod가 비어있지 않은 노드에서 정상적으로 종료되는지 여부입니다. true
    scale-down-utilization-threshold 요청된 리소스의 합계를 용량으로 나눈 노드 사용률 수준으로, 이 수준의 노드는 스케일 다운 대상으로 고려할 수 있습니다. 0.5
    max-graceful-termination-sec 노드를 스케일 다운하려고 할 때 클러스터 자동 크기 조정기가 Pod 종료를 위해 대기하는 최대 시간(초) 600초
    balance-similar-node-groups 비슷한 노드 풀을 검색하고 두 노드 풀의 노드 수를 균형 있게 조정합니다. false
    expander 스케일 업에 사용하는 노드 풀 확장기의 유형입니다. 가능한 값은 most-pods, random, least-waste 및 priority입니다. random
    skip-nodes-with-local-storage true인 경우 클러스터 자동 크기 조정기는 로컬 스토리지가 포함된 Pod가 있는 노드를 삭제하지 않습니다(예: EmptyDir 또는 HostPath). false
    skip-nodes-with-system-pods true인 경우 클러스터 자동 크기 조정기는 kube-system에서 Pod가 있는 노드를 삭제하지 않습니다(DaemonSet 또는 미러 Pod 제외). true
    max-empty-bulk-delete 동시에 삭제할 수 있는 빈 노드의 최대 수입니다. 10개 노드
    new-pod-scale-up-delay Kubernetes 스케줄러가 모든 Pod를 예약하기 전에 CA가 작동하지 않도록 하려는 버스트/일괄 처리 규모와 같은 시나리오의 경우, 어느 정도 시간이 지나기 전에 예약되지 않은 Pod를 CA가 무시하도록 지시할 수 있습니다. 0초
    max-total-unready-percentage 클러스터에서 준비되지 않은 노드의 최대 비율입니다. 이 비율을 초과하면 CA가 작업을 중단합니다. 45%
    max-node-provision-time 노드가 프로비전될 때까지 자동 크기 조정기가 대기하는 최대 시간입니다. 15분
    ok-total-unready-count max-total-unready-percentage에 관계없이 준비되지 않은 노드가 허용되는 수입니다. 노드 3개
  • 설정 예시 
    az aks nodepool add \
    --resource-group $RESOURCE_GROUP_NAME \
    --cluster-name $CLUSTER_NAME \
    --os-type Windows \
    --name $CONTAINER_D_NODE_POOL_NAME \
    --node-vm-size Standard_D4s_v3 \
    --kubernetes-version 1.20.5 \
    --aks-custom-headers WindowsContainerRuntime=containerd \
    --node-count 1​

3. 참고 문서

GitHub Actions 워크플로 이해 및 Secret 사용 모범 규약

. Github Actions 란?

 => GitHub Actions는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD(연속 통합 및 지속적인 업데이트) 플랫폼입니다. 리포지토리에 변경 내용을 푸시할 때마다 테스트를 실행하거나 병합된 pull request를 프로덕션에 배포하는 워크플로를 만들 수 있습니다.

 

2. 구성

 => 끌어오기 요청이 열리거나 이슈가 생성되는 것과 같은 ‘이벤트’가 리포지토리에서 발생할 때 트리거되도록 GitHub Actions ‘워크플로’를 구성할 수 있습니다. 워크플로는 순차적 또는 병렬로 실행될 수 있는 ‘작업’을 하나 이상 포함합니다. 각 작업은 자체 가상 머신 ‘실행기’ 또는 컨테이너 내에서 실행되며, 정의한 스크립트를 실행하거나 워크플로를 간소화할 수 있는 재사용 가능한 확장인 ‘작업’을 실행하는 ‘단계’를 하나 이상 포함합니다. 

 

3. Workflow 란?

=> 워크플로는 하나 이상의 작업을 실행할 구성 가능한 자동화된 프로세스입니다. 워크플로는 리포지토리에 체크 인된 YAML 파일에서 정의되며, 리포지토리의 이벤트로 트리거될 때 실행되거나 수동으로 또는 정의된 일정에 따라 트리거될 수 있습니다.

워크플로는 리포지토리의 .github/workflows 디렉터리에 정의됩니다. 리포지토리에 다음과 같은 각각의 다른 작업 집합을 수행하는 여러 워크플로가 있을 수 있습니다.

  • 끌어오기 요청을 빌드하고 테스트합니다.
  • 릴리스가 생성될 때마다 애플리케이션을 배포합니다.
  • 새 문제가 보고될 때마다 레이블을 추가합니다.

워크플로를 자동으로 트리거하려면 를 사용하여 on워크플로를 실행할 수 있는 이벤트를 정의합니다. 구체적인 구문 링크는 아래를 참고하시기 바랍니다.

 

4. 이벤트

  • 이벤트는 워크플로 실행을 트리거하는 리포지토리의 특정 활동입니다. 예를 들어 누군가가 끌어오기 요청을 만들거나, 이슈를 열거나, 리포지토리에 커밋을 푸시할 때 GitHub에서 활동이 시작될 수 있습니다. 일정에 따라 REST API에 게시하여 또는 수동으로 실행되도록 워크플로를 트리거할 수 있습니다.
  • 주요 이벤트 트리거 커맨드
    • push: 브랜치 또는 태그에 변경 사항이 푸시될 때 트리거됩니다. 특정 파일 또는 폴더 변경에 따라 트리거를 제한하려면 paths 옵션을 사용할 수 있습니다. 
    • pull_request: 풀 리퀘스트가 생성, 업데이트 또는 닫힐 때 트리거됩니다.
    • workflow_dispatch: 사용자가 GitHub UI에서 워크플로우를 수동으로 실행할 때 트리거됩니다.
    • schedule: 지정된 cron 표현식에 따라 트리거됩니다. 예를 들어, 매일 자정에 실행되도록 설정할 수 있습니다.
    • release: 릴리즈가 생성, 업데이트 또는 삭제될 때 트리거됩니다. 
    • issues: 이슈가 생성, 업데이트 또는 닫힐 때 트리거됩니다.
    • pull_request_target: 풀 리퀘스트의 타겟 브랜치에 대한 변경 사항이 발생할 때 트리거됩니다.

5. Secret 설정

  • 리포지토리 소유자만 개인 계정 리포지토리의 GitHub에 비밀 또는 변수를 만들 수 있습니다. GitHub에서 조직 리포지토리의 비밀이나 변수를 생성하려면 admin 액세스 권한이 있어야 합니다. 마지막으로, 협력자 액세스 권한이 있는 사용자만 REST API를 통해 개인 계정 리포지토리 또는 조직 리포지토리에 대한 비밀 또는 변수를 만들 수 있습니다.
  • 조직에서 비밀 또는 변수를 만들 때, 정책을 사용하여 리포지토리별로 액세스를 제한할 수 있습니다. 예를 들어 모든 리포지토리에 대한 액세스 권한을 부여하거나 프라이빗 리포지토리 또는 지정된 리포지토리 목록에 대해서만 액세스를 제한할 수 있습니다
  • 비밀 설정 관련 모범 사례
    • 최소 권한의 원칙
      • 저장소에 대한 쓰기 권한이 있는 모든 사용자는 저장소에 구성된 모든 비밀에 대한 읽기 권한을 갖습니다. 따라서 워크플로 내에서 사용되는 자격 증명에 필요한 최소한의 권한만 부여해야 합니다.
      • GITHUB_TOKEN작업은 컨텍스트 에서 에 액세스하여 을 사용할 수 있습니다 github.token. 자세한 내용은 컨텍스트 참조를GITHUB_TOKEN 참조하세요. 따라서 에 필요한 최소 권한이 부여되었는지 확인해야 합니다. 의 기본 권한을 저장소 콘텐츠에 대한 읽기 전용 권한으로 설정하는 것이 보안에 좋습니다. 그런 다음 필요에 따라 워크플로 파일 내의 개별 작업에 대한 권한을 늘릴 수 있습니다. 
    • 민감한 데이터 마스크
      • 민감한 데이터는 워크플로 파일에 일반 텍스트로 저장해서는 안 됩니다 . GitHub 비밀이 아닌 모든 민감한 정보는 ::add-mask::VALUE. 를 사용하여 마스크 처리하세요. 이렇게 하면 해당 값이 비밀로 처리되어 로그에서 삭제됩니다. 
    • 노출된 비밀 삭제 및 회전
      • 비밀 삭제는 워크플로 실행기에서 수행합니다. 즉, 작업 내에서 사용되었고 실행기가 액세스할 수 있는 비밀만 삭제됩니다. 삭제되지 않은 비밀이 워크플로 실행 로그로 전송된 경우, 로그를 삭제하고 해당 비밀을 순환해야 합니다. 
    • 구조화된 데이터를 비밀로 사용하지 마십시오
      • 구조화된 데이터는 로그 내 비밀 삭제가 실패하게 만들 수 있습니다. 삭제는 주로 특정 비밀 값과 정확히 일치하는 항목을 찾는 데 의존하기 때문입니다. 예를 들어, JSON, XML 또는 YAML(또는 유사한 형식)의 blob을 사용하여 비밀 값을 캡슐화하지 마십시오. 이렇게 하면 비밀이 제대로 삭제될 가능성이 크게 낮아집니다. 대신, 각 민감한 값에 대해 개별 비밀을 생성하십시오.
    • 워크플로 내에서 사용되는 모든 비밀을 등록합니다.
      • 워크플로 내에서 다른 민감한 값을 생성하는 데 비밀을 사용하는 경우, 생성된 값은 공식적으로 비밀로 등록 해야 로그에 기록될 경우 삭제됩니다. 예를 들어, 웹 API에 액세스하기 위해 개인 키를 사용하여 서명된 JWT를 생성하는 경우, 해당 JWT를 비밀로 등록해야 로그 출력에 기록될 경우 삭제되지 않습니다.
      • 비밀 등록은 모든 종류의 변환/인코딩에도 적용됩니다. 비밀이 Base64 또는 URL 인코딩 등 어떤 방식으로든 변환된 경우, 새 값도 비밀로 등록해야 합니다.
    • 비밀이 어떻게 처리되는지 감사
      • 비밀이 어떻게 사용되는지 감사하여 예상대로 처리되는지 확인하세요. 워크플로를 실행하는 저장소의 소스 코드를 검토하고 워크플로에서 사용되는 모든 작업을 확인하여 이를 수행할 수 있습니다. 예를 들어, 의도하지 않은 호스트로 전송되거나 로그 출력에 명시적으로 출력되지 않는지 확인하세요.
      • 유효/유효하지 않은 입력을 테스트한 후 워크플로 실행 로그를 확인하고, 비밀이 제대로 삭제되었는지 또는 표시되지 않았는지 확인하세요. 호출하는 명령이나 도구가 어떻게 오류를 STDOUT및 로 보내는지 항상 명확하게 알 수 있는 것은 아니며 STDERR, 결과적으로 비밀이 오류 로그에 기록될 수도 있습니다. 따라서 유효 및 유효하지 않은 입력을 테스트한 후 워크플로 로그를 수동으로 검토하는 것이 좋습니다. 
    • 등록된 비밀 감사 및 순환
      • 등록된 비밀번호를 정기적으로 검토하여 여전히 필요한지 확인하세요. 더 이상 필요하지 않은 비밀번호는 제거하세요.
      • 손상된 비밀이 유효한 시간 창을 줄이려면 비밀을 주기적으로 교체하세요.
    • 비밀에 대한 접근에 대한 검토를 요구하는 것을 고려하세요
      • 필수 검토자를 사용하여 환경 비밀을 보호할 수 있습니다. 워크플로 작업은 검토자의 승인을 받을 때까지 환경 비밀에 액세스할 수 없습니다. 

5. 참고 문서

Azure Data Platform 이해 및 서비스 개요

1. Azure Data Platform 이란?

  • Azure 데이터 플랫폼은 데이터베이스, 데이터 저장 및 분석을 위한 다양한 데이터 서비스를 제공하며, 다양한 작업에 Azure Virtual Machine 을 활용합니다 . Azure 스택의 모든 요소를 포함합니다. 이 플랫폼을 사용하면 모든 데이터에 대한 단일 진실 소스를 구축하거나 BI, 보고 AI/ML, 실시간 분석과 같은 혁신적인 솔루션을 스트리밍할 수 있는 기반 제품입니다.

 

2. 이점

  • 확장성 및 탄력성: Azure Data Platform은 변화하는 데이터 수요에 맞춰 쉽게 확장하거나 축소할 수 있습니다.
  • 비용 효율성: 사용량에 따라 비용을 지불하는 가격 모델을 사용하면 사용량에 따라 비용을 최적화할 수 있습니다.
  • 보안 및 규정 준수: Azure는 강력한 보안 기능과 규정 준수 인증을 제공하여 데이터를 보호합니다.
  • 다른 Azure 서비스와의 통합: 데이터 시각화를 위한 Power BI, 고급 분석을 위한 AI 서비스 등 다른 Azure 서비스와 원
    게 통합됩니다. 
  • 운영 부담 감소: 완전 관리형 서비스는 인프라 관리를 담당하므로 고객은 핵심 사업에 집중할 수 있습니다. 
  • 더 빠른 통찰력 확보 시간: 빠른 데이터 처리, 분석, 시각화를 위한 도구와 서비스를 제공하여 통찰력을 얻는 시간을 단축합니다. 

3. 사용사례

  • 실시간 분석: 사기 감지, 이상 감지 및 개인화된 추천을 위해 데이터 스트림을 분석합니다.
  • 데이터 웨어하우징 및 비즈니스 인텔리전스: 데이터웨어하우스를 구축하고 데이터 기반 의사 결정을 위한 대화형 대시보드를 만듭니다. 
  • AI와 머신 러닝: 이미지 인식, 자연어 처리, 예측 분석 등 다양한 애플리케이션을 위한 머신 러닝 모델을 개발하고 배포합니다. 
  • 데이터 통합 및 마이그레이션: 다양한 소스의 데이터를 통합하고 기존 온프레미스 데이터를 클라우드로 마이그레이션합니다. 
  • 사물 인터넷(IoT) 솔루션: IoT 기기의 데이터를 처리하고 분석하여 실시간 통찰력과 자동화를 제공합니다.
 

4. Azure Data Platform 서비스 특징

서비스명 특징
Azure Data Factory Data Factory는 디지털 혁신 이니셔티브 전체에서 작동하는 데이터 통합과 혁신 계층을 제공하는 서버리스 완전 관리형 서비스입니다. 기술 지식이 없는 통합 사용자와 데이터 엔지니어가 비즈니스 및 IT 주도의 분석/BI를 추진할 수 있는 역량을 갖추었습니다. 데이터를 준비하고, ETL 및 ELT 프로세스를 생성하고, 코드 없이 파이프라인을 오케스트레이션 및 모니터링합니다. 관리형 Apache Spark™ 서비스가 코드 생성 및 유지 관리를 처리합니다. 복사 작업을 자동화하는 지능형 의도 기반 매핑을 사용하여 더 빠르게 변환합니다.
Azure Event Hubs Azure Event Hubs는 짧은 대기 시간으로 어떤 원본에서 어떤 대상으로든 초당 수백만 개의 이벤트를 스트리밍할 수 있는 클라우드의 네이티브 데이터 스트리밍 서비스입니다. Event Hubs는 Apache Kafka와 호환됩니다. 코드 변경 없이 기존 Kafka 워크로드를 실행할 수 있습니다.
Azure Data Lake Storage Azure Data Lake Storage는 Azure Blob Storage를 기준으로 하는 빅 데이터 분석 전용 기능 세트입니다. 데이터 레이크는 정형 및 비정형의 모든 데이터를 저장할 수 있는 단일 중앙 리포지토리입니다. 조직에서는 데이터 레이크를 사용하여 단일 위치에서 다양한 데이터를 빠르고 쉽게 저장하고 액세스하고 분석할 수 있습니다. 데이터 레이크를 사용하면 기존 구조에 맞게 데이터를 구성할 필요가 없습니다. 대신 데이터를 일반적으로 파일 또는 Blob(Binary Large Object)에 해당하는 원시 또는 네이티브 형식으로 저장할 수 있습니다.
Azure Data Lake Storage는 클라우드 기반 엔터프라이즈 데이터 레이크 솔루션입니다. 이 솔루션은 모든 형식으로 대량의 데이터를 저장하고 빅 데이터 분석 워크로드를 용이하게 하도록 설계되었습니다. 다양한 프레임워크를 사용하여 쉽게 액세스 및 분석할 수 있도록 단일 위치에서 모든 형식과 수집 속도의 데이터를 캡처하는 데 사용합니다.
Azure Data Lake Storage는 전용 서비스 또는 계정 유형이 아닙니다. 대신 Azure Storage 계정의 Blob Storage 서비스와 함께 사용하는 기능 집합으로 구현됩니다. 계층 구조 네임스페이스 설정을 사용하도록 설정하여 이러한 기능을 잠금 해제할 수 있습니다.
기본적으로 Apache HDFS(Hadoop 분산 파일 시스템)를 데이터 액세스 계층으로 사용하는 모든 프레임워크에서 사용할 수 있도록 설계되어, 빅데이터 분석에 최적화되어있는 서비스입니다.
Azure Cosmos DataBase Azure Cosmos DB는 지역 복제 분산 캐싱에서 백업 스토리지, 벡터 인덱싱 및 검색에 이르기까지 운영 데이터 요구 사항에 대한 단일 데이터베이스가 됨으로써 애플리케이션 개발을 간소화하고 신속하게 처리합니다. 또한 AI 에이전트, 디지털 상거래, 사물 인터넷 및 예약 관리와 같은 최신 애플리케이션을 위한 데이터 인프라를 제공합니다. 관계형, 문서, 벡터, 키-값, 그래프 및 테이블을 비롯한 모든 운영 데이터 모델을 수용할 수도 있습니다. 
반복 개발을 위한 유연한 스키마, 대기 시간이 중요한 워크로드, 매우 탄력적인 워크로드(콘서트 티켓 예약 서비스), 높은 처리량 워크로드(원격 장비 상태 분석), 고가용성 중요 업무용 워크로드(web App)에 적합합니다.
Azure Data Warehouse 데이터 웨어하우스는 보고 및 분석을 위해 정형 데이터(데이터베이스 테이블, Excel 시트) 및 반정형 데이터(XML 파일, 웹 페이지)를 저장하는 중앙 집중식 리포지토리입니다. 데이터는 POS(Point-Of-Sale) 시스템, 비즈니스 응용 프로그램 및 관계형 데이터베이스와 같은 다양한 원본에서 수집되며, 일반적으로 웨어하우스에 도달하기 전에 정리 및 표준화됩니다. 데이터 웨어하우스는 많은 양의 정보를 저장할 수 있으므로 데이터 웨어하우스를 사용하면 데이터 마이닝, 데이터 시각화 및 기타 형태의 비즈니스 인텔리전스 보고에 사용할 수 있는 다양한 기록 데이터에 쉽게 액세스할 수 있습니다.
Azure Stream Analytics Azure Stream Analytics는 대기 시간이 밀리초 미만인 대용량 스트리밍 데이터를 분석 및 처리하도록 설계된 완전 관리 스트림 처리 엔진입니다. Stream Analytics를 사용하여 스트리밍 데이터 파이프라인을 빌드하여 애플리케이션, 디바이스, 센서, 클릭스트림 및 소셜 미디어 피드를 비롯한 다양한 입력 원본에서 발생하는 데이터의 패턴과 관계를 식별할 수 있습니다. 그런 다음 이러한 패턴을 사용하여 작업을 트리거하고 경고 발생, 보고 도구에 정보 제공, 나중에 사용하기 위해 변환된 데이터 저장 등의 워크플로를 시작할 수 있습니다. Stream Analytics는 IoT 디바이스에서 직접 데이터를 처리할 수 있도록 하는 Azure IoT Edge 런타임에서도 사용할 수 있습니다.
급증, 하락, 느린 긍정적 및 부정적 변화를 검색하기 위한 센서 데이터의 이상 탐지, fleet 관리 및 드라이버가 없는 자동차에 대한 지리 공간적 분석, 원격 모니터링 및 높은 가치 자산의 예측 유지 관리, 스트림 분석을 클릭하여 고객 동작 확인, 애플리케이션 및 IoT 디바이스의 실시간 원격 분석 스트림 및 로그 분석에 주로 사용됩니다.
Azure Synapse Analytics Azure Synapse는 데이터 웨어하우스와 빅 데이터 시스템 전체에서 인사이트를 얻는 시간을 앞당길 수 있는 엔터프라이즈 분석 서비스입니다. Azure Synapse는 엔터프라이즈 데이터 웨어하우징에 사용되는 최고의 SQL 기술, 빅 데이터에 사용되는 Spark 기술, 로그 및 시계열 분석을 위한 Data Explorer, 데이터 통합 및 ETL/ELT를 위한 파이프라인, Power BI, CosmosDB 및 AzureML과 같은 Azure 서비스와의 긴밀한 통합을 결합합니다.
Azure AI Search Azure AI Search는 다른 유형의 콘텐츠를 인덱싱하고 API, 애플리케이션 및 AI 에이전트를 통해 검색할 수 있도록 하는 확장 가능한 검색 인프라입니다. 이 플랫폼은 Azure의 AI 스택(OpenAI, AI Foundry, Machine Learning)과 네이티브 통합을 제공하고 타사 및 오픈 소스 모델 통합을 위한 확장 가능한 아키텍처를 지원합니다.
이 서비스는 대화형 AI 애플리케이션에 대한 기존 검색 워크로드와 최신 RAG(검색 보강 세대) 패턴을 모두 처리합니다. 따라서 채팅 완성 모델을 통해 동적 콘텐츠 생성이 필요한 AI 기반 고객 환경뿐만 아니라 엔터프라이즈 검색 시나리오에도 적합합니다.
Azure Databricks Azure Databricks는 엔터프라이즈급 데이터, 분석 및 AI 솔루션을 대규모로 빌드, 배포, 공유 및 유지 관리하기 위한 통합된 개방형 분석 플랫폼입니다. Databricks Data Intelligence 플랫폼은 클라우드 계정의 클라우드 스토리지 및 보안과 통합되며, 클라우드 인프라를 관리하고 배포합니다. 엔터프라이즈 데이터 레이크하우스 빌드, ETL 및 데이터 엔지니어링, 기계 학습, AI 및 데이터 과학, 대규모 언어 모델 및 생성 AI, 데이터 웨어하우징, 분석 및 BI, 데이터 거버넌스 및 보안 데이터 공유, DevOps, CI/CD 및 작업 오케스트레이션, 실시간 및 스트리밍 분석 에 주로 사용됩니다.
Azure Machine Learning Azure Machine Learning은 ML(기계 학습) 프로젝트 수명 주기를 가속화하고 간편하게 관리할 수 있는 클라우드 서비스입니다. ML 전문가, 데이터 과학자 및 엔지니어는 일상적인 워크플로에서 이를 사용하여 모델을 학습 및 배포하고 MLOps(기계 학습 운영)를 관리할 수 있습니다.
Machine Learning에서 모델을 만들 수도 있고 PyTorch, TensorFlow 또는 scikit-learn과 같은 오픈 소스 플랫폼에서 빌드된 모델을 사용할 수도 있습니다. MLOps 도구를 사용하여 모델을 모니터링, 재학습 및 재배포할 수 있습니다.
Azure Machine Learning에는 LLM(대규모 언어 모델)에서 제공하는 생성형 AI 애플리케이션을 빌드하는 데 도움이 되는 도구가 포함되어 있습니다. 솔루션에는 모델 카탈로그, 프롬프트 흐름 및 AI 애플리케이션의 개발 주기를 간소화하는 도구의 모음이 포함되어 있으며, Azure Machine Learning 스튜디오 및 Azure AI Foundry를 모두 사용하여 LLM을 사용할 수 있습니다. 

 

5. 참고 문서

Azure 구독 및 관리 그룹에 대하여

1. Azure의 계층 구조 이해

  • Microsoft Azure는 클라우드 리소스를 효과적으로 구성하고 관리하기 위해 구조화된 계층 구조를 사용합니다. 이 계층 구조를 이해하는 것은 적절한 리소스 구성, 접근 제어, 비용 관리 및 거버넌스를 위해 매우 중요합니다. Azure계정은 기본적으로 "테넌트 > 관리 그룹 > 구독 > 리소스 그룹 > 리소스"와 같은 계층 구조로 리소스를 관리합니다. 


2. Azure 계정

  • 정의
    Azure 계정은 Azure 서비스와 구독에 접근할 수 있게 해주는 전 세계적으로 고유한 엔티티입니다. 이메일 주소와 연결되어 있으며 연락처 정보와 결제 세부 정보(신용 카드 정보 등)를 포함합니다.
  • 목적
    Azure 계정은 Microsoft와의 결제 관계를 수립하고 구독 내 리소스에서 발생하는 모든 비용을 지불할 책임이 있습니다.
  • 주요 사항
    - 하나의 Azure 계정으로 여러 구독을 관리할 수 있습니다
    - 계정 소유자는 계정 관리자로 간주됩니다
    - Azure 계정을 생성하면 첫 번째 구독도 함께 생성됩니다

3. Azure 테넌트(Microsoft Entra ID 테넌트)

  • 정의
    Azure 테넌트는 Microsoft 클라우드 서비스에 가입할 때 자동으로 생성되는 Microsoft EntraID(이전의 Azure Active Directory)의 전용 인스턴스로, 조직 구조의 최상위에 위치하며, ID 및 접근 관리 기능을 제공합니다.
  • 목적
    테넌트는 단일 조직을 나타내며 인증 및 권한 부여를 위한 보안 경계 역할을 합니다.
  • 주요 사항
     -  테넌트는 사용자, 그룹 및 애플리케이션이 포함된 자체 디렉터리를 가지고 있습니다
     - 하나의 테넌트는 여러 구독을 포함할 수 있습니다
     - 테넌트는 Microsoft Entra ID를 통해 ID와 접근 제어를 관리합니다
     - 여러 구독을 하나의 테넌트에 연결할 수 있습니다
     - 테넌트는 Azure 조직 구조의 최상위에 위치하며 ID 및 접근 관리 기능을 제공합니다.

4. 관리 그룹

  • 정의
    다수의 Azure 구독을 조직적이고 효율적으로 관리하기 위한 계층 구조입니다. 이를 통해 조직의 구조를 반영하여 구독을 그룹화하고, 정책 및 액세스 제어를 일괄적으로 적용할 수 있습니다
  • 목적
    기업의 조직 구조나 부서별로 구독을 그룹화하여 관리 효율성을 높이고(조직적 관리), 관리 그룹에 정책 및 권한을 할당하면 하위 관리 그룹, 구독 및 리소스 그룹에 상속되어 일관된 거버넌스를 유지하고(일관된 정책 및 엑세스 제어), 수백, 수천 개의 구독을 관리할 때 유연하고 확장 가능한 관리 체계를 제공(규모 확장성)합니다. 
  • 주요 사항
     - 하나의     디렉터리는 10,000개의 관리 그룹을 지원할 수 있습니다.
     - 관리 그룹 트리에서 지원할 수 있는 최대 깊이 수준은 6입니다. 이 제한에는 루트 수준 또는 구독 수준이 포함되지 않습니다.
     - 각 관리 그룹과 구독은 부모를 하나만 지원할 수 있습니다.
     - 각 관리 그룹에는 여러 자식 요소가 있을 수 있습니다.
     - 모든 구독 및 관리 그룹은 각 디렉터리의 단일 계층 내에 위치합니다 

5. Azure 구독

  • 정의
    Azure 구독은 Azure에서 리소스를 프로비저닝하는 데 사용되는 논리적 컨테이너입니다.Microsoft와의 법적 계약으로, Azure 서비스에 대한 접근을 제공합니다.
  • 목적
    구독은 Azure 리소스에 대한 결제 배열, 접근 제어 경계 및 규모 제한을 정의합니다.
  • 주요 사항
     - 각 구독은 하나의 테넌트와 연결됩니다
     - 구독은 결제 단위를 나타내며, 구독 내 모든 리소스는 함께 청구됩니다
     - 구독은 리소스에 대한 격리 경계를 제공합니다
     - 조직은 일반적으로 다양한 부서, 프로젝트 또는 환경(개발, 테스트, 프로덕션)에 대해 여러 구독을 생성합니다
     - 구독에는 리소스 사용에 대한 제한이 있습니다

6. 리소스 그룹

  • 정의
    리소스 그룹은 애플리케이션이나 솔루션을 위한 관련 Azure 리소스를 담는 논리적 컨테이너입니다.
  • 목적
    리소스 그룹은 리소스를 개별적으로 관리하는 대신 컬렉션으로 구성하고 관리하는 데 도움이됩니다.
  • 주요 사항
     - 모든 Azure 리소스는 정확히 하나의 리소스 그룹에 배치되어야 합니다.
     - 리소스 그룹은 다양한 지역의 리소스를 포함할 수 있습니다
     - 리소스는 한 번에 하나의 리소스 그룹에만 존재할 수 있습니다.
     - 하나의 리소스 그룹은 여러 리소스를 가질 수 있습니다.
     - 리소스 그룹은 중첩될 수 없습니다
     - 리소스 그룹에 작업을 적용하면 그 안에 포함된 모든 리소스에 적용됩니다
     - 리소스 그룹은 동일한 수명 주기를 공유하는 리소스를 그룹화하는 데 유용합니다

7. Azure 구독 및 그룹 관리에 대한 모범 사례

  • 관리 그룹을 사용하여 거버넌스 및 정책 상속을 위해 여러 구독을 그룹화한다.
  • 비즈니스 기능, 환경 또는 결제 요구 사항에 따라 논리적 구독을 생성한다.
  • 동일한 수명 주기를 공유하는 리소스를 중심으로 리소스 그룹을 설계한다.
  • 모든 계층 수준에서 일관된 명명 규칙을 적용한다.
  • 태그를 사용하여 리소스에 대한 추가 메타데이터를 제공한다.

8. 참고 문서

Flow Logs의 종류와 특징(Vnet Flow logs)

1. Azure Network Watcher란?

  • Azure Network Watcher는 메트릭을 모니터링, 진단, 확인하고 Azure IaaS(Infrastructure-as-a-Service) 리소스에 대한 로그를 사용 또는 사용하지 않도록 설정하는 도구 모음을 제공합니다.
  • Network Watcher를 사용하면 VM(가상 머신), VNet(가상 네트워크), 애플리케이션 게이트웨이, 부하 분산 장치 등과 같은 IaaS 제품의 네트워크 상태를 모니터링하고 복구할 수 있습니다.
  • 다만, Network Watcher는 PaaS 모니터링 또는 웹 분석용으로 설계되거나 의도되지 않았습니다.

2. 구성 및 종류

  • Network Watcher는 모니터링, 네트워크 진단 도구, 트래픽 세 가지 주요 도구 및 기능 집합으로 구성되며, 아래와 같습니다.
카테고리 서비스명 상세 설명
Monitoring Connection Monitor 연결 모니터 테스트는 TCP, ICMP, HTTP ping에 대한 패킷 손실 및 네트워크 지연 시간 지표를 집계하여 측정합니다. 통합 토폴로지는 종단 간 네트워크 경로를 시각화하고, 홉 성능 지표를 통해 네트워크 경로 홉을 강조 표시합니다. 연결 모니터는 문제의 근본 원인을 효율적으로 분석하고 해결할 수 있도록 실행 가능한 인사이트와 상세한 로그를 제공합니다
참조 링크 : https://learn.microsoft.com/en-us/azure/network-watcher/connection-monitor-overview
Topology 토폴로지는 Azure에서 여러 구독, 지역 및 리소스 그룹에 걸쳐 리소스와 리소스 간의 관계를 확인할 수 있는 대화형 인터페이스를 제공합니다. Azure Network Watcher 연결 모니터 및 트래픽 분석 에서 얻은 인사이트를 제공하는 대화형 그래픽 인터페이스를 통해 클라우드 네트워크 인프라를 관리하고 모니터링할 수 있습니다. 토폴로지는 연결 문제 해결 , 패킷 캡처 , 다음 홉 과 같은 Network Watcher 진단 도구에 대한 상황별 액세스를 제공하여 네트워크 문제를 진단하고 해결하는 데 도움을 줍니다 .
참조 링크 : https://learn.microsoft.com/en-us/azure/network-watcher/network-insights-topology
Network Diagnostic Tools

(https://learn.microsoft.com/en-us/azure/network-watcher/)		 NSG diagnostics NSG 진단은 Azure Network Watcher 도구로, Azure 가상 네트워크에서 허용 또는 거부되는 네트워크 트래픽을 파악하고 디버깅에 필요한 자세한 정보를 제공합니다. NSG 진단을 통해 네트워크 보안 그룹 규칙이 올바르게 설정되었는지 확인할 수 있습니다.
IP flow verify IP 흐름 확인은 Azure Network Watcher의 기능으로, 구성된 보안 및 관리 규칙에 따라 Azure 가상 머신에서 패킷이 허용 또는 거부되는지 확인하는 데 사용할 수 있습니다. 네트워크 보안 그룹(NSG) 규칙과 Azure Virtual Network Manager 관리 규칙을 확인하여 가상 머신 연결 문제를 해결하는 데 도움이 됩니다. 다른 Azure 리소스, 인터넷 및 온-프레미스 환경과의 연결 문제를 진단하는 빠르고 간단한 도구입니다
Effective security rules 효과적인 보안 규칙 보기는 Azure Network Watcher의 기능으로, 네트워크 인터페이스에 적용된 인바운드 및 아웃바운드 규칙을 집계하여 볼 수 있습니다. 네트워크 인터페이스에 적용된 보안 및 관리 규칙을 한눈에 볼 수 있습니다. 이 기능을 사용하여 연결 문제를 해결하고 Azure 네트워크 리소스의 보안 및 규정 준수를 감사할 수 있습니다.
Packet capture Azure Network Watcher 패킷 캡처를 사용하면 패킷 캡처 세션을 생성하여 가상 머신(VM) 또는 확장 집합 간의 트래픽을 추적할 수 있습니다. 패킷 캡처는 네트워크 이상을 사후 및 사전 예방적으로 진단하는 데 도움이 됩니다. 또한 네트워크 통계 수집, 네트워크 침입 정보 수집, 클라이언트-서버 통신 디버깅 등 다양한 용도로 활용할 수 있습니다.
VPN troubleshoot VM 네트워크 문제 해결사는 고객이 Azure 가상 머신에서 자주 사용되는 포트가 차단되었는지 빠르게 확인할 수 있도록 도와줍니다. VM 네트워크 문제 해결사는 NSG 진단 도구를 기반으로 구축되었습니다. 이 문제 해결사는 일반 포트에 대한 VM 트래픽을 시뮬레이션합니다. 흐름 허용 여부와 해당 흐름을 허용 또는 거부하는 보안 규칙에 대한 자세한 정보를 함께 제공합니다. 고객은 결과에서 NSG 규칙을 클릭하여 필요에 따라 수정할 수 있습니다.
Next hop 다음 홉은 Azure Network Watcher의 기능으로, 특정 대상 IP 주소의 다음 홉 유형 , IP 주소 , 경로 테이블 ID를 제공합니다 . 다음 홉 정보를 알면 트래픽이 의도한 대상으로 전송되는지 또는 전송이 중단되는지 확인하는 데 도움이 됩니다. 트래픽이 온프레미스 위치 또는 네트워크 가상 어플라이언스로 전송되는 부적절한 경로 구성은 연결 문제를 야기할 수 있습니다.
Connection troubleshoot 연결 문제 해결은 네트워크 보안 그룹, 사용자 정의 경로 및 차단된 포트와 관련된 문제를 감지하기 위해 모든 연결 주요 검사를 수행하는 포괄적인 방법을 제공하여 평균 해결 시간(MTTR)을 단축합니다. . 반환되는 결과는 연결 문제의 근본 원인과 플랫폼 문제인지 사용자 구성 문제인지에 대한 통찰력을 제공할 수 있습니다.
Traffic Vnet Flow Logs 가상 네트워크 흐름 로그는 Azure Network Watcher의 기능입니다. 가상 네트워크를 통과하는 IP 트래픽에 대한 정보를 기록하는 데 사용할 수 있습니다.
가상 네트워크 흐름 로그의 흐름 데이터는 Azure Storage로 전송됩니다. Azure Storage에서 데이터에 액세스하여 시각화 도구, 보안 정보 및 이벤트 관리(SIEM) 솔루션 또는 침입 탐지 시스템(IDS)으로 내보낼 수 있습니다. 가상 네트워크 흐름 로그는 네트워크 보안 그룹 흐름 로그 의 일부 한계를 극복합니다 .
NSG Flow Logs 네트워크 보안 그룹(NSG) 흐름 로깅은 Azure Network Watcher의 기능으로, 네트워크 보안 그룹을 통과하는 IP 트래픽에 대한 정보를 로깅할 수 있습니다 . 흐름 데이터는 Azure Storage로 전송되며, 여기에서 원하는 시각화 도구, 보안 정보 및 이벤트 관리(SIEM) 솔루션 또는 침입 탐지 시스템(IDS)으로 데이터를 내보내고 액세스할 수 있습니다.
Traffic analytics 트래픽 분석은 클라우드 네트워크의 사용자 및 애플리케이션 활동에 대한 가시성을 제공하는 클라우드 기반 솔루션입니다. 특히, 트래픽 분석은 Azure Network Watcher 흐름 로그를 분석하여 Azure 클라우드의 트래픽 흐름에 대한 통찰력을 제공합니다. 또한 원시 흐름 로그를 분석하고 로그 데이터를 보안, 토폴로지 및 지리적 정보와 결합합니다. 이를 통해 사용자 환경의 트래픽 흐름에 대한 통찰력을 제공합니다.

 

3. Vnet Flow Logs 의 장점(vs NSG Flow Logs) 및 특징 

  • 가상 네트워크 흐름 로그와 네트워크 보안 그룹 흐름 로그는 모두 IP 트래픽을 기록하지만 동작과 기능이 다릅니다.
  • 가상 네트워크 흐름 로그는 가상 네트워크 에서 로깅을 활성화할 수 있으므로 트래픽 모니터링 범위를 간소화합니다 . 가상 네트워크 내에서 지원되는 모든 워크로드를 통과하는 트래픽이 기록됩니다.
  • 가상 네트워크 흐름 로그를 사용하면 네트워크 보안 그룹 흐름 로그 처럼 다중 레벨 흐름 로깅을 활성화할 필요가 없습니다 . 네트워크 보안 그룹 흐름 로그에서 네트워크 보안 그룹은 서브넷과 네트워크 인터페이스(NIC) 모두에 구성됩니다.
  • 네트워크 보안 그룹 규칙 에서 허용 또는 거부하는 트래픽을 식별하는 기존 지원 외에도 , 가상 네트워크 흐름 로그는 Azure Virtual Network Manager 보안 관리 규칙 에서 허용 또는 거부하는 트래픽을 식별하는 기능을 지원합니다. 또한 가상 네트워크 흐름 로그는 가상 네트워크 암호화를 사용하는 경우 네트워크 트래픽의 암호화 상태를 평가하는 기능도 지원합니다 .
  • 중복된 트래픽 기록과 추가 비용을 피하기 위해 동일한 기본 작업 부하에서 가상 네트워크 흐름 로그를 활성화하기 전에 네트워크 보안 그룹 흐름 로그를 비활성화하는 것이 좋습니다.
  • 서브넷의 네트워크 보안 그룹에서 네트워크 보안 그룹 흐름 로그를 활성화한 다음, 동일한 서브넷이나 부모 가상 네트워크에서 가상 네트워크 흐름 로그를 활성화하면 중복 로깅이 생성되거나 가상 네트워크 흐름 로그만 생성될 수 있습니다.
  • 트래픽은 프라이빗 엔드포인트 자체에서 기록할 수 없습니다. 소스 VM에서 프라이빗 엔드포인트로 향하는 트래픽을 캡처할 수 있습니다. 트래픽은 VM의 소스 IP 주소와 프라이빗 엔드포인트의 대상 IP 주소로 기록됩니다. PrivateEndpointResourceId필드를 사용하여 프라이빗 엔드포인트로 흐르는 트래픽을 식별할 수 있습니다.
  • 스토리지 계정은 가상 네트워크와 동일한 지역에 있어야 합니다.
  • 저장소 계정은 가상 네트워크의 동일한 구독에 있어야 하거나 가상 네트워크 구독의 동일한 Microsoft Entra 테넌트와 연결된 구독에 있어야 합니다.
  • 스토리지 계정은 표준이어야 합니다. 프리미엄 스토리지 계정은 지원되지 않습니다.
  • 스토리지 계정의 액세스 키를 변경하거나 순환하면 가상 네트워크 흐름 로그가 작동하지 않습니다. 이 문제를 해결하려면 가상 네트워크 흐름 로그를 비활성화했다가 다시 활성화해야 합니다.
  • 흐름 로그는 OSI(Open Systems Interconnection) 모델의 4계층에서 작동하며 가상 네트워크를 통과하는 모든 IP 흐름을 기록합니다.
  • 로그는 Azure 플랫폼을 통해 1분 간격으로 수집됩니다. Azure 리소스나 네트워크 트래픽에는 영향을 미치지 않습니다.
  • 로그는 JSON(JavaScript Object Notation) 형식으로 작성됩니다.
  • 각 로그 레코드에는 흐름이 적용되는 네트워크 인터페이스, 5-튜플 정보, 트래픽 방향, 흐름 상태, 암호화 상태 및 처리량 정보가 포함됩니다.
  • 네트워크의 모든 트래픽 흐름은 해당 네트워크 보안 그룹 규칙 또는 Azure Virtual Network Manager 보안 관리 규칙을 통해 평가됩니다 .

4. 참고 문서

Express Route 개념 및 SKU Tier 특징 이해

 

1. Azure ExpressRoute 개념

Azure ExpressRoute는 온프레미스(데이터 센터)와 Azure Region 간을 전용선으로 연결하는 서비스입니다.

  • 인터넷을 거치지 않고, Azure 백본 네트워크를 통해 안정적이고, 안정적·보안적인 통신을 제공합니다.
  • 대규모 데이터 전송, 낮은 지연 시간, 안정적인 대역폭이 필요한 기업 환경 및 하이브리드 클라우드에 적합합니다.
  • 연결 방식: 고객 온프레미스 → 통신사(ExpressRoute 파트너) → ExpressRoute Location(피어링 지점) → Microsoft Azure Backbone → 대상 Azure Region의 VNet

Geo Region
 └─ Region (예: Korea Central, Korea South)
     └─ AZ (Availability Zone)
         └─ ExpressRoute Location (피어링 지점)

2.장점

  • 보안성: 인터넷을 통하지 않음
  • 안정성: 전용선 SLA 보장
  • 예측 가능한 성능: 대역폭 보장
  • 하이브리드 환경 최적화: 온프레미스 + Azure 간 안정적인 통신

3. Azure ExpressRoute SKU 종류 및 특징

SKU 주요 특징 커버리지 가용성
Local - 특정 ExpressRoute Location과 동일 리전의 Azure 리소스만 연결 가능 ExpressRoute Location이 속한 Region의 Azure 리소스만 연결 가능
(다른 Region 연결 불가 / Geo Region 개념이 적용되지 않음)		 단일 Location 내 이중화
(이중 회선)
Standard - 하나의 ExpressRoute Location에 전 세계 동일 지리적 지역(Geo) 내 모든 Azure 리전 연결 가능
- 다수의 VNet 연결 가능		 동일 Geo Region (예: Korea Central ↔ Korea South) Location 단위 이중화
Premium - 글로벌 커버리지: 전 세계 모든 Azure 리전 연결 가능
- 더 많은 VNet 및 회선 연결 지원
- Microsoft 365 등 SaaS 서비스와의 전용 연결 가능		 전 세계 Region Location 단위 이중화

4. ExpressRoute Metro (신규 서비스)

  • 기존 ExpressRoute는 하나의 Location 장애 시 서비스 불가한 한계가 있었음.
  • ExpressRoute Metro는 동일 리전 내 서로 다른 두 개 Location에 각각 1회선씩 연결해 Location 장애에도 서비스 연속성을 제공.
  • 두 Location 간 자동 페일오버로 고가용성 확보.

예시

[ER Location A] <— Circuit 1 —> Azure Region
[ER Location B] <— Circuit 2 —> Azure Region

5. SKU 선택 가이드

요구사항 SKU 한국 예시
1 Region 전용, 저비용 Local **Korea Central Region(서울)**에서만 사용. ExpressRoute Location도 서울(예: KT 목동)로 연결. **Korea South Region(부산)**이나 다른 Region 연결 불가.
동일 Geo Region 내 여러 Region 연결 Standard Korea Central ↔ Korea South 양쪽 Region 연결 가능. 예를 들어 서울에서 부산에 있는 DR VNet까지 전용선으로 연결.
전 세계 Azure Region 연결 Premium 서울(Korea Central)에서 미국 East US, 일본 Japan East 등 전 세계 Azure Region과 전용선 연결 가능. 해외 개발·테스트 환경까지 하나의 Circuit으로 커버.
동일 Region 내 Location 장애 대비 ExpressRoute Metro Korea Central(서울) Region 내 2개의 다른 ExpressRoute Location에 각각 회선 연결. 예: KT 목동 + LG U+ 상암에 각각 연결해서 한 Location 장애 시에도 연결 유지.

 

  • Local → “서울에서만 쓸래”
  • Standard → “서울 ↔ 부산 같이 같은 Geo 안에서 쓸래”
  • Premium → “서울에서 해외까지 다 연결할래”
  • Metro → “서울 Region에서 두 데이터센터(두 Location)에 회선 나눠 연결해 장애 대비할래”

6.  [추가] ExpressRoute Circuit 및 Gateway CRUD 제약사항

  • 생성(Create): 회로 생성 시 Local/Standard/Premium SKU와 Metered/Unlimited 요금제를 선택해야 합니다. Local SKU는 항상 UnlimitedData입니다learn.microsoft.com.
  • 읽기(Read): Get‑AzExpressRouteCircuit 명령 또는 포털에서 회로 상태를 조회할 수 있으며, 이는 제약이 없습니다.
  • 수정(Update): 일부 업그레이드/다운그레이드는 허용되지만, Standard → Local과 Unlimited → Metered 변경은 지원되지 않습니다learn.microsoft.com. 대역폭은 늘릴 수 있지만 줄일 수 없으며, 줄이려면 회로를 다시 만들어야 합니다learn.microsoft.com.
  • 삭제(Delete): 회로를 삭제하려면 모든 연결 리소스를 제거하고, 서비스 공급자가 회로를 비프로비저닝(Not provisioned) 상태로 변경해야 합니다learn.microsoft.com.
  • 즉, ExpressRoute SKU를 선택한 후에는 수정 가능한 범위가 제한되어 있으므로 초기 설계 시 요구되는 연결 범위(지역/전 세계), 대역폭, 요금제 등을 신중히 결정해야 합니다. (아래 표 요약)
카테고리 CRUD 기능/제약사항 기타
ExpressRoute Circuit Create / Read 가능 회로 생성 및 조회 가능
  Update ○ Premium add-on 변경
○ Bandwidth 업그레이드
○ Metered → Unlimited 변경
× Bandwidth 감소
× Unlimited → Metered 변경		 일부 항목은 재생성 필요
  Delete ○ 가능 (사전 자원 정리 필요) 서비스 제공자 deprovision 후 삭제 가능
ExpressRoute Gateway Upgrade SKU ○ non-Az → Az via migration tool 다운그레이드 불가
  Downgrade SKU × 불가 Az → non-Az는 지원 않음
  네트워크 구성 제약 ○ Subnet 이름, NSG 미지원 등 기본 설계 제약 존재

 

7. 참고 문서

AKS Istio add-on 적용 시 유의 사항

. Sidecar Container에 대한 이해

  • 쿠버네티스에서 사이드카(Sidecar) 컨테이너는 포드(Pod) 안에 있는 보조 컨테이너로, “메인” 컨테이너를 확장하거나 보완하는 역할을 합니다. 컨테이너 간에는 네트워크와 파일 시스템을 공유할 수 있기 때문에 하나의 컨테이너는 애플리케이션 서버를 실행하고, 다른 컨테이너는 로그를 수집하거나 파일을 동기화하는 등 별도의 기능을 수행할 수 있습니다. 쿠버네티스 블로그는 사이드카 컨테이너를 “기존 컨테이너를 확장하고 개선한다”고 설명하며, 예로서 Nginx 웹 서버 컨테이너에 파일 시스템을 Git 저장소와 동기화하는 컨테이너를 추가해 Git Push‑to‑Deploy 기능을 제공하는 구성을 들었습니다kubernetes.io. 이처럼 사이드카는 메인 애플리케이션과 분리된 팀이 개발·유지보수할 수 있는 모듈로서, 프록시(ambassador), 로그 수집, 모니터링 어댑터 등 다양한 패턴에 활용됩니다

2. Service Mesh에 대한 이해

  • Kubernetes에서 동작하는 다양한 어플리케이션이 서로 데이터를 공유하거나, 인증 및 라우팅하는 것을 지원하는 기술이다. 특히 Microservice 환경에서 많이 활용되는 네트워크 구성이고, 네트워크의 형태가 mesh형식으로 구성되는 경우가 많아 service mesh라고 명명되었다. Service mesh는 각 컨테이너에 적용된 side car에 통신과 관련된 많은 기능들을 제공하여, 어플리케이션 코드의 변경없이 다양한 네트워크 구성(인증, 라우팅, 보안 등)을 적용할 수 있도록 한다.

3. Istio란?

  • Istio는 이러한 사이드카 패턴을 활용해 서비스 메시(service mesh) 기능을 제공하는 대표적인 플랫폼입니다. 서비스 메시란 마이크로서비스 환경에서 서비스 간 통신을 관리하는 인프라 계층으로, 보안(mTLS), 트래픽 관리, 관찰 가능성과 같은 기능을 애플리케이션 코드 변경 없이 제공하는 것이 목적입니다. Istio는 애플리케이션 옆에 “프록시(사이드카)”를 주입하여 모든 입·출력 트래픽을 프록시로 통하게 하고, 중앙의 제어 플레인에서 프록시의 동작을 설정합니다. 이 구조 덕분에 서비스 개발자는 비즈니스 로직에 집중하고, Istio가 정책 기반 라우팅, A/B 테스트·카나리 배포, 로드밸런싱, 장애 주입, 회로 차단 등 고급 트래픽 제어를 제공하며, 서비스 간 통신을 상호 TLS로 암호화하고 정책·인가를 적용할 수 있습니다. Istio는 또한 프록시에서 발생하는 텔레메트리를 수집해 Grafana나 Prometheus와 같은 도구로 통합하여 가시성을 높입니다. Istio의 데이터 플레인은 전통적인 사이드카 모드 외에도 2024년부터 개발 중인 Ambient mode를 제공하지만, 일반적으로 사이드카 방식이 가장 널리 사용됩니다.

4. Istio 구성

  • Istio는 크게 데이터 플레인(Data Plane)과 컨트롤 플레인(Control Plane)으로 나뉩니다.

 

  • Gateway
    - 설명: Istio Mesh의 진입점(Ingress Gateway) 혹은 출구점(Egress Gateway) 역할.
    - 용도:
    • 외부 트래픽을 받아 VirtualService로 전달
    • 수신할 포트, 프로토콜, 호스트를 정의
    • 예: HTTPS 443 포트로만 접근 허용
  • VirtualService
    - 설명: L7 계층의 라우팅 규칙을 정의하는 Istio 리소스
    - 용도:
    • URL 경로, HTTP 헤더, 요청 속성에 따라 다른 서비스 또는 버전으로 트래픽 분기
    • Canary 배포, Blue/Green 배포 등 점진적 배포 전략 가능
    • 예시: /v1 요청은 v1 서비스로, /v2 요청은 v2 서비스로 전송.
  • DestionationRule
    -     설명: VirtualService가 지정한 목적지 서비스에 대한 연결 정책을 정의.
    - 용도:
    • 서비스 버전(Subset)별 mTLS 보안 설정.
    • 로드밸런싱 전략(Round Robin, Least Request 등).
    • 장애 대응(Circuit Breaker, 재시도 정책).
  • Service
    - 설명: Kubernetes의 기본 서비스 리소스.
    - 역할: 동일한 레이블을 가진 Pod 그룹을 하나의 네트워크 엔드포인트로 노출.
    - Istio에서의 의미: DestinationRule이 참조하는 대상이며, 실제로 트래픽을 전달하는 중간 집합체.

  •  Pod
    -     설명: 애플리케이션이 실제로 동작하는 최소 배포 단위.
    - 역할: Envoy Proxy 사이드카가 함께 배포되어 트래픽을 가로채고, Istio 정책을 적용.
    - 참고: Pod 내부의 Envoy가 mTLS, 인증·인가, 모니터링 등의 기능 수행.

5. 주요 Istio 용어

용어 주요 용도
Gateway 외부 트래픽 진입점 정의. 포트/프로토콜/호스트 지정 가능
VirtualService L7 라우팅 규칙 정의 (경로, 헤더, 호스트 기반)
DestinationRule 서비스 목적지의 연결·보안·LB 정책 설정
ServiceEntry Mesh 기본 정책상 막혀 있는 외부 도메인/서비스 로의 호출을 허용/정의
Sidecar 리소스 네임스페이스·서비스별 트래픽 범위 제한
PeerAuthentication 서비스 간 트래픽을 mTLS(STRICT/PERMISSIVE/DISABLE) 로 설정
RequestAuthentication JWT 인증 적용
AuthorizationPolicy 주체(인증 주체/네트워크/네임스페이스 등), 대상(경로/메서드/포트), 조건을 조합해 허용/차단 규칙 설정
Virtual Host VirtualService에서 지정하는 hosts 필드 개념. 요청 호스트 기반 라우팅
Subset DestinationRule에서 정의하는 서비스 버전(예: v1, v2). Canary 배포 시 사용

 

6. AKS Istio add‑on의 주요 제한사항

제한 사항 상세 내용
Open Service Mesh(OSM) add‑on과 함께 사용할 수 없음learn.microsoft.com AKS 클러스터에 이미 OSM add‑on을 사용 중이라면 Istio add‑on을 활성화할 수 없습니다. 두 서비스 메시 add‑on은 동시에 설치할 수 없기 때문에 하나를 선택해야 합니다.
직접 설치한 Istio와 함께 사용할 수 없음learn.microsoft.com 클러스터에 오픈 소스 Istio를 수동 설치한 경우, 관리형 Istio add‑on을 사용할 수 없습니다. add‑on을 사용하려면 기존 Istio를 제거하거나 다른 클러스터에 add‑on을 활성화해야 합니다.
가상 노드(Azure Container Instances)에서 실행되는 Pod는 메시에 포함 불가learn.microsoft.com AKS의 virtual nodes 기능을 이용해 노드를 확장한 경우, 가상 노드에서 실행되는 Pod는 Istio 메시 네트워크에 참여할 수 없습니다.
Ambient 모드(사이드카 없는 모드) 미지원learn.microsoft.com 2023년부터 Istio에 추가된 Ambient mode는 사이드카 없이 서비스 메시를 구현하는 방식입니다. 현재 AKS Istio add‑on에서는 이를 지원하지 않으며, 향후 로드맵에 따라 제공될 예정입니다.
멀티 클러스터 지원 없음learn.microsoft.com 하나의 Istio 제어 플레인으로 여러 AKS 클러스터를 연결하는 멀티‑클러스터 메시 구성이 아직 지원되지 않습니다.
Windows Server 컨테이너 미지원learn.microsoft.com Istio는 현재 Linux 컨테이너만 지원하므로, Windows 기반 노드에서 실행되는 Pod는 메시에 참여할 수 없습니다.
특정 사용자 정의 리소스(CRD) 차단learn.microsoft.com ProxyConfig, WorkloadEntry, WorkloadGroup, IstioOperator, WasmPlugin과 같은 CRD를 사용한 메시 설정 커스터마이징이 불가능합니다. 이는 관리형 add‑on의 안정성을 위해 일부 고급 설정을 제한한 것입니다.
허용된 EnvoyFilter 유형 제한learn.microsoft.com Envoy에 커스텀 HTTP 필터를 주입하는 EnvoyFilter 리소스는 Lua 스크립트, Compressor, Local Rate Limit 필터만 허용됩니다. 다른 유형의 필터는 차단되며, 허용된 필터 사용 중 발생한 문제는 Microsoft 지원 범위에 포함되지 않습니다.
Gateway API(이니셔티브 GAMMA)를 통한 Istio 인그레스 관리 미지원learn.microsoft.com Istio Ingress Gateway를 Kubernetes Gateway API로 구성하는 기능이 아직 정식 지원되지 않습니다. 대신 기존의 Istio 리소스나 Azure CLI 명령을 이용해야 하며, 포트·프로토콜 변경 같은 상세 설정은 제한됩니다.
MeshConfig 일부 필드만 커스터마이징 가능learn.microsoft.com Istio의 MeshConfig 구조체 중 일부 필드만 AKS add‑on에서 수정할 수 있습니다. 허용되지 않은 설정을 변경하려면 현재로서는 add‑on이 아닌 자체 Istio 설치를 이용해야 합니다.

 

7. 참고 문서

CI/CD Pipeline 구성 시 Credential 관리 주의 사항과 방법

. 개요

CI/CD 파이프라인은 빌드, 테스트, 배포 과정에서 다양한 시스템과 서비스에 접근해야 합니다. 이 과정에서 Access Key, Service Principal, Token, Secret과 같은 민감정보(이하 Credential)를 잘못 관리하면, 외부로 유출되어 심각한 보안사고로 이어질 수 있습니다.

2. Credential 관리 시 주요 위험 요소

 (1) 소스코드에 비밀정보 하드코딩

  • Access Key, Secret, Token을 코드나 설정 파일에 직접 포함할 경우, GitHub/GitLab 등 저장소에서 노출 위험 존재.
  • 이미 commit된 이력에는 삭제해도 정보가 남아있을 수 있음.

 (2) 과도한 권한 부여

  • 예: Service Principal에 Subscription 단위의 Owner 권한 부
    → 탈취 시 전체 구독 리소스에 대한 무제한 권한 발생.

 (3) Credential 공유 방식의 문제

  • 이메일, 메신저 등 보안이 취약한 경로로 전달
  • 중앙 관리 없이 개인이 직접 보관

 (4) 회수·폐기 절차 부재

  • 사용 종료 후에도 Credential이 유효하게 남아 있는 경우 악용 가능.

3. 보안 강화를 위한 관리 방법

(1) Secret 하드코딩 금지

  • 비밀정보 스캐닝:
    • GitHub Advanced Security, SonarQube, truffleHog 등을 이용해 정적 분석.
    • 패스워드, 토큰, 키 패턴을 주기적으로 검색.
  • 이미 커밋된 비밀정보 처리:
    • 단순 삭제가 아닌 해당 Credential 폐기 및 재발급 필수.

 (2) Managed Identity / OIDC 연동 활용

  • Azure 환경에서는 Managed Identity를 부여하여 VM, App Service, AKS Pod가 Key Vault 또는 Storage에 직접 접근 가능.
  • GitHub Actions, Azure DevOps는 OIDC(OpenID Connect)를 사용하여 단기 토큰 기반 인증 지원 → 장기 Secret 불필요.

 (3) 권한 최소화(Least Privilege)

  • 서비스 접근 범위를 최소한으로 설정.
    • 예: Storage 작업 시 전체 Owner 대신 해당 StorageAccount에만 Storage Blob Data Contributor 권한 부여.
  • 구독(Subscription) 단위 권한 부여 지양.

 (4) 중앙화된 비밀정보 관리

  • Azure Key Vault 사용:
    • Secret, Key, Certificate 저장 및 액세스 제어.
    • RBAC 또는 Access Policy로 접근 제한.
  • CI/CD 파이프라인에서 Key Vault Secret을 런타임 시점에 가져와 사용.

 (5) Credential Rotation(주기적 교체)

  • 일정 주기마다 Secret, Access Key 변경.
  • 자동화 스크립트를 활용해 Rotation 절차 CI/CD에 포함.

 (6) 활동 모니터링 및 알림

  • Azure Monitor, Activity Log, Defender for Cloud를 이용해 Credential 사용 내역 추적.
  • 의심스러운 접근 발생 시 알람 설정.

4. 권장 CI/CD 구성 예시

 (1) OIDC 기반 로그인

  • GitHub Actions, Azure DevOps 같은 CI/CD 플랫폼이 **클라우드(예: Azure)**에 인증할 때
    장기 토큰이나 Secret 없이, 한 번 쓰고 버리는 **짧은 수명 토큰(Short-lived Token)**을 발급받는 방식.
  • GitHub Secrets에 클라우드 로그인용 비밀번호/토큰을 저장할 필요 없음
  • 토큰이 만료되면 재사용 불가능 → 탈취돼도 위험 최소화

 (2) Key Vault 호출

  • Secret이 파이프라인 로그나 코드에 남지 않음.
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Azure 로그인 (OIDC 사용)
        uses: azure/login@v1
        with:
          client-id: ${{ secrets.AZURE_CLIENT_ID }}
          tenant-id: ${{ secrets.AZURE_TENANT_ID }}
          subscription-id: ${{ secrets.AZURE_SUBSCRIPTION_ID }}
          enable-AzPSSession: true
      - name: Key Vault에서 Secret 가져오기
        run: |
          secret=$(az keyvault secret show \
            --vault-name myKeyVault \
            --name storage-key \
            --query value -o tsv)
          echo "##[set-output name=storageKey;]$secret"

5. 결론

  • CI/CD Pipeline에서 Credential은 단순 인증 수단이 아니라 보안 경계선입니다.이를 안전하게 관리하지 않으면 전체 인프라가 위험해질 수 있습니다. 따라서 하드코딩 방지 → 중앙화된 관리 → 최소 권한 → 주기적 회수/교체 순으로 정책을 확립하는 것이 필수입니다.

6. 참고 문서

AKS Node Pool 이해와 운영 모범 가이드

. Node Pool 개념

  • AKS에서 Node Pool은 동일한 VM 크기·구성·OS를 가진 노드 그룹을 의미합니다.
  • 클러스터에는 최소 하나의 System Node Pool이 필요하며, 애플리케이션 워크로드는 User Node Pool에서 실행하는 것이 권장됩니다.

2. Node Pool 유형

구분 설명 특징
System Node Pool Kubernetes 핵심 컴포넌트
(CoreDNS. kube-proxy. OMS Agent 등)가 실행되는 풀		 - 최소 1개 필요
- 안정성과 가용성 우선
- VM 크기 변경·불필요한 Scale 조정 지양
User Node Pool 애플리케이션 워크로드(Pod)가 실행되는 풀 - 워크로드 특성별 Pool 구성 가능
- VM 크기·OS·GPU 여부 다양하게 설정 가능

 

3. 용도별 배치 가이드

조치/작업 권장 Node Pool 이유
CoreDNS, kube-proxy, 모니터링 에이전트 System 클러스터 필수 서비스
일반 애플리케이션 Pod User 시스템 리소스와 분리
GPU·고성능 연산 GPU 전용 User 특수 VM 필요
Canary·Blue/Green 배포 별도 User 운영 영향 최소화
CI/CD Job 실행 User 비즈니스 로직 처리 영역
업그레이드 테스트 임시 User System Pool 영향 차단

4. System Node Pool에서 하지 말아야 할 작업

  • 사용자 애플리케이션 Pod 배포
  • OS 업그레이드·VM 크기 변경 테스트
  • 불필요한 Add-on 설치
  • 대규모 리소스 사용 워크로드 실행

-> 이유: 시스템 리소스와 경쟁하면 클러스터 전체 안정성이 저하됩니다.

5. 멀티 Node Pool 생성시 유의사항

  • AKS 클러스터에 시스템 노드 풀을 대체할 다른 시스템 노드 풀이 있으면 시스템 노드 풀을 삭제해도 됩니다. 그렇지 않은 경우 시스템 노드 풀을 삭제할 수 없습니다.
  • 시스템 풀에 하나 이상의 노드가 포함되어야 하고, 사용자 노드 풀에는 0개 이상의 노드가 포함될 수 있습니다.
  • 여러 노드 풀을 사용하려면 AKS 클러스터에서 표준 SKU 부하 분산 장치를 사용해야 합니다. 기본 SKU 부하 분산 장치에서는 이 기능이 지원되지 않습니다.
  • AKS 클러스터는 노드에 대한 Virtual Machine Scale Sets를 사용해야 합니다.
  • 노드 풀의 이름은 영숫자 소문자만 포함할 수 있고 소문자 문자로 시작해야 합니다.
    • Linux 노드 풀의 경우 길이는 1~12자 사이여야 합니다.
    • Windows 노드 풀의 경우 길이는 1~6자 사이여야 합니다.
  • 모든 노드 풀은 동일한 가상 네트워크에 있어야 합니다.
  • 클러스터를 만들 때 여러 노드 풀을 만드는 경우 노드 풀의 모든 Kubernetes 버전은 컨트롤 플레인에 설정된 버전과 일치해야 합니다.

6. 운영 시 Best Practice 

  1. System Node Pool 최소 1개 유지
    • 권장 VM 크기: 최소 2 vCPU, 8 GB RAM
    • Availability Zone 분산 구성 가능
  2. User Node Pool은 워크로드 특성별로 분리
    • 예: API 전용 Pool, Batch 전용 Pool, GPU Pool
  3. 시스템과 워크로드 분리로 안정성 확보
    • 운영 중 문제 발생 시 User Pool만 Scale 조정 가능
  4. 업그레이드·테스트는 임시 Pool 활용
    • 기존 Pool에 영향 없이 새 버전 검증 가능

7. 참고 문서

 
저작자표시 비영리 변경금지 (새창열림)

'카테고리 없음'의 다른글

  • 현재글성덕이의 티티티
댓글

티스토리툴바