Iac 툴인 pulumi의 stack 차이에 대해 정리하기
pulumi는 클라우드 3사 (AWS, Azure, GCP) 및 쿠버네티스 서버에서 코드를 사용해 배포를 원활하게 배포하는 플랫폼이다.
pulumi에 대한 기본적인 설명은 이전에 작성한 이 글에서 확인할 수 있으나, 조금 개략적인 설명을 하자면, 파이썬/고/타입스크립트 등을 사용하여 클라우드나 쿠버네티스에 띄워져 있는 애플리케이션을 서버에 올리거나 내릴 수 있다.
팀에서 PoC를 할 땐, Terraform과 많이 비교를 하면서 찾아봤었는데 terraform의 경우 자체적으로 만들어야하는 스크립트 파일이 있어서 해당 파일을 사용하여 배포 작업을 수행하는데, 이 부분에 대해 learning 커브가 있을 것을 염려하여, pulumi를 사용한 것도 있다.
실제로 사용해보니 pulumi로 배포하는 것은 무척 간단하고, 빠르며, 관리하기가 편하다는 장점 때문에 팀에서 정기 서버 업데이트를 할 때마다 pulumi를 사용하여 진행하고 있다.
그런데 이 pulumi에서 배포하는 방식을 관리하는 것에 2가지 방법이 있다는 것을 알게 되었다.
pulumi에는 배포를 하기 위한 관리 방법으로 stack이라는 단위를 사용한다.
이 stack은 pulumi를 처음 설치하면 pulumi up으로 코드 작업한 애플리케이션을 띄울 때 배포할 작업을 위해 stack을 생성하거나 기존 스택 중 값을 선택하는 것을 확인할 수 있다.
그런데 이 스택을 managing 하는 것에 pulumi 공식문서에서는 monolithic과 micro한 방식을 선택할 수 있게 안내하고 있다.
monolithic 배포는 말 그대로 단일 구조로 관리하는 형태로, pulumi를 통해 배포될 애플리케이션을 하나의 stack에서 모두 관리하는 형태다.
stack은 애플리케이션의 배포 주기나 목적에 따라 여러개로 분리해서 사용하는 것이 가능한데 (여러 개로 분리하는 것이 마이크로 스택 사용의 기초다) monolithic하게 가겠다는 것은 하나의 스택에 관리할 모든 애플리케이션을 모아 배포하는 것이다.
현재 팀에서도 선택한 방식이기도 하고, 한 번에 모아 배포하기 때문에 정기 배포 시점마다 관리하는 것이 무척 편한 방식이기도 하다.
다만, 한 번에 다수의 애플리케이션을 띄우다보니, 애플리케이션을 배포하는데 많은 시간이 걸린다는 단점이 있다.
반대로 pulumi의 micro stack 배포는 위에 표기된 pulumi stack ls 의 결과 값을 사용한다 보면 이해가 쉬운데, 애플리케이션 폴더마다 따로 따로 pulumi stack을 분리하여 잦은 배포가 예상 되거나 (특히 알파, 베타 테스트 등으로 버그가 자주 발생할 것이라 예측 될 때) 업데이트 사항이 빠르게 반영이 되어야하는 상황 등에 사용하기 무척 용이하다.
무엇보다 특정 애플리케이션에서 서비스 장애가 발생했을 경우를 가정해보면, monolithic한 배포 방식은 특정 애플리케이션에서 배포하다 버그가 발생하면 배포 자체가 멈추는데, micro stack은 소수의 애플리케이션만 관리하기 때문에 이런 문제로부터 독립적이다. (즉, 영향을 받지 않는다)
또한 monolithic한 배포 방법보다 배포 속도도 빠르다. 때문에 이러한 특성을 반영해서 앞전까지는 배포할 것이 몇 개 없었던 팀 상황에 비해 3개월 만에 비즈니스 상황이 많이 변화하면서 관리할 것이 많아졌고, 최근에 micro stack으로 우리는 리팩토링을 진행하고 있다.
아직 구체적으로 pulumi 배포 방식이 결정된 것은 아니지만 (PoC를 이것 저것 해보면서 확장성과 관리적 측면을 고려한 방식을 포함시키고자 하고 있다) 기본적으로 정기 업데이트에만 관리가 필요한 core 애플리케이션은 monolithic하게 포함시키고, 그 외 독립적으로 실행되는 애플리케이션들의 경우에는 micro하게 배포하는 것을 감안하고 있다.
예를 들면, 쿠버네티스 연관 애플리케이션의 경우 애플리케이션이 띄워지는 플랫폼 코드에 해당하기 때문에 core 애플리케이션에 해당하며, 이 쿠버네티스에 올려지는 코드들이 micro 애플리케이션에 해당한다.
모든 코드를 monolithic or micro하게끔 단일 선택을 하면 무척 좋겠지만, 비즈니스 상황이라는 것은 늘 변하기 마련이고, 이러한 상황을 어느 정도 인지하여 코드를 작성하는 것이 필요로 한다.
클린코드나 소프트웨어 아키텍쳐가 시간이 지나도 기본적인 것으로 받아들여지는 것은 이러한 이유 때문이라 생각하며, 변화에 유동적으로 대처할 수 있어야하기 때문에 리눅스만큼이나 바이블처럼 받아들여지는 것이 아닐까 싶다.
최근에는 개발 업무보다 IDC 또는 클라우드 3사 (GCP, Azure, AWS) 쪽을 서칭하면서 회사 서버를 scale-out할 방법들을 팀에서 찾아다니고 있다.
하드웨어와 관련한 일이기 때문에 무척 생소해서 업체들에게 연락을 많이 돌리면서 찾아보는 중인데, 최근에 가닥을 잡아 IDC 쪽으로 입주하는 것을 생각하고 있다.
(이 부분에 대해서는 무엇을 우선 요소로 고려하고 입주하는지 추후에 정리할 예정이다)
9월부터 클라우드 업체와 비교하면서 고려할 것이 워낙 많다보니 시간이 좀 걸렸고, 외부 업체와 미팅이 종종 있었는데, 개발 인프라라는 것이 워낙 많은 것들을 고려해야하기 때문에 (소프트 & 하드웨어, 성능, 고가용성, 안정성, 확장성, 비용…) 조사하고 정리하고의 반복이었는데, 이제 거의 마무리가 된 것 같다.
바로 어제 카카오가 입주한 IDC에서 화재로 여태까지 서비스에 문제가 많은데, 우리가 입주 전에 카카오에서 간접적으로 언질해준 것 같은 느낌이 든다.
(어차피 카카오에 뛰어난 엔지니어들이 많을테니, 카카오의 비즈니스에는 큰 걱정이 없다)
개발 업무에서 하드웨어도 충분히 고려해야할 요소라는 것은 항상 인지하고 있었는데, 최근 업무들이 이러한 사항들의 학습을 요구하고 있다.
개발 업무에 정답은 없지만, 해답은 있다. 비즈니스의 현재와 미래 상황을 적절히 고려하여 그 때 그 때 최선의 답을 선택해 적용하자.
Ryan
