IaC 전체 프로세스 설계

Terraform / Terragrunt 도입 이후, 바로 구축하지 않고 먼저 설계한 것들

Terraform / Terragrunt를 도입한 이후, 바로 dev 환경부터 IaC로 구축하지는 않았다.
먼저 전체 IaC 운영 프로세스를 어떻게 가져갈지 큰 흐름을 정리하는 과정부터 진행했다.

 

기존 인프라 기준으로 IaC를 정리해야 하는 상황이었고, 프로젝트와 환경이 계속 늘어나는 구조였기 때문에
초기 운영 기준을 먼저 정의하는 것이 중요하다고 판단했다.

 

---

IaC 전환 전에 먼저 정리했던 기준

IaC 전환을 시작하기 전에 몇 가지 운영 기준을 먼저 정리했다.

• 프로젝트 단위는 어떻게 나눌지, dev / stg / prod 같은 환경은 어떤 기준으로 분리할지
• remote state는 어떤 단위로 관리할지
• 그리고 리소스 간 dependency는 어떤 방식으로 연결할지

에 대한 기준을 먼저 잡았다.

 

또한 공용 인프라(shared infra)를 어떤 경우에 사용할지에 대해서도 같이 정리했다.

 

결과적으로 IaC 도입 자체보다는 IaC를 어떻게 운영할 것인지에 더 초점을 맞췄다.

단순히 인프라를 코드로 만드는 것보다, 프로젝트와 환경이 늘어났을 때도 유지할 수 있는 구조를 만드는 것이 더 중요하다고 생각했다.

---

IaC 전체 운영 프로세스 설계

 

전체 흐름은 아래 기준으로 잡았다.

• 기존 인프라 구조 분석
• IaC Repository 구조 설계
• Terraform Module 구조 정리
• Terragrunt 환경 구조 설계
• remote state 전략 설계
• dependency 구조 설계
• dev 환경 IaC 전환 시작

처음부터 모든 환경을 한 번에 IaC로 전환하기보다는 dev 환경부터 단계적으로 전환하는 방향으로 진행했다.

 

---

 

현재 인프라 구조

IaC 전환을 진행하기 전에 현재 사용중인 인프라 자원 구성을 먼저 정리했다.

• VPC
• Subnet
• Nat Gateway
• Route Table
• Bastion
• Naver Kubernetes Service (NKS)
• Cloud DB for MySQL
• Object Storage
• Init Script
• login_key (pem)

 

현재 기준으로는 아래와 같은 구조로 인프라가 구성되어 있었다.

Internet
   │
Load Balancer
   │
  VPC
   ├ Bastion
   ├ NKS
   ├ DB

External Service
 ├ Object Storage
 ├ login key
 ├ init script

 

---

현재 인프라 구조와 IaC 운영 기준을 정리한 이후 실제 IaC 적용은 dev 환경부터 시작하기로 했다.

운영 환경을 바로 전환하기보다는 dev 환경에서 Terraform / Terragrunt 구조를 먼저 적용하면서 IaC 구조와 운영 방식을 검증하는 것이 더 현실적인 접근이라고 판단했다.

다음 단계에서는 기존 인프라 구조를 기준으로 dev 환경을 IaC로 전환하는 과정을 정리해보려고 한다.