Azure

Azure 는 마이크로소프트가 운영하는 클라우드 플랫폼입니다. 가상 머신이나 저장소 같은 것을 직접 사서 두는 대신 빌려 씁니다. 빌린 것들은 전부 같은 관리 계층을 지나 만들어지고 지워집니다. 어디에 둘지는 리전이라는 단위로 고릅니다.

쉽고 빠른 이해

Azure 는 가상 머신이나 저장소 같은 컴퓨팅 자원을 사지 않고 빌려 쓰게 해주는 클라우드 플랫폼입니다. 가상 머신 한 대를 빌려서 쓰다가 필요 없어지면 지우는 식입니다.

Azure 가 없으면 이런 것들을 직접 사서 데이터센터에 두어야 합니다. 빌려 쓰면 그럴 필요가 없습니다.

어떻게 도는지는 이렇습니다.

무언가를 만들면 그 요청은 정해진 한 곳을 지나 확인을 거친 뒤 처리됩니다
어디에 만들지는 리전 단위로 고릅니다
설정을 거는 관리 범위는 네 단계로 나뉘어 있어 위 단계에서 건 설정이 아래 단계로 물려집니다

대가도 있습니다. 데이터를 어떻게 지킬지, 계정과 접근 권한을 관리하는 일은 언제나 쓰는 사람 몫으로 남습니다. 여러 곳에 나눠 두는 것도 자동으로 되지 않아서, 직접 고르지 않으면 한 곳이 멈췄을 때 같이 멈출 수 있습니다.

상세

Azure 에 무언가를 만들면 그 요청은 Azure Resource Manager 를 지납니다. 공식 문서는 이것을 Azure 의 배포·관리 서비스라고 정의합니다. Resource Manager 가 직접 제공하는 관리 계층이 방금 그 요청이 지난 자리이고, 그 계층이 하는 일은 만들고 고치고 지우는 것을 돕는 것입니다. 배포한 뒤에는 접근 제어, 잠금, 태그 같은 관리 기능으로 지키고 정리한다고 적습니다.

문서는 그 계층이 하나뿐이라는 것을 이렇게 적습니다. Azure 의 API(Application Programming Interface, 응용 프로그램 인터페이스)든 도구든 SDK(Software Development Kit, 소프트웨어 개발 키트)든, 무엇으로 요청을 보내도 Resource Manager 가 그 요청을 받습니다. 인증하고 인가한 다음에 해당 Azure 서비스로 넘깁니다. 모든 요청이 같은 API 로 처리되기 때문에 도구가 달라도 같은 결과와 같은 기능을 보게 된다고 적습니다.

sequenceDiagram
    participant 클라이언트 as API·도구·SDK
    participant ARM as Azure Resource Manager
    participant 서비스 as 해당 Azure 서비스
    클라이언트->>ARM: 요청을 보낸다
    ARM->>ARM: 인증한다
    ARM->>ARM: 인가한다
    ARM->>서비스: 요청을 넘긴다

Azure 를 통해 다룰 수 있는 항목을 리소스라고 부릅니다. 앞 문단에서 요청이 만들고 고치고 지운 것이 바로 이 리소스입니다. 문서가 드는 예는 가상 머신, 스토리지 계정, 웹 앱, 데이터베이스, 가상 네트워크입니다. 리소스 그룹과 구독과 관리 그룹과 태그도 리소스라고 적습니다.

관리 범위 네 단계

문서는 Azure 가 관리 범위를 네 단계로 제공한다고 적습니다. 관리 그룹, 구독, 리소스 그룹, 리소스입니다. 리소스 그룹은 하나의 Azure 솔루션에 딸린 관련 리소스들을 담는 컨테이너입니다. 여러 서류를 한 폴더에 모아 두는 것과 비슷합니다.

어느 단계에나 관리 설정을 걸 수 있고, 어느 단계를 골랐느냐가 그 설정이 얼마나 넓게 적용될지를 정합니다. 낮은 단계는 높은 단계의 설정을 물려받습니다. 문서가 드는 예는 구독에 정책을 걸면 그 구독 안의 모든 리소스 그룹과 리소스에 그 정책이 적용된다는 것입니다.

flowchart TD
    A[관리 그룹] --> B["구독 · 정책을 건다"]
    B -.물려받는다.-> C1[리소스 그룹]
    B -.물려받는다.-> C2[리소스 그룹]
    C1 -.물려받는다.-> D1[리소스]
    C1 -.물려받는다.-> D2[리소스]
    C2 -.물려받는다.-> D3[리소스]

리소스 공급자는 Azure 리소스를 공급하는 서비스입니다. 문서가 드는 흔한 예는 가상 머신 리소스를 공급하는 Microsoft.Compute 입니다.

리전과 가용성 영역

Azure 리전 개요 문서는 전 세계에 70개가 넘는 리전을 제공한다고 적습니다. 리전들은 여러 지오그래피에 걸쳐 놓여 있습니다. 지오그래피 하나가 데이터 상주 경계(데이터가 그 지역 밖으로 나가지 않아야 한다는 경계) 하나를 나타냅니다. 미국이나 유럽 같은 단위이고, 그 안에 리전이 하나 이상 들어갈 수 있습니다. 리전은 데이터센터와 네트워크 설비를 포함하는 물리 시설의 묶음입니다.

리전 하나는 데이터센터 하나 이상으로 이루어집니다. 그 데이터센터들은 대용량 · 장애 내성 · 저지연 네트워크 연결로 이어져 있습니다. Azure 데이터센터는 보통 큰 대도시권 안에 있습니다. 모든 리전은 고정된 데이터 상주 경계 노릇을 하는 하나의 지오그래피 안에 들어갑니다. 지오그래피마다 가용성 영역을 갖춘 리전이 최소 하나 있습니다.

많은 Azure 리전이 가용성 영역을 제공합니다. 리전 안에서 갈라 놓은 데이터센터 묶음입니다. 각 가용성 영역은 독립된 전원, 냉각, 네트워크 설비를 갖습니다. 한 영역에 장애가 나도 남은 영역들이 리전 서비스와 용량과 고가용성을 받칩니다. 가용성 영역 문서는 데이터센터 하나만으로는 이 수준의 보호가 나오지 않는다고 적습니다. 영역들은 보통 몇 킬로미터 떨어져 있고, 대개 서로 100킬로미터 안에 있습니다.

지오그래피 안에 리전이 담기고, 리전 안에 데이터센터가 담기는 것이 기본 구조입니다. 가용성 영역을 제공하는 리전은 한 겹이 더 있습니다 — 그 리전 안의 데이터센터들이 먼저 가용성 영역 묶음으로 갈리고, 각 가용성 영역 안에 데이터센터가 담깁니다.

flowchart TD
    subgraph GEO[지오그래피]
        R1["리전 · 가용성 영역 없음"]
        R1 --> D1[데이터센터]
        R1 --> D2[데이터센터]
        subgraph R2["리전 · 가용성 영역 있음"]
            AZ1[가용성 영역]
            AZ2[가용성 영역]
            AZ1 --> D3[데이터센터]
            AZ2 --> D4[데이터센터]
        end
    end

포기한 것

데이터와 신원까지 맡는 일

공유 책임 모델 문서는 어떤 보안 작업을 클라우드 공급자가 맡고 어떤 작업을 고객이 맡는지를 이해하는 것이 결정적이라고 적습니다. 워크로드(실제로 돌리는 애플리케이션이나 서비스) 책임은 그 워크로드를 SaaS(Software as a Service, 서비스형 소프트웨어), PaaS(Platform as a Service, 서비스형 플랫폼), IaaS(Infrastructure as a Service, 서비스형 인프라), 온프레미스(자체 데이터센터에 서버를 직접 두고 운영하는 방식) 데이터센터 중 어디에 올렸느냐에 따라 갈립니다.

올려두는 계층이 높아질수록 마이크로소프트가 가져가는 칸이 늘어납니다. 물리 데이터센터, 물리 네트워크, 물리 호스트는 IaaS · PaaS · SaaS 어디서나 마이크로소프트 몫입니다. 온프레미스에서만 고객 몫입니다. 운영체제가 경계입니다. 온프레미스와 IaaS 에서는 고객이, PaaS 와 SaaS 에서는 마이크로소프트가 맡습니다.

그런데 계층을 아무리 올려도 넘어가지 않는 칸이 있습니다. 문서는 모든 클라우드 배포 형태에서 데이터와 신원은 고객의 것이라고 못 박습니다. SaaS 를 포함한 모든 배포 형태에서 고객 데이터, 구성과 설정, 신원과 사용자는 언제나 고객 몫입니다. 문서가 이름으로 적어 둔 네 가지는 이렇습니다.

언제나 고객이 지는 것	문서가 적는 범위
데이터	데이터 분류, 데이터 보호, 암호화 결정, 데이터 거버넌스 요구 준수
엔드포인트	클라우드 서비스에 접근하는 클라이언트 장치와 엔드포인트. 모바일 기기, 노트북, 데스크톱
계정	사용자 계정의 생성, 관리, 접근 제거
접근 관리	역할 기반 접근 제어, 다중 인증, 조건부 접근 정책의 구현과 관리

포기한 자리에 남는 것은 경계가 글로 적혀 있다는 사실입니다. Azure 는 고객의 데이터 분류와 암호화 결정을 대신하지 않지만, 어느 칸이 어느 배포 형태에서 누구 몫인지는 표로 못 박아 둡니다. 그래서 SaaS 로 올리든 IaaS 로 올리든 자기가 계속 들고 갈 네 칸이 무엇인지 미리 알고 시작합니다.

이중화를 고르는 일

가용성 영역 문서는 영역 중복 리소스와 영역 리소스를 갈라 적습니다. 복원력은 장애가 나도 서비스가 계속 버티는 성질입니다 — 가용성 영역 하나가 통째로 멎어도 서비스가 안 멈추면 그 서비스는 복원력이 있는 것입니다. 어느 쪽으로 둘지는 고객이 고르고, 고른 쪽에 따라 이 복원력이 있는지가 갈립니다.

구분	문서가 적는 동작
영역 중복 리소스	서비스가 여러 가용성 영역에 걸쳐 복제하거나 분산합니다. 두 개 이상의 영역을 쓰는 한 그 리소스는 영역 장애를 견딥니다
영역 리소스	고객이 직접 고른 가용성 영역 하나에 배포됩니다. 영역 배포는 가용성 영역 장애에 대한 복원력을 자동으로 주지 않습니다

가상 머신 신뢰성 문서는 같은 모양을 SLA(Service Level Agreement, 서비스 수준 계약) 쪽에서 적습니다. Azure 를 쓸 때 신뢰성은 공동 책임입니다. 마이크로소프트는 복원력과 복구를 받치는 기능들을 제공합니다. 고객은 그 기능들이 자기가 쓰는 모든 서비스 안에서 어떻게 도는지 이해하고, 자기 목표와 가동 시간 목표에 맞는 기능을 골라 쓸 책임을 집니다.

SLA 는 각 서비스의 기대 가용성과, 그 가용성을 얻으려면 솔루션이 만족해야 하는 조건을 적어 둡니다. 가상 머신에서 SLA 는 기본 수준의 가용성을 줍니다. SLA 에 정의된 가동 시간 비율은 가상 머신을 둘 이상 두고 다음 중 하나를 했을 때 올라갑니다. 그 가상 머신들을 두 개 이상의 가용성 영역에 걸쳐 배포하거나, 가용성 영역과는 별도로 마련된 배치 단위인 가용성 집합에 넣어 배포하는 것입니다.

Azure 가 복원력의 수준을 대신 정해 주지는 않습니다. 대신 어느 수준이 어떤 조건에서 나오는지를 SLA 에 적어 두고, 가상 머신을 몇 대 두고 어디에 흩을지를 그 조건에 맞춰 고르게 합니다. 한 대만 띄우는 선택지도 그대로 남습니다.

예시

GitLab.com 의 스테이징 데이터베이스

이 사고는 Azure 디스크 스냅샷이 켜져 있지 않았던 것처럼, 보호 장치를 직접 켜 두는 일이 고객 몫으로 남는다는 것을 실제 장애 사례로 보여줍니다. GitLab 이 2017-01-31 데이터베이스 장애의 사후분석을 공개했습니다. 그 글이 Azure 위에 올린 것들을 이름으로 적습니다.

17:20 UTC(Coordinated Universal Time, 협정 세계시), 작업을 시작하기 전에 엔지니어가 프로덕션 데이터베이스의 LVM(Logical Volume Manager, 논리 볼륨 관리자) 스냅샷을 떠서 스테이징 환경에 올렸습니다. 스테이징 데이터베이스를 최신 상태로 만들어 부하 시험을 더 정확하게 하려는 목적이었습니다. 나중에 복구는 그 스테이징 데이터베이스의 사본으로 이루어졌습니다. 사후분석은 그 사본이 다른 리전의 느린 Azure 가상 머신 위에 올려져 있었다고 적습니다.

왜 gitlab.com 복구에 스테이징 데이터베이스가 필요했는지도 그 글이 적습니다. 데이터베이스 서버들에 Azure 디스크 스냅샷이 켜져 있지 않았고, pg_dump 로 도는 주기적 데이터베이스 백업이 동작하지 않고 있었습니다. 보조 데이터베이스 호스트로 페일오버하지 못한 이유도 적혀 있습니다. 보조 데이터베이스의 데이터가 복제를 복구하는 과정에서 지워져서 재해 복구에 쓸 수 없었습니다.

정리하면 이렇습니다.

flowchart TD
    A[Azure 디스크 스냅샷이 꺼져 있었다] --> D[복구할 방법이 없었다]
    B[pg_dump 백업이 동작하지 않고 있었다] --> D
    C[보조 데이터베이스가 복제 복구 중 지워졌다] --> D
    D --> E[남은 것은 스테이징 데이터베이스 사본뿐이었다]
    E --> F[다른 리전의 느린 Azure 가상 머신 위 사본으로 복구했다]

같은 글이 Azure 디스크 스냅샷이 무엇인지도 적습니다. 디스크 전체의 스냅샷을 만드는 데 씁니다. 이 스냅샷은 잃어버린 사용자 계정 하나처럼 개별 데이터 조각을 되돌리는 일을 편하게 해주지는 않습니다. 가능하기는 합니다. 주 목적은 디스크 장애 시 디스크 전체를 복구하는 것입니다. Azure 에서 스냅샷은 스토리지 계정에 속하고, 스토리지 계정은 다시 하나 이상의 호스트(그 스토리지를 실제로 쓰는 컴퓨트 자원)에 연결됩니다. 스냅샷이 개별 파일이 아니라 이 스토리지 계정 단위로 찍히기 때문에, 되돌릴 때도 그 계정에 연결된 디스크 전체가 통째로 돌아옵니다.

Azure Architecture Center 의 cache-aside 예제

Azure 아키텍처 문서는 여러 애플리케이션 인스턴스가 공유할 분산 캐시를 만들 때 Azure Managed Redis 를 고려하라고 적습니다. 예제는 .NET 용으로 쓰인 Redis 클라이언트 라이브러리인 StackExchange.Redis 를 씁니다. Azure Managed Redis 인스턴스에 연결하려면 정적 메서드 ConnectionMultiplexer.Connect 를 부르고 연결 문자열을 넘깁니다.

csharp

// set five minute expiration as a default
private const double DefaultExpirationTimeInMinutes = 5.0;

public async Task<MyEntity> GetMyEntityAsync(int id)
{
    var key = $"MyEntity:{id}";
    var cache = Connection.GetDatabase();
    var json = await cache.StringGetAsync(key).ConfigureAwait(false);
    var value = string.IsNullOrWhiteSpace(json) ? default(MyEntity) : JsonConvert.DeserializeObject<MyEntity>(json);
    if (value == null) // cache miss
    {
        value = ...; // fetch from origin store, code omitted (store-dependent)
        if (value != null)
        {
            await cache.StringSetAsync(key, JsonConvert.SerializeObject(value)).ConfigureAwait(false);
            await cache.KeyExpireAsync(key, TimeSpan.FromMinutes(DefaultExpirationTimeInMinutes)).ConfigureAwait(false);
        }
    }
    return value;
}

문서는 이 GetMyEntityAsync 가 cache-aside 패턴의 구현이라고 적습니다. 키로 캐시에서 항목을 꺼내 봅니다. 캐시에 맞는 것이 없으면 데이터 저장소에서 객체를 가져와 캐시에 넣고 돌려줍니다. 값을 정하는 자리는 DefaultExpirationTimeInMinutes 한 줄입니다. 기본값이 5.0 분이고, 그 값만큼의 만료가 KeyExpireAsync 로 걸립니다. 만료를 거는 이유도 문서가 적습니다. 그 사이에 다른 서비스나 프로세스가 값을 고쳤을 때 캐시에 낡은 값이 남지 않게 하려는 것입니다.

sequenceDiagram
    participant 앱
    participant 캐시
    participant 원본 as 데이터 저장소
    앱->>캐시: 키로 조회한다
    alt 캐시에 있음
        캐시-->>앱: 값을 돌려준다
    else 캐시 미스
        앱->>원본: 객체를 가져온다
        원본-->>앱: 값을 돌려준다
        앱->>캐시: 값을 저장하고 만료를 건다
        캐시-->>앱: 완료
    end

운영

조정할 수 있는 한도와 없는 한도

Azure 구독 한도 문서는 일부 서비스가 조정 가능한 한도를 갖는다고 적습니다. 한도를 조정할 수 있으면 표에 기본 한도와 최대 한도 열이 함께 실립니다. 기본 한도 위로는 올릴 수 있지만 최대 한도 위로는 못 올립니다. 기본 한도 위로 올리려면 온라인 고객 지원 요청을 열면 되고, 이 요청 자체에는 요금이 붙지 않습니다. 무료 Azure 평가판 구독은 한도나 쿼터 상향 대상이 아닙니다. 이 문서에서 한도와 쿼터는 같은 것을 가리키는 말입니다.

구독과 리소스 그룹의 상한

Azure 구독 한도 문서는 관리 그룹부터 리소스 그룹 안의 리소스까지, 범위가 좁아질수록 실무에서 부딪히는 개수 한도를 표로 적어 둡니다(이 표에서는 상한이라고 부릅니다). 가장 넓은 범위인 Microsoft Entra 테넌트(조직 하나를 나타내는 단위. 그 조직이 쓰는 구독과 사용자가 여기 속합니다)부터 리소스 그룹까지 좁혀지면서 상한이 갈립니다.

범위	항목	값
관리 그룹	Microsoft Entra 테넌트당 관리 그룹	10,000
관리 그룹	관리 그룹당 구독	무제한
관리 그룹	계층 깊이	루트 단계 + 6단계
관리 그룹	관리 그룹 수준 배포	800
구독	Microsoft Entra 테넌트에 딸린 구독	무제한
구독	구독당 리소스 그룹	980
구독	Azure Resource Manager API 요청 크기	4,194,304 바이트
구독	구독당 태그, 직접 붙인 것	50
구독	구독 수준 배포	800
구독	구독 수준 배포의 위치	10
리소스 그룹	리소스 종류별 리소스	800
리소스 그룹	배포 이력에 남는 배포	800
리소스 그룹	배포 하나에 든 리소스	800
리소스 그룹	고유 범위당 관리 잠금	20
리소스 그룹	리소스나 리소스 그룹당 태그	50

리소스 종류별 800 에는 예외가 있습니다. Azure 구독 한도 문서는 일부 리소스 종류가 이 값을 넘을 수 있다고 적고 그 목록을 따로 둡니다. 표가 보여주는 것은 이렇습니다 — 관리 그룹과 구독 수준은 사실상 여유롭지만(관리 그룹 만 개, 구독 수 무제한), 범위가 리소스 그룹 안으로 좁혀지면 종류별 800 이라는 훨씬 촘촘한 벽에 먼저 부딪힙니다.

템플릿 한 벌의 상한

Resource Manager 템플릿은 Resource Manager 가 리소스를 만들 때 쓰는 배포 파일입니다. 그 안에 담는 매개변수, 변수, 리소스, 출력 각각에도 상한이 있습니다.

항목	값
매개변수	256
변수	256
리소스, 복사 개수 포함	800
출력	64
템플릿 크기	4 MB(Megabyte, 메가바이트)
리소스 정의 크기	1 MB

복사 개수를 포함한다는 것은, 리소스 정의 하나를 여러 벌로 반복해 만드는 복사 기능으로 늘어난 리소스도 이 800 안에 함께 센다는 뜻입니다. 템플릿을 짤 때는 이 여섯 항목을 함께 놓고 어디서 상한에 먼저 닿을지 봐야 합니다.

vCPU 쿼터는 리전마다 따로

vCPU 는 가상 CPU(Central Processing Unit, 중앙처리장치) 입니다. Azure 구독 한도 문서는 vCPU 쿼터가 리전 단위로 관리된다고 적습니다. 워크로드에 필요한 쿼터를 리전 하나마다 정하고, 배포하려는 리전마다 그 양을 따로 요청합니다. 문서가 드는 예는 이렇습니다. West Europe 에서 30 vCPU 를 써야 하면 West Europe 에 30 vCPU 를 콕 집어 요청합니다. 그렇게 해도 다른 어느 리전의 vCPU 쿼터도 올라가지 않습니다.

Azure

상세

관리 범위 네 단계

리전과 가용성 영역

포기한 것

데이터와 신원까지 맡는 일

이중화를 고르는 일

예시

GitLab.com 의 스테이징 데이터베이스

Azure Architecture Center 의 cache-aside 예제

운영

조정할 수 있는 한도와 없는 한도

구독과 리소스 그룹의 상한

템플릿 한 벌의 상한

vCPU 쿼터는 리전마다 따로

관련 항목

관리와 배포

컴퓨트

저장과 데이터

네트워크

신원과 보안

관측과 이전

이것이 놓이는 물리 단위

이것에 적용되는 규칙·원칙

예시가 보여주는 기법