Google Cloud 전문가용 Azure

  • 아티클

이 문서는 Google Cloud 전문가가 Microsoft Azure 계정, 플랫폼, 서비스의 기본 사항을 이해하는 데 도움이 됩니다. 또한 Google Cloud 및 Azure 플랫폼 간의 주요 유사점과 차이점을 다룹니다. (Google Cloud는 이전에 GCP(Google Cloud Platform)라고 했습니다.)

다음 내용을 배웁니다.

  • Azure에서 계정 및 리소스가 구성되는 방식.
  • Azure에서 사용 가능한 솔루션이 구성되는 방식.
  • 주요 Azure 서비스가 Google Cloud 서비스와의 다른 점.

Azure와 Google Cloud는 시간에 관계없이 각 기능을 독립적으로 개발했기 때문에 각 기능의 구현 및 디자인에서 큰 차이를 보입니다.

Google Cloud용 Azure 개요

Google Cloud와 마찬가지로, Microsoft Azure는 핵심 컴퓨팅, 스토리지, 데이터베이스 및 네트워킹 서비스 세트를 중심으로 빌드됩니다. 두 플랫폼이 제공하는 제품과 서비스의 기본적인 사항은 동일한 경우가 많습니다. Google Cloud와 Azure 모두 Linux 또는 Windows 호스트를 기반으로 고가용성 솔루션을 빌드할 수 있습니다. 따라서 Linux 및 OSS 기술을 사용하여 개발하는 데 익숙한 분들은 어느 플랫폼으로도 작업을 수행할 수 있습니다.

두 플랫폼의 기능은 유사하지만, 기능을 제공하는 리소스는 종종 다르게 구성됩니다. 솔루션을 빌드하는 데 필요한 서비스 간에 항상 정확한 일대일 관계가 성립하는 것은 아닙니다. 다른 경우에는 특정 서비스가 한 플랫폼에만 제공되고 다른 플랫폼에는 제공되지 않습니다.

계정 및 구독 관리

Azure에는 리소스를 효과적으로 관리하기 위한 관리 그룹과 구독 및 리소스 그룹의 계층이 있습니다. 이는 Google Cloud의 리소스에 대한 폴더 및 프로젝트 계층과 유사합니다.

관리 그룹이 루트이고 구독 및 리소스 그룹이 리프 노드인 트리 구조를 보여주는 다이어그램입니다.

Azure 수준의 관리 범위

  • 관리 그룹: 이러한 그룹은 여러 구독의 액세스, 정책 및 규정 준수를 관리하는 데 도움이 되는 컨테이너입니다. 관리 그룹에 속하는 모든 구독은 관리 그룹에 적용되는 조건을 자동으로 상속합니다.
  • 구독: 구독은 사용자 계정 및 해당 사용자 계정으로 만든 리소스를 논리적으로 연결합니다. 각 구독에는 리소스를 만들고 사용할 수 있는 제한양 또는 할당량이 있습니다. 조직에서는 구독을 사용하여 사용자, 팀 또는 프로젝트에서 만든 리소스 및 그로 인한 비용을 관리할 수 있습니다.
  • 리소스 그룹: 리소스 그룹은 웹앱, 데이터베이스, 스토리지 계정과 같은 Azure 리소스가 배포되고 관리되는 논리적 컨테이너입니다.
  • 리소스: 리소스는 가상 머신, 스토리지 또는 SQL 데이터베이스처럼 사용자가 만드는 서비스의 인스턴스입니다.

조직의 규모와 요구 사항에 따라 여러 가격 책정 옵션을 사용하여 Azure 서비스를 구입할 수 있습니다. 자세한 내용은 가격 책정 개요 페이지를 참조하세요.

Azure 구독은 대금 청구 및 권한 관리 책임이 있는 소유자가 할당된 리소스 그룹입니다.

Google Cloud 프로젝트는 청구, 할당량 및 제한 측면에서 Azure 구독과 개념적으로 유사합니다. 그러나 기능적 관점에서 Google Cloud 프로젝트는 Azure의 리소스 그룹과 더 유사합니다. 클라우드 리소스가 배포되는 논리적 단위입니다.

Google Cloud와 달리 Azure 구독의 최대 수는 없습니다. 각 Azure 구독은 단일 Microsoft Entra 테넌트(Google Cloud 용어의 계정)에 연결됩니다. Microsoft Entra 테넌트에는 무제한의 구독이 포함될 수 있는 반면 Google Cloud는 계정당 30개의 프로젝트로 제한됩니다.

구독에는 세 가지 유형의 관리자 계정이 할당됩니다.

  • 계정 관리자 구독에 사용된 리소스 요금이 청구되는 구독 소유자 및 계정입니다. 구독 소유권을 양도하여 계정 관리자를 변경하는 것만 가능합니다.
  • 서비스 관리자 이 계정은 구독에서 리소스를 만들고 관리할 수 있는 권한을 갖고 있지만 대금 청구를 처리하지는 않습니다. 기본적으로 계정 관리자 및 서비스 관리자는 동일한 계정에 할당됩니다. 계정 관리자는 구독의 기술 및 운영적 측면을 관리할 별도의 사용자를 서비스 관리자 계정에 할당할 수 있습니다. 구독당 서비스 관리자를 한 명만 할당할 수 있습니다.
  • 공동 관리자 한 구독에 공동 관리자 계정을 여러 개 할당할 수 있습니다. 공동 관리자는 서비스 관리자를 변경할 수 없지만 구독 리소스와 사용자를 완전하게 제어할 수 있습니다.

Azure 리소스에 대한 세분화된 액세스 관리를 위해 70개 이상의 기본 제공 역할이 포함된 Azure RBAC(Azure 역할 기반 액세스 제어)를 사용할 수 있습니다. 자체 사용자 지정 역할을 만들 수도 있습니다.

구독 수준 아래에서 사용자 역할 및 개별 권한을 특정 리소스에 할당할 수도 있습니다. Azure에서 모든 사용자 계정은 Microsoft 계정 또는 조직 계정(Microsoft Entra ID를 통해 관리되는 계정)과 연결됩니다.

구독에는 기본 서비스 할당량 및 제한이 있습니다. 전체 제한 목록은 Azure 구독 및 서비스 제한, 할당량 및 제약 조건을 참조하세요. 관리 포털에서 지원 요청을 제출하여 이러한 제한을 최대값까지 높일 수 있습니다.

참고 항목

리소스 관리

Azure에서 "리소스"라는 용어는 모든 컴퓨팅 인스턴스, 스토리지 개체, 네트워킹 디바이스 또는 플랫폼 내에서 만들거나 구성할 수 있는 기타 엔터티를 의미합니다.

Azure 리소스는 두 가지 모델, 즉 Azure Resource Manager 또는 기존 Azure 클래식 배포 모델 중 하나를 사용하여 배포 및 관리됩니다. 모든 새 리소스는 Resource Manager 모델을 사용하여 만듭니다.

리소스 그룹

또한 Azure에는 VM, 스토리지, 가상 네트워킹 디바이스 등의 리소스를 구성하는 "리소스 그룹"이라는 엔터티가 있습니다. Azure 리소스는 항상 하나의 리소스 그룹과 연결됩니다. 한 리소스 그룹에서 생성된 리소스를 다른 그룹으로 이동할 수 있지만, 한 번에 한 리소스 그룹에만 소속될 수 있습니다. 자세한 내용은 리소스 그룹, 구독 또는 지역 간 Azure 리소스 이동을 참조하세요. 리소스 그룹은 Azure Resource Manager가 사용하는 기본적인 그룹화 방법입니다.

태그를 사용하여 리소스를 구성할 수도 있습니다. 태그는 리소스 그룹 멤버 자격에 관계없이 구독의 리소스를 그룹화할 수 있는 키-값 쌍입니다.

관리 인터페이스

Azure는 리소스를 관리하는 여러 방법을 제공합니다.

  • 웹 인터페이스. Azure Portal은 Azure 리소스에 대한 완전한 웹 기반 관리 인터페이스를 제공합니다.
  • REST API. Azure Resource Manager REST API는 Azure Portal에서 사용 가능한 대부분의 기능에 대해 프로그래밍 방식의 액세스를 제공합니다.
  • 명령줄. Azure CLI는 Azure 리소스를 만들고 관리할 수 있는 명령줄 인터페이스를 제공합니다. Azure CLI는 Windows, Linux 및 macOS에서 사용할 수 있습니다.
  • PowerShell. PowerShell용 Azure 모듈을 사용하면 스크립트를 사용하여 자동화 관리 작업을 실행할 수 있습니다. PowerShell은 Windows, Linux 및 macOS에서 사용할 수 있습니다.
  • 템플릿. Azure Resource Manager 템플릿은 JSON 템플릿 기반 리소스 관리 기능을 제공합니다.
  • SDK. SDK는 사용자가 Azure 서비스를 프로그래밍 방식으로 관리하고 상호 작용할 수 있도록 하는 라이브러리 컬렉션입니다.

이러한 각 인터페이스에서 리소스 그룹은 Azure 리소스를 만들고 배포하고 수정하는 데 있어서 핵심적인 역할을 합니다.

또한 Hashicorp's Terraform 및 Netflix Spinnaker 같은 여러 타사 관리 도구도 Azure에서 사용할 수 있습니다.

참고 항목

영역 및 가용성 영역

오류는 해당 영향의 범위가 다를 수 있습니다. 실패한 디스크와 같은 일부 하드웨어 오류는 단일 호스트 컴퓨터에 영향을 줄 수 있습니다. 실패한 네트워크 스위치는 전체 서버 랙에 영향을 줄 수 있습니다. 데이터 센터의 전원 손실 등 전체 데이터 센터를 방해하는 오류는 일반적이지 않습니다. 드문 경우지만 전체 지역을 사용할 수 없게 될 수 있습니다.

중복성을 통해 애플리케이션을 복원력 있게 만들 수 있습니다. 그러나 애플리케이션을 디자인할 때 이러한 중복성에 대해 계획해야 합니다. 또한 필요한 중복성 수준은 비즈니스 요구 사항에 따라 달라집니다. 모든 애플리케이션이 지역 정전 사태를 방지하기 위해 여러 지역에 중복성이 필요한 것은 아닙니다. 일반적으로 중복성과 안정성 및 고비용과 복잡성 간에 균형을 조절해야 합니다.

Google Cloud에서 지역에는 두 개 이상의 가용성 영역이 있습니다. 가용성 영역은 지리적 지역에 물리적으로 격리된 데이터 센터와 일치합니다. Azure에는 가용성 집합, 가용성 영역 및 쌍을 이루는 지역 등 각 잠재적 오류 수준에서 중복되는 애플리케이션을 제공하기 위한 여러 기능이 있습니다.

다음 표에서는 각 옵션을 요약합니다.

가용성 집합 가용성 영역 쌍을 이루는 지역
오류의 범위 랙 데이터 센터 지역
요청 라우팅 Load Balancer 영역 간 부하 분산 장치 Traffic Manager
네트워크 대기 시간 매우 낮음 낮음 중간부터 높음
가상 네트워킹 VNet VNet 지역 간 VNet 피어링

가용성 집합

디스크 또는 네트워크 전환이 실패한 경우 하드웨어 오류로부터 보호하려면 가용성 집합에 둘 이상의 VM을 배포합니다. 가용성 집합은 공통 전원 소스 및 네트워크 스위치를 공유하는 두 개 이상의 장애 도메인으로 구성됩니다. 가용성 집합의 VM은 장애 도메인에 분산되어 있으므로 하드웨어 오류가 하나의 장애 도메인에 영향을 주는 경우 네트워크 트래픽은 다른 오류 도메인에서 VM을 라우팅할 수 있습니다. 가용성 집합에 대한 자세한 내용은 Azure에서 Windows 가상 머신의 가용성 관리를 참조하세요.

가용성 집합에 추가되는 VM 인스턴스에는 업데이트 도메인이 할당됩니다. 업데이트 도메인은 동시에 계획된 유지 관리 이벤트를 수행하도록 설정된 VM 그룹입니다. VM을 여러 업데이트 도메인에 분산하면 계획된 업데이트 및 패치 이벤트가 지정된 시간에 이러한 VM의 하위 집합에만 영향을 줍니다.

각 역할의 한 인스턴스가 정상적으로 작동하려면 애플리케이션의 인스턴스 역할을 통해 가용성 집합을 구성해야 합니다. 예를 들어 3계층 웹 애플리케이션에서는 프런트 엔드, 애플리케이션 및 데이터 계층에 대한 별도의 가용성 집합을 만듭니다.

웹 인스턴스가 있는 웹 계층, 앱 인스턴스가 있는 앱 계층, 데이터베이스 인스턴스가 있는 데이터 클러스터에 대한 가용성 집합이 포함된 다이어그램입니다.

가용성 집합

가용성 영역

Google Cloud처럼 Azure 지역에는 가용성 영역이 있을 수 있습니다. 가용성 영역은 Azure 지역 내에서 물리적으로 별도의 영역입니다. 각 가용성 영역에는 고유한 소스, 네트워크 및 냉각 장치가 있습니다. 가용성 영역 간에 VM을 배포하면 데이터 센터 전체의 오류로부터 애플리케이션을 보호할 수 있습니다.

세 영역을 모두 교차하는 서브넷이 있는 세 영역이 포함된 지역이 있는 영역 중복 가상 머신 배포를 보여주는 다이어그램입니다.

Azure에서 영역 중복 VM 배포

자세한 내용은 가용성 영역 및 지역 사용에 대한 권장 사항 참조하세요.

쌍을 이루는 지역

지역 가동 중단으로부터 애플리케이션을 보호하려면 인터넷 트래픽을 서로 다른 지역에 배포하는 Azure Traffic Manager를 사용하여 애플리케이션을 여러 지역에 배포할 수 있습니다. 각 Azure 지역은 다른 지역과 쌍을 이룹니다. 이러한 지역은 함께 지역 쌍을 구성합니다. 브라질 남부를 제외하고 지역 쌍은 세금 및 법률 집행 관할 구역의 데이터 상주 요구 사항을 충족하기 위해 동일한 지리적 위치 내에 위치합니다.

데이터 센터가 물리적으로 떨어져 있지만 비교적 가까운 영역에 있는 가용성 영역과는 달리, 쌍을 이루는 지역은 일반적으로 480킬로미터 이상 떨어져 있습니다. 이 설계는 대규모 재해가 발생하더라도 쌍을 이루는 지역의 한 쪽 지역만 영향을 받게 합니다. 인접한 쌍은 데이터베이스 및 스토리지 서비스 데이터를 동기화할 때 설정할 수 있으며, 쌍을 이루는 지역 중 한 번에 한 영역에서만 플랫폼 업데이트가 수행되도록 구성됩니다.

Azure 지역 중복 스토리지는 적절한 쌍을 이루는 지역에 자동으로 백업됩니다. 그 외 리소스의 경우 쌍을 이루는 지역을 사용하여 완전한 이중화 솔루션을 만든다는 것은 두 영역 모두에 솔루션 전체 복사본을 만든다는 의미입니다.

다이어그램은 Azure의 지역 쌍을 보여줍니다. 지역에는 각각 데이터 센터를 포함하는 두 지역을 포함하는 지역 쌍이 포함됩니다.

Azure의 지역 쌍

참고 항목

서비스

플랫폼 간 서비스 맵핑 방법 목록은 Google Cloud와 Azure 서비스 비교를 참조하세요.

지역에 따라 일부 Azure 제품 및 서비스가 제공되지 않을 수도 있습니다. 자세한 내용은 지역별 제품 페이지를 참조하세요. 서비스 수준 계약 페이지에서 각 Azure 제품 및 서비스의 작동 시간 보장 및 가동 중지 시간 크레딧 정책을 확인할 수 있습니다.

다음 단계