RESOURCES

Amazon Web Services(AWS) 사용자 중에서는 보안 제어 규정 준수를 유지하면서 AWS에서 팀의 배포를 가속화하는 방법을 궁금해하는 경우가 많습니다. 오늘 포스팅에서는 성숙한 조직에서 팀의 AWS 배포를 관리하기 위해 도입한 일반적인 거버넌스 모델에 대해 알아보고자 합니다. 이러한 모델은 클라우드 인프라 배포의 성숙도를 높이는 데 가장 잘 사용됩니다.

AWS 배포를 위한 거버넌스 모델

 

성숙한 클라우드 채택자가 AWS에서 인프라 배포를 관리하는 데 사용하는 세 가지 공통 모델을 구분합니다. 모델은 제어 대상(인프라 코드, 배포 도구 체인 또는 프로비저닝된 AWS 리소스)이 다릅니다. 다음과 같이 모델을 정의합니다.

 

1. 애플리케이션 팀이 배포와 함께 재사용할 수 있는 선별된 배포 템플릿의 저장소를 제공하는 중앙 패턴 라이브러리
2. CI/CD(Continuous Integration/Continuous Delivery)는 애플리케이션 팀에서 재사용할 수 있는 도구 체인 표준을 제공합니다.
3. 중앙 관리형 인프라 – 애플리케이션 팀이 중앙 운영 팀에서 관리하는 AWS 리소스를 배포할 수 있습니다.

 

애플리케이션 팀에 얼마나 많은 책임을 전가할지 결정하는 것은 자율성, 운영 모델, 애플리케이션 유형 및 변경 속도에 따라 다릅니다. 세 가지 모델을 함께 사용하여 다양한 사용 사례를 처리하고 영향을 극대화할 수 있습니다. 일반적으로 조직은 중앙 패턴 라이브러리에서 사전 승인된 배포 템플릿을 수집하여 시작합니다.

 

모델 1: 중앙 패턴 라이브러리

 

이 모델을 통해 클라우드 플랫폼 엔지니어는 팀이 인프라를 코드 템플릿으로 참조할 수 있는 중앙 패턴 라이브러리를 게시합니다. 애플리케이션 팀은 중앙 저장소를 분기하거나 템플릿을 자체 저장소에 복사하여 템플릿을 재사용합니다. 애플리케이션 팀은 AWS CodePipeline을 사용하여 자체 배포 AWS 계정 및 파이프라인과 리소스 프로비저닝 프로세스를 관리하는 동시에 AWS CodeCommit과 같은 서비스와 함께 중앙 패턴 라이브러리의 템플릿을 재사용할 수도 있습니다. 그림 1은 이 거버넌스 모델의 개요를 제공합니다.

 

중앙 패턴 라이브러리는 재사용 가능한 자산을 통해 가장 방해가 적은 형태의 지원을 나타냅니다. 애플리케이션 팀은 배포 프로세스 및 도구 체인에 대한 자율성을 유지할 수 있는 중앙 패턴 라이브러리 모델을 높이 평가합니다. 기존 템플릿을 재사용하면 팀의 첫 번째 인프라 템플릿 생성 속도가 빨라지고 태그 지정 정책 및 보안 제어와 같은 정책 준수가 쉬워집니다. 재사용 가능한 템플릿이 애플리케이션 팀의 리포지토리에 있는 후 템플릿이 향상되면 중앙 라이브러리에서 증분 업데이트를 가져올 수 있습니다. 이를 통해 팀은 적합하다고 판단될 때 당길 수 있습니다. 팀의 리포지토리를 변경하면 연결된 인프라 코드를 배포하는 파이프라인이 트리거됩니다.

 

중앙 패턴 라이브러리 모델을 통해 애플리케이션 팀은 자동화된 배포의 이점을 얻기 위해 리소스 구성 및 CI/CD 도구 체인을 자체적으로 관리해야 합니다. 모델 2는 이 문제를 해결합니다.

 

모델 2: 서비스로서의 CI/CD

 

모델 2에서 애플리케이션 팀은 AWS Service Catalog에서 관리되는 배포 파이프라인을 시작합니다 . 여기에는 애플리케이션을 실행하는 데 필요한 인프라 코드와 종단 간 배포 흐름을 보여주는 “hello world” 소스 코드가 포함됩니다.

클라우드 플랫폼 엔지니어는 서비스 카탈로그 포트폴리오(이 경우 CI/CD 도구 체인)를 개발합니다. 그런 다음 애플리케이션 팀은 파이프라인 코드의 인스턴스와 채워진 Git 리포지토리를 배포하는 AWS Service Catalog 제품을 시작할 수 있습니다(그림 2).

 

파이프라인은 리포지토리가 채워진 직후에 시작되어 “hello world” 애플리케이션이 첫 번째 환경에 배포됩니다. 인프라 코드(예: Amazon Elastic Compute Cloud[Amazon EC2] 및 AWS Fargate)는 애플리케이션 팀의 리포지토리에 있습니다. 증분 업데이트는 AWS Service Catalog에서 제품 업데이트를 시작하여 가져올 수 있습니다. 이를 통해 응용 프로그램 팀은 적절하다고 판단될 때 당길 수 있습니다.

 

이 거버넌스 모델은 여러 팀과 AWS 계정에 리소스를 프로비저닝하는 종단 간 배포 자동화를 제공하므로 전체 스택 책임 또는 플랫폼 프로젝트가 있는 성숙한 개발자 조직에 특히 적합합니다. 이 모델은 또한 배포 프로세스에 대한 보안 제어를 추가합니다. 팀이 도구 체인 표준을 적용할 여지가 거의 없기 때문에 이 모델은 매우 독단적인 것으로 인식될 수 있습니다. 이 모델은 애플리케이션 팀이 자체 인프라를 관리할 것으로 기대합니다. 모델 3은 이 문제를 해결합니다.

 

모델 3: 중앙에서 관리되는 인프라

 

이 모델을 통해 애플리케이션 팀은 중앙 운영 팀이 관리하는 리소스를 셀프 서비스로 프로비저닝할 수 있습니다. 클라우드 플랫폼 엔지니어는 중앙 팀에서 사전 승인한 구성을 사용하여 인프라 포트폴리오를 AWS Service Catalog에 게시합니다(그림 3). 이러한 포트폴리오는 애플리케이션 엔지니어가 사용하는 모든 AWS 계정과 공유할 수 있습니다.

AWS Service Catalog 제품을 통해 AWS 리소스를 프로비저닝 하면 리소스 구성이 중앙 운영 요구 사항을 충족할 수 있습니다. 모델 2와 비교하여 미리 채워진 인프라 템플릿은 해당 AWS 서비스(예: Amazon EC2)의 API를 직접 참조하는 것과 달리 AWS 서비스 카탈로그 제품을 시작합니다. 이는 인프라 구성 및 프로비저닝 방법을 잠급니다.

 

경험상 다양한 AWS Service Catalog 제품을 관리하는 것은 필수적입니다. 이렇게 하면 템플릿이 약간씩 다른 많은 제품이 확산되는 것을 방지할 수 있습니다. 중앙에서 관리되는 인프라는 “온프레미스” 사고 방식을 전파하므로 애플리케이션 팀이 전체 스택을 소유할 수 없는 경우에만 사용해야 합니다.

 

모델 2와 3을 결합하여 애플리케이션 엔지니어가 배포 도구 체인과 리소스를 AWS 서비스 카탈로그 제품(그림 4)으로 출시하는 동시에 팀 리포지토리에 미리 채워진 인프라 템플릿에서 프로비저닝할 수 있는 기회를 유지할 수 있습니다. 코드가 리포지토리에 있으면 프로비저닝된 AWS 서비스 카탈로그 제품에서 업데이트를 실행하여 증분 업데이트를 가져올 수 있습니다. 이를 통해 애플리케이션 팀은 서비스 카탈로그 제품의 수동 배포를 피하면서 필요에 따라 업데이트를 가져올 수 있습니다.

 

모델 비교

 

세 가지 거버넌스 모델은 다음과 같은 측면에서 다릅니다(표 1 참조).

 

• 거버넌스 수준: 클라우드 플랫폼 엔지니어가 중앙에서 관리하는 구성 요소는 무엇입니까?
• 애플리케이션 엔지니어의 역할: 책임 분할 및 운영 모델은 무엇입니까?
• 사용 사례: 각 모델은 언제 적용됩니까?

 

표 1. 인프라 배포 관리를 위한 거버넌스 모델

결론

오늘 포스팅에서는 AWS 리소스 배포를 관리하기 위한 세 가지 공통 거버넌스 모델을 구분했습니다. 세 가지 모델을 함께 사용하여 다양한 사용 사례를 처리하고 조직에 미치는 영향을 극대화할 수 있습니다. 얼마나 많은 책임을 애플리케이션 팀으로 이전할 것인지 결정하는 것은 조직의 설정 및 사용 사례에 따라 다릅니다.

 

메가존클라우드 TechBlog는 AWS BLOG 영문 게재 글이나 관련 기사 중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아 정기적으로 게재하고 있습니다. 추가로 번역 및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS 페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.