on
[ Terraform Up&Running ] 왜 테라폼을 써야할까?
이 글은 Terraform Up&Running 책을 읽고 쓴 글입니다.
더 자세한 내용을 원하시면 해당도서 구매를 추천드립니다.
아 리소스 잘못 건드렸다
AWS, AZURE, GCP 등의 클라우드 서비스를 사용하는 환경에서 개발 업무를 하다 보면 종종 개발 서버를 위한 인프라를 작업해야 할 일이 생긴다.
주로 새로운 인프라를 띄우거나, 서버에 접근할 수 있는 권한을 추가하거나, 로드밸런서의 설정을 변경하거나 하는 등의 작업을 위해서인데, 막상 작업을 위해 콘솔에 들어가면 수많은 리소스들 때문에 내가 어떤 작업을 해야 하는지 헤매곤 한다. ( 나는 지금도 들어갈때 마다 헤맨다 )
이것은 서비스를 위해 필요한 리소스 자체가 많고, MSA 환경일 경우에 여러 서비스를 위한 리소스가 올라가 있기 때문에 더더욱 인프라 작업은 삽질로 이어지기 마련이다.
수많은 AWS 리소스에서 내가 원하는 것을 찾는것은 정말 힘든 일이다
인프라를 콘솔(수동) 으로 관리하면 원하는 작업을 하기 어려운 것도 있지만, 기존에 띄워 뒀던 인프라의 관리가 안되는 것도 큰 문제점이다. 관련하여 전해져 내려오는 이런 이야기가 있다.
그 서버는 건드리지도 말고, 가르키지도 말고, 쳐다보지도 마!
출처를 알 수 없이 전해지는 이야기가 하나 있다. 데이터 센터에 로그인 정보도 모르고 용도도 모르는 서버 한 대가 있었다. 누군가 용감하게 나서서 그 서버를 네트워크에서 제거했다. 그러자 네트워크가 완전히 마비되어 즉시 케이블을 다시 연결했다. 그 후 누구도 서버를 다시는 건드리지 않았다.
Kief Morris, 『Infrastructure as Code: Managing Servers in the Cloud』
인프라가 커지고 복잡해질 수록 이러한 문제들은 기하급수적으로 증가하는데, 이러한 문제를 해결하기 위해 나온 툴들이 바로 IaC(Infra as Code) 도구들이고, Terraform 은 그 도구중 가장 대표적인 제품이다 .
데브옵스의 등장
클라우드 서비스가 성행하기 이전, 소프트웨어 회사는 물리적인 인프라를 관리하며 이를 관리하는 인프라팀을 따로 두었다. 개발팀은 개발팀 (Devs) 인프라 운영팀은(Ops) 팀이라고 불렀다.
개발팀이 개발을 하여 운영팀에 넘겨주면, 이를 운영팀이 실제 운영환경에 배포했는데, 이 과정이 모두 수동으로 이루어지다 보니 서버마다 설정이 묘하게 다른 구성 드리프트나 개발환경과 운영환경의 차이 때문에 서비스가 정상적으로 운영환경에서 동작하지 않는 문제가 생기곤 했다.
하지만 클라우드 서비스의 도입 이후 이러한 모습은 많이 달라졌는데, 인프라 리소스들을 물리적으로 다루지 않고 코드로 정의하고 관리할 수 있게 되면서 개발팀과 운영팀의 경계가 모호해졌기 때문이다.
해당 책에서는 데브옵스의 정의를 아래와 같이 하고있다.
데브옵스는 소프트웨어를 효율적으로 전달하는 프로세스다.
데브옵스의 필수품, 코드형 인프라
코드형 인프라(IaC)란 코드를 통하여 인프라를 생성, 배포, 수정, 삭제하는 것을 말한다. 이에는 아래와 같이 다섯가지 종류가 있다.
- 애드혹 스크립트 : bash 스크립트 등을 서버에 직접 실행하는 방식
- 구성 관리 도구 : 세프, 퍼핏, 앤서블 등 서버의 환경 구성을 구성정의 파일을 통해 관리하는 도구
- 서버 템플릿 도구 : 도커 등으로 서버 환경에 필요한 운영체제, 소프트웨어, 파일등을 모두 포함하고 있는 이미지(스냅숏)으로 관리하는 도구
- 오케스트레이션 도구 : 쿠버네티스 등으로 위 서버 템플릿 도구로 생성한 서버 스냅숏을 실제 인프라에 띄워 관리하는 도구
- 프로비전 도구 : 위 도구들과는 다르게 인프라 자체를 생성하는 도구 - 테라폼은 여기에 속한다
코드형 인프라의 장점
여기까지 왔으면 코드형 인프라를 왜 사용해야 하는지에 대한 의문이 생긴다. 배시 스크립트 와 AWS콘솔 만으로도 서버를 편하게 관리할 수 있는데, 왜 새로운 도구와 DSL를 공부하고 더 많은 코드를 작성해야 할까?
- 자급식 배포 : 자동 배포 파이프라인을 구성해 놓음으로써, 일부의 관리자 말고도 모든 개발자가 원할때 직접 배포할 수 있다.
- 속도와 안정성 : 사람 대신 컴퓨터가 자동으로 배포하면 당연히 속도가 빨라지고 human error 가 날 확률이 적어진다.
- 문서화 : 소스파일 자체가 인프라에 대한 문서 역할을 한다.
- 버전관리 : 인프라의 변경 내역을 git 과 같은 버전 관리 도구로 관리할 수 있다.
- 유효성 검증 : 인프라가 변경을 적용 전 정적 분석을 통해 오류를 미리 잡을 수 있다.
- 재사용성 : 인프라 코드를 재사용 함으로써 비슷한 인프라에 대해서 두번 일하지 않아도 된다.
- 행복 : 수동으로 인프라를 관리하고 배포를 한다는 것 자체가 큰 고통이다!
테라폼 쓰고 행복 찾자
글을 마치며
이번 글에서는 데브옵스의 등장 배경과, 코드형 인프라 도구들의 종류, 코드형 인프라의 장점에 대하여 알아보았다.
개인적으로 책에 나와 있었던 인프라를 수동으로 관리하였을 때의 문제점에 대한 공감이 많이 되었는데, 인프라를 관리하는 고통에 대해서는 아마도 인프라를 직접 관리해본 사람이라면 누구든 고개를 끄덕였을 것이라 생각한다.
다음 글에서는 테라폼의 기본 사용법에 대해 적어보려 한다.
Discussion and feedback