인프라의 코드화: 쓰면 좋습니까?

AWS의 각종 서비스들을 콘솔로 관리하다 보면 정말 여러 페이지를 오가야 할 때가 있다.

 

이게 바로 AWS EC2 콘솔

 

가령 정식 구성으로 서버 하나를 띄운다고 생각해도...

 

1. EC2 인스턴스용 Security Group(SG) 생성
2. 1번과 미리 준비한(!) AMI를 가지고 Launch Template 생성
3. Target Group 생성
4. 2번과 3번을 가지고 Auto Scaling Group(ASG) 생성
5. 3번을 가지고 Load Balancer(LB) 생성. 이때 LB용 SG도 생성됨
6. 5번에서 생성된 SG를 1번에 등록
7. 마지막으로 5번의 도메인을 가지고 Route53 Record 생성!

 

리소스만 6개가 필요하다. 여기서는 각각의 단계가 구체적으로 어떤 역할을 하는지보다 얼마나 복잡한지에 집중하려고 한다.

이런 복잡한 과정을 매번 개발자의 손으로 해야 한다면 어떤 일이 발생할까?

 

반복되는 실수

위의 복잡한 선후관계에 익숙하지 않은 개발자가, "아 서버 띄워야지!" 하면서 AWS 콘솔에 들어가는 상황을 가정해 보면...

대충 생각해도 많은 함정들이 도사리고 있다.

 

1. Launch Template에 Instance Type을 지정하지 않아서 ASG 생성할 때 오류를 맞는다.
   → 그래도 발견하기 쉬운 편.
2. Launch Template을 수정했는데 ASG에 Launch Template 버전을 1로 고정해 두는 바람에 변경사항이 반영되지 않는다.
   → 발견하기 어려운 문제랑 엮이면 삽질할 수도 있다.
3. Target Group 생성을 안 하고 ASG를 생성해서 Load Balancer에 등록할 Target이 안 나온다.
   → 돌아다닐 곳이 많다. Target Group도 생성하고 ASG 옵션도 수정해야 한다.
4. Target Group을 생성했는데 ASG랑 연결을 안 해서 ASG에서 인스턴스를 늘렸는데도 Load Balancer의 요청이 들어오지 않는다.
   → 익숙한 문제가 아니면 삽질할 가능성이 높다.
5. 어떻게 Target Group이랑 LB랑 연결해도 미리 생성해 둔 SG에 LB의 접근을 허용해 두지 않아 요청 시 Timeout이 발생한다.
   → 역시 잘 아는 문제가 아니면 고생할 가능성이 높다.
6. Launch Template에 Security Group을 지정하지 않아서 새로 생성된 인스턴스들이 default SG로 생성된다.
   → 가장 우려되는 실수. 이대로 인터넷에라도 노출되면...? 😈 비트코인 채굴 각

 

 

간단하게 6개의 리소스를 가지고 예를 들었지만, 더 복잡하게 리소스를 생성하고 wiring해야 하는 상황도 발생할 것이다.

AWS에서 제공하는 몇몇 관리형 서비스는 다른 서비스의 이용을 사실상 불가피하게 만드는 경우도 있다.

(CloudWatch로 모니터링하도록 하거나, SQS로 작업 상황을 받는 등)

즉 "이거 하나 만들어야지" 생각하고 작업하기 시작해도 얼마든지 리소스가 불어날 가능성이 있다.

그리고 리소스가 늘어날수록, 실수할 가능성도 높아진다.

 

또 어떤 리소스는 실수를 유발하기 쉽게 만들어져 있다. 특히 IAM Policy는...

특정 리소스의 ARN(고유 식별자)을 복사해서 붙여넣어야 한다. 

깜빡하고 리소스를 먼저 생성해 두지 않으면 붙여넣을 ARN도 없어서 무조건 되돌아가야 하고,

복붙하다 글자 하나 지워서 에러가 발생하면 개발자의 인내심이 폭발할 수도 있다.

 

집에,,, 가고,,, 싶다,,, 안돼,,, 커피,,, 마셔요,,, 우리,,,

 

간단히 말해 실수가 발생하기 무척 쉬운 환경이다.

게다가, 이런 클릭클릭에서 발생하는 실수는 코드를 짤 때의 실수, 즉 Exception이 떨어지는 것과는 성질이 다르다.

Exception은 개발자가 잘 처리하면 그 뒤로는 컴퓨터의 몫이므로 거의 절대 실수하지 않지만,

사람은 실수할 수 있고 같은 실수를 반복한다 그 실수는 경우에 따라 6번처럼 치명적인 결과를 가져오기도 한다.

 

그렇다고 해서 실수하지 말아야 한다는 것은 아니다. (그런 목표는 개발자에게 어울리지 않는다 😛)

다만 한번 실수하면 다시는 같은 실수를 반복하지 않는 환경을 만들어야 한다.

 

만약 연계된 리소스를 코드로 정의해 두고, 빠르게 검증해 보고,

이를 모듈화해서 클릭클릭 없이 원하는 환경에 턱턱 생성할 수 있다면 좋지 않을까.

한번 검증된 방법은 사람의 개입 없이도 실행할 수 있는데, 실수하기 어려운 환경이 되지 않을까.

 

기록되지 않는 작업

여차저차 트러블슈팅을 해서 리소스 6개를 생성했다고 치자.

시간이 많이 지나서, 운영 환경에도 같은 서버를 띄워 달라는 요청을 받았다.

 

그러나 여차저차 해서 만든 건 머릿속에 체계적으로 순서가 잡히지 않는다.

즉 "해봐야 아는 상태"가 되는데, 이 상태에서 복잡하게 리소스를 생성한다고 한들

개발 환경의 구성과 똑같다는 확신은 들지 않는다. 찾기 어려운 문제가 숨어들었을 수도 있고,

실수를 반복하고 있을 수도 있다.

 

기간을 좀 더 늘려서 누군가 내 작업을 이어받아야 하는 상황이 온다면 문제가 커진다.

후임자 입장에서는 리소스를 보고 "아 이건 이거랑 연결되어 있구나"라고 이해할 수 있겠지만,

그렇다 해도 내가 놓친 부분이 있을 수 있다.

저 멀리 어딘가의 어떤 RDS 파라미터 하나를 바꾸면 애플리케이션 동작이 전부 흐트러질 수도 있다.

대대로 전해져 내려오는 AMI 같은 건, Image로 생성되기 전에 쉘에 대고 뭔 짓을 했는지 도통 알 수가 없다.

 

몇 개월 후의 나 혹은 몇 년 후의 후임자에게 내 작업을 넘겨주기 위해서는 정말 괜찮은 기록이 필요하다.

그래야 개발 환경과 운영 환경의 인프라를 동일하게 생성할 수 있고,

파라미터 변경이나 버전 업데이트도 임팩트를 예상하면서 할 수가 있다.

간단히 말해 뒤에 오는 사람이 자신감 있게 작업을 진행할 수가 있다.

 

어느 정도면 괜찮은 기록일지는 사람마다 다르겠지만,

실행할 수 있는 기록이어서 CLI 명령 한 줄로 필요한 인프라를 턱턱 만들 수 있고,

포맷이 간단해서 원하는 부분은 얼마든지 고쳐가면서 작업할 수 있다면,

그리고 git 등 익숙한 방법으로 버전 관리할 수 있다면 꽤 괜찮은 기록 아닐까.

 

번거롭고 귀찮은 일

AWS 콘솔로 이런 작업을 진행하려고 하면 꽤 많은 페이지들을 돌아다녀야 한다.

페이지를 이동하고, 새 탭을 띄우고 하는 이런 작업은 개발자를 피곤하게 만든다.

 

이렇게나 갔다올 곳이 많다.

다행히 이번 작업은 EC2 콘솔 안에서 처리할 수 있었지만, 다른 서비스의 경우에는 고통이 더 심해진다.

만약 EC2 인스턴스가 올라가고 내려오는 것을 모니터링하고 싶으면 CloudWatch 콘솔로 가서 Event Rule을 등록해야 한다.

그걸 SQS 큐로 받고 싶다면 SQS 콘솔로 가야 하고,

무중단 배포라도 하고 싶으면 CodeDeploy 콘솔로 가야 하고,

AWS SDK 쓰려고 IAM Role이라도 생성하고 싶으면 IAM 콘솔로 가야 한다.

 

그리고 AWS는 이런 콘솔들의 UI가 다 다르다.

메뉴부자 아마존

AWS CLI를 사용할 수도 있겠지만, CLI 명령도 어쨌든 순서가 틀리면 오류가 나기 마련이다.

그리고 동적으로 변화하는 값도 있기 때문에 쉘 스크립트로 작성하는 것이 꽤나 번거로운 일이 될 수 있다.

 

만약 리소스 순서를 사람이 아닌 툴이 알아서 결정해, 성공적으로 리소스를 생성해 준다면 어떨까.

그리고 그 모든 게 terraform apply 명령 한 줄로 가능하다면...? 광고같아

 

인프라 자동화를 어떻게 하는가

최근에 Terraform을 본격적으로 배우고 적용하기 시작했는데, 편한 점들이 많다.

코드상에서 필요한 리소스들을 정의하면, 마치 리소스의 특정 속성을 읽는 것처럼 dot notation으로 ARN 같은 것들을 접근할 수 있고,

다른 리소스에서 참조하여 사용할 수 있다.

 

SQS Policy의 일부. 복붙이 아니다 reference이다

 

서로 reference로 이어주면 Terraform이 알아서 리소스 생성 순서를 결정해 주고,

특정 값들만 output으로 정의하면 리소스 생성이 끝났을 때 필요한 값들만 콘솔에 찍어준다.

 

한번 사용하면 충분히 빠져들게 되지만, terraform을 공부하면서 몇 가지 함정이 있다는 것을 느꼈다.

 

1. 코드 읽을 때: 이 값은 어디서 튀어나오는 건지 모르겠다.
2. 코드 수정할 때: cycle이라고 뜨면서 생성이 안 된다.
3. 코드 반영할 때: 내가 변경하지 않은 것도 다 바꾸려고 한다.
4. AWS 특수 함정: 콘솔에서 만든 기억대로 작성했는데 안 된다.

 

다음 글에서는 직접 겪었던 Terraform의 4대 함정에 대해서 다뤄보려고 한다.