about me
20'S LIFE IN SYDNEY and BUSAN
IaC의 의미와 필요성
AWS 콘솔을 이용해 인프라 구성을 진행하는 것이 항상 좋은 일일까요?
이러한 상황을 가정해볼게요!
인프라를 완전히 다른 리전에 똑같이 복제하고 싶을 경우
특히, 해당 리전이 갑자기 사용할 수 없는 상황에 직면했을 경우
기존과는 다른 새로운 아키텍처를 빠른 시간 내에서 적용해야 할 경우
수동 설정의 한계
수동 설정은 쉽게 서비스를 제공하고, 아키텍처를 빠르게 실험해볼 수 있다는 점에서 유리하지만, 많은 단점도 가지고 있습니다.
- 휴먼 에러 때문에 서비스를 설정할 때에 잘못 설정하기 쉽습니다
- 설정을 통해 인프라 구성(Desired state)을 만들었는지 확인하기가 어렵고 예측되는 상태를 관리하기 어렵습니다
- 환경 설정에 대한 내용을 다른 팀 멤버에 전달하기 어렵습니다
- 인프라 구성을 다른 리전에 똑같이 적용하기가 어렵습니다.
*** 여기서 말하는 수동설정은 인프라 엔지니어가 AWS Console을 사용해서 GUI로 인프라를 구성하는것을 말합니다!
IaC
DevOps의 주요 가치 중 하나는 바로 자동화입니다.
코드형 인프라(Infrastructure as Code), 즉 IaC는 설정을 코드로 작성하여 클라우드 인프라스트럭처의 생성/수정/삭제를 자동화하는 방법입니다.
이는 서버, 데이터베이스, 네트워크, 배포 프로세스, 테스트 등 거의 모든 것을 코드로 관리할 수 있다는 의미입니다.
기존에는 (하드웨어) 서버 준비, 네트워킹과 같은 운영적 측면이 물리적 영역과 대응했습니다.
실제로, 선을 연결하고, 하드웨어를 준비하던 시절이 있었죠...?
그러나 현재와 같은 클라우드 네이티브 환경에서는, 운영적 측면이 모두 코드로 대체될 수 있습니다.
이는 다르게 얘기하자면, IaC는 인프라스트럭처의 설계도가 될 수도 있습니다.
IaC의 장점
IaC는 다음과 같은 특징 및 장점을 가집니다.
- 인프라를 만드는 과정이 자동화되므로, 오류가 훨씬 덜 발생하고 안전합니다.
- IaC는 코드로 관리되기 때문에 쉽게 공유할 수 있고, 버전 관리에도 용이합니다. (깃헙을 이용하면 되겠지요?)
- 코드와 현재 상태를 비교하여, 추후 인프라 상태의 변경에 따르는 위험을 분석하고 검증할 수 있습니다.
- 배포 과정을 소수의 시스템 관리자만 진행하는 것이 아닌, 개발자 스스로가 배포하고 인프라를 통제할 수 있는 환경으로 만들 수 있습니다.
기대하는 인프라 구성을 만든다는 것은?
코드에 '이렇게 AWS 인프라가 구성이 되면 내가 원하던 구성임' 이라고 선언하는 것입니다.
- 테라폼은 HCL 언어(확장자명 tf)를 사용합니다
위 사진처럼 코드만으로 저 구성이 만들어지면 기대하는 인프라가 만들어졌다고 할 수 있겠지요..?
그렇다면 왜 Iac 서비스가 많은데 테라폼을 사용할까요?
테라폼이 사용하는 HCL 언어가 주는 장점에 있습니다.
- HCL은 선언적이지만, 논리적인 기능을 제공합니다 (YAML에서는 지원하지 않는 반복문, 지역변수등을 지원합니다)
- 다양한 클라우드 사업자와 호환이 됩니다. (AWS는 물론이고 AZURE GCP 심지어 NaverCloud도 가능하더라구요...? ㄷㄷ)
- https://registry.terraform.io/browse/providers
여기서 선언적이라는 말은 처음 선언해서 terraform apply를 해서 만든 인프라에 대해서, 코드로 인프라에 조금 더 구성을 추가를 하고 apply를 한다고 해서 원래있던 인프라 a에 대해서 a + a'가 만들어지는게 아니라 a'의 상태만으로 만들어주는것을 말해요!
tf 스테이트파일 기준으로 이미 올라간 인프라를 비교해서 다를경우 스테이트파일 기준으로 만듭니다. (선언형) 쉽게 말하면 이미 올라간 콘솔 상태의 스냅샷이라고도 볼수 있어요
lock파일은 하나의 인프라에 대해서 동시에 고치고 적용이 되어버리면 안되니까 lock을 걸어서 형상관리를 하는 파일이라고 생각하면 될것같아요
테라폼으로 완전히 없는 인프라를 만드는 것도 가능하고
콘솔상에 존재하는 인프라에 더 붙이는것도 가능하다.
유용하고 신기하지 않나요...? ㅎ
댓글