e34.fm 은 메르카리의 SRE, 플랫폼 조직을 이끌고 있는 @deeeet 님과 @rrreeeyyy. 님이 진행하는 인프라/SRE 등을 주제로 하는 일본 팟캐스트에요.

최근에는 페이스북을 잘 하진 않지만, 가끔 들어가보면 이전에 제가 올렸던 글들을 추억해?주는 기능이 있어, 예전 생각들을 돌아볼 수 있어요.

그 중에서 이런 것도 적었었구나 발견한게 있는데, 산책하면서 e34.fm 을 듣고 음성메모 했다가 집에 돌아와서 정리했던 기록이에요.

최근에 회사에서는 기존에 테라폼으로 하던 작업들을 사내 IDP(Internal Developer Platform)에 기능으로 녹여 개발자가 직접 필요한 리소스를 (생성/수정하는) 셀프서비스 할 수 있도록 하고 있는데, 2년 전에 비해서 생각이 많이 바꼈구나 하고... 알게됐어요.

2년 전, 새로운 기술에 관심을 가지고 팟캐스트를 구성하던 두 분은 어떤 생각을 하고 계셨는지, 그리고 지금 업계는 어떻게 변화하고 있는지 한번 살펴보고 생각해보면 어떨까요...

https://e34.fm/3/ 들으면서 기억에 남았던 부분 메모.

아직 초반 부분만 들었는데도 재밌어서 산책나가서 엄청 음성 메모 많이 하게 됨. (11개의 녹음을 정리함)

다른 것 보다 최근 팀이나 스터디 멤버들하고, Terraform이나 Reconcile loop를 사용한 인프라 관리에 대한 이야기를 많이 했는데 딱 그 이야기가 나와서 재밌게 들었음.

HashiConf Europe 2021 내용으로 시작.

* 2011년 cloudformation이 나왔던 해에 미쉘이 텀블러 블로그에 테라폼에 대한 초기 아이디어를 정리하고 코딩을 시작 3년 뒤 2014년에 테라폼 0.0.1 릴리즈

* 다들 테라폼 1.0 은 나오지 않을 것이다. 계~~속 0.x 버전을 유지할 것이다 했지만 발표. 흐흐흐

* `terraform test` 커맨드로 모두가 지지고 복던 테스트 문제가 해결되면 좋겠다고 기대.

* terraform-cdk 가 나와서 절반은 이제 프로그래머블하게 되는구나! 하고 기대되는 반면, Chef의 안좋았던 기억들이 떠오름. (너무 복잡해져서 카오스가 되는 문제.) 실제로 좀 만져보니 젤 처음 작성한 사람의 스타일이 표준이 되서 그 사람의 리뷰가 필요한 구조가 되는 것 같다.

* Terraform 0.0.1 ~ 1.0 동안의 인프라의 가장 큰 변화는 쿠버네티스의 등장이라고 생각 함. 그 중에서도 reconcile loop 의 등장이 가장 큰 변화라고 생각

* reconciliation loop를 간략히 설명하면 원하는 상태를 스펙으로 정의하면 컨트롤러가 지금 현재 대상의 상태를 체크하고, desired state와 다를 경우 지속적으로 변경해 줌. 이 동작이 영원히 실행 됨.

* Terraform 과의 차이점은 테라폼은 State관리가 필요. K8s는 reconcile loop가 지속적으로 상태를 변경하지만, Terraform은 명령을 실행할 때만 변경 됨.

* Terraform 사용할 때, 사용자가 콘솔에서 손으로 리소스를 수정한 경우, 싱크가 깨지는 고통이 있음. K8s는 다른 접근으로 reconcile loop를 적용했고, 처음에는 Pod, Deployment등 K8s리소스 관리를 위해 사용했지만 이를 응용해서 클라우드 리소스에도 이 개념을 적용함

* GCP의 Config Connector, AWS Controllers for Kubernetes, Crossplane등이 이런 접근방식.

* 당장 reconcile loop등의 접근방식이 좋다고 테라폼을 대체할 수 있는 건 아니지만, 그리고 State사용방식이 1.0에도 유지되는 걸 보면 바로 바뀔 것 같진 않지만 Terraform에서 지금의 불편함을 어떤 새로운 방법으로 개선할지 기대 됨.

* 지금 Terraform이 제일 Best라고 말할 수는 없는 상황이기 때문에, 앞으로 Terraform 세력 vs Reconcile Loop 세력이 겨뤄서 어떤 좋은 결과를 도출할지 지켜봐야할 것 같다.

* CrossPlane이 이 중간정도의 위치에서 뭔가 해보려고 하는 것 같은데 지켜봐야할 것 같다. @deeeet 상은 IAM 에 Reconcile Loop의 활용을 적극적으로 적용해보고자 하는 의지가 있다.

* IAM 은 항상 기대 상태로 유지되기를, 강한 모티베이션으로 원하기 때문에 적극적 검토.

* Vagrant가 3.0 으로 버전업하면서 기존 Ruby에서 Go로 변경되려 함.

그런데 요즘 Vagrant 좀 쓰고 있니? 흐흐

이것보다 주목할 점은 기존 Client 구조에서 도커처럼 Server-Client 구조로 변경하려고 함.

* 이게 왜 의미가 있냐면, 앞으로 GitHub Codespaces 처럼 공유된 클라우드 환경의 프로비저닝을 원격에서 제어하는 needs가 많이 발생하게 될 것 같음. 흐름을 잘 파악하고 있다고 생각.

* M1 맥북 넘어오면서 서버랑 CPU 가 달라 발생하는 이슈나, 제대로 작동하지 않는 툴 때문에 리모트 서버를 두는 경우가 있는데, Vagrant가 그런 문제를 해결해 주지 않을까? 아이패드 등으로 (이미 프로비저닝 되어있는) 공유 개발환경에 접속한다던가...

나도 요즘 stateless한 AWS 리소스는 Terraform 이 아닌 Reconcile Loop를 활용한 방안으로 관리하는 것이 더 좋지 않은가? 하고 생각이 바뀌고 있음.

e34 팟캐스트 진짜 짱임. 영어 팟캐스트도 이만큼 알아들을 수 있으면 정말 좋겠지만, 쉽지 않으니 나에겐 인프라 보석과 같은 팟캐스트.