Azure 가상 네트워크

• Azure 가상 네트워크 : Azure 클라우드 리소스를 논리적으로 격리 -> 서로 다른 Azure 리소스 간 상호 통신, 인터넷 통신 및 온-프레미스 네트워크 통신을 안전하게 수행 가능
  
  
  

• 특징

1. Azure에서 VPN(가상 사설망)을 프로비저닝하고 관리 가능
2. 고유한 CIDR(Classless Interdomain Routing) 블록을 가짐
3. 다른 가상 네트워크 및 온-프레미스 네트워크에 연결 가능
4. 가상 네트워크에 대한 DNS 서버 설정을 제어 가능
5. 가상 네트워크를 서브넷으로 구분 가능

• 활용 시나리오

1. 프라이빗 클라우드만 사용하는 전용 가상 네트워크 :
2. 가상 네트워크를 사용하여 안전하게 데이터 센터 확장 : 기존의 사이트 간 VPN을 빌드하여 데이터 센터 용량을 안전하게 확장
3. 하이브리드 클라우드 시나리오 사용 : 모든 형식의 온-프레미스 시스템에 클라우드 기반 애플리케이션을 안전하게 연결
   
   
   

서브넷

• Azure 서브넷 : 가상 네트워크 내에서 논리적 구분을 구현하는 방법
  
  
  

• 특징

1. 각 서브넷은 가상 네트워크 주소 공간에 속하는 IP 주소 범위를 포함
2. 서브넷의 주소 범위는 가상 네트워크의 주소 공간 내에서 고유해야 함
3. 하나의 서브넷에 대한 범위는 동일한 가상 네트워크의 다른 서브넷 IP 주소 범위와 겹치지 않아야 함
4. CIDR 표기법을 사용하여 서브넷의 IP 주소 공간을 지정
   
   
   

• 예약된 주소 (아래는 192.168.1.0/24의 IP 주소 범위에서의 예시)

• 서브넷 사용 시 고려사항

1. 서비스 요구 사항을 고려 : 서브넷 내부 및 외부로 허용되어야 하는 트래픽 유형 및 라우팅에 대한 특정 요구 사항이 있음
2. 네트워크 가상 어플라이언스를 고려 : Azure의 기본 라우팅을 재정의하여 서브넷 간 Azure 라우팅을 방지
3. 네트워크 보안 그룹을 고려 : 각 네트워크 보안 그룹에는 원본과 대상 간의 트래픽을 허용하거나 거부하는 규칙이 있음
4. 프라이빗 링크를 고려 : Azure Private Link는 가상 네트워크에서 Azure PaaS(Platform as a Service), 고객 소유 또는 Microsoft 파트너 서비스에 대한 프라이빗 연결을 제공
   
   
   

가상 네트워크 만들기

• 주의사항

1. 조직에서 아직 사용하지 않는 IP 주소 공간을 사용하도록 계획
2. IP 주소 공간을 만든 후에는 변경 불가
3. 하나 이상의 서브넷을 정의 필요
4. 네트워크에 대한 Azure 구독, 리소스 그룹, 가상 네트워크 이름 및 서비스 지역을 제공해야 함
   
   
   

ip주소 지정

• 다른 Azure 리소스, 온-프레미스 네트워크 및 인터넷과 통신하기 위해 Azure 리소스에 IP 주소를 할당
• private ip : Azure 가상 네트워크 및 온-프레미스 네트워크 내에서 통신
• public ip : 리소스가 인터넷과 통신

• 고정ip주소 적합 상황

1. DNS 이름 확인(IP 주소를 변경하려면 A 레코드를 업데이트해야 하는 경우)
2. 앱 또는 서비스에 고정 IP 주소를 사용해야 하는 IP 주소 기반 보안 모델
3. TLS/SSL 인증서가 IP 주소에 연결
4. IP 주소 범위를 사용하여 트래픽을 허용하거나 거부하는 방화벽 규칙
5. 도메인 컨트롤러 및 DNS 서버와 같은 역할 기반 가상 머신.
   
   
   

• public ip 할당 시 고려사항

1. 동적 주소 : 공용 IP 주소가 Azure 리소스에 연결되고 처음으로 시작된 후에 할당 -> 가상 머신과 같은 리소스가 중지(할당 취소)된 다음, Azure를 통해 다시 시작되면 동적 주소가 변경
2. 고정 주소 : 공용 IP 주소를 만들 때 할당 -> 공용 IP 주소 리소스를 삭제할 때까지 해제되지 않음
   
   
   

• public ip 주소 리소스 연결

1. 가상 머신 네트워크 인터페이스, 인터넷 연결 부하 분산 장치, VPN 게이트웨이 및 애플리케이션 게이트웨이와 연결 가능
   
   
   

• private ip 주소 리소스 연결

1. 가상 머신 네트워크 인터페이스, 내부 부하 분산 장치 및 애플리케이션 게이트웨이와 연결 가능
   
   
   

네트워크 보안 그룹

• 네트워크 보안 그룹 : 가상 네트워크의 리소스에 대한 네트워크 트래픽을 제한하는 방법
  
  
  

• 특징

1. 인바운드 또는 아웃바운드 네트워크 트래픽을 허용하거나 거부하는 보안 규칙 목록이 포함
2. 서브넷 또는 네트워크 인터페이스(NIC(네트워크 인터페이스 카드))에 연결
3. 여러 번 연결 가능
   
   
   

• DMZ : 가상 네트워크와 인터넷 내의 리소스 간에 버퍼 역할 서브넷 (네트워크 보안 그룹 설정을 통해 만들 수 있음)
  
  
  

• 보안규칙

1. 각 보안 규칙에는 우선 순위 값이 할당 -> 네트워크 보안 그룹에 대한 모든 보안 규칙은 우선 순위에 따라 처리
2. 기본 보안 규칙은 제거 불가

• 예제1) 인바운드 트래픽 규칙 : 가상 네트워크 및 Azure 부하 분산 장치의 트래픽을 제외한 모든 인바운드 트래픽을 거부

• 예제2) 아웃바운드 트래픽 규칙 : 인터넷 및 가상 네트워크로의 아웃바운드 트래픽만 허용

• 보안그룹 규칙 순서

1. 인바운드 트래픽
   1. 서브넷에 대한 네트워크 보안 그룹 보안 규칙을 처리
   2. 네트워크 인터페이스에 대한 보안 규칙을 처리
2. 아웃바운드 트래픽 (인바운드 트래픽 역순)
   1. 네트워크 인터페이스에 대한 네트워크 보안 그룹 보안 규칙을 평가
   2. 서브넷에 대한 보안 규칙을 평가

• 보안그룹 설정 시 고려사항

1. 모든 트래픽 허용 : 기본 Azure 보안 규칙에 따라 서브넷 또는 NIC를 통한 모든 네트워크 트래픽을 허용 -> 가상 머신을 서브넷 내에 배치하거나 네트워크 인터페이스를 활용하는 경우 서브넷 또는 NIC를 네트워크 보안 그룹과 연결할 필요가 없음
2. 허용 규칙의 중요성을 고려 : 네트워크 보안 그룹에 서브넷 또는 NIC가 있는 경우 각 수준에서 허용 규칙을 정의해야 함. 그렇지 않으면 허용 규칙 정의를 제공하지 않는 모든 수준에 대해 트래픽이 거부
3. 서브넷 내 트래픽을 고려 : 서브넷에 연결된 네트워크 보안 그룹에 대한 보안 규칙은 서브넷의 모든 가상 머신 간의 트래픽에 영향을 줄 수 있음
4. 규칙 우선 순위를 고려 : 네트워크 보안 그룹에 대한 보안 규칙은 우선 순위에 따라 처리
   
   
   

• 애플리케이션 보안 그룹 : 워크로드별로 가상 머신을 논리적으로 그룹화 -> 그룹화된 애플리케이션 보안 그룹에 따라 네트워크 보안 그룹 규칙을 정의할 수 있음 (워크로드별 보안 그룹)

Azure Container Instances (ACI)

• 동일한 물리적 하드웨어에서 여러 개의 격리된 운영 체제 인스턴스를 동시에 실행할 수 있음
• Container에 대한 내용은 kubernetes 개요 글 참고

구현 방법

• 컨테이너 그룹 : Azure Container Instances의 최상위 리소스 (동일한 호스트 머신(=host os?)에서 예약되는 컨테이너의 컬렉션)
  
  
  

• 특징

1. 컨테이너 그룹은 kubernetes의 POD와 유사 (수명 주기, 리소스, 로컬 네트워크, 스토리지 볼륨 공유)
2. Azure Container Instances는 그룹 내 모든 컨테이너의 리소스 요청을 함께 추가하여 리소스를 다중 컨테이너 그룹에 할당
3. 다중 컨테이너 그룹을 배포하는 두 가지 일반적인 방법은 ARM(Azure Resource Manager) 템플릿 및 YAML 파일
   
   
   

• 예시

1. 단일 호스트 컴퓨터에서 예약되며 DNS 이름 레이블이 할당
2. 하나의 노출된 포트를 사용하여 단일 공용 IP 주소를 노출
3. 그룹의 한 컨테이너가 포트 80에서 수신 대기합니다. 다른 컨테이너는 포트 1433에서 수신 대기
4. 이 그룹에는 Azure Files 파일 공유 두 개가 볼륨 탑재로 포함. 그룹의 각 컨테이너는 파일 공유 중 하나를 로컬로 탑재

Azure Container Apps

• Azure Container Apps : 컨테이너화된 애플리케이션을 실행하면서 인프라를 덜 유지하고 비용을 절감할 수 있는 서버리스 플랫폼 (서버 구성, 컨테이너 오케스트레이션 및 배포 세부 정보를 염려x)
  
  
  

• 특징

1. 컨테이너에 배포된 많은 마이크로 서비스에 걸쳐 있는 애플리케이션에 최적화
2. Kubernetes 및 Dapr, KEDA 및 envoy와 같은 오픈 소스 기술을 통해 제공
3. 서비스 검색 및 트래픽 분할과 같은 기능을 통해 Kubernetes 스타일 앱 및 마이크로 서비스를 지원
4. 트래픽에 따라 비율 크기 조정
5. 이벤트 기반 애플리케이션 아키텍처를 사용하도록 설정
6. 요청 시, 예약된 및 이벤트 기반 작업 실행을 지원
7. 기본 Kubernetes API에 대한 직접 액세스를 제공하지 않음
   
   
   

• ACA vs AKS 비교
  : 요약하면 ACA는 kubernetes 인프라에 대한 제어가 필요 없을 때, AKS는 kubernetes 인프라에 대한 제어가 필요할 때 활용

Azure App Service

• Azure App Service : App Service Plan에 의해 실행되는 Application

• App Service Plan : Application에 대한 Azure 컴퓨팅 리소스 집합
  
  
  

• Azure App Service 이점

• App Service 사용 시, 정의되는 설정

1. 운영체제
2. region
3. 가격책정 계층 : 어떤 App Service를 이용할 수 있는지와 얼마를 지불해야 하는지에 대한 계층 -> 설정한 OS에 따라 달라짐
4. VM 인스턴스 수 : 3~30
5. VM 인스턴스 크기 : CPU, Memory, 원격 스토리지
   
   
   

• App Service Plan 사용 시, 고려사항

1. 비용 고려
2. 여러 App 실행 고려 : 동일 Plan내 컴퓨팅 자원을 공유할 여러 Application 실행 고려 -> 비용 절감 가능
3. 계획 용량 고려 : App이 사용할 컴퓨팅 리소스 사용계획 고려
4. App 격리 고려 : 다음의 경우 새 plan을 생성해야 함
   • 독립된 환경 필요
   • 서로 다른 지역의 리소스 필요
     
     
     

가격 책정 계층

1. 무료
2. 공유
3. 기본 : 트래픽 요구 사항이 낮고 고급 자동 크기 조정 및 트래픽 관리 기능이 필요하지 않은 애플리케이션
4. 표준 : 일반적인 프로덕션 워크로드를 실행, auto scaling 기능 포함, Web App for Containers 지원
5. 프리미엄 : 프로덕션 애플리케이션에 향상된 성능을 제공
6. 프리미엄v2
7. 프리미엄v3
8. 격리 : 가상 네트워크에서 실행해야 하는 중요 업무용 워크로드를 실행하도록 설계, 표준 계층에 비해 더 빠른 프로세서, SSD 스토리지 및 이중 메모리 대 코어 비율을 갖춘 Dv2 시리즈 가상 머신을 제공
9. 격리v2
   
   
   

• 가격책정 계층 그룹화

1. 공유 컴퓨팅
   • 무료, 공유 계층
   • 다른 고객의 앱을 비롯한 다른 App Service 앱과 동일한 Azure VM에서 앱을 실행 (Scale-out 불가)
   • 일반적으로 개발 및 테스트 목적으로 활용
2. 전용 컴퓨팅
   • 기본, 표준, 프리미엄, 프리미엄V2, 프리미엄V3 계층
   • 동일한 App Service 요금제에 속한 앱만 동일한 컴퓨팅 리소스
   • 계층이 높을수록 Scale-out 인스턴스 수 증가
3. 격리
   • 격리 및 격리V2 계층
   • 전용 Azure 가상 네트워크에서 전용 Azure VM을 실행
   • 앱에 대한 컴퓨팅 격리 + 네트워크 격리
     
     
     

Azure App Service 스케일링 방법

• App Service Application의 스케일링 단위는 App Service Plan 단위

• 가격 책정 계층에 따라 App 실행 방식과 Scaling 방식이 달라짐

• Scale-up 방법 : Azure App Service 플랜의 가격 책정 계층을 변경하여 강화

• Scale-out 방법 : 가상 머신 인스턴스 수가 증가, 가격 책정 계층에 따라 인스턴스 확장
  
  
  

• 고려사항

1. 수동조정 case 고려 : 무료 계층을 사용하여 웹앱 테스트를 시작하는 시나리오 (점진적으로 가격책정 계층 상향) -> 비용 절약
2. 사용자 지원, 가격 절감 고려 : Auto Scaling 설정, 부하에 따른 인스턴스 수 조절 -> 비용 절약
3. 스케일 설정 변경 시, 재배포 필요x
4. App Service Plan 외의 서비스는 Scaling 관여하지 않음
   
   
   

Auto Scaling

• 고려사항

1. 최소 인스턴스 수
2. 최대 인스턴스 수
3. 최소, 최대 인스턴스 수 간 적절한 gap 필요
4. 크기조정 규칙 조합
5. 메트릭 통계 : 진단 메트릭에 적합한 통계(평균, 최소, 최대, 합계)를 주의하여 선택
6. 기본 인스턴스 수 : 항상 안전한 기본 인스턴스 수를 선택
7. 알림 : 자동 스케일링 알림을 구성
   
   
   

CI/CD

• Azure Portal에서 CI/CD 설정 제공

• 소스코드가 변경되면 자동으로 배포되어 웹/앱에 동기화 됨

• Azure DevOps 서비스를 사용하면 고유한 빌드 및 릴리스 프로세스를 정의할 수도 있음
  
  
  

• 제공되는 소스코드 저장소

1. GitHub
2. Bitbucket
3. 로컬 Git
4. Azure Repos
   
   
   

• 배포 슬롯

1. 표준, 프리미엄 및 격리된 App Service 가격 책정 계층에서 사용 가능
2. 앱 콘텐츠와 구성 요소는 프로덕션 슬롯을 포함한 두 배포 슬롯 간에 교환 가능 -> 버전 up/down 기능

App Service App Security

• 코드를 최소한으로 작성하거나 작성하지 않고 사용자를 로그인하고 데이터에 액세스할 수 있음
  
  
  

• 특징

1. Azure App Service의 인증 및 권한 부여 보안 모듈 은 애플리케이션 코드와 동일한 환경에서 실행되지만 별도로 실행
2. 앱 설정을 사용하여 구성
3. 들어오는 모든 HTTP 요청이 애플리케이션 코드에서 처리되기 전에 Security 모듈을 통과
   
   
   

사용자 지정 도메인

1. 도메인 이름을 예약 : Azure Portal에서 직접 구입 -> Azure Portal에서 직접 웹앱의 도메인 이름을 관리
2. 도메인을 Azure 웹앱에 매핑하는 DNS 레코드를 만듦
   • 웹앱의 경우 A(주소) 레코드 또는 CNAME(Canonical 이름) 레코드를 만듦
   • IP 주소가 변경되면 CNAME 항목은 여전히 유효하지만 A 레코드를 업데이트 필요
3. Azure Portal에서 사용자 지정 도메인을 사용하도록 설정
   
   
   

백업 및 복원

1. 표준 또는 프리미엄 계층 App Service 요금제가 필요
2. 동일한 구독에 Azure Storage 계정 및 컨테이너가 필요
3. 백업 정보
   • 앱 구성 설정
   • 파일 콘텐츠
   • 앱에 연결된 모든 데이터베이스
4. 백업은 Zip 파일과 XML 파일로 구성
5. 백업을 수동으로 또는 일정에 따라 구성 가능
6. 부분 백업이 지원됩니다. 백업에서 제외할 파일 및 폴더를 지정 가능
7. 최대 10GB의 앱과 데이터베이스 콘텐츠를 저장 가능
8. Azure Portal에서 스토리지 계정 및 앱(또는 사이트)의 컨테이너 페이지에 표시
   
   
   

• 복원 시 고려사항

1. 전체 백업을 고려 -> 해당 사이트의 모든 콘텐츠가 백업에 있는 항목들로 대체
2. 부분 백업을 고려 -> 제외된 폴더 또는 파일에 있는 모든 콘텐츠가 있는 그대로 남아 있음
3. 백업 파일 검색을 고려 -> 앱 또는 사이트 복원을 수행하지 않고도 콘텐츠를 볼 수 있음
4. 백업 대상에 대한 방화벽을 고려 -> 방화벽 설정 시, 스토리지 계정을 백업의 대상으로 사용할 수 없음
   
   
   

Azure Application Insights

• Azure Application Insights : 라이브 애플리케이션을 모니터링할 수 있는 Azure Monitor의 기능 -> 사용자가 문제를 진단하고 사용자가 실제로 앱을 사용하여 수행할 작업을 이해하는 데 도움이 되는 강력한 분석 도구를 제공
  
  
  

• 특성

1. 온-프레미스, 하이브리드 환경 또는 퍼블릭 클라우드에서 호스트되는 구성에 사용 가능
2. Azure 파이프라인 프로세스와 통합되며, 다양한 개발 도구에 대한 연결점이 있음
3. Visual Studio App Center를 통합하여 모바일 앱에서 데이터를 모니터링하고 분석

• 모니터링 대상

1. 요청 속도, 응답 시간 및 실패율을 확인 : 어떤 페이지가 가장 성능이 우수한지 확인, 응답 시간과 실패율이 높아지면 아마도 리소스 문제
2. 종속성 비율, 응답 시간 및 실패율을 확인 : 외부 서비스가 앱 성능을 저하시키는지 조사
3. 예외를 확인 : 서버 및 브라우저 예외가 전부 보고
4. 페이지 보기 및 로드 성능을 확인 : 페이지 보기 숫자를 수집하고 로드 성능을 분석
5. 성능 지표 확인 : CPU, 메모리, 네트워크 사용량 등에 대한 성능 출력을 모니터링
6. Docker 또는 Azure의 진단을 앱 Application Insights에 통합
7. 진단 추적 로그를 확인 : 제를 진단하는 데 도움
8. 사용자 지정 이벤트 및 메트릭을 확인 : 클라이언트 또는 서버 코드로 작성, 비즈니스 이벤트를 추적

가용성 계획에 포함되어야 하는 전략

1. 계획되지 않은 하드웨어 유지 관리 : 물리적 컴퓨터에 연결된 하드웨어 또는 플랫폼 구성 요소가 실패할 것으로 예측하는 경우에 발생 -> 실시간 마이그레이션 기술을 사용하여 오류가 발생한 하드웨어에서 정상적인 물리적 컴퓨터로 가상 머신을 마이그레이션 -> 성능저하 우려 있음
2. 예기치 않은 가동 중지 시간 : 로컬 네트워크 오류, 로컬 디스크 오류 또는 기타 랙 수준의 오류가 포함 -> 가상 머신을 동일한 데이터 센터의 정상적인 물리적 컴퓨터로 자동으로 마이그레이션(복구) -> 임시 드라이브가 손실 우려 있음
3. 계획된 유지 관리 : 플랫폼 인프라의 전반적인 안정성, 성능 및 보안을 개선하기 위해 Microsoft에서 기본 Azure 플랫폼으로 정기적으로 업데이트

• 가상 머신 운영 체제 또는 기타 소프트웨어를 자동으로 업데이트하지 않습니다. 이러한 업데이트는 전적으로 사용자의 제어와 책임 하에 실시됩니다. 그러나 기본 소프트웨어 호스트 및 하드웨어는 안정성과 고성능을 보장하기 위해 정기적으로 패치
  
  
  

가용성 집합

• 특징

1. 동일 가용성 집합의 가상 머신은 모두 동일한 기능을 수행
2. 동일 가용성 집합의 가상 머신은 모두 동일 소프트웨어 설치
3. 동일 가용성 집합의 가상 머신은 여러 물리적 서버, 컴퓨팅 랙, 스토리지 단위 및 네트워크 스위치에 나눠 실행
4. 가용성 집합을 변경하려면 가상 머신을 삭제한 다음, 다시 만들어야 함
5. 단일 실패 지점이 모든 컴퓨터에 영향을 주지 않도록 하는 데 도움 -> 호스트 운영 체제를 업그레이드하는 동안 모든 컴퓨터가 동시에 업그레이드되지 않도록 함
   
   
   

• 고려 사항

1. 중복 고려
2. 애플리케이션 계층의 분리를 고려 : 각 애플리케이션 계층은 별도의 가용성 집합 필요 -> 실패지점 확산 방지
3. 부하 분산을 고려 : Azure Load Balancer를 사용
4. 관리 디스크를 고려 : 블록 수준 스토리지
   
   
   

업데이트 도메인 및 장애 도메인

• 업데이트 도메인 : 서비스 업그레이드(또는 롤아웃) 프로세스 중에 함께 업그레이드되는 노드 그룹 -> Azure가 배포 전체에서 증분 또는 롤링 업그레이드를 수행

• 장애 도메인 : 실패의 물리적 단위를 나타내는 노드 그룹 -> 동일한 물리적 랙에 속하는 노드로 간주 -> 장애 도메인은 단일 실패 지점을 공유하는 공통된 하드웨어(또는 스위치) 집합
  
  
  

• 가용성 집합내 VM은 각각 업데이트 도메인과 장애 도메인에 배치됨

• 업데이트 도메인은 기본 5개, 최대 20개까지 구성 가능

• 한 번에 한 개의 업데이트 도메인만 다시 부팅

• 두 개의 장애 도메인이 함께 동작되어 하드웨어 오류, 네트워크 중단, 전원 중단 또는 소프트웨어 업데이트에 따른 상황을 완화
  
  
  

• 장애 도메인과 가용성 집합 구성

가용성 영역

• 가용성 영역 : 데이터 센터 오류에서 애플리케이션 및 데이터를 보호하는 고가용성 기능 (장애 도메인과 업데이트 도메인의 조합)
  
  
  

• 특징

1. Azure 지역 내의 고유한 물리적 위치
2. 각 영역은 독립된 전원, 냉각 및 네트워킹을 갖춘 하나 이상의 데이터 센터
3. 모든 지역에서 최소한 세 개의 별도 영역이 필요
4. 가용성 영역을 물리적으로 구분하면 애플리케이션 및 데이터를 데이터 센터 오류로부터 보호 가능
5. 영역 중복 서비스는 단일 실패 지점으로부터 보호하기 위해 가용성 영역 전체에서 애플리케이션과 데이터를 복제
   
   
   

Scaling

• 스케일링 기능 : VM 처리량에 하드웨어 리소스를 맞추는 기능
  
  
  

• 수직 스케일링(Scale up/down) : VM의 크기를 늘리거나 줄임

1. 활용률이 낮을 때 비용 절감을 위해 VM크기 줄임
2. 더 많은 처리를 위해 VM크기 늘림
   
   
   

• 수평 스케일링(Scale out/in) : VM 수 조정
  
  
  

• 고려사항

1. 일반적으로 수평 스케일링은 수직 스케일링보다 제한 사항이 적음 : 수직은 지역별로 달라질 수 있음, 수평은 데이터에 대한 액세스가 일시적으로 제한될 수 있음
2. 유연성 고려 : 수평 스케일링이 더 유연
3. 재설정 고려 : 다시 프로비저닝이 필요할 수 있는 경우와 서비스 중단 계획을 고려
   
   
   

Scale Sets

• Azure Virtual Machine Scale Sets : 동일한 VM 세트를 배포 및 관리하는 데 사용할 수 있는 Azure 컴퓨팅 리소스 -> auto scaling 가능
  
  
  

• 특징

1. 모든 가상 머신 인스턴스는 동일한 기본 운영 체제 이미지 및 구성
2. 기본 레이어 4 트래픽 배포를 위해 Azure Load Balancer 사용을 지원하고 고급 L7 트래픽 배포 및 TLS/SSL 종료를 위해 Azure Application Gateway 사용을 지원
3. 중단을 최소화하면서 다른 가상 머신 인스턴스를 통해 애플리케이션에 계속 액세스
4. 고객의 요구를 충족하기 위해 Virtual Machine Scale Sets는 자동 스케일링을 구현
5. 최대 1,000개의 가상 머신 인스턴스를 지원 (사용자 지정 가상 머신 이미지인 경우 최대 600개)
   
   
   

• Scale Sets을 만들기 위한 설정

1. 오케스트레이션 모드 : 가상 머신을 관리하는 방법을 선택 -> 가상 머신 모델을 수동 정의 -> Azure는 해당 모델을 기반으로 동일한 인스턴스를 생성
2. 이미지 : VM의 기본 운영 체제 또는 애플리케이션
3. VM 아키텍처 : x64 또는 Arm64 기반 가상 머신을 선택 가능
4. VM 크기 : 처리 성능, 메모리 및 스토리지 용량 등의 요소를 결정
5. 크기조정 모드
   • 자동 크기 조정 설정
     • 기본 인스턴스 수 : 초기 가상 머신 수(0~1000)
     • 인스턴스 제한 : 스케일 다운하려는 최소 인스턴스 수, 스케일 업하려는 최대 인스턴스 수
     • 스케일 아웃 : 스케일 아웃 자동 크기 조정 규칙을 트리거하기 위한 CPU 사용량 백분율 임계값. 스케일 아웃할 인스턴스 수
     • 스케일 인 : 스케일 인 자동 크기 조정 규칙을 트리거하기 위한 CPU 사용량 백분율 임계값. 스케일 인할 인스턴스 수
     • 쿼리 기간 : 이 기간은 자동 크기 조정 엔진이 메트릭 사용량 평균을 다시 조회하는 시간.
     • 일정: 시작 및 종료 날짜를 지정. 특정 요일에 일정을 반복할 수도 있음
       
       
       

Auto Scaling

• 고려사항

1. 자동 조정된 용량 : 정의된 임계값이 충족되면 자동 크기 조정 규칙이 작동
2. 스케일 아웃 : 구현된 가상 머신 인스턴스의 수를 늘리도록 자동 크기 조정 규칙을 구성
3. 스케일 인 : 감소된 로드가 일정 기간 동안 일관성 있게 유지될 경우 구현된 가상 머신 인스턴스 수를 줄이도록 자동 크기 조정 규칙을 구성
4. 예약 이벤트 : 정해진 시간에 구현의 용량을 자동으로 늘리거나 줄이도록 이벤트를 예약
5. 오버헤드 : 자동 크기 조정과 함께 Azure Virtual Machine Scale Sets를 사용하면 애플리케이션의 성능을 모니터링하고 최적화하는 데 드는 관리 오버헤드 감소 가능