2. 가상 머신 가용성 구성

유지 관리 및 가동 중지 시간 계획

Azure VM 쓰다가 얘기치 못한 중단이 생길 수 있음. 만약을 대비한 무언가가 있어야 함.

• 계획되지 않은 하드웨어 유지 관리
  • 하드웨어에 연결된 플랫폼 요소가 실패로 예측되면 발생
  • 실시간 마이그레이션 지원
    • 오류 예측되면 멀쩡판 PC로 자동 마이그레이션
    • 잠깐 VM 일시 중지됨
    • 이벤트 전후에 성능 저하 가능성 있음
• 얘기치 않은 가동 중지 시간
  • VM의 하드웨어 or 실제 인프라에 문제 발생
  • 로컬 네트워크 오류, 디스크 오류 등
  • VM을 정상적인 PC로 마이그레이션
  • 복구 중 재부팅 발생, 경우에 따라 임시 드라이브 손실
• 계획된 유지 관리
  • = 업데이트

가용성 집합 만들기

가용성 집합 = VM 그룹 배포를 위한 논리적 기능 그룹화 << 한개 실패해도 다른거 영향 안받음 데이터 센터 OS 업데이트 동안 모든 컴퓨터가 업데이트 되면 싹 다 중단되니까.. 이 일이 발생하지 않게 하는거임 ㅇㅇ 이렇게 해서 가용성 집합의 VM은 여러 물리적 서버, 컴퓨팅 랙, 스토리지 단위, 네트워크 스위치 등등에서 실행되게 됨.

가용성 집합에 대해 알아야 할 사항

가용성 집합의 몇 가지 특성을 좀 짚어보자.

• (가용성 집합의)모든 VM은 같은 기능 집합을 수행해야함
• (가용성 집합의)모든 VM은 같은 소프트웨어 설치돼있어야 함
• 오류 발생 시 가용성 집합의 VM의 하위 집합만(??) 영향 받음
  • 애플리케이션 계속 가동, 고객도 계속 사용 가능
• VM, 가용성 집합 동시 생성 가능
  • VM 생성 시 결정한 가용성 집합은 수정 불가능
  • 가용성 집합 변경하려면 삭제하고 다시 만들어야 함 ㅋㅋ
• Azure Portal, ARM(Azure Resource Manager) 템플릿, 스크립팅 도구, API 등 사용하여 가용성 집합 빌드 가능
• MS Azure에서 SLA 제공

가용성 집합에 VM 추가해도 완전 보호 되는건 아님! 애플리케이션 수준에서 보호하려면 다른 복구 / 백업 기술 써야함.

가용성 집합 사용 시 고려사항

안정적인 클라우드 솔루션 만들 때 가용성 집합은 필수임 (안정적이어야 함 → 중단없어야함 → 가용성 집합) 근데 주의할 점이 있음

• 중복 고려
  • 중복성 구현하려면 여러 가용성 집합에 VM 배치해야 함
• 애플리케이션 계층의 분리 고려
  • 각 애플리케이션 계층은 별도의 가용성 집합에 있어야 함(??)
  • 이러한 분리는 단일 지점에서 생긴 오류를 완화하는데 도움 됨
• 부하 분산 고려
  • Azure Load Balancer로 부하 분산된 가용성 집합 만들자
    • 고가용성, 네트워크 성능 굿
• 관리 디스크 고려
  • 블록 수준 스토리지를 위한 가용성 집합에서, VM과 Azure 관리 디스크 사용 가능

업데이트 도메인, 장애 도메인 검토

Azure VM Avaiability Sets(가용성 집합) 애플리케이션 배포 / 업그레이드 시, 고가용성, 내결함성 유지에 도움 되는게 이씨음. 업데이트 도메인, 장애 도메인 << 이 둘임. 가용성 집합의 각 VM은 하나의 업데이트 도메인, 하나의 장애 도메인에 배치됨.

업데이트 도메인

• 서비스 업그레이드 or 롤아웃 중 함께 업그레이드 되는 노드 그룹
• 배포 전체에서 증문, 롤링 업그레이드 수행 가능
• 각각의 업데이트 도메인 << 동시 업데이트, 재부팅 가능한 VM + 물리 하드웨어 세트 포함
• 예정된 업데이트 시 한번에 하나의 업데이트 도메인만 재부팅
• Default 5개 업데이트 도메인
  • 사용자 커스텀 불가
• 최대 20개 업데이트 도메인 구성 가능

장애 도메인

실패의 물리적 단위 나타내는 노드 그룹. 동일한 (물리적)랙의 노드를 장애 도메인으로 간주. 그러니까 서버 랙(컴퓨터 넣는 선반같은거) 하나를 하나의 장애 도메인으로 보는 것 같음.

• 단일 실패지점 공유하는 공통된 하드웨어 집합 공유하는 VM 그룹 정의
  • 전원, 네트워킹 스위치 세트로 서비스되는 서버 랙 등
• 두 개의 장애 도메인은 함께 작동함
  • 하드웨어 오류, 네트워크 중단 등에 대한 상황 완화

그림을 보자. 2개의 랙 각각에 VM이 두 개씩 있음. 랙은 각각 장애 도메인으로 표현될 수 있음.

하나의 장애 도메인에서, VM은 각자 다른 가용성 집합에 있음. 웹 가용성 집합(위의 하얀 네모)에는 두 개의 VM이 있으며 각자 다른 장애 도메인에 속함. SQL 가용성 집합(아래의 하얀 네모)도 마찬가지임.

이렇게 해놓으면 웹의 VM 하나가 고장나도 다른 가용성 집합에서 돌리면 됨 와 안전하다!

가용성 영역 검토

“가용성 영역은 데이터 센터 오류에서 애플리케이션 및 데이터를 보호하는 고가용성 기능입니다” “Azure 지역의 가용성 영역은 장애 도메인과 업데이트 도메인의 조합입니다”

자료에 계속 같은 말이 나옴. 했던말 또 한다? 이거 중요하다는 말 아니겠냐.

아무튼, Azure 지역의 3개 영역에서 VM 만드는 시나리오를 생각해보자. 이 VM들은 3개의 장애 도메인, 3개의 업데이트 도메인에 분산될 것임. 이렇게 해야 업데이트 있을 때 동시에 이뤄지지 않음. 동시에 업데이트하면 앱 못쓰니까 사고잖음. 이렇게 가용성 영역으로 영역 내부에서 리소스를 공동 배치하고 다른 영역으로 복제해서 고가용성 만드는겨.

가용성 영역에 대해 알아야 할 사항

• 가용성 영역은 Azure 지역 내 고유한 물리적 위치.
• 각 영역은 독립된 환경(냉각, 네트워크 등)을 가진 하나 이상의 데이터센터.
• 복원력 보장을 위해 활성화된 모든 지역에서 최소 3개의 별도 영역 필요.
• 한 지역 내 가용성 영역의 물리적 구분 → 데이터센터 보호
• 영역 중복 서비스 << 가용성 영역 전체에서 애플리케이션, 데이터 복제

가용성 영역 사용 시 고려해야 할 사항

가용성 영역 지원하는 Azure 서비스는 두 카테고리로 나눌 수 있음.

• 영역 서비스
  • 각 리소스를 특정 영역에 고정
  • VM, Azure managed disks, Std IP Addr 등
• 영역 중복 서비스
  • 모든 영역에서 자동 복제
  • 영역 중복 Azure Storage, Azure SQL DB 등

수직, 수평 스케일링 비교

마찬가지로 AZ-900과 겹치는 내용. 하드웨어 리소스 가용성, VM 처리량 비례하게 스케일링. VM의 응답 시간, 처리량에 부정적 영향 없으면서 증가하는 요청 처리 가능. 대부분 수평, 수직 두 가지로 구현됨.

수직 스케일링

스케일 업, 스케일 다운 이라고도 표현함. 워크로드에 따라 VM의 “규모를” 늘리거나 줄임. 스케일 업은 VM이 더 강해지는거, 스케일 다운은 VM이 더 약해지는거겠지 ㅇㅇㅇ

수직 스케일링 사용 시 유리한 경우

• 주말에 안쓰면 VM 스케일 다운, 비용 절감
• 스케일 업으로 VM 더 안만들어도 되도록 크기 늘림

수평 스케일링

스케일 아웃, 스케일 인 이라고도 함. 수직 스케일링이 VM의 성능을 조절했다면, 수평 스케일링은 VM의 수를 조절함.

그림으로 보면 이해가 쉽죠잉

수직 및 수평 스케일링 사용 시 고려해야 할 사항

• 제한 사항 고려
  • 수평 스케일링 제한 <<< 수직 스케일링 제한
  • 수직 스케일링: 하드웨어 가용성에 따라 좌우되는 구현
    • 상한 도달 빠름
    • 지역별로 상한 달라짐
    • 일시적으로 VM 재부팅 해야함 → 앱, 데이터 접근 일시 제한 가능성
• 유연성 고려
  • (클라우드에서) 수평 스케일링이 더 유연
  • 수천개의 VM 실행으로 워크로드, 처리량 변화 관리 가능
• 재(다시) 프로비저닝 고려
  • re-provisioning: 기존 VM 제거, 새 VM으로 교체
  • re-provisioning이 필요한 경우 데이터 유지관리, PC 마이그레이션 필요한지 확인해야

Azure VM Scale Sets 구현

Azure VM Scale Sets << 동일한 VM 세트 배포, 관리하는데 씀. VM Scale Sets 구현 + 모든 VM 동일 방식 구성 = 진정한 자동 스케일링 수요 변동에 따라 VM 수 자동으로 늘리거나 줄임.

VM Scale Sets 쓰면 VM 미리 프로비저닝 할 필요가 없음. 대규모 서비스 쉽게 만들 수 있음. 자동으로 스케일 조정됨. VM을 추가 or 제거하는 과정은 수동으로 하거나 자동으로 하거나 둘이 섞을 수도 있음.

Azure VM Scale Sets에 대해 알아야 할 사항

• 모든 VM 인스턴스는 동일한 OS image, 구성에서 생성됨
  • 추가 구성 작업, 네트워크 관리 없이 수백개 VM 쉬운 관리 가능
• Layer4 트래픽 배포를 위해 Azure Load balancer 사용 지원
  • 고급 L7 트래픽 배포, TLS/SSL 종료를 위한 Azure Application Gateway 지원
• 애플리케이션의 여러 인스턴스 실행 가능
  • VM 중 하나에 문제 생기면 중단 최소화 하며 다른 VM으로 돌려버림, 계속 사용 가능
• 요구사항 충족을 위한 자동 스케일링 구현
• 최대 1000개 VM 인스턴스 지원
  • 사용자 고유, 사용자 지정 VM Image 만들고 업로드 하는 경우 최대 600개

VM Scale Sets 만들기

Azure Portal에서 구현 가능. VM 수, 크기, Azure Spot 인스턴스, 관리디스크, 할당 정책 사용을 위한 설정 가능.

• 오케스트레이션 모드
  • VM 관리 방법 선택
  • 같은 구성의 VM 수동으로 만들어 확장 집합에 추가 가능
  • 균일한 오케스트레이션 모드: VM 모델 정의, 이 모델 기반으로 동일한 인스턴스 생성
• 이미지
  • VM의 OS, 애플리케이션 선택
• VM Architecture
  • VM 실행할 x64 or ARM64 선택 가능
  • x64 << 가장 높은 소프트웨어 호환성
  • ARM64 << 50% 더 뛰어난 가성비
• 크기
  • 처리성능, 메모리, 스토리지 용량 등
  • VM크기, OS 종류에 따라 시간당 요금 청구

고급 탭의 기능

• 분산 알고리즘
  • 장애 도메인 전체에서 VM 균형 결정
  • 최대 분산: 각 영역에서 최대한 많은 장애 도메인에 분산
  • 고정 분산: 항상 5개의 장애 도메인에 분산
    • 가용 장애 도메인이 5개 미만인 경우 ‘고정 분산’ 쓰는 확장 집합은 실패함
    • → 최대 분산을 쓰는게 좋음!

자동 스케일링 구현

Azure VM Scale Sets로 VM 인스턴스 수 자동으로 조절 가능하다 했제 자동 크기 조정이라고 한다는데 뭐 당연한거 아니겠냐. 워크로드 수요에 맞춰 동적으로 확장할 수 있다는데.. 똑같은 말 계속 하는거 보니 중요한가보다.

불필요한 VM 수 최소화 함. 일정한 수준의 성능 계속 누릴 수 있음.

자동 크기 조정 사용 시 고려 사항

회사 내 웹 사이트 구현에 어떻게 도움될런지 잘 생각해보자.

• 용량 자동 조정 고려
  • 임계값 충족 → 이벤트 발생 → 용량 조정
• 스케일 아웃 고려
  • 꾸준히 수요 증가한다면 VM 수 늘리도록 규칙 지정 가능
• 스케일 인 고려
  • 작업 수행에 필요한 수만 쓰도게 VM 수 줄임
• 예약된 이벤트
  • 정해진 시간에 정해진 용량을 줄이거나 늘이게 예약 가능
• 오버헤드 고려
  • 자동 크기 조정 + VM Scale Set → 모니터링, 최적화 관리를 위한 오버헤드 감소

자동 크기 조정 구성

Azure Portal에서 VM Scale Set 구현할 때 수동 or 자동 크기 조정 설정 가능. 제대로 쓰려면 VM의 최대, 최소, 기본 수 정의해야 함.

크기 조정 모드

• 수동 업데이트
  • 인스턴스 수 << 확장 집합의 VM 수로 설정
  • 스케일 인 정책 구성하여 VM이 삭제되는 순서 정함
  • 높은 인스턴스 ID부터 삭제되게 선택 가능
• 자동 크기 조정
  • 일정에 따라 용량 자동 조정 가능
  • 사용 가능한 최대 가상 머신 수 지정

자동 크기 조정 구성

자동 크기 조정 << 크기 조정 조건을 기반으로 함

• 기본 인스턴스 수
  • 초기 VM 수 (0 ~ 1000)
• 인스턴스 제한
  • 스케일 다운 하려는 최소 인스턴스 수
  • 스케일 업 하려는 최대 인스턴스 수
• 스케일 아웃
  • 자동 스케일링 규칙을 트리거 할 CPU 사용량 %
  • 스케일 아웃 할 인스턴스 수
• 스케일 인
  • 자동 스케일링 규칙을 트리거 할 CPU 사용량 %
  • 스케일 인 할 인스턴스 수
• 쿼리 기간
  • 조건을 충족하는지 확인하는 기간.
  • 1시간에 한번 검색하여 스케일 조정 여부 결정, 1일에 한번 검색하여… 이런 뜻인 것 같음
• 일정
  • 시작, 종료일 지정
  • 특정 요일에 일정 반복하게 지정 가능