헬름 차트를 관리하는 가장 좋은 방법은 무엇인가?

안녕하세요, 오늘은 Project A팀의 개발자이자 기고자, 멀린 카터 님이 쓰신  "What's the best way to manage Helm charts?"라는 글을 번역해 보았습니다. 헬름에 대해서 좀 더 알고 싶어 실용적인 글을 찾아보던 중에 이 글을 읽고 번역하게 됐습니다.

 

혹여 모르시는 분들께 간단히 말씀드리면, Yaml 파일 등과 같은 리소스들을 묶어서 차트로 관리를 하게 되는데 이 리소스 패키지를 공유하고, 관리할 수 있는 툴이 Helm입니다.

물론, 이 글은 멀린 카터님께 허락을 구하고 번역하였습니다.

해당 내용은 실제 업무에서 겪었던 내용도 다루고 있어 실무 담당하시는 분들께도 도움이 될 것 같습니다.
번역을 매끄럽게 하기 위해서 직역보다는 의역도 포함 하였습니다. 오역이나 내용에 대한 피드백은 언제나 감사합니다! 😁

 

원본 링크 :

https://insights.project-a.com/whats-the-best-way-to-manage-helm-charts-1cbf2614ec40

 

What’s the best way to manage Helm charts?

 

 

 

백그라운드 이미지 출처  -  언스플래쉬의 조셉 배리 엔 토스

 

 

좋든 싫든, 헬름은 이제 어디서든 마주할 수 있는 쿠버네티스 애플리케이션 관리 도구입니다. 대단하면서도 압도적인 다른 여러 가지 방식으로도 사용할 수 있습니다. 저희는 이 같은 질문이 끊임없이 지속됨을 알게 되었습니다.

 

1)    어디에 헬름 차트를 두어야 하나?

앱 파일과 보관하는지 아님 차트 레파지토리에 저장하는지?

 

2)    헬름 차트를 어떻게 나눌 것인가?

 하나의 공유 차트를 사용하는지 아니면 각각의 서비스에 차트를 유지하는지?

 

다음과 같은 내용의 질문들은 스타트업들을 대상으로 구축했던 저희의 경험과 포트폴리오를 기반으로 기술할 예정이고, 또한 더 큰 규모의 기업 관점에서도 기술할 예정입니다.

 

여기에 강조할 여러 옵션이 있습니다:

 

1.    차트 레파지토리를 사용하여 하나의 큰 차트를 저장하기

2.    차트 레파지토리를 사용하여 여러 서비스별 차트를 저장하기

3.    서비스와 동일한 레파지토리에 서비스별 차트를 저장하기

(스포일러 경고 : 저희는 이 방법을 선호합니다)

 

그리고 나서 이러한 옵션들을 적용하기로 했을 때 고려해야 할 의존성 차이와 팀 구성에 관한 요소들도 다룰 것입니다.

 

옵션 1: 차트 레파지토리에 하나의 큰 공유 차트 유지하기

 

저희 프로젝트 중 한 곳에서, 여러 서비스를 배포하기 위해 하나의 큰 차트에서부터 착수했던 적이 있습니다. 차트는 ChartMuseum에 저장되었고, 배포 인프라에 책임자에 의해서 유지되고 있습니다.

비슷한 구성의 환경에서 서비스가 구성되어 있다면, 공유 차트를 사용하여 여러 번거로움을 줄일 수 있습니다.

조시 돌리츠키(Josh Dolitsky)는 KubeCon 2019에서 이런 시나리오를 들어 말했습니다 :

 

"저는 최근에 프로젝트에 착수하게 되었고, 9개의 마이크로서비스가 구동 중이었습니다. 두세 개의 프로젝트를 작업하는 중, 저는 이 HTTP 리스닝 서비스가 꽤 동일하게 구성되어 있다는 것을 알게 되었습니다. 그래서 저는 각각의 서비스에서 동일하게 동작하는 하나의 헬름 차트를 만들고 그 차트를 사용해서 각기 다른 환경에서 동작하는 9개의 다른 서비스들을 배포하게끔 하였습니다. – 단지 서비스별로 새로운 도커 태그를 세팅했을 뿐입니다."

 

이 케이스에서는 ChartMuseum와 같은 차트 레파지토리에 헬름 차트를 저장하는 것이 이치에 맞습니다. 이러한 서비스별 레파지토리에 값만 넣어두면 됩니다.

옵션 2: 차트 레파지토리에 여러 서비스별 차트 유지하기

 

서비스별 차트는 하나의 서비스를 변경할 때 다른 서비스의 어떤 것이 깨질까 하는 염려 없이도 변경할 수 있다는 등의 이점이 있습니다. 하지만 중복된 업무를 야기할 수도 있습니다. 만약 공통 구성을 업데이트해야 한다면, 각 차트에서 동일한 내용을 변경해야 할 것입니다.

하나의 차트 레파지토리에서 계속 서비스별 차트를 보관할지 아닐지는 또 다른 질문입니다. 어쨌든 간에 만약 차트가 서비스별이라면, 차트를 같이 저장하는 것보다 더 강력한 아키텍처적인 논점은 없을 것입니다. 하지만 모든 차트를 관리하는 전담 팀원이나 팀을 두고 있다면 더 쉬울 수도 있습니다.

 

실례로, 15개의 다른 마이크로서비스를 중앙 차트 레파지토리를 통해서 차트를 유지하는 데브옵스 엔지니어와 같이 일한 적이 있었습니다. 개발자들은 차트 업데이트를 어떻게 해야 하는지 알고, 종종 그렇게 작업했습니다. 하지만 리소스 관련 세팅 작업에서 파드 중단(pod disruption budgets)과 같은 조작을 선호했습니다.

 

옵션 3: 서비스와 동일한 레파지토리에서 서비스별 차트 유지하기

 

서비스별 차트는 서비스마다 다른 큰 차이점이 있다고 할 때, 마이크로서비스 기반 애플리케이션을 위해서 좋은 선택입니다.

이 패턴은 서비스 코드와 같은 동일 레파지토리 내에서 각 차트를 보관할 때 더 좋습니다.

 

만약에 서비스 레파지토리 내에서 헬름 차트를 보관한다고 한다면, 다른 프로젝트로부터 독립적인 서비스의 지속적인 배포가 더 쉬울 수 있습니다. 그리고 애플리케이션의 로직 변화와 동시에 차트 업데이트를 커밋할 수 있습니다. (새로운 변수를 추가하는 작업 등)

-       변경 사항 중 깨진 부분에 대해 쉽게 인지하고 되돌리는 작업을 쉽게 할 수 있습니다.

 

하지만 이같은 이점들은 얼마나 많은 마이크로서비스를 유지하고 있느냐에 따라 달려있는 내용입니다. 만약에 앞서 말씀드린 바와 같이 두 자릿수의 서비스를 가지고 있을 때 (앞서 기술한 시나리오의 내용과 비슷하게) 이 옵션은 도움보다는 장애 요인이 될 것입니다.

특별히 조시 돌리츠키의 예제와 같이 매우 동일한 서비스들을 다룰 때 더욱더 그렇습니다.

 

옵션을 결정하면서 어떤 것을 염두에 둘 것인가?

주요하게 생각해야 할 옵션에는 일반적으로 두 가지 측면이 있습니다 :

 

종속성과 재생산성 :

각 서비스의 종속성이 얼마나 다른가?

하나의 서비스를 변화시킬 때 다른 서비스를 깰 리스크는 무엇이 있는가?

특정 개발 조건에서 재생산을 어떻게 할 것인가?

 

팀 구성 :

각 서비스에 책임을 갖는 작은 자치 구조의 팀을 가지고 있는가?

데브옵스에 대해서 지식을 가지고 있는 개발자들을 보유하고 있는가?

팀에 “DevOps” 문화가 얼마나 잘 적용되어 있는가?

 

종속성과 재생산성

 

애플리케이션과 별도로 차트를 유지한다면, 차트가 서로 다르게 버전이 나누어져 관리됩니다. 만약에 배포에 문제가 있다면, 문제가 생긴 부분을 재생산해야 하는데, 이때 다음을 대상으로 식별할 필요가 있습니다.

 

A) 서비스 버전

 

B) 배포할 때 사용할 차트 버전. 사람들은 지름길을 택해서 항상 x.x.x 서비스의 “최신” 차트를 테스트하고 싶을지 모르지만, 이는 끔찍한 아이디어입니다.

 

문제를 야기했던 당시와 똑같은 조건을 만들어 낼 수 없을 겁니다.

그래서 만약 차트를 변경해야 하는 배포를 종종 한다면? 그런 테스트를 동시에 해야 하지 않을까요?

다음의 일러스트의 시나리오를 통해서 동일한 공유 차트 내에서 많은 개발자가 브랜치 버전을 만들어야 할 경우를 생각해 봅시다.

 

 

각 서비스 브랜치는 정확한 차트 브랜치를 사용할 필요가 있습니다.

 

 

·       개발자들(Edeltraud and Eberhardt – 한국명 철수와 훈이)이 동시에 다른 특징을 가진 브랜치에서 작업을 하고 있고, Dev 환경에서 차트 변화를 테스트하고 싶어 합니다. 그래서 차트를 분기할 필요가 있습니다.

 

·       한편, 데브옵스 엔지니어인 Duane은 공유 차트의 자신의 브랜치에서 일부 공통 구성요소를 업데이트합니다.

 

만일 아무도 차트 변화를 브랜치를 통해 분기하지 않는다면, 다른 서비스의 배포가 깨질 위험을 감수해야 합니다.

저희는 정확히 이 문제를 마주한 지 그리 오래지 않았습니다. 차트 담당자는 공유 차트를 새로운 조건 블록과 함께 업데이트했습니다. 차트의 상태는 새로운 변수인 “foo”가 “enabled, 가능” 상태로 설정되었는지를 확인하기 위해서 체크되었습니다.

그렇지만, 변수 “foo”는 아직 모든 서비스에 대해서 값을 위한 파일에 정의되지 않았습니다. 서비스의 배포가 누락된 변수들로 인해서 깨졌습니다. – 불행하게도, 그 당시에 차트 내에 정의된 기본 폴백 동작은 없었습니다.

 

만약 차트와 코드가 같은 레파지토리에 있고, 동일한 브랜치 안에서 테스트할 수 있다면 이러한 종류의 이슈를 테스트하기는 무척이나 쉽습니다.

우리는 처음부터 과하게 보일 때라도 이런 작업을 진행합니다.

종속성이 거의 없는 서비스에 착수했던 적이 있었습니다 :

각 서비스에 대해서 헬름 차트는 특정 도커 태그가 있는 하나의 메인 컨테이너만 배포합니다. 이미지 이름과 도커 태그는 변수를 통해서 전달됩니다. 그럼에도 불구하고, 우리는 여전히 공유 차트를 사용하지 않고 대신에 각 서비스 레파지토리에 서비스별로 차트를 배치하기로 했습니다.

 

주된 이유는 다룰 서비스가 4개뿐이었기 때문입니다. 하지만 개발자들은 CI/CD에 영향을 미칠 모든 구성을 소유하는 것을 선호했습니다. 이런 케이스가 항상 있는 것은 아니지만, 다른 차원의 문제를 실험해 볼 좋은 기회였습니다.

 

팀 구성

 

차트 유지의 문제는 개발 프로세스를 누가 유지하고 있는지에 따라 달렸습니다.

또 다른 헬름 전담자인 매트 페리나의 “헬름이 해결하려고 하는 복잡성“이라는 훌륭한 글이 있습니다. 그는 쿠버네티스에서 복잡도를 다루는 3가지 주요한 역할에 대해서 명시합니다. 명확히 짚고 넘어가기 위해서, 저는 그가 표현한 역할을 인용하여 다음과 같이 표현하겠습니다.

 

1.     앱 개발자 : 이들은 서비스를 만들고, 특성을 추가하고, 버그를 수정합니다.

 

2.     배포자 : 이들은 애플리케이션을 세상으로 배포하는 데 있어서 책임을 갖습니다.

희망적이게도 그들에게는 어지간하면 앱 배포를 자동화할 수 있습니다.

하지만 어떻게 동작하는지에 대해서 지식을 갖고 있고, 필요하다면 바꿀 수 있어야 합니다.

 

3.     시스템 엔지니어 : 이들은 개발자들이 배포한 쿠버네티스 환경을 유지합니다. 그들은 계산적인 리소스를 관리하는데 전문가이고, 어떠한 서비스의 다운 타임도 줄이려고 노력합니다.

 

첫 번째와 세 번째 역할은 흔히 볼 수 있는 일반적인 직책명과 일치합니다. 하지만 “배포자”는 좀 모호합니다.

이 역할은 종종 다른 두 가지 역할이 이 역할을 함께 담당합니다. 그리고 이는 헬름 차트를 어떻게 다룰지도 영향을 미칩니다.

 

저희는 이를 경험을 통해 배울 수 있었습니다.

 

초기 단계 스타트업의 DevOps

 

앞서 언급한 바와 같이, 저희는 스타트업들을 위해서 종종 빠른 속도로 규모를 확장하는 운영 지원 사업을 제공하고 있습니다.

저희는 수많은 “전통적이지 않은” 셋업과 부서들을 보았습니다. 초기 단계에서는, 앱 개발자들은 때론 다른 감투를 써서 시스템 관리자의 도움 없이도 프린터 세팅을 하거나 사무실의 VPN을 구성하는 등의 작업 등도 수행할 필요가 있습니다.

 

그들은 고개를 들고 주변을 살펴서 다른 두 가지 역할이 무엇을 담당하는지에 대해서 최선을 다해서 알아낼 것이고, 저희가 업무를 맡기 전까지는 그들을 도와줄 다른 사람은 없습니다.

헬름을 구성하면, 대다수 앱 개발자들은 그들이 다루고 있는 가장 쉬운 장소(예를 들면, 그들이 유지하고 있는 동일한 레파지토리)에 그들의 차트를 모두 넣을 것입니다. 

 

큰 규모의 회사의 DevOps

 

더 크고, 구조화된 팀에서 일하고 있는 경우, 앞선 세션에서 언급한 다양한 각도의 공포에 대해서 읽어본 적이 있을 겁니다.

 

이 경우, 회사 내에 데브옵스 엔지니어가 있을 것이고, 심지어는 하나의 데브옵스 부서가 있을 것입니다. 그리고 그들은 종종 “배포자” 역할에 대해서 책임을 느낄 것입니다. 그들은 모든 차트를 차트 레파지토리인 ChartMuseum과 같은 곳에 저장하여 좀 더 중앙화 된 접근을 선호할 가능성이 있습니다. 그리고 종종 그럴듯한 이유를 들어 앱 개발자들이 헬름 차트에 대해서 깊게 관여하는 것을 내버려 두려고 하지 않습니다.

 

일례로, VM웨어 시스템 엔지니어 에이미 첸이 발표한 “밑바닥서부터 헬름 차트 구성하기’라는 테크 토크쇼를 시청한 적이 있는데, 도입부에 그녀가 이런 말을 했습니다 :

 

“인프라스트럭처에서, 주된 목표는 항상 실패에 대비하는 것이잖아요? 신뢰라는 것은 없습니다 – 마치 제가 앱 개발자를 믿으려 하지 않고, 앱 개발자들을 신뢰하지 않아도 된다는 느낌 같이요”

 

이 내용은 이해할 수가 없습니다. 당신은 CPU와 메모리 제한 혹은 파드 중지와 같은 설정을 앱 개발자가 어지럽히지 않길 바랍니다. 하지만 이러한 “데브옵스 문화”와 같은 전체의 개념은 특히 인프라스트럭처 유지자와 개발자 간의 가끔 소원해지는 관계의 개선도 포함됩니다.

 

 

데브옵스 문화 적용하기

아틀라시안(지라와 트렐로 보유기업)은 데브옵스 문화에 대해서 다루는 “팀 플레이북”이라는 책을 발간하여 다음과 같이 정의했습니다 :

 

“데브옵스 문화는 개발자와 운영팀 그리고 그들이 만드는 소프트웨어에 대한 책임을 공유하고, 그들의 이해를 공유하는 것에 대한 모든 것이다. 이것은 개발, IT/운영, “비즈니스” 전반에 걸친 투명성과 커뮤니케이션의 증대를 의미한다”

 

만약에 이를 헬름 차트 유지와 인프라스트럭처 구성을 위해서 실전에 적용하려 한다면, 애플리케이션 개발자들의 손에 많은 책임을 쥐게 할 것입니다. 그들은 “배포자”의 역할을 맡아 그들의 레파지토리에 있는 구성을 바꿀 것입니다.

 

시스템 엔지니어들은 여전히 구성을 중앙화하고 독점적으로 운영할 수 있습니다.

예를 들어, 일부 팀들은 테라폼 환경 구성이나 헬름 파일 등과 같이 새 프로젝트에서 필요로 하는 공동의 리소스를 갖는 중앙 인프라스트럭처 레포지토리를 유지합니다. (인그레스 컨트롤러 구성하거나 cert 매니저를 구성함으로써)

헬름 3은 또 다른 차트에서 하나의 부분으로 배포되기만 할 수 있는 “라이브러리 차트”라는 것을 지원합니다. 이것이 공통, 서비스별 변화에 따른 책임을 나누는 일을 좀 더 쉽게 만들 수 있습니다.

 

차트가 서비스 레파지토리에 있을 때도, 시스템 엔지니어는 여전히 중요한 변화에서 문지기 역할을 수행할 수 있습니다. 예를 들면,  깃허브 코드 오너 파일을 사용하여 시스템 엔지니어를 리뷰어로 추가함으로써 차트 디렉토리의 변화에서도 보증할 수 있도록 합니다.

만일 시스템 엔지니어가 애플리케이션 개발과 관련되지 않은 변화를 적극적으로 만들어 나갈 필요가 있는 경우, 직접 개발자들에게 지시하고 그들에게 이 변화가 왜 필요한지에 대해서 설명해야 할 수도 있습니다.

앞서 보여드린 일러스트에 이 시나리오의 내용을 반영해 고려해 봅시다.

 

 

 

 

개발자들은 인프라스트럭처에 대해서 더 배우고 이러한 변화들이 서비스에 어떻게 영향을 미치는지에 대해서 알게 됩니다.

 

가이드라인

 

만약 간단하면서도 실용적인 방법을 뽑으라면, 이 내용을 뽑겠습니다 :

 

옵션 #3 서비스와 동일한 레파지토리에서 서비스별 차트 유지하기

 

먼저, 서비스 레파지토리내의 각 서비스별 헬름 차트를 유지하도록 합시다. 혹은 최소한 앞서 기술한 하이브리드 방식의 접근법을 고려하도록 합니다.

 

만약 수 십개의 서비스가 매우 비슷하게 이루어져 있다면, 공유 차트가 더 좋은 선택입니다. 단지 중앙 레포지토리 안에 넣어둬야 한다는 것만 기억하면 됩니다. 이는 서비스 배포를 깨뜨리는 우발적 결합의 위험을 증가시킵니다.

증가된 위험이 뜻하는 것은 배포에 대해서 더 주의해야 한다는 것이고, 다시 말해 배포를 이전보다 덜 자주 하게 되리라는 것입니다.

 

서비스별 차트를 갖고 있다고 해도, 분산 처리해서 관리할 전담 팀이나 인원이 없기 때문에 차트들을 중앙적으로 저장해야 할 수 있습니다.

 

혹은 회사에서 “배포자”와 “애플리케이션 개발자”간의 책임을 분산할 수 있습니다.

 

무엇을 할지에 대해서 결정할지와 관계없이, 제가 희망하기로는 최종 결정 시에 무엇을 제일 중요하게 고려할 지에 대해서 분명히 하기를 바랍니다. 특히나 일상 업무가 아닐 때 “배포자”가 되기는 쉽지 않습니다.