인턴 기간 진행했던 일들 + 배운 내용과 생각을 정리한다. 기록을 안 하면 큰 줄기만 기억하고 디테일은 까먹을게 뻔하다.
Object Storage 리소스 추가
처음 진행했던 일이다. 전반적인 테라폼 프로바이더 프로젝트의 구조를 파악하고, Object Storage에 대한 테라폼 프로바이더를 제공하는 것을 목적으로 했다. 기존과 조금 다른 형태의 코드 작성이 필요했었는데, 그 이유는 아래와 같다.
- NCP의 Object Storage의 경우 AWS S3 Compatible API를 사용하고 있어 AWS SDK와의 호환성을 확인해야함.
- VPC 종속의 리소스가 아니어서 기존과 조금 다른 형태로 생성과 삭제를 확인해야함.
특히 가장 시간을 쏟은 부분은 1번이었다. NCP 서비스 자체에서 제공하는 기능인지 확인하고, 그 메서드가 AWS SDK의 어떤 메서드와 연결되어 사용되는지 확인할 필요가 있었다. 일반적으로 이름에 큰 차이가 없어서 큼직한 기능들의 경우는 연결을 확인하는 것이 어렵지 않았지만, 테라폼 프로바이더 제공을 위해 세부적인 조건들까지 확인해야하는 부분에 있어서 신경써야 하는 부분이 많았던 것 같다.
한 예시로 ACL의 경우 AWS SDK에서는 6개의 선택지를 제공하고 있었는데, NCP에서는 이 중 4개의 선택지만 작동했고 (이외에는 없는 옵션이라고 panic을 발생시킴), 그 결과로는 공개 - 공개 안 함 두 가지 선택지만 적용되는 방식이었다. 이렇듯 매번 경우가 달라서 확인에 어려움을 겪는 경우가 있었다.
그 외에도, 버킷에 대해서는 AWS SDK 에서 제공하는 것은 헤더 정보 or 버킷 리스트라는 점이 있어서(단일 버킷만을 가져오지는 못함), 실제 전체 버킷 리스트를 불러서 이 중 원하는 버킷을 찾아야하는 이슈도 있었다. 테라폼 특성 상 시간이 걸리는 것이 크리티컬하지 않았지만, 그래도 충분히 꺼려지는 부분이었다.
전반적으로 처음 테라폼 프로바이더 코드를 짜고, 관련한 내용들을 추가하려고 하다보니 쉽지 않았지만, 전반적인 구조를 파악하는데 있어 좋은 경험이었다.
관련하여, 일전부터 계속 적용하고 싶었던 백엔드(remote state)관련 설정도 적용할 수 있었는데, AWS S3 Compatible API를 사용하는 만큼 실제 S3버킷처럼 remote state를 적용하고 사용이 가능했다.
그러나, DynamoDB와 같이 분산 락을 제공하지는 못하였다. 애초에 이를 위해서는 테라폼 apply 과정의 생명주기에 관여할 수 있어야 했는데, 그러기 위해서는 terragrunt와 같은 서드파티 도구들이 필요한 부분이 있어 추가 조사를 진행하지는 않았다.
Codegen PoC
Naver Cloud 전사적으로 OAS를 기반으로하는 서비스 제공을 고려하고 있는 듯 했다. 따라서 우리도 이를 기반으로 Codegen을 적용할 수 있도록 관련 도구를 만드는 작업을 진행했다.
아직 논의가 많은 부분 진행되지는 않았지만, 미리 PoC를 제공함으로써 논의에서 codegen을 활용한 자동화 가능성을 보여주는 좋은 기회인 듯 하였다.
조금 문제라고 생각되었던 부분이 있다면, 생각보다 리서치 및 적용하는 데 있어서 방향 전환이나 특정 block요소들로 인해 시간이 지체되었다는 점이었다 (개인적인 생각).
근데 기존에 내가 너무 빠르게 움직여야하는 (가령 스타트업이라던가, 데드라인이 정해진 프로젝트 단위의 일들) 곳에서 작업을 해오다보니 이러한 비동기적인 업무에 많이 어색함을 느끼는 것도 물론 한몫 하는 듯 했다.
또한 조직장님의 기대 혹은 방향에 맞추거나 하는 것에 있어 방향을 조정하는 등의 소요가 있었기에 시간 지연을 충분히 고려했어야 할지도 모른다. 어쨌든 기본적인 open api spec, terraform에서 제공하는 codegen 프로젝트의 기본 cli 도구 (hashicorp에서도 불필요한 수작업 자동화를 위한 codegen 프로젝트를 자체적으로 진행하고 있다. 많은 CSP의 케이스를 고려하고자 하다보니 많은 것을 해결해주지는 못한다.)들을 이용해서 자동으로 terraform provider 코드를 생산하고 관리하는 도구를 만들어내는 일을 진행했다.
이에 관련하여 Google 에서 진행중인 GCP Magic Modules라는 형태의 도구가 눈에 띄었는데, 실제 많은 부분을 자동화한 상태 + 개발자의 이슈 처리로 엣지 케이스들 및 에러 처리를 해결하고 있었다. 그 구조가 현재 생각할 수 있는 나름 이상적인 형태에 가까웠고 (실제로 적용되는 케이스 중에서), 그렇게 실 케이스가 있다는 점이 긍정적으로 다가와 이러한 형태를 차용하고자 하였다.
이를 위해 현재는 관련한 도구 (codegen을 직접적으로 수행하는 부분. 전처리 제외.)를 만들고 고도화하는 작업을 진행하고 있다.
남은 3개월동안은 Google 의 Magic Modules를 벤치마킹하여 자동화 파이프라인을 구축하는 일을 진행하지 않을까 싶다.
Testing
현재 NCP Terraform provider에는 주기적으로 테스트를 수행하는 도구가 존재하지 않는다. 각 단위 테스트를 수행할 수 있지만, 각 리소스 별 코드를 만들고 배포하고 난 뒤에는 별 수정 없이 그대로 진행되어 왔었다. 따라서 오랜 시간이 지난 리소스에 대한 테스트는 온전히 돌아가는지 알 수 없었으며, 각 상품(서비스)에 대한 spec이 바뀐 경우 고스란히 테스트 실패로 전해질 수밖에 없었다.
이러한 경우를 방지하고자, 매일 자정마다 전체 regression testing을 수행하고, 테스트 결과를 적재하여 이를 시각화하는 파이프라인의 구축이 필요했다. 이를 위해 고려한 것은 다음과 같다.
- 테스트 결과에서 어떤 정보를 뽑아내어 적재할 것인가?
- 적재한 데이터를 어떻게 시각화할 것인가?
- VPC제한에 대한 테스트 실행 계획을 어떻게 수립하고, 어떻게 최적화된 형태로 테스트를 수행할 것인가?
거창해보이지만, 하나씩 차근히 생각해보면 어렵지 않았다.
테스트 결과의 경우, 몇 번의 리서치를 통해 ctrf라는 포맷을 찾아낼 수 있었다. 더불어, ctrf 기본 포맷에 추가적으로 에러 메세지를 담는 형태로 failed test를 손쉽게 해결할 수 있도록 하였다.
ctrf 포맷 자체가 json형태를 기본으로 하기 때문에, 이에 대한 시각화 도구가 필요했다. 이 때, regression test는 매일 진행되는 만큼 가장 큰 축이 시간이 된다. 따라서 처음에는 InfluxDB + Grafana 를 고려했었으나, 보여줄 정보가 그렇게 방대한 것이 아님 + 각 날짜별 데이터를 확인하고 싶은 것이지 시간에 따른 추이를 확인하고자 하는 것이 아님 을 생각했을 때 오버엔지니어링이라고 판단되었다.
이에, 단순한 json을 보여주는 것이라면 그냥 프론트엔드 간단히 구축하는게 블랙박스도 없애고 좋지 않을까? 라는 생각에 곧바로 대시보드를 제작하였고(vercel v0를 이용해서 코드는 ai가 짜주었다. ai가 사용했던 스택은 요즘 국룰인 스택이어서 더욱 편했다…), 나름 원하는 바가 잘 가시화된 대시보드가 제작된 듯 하였다.
허나, 아직 실패한 테스트의 경우 자원을 남기게 된다는 치명적인 이슈가 존재했다. 자원이 남는 경우 매일 자동화된 테스트를 진행할 수 없이 인력이 필요한 상태가 되기 때문이다. 따라서 최근 자원의 id를 실패한 케이스들과 매칭하여 해당 테스트를 스킵하는 형태로 테스트를 구성하는 작업을 진행했다.
NCP에서는 계정 당 생성 가능한 VPC 개수가 3개로 제한되어 있다. 내부 테스트용 계정에 추가 확장을 받은 상태였지만, 무제한 생성은 불가한 형태이다. 현재 리소스 + 이후 추가될 리소스를 감안한다면 이는 모든 테스트를 병렬로 실행하지 못한다는 이슈를 발생시키는 원인이 되었다. 이에 GitHub Actions에 존재하는 matrix의 include 키워드를 활용하여, 각 병렬 테스트 단위별로 직렬로 실행할 리소스들을 명시해두어 총 7개 정도의 병렬 테스팅이 진행되도록 조치했다. 각 테스트 별로 반드시 1개의 VPC만 사용한다는 보장이 없고 + 테스트 별로 소요되는 시간이 천차만별이었기에 이 부분은 몇 번의 수동 테스트를 거쳐 계획을 수립해두었다.
이외에, 해당 테스팅이 병합되고 적용된 뒤에는 리전 및 망 별 테스팅을 진행할 예정이다. 이는,,,추후에 정리해보도록 하자.