System
Microsoft Azure
Azure Training
Az-900 : Region

Az-900 : Region

Azure 글로벌 인프라 아키텍처

Microsoft Geography

  • Azure는 전 세계를 지정학적 경계 또는 국가 경계로 정의되는 지리적 위치로 분할합니다.

  • Azure Geography란 일반적으로 데이터 상주성 및 규정 준수 경계를 유지하는 두 개 이상의 Azure 지역을 포함하고 있는 별도의 시장을 의미합니다.

  • Azure Geography을 사용하면 아래와 같은 이점을 가질 수 있습니다.

    • 지리적 위치를 통해 특정 데이터 상주성 및 규정 준수 요구 사항이 있는 고객은 데이터와 애플리케이션을 가깝게 유지할 수 있습니다.

    • 지리적 위치는 지리적 경계 내에서 데이터 상주성, 주권, 규정 준수 및 복원력 요구 사항이 지켜지도록 보장합니다.

    • 지리적 위치는 전용 대용량 네트워킹 인프라 전체에 걸쳐 발생하는 Azure 지역 전체 장애를 견디는 내결함성을 갖고 있습니다.

  • Azure의 Geography는 아래와 같이 4개로 분류됩니다.

    • 아메리카

    • 유럽

    • 아시아 태평양

    • 중동 및 아프리카

 

Azure Region

  • Azure Region은 서로 가까운 곳에 있고 대기 시간이 짧은 네트워크를 통해 연결된 데이터 센터를 하나 이상 포함하고 있는 지리적 영역을 의미합니다.

  • Azure는 전 셰계에 위차한 데이터 센터로 구성

  • 최소 한 개 이상의 데이터 센터를 포함

  • 데이터 센터는 서로 근접한 위치에 있어 네트워크의 대기 시간이 짧은 특징을 가짐

  • Region은 각 지역에 맞는 Geography에 구성됩니다.

 

  • Region Pairs

  • 각 Azure 지역은 300마일 이상 떨어져 있는 동일한 지리적 위치(예: 미국, 유럽 또는 아시아) 내의 다른 Azure 지역과 항상 쌍을 이룹니다.

  • Region Pairs를 통해 한 지리적 위치에서 가상 머신 스토리지 같은 리소스를 복제할 수 있으며, 이렇게 하면 두 Azure 지역에 동시에 영향을 주는 자연재해, 내전, 정전 또는 물리적 네트워크 중단 등의 이벤트 때문에 서비스가 중단될 가능성을 줄일 수 있습니다.

  • 각 Azure region은 다른 region과 페어링 연결되어 있습니다.

  • 특정 서비스는 paired region 사이의 자동 복제기능을 제공

  • region 장애 시, paired 된 리전을 복제하는 것이 우선시 되어짐

 

  • 특수 Azure Region

    • US DoD 중부, US Gov 버지니아, US Gov 아이오와 등 : 미국 정부 기관 및 파트너를 위한 물리적 및 논리적 네트워크로 격리된 Azure 인스턴스입니다. 이러한 데이터 센터는 선별된 미국인이 운영하며 추가 규정 준수 인증서를 포함하고 있습니다.

    • 중국 동부, 중국 북부 등 : 이러한 지역은 Microsoft 및 21Vianet 간의 고유한 파트너십을 통해 사용할 수 있으며, Microsoft에서 데이터 센터를 직접 관리하지 않습니다.

 

  • Region을 사용하는 이유

    • 보다 쉽게 확장이 가능하게 하는 확장성

    • 한 리전에 문제가 발생시 다른 리전에서 서비스가 가능토록 하는 가용성

    • 한국 중부, 한국 남부는 짝꿍 리전으로 한 리전이 오류가 발생 시 다른 리전에서 대신 서비스하도록 설정되어 있음

 

가용성 옵션 ( Availability Options )

  • 가용성 영역은 Azure 지역 내에서 물리적으로 분리된 데이터 센터입니다.

  • Vm을 나눠서 생성함으로써, 끊어지지 않는 연속적인 서비스가 가능토록 하는 개념

  • 프로미엄 스토리지를 사용하면 99.9%의 연결성을 보장해주지만, 일반적인 경우에는 가용성 집합 혹은 가용성 영역을 생성하는 것이 권장되어짐

    • 가용성 집합 (Availability sets)

      • 유지 관리 혹은 하드웨어 오류 발생 시에도 응용 프로그램을 온라인 상태로 유지하는 서비스

      • Update domains (US) : 예약된 유지관리, 성능 또는 보안 업데이트는 업데이트 도메인을 통해 순서가 정해짐

      • Fault domains (FD) : 데이터 센터 내에서 여러 하드웨어서 워크로드르 물리적으로 분

     

    • 가용성 영역 ( Availability zones )

      • Azure Region 내에서의 물리적으로 분리된 영역

      • 가용성 영역보다 한 단게 확장된 개념

      • 하나 혹은 이상의 데이터센터로 구성되고 독립된 전원, 쿨링, 네트워크를 가짐

      • 독립된 영역으로 동작

 

Azure SLA (서비스 수준 계약)

  • Microsoft는 포괄적인 운영 정책, 표준 및 관례를 준수함으로써 고객에게 우수한 품질의 제품 및 서비스를 제공하기 위해 최선을 다하고 있습니다.

  • Azure 제품 및 서비스의 SLA는 세 가지 주요 특징을 가지고 있습니다.

    • 성능 목표

      • SLA는 Azure 제품 또는 서비스의 성능 목표를 정의합니다. SLA가 정의하는 성능 목표는 각 Azure 제품 및 서비스로 한정됩니다. 예를 들어 일부 Azure 서비스의 성능 목표는 작동 시간 보증 또는 연결률로 표현됩니다.

     

    • 작동 시간 및 연결 보증

      - **일반적인 SLA는 해당하는 각 Azure 제품 또는 서비스의 성능 목표 약정을 99.9%("3개의 9")에서 99.999%("5개의 9") 사이에서 지정합니다. 이러한 목표는 서비스의 작동 시간 또는 응답 시간 같은 성능 기준에 적용할 수 있습니다.**

- SLA % |	주간 가동 중지 | 시간	월간 가동 중지 시간 |	연간 가동 중지 시간

      — | — | — | — 99 | 1.68시간 | 7.2시간 | 3.65일 99.9 | 10.1분 | 43.2분 | 8.76시간 99.95 | 5분 | 21.6분 | 4.38시간 99.99 | 1.01분 | 4.32분 | 52.56분 99.999 | 6초 | 25.9초 | 5.26분

     

    • 서비스 크레딧

      • 또한 SLA는 Azure 제품 또는 서비스가 관련 SLA 사양을 수행하는 데 실패할 경우 Microsoft에서 어떻게 대응할 것인지를 설명합니다.

      • 99.9 -> 10

      • 99 -> 25

      • 95 -> 100

 

Azure SLA를 통한 앱 안정성 향상

  • SLA를 사용하여 Azure 솔루션이 클라이언트와 사용자의 비즈니스 요구 사항 및 수요를 얼마나 충족하는지 평가할 수 있습니다.

  • 고유한 SLA를 만들어서 고객의 특정 Azure 애플리케이션에 맞는 성능 목표를 설정할 수 있습니다. 이 접근 방식을 애플리케이션 SLA라고 합니다.

  • SLA를 사용한 이점

    • 앱 요구 사항 이해

      • 효율적이고 신뢰할 수 있는 Azure 솔루션을 빌드하려면 워크로드 요구 사항을 알아야 합니다.

     

    • 복원력

      • 복원력은 오류를 복구하여 계속 작동하는 시스템 기능입니다. 오류를 방지하는 것이 아니라 가동 중지 또는 데이터 손실을 방지하는 방법으로 오류에 대응하는 것입니다.

     

    • 비용 및 복잡성과 고가용성

      • 가용성이란 시스템이 정상적으로 작동하는 시간을 말합니다. 가용성을 최대화하려면 가능한 서비스 오류를 방지하는 수단을 구현해야 합니다.

     

    • 애플리케이션 SLA를 정의할 때 고려할 사항

      • 플리케이션 SLA에서 정의하는 성능 목표가 4개의 9(99.99%)인 경우 수동 작업으로 오류를 복구하면 SLA를 충족하기에 충분하지 않을 수 있습니다. Azure 솔루션이 자체적으로 진단하고 자체적으로 복구해야 합니다.

      • 4개의 9보다 높은 SLA 성능 목표를 충족하도록 신속하게 오류에 대응하기는 쉽지 않습니다.

      • 애플리케이션 SLA 성능 목표를 측정할 시간 범위를 신중하게 고민해야 합니다. 시간 범위가 짧을수록 허용 오차도 작습니다. 애플리케이션 SLA를 시간 단위 또는 일 단위 가동 시간으로 정의하는 경우 허용 오차가 작으면 성능 목표를 달성하지 못할 수 있다는 점을 이해해야 합니다.

 

RSS Feed
마지막 수정일자
Az-900 : CloudComputingAz-900 : 관리옵션