[reinvent 2024] 테라폼 스택으로 다중 계정, 다중 지역 앱 구축(HashiCorp 스폰서)
Summary
복잡한 애플리케이션 플랫폼을 효율적으로 관리하는 것은 많은 조직에게 여전히 중요한 과제입니다. 이 세션에서는 다양한 환경에서 인프라의 프로비저닝 및 관리를 간소화하고 HCP Terraform의 새로운 기능을 통해 복잡한 다층 배포를 간소화하는 방법을 알아보세요. 인프라 관리 관행을 개선하고 전반적인 운영 효율성을 높이기 위해 Terraform을 활용하는 방법을 알아보세요. 이 프레젠테이션은 AWS 파트너인 HashiCorp에서 제공합니다.
리인벤트 2024 테크 블로그의 더 많은 글이 보고 싶다면?
Overview
들어가며
AWS re:Invent에서 Terraform 관련 Session이 있었다는게 반가운 마음에 급하게 신청했습니다.
평소에 Terraform에 대한 관심도가 많았었기에 단순 배포 및 학습은 많이 진행해왔었지만 Stack을 활용하는 부분에 대해서는 경험이 부족했습니다. 이번 기회에 Stack은 무엇이고 어떻게 사용되는지 알 수 있는 기회가 될 수 있어 좋겠다고 생각했습니다.
다중 계정 관리와 설정 분리
다중 계정 관리 및 운영을 위해 어떠한 부분들을 생각해야 할까요?
운영을 하다 보면 프로덕션, 개발, 스테이지, 테스트 환경으로 나누게 되며 이러한 환경들은 두 가지 중점이 있습니다.
1) 네트워크, 보안, IAM 규칙 등 플랫폼 인프라를 배포하여 다양한 환경과 워크로드에 일관성을 유지하는게 중요합니다.
2) 수백, 수천 개의 계정을 다룰 때 어떻게 일관성을 유지할 수 있을지 입니다.
각 계정을 일일이 확인할 수 없기 때문에 설정을 모델로 분리하고 주요 배포를 중앙에서 관리해야 합니다.
하지만 위 작업은 상태 관리와 워크플로 관리에서 어려움이 있고 각 계정에 적절한 변수를 할당하기 위해 디렉토리 설정이 필요합니다.
이러한 상황에서 특히 애플리케이션은 인프라와 애플리케이션 경계가 모호한 경우가 많아 관리의 복잡성이 증가하는데요, Kubernetes를 예시로 설명드려보겠습니다.
Kubernetes 클러스터는 워크로드를 실행하며 VPC, 클러스터, 애드온 등 여러 요소가 복잡하게 연결되어 있습니다.
아직 이해가 조금 부족하실 수 있으실텐데요 아래 사진을 통해 추가 설명 드리겠습니다.
아래 사진을 보게 되면 먼저 클러스터를 생성한 다음, Service와 Add-ons를 생성해야 한다는 것을 알 수 있습니다.
운영을 하다 보면 프로덕션, 개발, 스테이지, 테스트 환경으로 나누게 되며 이러한 환경들은 두 가지 중점이 있습니다.
1) 네트워크, 보안, IAM 규칙 등 플랫폼 인프라를 배포하여 다양한 환경과 워크로드에 일관성을 유지하는게 중요합니다.
2) 수백, 수천 개의 계정을 다룰 때 어떻게 일관성을 유지할 수 있을지 입니다.
각 계정을 일일이 확인할 수 없기 때문에 설정을 모델로 분리하고 주요 배포를 중앙에서 관리해야 합니다.
하지만 위 작업은 상태 관리와 워크플로 관리에서 어려움이 있고 각 계정에 적절한 변수를 할당하기 위해 디렉토리 설정이 필요합니다.
이러한 상황에서 특히 애플리케이션은 인프라와 애플리케이션 경계가 모호한 경우가 많아 관리의 복잡성이 증가하는데요, Kubernetes를 예시로 설명드려보겠습니다.
Kubernetes 클러스터는 워크로드를 실행하며 VPC, 클러스터, 애드온 등 여러 요소가 복잡하게 연결되어 있습니다.
아직 이해가 조금 부족하실 수 있으실텐데요 아래 사진을 통해 추가 설명 드리겠습니다.
아래 사진을 보게 되면 먼저 클러스터를 생성한 다음, Service와 Add-ons를 생성해야 한다는 것을 알 수 있습니다.
Add-ons을 생성하려면 클러스터의 ARN, 이름, 또는 ID를 알아야 합니다.
클러스터 존재하려면 먼저 VPC가 생성되어야 하고 다음으로 EKS Cluster가 생성되어야 하는 것을 의미합니다.
만약 순서를 무시하고 Terraform Plan을 실행을 하게 되면 어떻게 될까요?
흔히 자주 볼 수 있는 “알 수 없음(Unknown)” 오류를 확인하실 수 있으실 겁니다.
애플리케이션 또한 깊이 들여다보면 비슷한 문제가 발생되는데요
Pod를 사용하려면 네임스페이스가 필요하고, 네임스페이스를 사용하려면 클러스터가 필요하며, 클러스터에는 Kubernetes 제공자에 대한 인증이 필요합니다.
이러한 작업을 여러 계정과 환경으로 나누면 종속성들이 서로 복잡하게 얽혀 관리와 운영을 하는데 많은 어려움이 발생될 수 있는거죠
이러한 종속성 문제를 해결하기 위해 고객들은 어떤 방법을 사용할까요?
일반적으로 고객들이 선택하는 방법은 Terraform 배포를 여러 단계로 나누는 것입니다.
먼저 VPC를 배포하고, 별도의 워크스페이스에서 Kubernetes 클러스터를 배포한 뒤, Service 및 Add-ons와 Pod를 배포합니다. 이렇게 단계별로 나누면 각 단계 간의 종속성을 올바르게 매핑되도록 할 수 있습니다.
이제 본론으로 다시 돌아와 여러 개의 프로젝트 환경에 대해 생각해보겠습니다.
아래 사진을 보면 하나의 프로젝트나 워크스페이스가 다른 워크스페이스와 어떻게 종속되어 있는지를 확인할 수 있습니다. 만약 진행과정에서 문제가 발생할 경우 이러한 종속성 문제를 다시 해결해야 하는 상황이 생길 수 있는거죠
클러스터 존재하려면 먼저 VPC가 생성되어야 하고 다음으로 EKS Cluster가 생성되어야 하는 것을 의미합니다.
만약 순서를 무시하고 Terraform Plan을 실행을 하게 되면 어떻게 될까요?
흔히 자주 볼 수 있는 “알 수 없음(Unknown)” 오류를 확인하실 수 있으실 겁니다.
애플리케이션 또한 깊이 들여다보면 비슷한 문제가 발생되는데요
Pod를 사용하려면 네임스페이스가 필요하고, 네임스페이스를 사용하려면 클러스터가 필요하며, 클러스터에는 Kubernetes 제공자에 대한 인증이 필요합니다.
이러한 작업을 여러 계정과 환경으로 나누면 종속성들이 서로 복잡하게 얽혀 관리와 운영을 하는데 많은 어려움이 발생될 수 있는거죠
이러한 종속성 문제를 해결하기 위해 고객들은 어떤 방법을 사용할까요?
일반적으로 고객들이 선택하는 방법은 Terraform 배포를 여러 단계로 나누는 것입니다.
먼저 VPC를 배포하고, 별도의 워크스페이스에서 Kubernetes 클러스터를 배포한 뒤, Service 및 Add-ons와 Pod를 배포합니다. 이렇게 단계별로 나누면 각 단계 간의 종속성을 올바르게 매핑되도록 할 수 있습니다.
이제 본론으로 다시 돌아와 여러 개의 프로젝트 환경에 대해 생각해보겠습니다.
아래 사진을 보면 하나의 프로젝트나 워크스페이스가 다른 워크스페이스와 어떻게 종속되어 있는지를 확인할 수 있습니다. 만약 진행과정에서 문제가 발생할 경우 이러한 종속성 문제를 다시 해결해야 하는 상황이 생길 수 있는거죠
새로운 환경을 추가하려면 반드시 순서에 맞게 추가해야 하며 이를 처리하는데 시간이 소요되게 됩니다.
이러한 문제는 플랫폼 리소스와 워크로드 리소스 모두에서 발생되며 결과적으로 작업 흐름을 체계적으로 정리하고 단계를 순서대로 진행하는데 어려움이 생기게 됩니다.
플랫폼 리소스와 워크로드 리소스에 대해 얼마나 알고 있으신가요?
플랫폼 리소스는 다수의 계정과 지역을 관리하고 공통 리소스를 다루며 일관성을 선호합니다.
반면 워크로드 리소스는 특정 계정과 지역, 리소스를 선택적으로 관리하고 배포 순서를 중요시 합니다.
하지만 두 경우 모두 워크플로와 단계 관리에서 여전히 어려움이 있습니다.
이러한 문제는 플랫폼 리소스와 워크로드 리소스 모두에서 발생되며 결과적으로 작업 흐름을 체계적으로 정리하고 단계를 순서대로 진행하는데 어려움이 생기게 됩니다.
플랫폼 리소스와 워크로드 리소스에 대해 얼마나 알고 있으신가요?
플랫폼 리소스는 다수의 계정과 지역을 관리하고 공통 리소스를 다루며 일관성을 선호합니다.
반면 워크로드 리소스는 특정 계정과 지역, 리소스를 선택적으로 관리하고 배포 순서를 중요시 합니다.
하지만 두 경우 모두 워크플로와 단계 관리에서 여전히 어려움이 있습니다.
그렇다면 이 문제를 해결하기 위해 어떻게 해야할까요?
이 문제를 해결하기 위해 “Declarative Deployment” 방법을 제안합니다.
Declarative Deployment 방식은 명령형 방식 대신 선언형 방식으로 인프라와 워크로드를 관리함으로써 복잡성을 줄이고 일관성을 유지하려는 접근 방법 입니다.
아래 사진에서 보시는 것과 같이 지역과 인스턴스 개수를 지정하는 방식입니다. 이렇게 되면 사용자는 무엇을 원하는지 명시하고 시스템은 어떻게 이를 구현할지 자동으로 처리할 수 있습니다.
이 문제를 해결하기 위해 “Declarative Deployment” 방법을 제안합니다.
Declarative Deployment 방식은 명령형 방식 대신 선언형 방식으로 인프라와 워크로드를 관리함으로써 복잡성을 줄이고 일관성을 유지하려는 접근 방법 입니다.
아래 사진에서 보시는 것과 같이 지역과 인스턴스 개수를 지정하는 방식입니다. 이렇게 되면 사용자는 무엇을 원하는지 명시하고 시스템은 어떻게 이를 구현할지 자동으로 처리할 수 있습니다.
지난 10년 동안 HashiCorp는 워크스페이스를 분리하려고 노력해 왔다고 합니다.
모든 것이 깔끔하게 분리되도록 해서 누군가가 DNS 레코드를 수정할 때 DNS 존이나 VPC 등이 손상되지 않도록 해야 했습니다. 단일 적용이 더 간단할 수 있지만 스택을 사용한다면 이러한 분리를 유지하면서 이를 한 단계 더 발전시킬 수 있습니다.
지금까지 다중 계정 관리의 고려사항에 대해 생각해 보았고 이제 스택이 무엇인지 설명드리겠습니다.
Terraform 스택이란 무엇일까요?
모든 것이 깔끔하게 분리되도록 해서 누군가가 DNS 레코드를 수정할 때 DNS 존이나 VPC 등이 손상되지 않도록 해야 했습니다. 단일 적용이 더 간단할 수 있지만 스택을 사용한다면 이러한 분리를 유지하면서 이를 한 단계 더 발전시킬 수 있습니다.
지금까지 다중 계정 관리의 고려사항에 대해 생각해 보았고 이제 스택이 무엇인지 설명드리겠습니다.
Terraform 스택이란 무엇일까요?
Terraform Stack 관리 및 고려사항
Terraform Stack은 애플리케이션 스택처럼 여러 부분으로 구성되 기본적인 단위는 컴포넌트(component)입니다.
컴포넌트는 스택을 구성하는 작은 조각들로 각각 네트워크 및 데이터베이스 컴퓨팅 리소스 등 필요한 요소들을 결합하는 단위이며, 각각의 컴포넌트는 스택에서 필요한 리소스를 정의하며 여러 개의 모듈을 모아 스택이 어떤 리소스를 포함하고 있는지 보여주는 역할을 합니다.
여기에 배포 단위를 추가하면 모듈과 컴포넌트 모음을 몇 번이나 배포할지 정의할 수 있습니다.
여기서 Terraform Stack의 장점을 볼 수 있는데요
이를 통해 동일한 코드를 반복 작성할 필요 없이 정의된 인프라 프로비저닝을 여러 번 자동으로 실행할 수 있습니다.
다시 말해 특정 리소스를 반복적으로 생성해야 하는 작업을 효율적으로 처리하며 코드 재사용성을 높이고 인프라 배포를 간소화하게 되는거죠
컴포넌트는 스택을 구성하는 작은 조각들로 각각 네트워크 및 데이터베이스 컴퓨팅 리소스 등 필요한 요소들을 결합하는 단위이며, 각각의 컴포넌트는 스택에서 필요한 리소스를 정의하며 여러 개의 모듈을 모아 스택이 어떤 리소스를 포함하고 있는지 보여주는 역할을 합니다.
여기에 배포 단위를 추가하면 모듈과 컴포넌트 모음을 몇 번이나 배포할지 정의할 수 있습니다.
여기서 Terraform Stack의 장점을 볼 수 있는데요
이를 통해 동일한 코드를 반복 작성할 필요 없이 정의된 인프라 프로비저닝을 여러 번 자동으로 실행할 수 있습니다.
다시 말해 특정 리소스를 반복적으로 생성해야 하는 작업을 효율적으로 처리하며 코드 재사용성을 높이고 인프라 배포를 간소화하게 되는거죠
플랫폼을 지원하는 코드를 효율적으로 전달하려면 문서를 작성하여 코드의 사용 방법을 명확히 해야 하고 이를 예측 가능한 방식으로 반복적으로 호출할 수 있도록 해야 합니다.
하지만 수동 작업은 실수가 발생하기 쉽고 번거롭기 때문에 이러한 과정을 자동화함으로써 오류를 줄이고 작업 효율성을 높이는 것이 중요합니다.
Terraform Stack은 네 가지 기본 단위로 구성되며 VPC, 라우팅 테이블, 인터넷 게이트웨이, IAM 모듈 등 인프라의 핵심 요소를 포함합니다. 아래 사진을 통해 AWS 플랫폼 리소스의 구성 및 배포 단계를 보실 수 있습니다.
하지만 수동 작업은 실수가 발생하기 쉽고 번거롭기 때문에 이러한 과정을 자동화함으로써 오류를 줄이고 작업 효율성을 높이는 것이 중요합니다.
Terraform Stack은 네 가지 기본 단위로 구성되며 VPC, 라우팅 테이블, 인터넷 게이트웨이, IAM 모듈 등 인프라의 핵심 요소를 포함합니다. 아래 사진을 통해 AWS 플랫폼 리소스의 구성 및 배포 단계를 보실 수 있습니다.
이어서 아래 사진은 애플리케이션 워크로드의 배포 예시를 보여줍니다.
이 두 사진을 통해 Stack은 인프라 리소스와 애플리케이션 리소스를 통합적으로 정의, 구성, 배포, 관리하는 역할을 하는 것을 보실 수 있습니다.
결론적으로 Stack에 대해 다시 정리드리면 저는 아래와 같이 세가지를 핵심으로 설명드릴 수 있을 것 같습니다.
1) Stack은 플랫폼 리소스와 애플리케이션 리소스를 통합적으로 관리하며 일관성, 재사용성, 자동화를 통해 복잡한 클라우드 환경을 효율적으로 운영합니다.
2) Stack을 잘 활용하기 위해 복잡한 워크로드를 효율적으로 관리할 수 있는 오케스트레이션 규칙이 필요합니다. 여기서 오케스트레이션 규칙이란 복잡한 시스템이나 작업에서 리소스와 작업을 올바른 순서로 실행하고 관리하기 위한 규칙을 의미합니다.
3) 클러스터를 설계할 때 리소스 간의 종속 관계와 라이프사이클을 고려하여 설계하는 것이 중요합니다.
결론적으로 Stack에 대해 다시 정리드리면 저는 아래와 같이 세가지를 핵심으로 설명드릴 수 있을 것 같습니다.
1) Stack은 플랫폼 리소스와 애플리케이션 리소스를 통합적으로 관리하며 일관성, 재사용성, 자동화를 통해 복잡한 클라우드 환경을 효율적으로 운영합니다.
2) Stack을 잘 활용하기 위해 복잡한 워크로드를 효율적으로 관리할 수 있는 오케스트레이션 규칙이 필요합니다. 여기서 오케스트레이션 규칙이란 복잡한 시스템이나 작업에서 리소스와 작업을 올바른 순서로 실행하고 관리하기 위한 규칙을 의미합니다.
3) 클러스터를 설계할 때 리소스 간의 종속 관계와 라이프사이클을 고려하여 설계하는 것이 중요합니다.
결론
Terraform Stack은 VPC, IAM 등 리소스를 논리적으로 분리해 다중 계정과 환경에서 복잡한 종속성을 효율적으로 관리하기에 코드 중복을 최소화하고 작업을 자동화하여 배포를 간소화하며 여러 환경에서 동일한 코드를 재사용할 수 있도록 지원합니다. Terraform Stack에 대한 개요 및 등장 배경 등 고려 사항들을 알게되면서 생각치도 못한 부분들에 대해 많이 알게 된 것 같습니다. 단순 배포 관리가 아닌 효율적으로 관리할 수 있는 방안을 고려하기 위한 HashiCorp의 노력도 엿볼수 있었습니다. 다중 계정 관리에 대해서도 이처럼 고려할 사항이 많았고 이로 인해 복잡한 클라우드 환경에서도 어떻게 설계를 해야하는지 배울 수 있는 기회였습니다.
글 │메가존클라우드, Managed & Support Center (MSC), 국지수 매니저
게시물 주소가 복사되었습니다.