Azure Landing Zone 이란?

Azure Landing Zone 이란?

Landing Zone(랜딩존)이란 말 그대로 착륙 공간을 의미합니다. 이를 클라우드 인프라 환경으로 접목시켜 본다면, 클라우드 인프라를 처음 시작하는 기업 들에게 안정적인 초기 클라우드 환경을 제공해주는 개념과 같습니다.

이는 마치 실제 사회에서 도시 계획을 세우듯 클라우드 인프라를 시작함에 앞서 적재 적소에 알맞은 인프라 요소를 배치하는 설계 계획과 같다고 볼 수 있습니다.

랜딩존의 개념은 각 클라우드 벤더 마다 그 개념과 필요 구성 요소, 구현 방식이 존재합니다.

이번에 소개할 Azure Landing Zone은 Azure 클라우드를 도입하는 기업과 유저들 에게 Azure 클라우드 사용에 보다 유용하고 안정적인 운영 환경을 위해 갖추어야할 구성요소들을 포함하는 하나의 플랫폼과 같다고 말할 수 있습니다.

이번 글에서는 이러한 Azure Landing Zone의 목적과 구성 요소에 대해 다뤄보도록 하겠습니다.

Azure Landing Zone의 목적

Azure 랜딩존은 마치 추상적인 개념처럼 느껴질 수 있지만, 자세히 들여다 보면 Azure 클라우드 인프라를 사용해 하나의 환경을 구축하는 인프라 프로젝트로 생각할 수 있습니다.

앞서 말했듯이 Azure 랜딩존 구축의 목적은 본격적인 클라우드 인프라를 전개하기 전에 클라우드 사용시 고려해야 하는 인프라 규정 및 보안 기준 그리고 운영 필요 요소 등을 설계하고 이를 재사용 할 수 있도록 하는데 그 목적이 있습니다.

또한, 랜딩존은 재사용성이 있으면 더욱 좋습니다. 랜딩존을 통해 설계된 규정 및 보안 기준이 갖춰진 하나의 랜딩존 플랫폼을 추후 새로운 클라우드환경이 필요할 경우(ex: 신설 부서) 이미 규정이 녹여진 랜딩존 설계도를 재사용 한다면, 보다 생산적이고, 효율적인 인프라 환경 구축이 가능해집니다.

Azure Landing Zone의 설계 구성 요소

Azure 랜딩존 설계 시 아래와 같이 5가지의 구성요소를 고려할 수 있습니다.
1. IAM / Resource Organization
2. Governance
3. Security
4. Networking
5. Monitoring / Business Continuity

1. IAM / Resource Organization

IAM (Identity and Access Management)

Azure 클라우드는 Active Directory 기반의 사용자 관리에 최적화 되어 있습니다.

Azure의 자격 증명 주체는 User(사용자)와 Application(애플리케이션) 2가지가 존재하며, Azure Active Directory 에서 등록 및 관리 할 수 있습니다.
(*Application은 Azure 클라우드에 프로그래밍 방식으로 접근할 때 사용 되는 자격 증명 주체 입니다.)

랜딩존 에서는 이러한 자격 증명 주체 관리 및 권한 부여에 대해 미리 계획하고 설계 해야 합니다. 이때 고려 대상으로는 아래 항목에 대해 상세하게 설계할 수 있습니다.

• Azure RBAC
  Azure에는 Directory Role이라 불리는 Azure AD Role(AAD Role)과 Resource Role이라 불리는 Azure Role이 있습니다. AAD Role은 이름에서 유추할 수 있듯이 Directory 관리에 한정된 권한이며, 실제 리소스 관리에 사용 되는 역할은 Azure Role을 통해 리소스에 대한 권한을 컨트롤 할 수 있습니다. 따라서 랜딩존 설계 시 디렉토리 운영자와 리소스 관리자 등 다양한 이해관계자들에게 적절한 권한을 부여하고 이를 감시할 수 있도록 설계해야 합니다.
• Azure Access Management
  Azure는 AAD를 통해 클라우드 접근제어를 구현할 수 있습니다.
  AAD는 대표적으로 Free, Premium P1, Premium P2의 3가지 Tier가 존재하며, 각 티어별로 지원하는 접근제어 기능에 차이가 존재합니다. 간단한 예시로 Free 버전도 사용자 MFA를 무료로 제공하지만, Premium Directory를 사용하게 되면 MFA 주기 및 정책을 상세하게 컨트롤 할 수 있습니다. 또한, 위치 기반, 아이피 기반의 클라우드 접근제어, JIT(Just In Time)정책 등과 같은 추가 기능도 Premuim Directory를 사용해야 구현이 가능합니다. 이는 기업의 보안 요구 수준에 맞춰 AAD의 Premium 유료 라이선스 구매 필요 유무를 결정하고 이에 맞춰 클라우드 접근제어 설계를 구현해야 할 것 입니다.

Resource Organization

Resource Organization Diagram리소스 조직 체계를 설명하기에 앞서 Azure는 기본적으로 아래와 같은 계층 구조를 사용할 수 있습니다.

Tenant(Tenant Root Group)
-> Management Group
-> Subscription
-> Resource Group
-> Resource

테넌트를 하나의 논리적인 클라우드 환경으로 볼 수 있으며, 그아래 관리그룹이 존재하고, 그 아래 여러 구독을 생성하여 실제 리소스를 배포하게 됩니다.

Azure 랜딩존 에서는 향후 인프라 운영 및 관리를 고려하여 리소스 조직 체계를 설계해야 하며, 이를 통해 인프라 리소스 자산 식별과 빌링 체계를 쉽게 파악할 수 있도록 준비해야 합니다.

Azure 에서는 리소스 구성 체계에 도움이 되는 도구로서 Management Group를 사용할 수 있습니다. (기본적으로 테넌트 생성시 Tenant Root Group이라는 관리그룹이 존재하며 이를 기본값으로 사용하게 됩니다.)

Management Group은 하나의 테넌트를 논리적으로 구분하여 구독을 그룹화하여 관리하고, 사용자 관리와 정책 적용을 분할된 환경에서 수행 할 수 있습니다. 즉, 관리그룹을 사용하게 되면 클라우드 비용 관리와 클라우드 정책 적용, 사용자 관리를 하나의 테넌트 에서 구분지어 수행할 수 있는 장점이 있습니다.

이는 큰 규모의 기업에서 부서별로 관리그룹을 할당하여 클라우드 인프라 관리에 도움을 줄 수 있는 방안입니다. 그리 큰 규모가 아닐 경우 구독과 리소스 그룹을 통해 인프라 환경을 구분 지을 수 있습니다.

여기에 리소스 명명규칙과 태그기준을 정하여 자산 식별을 편리하게 해야하며, 이를 통해서도 인프라 환경을 구분 지어 관리될 수 있도록 기준을 마련해야 합니다. 명명규칙과 태그의 예시는 다음과 같습니다.

• 명명규칙

  <환경>-<목적>-<리소스명>-<Number>
  prd-app-vm-###

• 태그

  Environment: Production
  Service: AppStore
  Team: InfraPart-1

2. Governance

클라우드 에서의 거버넌스는 함축적인 의미를 담고 있습니다.

앞서 말한 IAM/Resource Organization을 통해 Identity의 기준과 리소스의 일관성을 유지하고, 보안 기준과 기업 규정을 설계하고, 비용 관리 기준을 마련할 수 있습니다.

이 글에서 설명드릴 내용은 Azure에서 거버넌스를 형성하는 서비스인 Azure Policy를 사용하여 Azure 거버넌스를 구현하는 것에 대해 소개합니다.

Azure Policy는 Json기반으로된 클라우드 정책 설계 도구입니다. 정책이라는 말 그대로 클라우드 환경에 일종의 규칙과 제약을 가할 수 있습니다. 이를 활용하여 무분별한 클라우드 사용에 제약을 가하고, 예측 가능하고 일관성 있는 클라우드 환경을 설계할 수 있습니다.

아주 작은 예시로는, 허용되지 않는 지역에 리소스 배포를 금지하거나, 특정 SKU만을 생성 가능하도록 하고, 리소스 태깅 자동화 혹은 누락에 대한 경고 표시 등을 구현할 수 있습니다.

이 외에도 기본적으로 제공되는 다양한 기관의 클라우드 정책을 할당하거나 기업 환경에 필요한 정책을 커스텀하여 사용할 수 있으며, 할당된 정책의 준수 정도를 평가하여 현재 클라우드 환경이 규정을 준수하는지 모니터링 할 수 있습니다.

3. Security

Azure는 'Microsoft Defender for Cloud' 라는 SaaS 형태의 보안 서비스를 기본적으로 제공해주고 있습니다. 이 기능을 활성화 하여 클라우드 전반의 잠재되어 있는 보안 위협을 식별하고 현재 보안 상태를 평가해 줍니다.

Defender의 기능은 라이선스 유무에 따라 다양한 기능을 제공하며, 랜딩존 에서는 적재 적소에 필요한 기능을 선택하여 활성화 하고, 관리자가 보안 준수 상태를 지속적으로 평가할 수 있도록 환경을 마련 해야 합니다. 주요 기능으로는 Workload Protection, Security Alerts, 보안 점수 평가 등이 있습니다.

추가적으로, Azure의 KMS 서비스로 많이 사용 되는 Key Vault는 워크로드에 필요한 다양한 비밀, 자격증명을 중앙에서 관리할 수 있도록 해줍니다. 랜딩존에서는 키볼트의 접근제어정책을 보다 상세하게 설계하여 안전한 접근환경을 마련해야 합니다.

4. Networking

인프라 구축에 기본이 되는 네트워킹은 랜딩존의 핵심 요소입니다. 각 조직마다 요구하는 워크로드와 연결 방식이 다양하며, 이에 따라 알맞은 아키텍쳐를 도출해 내야 합니다.

간단한 예시로 IaaS / PaaS 등 리소스의 대분류에 따라 Azure에서 지원하는 네트워킹 설계가 달라집니다. 네트워크 형상을 '허브 & 스포크'로 가져갈지, 글로벌 vWAN환경이 필요할지, On-Premise 네트워크와의 사설 연결이 필요한지 등 다양한 고려 사항이 존재합니다.

예를들어 검토해볼 만한 네트워크 요구사항은 다음과 같습니다.

1. 가상네트워크의 필요성 → IaaS or PaaS
2. 여러 VNET과의 연결 필요성 → VNET Peering, Hub-Spoke, vWAN
3. Azure VNET과 온프레미스 간의 연결 필요성 → VPN Gateway, Express Route
4. 라우팅 및 방화벽 요구 수준 → UDR, NSG, Azure Firewall
5. 외부 트래픽에 대한 In/Out Bound 필터링 및 방화벽 수준, 부하 분산 필요성 → Azure Firewall, Application Gateway with WAF, Front Door
6. 글로벌 서비스의 필요성 → Front Door, Traffic Manager
7. DNS 관리의 필요성 → Azure DNS, VM for DNS

5. Monitoring / Business Continuity

Monitoring

Azure에서는 모니터링 서비스로서 Azure Monitor 서비스를 사용하게 됩니다. Azure Monitor는 Azure 클라우드 플랫폼 및 리소스의 로그/메트릭 데이터를 제공하며, 클라우드 서비스에 대한 성능과 가용성을 모니터링 할 수 있습니다.

Azure Monitor는 플랫폼 로그(Activity Log, Azure AD Log), 플랫폼 메트릭(Perfomance Metric)과 같은 데이터를 기본 제공하며 적절한 모니터링 대상 선정과 모니터링 옵션 활성화를 통해 모니터링 데이터의 수집수준, 저장 기간, 저장 방법, 시각화, 알람설정 등을 필요에 맞게 설계해야 합니다.

• Diagnostic Setting (진단설정)

  각 리소스 별로 기본제공되는 로그 이상으로 상세한 수준의 로그를 제공받을 수 있습니다. 이러한 로그는 Azure Log Analytics Workspace로 보내 분석 하고 시각화 하거나, Storage에 적재하여 영구 보관할 수 있으며, 이벤트 드라이븐 리소스에 연결하여 외부환경에 로그를 보낼 수 있습니다.

• Insights

  주요 리소스 별로 Insights 기능을 활성화 하여 Log Analytics Workspace로 데이터를 저장하고 이를 Workbook 대시보드 에서 미리 준비된 시각화 대시보드를 제공받을 수 있습니다.

• Log Analytics Workspace

  Azure Monitor에 저장되고 소멸하는 로그 데이터를 사용자 환경에 적재하여 쿼리를 통해 분석하고 이를 시각화 할 수 있습니다, 로그 데이터의 저장기간을 최대 2년으로 늘릴수도 있습니다.

• Application or OS (Application Insights for APM, LA / Monitor Agent)

  APM 수준의 모니터링이 필요한지, OS 수준의 모니터링이 필요한지 여부를 체크하여 APM 혹은 에이전트를 통한 OS 수준 모니터링을 계획할 수 있습니다.

• Network Monitoring (Network Watcher, NSG Flowlogs)

  네트워크 모니터링 수준을 정하고, 네트워크 로그와 시각화 방법을 구체화 해야 합니다. 네트워크 와쳐와 이를 사용한 NSG Flowlogs는 IaaS 수준에서 활용할 수 있는 모니터링 서비스로서 네트워크 패킷을 캡쳐하여 분석할 수 있고, 트래픽의 흐름을 시각화하여 제공받을 수 있습니다.

Business Continuity

백업과 가용성, 재해복구는 예기치 못한 상황에도 높은 서비스 가용성 수준을 유지하게 해줍니다.

Azure 리소스 별로 백업 옵션과 가용성, 재해복구 서비스가 존재하기 때문에, 중요 워크로드 및 서비스를 선정하고, 필요한 가용성 수준, 백업 빈도와 백업데이터 보존 기간, 복원 속도, 재해복구의 필요성을 고려하여 알맞은 비즈니스 연속성을 설계해야 합니다.

대표적인 리소스에 대한 예시는 아래와 같습니다.

• IaaS VM

  Azure Recovery Service Vault를 통해 백업 주기와 보존기간, 복구 시간을 상세하게 설정할 수 있으며, 디스크 수준의 백업은 Azure Backup 서비스를 통해 구현할 수 있습니다.
  DR 구성은 Site Recovery 서비스를 사용해 Regional Fail에 대비할 수 있으며, 기본적인 가용성 옵션으로는 Availability Zone(DC 수준), Availability Set(랙 수준, 유지보수 관리) 과 같은 VM 가용성 옵션을 적극적으로 사용해야 합니다.

• PaaS Compute / DB

  기본적으로 내장된 백업 서비스를 사용하게 되며, 높은 트래픽 발생시 자동 스케일 아웃 설정을 통해 가용성을 유지할 수 있습니다.

• Storage

  Azure 저장소 서비스의 경우 LRS/ZRS/GRS/RA-GRS/RA-GZRS 와 같은 데이터 복제-저장 수준을 선택해 데이터의 가용성을 설계 할 수 있습니다. 위 내용을 간단하게 말하면, DC 내부/DC 단위/Region 단위와 같이 데이터를 복제하여 안전하게 저장하는 수준을 말합니다. 각 옵션에 따른 비용차이도 고려하여 설계해야 합니다.

구현 옵션

위에서 설명한 요소들을 구현하기 위한 랜딩존의 구현 옵션으로는 기본적으로 Azure Portal, Azure CLI, Azure Powershell 등을 통해 구현할 수 있지만, Terraform과 같은 IaC 도구를 사용하면 코드 자체로서 랜딩존의 설계도가 될 수 있으며, 향후 새로운 환경에 반복하여 사용시 효율적으로 활용할 수 있습니다.

추가적으로 직접 사용해보진 않았지만, Terraform 퍼블릭 모듈 중 Azure Landing Zone CAF 모듈이 존재하며, 이를 사용해 랜딩존을 배포할 수도 있습니다.

마치며

클라우드 사용에는 다양한 요구사항과 제약조건이 존재할 수 있습니다. 따라서, 적재 적소에 필요한 리소스와 기능을 선택하고, 이를 검증하고, 구현 해야 합니다.

또한, 작은 규모로 시작해 그 규모를 확장 할 수 있도록 하거나 반복적으로 사용할 수 있는 설계를 해야 할 것 입니다.

이번 글을 통해 추상적으로 느껴지는 클라우드 랜딩존 이라는 개념이 조금이나마 구체화 되었길 바랍니다.

감사합니다.
(이 글은 미디엄에서 22.09.15일에 작성한 글입니다.)