[Korean] HashiCorp Terraform 적용 단계

Transcript

안녕하세요. 저는 아몬 데드거(Armon Dadgar)입니다. 오늘은 Terraform을 도입하는 단계에 대해 설명하고자 합니다. Terraform의 신규 사용자들은 종종 "어떻게 개인이 사용하던 단계에서, 하나의 팀, 여러 팀, 그리고 조직 전반으로 도입을 확대할 수 있는지"를 묻곤 합니다. 그래서 사용자의 규모와 관계없이, 고객 모두에게 Terraform을 도입하는 여정과, 각 단계를 거치면서 나타나는 몇 가지 패턴을 함께 살펴보는 것이 도움이 될 것으로 생각했습니다.

Terraform에 대해 논의할 때, 우리는 일반적으로 개인 개발자로부터 시작합니다. 개인 기여자가 있습니다. 그들이 하는 일이 매우 긴밀하게 연결되어 있으며, 이것은 Terraform 구성으로 IaC(infrastructure as code)를 작성합니다. 이것이 Terraform config, 그리고 이 워크플로우는 Terraform에서 잘 규정되어 있습니다. 구성을 작성한 다음, 로컬에서 Terraform 플랜을 실행하면,

• Terraform이 무엇을 수행할 것으로 예상되는지,
• 무엇을 생성하고 수정하며, 인프라에서 삭제하는 등의 실제로 인프라를 어떻게 수정되어야 하는지 등을 확인할 수 있으며,
• Terraform을 통한 변경을 검증할 수 있는 기회를 갖게 됩니다.

이 결과가 만족스럽다면, 이를 검사하고 검증한 다음, 실제로 변경하는 것입니다. 이들을 적용하여 인프라의 변경, 즉, 다양한 인프라를 생성, 수정, 삭제하게 됩니다. 애플리케이션과 매우 비슷하고 인프라에 대한 정의가 유기적으로 동작합니다.

오늘날 일련의 인프라를 구축하고, 미래에 이를 확장하거나 증설 또는 축소할수 있습니다. 또한, 처음으로 돌아가서 다시 구성을 수정할 수 있습니다. 원점으로 돌아가, 구성을 변경하고 다시 플랜(plan)과 어플라이(apply)의 주기를 진행할 수 있습니다.

이는 개인 수준에서 이루어지는 방식입니다. 이제, 팀 수준에서 시작하면 어떻게 될까요?

팀 수준으로 가는 순간, 일련의 협업에 대한 고려가 필요합니다. 특히, 이 인프라가 어떤 모습이어야 하는지에 대한 하나의 정의를 수정하는 경우, 여러 사람들이 같은 작업을 하게 됩니다. 그렇다면, 어떻게 실제로 인프라에 대한 일관된 정의를 확보하고 서로 다른 사람의 작업을 망치지 않으면서 변경을 안전하게 수행할 수 있을까요? 플로우를 약간 변경해 보겠습니다.

마찬가지로 로컬 환경에서 구성을 작성하거나 수정하는 실무자에서 시작합니다. 실무자들은 이들 변경이 안전한지 확인하기 위해 로컬에서 플랜을 실행할 수도 있습니다. 하지만, 이를 자체적으로 적용하는 대신, 한 단계를 추가합니다. 버전 제어 시스템(VCS)상에서 수정하고 저장합니다. 이는 GitHub나 Bitbucket, 아니면 GitLab일수도 있고, 선호하는 여타 버전 제어 시스템일 수 있습니다.

핵심은 VCS가 신뢰할 수 있는 단일 데이터 소스를 제공한다는 것입니다. 여러 사람들이 동시에 이 구성을 편집하지만, 구성 자체를 수행하는 데 사용하는 마스터 사본은 오직 하나입니다. 이제 중앙 데이터 소스가 있기 때문에 이를 활용하고 이러한 데이터 소스에 Terraform을 적용할 수 있습니다.

이러한 방식으로 우리의 구성에 대한 본질적인 정의를 얻게 됩니다. 한 번에 오직 하나만 변경되며, 병렬로 여러 변경이 실행되어 서로 다른 사람의 작업을 망치는 사태를 막을 수 있습니다.

변경 사항을 적용했다면, 다시 돌아가서 이 고리를 재시작합니다. 이 단계에서 해야 하는 일은 버전 제어 시스템을 사용하고 구성에 대한 일관성을 확보한 다음, 여기에 Terraform으로 변경을 적용하여 일관성을 보장하는 것입니다.

단일 팀에서 다수의 팀으로 넘어가면서 바뀌는 것은 이제 분업으로 작업 수행해야 한다는 것입니다. 지금 실제로 우리가 가진 것은 전체 인프라를 정의한 단일 Terraform 구성 세트입니다.

하지만, 다수의 팀으로 가게 되면, 이는 비현실적이 되기 시작합니다. 지나치게 많은 조율 작업이 필요하고 구성은 지나치게 복잡해집니다.

따라서, 인프라를 계층적으로 분리하려고 합니다. 기반 네트워크 유형과 클라우드 구성을 담당하는 하나의 팀이 있습니다.

그리고, 일련의 미들웨어, 즉 미들웨어 티어가 있습니다. 여기에는

• 로깅을 위한 공통 솔루션,
• 공통 모니터링 솔루션,
• 그리고 아마도 애플리케이션 간에 공유하는 보안 정책 등 여러 다른 요소들이 있을 수 있습니다.

이는 모든 애플리케이션들이 사용할 기본 공유 인프라입니다. 각 애플리케이션 팀이 로깅 방식부터 다시 개발하는 것을 원치 않을 것입니다.

그 끝에는 현업 애플리케이션 팀이 있습니다. 예를 들어, app1과 app2이 있다고 하겠습니다. 이들 애플리케이션 팀은 이들 구성 요소 중 다른 그 어느 것도 정의하지 않습니다. 네트워크도, 모니터링도 정의하지 않으며 단지 사용할 뿐입니다.

한 애플리케이션이 이 미들웨어의 일부 하위 세트를 사용할 수도 있습니다. 우리가 해왔던 작업은 전반적으로 이들 각 부분들을 구성하고 애플리케이션과 인프라를 구축하는 것입니다. 전반적인 인프라는 이들 모든 부분들이지만, 보다 작은 단위로 이를 관리하고 있습니다. Terraform에서는 이들 각각을 워크스페이스라고 부릅니다. 따라서, 이 대규모 인프라를 일련의 워크스페이스로 나눈 다음, 이를 결합해 대규모 인프라로 구성해야 합니다.

이제 다수의 팀으로 넘어가면서, 애플리케이션 팀이 들어와서 네트워크 토폴로지에 대한 정의를 변경하고 변경을 배포해 버리는 상황을 원치 않을 수 있습니다. 개별 워크스페이스로 분리하는 것뿐만 아니라, 여기에 역할 기반 접근 제어를 적용해야 합니다. 예를 들면, 네트워킹 팀은 네트워킹 유형의 작동 방식을 수정하는 것이 허용되고, 로깅 팀은 로깅 미들웨어의 형태를 수정할 수 있지만, 그 외 다른 팀들은 이를 사용하는 것만 가능합니다.

애플리케이션을 네트워크에 배포하려면 네트워크가 어떤 형태인지 알아야 하며, Amazon VPC가 어떤 것인지, 서브넷이 어떤 것인지를 알아야 합니다. 조직 내 다른 부문에서 이들 워크스페이스에 대해 읽기가능한 권한을 허용하지만, 이들 개별 요소들을 소유 및 관리해야 하는 그룹에 쓰기 접근 권한이나 변경할 수 있는 권한을 제한할 수 있습니다.

이제 각 팀들, 예를 들어 애플리케이션 팀은 바로 이들 모든 요소들을 사용할 수 있습니다. 네트워크, 로깅, 모니터링을 사용할 수 있으며 애플리케이션을 개발, 배포 및 관리할 수 있습니다.

다시 한번, "우리 팀은 읽기 및 쓰기 권한을 유지하고 있다."고 할 수 있지만, 백단의 애플리케이션인 app3가 있으며 이를 사용하고 이러한 방식으로 인프라를 구축하기를 원할 수 있습니다.

다수의 팀으로 넘어가면, 팀이 상호 독립적으로 업무를 수행할 수 있도록 하는 방법이 중요합니다. 하지만, 이는 모든 사람들이 안전하게, 모든 유형의 변경을 수행할 수 있는 위험에 노출되지 않으면서 이루어져야 합니다.

지금보다 적용 범위가 확장되기 시작하면, 즉, 여러 팀이 이를 사용하는 수준에서 조직 차원에서 이를 배포하는 수준으로 넘어가면 어떻게 될까요? 조직 차원에서는 여러 거버넌스 과제에 직면하게 됩니다. 이와 더불어 더 많은 사람들이 업무를 수행하는 방법에 대해서도 고민해야 합니다. 해당 단계에서 여전히 대부분 사람들이 Terraform을 친숙하게 사용하고 있지만, 조직 전체로 확대한다고 해서 모두가 Terraform을 사용하거나 모든 사람들을 교육하기 위해 투자할 가능성은 적습니다.

여기에는 2가지 해법이 있습니다. 첫번째 해법은 생산자(publisher)와 사용자(consumer)에 대한 공통의 패턴입니다. 먼저, 제한된 수의 생산자로 시작해 보겠습니다. 이제 생산자는 기본적으로 여러 다른 유형의 인프라를 구축하는 방법을 설명된 중앙 레지스트리에 모듈로 푸시합니다. 아마도 * Java 앱을 배포하는 방법, * C# 앱을 배포하는 방법, * 데이터베이스를 배포하는 방법 등을 설명하는 모듈이 있을 수 있습니다.

이들 생산자는 이 레지스트리로 실제 이를 관리하는 방법에 대한 정의를 푸시하고 이 모듈은 고유한 Terraform 구성으로 패키징합니다. 이제 훨씬 많은 수의 사용자들이 이 앱을 사용할 수 있습니다. 사용자들이 Terraform이나 패턴에 대해 잘 알고 있어야 할 필요는 없습니다. 사용자들은 "나에게 Java 애플리케이션이 있고, 여기에 .jar 파일이 있습니다. 그 중 3개를 Amazon에 배포하려고 합니다."라고 말합니다.

사람들이 변경하도록 허용하지만, 이와 관련한 다른 복잡한 모든 것은 추상화하는 포인트를 제공할 수도 있습니다. 이를 통해 훨씬 많은 수의 사용자들로 확장할 수 있으며 이들에게 IaC(Infrastructure as Code)를 작성하는 방법이나, 클라우드 전문가가 되도록 교육할 필요가 없습니다.

또다른 과제는 많은 사람들과 상호 작용하는 이들 사용자들이 안전하게 작업을 수행할 수 있도록 하는 것입니다.

사람들이 방화벽을 열어 모든 트래픽의 수신을 허용하거나, S3 버킷을 공개적으로 설정해 데이터를 읽고 노출하도록 허용하는 것을 원치 않습니다. 우리가 하려는 것은 샌드박스를 정의하고 "샌드박스 내부에서 원하는 모든 유형의 인프라 변경을 수행하도록 허용됩니다."고 말하는 것입니다.

또한, 샌드박스 내에 있는 한, 사전 정의된 Java 모듈을 사용할 수 있으며 Terraform 사용법을 알고 있다면, 자신만의 고유한 커스텀 리소스를 작성할 수 있습니다. 샌드박스 내에 있는 한, 이를 수행하도록 허용됩니다. 티켓을 제출하거나 보안팀의 검사를 통해 인프라가 유효한지 확인할 필요가 없으며, 원하는 대로 변경하고 제출하며 계속 진행할 수 있습니다.

하지만, 샌드박스 밖에서 무엇인가를 시도하고 배포한다면, 예를 들어 잘못된 region에 배포하거나 보안 컨트롤을 우회하는 경우, 시스템이 이를 차단해야 합니다.

이에 초점을 맞춘 프로젝트를 Sentinel이라고 부릅니다. Sentinel에 대한 아이디어는 코드화된 정책(policy-as-code)을 어떻게 적용할 것인가 하는 질문에서 시작되었습니다. 정책은 예를 들어, * Staging은 항상 east-region에 배포하고 * Production은 항상 west-region에 배포하며, * 방화벽 규칙은 결코 전체 인터넷에서 들어오는 트래픽을 허용하지 않는다는 것 등이 있습니다.

그 자체가 코드인 다른 Sentinel 정책 세트로서 포함할 수 있으며, 이는 기본적으로 정책이 어떤 형태여야 하는지를 기술합니다.

이 정책은 이제 이 샌드박스를 정의합니다. 정책을 위반하지 않는 것들은 내부에 있고, 상대적으로 샌드박스의 제한에 도달해 정책을 위반한 것들은 거절됩니다.

Terraform Enterprise에서 이 Sentinel 정책을 삽입하면 시스템은 이를 자동으로 모든 변경 사항에 강제화합니다.

한 발자국 뒤에서 보면, 점진적인 도입 과정을 확인할 수 있습니다. 1. 이는 피드백이 활발한 개인에서 시작하며 협업에는 문제가 없습니다. 이들은 로컬에서 자신만의 플랜 어플라이 주기를 수행할 수 있으며 조율 문제에 대해 고민할 필요가 없습니다. 2. 여러 사람들이 참여하기 시작하는 순간, Terraform의 구성 파일 자체는 물론, 변경 시 사람들이 서로의 일을 망치지 않게 변경을 순차적으로 적용할 수 있도록 단일 데이터 소스가 있어야 합니다. 이를 위해서는 VCS를 이용해야 하며, 변경 사항을 순차적으로 적용하고 상태를 관리하는 시스템으로 다시 연결하는 것과 관련한 몇 가지 간단한 변경이 이루어져야 합니다. 3. 그 다음, 보다 확대되면, 하나의 모놀리식 구성을 다수의 소규모 구성으로 분해하고 다시 역할 기반 접근 제어로 연계해야 하며, 이는 안전하게 수행해야 합니다. 4. 조직 수준의 최종 단계에서는 많은 사용자들이 레지스트리, 사전 승인된 모듈(서비스 카탈로그)에 대한 개념을 도입함으로써 쉽게 사용할 수 있도록 해야 하는 것은 물론, 실제로 허용되는 것/제한되는 것을 정책을 통해 제어해야 합니다. 정책을 통해 이를 수행할 수 없다면, 때로 티케팅 큐를 생성해야 합니다. 이 경우, 모든 변경 사항은 수동으로 검토되고 기민한 셀프 서비스 인프라를 통해 확보했던 효율성을 잃게 됩니다.

Terraform을 사용하고 이들 단계를 거치면서 채택의 여정을 이해하는 데 도움이 되었기를 바랍니다. Terraform을 사용하고 보다 심층적으로 이해하는 데 도움이 되는 많은 자료들이 온라인으로 제공되고 있습니다.

협업 및 관리와 관련해 어려운 상황에 처해 있다면, Terraform Enterprise을 검토해 보십시오. 감사합니다.