AZ-104: Azure 컴퓨팅 리소스 배포 및 관리

가상 머신 구성

• 가상 네트워크는 VM과 다른 Azure 서비스 간의 프라이빗 연결을 제공하기 위해 사용 
• 가상머신 위치가 사용 가능한 옵션을 제한할 수 있음(지역마다 사용 가능한 하드웨어가 다름)
• Azure는 64비트 운영체제만 지원

• 모든 Azure 가상머신은 적어도 2개의 디스크를 갖음(OS 디스크 및 임시 디스크)
• 모든 디스크는 VHD(가상 하드 디스크)로 저장됨
• VHD는 온프레미스 서버의 물리적 디스크와 유사하지만 가상화되어 있음
• OS 디스크 : 선택된 운영체제가 사전 설치되어 있으며 기본적으로 C: 드라이브로 지정
• 임시 디스크 : 페이지 또는 스왑 파일을 저장하는 데 사용하며 윈도우는 D: 리눅스는 /dev/sdb
• 데이터 디스크 : 사용자가 선택한 레이블로 지정

• Azure Bastion은 완전 관리형 PaaS 서비스
• SSL을 통해 직접 가상머신에 안전한 RDP/SSH 연결 제공
• Bastion을 통해 연결하는 경우에는 가상머신에 공용 IP 주소가 필요하지 않음 

 

가상 머신 가용성 구성

• 가용성 집합 : 관련된 가상머신 그룹이 함께 배포되도록 하는 데 사용할 수 있는 논리적 기능
• 그룹화는 단일 실패 지점이 모든 컴퓨터에 영향을 주지 않도록 하는 데 도움되며 데이터센터에서 호스트 운영체제를 업그레이드하는 동안 모든 컴퓨터가 동시에 업그레이드되지 않도록 함

• 가용성 집합의 각 가상머신은 하나의 업데이트 도메인과 하나의 장애 도메인에 배치
• 업데이트 도메인은 서비스 업그레이드 중에 함께 업그레이드되는 노드 그룹
• 기본 5개 최대 20개의 업데이트 도메인 구성 가능
• 장애 도메인은 실패의 물리적 단위를 나타내는 노드 그룹
• 동일한 물리적 랙에 속하는 노드로 간주
• 단일 실패 지점을 공유하는 공통된 하드웨어(또는 스위치) 집합을 공유하는 가상머신 그룹을 정의
• 두 장애 도메인은 함께 작동하여 하드웨어 오류, 네트워크 중단, 전원 중단 또는 소프트웨어 업데이트에 따른 상황을 완화
• 가용성 영역은 장애 도메인과 업데이트 도메인의 조합
• Azure 지역의 세 영역에서 3개의 가상머신을 만들면 3개의 장애 도메인과 3개의 업데이트 도메인에 분산됨
• 가용성 영역의 각 영역은 독립된 전원, 냉각 및 네트워킹을 갖춘 하나 이상의 데이터 센터로 구성 
• 가상머신 크기를 높이는 스케일 업 = 수직 스케일링
• 가상머신 개수를 늘리는 스케일 아웃 = 수평 스케일링
• 일반적으로 스케일 아웃이 스케일 업보다 제한사항이 적고 유연함
• VMSS : 동일한 VM 세트(동일한 이미지 및 구성)를 배포 및 관리하며 자동 스케일링
• VMSS는 L4 및 L7 사용을 지원 
• 오케스트레이션 모드 > 가상머신을 관리하는 방법
• 유연한 : 가상 머신을 수동으로 만들어 확장 집합에 추가
• 균일한 : 가상머신 모델을 정의하고 해당 모델을 기반으로 동일한 인스턴스 생성
• 분산 알고리즘 > 최대 분산 방식 권장 
• 사용량이 많은 프로덕션 기간인 시나리오 : 사전에 예약하여 여러 개의 인스턴스를 배포하는 일정 기반 규칙

 

Azure App Service 요금제 구성

• App Service 계획은 실행할 웹 애플리케이션에 대한 컴퓨팅 리소스 집합을 정의 
• 계획에 배치하는 모든 애플리케이션은 계획에 정의된 컴퓨팅 리소스에서 실행
• 세 가지 설정 정의 : 지역 / VM 인스턴스 수 / VM 인스턴스 크기(소형, 중형, 대형)
• App Service 계획은 App Service 애플리케이션의 스케일링 단위
• App Service 계획의 가격 책정 계층에 따라 애플리케이션이 다른 방식으로 실행되고 스케일링
• 계층 : 무료, 공유 계층 / 기본, 표준, 프리미엄, 격리 계층
• 무료 및 공유 > 개발 및 테스트 목적으로만 사용
• 기본 > 트래픽 요구사항이 낮고 고급 자동 크기 조정이 필요하지 않은 애플리케이션
• 표준 > 프로덕션 워크로드
• 프리미엄 > 더 향상된 성능
• 격리 > 중요 업무용 워크로드 = 프라이빗 전용 환경
• 스케일 업 : 애플리케이션이 있는 App Service 플랜의 가격 책정 계층을 변경하여 강화
• 스케일 아웃 : App Service 플랜 가격 책정 계층에 따라 최대 30개의 인스턴스로 확장 가능
• 플랜 계층은 수동으로 조정하는 것을 권장
• 무료 계층으로 시작하여 사용자 지정 DNS 이름을 추가할 때 공유 계층으로 확장
• 다음으로 SSL 바인딩을 만들기 위해 기본 계층으로 확장 후 표준 계층으로 스케일 업 등
• 자동 크기 조정 규칙 : 메트릭 기반 규칙(ex. CPU) / 시간=일정 기준 규칙(ex. 부하 시간 패턴이 있는 경우)

 

Azure App Service 구성

• Azure App Service는 웹 애플리케이션을 호스팅하는 HTTP 기반 서비스
• Azure App Service는 모든 플랫폼 또는 디바이스용 웹 사이트, 모바일 백엔드 및 웹 API를 만드는 데 필요한 모든 항목을 함께 제공
• 여러 언어 및 프레임워크 / DevOps 최적화 / 서버리스 코드 등 다양한 이점
• 사용 가능한 리소스, 기능 및 용량을 설정하려면 앱을 App Service 요금제에 연결
• Always On : 트래픽이 없는 경우에도 앱을 로드된 상태로 유지
• ARR 선호도 : 클라이언트가 세션 수명 동안 동일한 인스턴스로 라우팅되는지 확인
• 연결 문자열 : 미사용 상태에서 암호화되며 암호화된 채널을 통해 전송

• 개발 머신에서 Azure DevOps. GitHub 등을 통해 웹앱에 자동으로 동기화 = CICD
• 자동화된 배포 : Azure DevOps / GitHub / Bitbucket
• 수동 배포 : Git / CLI / Visual Studio / FTP

• 웹앱, 모바일 백엔드, API 앱을 App Service에서 배포할 때 기본 프로덕션 슬롯 대신 별도의 배포 슬롯 사용 가능 
• 배포 슬롯은 표준, 프리미엄, 격리 계층에서만 지원  
• 앱 콘텐츠와 구성 요소는 프로덕션 슬롯을 포함한 두 배포 슬롯 간에 교환 가능 
• Linux의 웹앱에서는 자동 교환이 지원되지 않음 
• 배포 슬롯 간에 교환되는 설정과 원본 슬롯에 남아 있는 설정(슬롯별)이 다름
• 교환되는 설정(=교환되더라도 콘텐츠에 계속 적용) > 프레임워크 버전, 공용 인증서, 연결 문자열 등
• 원본 슬롯에 남아 있는(슬롯별) 설정 > 사용자 지정 도메인 이름, 비공개 인증서, 크기 조정 설정 등
• App Service의 인증 및 권하 부여 보안 모듈은 애플리케이션 코드와 동일한 환경에서 실행되지만 별도로 실행
• 보안 모듈을 사용하도록 설정하면 들어오는 모든 HTTP 요청이 애플리케이션 코드에서 처리되기 전에 모듈을 통과
• 익명 요청 허용 > 인증되지 않은 트래픽의 권한 부여를 연기
• 인증된 요청만 허용 > 사용자가 선택한 공급자에 대한 모든 익명 요청을 /.auth/login/<provider>로 리디렉션
• 모든 호출에 대한 액세스를 제한하므로 공용 홈페이지가 필요한 경우 부적절
• 로깅 및 추적 > 로그 파일에서 직접 인증 및 권한 부여 추적 확인   
• 웹앱을 만들면 Azure에서 azurewebsites.net의 하위 도메인에 할당되며 가상 IP 주소 할당
• 프로덕션 웹앱의 경우 사용자 지정 도메인 이름 표시 가능(App Service 플랜의 유료 계층 필요)   
• 1. 도메인 이름 예약
• 2. 도메인을 Azure 웹앱에 매핑하는 DNS 레코드 생성
• 웹앱의 경우 A 또는 CNAME 레코드 생성
• A 레코드는 도메인 이름을 IP 주소에 매핑
• CNAME 레코드는 도메인 이름을 다른 도메인 이름에 매핑하며 DNS는 두 번째 이름을 사용하여 주소 조회
• IP 주소 변경 시 CNAME은 계속 유효하지만 A는 업데이트 필요       
• 3. 사용자 지정 도메인 사용
• 사용자 지정 도메인의 유효성 검사하고 게시 전 도메인 테스트 필요
• 백업 및 복원 기능을 사용하려면 표준 또는 프리미엄 계층 App Service 플랜이 필요
• 백업할 앱과 동일한 구독에 Azure Storage 계정 및 컨테이너 필요
• 백업 파일은 Zip 파일과 XML 파일로 구성되며 전체 백업 및 부분 백업 가능
• 전체 백업의 경우 사이트의 모든 콘텐츠가 백업에있는 항목들로 대체(파일이 사이트에 있지만 백업에 없으면 삭제)    

• Azure Application Insights는 라이브 애플리케이션을 모니터링할 수 있는 Azure Monitor의 기능
• 요청 속도, 응답 시간 및 실패율, 종속성 비율, 예외, 사용자 및 세션 수 등 모니터링 가능 

 

Azure Container Instances 구성

비교	컨테이너	가상머신
격리	호스트 및 기타 컨테이너로부터 어느 정도격리하지만 가상머신처럼 강력한 보안 경계 X	호스트 운영체제와 다른 가상머신으로부터 완벽하게 격리되며 보안 경계가 중요한 경우에 유용
운영체제	운영체제의 부분 실행 가능	전체 운영체제 실행
배포	명령줄을 통해 Docker 사용하여 개별 컨테이너 배포	Windows Admin Center 또는 Hyper-v 관리자를 사용하여 개별 가상머신 배포
영구 스토리지	단일 노드에는 로컬 스토리지용 Azure 디스크 사용	단일 가상머신의 로컬 스토리지에 VHD 사용
내결함성	클러스터 노드에서 장애가 발생하면 오케스트레이터는 해당 노드에서 실행되는 모든 컨테이너를 다른 클러스터 노드에 다시 생성	클러스터의 다른 서버에 대해 장애 조치(Failover)를 취할 수 있으며 이때 가상머신의 운영체제는 새로운 서버에서 다시 실행

• Azure Container Instances의 최상위 리소스는 컨테이너 그룹
• 컨테이너 그룹은 같은 호스트 컴퓨터에서 예약되어 있는 컨테이너 컬렉션
• 컨테이너 그룹의 컨테이너는 수명 주기, 리소스, 로컬 네트워크, 스토리지 볼륨을 공유
• 다중 컨테이너 그룹 배포 방법 : ARM(다른 Azure 서비스 리소스를 배포하는 경우) or YAML(컨테이너 인스턴스만 배포하는 경우)
• 컨테이너 그룹은 외부 연결 IP 주소, 해당 IP 주소에 있는 하나 이상의 포트, FQDN이 포함된 DNS 레이블 공유할 수 있음
• Container Instances는 상태 검색 및 유지에 Azure Files 사용
• 컨테이너가 사용 중인 경우에만 요금 발생

• 컨테이너 그룹은 단일 호스트 컴퓨터에서 예약되며 DNS 이름 레이블이 할당
• 컨테이너 그룹은 하나의 노출된  포트를 사용하여 단일 공요 IP 주소를 노출
• 그룹의 한 컨테이너가 포트 80에서 수신 대기, 다른 컨테이너는 포트 1433에서 수신 대기
• Azure Files 파일 공유 2개가 볼륨 탑재로 포함되며 각 컨테이너는 하나의 파일 공유를 로컬로 탑재   
• 다중 컨테이너 그룹 시나리오 : 웹앱 업데이트 / 로그데이터 수집 / 앱 모니터링 / 프런트엔드 및 백엔드  
• Docker의 주요 기능은 컨테이너화된 소프트웨어가 항상 Windows 또는 Linux에서 로컬 또는 Azure의 클라우드에서 동일하게 실행되도록 보장하는 것
• Dockerfile은 이미지를 빌드하는 방법에 대한 지침이 포함된 텍스트 파일  

 

Azure CLI를 사용하여 가상 머신 관리

• --no-wait 옵션을 추가하여 CLI 도구가 즉시 반환되도록 하고 백그라운드에서 실행
• JMESPath를 사용하여 쿼리에 필터를 추가하여 출력할 수 있음(ex. people[?age > '25'].[name]) 
• --query hardwareProfile.vmSize
• --query "networkProfile.networkInterfaces[].id" -o tsv
• --query "instanceView.statuses[?starts_with(code, 'PowerState/')].displayStatus" -o tsv

 

Azure에서 Windows 가상 머신 만들기

• Windows VM에 대해 기본적으로 두 개의 VHD가 생성(OS 및 임시 디스크)
• 비관리 디스크의 경우 VM 디스크에 해당하는 VHD를 유지하는 데 사용되는 스토리지 계정을 사용자가 관리
• 관리 디스크는 관리되는 최신 디스크 스토리지 모델(안정성 향상 / 보안 강화 / 스냅샷 지원 / 백업 지원)
• 사용자 지정 소프트웨어 설치 : 웹 브라우저를 열고 다운로드하여 설치 or 소프트웨어를 로컬 머신에서 VM으로 복사하여 설치
• 처음부터 새로 만드는 모든 추가 드라이브는 초기화 및 포맷 과정 필요
• NSG 인바운드 : 서브넷 수준 - NIC 수준
• NSG 아웃바운드 : NIC 수준 - 서브넷 수준

 

Azure App Service를 사용하여 웹 애플리케이션 호스트

Azure App Service는 플랫폼을 호스트하는 완전 관리형 웹 애플리케이션

배포 슬롯 : 스테이징 배포 슬롯을 만들고 프로덕션 슬롯과 손쉽게 교환 가능 

• CICD 지원
• 기본 제공 자동 크기 조정 지원(스케일 업 / 스케일 아웃)
• 게시 > 컨테이너 : Docker 이미지로 배포 가능
• 게시 > 코드 : 런타임을 알고 있어야 함 (Docker의 경우 이미지에 포함되므로 생략)
• 운영체제 > Windows : 모니터링 탭이 활성화되며 Application Insights 사용 가능
• App Service 플랜은 App Service 앱을 실행하는 가상 서버 리소스 세트
• 플랜(=계획)의 계층(=크기=SKU)에 따라 할당된 앱을 실행하는 가상 서버의 성능 및 특성이 결정
• 단일 플랜은 여러 웹앱을 호스트할 수 있음
• 자동화된 배포 : Azure DevOps / GitHub / Bitbucket / OneDrive / Dropbox
• 수동 배포 : Git / az webapp up (새 웹앱 자동 생성 가능) / ZIP 배포 / WAR 배포 / Visual Studio / FTP