[Terraform] DevOps의 등장, 코드형 인프라, 테라폼의 작동 방식, 코드형 인프라 도구 조합

1. 데브옵스(DevOps)의 등장

1) 일반적으로 개발팀(Devs), 운영팀(Ops)으로 역할이 분리되어 불림

• 개발팀은 애플리케이션을 만들어 운영팀으로 넘겨줌
• 운영팀은 애플리케이션을 어떻게 배포하고 운영할 것이 결정함

→ 서버를 랙에 설치하거나 네트워크 케이블을 설정하는 등의 배포 작업이 수동으로 이루어짐

2) 조직이 커지면서 수동으로 진행하는 작업은 느리고 반복적인 작업이 됨

• 운영팀의 실수로 모든 서버가 똑같이 설정되지 않고 일부 설정이 미묘하게 다른 '구성 드리프트(Configration Drift)'가 발생함

3) 데이터 센터를 직접 운영하는 대신 AWS, Azure, GCP 같은 클라우드 플랫폼을 이용함

• 하드웨어에 돈과 노력을 투자하는 대신 소프트웨어 작업에 더 많은 시간을 소모함
• 개발팀과 운영팀 모두 소프트웨어 작업에 많은 시간을 소비하며 두 팀의 구분이 모호해 짐

4) 데브옵스는 소프트웨어를 효율적으로 전달하는 프로세스라는 정의가 가능함

• 지속적으로 코드를 통합하고 항상 배포 가능한 상태로 유지함

5) 데브옵스로 혁신한 회사의 예시

• 노드스트롬(Nordstrom)
  • 한 달에 제공하는 기능 수를 100% 늘리고 결함을 50% 줄임
  • 리드 타임, 프로덕션 환경에서 코드를 실행할 때까지의 시간을 60% 줄이고 배포 중에 발생하는 문제도 60~90% 줄임
• HP
  • 새로운 기능을 개발하는 데 쏟는 시간을 5%에서 40%로 증가, 전체 개발 비용을 40% 감소
• 엣시(Etsy)
  • 하루에 25~50번이나 배포할 수 있게 되었고, 운영 중단 시간은 줄어듬

6) 데브옵스의 4가지의 핵심 가치

• 문화(Culture)
• 자동화(Automation)
• 측정(Measurement)
• 공유(Sharing)

→ CAMS

 

2. 코드형 인프라란?

1) 정의

• 코드를 작성 및 실행하여 인프라를 생성, 배포, 수정, 정리하는 것

2) 코드형 인프라의 5가지 범주

• 애드혹 스크립트

• 수행할 작업을 단계 별로 나누고 배시(Bash), 루비(Ruby), 파이썬(Python) 등 선호하는 언어를 사용하여 각 단계를 코드로 정의하고 작성된 스크립트를 서버에서 수동으로 실행하는 것
• setup-webserver.sh 예시

# apt-get 캐시 업데이트
sudo apt-get update

# PHP와 Apache2 설치
sudo apt-get install -y php apache2

# Git Repository에서 코드 다운로드
sudo git clone https://github.com/brikis98/php-app.git /var/www/html/app

# Apache2 웹 서버 시작
sudo service apache2 start

• 사용자가 매번 수동으로 맞춤 코드를 작성해야 함
• 각 개발자가 자신만의 고유한 스타일로 작업함 → 큰 Repository에 두고 사용하면 결국 관리하기 어려운 ‘스파게티 코드’로 전락할 위험이 큼
• 소규모 일회성 작업에는 적합하지만, 모든 인프라를 코드로 관리하려면 작업 목적에 맞게 설계된 코드형 인프라 도구를 사용하는 것이 바람직 함!

 

• 구성 관리 도구

• 대표적인 예로 셰프, 퍼핏, 앤서블, 솔트스택이 있음
• web-server.yaml 예시

# apt-get 캐시 업데이트
- name: Update the apt-get cache
  apt: 
    update_cache: yes
    
# PHP 설치
- name: Install PHP
  apt:
    name: php
    
# Apache2 설치
- name: Install Apache
  apt:
    name: apache2
    
# Git Repository에서 코드 다운로드
- name: Copy the code from the repository
  git: repo=https://github.com/brikis98/php-app.git dest=/var/www/html/app
  
# Apache2 웹 서버 시작
- name: Start Apache
  service: name=apache2 state=started enabled=yes

• 애드혹 스크립트와 다른 장점
  • 코딩 규칙 : 코딩 규칙이 포함되어 있어 일관되고 예측 가능한 구조를 제공
  • 멱등성 : 실행 횟수에 관계없이 올바르게 동작하는 성질을 가짐
  • 분산형 구조 : 원격의 수많은 서버를 관리하기 위해 설계됨

 

• 서버 템플릿 도구

• 구성 관리 도구의 대안으로 도커(Docker), 패커(Packer), 베이그런트(Vagrant)가 생김
• 운영체제, 소프트웨어, 파일 및 기타 필요한 모든 내용을 포함하고 있는 ‘스냅숏(Snapshot)’으로 이미지 생성
• 앤서블과 같은 코드형 인프라 도구를 사용하여 모든 서버에 이미지 설치 가능
• 이미지 작업을 위한 2가지 도구
  • 가상 머신(Virtual Machine, VM)
    • 가상 머신은 하드웨어를 포함한 전체 컴퓨터 시스템을 에뮬레이트함
      VMware, Virtual Box, Parallels와 같은 하이퍼바이저를 사용하여 CPU, 메모리, 하드 디스크, 네트워크를 가상화 함
    • 장점 : 호스트 시스템 및 다른 가상 머신 이미지와는 완전히 분리되어 실행됨
    • 단점 : 모든 하드웨어를 가상화하고 다른 VM과도 완전히 분리했기 때문에 VM마다 별도의 CPU, 메모리, 리소스가 할당되어 오버헤드가 발생함
    • 패커, 베이그런트 같은 도구를 사용하여 코드로 정의 가능
  • 컨테이너(Container)
    • OS의 사용자 공간을 에뮬레이트 함
      도커, 코어OS의 rkt 또는 크라이오(cri-o)와 같은 컨테이너 엔진을 실행하여 격리된 프로세스, 메모리, 마운트 지점, 네트워킹을 만듦
    • 장점 : 호스트 시스템 및 다른 컨테이너와는 격리되어 실행됨
    • 단점 : 단일 서버에서 실행되는 모든 컨테이너가 해당 서버의 OS 커널과 하드웨어를 공유 → VM을 사용하는 것만큼의 격리 및 보안 수준을 갖추기 힘듦
    • 도커, 코어OS의 rkt와 같은 도구를 사용하여 코드로 정의 가능
  • 가상 머신 하이퍼바이저와 컨테이너 엔진 이미지 유형 비교

가상 머신은 하드웨어를 가상화 하고, 컨테이너는 사용자 공간을 가상화 함

• 패커를 사용해 AMI를 생성하는 경우 Bash 쉘 코드를 사용할 수 있음
• 서버 템플릿에서 사용되는 Bash 쉘 코드는 아파치 웹 서버 구동 명령(sudo service apache2 start)은 불가능 함 → 서버 템플릿(패커)은 일반적으로 이미지 내에 소프트웨어를 설치하는 데 사용
  • 패커 : AWS 계정에서 실행하는 AMI처럼 프로덕션 서버에서 직접 실행하는 이미지를 생성하는 데 사용
  • 베이그런트 : macOS나 Windows 랩톱에서 실행되는 버추얼박스 이미지와 같이 개발 컴퓨터에서 실행되는 이미지를 만드는 데 사용
  • 도커 : 개별 응용 프로그램의 이미지를 만드는 데 사용
• 불변 인프라(Immutable Infrastructure)로 전환하는 데 있어 핵심적인 구성 요소가 됨
  • 불변 인프라는 함수형 프로그래밍에서 사용하는 불변 변수 개념에서 영감을 얻어 등장한 것
  • 서버를 변경해야 하는 경우 서버 템플릿에서 새 이미지를 만들어 새 서버를 배포하는 방식으로 변경해야 함
  • 서버가 변경되지 않기 때문에 배포된 부분을 관리하기 쉬워짐

 

• 오케스트레이션 도구

• 서버 템플릿 도구는 VM이나 컨테이너를 생성하기에 매우 효율적이긴하나, 이를 관리하는 방법도 중요함!
• 관리적인 측면에서 고려해야 할 부분
  • VM과 컨테이너를 하드웨어에 효율적으로 배포하기
  • 롤링 배포, 블루-그린(Blue-Green) 배포, 카나리(Canary) 배포 전략을 사용하여 기존의 VM이나 컨테이너를 효율적으로 업데이트하거나 롤백하기
  • VM과 컨테이너의 상태를 모니터링하고 비정상적인 부분을 자동으로 대체하기(자동 복구)
  • 발생하는 트래픽에 따라 VM과 컨테이너의 수를 늘리거나 줄이기(자동 확장)
  • VM과 컨테이너의 트래픽을 분산하기(로드 밸런싱)
  • 서로 다른 네트워크에 있더라도 VM과 컨테이너가 서로 식별하고 통신할 수 있게 하기(서비스 검색)
• 쿠버네티스(Kubernetes), 마라톤/메소트(Marathon/Mesos), 아마존 엘라스틱 컨테이너 서비스(ECS), 도커 스웜(Docker Swarm), 노마드(Nomad)와 같은 오케스트레이션 도구가 필요함
• 쿠버네티스 클러스터(도커 컨테이너를 관리하고 작동하기 위해 사용하는 서버들의 그룹)을 배포하고, 도커 컨테이너를 어떻게 실행할 것인지 Yaml 파일에 코드로 정의할 수 있음
• Yaml은 많은 기능을 단 몇 줄의 코드로 구현할 수 있음

apiVersion: apps/vl

# Deployment를 사용해 도커 컨테이너의 여러 복제본을 배포하고 이에 대한 업데이트를 선언적으로 롤아웃
kind: Deployment

# 이름을 포함한 Deployment에 대한 메타데이터 
metadata:
  name: example-app

# Deployment 설정 
spec:
	# Deployment가 컨테이너를 찾는 방법을 지정
  selector:
    matchLabels: 
      app: example-app
      
  # Deployment가 컨테이너의 복제본 3개를 실행하도록 지정
  replicas: 3
  
  # Deployment 업데이트하는 방법을 지정, 롤링 업데이트(rolling update) 방법 선택
  strategy:
    rollingUpdate:
      maxSurge: 3
      maxllnavailable: 0 
    type: RollingUpdate
    
  # 배포할 컨테이너의 템플릿
  template:
    # 라벨을 포함한 컨테이너의 메타데이터
    metadata:
      labels:
        app: example-app
        
# 컨테이너 사양
spec: 
  containers:
    # 아파치 웹 서버가 80번 포트를 사용하도록 설정
    - name: example-app 
      image: httpd:2.4.39 
    ports:
      - containerPort: 80

kubectl apply -f example-app.yaml 명령을 통해 쿠버네티스가 애플리케이션을 배포할 수 있음(Yaml 파일을 변경하더라도 kubectl apply 명령으로 업데이트 된 앱을 다시 롤아웃 할 수 있음)

 

• 프로비전 도구

• 구성 관리, 서버 템플릿 및 오케스트레이션 도구가 각 서버에서 실행되는 코드를 정의하는 역할이라면, 테라폼, 클라우드포메이션(CloudFormation), 오픈스택히트(OpenStackHeat)와 같은 프로비전 도구는 서버 자체를 생성함
• 클라우드 서비스와 프로비전 도구를 사용하여 서버, 데이터베이스, 로드 밸런서 등 인프라의 모든 부분을 프로비저닝할 수 있음

 

3. 코드형 인프라의 장점

• 자급식 배포(Self-Service) : 전체 베포 프로세스를 자동화할 수 있으며, 개발자는 필요할 때마다 자체적으로 배포를 진행할 수 있음
• 속도와 안정성(Speed and Safety) : 사람이 진행하는 것보다 훨씬 빠르게 컴퓨터가 배포를 진행할 수 있으며, 오류가 적게 발생함
• 문서화(Documentation) : 누구나 읽을 수 있는 소스 파일로 인프라 상태를 나타낼 수 있음
• 버전 관리(Version Control) : 변경 내용이 모두 기록된 코드형 인프라 소스 파일을 저장하여 버전을 쉽게 관리할 수 있음 → 시스템 문제 발생 시 문제 발생 지점을 찾기 수월함(디버깅에 도움)
• 유효성 검증(Validation) : 코드가 변경될 때마다 검증을 수행하고 일련의 자동화된 테스트를 진행할 수 있음(정적 분석 프로그램에 코드를 전달하여 오류 발생 위험을 줄일 수 있음)
• 재사용성(Reuse) : 재사용 가능한 모듈로 패키징하여 매번 처음부터 배포하는 대신 문서화되고 검증된 모듈로 일관되게 배포할 수 있음
• 행복(Happiness) : 반복적이고 지루한 일이 될 수 있는 코드 배포나 수동적인 인프라 관리를 자동화하여 심리적 만족감을 느낄 수 있음

 

4. 테라폼의 작동 방식

• 해시코프(HashiCorp)사가 Go 언어로 개발한 오픈 소스 도구
• 하나의 바이너리 파일로 컴파일 되며 terraform이라는 명령어로 실행 가능
• terraform 바이너리가 클라우드 공급자를 대신해 API를 호출해 리소스를 생성함
  → 클라우드 공급자가 제공하는 API 서버를 활용할 뿐만 아니라 API 키 같은 인증 메커니즘도 같이 사용함!
• terraform 바이너리는 사용자가 구성한 코드를 파싱하고 코드에 지정된 클라우드 공급자에 대한 일련의 API 호출로 변환함

→ 자동 테스트와 코드 리뷰를 통해 유효성을 검증하고, 버전 관리 시스템에 코드를 커밋함, terraform apply 명령을 통해 실제로 변경을 수행하는 API를 호출하여 인프라 변경을 진행함

 

※ 참고 : 클라우드 공급자 간 투명한 이식성 테라폼은 여러 클라우드 공급자를 지원하는데, 실제로 클라우드 공급자는 동일한 유형의 인프라를 제공하지 않기 때문에 ‘정확히 동일한 인프라’를 배포할 수는 없음!

 

5. 일반적인 코드형 인프라 도구 조합

1) 프로비저닝과 구성 관리

• 테라폼과 앤서블을 함께 사용
• 테라폼을 사용하여 모든 기본 인프라 배포, 앤서블을 사용하여 서버에 앱을 배포

• 테라폼이 서버에 특별한 태그를 추가하고 앤서블은 이 태그를 이용해 서버를 식별해 구성을 진행함
• 일반적으로 앤서블을 변경 가능한 형태로 사용하면 절차적인 요소가 많은 코드를 작성해야 하므로 인프라 및 조직이 성장함에 따라 유지 관리가 어려워질 수 있음

2) 프로비저닝과 서버 템플릿

• 테라폼과 패커를 함께 사용
• 패커를 사용하여 앱을 VM 이미지로 패키징, 테라폼을 사용하여 VM 이미지와 기본 인프라 배포

• 서버 템플릿(패커)을 사용해 불변 인프라 방식으로 유지 관리가 더 쉬움
• VM을 구축하고 배포하는 데 시간이 오래 걸리고, 테라폼으로 구현할 수 있는 배포 전략이 제한적임 → 배포 스크립트를 많이 작성해야 하거나 오케스트레이션 도구를 함께 사용해야 함

3) 프로비저닝과 서버 템플릿 그리고 오케스트레이션 도구

• 테라폼, 패커, 도커 그리고 쿠버네티스를 함께 사용
• 패커를 사용하여 도커 및 쿠버네티스가 설치된 VM 이미지를 생성, 테라폼을 사용하여 VM 이미지를 실행하는 인프라 배포

• 도커 이미지가 상당히 빠르게 빌드되고 다양한 배포 전략, 자동 복구, 자동 확장 기능을 포함한 쿠버네티스의 모든 내장 기능을 활용할 수 있음
• 추가적인 인프라가 필요해 운영이 복잡해짐, 쿠버네티스 클러스터는 배포 및 운영이 어렵고 비용이 많이 듦
• 대부분의 클라우드 공급자는 쿠버네티스 서비스를 제공함 → 쿠버네티스의 일부를 관리하지 않아도 됨

[참고] 테라폼 업앤러닝 2nd Edition 책을 공부하며 작성한 공부용 글입니다 :)