Cloud 기초 || 랜딩존, 클라우드 환경 토대가 되는 요소들 Landing Zone Architecture & Naming Rule

클라우드 서비스를 진행하기 전에 네트워크 정책, 사용자 권한(IAM), 보안 정책 및 태깅정책 등  등 클라우드 운영 전반적인
운영에 대한 기초 정책/구조 구성을 하는 것이 랜딩존 구축이다.

클라우드 서버 환경에 띄울 리소스를 선정하는 것부터 어떤 식의 운영정책 / 권한정책 / 네이밍 정책을 할 것인지
전반적으로 가이드를 설정하는 토대 공사 / 철조 공사라고 생각하면 될 것 같다.

 

사람이 없는 조직에서 클라우드로 무언가 해보려고 하다보면
찔끔찔끔 IaaS 업무들, ETL 구성까지 관여해야 하는 상황이 오기 마련이다.

 

 

Azure IaaS 체크리스트를 만들다가 정리하는 클라우드 아키텍처 요소들

- AWS든 GCP 든 기능/명칭 거의 동일하나 일부 명칭은 Azure의 네이밍을 중심으로 정리한다.

• Virtual Machine (가상 머신)
  • 클라우드에서 호스팅되는 가상 컴퓨터로,  가상 머신을 사용하면 필요한 운영 체제, 미들웨어 및 애플리케이션을 설치하고 실행할 수 있다. 이후의 작업들과 정책들은 이 가상 머신 실행을 위한 빌드업이라고 보면 된다.

• Virtual Network (가상 네트워크)
  • Azure에 호스팅되는 가상 네트워크로, 가상 네트워크 상에 필요한 수만큼의  가상 머신(VM)을 운영할 수 있다.
• Subnet (서브넷)
  • 서브넷은 가상 머신의 서버를 구성할 때 사용되며,
    가상 네트워크 내에서 IP 주소 공간을 분할하는 형태로 이뤄진다.
    
    
• Network Security Group (네트워크 보안 그룹)
  • Azure 환경 내에서 보안 정책을 설정하는 영역으로, VM 및 서브넷에 대한 인/아웃바운드 트래픽을 제어한다.
  • IAM (Identity and Access Management) 
    : 클라우드 서비스에서 제공하는 사용자, 그룹 및 권한 관리 서비스로, 인프라 담당자가 클라우드 운영시 가장 많이 체크하게 되는 영역이다. 사용자 및 사용자 그룹의 권한과 액세스 범위를 정의한다.
  • RBAC (Role-Based Access Control) 기반 제어
    : 클라우드환경에서  정의한 역할 기반으로 액세스 제어하는 형식으로 IAM과 함께 겸용해 사용한다.
       (ex) 보안정책 관리자, 네트워크 관리자, 가상머신 관리자 등등 특정 레벨과 관리 권한을 정의해서 활용한다./ 
  • MFA (Multi-Factor Authentication) 설정
    : 시스템에 사용자가 로그인 시 시스템 보안의 기본인 2차 인증, 다양한 인증 요소를 사용하여 보안을 강화하는 방식으로, 상용서비스를 위한 클라우드 환경은 기본적으로 2차 이상 인증을 유지한다.
    
    
• Availability Set (가용성 집합)
  • 가상 머신을 묶어서 가용성을 높이는 데 사용됩니다. 가용성 집합에 가상 머신을 배치하면 가상 머신 간에 물리적인 분리가 유지되며, 가상 머신의 가용성이 향상됩니다.
• Load Balancer (로드 밸런서)
  • 가상 머신 간에 트래픽을 분산하는 데 사용됩니다. 로드 밸런서를 사용하면 단일 IP 주소로 여러 가상 머신에 대한 트래픽을 분산할 수 있습니다.

---

 

필요한 만큼 대여하는 클라우드 인프라 특성상 기본적으로 클라우드는 공간 분리 / 태깅 관리가 중요하다.

비용관리 관점에서도 상세하게 리소스 네이밍 규칙을 정하고 이를 준수해야 한다.

클라우드 환경에서 Naming Rule이 중요한 이유를 요약하면,

• 프로덕션, 개발, 테스트 및 QA 환경 분리를 명시한다.
  : Prod 환경에서는 정식 운영을 위한 배포를 수행하고, 그 전까지 새로운 기능 개발 및 테스트는 별도의 Dev/환경에서 수행한다. 프로젝트의 범위에 따라서 그리고 비용 커버 범위에 따라서 QA / Test 환경은 Optional이다. 그러나 스타트업이나 개인 프로젝트가 아닌 이상 굵직한 프로젝트엔 Test / QA 서버를 분리한다. (물론 중간 필요 시점부터)
  
  
• 리소스 추적과 효율적 스펙관리의 기본이 된다.
  환경이 Dev냐 Prod냐에 리소스의 스펙이 다르게 책정될 수 있다. 개발이나 테스트 환경에서는 Prod보다 저사양의 가상 머신이 필요할 수 있다.습니다. 따라서, 네이밍 및 태깅을 사용하여 각 리소스가 어떤 환경에 할당되어 있는지 추적할 수 있습니다.
  
  
• 명시된 환경별로 요구되는 보안정책도 상이하다.
  : 대상이 되는 환경에 따라 요구되는 보안정책이 달라지고 보안항목의 구성이 달라질 수 있다.
    다른 것 보다 실제 모든 운영 서비스 올라가는 Prod(프로덕션) 환경에서의 보안정책이 가장 강력해야 한다.
    클라우드 환경에서 이 보안정책이라는 게 강하면 강해질수록 장치 관점이나 관리 관점에서 비용이 증가한다.

그렇다면 우리는 어떻게 네이밍 해야 하는가?
사내에서 커스텀하는 방식에 따라 조금씩은 달라지겠지만 히스토리상 꼭 들어가야 하는 요소는
리소스의 유형 / 서비스 / 환경 / 역할 + 넘버이다.

   예시 1) type - service - environment - role - resource - numbering
          - vm-web-prod-frontend-01
          - vm-web-prod-backend-01
          - vm-app-prod-frontend-01
          - vm-app-prod-backend-01

   예시 2) service - environment - role - resource - numbering

          - web-prod-backend-01
          - db-prod-backend-01

• type: 리소스의 유형
           (ex) 가상 머신의 'vm'
• service: 리소스가 속한 서비스, 보통 클라우드 환경 자체가 분리되어 큰 이슈가 없긴하지만
                여러 서비스와 구분하기 경우 필요에 따라 서비스명을 prefix로 넣기도 한다. (명시적인 것은 협업의 기본)
           (ex) 'web'은 웹 서비스를, 'db'는 데이터베이스
• environment: 리소스의 환경을 명시하는 값
           (ex) 'prod'는 서비스 프로덕션 환경을, 'dev'는 개발 환경, 'qa'는 QA 환경을 나타낸다.
• role: 리소스의 역할을 명시하는 값
          (ex) 'frontend' 프론트엔드 서버, 'backend'는 백엔드 서버를 지칭한다.
• resource number: 여러 개의 동일 유형의 리소스를 사용하는 경우 마지막으로 넘버링으로 구분해 진행한다.

이와 같은 네이밍 룰을 통해 명확한 리소스를 인지하고, 사용량 및 이슈 모니터링이 용이해진다.

+ Azure의 네이밍툴도 팁으로 공유

     https://github.com/microsoft/CloudAdoptionFramework/tree/master/ready/AzNamingTool

GitHub - microsoft/CloudAdoptionFramework: Code samples and extended documentation to support the guidance provided in the Micro