복잡한 production 배포 환경을 쉽고 간결하게 관리하는 Terraform 사용법 탐색하기
“한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다.”
인프라 쪽 업무를 보다 보면 필연적으로 듣게 되는 용어 중 하나는 “IaC”다.
IaC는 Infrastructure as Code의 약자로, 쉽게 말해 회사의 인프라의 관리를 소스코드로 관리하는 방식에 대해 정의하는 방법을 의미한다.
처음에 회사에서 IaC 툴 도입 논의를 했을 때, 어리둥절 했다.
“지금 회사에서 관리하는 모든 인프라를 배포/유지/보수하는데 전혀 문제가 없는데 저 IaC를 왜 도입하는거지?”
실제로 IaC가 없을 때는 kubernetes 애플리케이션을 하나씩 배포하는 절차를 거쳤었고 (kubectl apply -f …) 아직 회사 인프라가 작을 때다 보니 배포하고 관리하는 것에 큰 어려움을 느끼지 못했다.
무엇보다 현재 회사에서 MLOps 팀이 인프라 업무를 함께 담당하면서 일하고 있는데, 이 부분이 IaC 툴을 도입하는 것에 대해 내가 큰 의문을 안갖게 했던 것 같다.
예를 들어, 회사에 인프라 팀이 따로 있어 온프레미스 & 클라우드 클러스터를 관리한다고 생각해보자.
이 때 하드웨어 서버 구축, 네트워크 연결, 전력 이중화 등의 업무는 인프라 팀에서 담당하고, 구성된 서버에 올라가는 소프트웨어를 개발하는 일은 우리가 알고 있는 개발자들이 담당하게 된다.
이 때 인프라팀에서 운영 서버의 설정 변경 등이 이뤄지게 되면, 개발자들이 진행하는 업무에 의존성이 존재하므로 영향을 받을 수 밖에 없는데 이 때 커뮤니케이션과 문제를 해결하는데 투입되는 시간 등의 비용이 발생할 수 밖에 없다.
무엇보다 인프라팀이 관리하는 인프라를 하나 하나 수동으로 관리한다고 상상해보면, 반복되는 컴포넌트 & 자주 사용하는 관리용 애플리케이션 등에 휴먼 에러가 섞이기 마련이고 결과적으로 관리 비용이 늘어날 수 밖에 없다.
그래서 IaC와 같은 툴이 필요하다.
IaC를 도입하면서 얻게 되는 이점은 여러가지가 있겠지만,
- 대표적으로 반복적인 컴포넌트를 한 곳에 정의해서 재사용 가능한 모듈로 구성할 수 있다는 점
- 소스코드로 인프라를 관리함으로써 인프라 명문화 가능
- 버전 관리
- 로깅
- 휴먼 에러 대폭 감소
등의 이점을 누릴 수 있다.
IaC에 대해 알고 적용한 이후로 IaC가 없는 세상에서 인프라를 관리하는 것은 무척 끔찍한 일이라는 것을 상상하게 된다.
예를 들어, 작년 하반기에 카카오 서버가 입주해 있는 IDC 센터에서 화재가 발생해서, 카카오 엔지니어들이 인프라 복구를 하기 위해 밤낮없이 업무에 매달렸다는 소식을 들었다.
만약 이 때 인프라 복구를 카카오와 같은 규모의 회사에서 엔지니어가 하나하나 수동으로 복구했다면? 3일 정도 시간 걸렸던 복구 업무가 몇 배는 더 늘어났을 것이고, 엔지니어들의 건강에도 악영향을 줬을 것이다.
terraform은 국내외로 가장 잘 알려져 있는 IaC 툴이고, 이미 많은 기업들에서 terraform을 사용해서 인프라 관리를 하고 있는 것으로 알고 있다.
기본적으로 다양한 인프라 관리 환경을 감안하여 온프레미스를 포함해 여러 provider들의 배포 환경들을 지원하고 있으며, terraform에는 HCL 이라고 해서 HashiCorp Configuration Language라는 형태의 소스코드로 인프라 스크립트를 작성하는 것이 가능하다.
책 읽으면서 이 부분이 terraform 도입할 때의 가장 큰 진입 장벽이 아닌가 고민을 했었고, 현재 회사에서 AWS 인프라 관리에 terraform을 도입했을 때도 “어차피 terraform 하나만을 사용하는데 사용하는 프로그래밍 언어면, 배워놓고 다른 곳에 사용하기에 확장성이 너무 떨어진다” 라는 생각을 하게 만들었다.
특히, AWS에 terraform 도입하기 전에 온프레미스 서버에는 Pulumi라는 Terraform의 경쟁 툴을 도입해서 사용하고 있는데, Python / Typescript / Golang 등 일반 프로그래밍 언어로 SDK를 지원하고 있다.
그런 부분에서 Pulumi는 진입장벽이 Terraform보다는 낮다는 장점이 분명히 존재하지만, 문제는 레퍼런스를 찾는 방법에 있었다.
Terraform 사용자 커뮤니티가 Pulumi 보다 전세계적으로 더 크고, 한국 내에서 참고 자료를 찾다보면 여러 회사에서 이미 사용한 사례를 충분히 공유하고 있던 덕분에 Terraform 스크립트를 구성하면서 발생한 에러에 더 빠른 대응이 가능하다.
그리고 이건 개인적으로 느끼는 부분이지만, Terraform이 서비스의 Output을 다루는 것이 Pulumi에 비해 좀 더 직관적이라는 생각이 든다.
스크립트를 구성할 때, output을 “output” 블록에 별도로 정의해서 구성하는데, 이 부분을 모듈화 해놓으면 함께 개발하는 팀원들이 output에 대한 사항을 빠르게 찾을 수 있는데, pulumi에서 이 부분은 못 본 것 같다.
배포할 때마다 state를 기록하는데, 이 state를 기반으로 로깅하는 것도 쉽고, terraform cloud를 사용하면 RBAC이 가능해서 배포한 사용자를 추적하는 것도 쉽다.
결정적으로 클라우드 서비스 사용할 때 굉장히 편리한 것이 현재 AWS / Azure / GCP 등에서 멀티 리전에 걸친 엔터프라이즈 서비스들을 통합해 볼 수 있는 대시보드를 별도로 제공하고 있지 않는데, Terraform을 사용해서 소스코드로 관리하면 회사 인프라를 한 번에 파악할 수 있다는 장점을 갖는다.
(아마 클라우드 업체들이 사용자의 망각을 유도해서 비용 과금을 유도했을 것이란 합리적인 추측이 있다.)
ClickOps만으로 인프라 관리하는 것도 무척 번거로운 일이고, 개발을 배운 이래로 지속적으로 직면하는 상황은 “더 효율적이고, 반복 업무의 자동화” 였고 Terraform은 이 관점에서 봤을 때 정말 합리적인 툴이라고 생각한다.
지금도 이 책은 회사에서 Terraform 코드를 손댈 때 참고하는 서적으로 옆에 두고 보면서 작업하고 있다.
Terraform 문서가 조금 불친절하다는 생각이 드는데(?) 옆에 한국어 도서 한 권이 있어서 영문서가 이해가 안 될 때 참고할 수 있어 무척 든든하다.
인프라 뿐만이 아니라 Micro Service Architecture로 인해 애플리케이션도 점점 독립적으로 관리해가는 추세인데, 회사 규모가 조금만 커져도 관리해야하는 애플리케이션이 무척 많아지는 것을 생각하면 terraform을 사용하는 것은 엔지니어 한 명 당 생산성을 무척 끌어올릴 수 있다.
개발자로서 창업을 해서 서비스를 운영한다면, 이러한 Terraform을 사용한 production 인프라 관리는 초기 창업 단계의생산성에 무척 기여하지 않을까 싶다.
Ryan
