[테라폼] TerraForm 이란? 2

https://dodo-devops.tistory.com/55

[테라폼] TerraForm 이란?

 

(3) 코드형 인프라의 장점

 코드형 인프라의 여러 측면을 살펴보니 다음과 같은 의문이 생긴다. 왜 새로운 언어와 도구를 배우고 더 많은 코드를 관리해야 하는걸까?

이유는 간단하다. 코드로 할 수 있는 것이 많기 때문이다. 수동으로 코드를 변환하지 않아도 되므로 소프트웨어를 효율적으로 배포 할 수 있다. 인프라가 코드로 정의되면 다음과 같은 배포 프로세스를 극적으로 개선할 수 있다.

 

자급식 배포(self-service)

 코드를 수동으로 배포하는 대부분 팀에서는 배포를 수행하는 데 필요한 명령어를 알고있는 소수의 시스템 관리자만 프로덕션 환경애 접속하여 배포를 진행한다. 이것은 회사가 성장하는데에 장애물이 된다. 인프라를 코드로 정의하면 전체 배포 프로세스를 자동화 할 수 있으며 개발자는 필요할 때마다 자체적으로 배포를 진행할 수 있다.

 

속도와 안정성(Speed and safety)

 배포 프로세스를 자동화하면 사람이 진행하는 것보다 훨씬 빠르게 컴퓨터가 배포를 진행할 수 있다. 자동화 된 프로세스는 일관되고 반복 가능하며 수동으로 진행했을 때보다 오류가 적게 발생하기 때문에 더 안전하다.

 

문서화(Documentation)

 시스템 관리자 조직만 인프라에 관한 정보를 독점하는 것이 아니라 누구나 읽을 수 있는 소스 파일로 인프라 상태를 나타낼 수 있다. 즉, 코드형 인프라는 문서 역할을 하며 시스템 관리자가 휴가중일 때도 조직의 모든 사람이 인프라 구조를 이해하고 업무를 볼 수 있도록 해준다.

 

버전관리(Version control)

 인프라의 변경 내용이 모두 기록된 코드형 인프라 소스 파일을 저장할 수 있으므로 버전을 쉽게 관리할 수 있다. 인프라 변경 내역이 남아있기 때문에 시스템에문제가 생겼을 때 문제가 발생한 지점을 찾을 수 있다. 문제의 내용을 확인한 다음 문제가 없던 이전 코드로 다시 되돌리면 문제가 해결된다. 

 

유효성 검증(Validation) 

 인프라 상태가 코드로 정의되어 있으며 코드가 변경될 때마다 검증을 수행하고 일련의 자동화괸 테스트를 실행할 수 있으며, 정적 분석 프로그램에 코드를 전달하여 오류 발생 위험을 줄일 수 있다.

 

재사용성(Reuse)

 인프라를 재사용 가능한 모듈로 패키징할 수 있으므로 모든 제품을 매번 처음부터 배포하는 대신 문서화되고 검증된 모듈로 일관되게 배포가능하다.

 

(4) 테라폼의 작동 방식

 먼저 테라폼의 작동 방식을 개괄적으로 살펴보자. 테라폼은 해시코프(HashiCorp)사가 Go 언어로 개발한 오픈 소스 도구이다. 운영 체제마다 바이너리 파일이 존재하는데 Go 코드는 하나의 바이너리 파일로 컴파일 되며 terraform 이라는 명령어로 실행할 수 있다.

 이 바이너이를 사용하여 랩톱이나 빌그 서버 또는 다른 어떤 컴퓨터에서든 인프라를 배포할 수 있으며 이를 위해 추가 인프라를 생성할 필요가 없다. 정확하게는 terraform 바이너리가 AWS, 애저, 구글 클라우드, 디지털오션, 오픈스택등의 공급자를 대신해 API를 호출하여 리소스를 생성한다. 즉 테라폼은 클라우드 공급자가 제공하는 API 서버를 활용할 뿐만 아니라 AWS에 이미 보유한 API 키 같은 인증 메커니즘도 같이 사용한다는 의미이다.

 

테라폼은 어떻게 API를 호출할까? 테라폼은 생성하려는 인프라 정보가 담겨있는 텍스트로 이루어진 테라폼 구성 파일을 생성하여 API를 호출한다. 이러한 구성 값들이 코드형 인프라를 만드는 코드이다.

 

# 테라폼 설정 예시 코드
resource "aws_instance" "example: {
 ami		= "ami-0dsadks232bh0"
 instance_type = "t2.micro"
}
resource "google_dns_record_set" "a" {
 name		= "demo.google-example.com"
 managed_zone = "example-zone"
 type 		  = "A"
 ttl		  = 300
 rrdatas	  = [aws_instance.example.public_ip]
}

 

이전에 테라폼 코드를 본 적이 없더라도 코드를 이해하는데에 어려움이 없을것이다. 이 코드는 먼저 테라폼으로 하여금 AWS를 호출할 API를 생성하여 서버를 배포하게 한다. 그런 다음 API 가 구글 클라우드를 실행하여 AWS 서버에 접속하기 위한 서버 IP 주소를 지정하는 DNS 정보를 생성하도록 하는 내용이다. 이처럼 테라폼을 사용하면 하나의 단순한 구문으로 여러 클라우드에 상호 연결된 리소스를 배포할 수 있다.

테라폼 구성 파일에 서버, 데이터베이스, 로드 밸런서, 네트워크 토폴리지등 전체 인프라를 정의하고 해당 파일의 버전을 관리할 수 있다. 그런 다음 terraform apply 같은 특정 명령어를 시용하여 인프라를 배포할 수 있다.   terraform 바이너리는 사용자가 구성한 코드를 파싱하고 코드에 지정된 클라우드 공급자에 대한 일련의 API 호출로 변환한다. 즉 테라폼은 구성 내용을 클라우드 공급자에 대한 API 호출로 변환하는 바이너리이다.

팀틔 누군가가 인프라를 수정하고자 항 때, 서버에 직접 접속하여 작업하거나 수작업으로 수정하는 대신 테라폼을 사용하여 구성 파일을 수정할 수 있다. 자동 테스트와 코드 리뷰를 통해 유효성을 검증하고, 버전 관리 시스템에 코드를 커밋한다. 커밋이 완료된 후 terraform apply 명령어를 통해서 실제로 변경을 수행하는 API를 호출하여 인프라 변경을 진행한다.

 

(5) 테라폼과 다른 코드형 인프라 도구 비교

 인프라를 코드로 관리하는 것은 멋진 일이지만 코드형 인프라 도구를 선택하는 과정은 그렇지 않다. 많은 코드형 인프라 도구의 기능은 서로 겹친다. 어떤 도구는 오픈소스이고, 어떤 도구는 오픈소스이지만 상업용을 지원한다. 고려해야하는 주요 절충 사항은 다음과 같다.

- 구성관리 vs 프로비저닝

- 가변 인프라 vs 불변 인프라

- 절차적 언어 vs 선언적 언어

- 마스터 서버가 있는가?

- 에이전트가 있는가?

- 커뮤니티가 크고 활성화되어 있는가?

- 성숙한 기술인가, 아니면 최첨단 기술인가?

- 여러 도구를 함께 사용할 것인가?

 

(5)-1 구성관리 vs 프로비저닝

앞에서 살펴본 것처럼 셰프, 퍼핏, 앤서블, 솔트스택은 구성 관리 도구인 반면 클라우드포메이션, 테라폼, 오픈스택 히트는 프로비전 도구이다. 둘을 명확하게 구분하기가 애매할 수 있다. 앤서블을 사용해 서버를 배포하는 것처럼 일반적으로 구성관리 도구도 어느 정도의 프로비전을 수행할 수 있다. 테라폼을 사용하여 구성 스크립트를 실행하는것처럼 프로비전 도구 역시 어느정도 구성을 수행할 수 있기 때문이다. 일반적으로 사용하려는 목적에 맞는 도구를 선책하는것이 바람직하다.

특히 도커 또는 패커와 같은 서버 템플릿 도구를 사용하는 경우 대부분의 구성 관리 요구가 이미 반영되어 있다. 일단 도커파일 또는 패커 템플릿에서 이미지를 만들었다면 이제 이미지를 실행할 인프라를 프로비저닝 해야한다. 프로비저닝을 하려면 프로비전 도구를 선택하는 것이 최선이다.

서버 템플릿 도구를 사용하지 않는 경우 구성 관리 및 프로비전 도구를 함께 사용하는것이 좋다. 예를 들어 테라폼을 사용하여 서버를 프로비저닝하고 셰프를 실행하여 각 서버를 구성할 수 있다.

 

(5)-2 가변 인프라 vs 불변 인프라

셰프, 퍼핏, 앤서블, 솔트스택과 같은 구성 관리 도구는 일반적으로 가변 인프라 패러다임을 사용한다. 예를 들어 셰프에 새 버전의 OpenSSL을 설치하도록 지시하면 기존 서버에서 소프트웨어 업데이트가 실행되고 변경 사항이 적용된다. 시간이 지나면서 점점 더 많은 업데이트를 적용하는데 그때마다 각 서버는 고유한 변경기록을 작성한다. 결과적으로 매 서버가 약간씩 다를 수 있으므로 진단 및 재현이 어려운 구성에 관한 버그가 발생할 수 있다. 자동화된 테스트 환경에서도 이러한 버그를 파악하기 어렵다. 테스트 서버에서는 구성 관리 변경이 제대로 동작할 수 있지만 실제 운영 환경의 서버에는 테스트 환경에 반영되지 않은 지난 몇개월 동안의 변경 사항이 누적된다. 따라서 운영 서버에는 동일한 변경 내용이 다르게 동작할 수 있다.

 

테라폼과 같은 프로비전 도구를 사용하여 도커 또는 패커에서 생성한 머신 이미지를 배포하는 경우 대부분의 변경은 완전히 새로운 서버를 배포하느것과 같다. 예를 들어 새버전의 OpenSSL 을 배포하는 경우 패커로 새 버전의 OpenSSL 이 포함 된 새 이미지를 작성하여 배포한 다음 이전 서버는 종료한다. 모든 배포는 새로운 서버에서 변경 불가능한 이미지를 사용한다. 이 방식은 구성 드리프트 버그를 줄이고 각 서버에서 어떤 소프트웨어가 실행중인지 정확하게 알 수 있게한다. 그리고 이전 버전의 소프트웨어(이전 이미지)로 손쉽게 복원할 수 있다. 또한 테스트 환경에서 테스트를 통과한 변경 불가능한 이미지는 운영환경에도 동일하게 배포되므로 동일한 방식으로 작동한다. 따라서 자동테스트의 효율성을 높일 수 있다. 물론 구성 관리 도구도 변경 불가능한 배포를 수행할 수는 있지만 이는 적절한 접근 방법이 아니므로 프로비전 도구를 사용하는것이 적절한 접근법이다. 그러나 이 같은 접근 방식에는 단점도 있다. 예를들어 사소한 변경을 할 때조차 서버 템플릿에서 이미지를 재구성하고 모든 서버를 재배치하기 때문에 시간이 오래걸린다. 또한 불변성은 실제로 이미지를 실행하는 순간까지만 지속된다. 즉, 서버가 가동되어 실행되기 시작하면 하드 드라이브가 변경되므로 어느 정도의 구성 드리프트는 발생할 수밖에 없다. 

 

 

(5)-3 절차적 언어 vs 선언적 언어

셰프와 앤서블은 원하는 최종 상태를 달성하는 방법을 단계별로 지정하는 절차적 스타일 코드를 권장한다. 테라폼, 클라우드포메이션, 솔트스택, 퍼핏, 오픈스택 히트는 모두 원하는 최종 상태를 지정하는 선언적 방식의 코드를 권장한다. 선언적 언어란 구현하려는 최종 상태를 지정하는 코드를 말하며 이때 코드형 인프라 자체는 그러한 최종 상태를 어떻게 구현할 것인지 계산하는 역할을 한다.

테라폼의 선언적 방식을 사용하면 코드는 항상 인프라의 최신상태를 나타낸다. 이전 기록 또는 시간에 대해 걱정할 필요없이 현재 배포되어있는 인프라의 내용과 구성을 한눈에 확인할 수 있다. 또한 현재 상태를 수동으로 설명 할 필요가 없으므로 재사용 가능한 코드를 작성하기도 쉽다. 물론 선언적 방식의 프로그래밍 언어는 표현력이 제한되어 있다는 단점도 있다. 예를 들면 중단 시간 없이 인프라를 변경하기 어려울 수 있다.

 

 

(5)-4 마스터 서버 유무

셰프, 퍼핏, 솔트스택은 인프라 상태를 저장하고 업데이트를 배포하기 위해 마스터 서버를 실행한다. 인프라를 업데이트 하려면 명령줄 도구와 같은 클라이언트를 사용하여 마스터 서버에 새 명령을 실행한다. 그러면 마스터 서버가 업데이트 내용을 모든 서버로 푸시하거나, 서버들이 주기적으로 마스터 서버에서 최신 업데이트를 가져온다.

마스터 서버에는 몇 가지 장점이 있다. 첫째 마스터 서버는 인프라의 상태를 살펴보고 관리할 수 있는 단일한 중앙 저장소 역할을 한다. 많은 구성 관리 도구는 마스터 서버에 셰프 콘솔, 퍼핏 엔터프라이즈 콘솔과 같은 웹 인터페이스를 제공하여 상황을 쉽게 확인할 수 있다. 둘째, 어떤 마스터 서버는 백그라운드에서 지속적으로 실행되어 구성의 일관성을 유지한다. 이렇게하면 누군가 서버를 수동으로 변경하더라도 마스터 서버는 변경사항을 되돌려 놓으므로 구성 드리프트 문제가 발생하는 것을 방지할 수 있다.

 

그러나 마스터 서버를 실행하는데는 몇가지 중대한 단점이 있다.

- 추가 인프라 필요

마스터를 실핼하려면 추가 서버 또는 고가용성 및 확장을 위해 클러스터링 된 서버사 필요하다/.

- 유지 관리

마스터 서버를 유지, 업그레이드, 백업, 모니터링 및 확장해야한다.

- 보안

클라이언트가 마스터 서버와 통신할 방법, 그리고 마스터 서버가 다른 모든 서버와 통신할 방법을 마련해야한다. 이는 일반적으로 추가 인증 시스템을 구성하는 것을 의미한다. 그런데 이러한 구성은 서버가 공격당할 가능성을 높인다.

 

앤서블, 클라우드 포메이션, 오픈스택 하트, 테라폼은 기본덕으로 마스터가 없는 도구이다. 더 정확하게 말하면 일부 서버는 마스터 서버에 의존할 수 있지만 이미 사용중인 인프라의 일부이며 관리해야 할 추가적인 요소가 아니다. 예를 들면 테라폼은 클라우드 업체가 제공하는 API 를 이용하여 동작한다. 앤서블은 SSH로 각 서버에 직접 연결하여 작업한다. 그렇기 때문에 어떤 추가적인 인프라 추가 인증 메커니즘을 관리 할 필요가 없다.

 

 

(5)-5 여러 도구를 함께 사용

앞서 코드형 인프라 도구를 비교했지만, 실제로 인프라를 구축하기 위해서는 여러 도구를 함께 사용해야 할 수도 있다. 살펴본 각 도구에는 장단점이 있으므로 적절한 도구를 선택하는 것이 중요하다.

 

프로비저닝과 구성관리 

테라폼과  앤서블을 함께 사용할 수 있다. 테라폼을 사용하여 VPCs(Virtual Private Clouds, 가상 프라이빗 클라우드) 서브넷, 라우팅 테이블 같은 네트워크 토폴리지와 MySQL, 레디스 같은 데이터 저장소 그리고 로드 밸런서, 서버 등을 포함한 모든 기본 인프라를 배포한다. 그런 다음 앤서블을 사용하여 서버에 앱을 배포한다. 이와 같은 방법은 처음에 접근하기 쉬운 방법이다. 테라폼과 앤서블은 클라이언트 전용 응용 프로그램으로서 추가로 실행할 인프라가 없고 앤서블과 테라폼을 함께 작동시킬 수 있는 방법이 있기 때문이다.  테라폼이 서버에 특별한 태그를 추가하고 앤서블은 그렇게 추가한 태그를 이용하여 서버를 식별하고 구성을 진행한다. 그러나 일반적으로 앤서블을 변경가능한 형태로 사용하면 절차적인 요소가 많은 코드를 작성해야 하므로 인프라 및 조직이 성장함에 따라 유지 관리가 어려워질 수 있다는 단점이 있다.

 

프로비저닝과 서버 템플릿

테라폼과 패커를 함께 사용할 수 있다. 패커를 사용하여 앱을 VM 이미지로 패키징한다. 그런 다음 테라폼을 사용하여 VM 이미지를 배포하고, VPCs, 서브넷, 라우팅 테이블 등 나머지 인프라 네트워크 토폴리지와 MySQL, 레디스 등 데이터 저장소, 로드 밸런서를 배포한다.

테라폼과 패커는 모두 클라이언트 전용 응용 프로그램이므로 이 구성도 추가적으로 구성할 인프라가 없기 때문에 초반에 쉽게 접근할 수 있다. 테라폼을 사용하여 VM이미지를 배포하는 작업을 많이 한다. 또한 불변 인프라 접근 방식이므로 유지 관리가 더 쉽다. 하지만 주요 단점이 있다. 첫째, 먼저 VM을 구축하고 배포하는데 시간이 오래 걸리므로 배포 속도가 느려질 수 있다. 둘째 테라폼에서는 기본젇으로 블루 - 그린 배포응 구현할 수 없는것과 같이 테라폼으로 구현할 수 있는 배포 전략은 제한적이다. 그러므로 복잡한 배포 스크립트를 많이 작성해야 하거나 오케스트레이션 도구를 사용한다.

 

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

테라폼, 패커, 도커 그리고 쿠버네티스를 함께 사용할 수 있다. 패커를 사용하여 도커 및 쿠버네티스가 설치된 VM 이미지를 생성한다. 그런 다음 테라폼을 사용하여 VM 이미지를 실행하는 서버, 나머지 인프라와 VPCs, 서브넷, 라우팅 테이블 같은 네트워크 토폴리지와 MySQL, 레디스 등 데이터 저장소, 로드 밸런서를 배포한다. 마지막으로 서버가 구동되면 컨테이너로 괸 애플리케이션을 쿠버네티스같은 오케스트레이션 도구에서 실행한다.

이 방법의 장점은 도커 이미지가 상당히 빠르게 빌드되고 로컬 컴퓨터에서 이미지를 실행하여 테스트할 수 있으며 다양한 배포 전략, 자동 복구, 자동 확장 기능을 포함하여 쿠버네티스의 모든 내장 기능을 활용할 수 있다는 점이다. 단점은 추가적인 인프라가 필요하므오 운영이 복잡해진다는 점이다. 쿠버네티스 클러스터는 배포 및 운영이 어렵고 비용이 많이 든다. 그러나 다행히도 현재 대부분의 주요 클라우드 공급자는 세심하게 관리되는 쿠버네티스 서비스를 제공하고 있다. 

 

 

 

 

 

 

출처 : 테라폼 업앤러닝 / 예브게니 브릭만 지음 / 김문주 옮김 (루비페이퍼)