[테라폼/Terraform]왜 테라폼을 사용해야 하는가? 1-2

3. 코드형 인프라의 장점

▶ 자급식 배포(self-service)

: 인프라 코드 정의 시 전체 배포 프로세스를 자동화 할 수 있으며, 이는 개발자가 필요할 때마다 자체적으로 배포를 진행할 수 있습니다.

 

▶ 속도와 안정성(speed and safety)
: 자동화하면 사람이 진행하는 것보다 훨씬 빠르게 배포를 할 수 있으며, 자동화 된 프로세스는 일관되고 오류를 적게 발생 합니다.

 

▶ 문서화(documentation)

: 문서화가 되어 누구나 읽을 수 있는 코드로 인프라 상태를 알 수 있으며, 담당자가 자리에 없더라도 조직의 모든 사람이 구조를 이해하고 대체할 수 있습니다.

 

▶ 버전 관리(version control)

: 코드형 인프라는 소스를 통해 버전 관리가 가능하며, 히스토리가 남아있어 시스템에 문제가 생겼을 경우 이전 버전으로 빠르게 롤백이 가능합니다.

 

▶ 유효성 검증(validation)

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

 

▶ 재사용성(reuse)

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

 

 

---

4. 코드형 인프라의 장점

테라폼은 해시코프사가 Go 언어로 개발한 오픈 소스 도구입니다.

운영 체제마다 바이너리 파일이 존재하는데 Go 코드는 하나의 바이너리 파일로 컴파일되며 terraform이라는 명령어로 실행할 수 있습니다.

 

▶ 테라폼 설정 예시

resource "aws_instance" "example" {
	ami = "ami-xxxxxxxx"
	instance_type = "t2_micro"
}

resource "google_dns_record_set" "a" {
	name = "example.example.com"
	managed_zone = "example-zone"
	type = "A"
	ttl = 300
	rrdatas = [aws_instance.example.public_ip]
}

 

이 코드는 먼저 테라폼으로 하여금 AWS를 호출할 API를 생성하여 서버를 배포하게 합니다.

그런 다음 API가 구글 클라우드를 실행하여 AWS의 서버에 접속하기 위한 서버 IP 주소를 지정하는 DNS 정보를 생성하도록 하는 내용입니다.

이처럼 테라폼을 사용하면 하나의 단순한 구문으로 여러 클라우드에 상호 연결된 리소스를 배포할 수 있습니다.

테라폼 명령어를 사용하면 terraform 바이너리는 사용자가 구성한 코드를 파싱하고 코드에 지정된 클라우드 공급자에 대한 일련의 API 호출로 변환합니다.

 

 

---

 

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

▶ 구성관리 VS 프로비저닝

: 구성 관리 도구와 프로비전 도구, 둘을 명확하게 구분하기가 애매할 수 있습니다.

구성 관리 도구도 어느 정도의 프로비전을 수행할 수 있고, 프로비전 도구 역시 어느 정도의 구성을 수행할 수 있습니다.

일반적으로는 사용하려는 목적에 맞는 도구를 선택하는 것이 바람직합니다.

현재는 구성 관리 도구 중 일부가 셰프 프로비저닝, 퍼핏 AWS 모듈과 같은 프로비저닝 지원을 점진적으로 포함시켰기 때문에 구성 관리와 프로비저닝은 점점 구분하기 애매하지고 있습니다.

 

※ 프로비저닝이란?

사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것을 말한다.

서버 자원 프로비저닝, OS 프로비저닝, 소프트웨어 프로비저닝, 스토리지 프로비저닝, 계정 프로비저닝 등이 있다.

- 참조 : https://ko.wikipedia.org/wiki/프로비저닝

 

▶ 가변 인프라 VS 불변 인프라

: 구성 관리 도구는 일반적으로 가변 인프라를 패러다임을 사용합니다.

예를 들어 셰프에 새 버전의 OpenSSL을 설치하도록 지시하면 기존 서버에서 소프트웨어 업데이트가 실행되고 변경 사항이 적용됩니다.

점점 더 많은 업데이트를 진행할 떄 마다 결과적으로는 매 서버가 약간씩 다를 수 있으므로 진단 및 재현이 어려운 미묘한 구성에 버그가 발생할 수 있습니다.

실제 운영 환경의 서버와 테스트 서버 환경 서버가 누적 되어있는 업데이트가 달라 서로 다르게 동작할 수도 있습니다.

 

테라폼과 같은 프로비전 도구를 사용하여 도커 또는 패커에서 생성한 이미지를 배포하는 경우 대부분의 ‘변경’은 ‘새로운 서버’를 배포하는 것과 같습니다.

예를 들어 새 버전의 OpenSSL을 배포하는 경우 패커로 새 버전의 OpenSSL이 포함된 새 이미지를 작성하여 배포한 다음 이전 서버는 종료합니다.

모든 배포는 새로운 서버에서 변경 불가능한 이미지를 사용합니다.

 

이와 같은 방식은 버그를 줄이고 각 서버에서 어떤 소프트웨어가 실행 중인지 정확하게 알 수 있으며 이전 버전의 소프트웨어로 손쉽게 복원할 수 있습니다.

그러나 이런한 방식에도 단점은 있습니다. 예를 들어 사소한 변경을 할 때조차 모든 서버를 재배치하기 떄문에 시간이 오래 걸립니다.

더구나 ‘불변성’은 실제로 이미지를 실행하는 순간까지만 지속됩니다. 서버가 가동된 후에는 임의적으로 서버의 구성을 변경할 수 있기때문에 어느 정도의 드리프트가 발생할 수 있습니다. 빈번하게 배포하는 경우 이러한 문제를 완화할 수 있습니다.

 

※ 드리프트란?

Template에 정의했던 Resource가 실제로 없거나 다르거나 하는 경우.

Resource를 사용자가 직접 수작업으로 수정하는 경우 이런 케이스가 발생할 수 있다.

 

▶ 절차적 언어 VS 선언적 언어

: 셰프와 앤서블은 단계별로 지정하는 절차적 언어 스타일 코드를 권장하고 테라폼, 클라우드 포메이션, 솔트스택, 퍼핏, 오픈스택 히트는 선언적 방식의 코드를 권장합니다.

 

※ 선언적 언어란?

구현하려는 최종 상태를 지정하는 코드를 말하며 이때 코드형 인프라 자체는 그러한 최종 상태를 어떻게 구현할 것인지 계산하는 역할을 말합니다.

 

차이점을 설명하기 위한 간단한 예를 들어보겠습니다.

 

- 절차적 접근 방식

- ec2:
	count: 10
	image: ami-000000000
	instance_type: t2.micro

 

- 선언적 접근 방식

resource "aws_instance" "example" {
	count = 10
	ami = "ami-000000000"
	instance_type = "t2.micro"
}

 

 

두 코드의 실행결과는 같은 결과를 내놓습니다.

서버의 갯수가 10대에서 15대로 변경이 필요하다고 하면 앤서블 같은 경우는 현재 배포되어 있는 서버가 몇 대 인지 파악 후 코드를 수정해야 합니다.

 

- 절차적 접근 방식

- ec2:
	count: 5
	image: ami-000000000
	instance_type: t2.micro

 

하지만 선언적 코드는 이전 서버의 상태를 종료 후 새롭게 서버를 배포합니다.

 

- 선언적 접근 방식

resource "aws_instance" "example" {
	count = 15
	ami = "ami-000000000"
	instance_type = "t2.micro"
}

 

 

절차적 접근 방식에는 다음 2가지 주요한 문제점이 있습니다.

• 절차적 코드는 인프라의 마지막 상태 정보를 기록하지 않습니다.
  템플릿을 읽는 것만으로는 무엇이 배포되었는지 알 수 없는니다. 템플릿이 적용 된 순서까지 알아야 무엇이 배포되었는지 알 수 있습니다. 적용 순서가 다르면 다른 인프라이기 때문에 코드만 보고 알아내기 어렵습니다.
• 절차적 코드는 재사용 가능성을 제한합니다.
  절차적 코드는 인프라의 현재 상태를 수동으로 고려해야 하기 때문에 재사용성이 본질적으로 제한됩니다. 결국 시간이 지남에 따라 규모가 커지고 복잡해지는 경향이 있습니다.

 

테라폼의 선언적 방식은 항상 인프라의 최신 상태를 나타냅니다.

그러기에 인프라의 내용과 구성을 한눈에 확인할 수 있으며, 코드의 재사용이 가능합니다.

 

 

▶ 마스터 서버유무

셰프, 퍼핏, 솔트스택은 인프라 상태를 저장하고 업데이트를 배포하기 위해 마스터 서버를 실행합니다.

 

마스터 서버의 장점

• 마스터 서버는 인프라의 상태를 살펴보고 관리할 수 있는 단일화 중앙 저장소 역할을 합니다.
• 어떤 마스터 서버는 백그라운드에서 지속적으로 실행되어, 구성의 일관성을 유지할 수 있습니다.

마스터 서버의 단점

• 추가 인프라 필요 : 마스터 서버를 실행하려면 추가 서버 또는 고가용성 및 확장성을 위해 클러스터링된 서버가 필요합니다.
• 유지 관리 : 마스터 서버를 유지, 업그레이드, 백업, 모니터링 및 확장해야 합니다.
• 보안 : 마스터 서버가 다른 서버와 통신을 해야하기에 포트를 열어야 하는데 이는 서버가 공격을 당할 가능성을 높입니다.

 

테라폼은(프로비전 도구) 마스터 서버가 없는 도구입니다. 예를 들어 테라폼은 클라우드 업체가 제공하는 API를 이용하여 동작하는데 어떤 의미에서는 API 서버가 마스터 서버가 될 수 있지만 추가 인프라나 인증 메커니즘이 필요하지 않습니다. 단지 사용자의 API키를 사용하면 됩니다.

 

▶ 에이전트 유무

셰프, 퍼핏, 솔트스택은 모두 구성하려는 서버에 에이전트를 설치해야 합니다.

이러한 에이전트는 백그라운드에서 실행되며 구성 관리 업데이트의 설치를 담당합니다.

 

에이전트의 단점

• 부트스트랩 : 어떻게 서버를 할당하고 에이전트를 설치해야 할까요? 일반적으로는 부트스트랩 즉 일회성 명령을 실행하여 클라우드 업체가 제공하는 API로 서버를 할당하고 SSH를 통해 해당 서버에 에이전트를 설치해야 합니다.
• 유지 관리 : 에이전트는 마스터 서버와 동기화 상태를 유지하도록 소프트웨어를 정기적으로 업데이트해야 합니다.
• 보안 : 에이전트가 마스터서버의 구성이 필요할 경우 모든 서버의 아웃바운드를 열어줘야 합니다. 이는 서버가 공격 당할 가능성을 만들어 줍니다.

구성 요소 간 관계가 복잡해지면 다양한 장애가 발생할 수 있습니다.

셰프 서버 예시

 

테라폼은 추가적인 에이전트를 설치할 필요가 없습니다.

더 정확하게 말하면 일부는 에이전트를 필요로 하지만 사용 중인 인프라의 일부로 이미 설치되어 있습니다.

 

▶ 커뮤니티 규모와 활성화

기술을 선택할 때 커뮤니티의 규모도 중요하게 고려해야 합니다.

커뮤니티 규모가 어느정도 활성화 되어 있어야 정보를 찾기 좀 더 용이합니다.

 

- 2019년 4월 중순 ~ 5월 중순 기준

 

	공개 유무	클라우드 지원	기여자 수	별점	커밋 수 (1개월)	버긋 수 (1개월)	라이브러리	스택 오버플로 질문 수	도구 언급 직업 수
셰프	공개	전체	562	5,794	435	86	3,832a	5,982	4,378b
퍼핏	공개	전체	515	5,299	94	314c	6,110d	3,585	4,200e
앤서블	공개	전체	4,386	37,161	506	523	20,677f	11,746	8,787
솔트스택	공개	전체	2,237	9,901	608	441	318g	1,062	1,622
클라우드 포메이션	비공개	AWS	?	?	?	?	377h	3,315	2,318
오픈스택 히트	공개	전체	361	349	12	600i	0j	88	2,201k
테라폼	공개	전체	1,261	16,837	173	204	1,462l	2,730	3,641

 

위의 표를 보면 몇 가지 사실을 알 수 있습니다.

• 클라우드 포메이션을 제외하면 모든 클라우드에서 사용할 수 있습니다.
• 앤서블은 인기 면에서 선두를 달리고 있으며 솔트스택과 테라폼이 뒤를 쫓고 있습니다.

즉 테라폼과 앤서블은 오늘날 활발한 대규모 커뮤니티를 보유하고 있으며, 이러한 경향에 따라 향후에 커뮤니티가 더욱 커질것으로 보입니다.

 

▶ 성숙한 기술 VS 최첨단 기술

 

	출시 연도	현재 버전
퍼핏	2005	7.1
셰프	2009	14.0.25
클라우드 포메이션	2011	???
솔트스택	2011	3002.2
앤서블	2012	2.9
오픈스택 히트	2012	15.0.0-39
테라폼	2014	0.13.5

테라폼은 인프라 도구들 중 가장 최근에 나왔으며, 1.0.0 이전의 버전이므로 아직은 안정적이지 않고 버그가 존재할 수 있습니다. 이것이 테라폼의 큰 약점입니다.

 

▶ 여러 도구를 함께 사용

실제 인프라를 구축하기 위해서는 여러도구를 함께 사용해야 할 수도 있습니다.

다음은 자주 사용하는 세 가지 일반적인 코드형 인프라 도구 조합입니다.

 

- 프로비저닝과 구성 관리

테라폼과 앤서블을 함께 사용할 수 있습니다.

테라폼을 사용하여 인프라 구성을 하고 앤서블을 사용하여 앱을 배포합니다.

그러나 일반적으로 앤서블을 변경 가능한 형태로 사용하면 절차적인 요소가 많은 코드를 작성해야 하므로 인프라 및 조직이 성장함에 따라 유지 관리가 어려워질 수 있다는 단점이 있습니다.

 

- 프로비저닝과 서버 템플릿

테라폼과 패커를 함께 사용할 수 있습니다. 테라폼으로 인프라를 구성하고 패커를 사용하여 VM 이미지로 배포 할 수 있습니다.

하지만 두 가지의 주요 단점이 존재합니다.

• VM을 구축하고 배포하는데 시간이 오래 걸릴 수 있습니다.
• 테라폼에서는 기본적으로 블루-그린 배포를 구현할 수 없는 것과 같이 테라폼으로 구현할 수 있는 배포 전략은 제한적입니다.

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

테라폼, 패커, 도커 그리고 쿠버네티스를 함께 사용할 수 있습니다.

패커를 사용하여 도커 및 쿠버네티스가 설치된 VM 이미지를 생성, 테라폼을 이용하여 인프라 구성, 마지막으로 서버가 구동되면 쿠버네티스로 애플리케이션을 실행 할 수 있습니다.

이 방법의 장점은 도커의 이미지가 상당히 빠르게 빌드되고 로컬 컴퓨터에서 이미지를 실행하여 테스트할 수 있으며 다양한 배포 전략, 자동 복구, 자동 확장의 기능을 활용할 수 있습니다.

단점은 추가적인 인프라가 필요하므로 운영이 복잡해집니다. 또한 오케스트레이션 도구를 학습하고 관리 및 디버깅을 해야합니다.

 

 

	공개 유무	클라우드 지원	도구 유형	인프라	언어	에이전트 유무	마스터 서버 유무	커뮤니티 규모	성숙도
셰프	공개	전체	구성 관리	가변	절차적	있음	있음	큼	상
퍼핏	공개	전체	구성 관리	가변	절차적	있음	있음	큼	상
앤서블	공개	전체	구성 관리	가변	절차적	없음	없음	매우 큼	중
솔트스택	공개	전체	구성 관리	가변	선언적	있음	있음	큼	중
클라우드 포메이션	비공개	AWS	프로비저닝	불변	선언적	없음	없음	작음	중
히트	공개	전체	프로비저닝	불변	선언적	없음	없음	작음	하
테라폼	공개	전체	프로비저닝	불변	선언적	없음	없음	매우 큼	하

코드형 인프라 도구는 유연합니다.

불변의 인프라와 선언적 언어를 사용하며 대규모의 커뮤니티와 성숙한 코드베이스를 가졌습니다.

테라폼이 완벽하진 않지만 모든 기준을 충족시키는 도구에 가장 가깝다고 볼 수 있습니다.

 

 

 

 

참조 : https://book.naver.com/bookdb/book_detail.naver?bid=20489970

테라폼 업앤러닝