테라폼 맨땅에서 부터 적용하기 1

AWS에서 리소스를 제어할때 기본적으로 AWS Console을 사용한다.

하지만 리소스가 점점 늘어날 수록 손으로 일일이 대응하기엔 시간도 많이 걸리고 휴먼에러도 많이 발생한다.

 

인프라는 다른 개발자들의 컨텐츠 작업보다는 훨씬 리스크가 큰 작업이다.

예를 들자면, 인프라는 건물이고 개발자는 인프라가 생성한 방에서 일하는 근로자인 것이다.

개발자가 실수를 하면 방에서 불이 나거나, 물 난리가 나는 정도의 레벨이라면 인프라의 실수는 기둥하나를 날리는 것이라던지, 중간 층을 통채로 날리던지 비교 여부를 떠나 개발자 대비 리스크가 훨씬 큰 작업이라는 것이다.

 

이번 적용기 글에선 사용법이나 이런 것들은 적지 않고 느낀 점만 간단히 적을 생각이다.

 

이미 많은 분들이 잘 사용할 수 있는 방법을 적어놨기 때문이고

사실상 best practice를 이용한 방법이 아닌 맨땅에서 시작했기 때문에 추천하기 어려운 구현 방법이다.

(사실상 맨땅부터 해서 배우는 중임)

 

사실 테라폼이라는게 이제 막 나온 것이 아니라 꽤 오래 되었고, 비슷한 솔루션도 많지만 내가 아는 중엔 제일 유명한 서비스라서

테라폼에서 적용을 한번 해보자! 라는 마음으로 시작하게 되었다.

 

Devops로서 자동화를 어느 정도 진행하면서도 실수가 없이 해야 하는 입장에선 최대한 리소스에 대한 가독성을 높이고 실수를 줄일 수 있는 방법을 계속 연구해야 한다.

하지만 늘 중소 스타트업에서 Devops는 없으면 없었지 있으면 1명인 곳이 거의 대부분이라서 나 대신 작업해 줄 사람이라곤 찾을 수 없다.

 

Chapter 1. 맨 땅에서 시작

처음부터 모듈화를 하면서 어떻게 처리할지 고민하지 않고, “일단 해보자!” 라는 마음으로 시작했다.

그러다 보니 이런 괴랄한 구조의 리소스가 생성되었다.

한땀 한땀 이 위에 있는 리소스에 대해서 모조리 찾아 나가면서 추가해 나가기 시작했다.

 

1. chatGPT로 샘플 코드 작성 후 resource 추가

2. terraform import

3. terraform plan

4. update 나온 사항 모두 일치화

5. terraform plan

6. no change 나올때까지 plan

7. 이해 될때까지 terraform apply 금지

 

이러다 보니 시간이 정말 많이 걸린 것 같다.

 

브랜치는 Dev → prod → stage 순서대로 import를 해가며 resource를 맞춰나가며 작업을 진행했다.

 

그냥 딱 내용만 봐선

 

"왜 Dev → stage → prod가 아니었나????"

 

라고 생각할 분들이 꽤 있을 것이다.

 

이유는 stage가 없었기 때문이다.

사실 이것을 도입한 가장 큰 이유는 어차피 Stage를 만들기는 해야 하니 쉽게 만들어보자! 라는 의미가 깔려 있었다.

 

입사 후 사실상 수동으로 CI/CD를 하던 구조를 ec2 + alb → ecs fargate + alb 구조로 github action CI/CD를 적용한 작업이 있다.

급한대로 CI/CD까진 구현했지만 결국 이 리소스를 그대로 stage까지 구현해야 하는 입장에선 당연히 큰 작업이므로

한방에 할 수 있는 작업으론 IaC가 최고라는 생각했다. (물론 한방에 망할수도 있다)

 

저 위에 있는 prod 설정을 모두 카피하여 stage로 붙이고 resource_name을 prod → stg로 변경 한 후 재배포 하니 정말 배포가 되었다.

일부 리소스는 문제가 있었지만 초회 시도시 전체 리소스 대비 80% 이상 정상 동작함을 확인하였으며

일부 리소스가 꼬인 부분만 수정해서 처리했다.

 

1차 작업이 완료된 시점에서는 모듈화도 되어 있지 않고, 파일 단위에 브랜치_서비스 패턴으로 붙은 다소 답답한 분위기 였다.

리소스를 한땀 한땀 보아가며, 추가하는데 꼬박 1주일은 쓴거 같다.

 

중간중간 terraform plan을 하며 계속 검증해 나가고 하다보니 더욱 오래 걸린 것 같다.

 

가장 큰 문제는 내가 prod 측을 수정하는데 누군가 AWS Console 등을 이용해서 dev, stage 환경을 수정하고 있다면 terraform plan에서 자꾸 걸린다는 것이었다.

 

그나마 다행인 점이 있다면, 나 이외에는 AWS Console을 이용해 리소스를 생성하는 사람이 거의 없었다는 것이다.

만일 누가 건드렸으면 더 큰 일이 벌어졌을 것 같다.

 

Github Action CI/CD가 걸려 있었기에 AWS Console이외에 바뀔만한 것은 ecs task definition 뿐이었고, 리소스가 삭제될 위험성을 감안하여 database등 실수로 삭제되면 대 재앙이 발생할 케이스의 작업들은 제외하였다.

 

----------------------------------------------------------------------------------------------------------------------

 

Chapter 1까지의 장점

• IaC로 인한 인프라 구조 가독성 증가
• 일괄 적용으로 인한 휴먼 에러 감소
• 배포시의 시간 단축

Chapter 1까지의 단점

• 순서가 중요한 변경 적용시 수동으로 해야 하는 포인트가 있음 (acm 변경 후 alb 연동 작업 등)
• 브랜치 단위로 작업을 적용하고 싶은데 다른 브랜치에서 작업이 바뀌고 있는 경우엔 어쩔 수 없이 될때까지 기다리거나 의도한대로 조정해줘야 한다.