[70일차]IaC 기반의 인프라 자동화 및 CI/CD 파이프라인 고도화

1. 서론: IaC와 테라폼(Terraform)의 이해

1.1 IaC (Infrastructure as Code)

IaC는 '코드형 인프라'를 의미하며, 수동으로 서버나 네트워크를 설정하는 대신 코드를 통해 인프라를 생성, 변경, 관리하는 기술이다. 이를 도입함으로써 얻을 수 있는 이점은 다음과 같다.

• 안정성 및 일관성: 사람의 실수(Human Error)를 배제하고 항상 동일한 환경을 구성할 수 있다.
• 재현 가능성: 코드가 존재한다면 언제 어디서든 동일한 인프라를 다시 만들어낼 수 있다.
• 버전 관리 및 협업: 인프라 설정 자체가 코드이므로 Git과 같은 형상 관리 도구를 통해 변경 이력을 추적하고 공유할 수 있다.

1.2 구성 관리 (Configuration Management)

소프트웨어 시스템에서 '구성(Configuration)'은 코드 못지않게 중요한 요소이다. 잘못된 구성은 시스템 전체의 장애를 유발할 수 있으므로, 의존성을 포함한 모든 구성을 체계적으로 관리해야 한다.

1.3 테라폼 (Terraform)

테라폼은 HashiCorp사에서 제공하는 대표적인 오픈소스 IaC 도구이다. 클라우드 서비스나 온프레미스 인프라를 선언적인 코드로 정의하여 프로비저닝한다.

테라폼의 워크플로우는 크게 5단계로 구분된다.

1. Scope: 관리할 인프라의 범위를 지정한다.
2. Author: HCL(HashiCorp Configuration Language)로 설정 코드를 작성한다.
3. Initialize (init): 필요한 프로바이더(플러그인)를 다운로드하고 초기화한다.
4. Plan (plan): 코드를 실행했을 때 변경될 사항을 미리 예측하고 계획을 수립한다.
5. Apply (apply): 계획된 내용을 실제 인프라에 적용한다.

---

2. 테라폼 실습 및 코드 분석

2.1 기본 구성 설정 (main.tf)

테라폼을 이용해 도커 컨테이너를 생성하는 기초 실습 코드이다.

terraform {
  required_provider {
    docker = {
      source = "kreuzwerker/docker"
      version = "=> 3.0.1"
    }
  }
}

provider "docker" {}

resource "docker_image" "nginx" {
  name = "nginx"
  keep_locally = false
}

resource "docker_container" "nginx" {
  image = docker_image.nginx.image_id
  name = "sample"

  ports {
    internal = 80
    external = 8000
  }
}

• Provider: 테라폼이 상호작용할 대상(여기서는 Docker)을 정의한다. terraform init 명령 수행 시 Terraform Registry에서 해당 플러그인을 자동으로 다운로드한다.
• Resource: 실제로 생성할 인프라 자원을 정의한다. 위 코드는 Nginx 이미지를 다운로드하고, 8000번 포트로 컨테이너를 실행하도록 선언하고 있다.

---

3. Kubernetes와 CI/CD 파이프라인 통합

3.1 인프라 상태(State) 관리의 중요성

테라폼은 인프라의 현재 상태를 저장하는 .tfstate 파일을 생성한다. 팀 단위 협업과 자동화된 파이프라인에서 이 파일의 관리는 매우 중요하다.

• SCM (Git) 저장: 보안 및 충돌 문제로 권장하지 않는다.
• Jenkins Agent / Local: 휘발성 환경이거나 공유가 불가능하므로 부적합하다.
• k8s Persistent Volume: 관리가 복잡할 수 있다.

해결책

Terraform Cloud나 AWS S3와 같은 원격 백엔드(Remote Backend) 서비스를 사용하여 상태 파일을 중앙에서 안전하게 관리하고, 잠금(Locking) 기능을 통해 동시 수정을 방지해야 한다.

---

3.2 프로덕션 vs 스테이징 환경 전략

이상적인 CD(지속적 인도)를 위해서는 스테이징 환경이 프로덕션 환경을 완벽히 모사해야 한다. 그러나 리소스 제약이 있는 경우(단일 k8s 클러스터 사용 시), 네임스페이스(Namespace)를 분리하여 논리적으로 환경을 격리하는 전략을 사용한다.

• Namespace 분리: prod 네임스페이스와 stage 네임스페이스를 생성하여 리소스를 격리한다.

파이프라인 흐름

1. CI: 코드 체크아웃 → 빌드 & 테스트 → 패키징 & 레지스트리 푸시
2. CD (Staging): 테라폼을 통해 스테이징 네임스페이스에 배포 → 인수 테스트(Acceptance Test) 수행
3. CD (Production): 스테이징 검증 완료 후 프로덕션 네임스페이스에 배포 → 스모크 테스트(Smoke Test) 수행

---

3.3 빌드 버전 관리

빌드된 아티팩트의 추적성을 위해 Jenkins의 Build Timestamp Plugin 등을 활용하여 고유한 버전 번호나 태그를 부여, 관리한다.

---

4. 운영 안정성을 위한 고려사항

4.1 비기능 테스트 (Non-Functional Testing)

기능의 구현 여부뿐만 아니라 시스템이 운영 환경에서 견딜 수 있는지를 검증하는 비기능 테스트가 필수적이다.

• 성능 테스트: 부하(Load), 스트레스(Stress), 확장성(Scalability) 테스트를 통해 임계치를 확인한다.
• 보안 테스트: 취약점을 점검한다.
• 복구 테스트: 장애 발생 시 시스템이 정상적으로 복구되는지 확인한다.

---

4.2 데이터베이스 변경 관리

Stateless한 웹 애플리케이션과 달리, 데이터베이스는 상태(State)를 가지므로 관리가 훨씬 까다롭다.

• 테스트 데이터와 프로덕션 데이터는 엄격히 분리되어야 한다.
• 스키마 변경 시 데이터 손실을 막기 위해 마이그레이션 스크립트를 활용하여 체계적으로 업데이트를 수행해야 한다.

---

4.3 릴리스 패턴 (Release Patterns)

배포 시 위험을 최소화하기 위해 다양한 전략을 사용한다.

• 롤링 업데이트 (Rolling Update): 구버전을 하나씩 점진적으로 신버전으로 교체한다.
• 블루-그린 배포 (Blue-Green Deployment): 신버전(Green) 환경을 완벽히 구성한 뒤 트래픽을 한 번에 전환한다.
• 카나리아 릴리스 (Canary Release): 일부 사용자에게만 신버전을 먼저 노출하여 안정성을 검증한 후 전체로 확대한다.

---

4.4 관측 가능성 (Observability)

시스템 배포 이후의 상태를 파악하기 위한 활동이다.

• 모니터링: 자원 상태(CPU, 메모리 등)를 지속적으로 측정한다.
• 진단: 잠재적 위험 요소를 조기에 발견한다.
• 알림: 장애나 빌드 실패 등 중요 이벤트 발생 시 담당자에게 즉시 알린다.

---

5. 결론: DevOps 도구 체인의 완성

이번 과제를 통해 현대적인 DevOps 환경을 구성하는 4대 핵심 도구의 역할을 명확히 정리할 수 있다.

1. Docker: 애플리케이션을 컨테이너화하여 환경 종속성 문제를 해결하고 이식성을 보장한다.
2. Kubernetes: 컨테이너화된 애플리케이션을 대규모로 오케스트레이션하며, 운영 안정성을 제공한다.
3. Terraform: 애플리케이션이 실행될 하부 인프라(클러스터, 네트워크 등)를 코드로 정의하고 관리한다.
4. Jenkins: 빌드, 테스트, 인프라 프로비저닝, 배포에 이르는 전 과정을 자동화하여 CI/CD 파이프라인을 완성한다.

이들의 유기적인 통합은 단순한 자동화를 넘어, 소프트웨어의 개발 속도와 운영 안정성을 동시에 달성하는 핵심 기반이 된다.