Stargate라는 개발 인프라 구축기

저희 팀의 개발 인프라는 위와 같습니다. 마침 제가 입사할 쯤이 기존에 존재하던 인프라를 새로운 환경으로 이전해야할 시점이었습니다. 덕분에 저는 저희 개발 환경을 처음부터 구축하고, 우리의 서비스를 배포해보고, 그 후 운영하면서 여러 경험들을 할 수 있었습니다.

Terraform으로 처음 접해 본 IaC

친구: IaC가 뭔 지 알아? 써봤어?

본인: 뭐 인프라를 코드로 관리한다는 건데, 나도 몰라 ㅋㅋ

본인: 아마 너무 고급 기술이라 대학 졸업할 때 까진 못 써볼 듯?

위의 대화는 제가 입사하기 약 일주일 전에 나눴던 대화인데, 입사 후에는 어느 덧 IaC와 꽤나 친근해진 것 같아 유머삼아 유머로 가져와봤습니다. 메가존 클라우드의 클라우드 원팀에서 일하기 전까지는 IaC는 저와는 거리가 먼 토픽이었고, Kubernetes 또한 minikube로 몇 가지 Object들을 배포해본 것이 다였습니다. 하지만, 저는 저희 팀에서 근무하게 되면서 terraform을 통해 위의 차트에 그려진 모든 인프라를 구축하고 파이프라인을 구축하게 됩니다.

terraform을 사용하며 느꼈던 점은 ‘장점만 존재하는 기술은 드물 것이다’라는 점입니다. 분명 대부분은 장점이 있으면 그에 따른 단점이 존재할 것이고, 개인적으로는 테라폼도 장단점이 공존하고있다는 느낌을 받았습니다. 저의 주관적인 느낌에 따른 가장 큰 장점과 단점을 몇 개만 설명해보겠습니다.

Terraform 단점

우선 단점부터. “사소한 인프라 변경도 코드에 반영하려면 문서를 찾아봐야하고, plan 내용을 검토해야한다”.

저희는 평소에는 EKS의 로그를 켜놓지 않았습니다. 그런데 언젠가 EKS 로그를 CloudWatch를 이용해 분석해야한 적이 있는데, AWS 콘솔에서 바로 눈 앞에 로그 설정 칸이 있었음에도 EKS 로그를 설정하는 terraform Docs를 찾아본 뒤 plan을 분석한 뒤 apply 했어야합니다. 물론 아마도 로그 설정 쯤이야 잠깐 콘솔로 설정했다가 콘솔로 해제하면 그 한 번쯤은 문제가 없었겠지만, 그런 식으로 이번 한 번만, 이것쯤이야 하면서 코드가 아닌 매뉴얼로 직접 인프라 형상을 제어하는 경험이 쌓이게되면 형상이 깨져서 다시 형상을 맞추기 힘들수도 있고, 애초에 그런 수작업이 많이 들어가야하는 경우가 있다면 오히려 IaC를 이용할 필요가 없다고 생각했기 때문에 최대한 인프라는 terraform code로만 작업한다는 저의 원칙을 지키기 위함이었습니다.

즉 자동화보다는 수작업이 편한 경우는 굳이 IaC라는 컨셉을 이용하는 것이 더 불편한 경우도 존재할 수 있을 것 같다는 생각이 들었습니다.

Terraform 장점

“내가 사용하고 있는 인프라 전체를 한 눈에 보기 쉽다”

물론 클라우드 서비스 하나에 대한 정보를 보고싶으면, 웹 콘솔에 들어가서 확인하는 것이 편하겠지만, 내가 이용하고 있는 AWS내의 모든 클라우드 서비스에 대한 정보나 설정을 보기에는 terraform 코드나 output, state 등이 더 알아보기 편할 수 있습니다.

“혹시 장애가 생긴 경우 그 원인을 추적하기 쉽다.”

수작업으로 클라우드 인프라를 관리하는 경우에 자신이 모르는 어떤 변동사항이 있고, 그 변동사항이 어떤 버그를 야기하고 있다면, 수작업으로 작업을 진행하는 경우에는 그 변동사항을 알아채고 트러블슈팅하기 쉽지 않을 것입니다.

하지만 테라폼 코드를 통해 인프라를 관리하면 변동사항을 테라폼이 알아서 잡아주고, 혹은 코드에 대한 커밋 내역 등을 통해 변동 사항을 체크해 볼 수도 있을 것입니다. 따라서 그 변동사항에 맞는 트러블 슈팅을 하기 쉬울 것 입니다.

개발 관련 다양한 서비스 배포

테라폼으로 인프라를 구축한 뒤에는 위의 차트에서 오른쪽에 작게 Stargate 라는 곳에 적힌 서비스들을 배포했습니다. 이 부분에 대해서는 너무나도 하고싶은 얘기가 많지만, 지루해질 수 있으니 그 중 기억에 많이 남거나 애착이 가는 서비스들에 대한 리뷰를 간단히 적어보겠습니다.

• Nginx Ingress Controller
  • 로컬에서 minikube로만 개발하다가 처음으로 Ingress를 사용하게 되었습니다. helm을 이용한 게 아니라, helm으로 만들어진 manifest를 수동으로 하나하나 설정해서 설치하고 관리했습니다. 설정이 꽤나 복잡했었기에 설정을 많이 변경하는 경우 helm으로 설치하는 건 어떨까싶습니다… 일하면서 Nginx로 L7 로드밸런싱 뿐만 아니라 L4 로드밸런싱도 몇 번 다룰 일이 있었고, 여러 Nginx Ingress Controller을 배포할 일도 있었고, gRPC 통신을 위한 설정을 해야할 일도 있었는데, 점점 수작업으로 하다보니 설정이 너무 복잡해져서 헷갈렸던 적이 있습니다. 뭔가 단점만 적은 것 같은데, K8s의 Ingress Controller로서 성능적인 부분은 제가 잘 모르겠지만, 크게 불편함 없이 잘 사용했습니다.
• ALB Ingress Controller
  • 서비스에 대해 직접 L7 로드밸런싱을 수행할 경우 이용합니다.
  • 헷갈렸던 점은 보통은 Nginx Ingress Controller는 사실 Ingress는 설정이고, 컨트롤러가 실제로 로드밸런싱을 수행하는데, ALB는 ALB Ingress Controller가 Ingress를 통해 ALB를 만들고 실제 로드밸런싱은 ALB Ingress Controller가 아니라 ALB가 한다는 점이었습니다.
  • 설정에 따라 다르지만 기본적으로는 노출시키고자 하는 서비스는 NodePort급 이상으로 서비스가 열려있어야하는데, 실수로 ClusterIP로 노출시켜 ALB가 서비스를 제대로 찾지 못한 적이 종종 있었습니다. 주의..!
• Cert Manager
  • 자동으로 cert를 발급해주고 갱신해주는 서비스입니다.
  • Let’s Encrypt를 이용했고 무료입니다.
  • 정말 정말 편리했습니다!
  • DNS, HTTP Challenge, TLS에 대해 많이 배울 수 있었습니다.
  • TLS 통신 과정은 공부해도해도 정확한 순서는 까먹게 돼서… 다시 공부해봐야겠습니다.
• Jenkins
  • 편한데, 관리하기 귀찮을 수 있을 것 같습니다.
  • 결정적으로 코드로 관리할 수도 없는데, UI도 그렇게 직관적인지는 잘 모르겠습니다.
• Spinnaker
  • 정말 편리합니다. Jenkins test 결과를 CD에 이용할 수도 있고, 편리하고 다양한 문법, 파이프라인 종류, 직관적인 UI/UX. 사실 Argo를 도입하고 싶었지만, Argo는 약간 가벼운 쿠버 환경에 대한 배포용 같은 느낌, IaC는 적극 도입되었으나 현실에 도입은 쉽지 않은 기술적 이상향 같은 느낌이 컸고, 현실적으로는 좀 더 안정적인 Spinnaker를 유지하게 됐습니다.
  • 좀 느리다고 생각했는데, 이 글을 쓰면서 생각해보니 개발에서는 K8s Deployment의 Grace Period 때문인 것 같아 그걸 좀 줄여볼 껄 싶습니다. 즉 다시 생각해보니 별로 느리지 않은 듯합니다.
  • 배포 자체는 안정적이고 좋은데, 설정할 때 버그가 종종 있습니다. 버그인지 제 실수인지는 모르겠지만 Pipeline stage 에서 Bake라는 모드가 “우와 신박하다!” 라고 생각했지만, 설정이 제대로 되지 않거나, OAuth login 실패에 대한 처리, Artifact 경로 설정이 너무 번거로운 점 등의 단점이 있었습니다.
• Keycloak
  • 우리의 개발툴들에 대한 인증을 사내 계정으로 연동시켜주는 Single Sign On 기능을 지원했습니다.
  • 새로운 팀원은 각 서비스에 별도의 가입 과정 없이, 앱 레벨에서 따로 권한 부여가 필요한 것이 아니라면 사내 계정으로 바로 이용이 가능했습니다.
  • 문서가 제대로 정리된 게 다소 부족한 느낌이었어서 세밀한 설정이나 정확한 작동원리를 파악하기는 쉽지 않았던 점이 조금 아쉽습니다.

인프라 구축에 대한 정리

내용이 너무 길어지면 읽기 힘들 것 같아 최대한 느낀 점 위주로 간단히 정리해보려고 노력해보았습니다. 인턴으로 일을 하기 전에 가벼운 마음 속 목표가 하나 있었습니다.

‘어떤 걸 어느정도 사용해보면 그것에 대한 주관적인 평가를 내릴 수 있는 사람이 되고싶다.’

누군가 “도커가 설치하기 정말 쉽더라구요.”, “minikube 써보니 정말 편리하더라구요.”, “Jenkins 보다는 travis가 편리더라구요.(혹은 그 반대)” 이런 얘기가 나와도 과거에는 공감할 수도, 제 주관적인 평가를 내릴 수도 없었습니다. 저의 경험으로 구성된 모집단이 없었기 때문입니다. 하지만 저희 클라우드 원 팀에서 근무하면서 어떻게 보면 깊이는 다소 얕았을 지 몰라도 정말 다양한 서비스를 접하고 다채로운 경험을 할 수 있었던 것 같습니다! 덕분에 이제는 어떤 서비스를 접하든, 새로운 언어를 접하는 저만의 느낌을 가질 수 있고, 의견을 말할 수 있을 것 같습니다!