Tekton과 Jenkins 비교: Red Hat OpenShift의 CI/CD 파이프라인에는 무엇이 더 적합한가?

Tekton은 Knative 프로젝트에서 확장되었으며, 이후 Red Hat OpenShift의 파이프라인에 관한 모든 것의 미래로서 Red Hat의 지원을 받아왔습니다. 2018년에 Tekton에 대해 처음 들었을 때 저의 첫 반응은 '대체 무슨 문제를 해결해야 하는 거지?'였습니다. 왜냐하면 저는 Jenkins를 알고 있고 Jenkins를 좋아하기 때문이죠. 그렇기 때문에 현재 사용하는 기술에 아무런 문제가 없는데 굳이 왜 새 기술을 힘들게 배워야 하냐는 생각이었습니다.

2023 Gartner® Magic Quadrant™에서 리더로 선정된 Red Hat

Red Hat은 Gartner 2023 Magic Quadrant 컨테이너 관리 부문의 실행 능력 및 비전의 완성도에서 최고점을 획득했습니다.

리포트 읽기

'Tekton이 Jenkins보다 나은 이유가 무엇인가?'라는 질문을 할 때마다 'Tekton은 클라우드 네이티브이기 때문이다'라는 답변을 가장 흔히 들었습니다. 하지만 그다음에는 주로 침묵이 뒤따르거나 다른 화제로 빠르게 전환되었죠. 그래서 저는 유레카의 순간을 기대하며 '클라우드 네이티브'에 대한 명확한 정의를 찾아보았습니다. 

2018년에 클라우드 네이티브 컴퓨팅 재단(Cloud Native Computing Foundation, CNCF)은 '클라우드 네이티브란 퍼블릭, 프라이빗, 하이브리드 클라우드와 같은 현대적인 다이나믹 환경에서 조직이 확장 가능한 애플리케이션을 빌드하고 실행할 수 있도록 지원하는 기술'이라는 정의를 발표했습니다.

당연히 이것으로는 명확하게 깨닫는 바가 없었습니다. 게다가 저는 수년간 잘 사용해 온 툴에 비이성적일 만큼 애착을 갖곤 합니다. 그렇기 때문에 오래됐지만 여전히 제 역할을 다하고 있는 Jenkins에 작별을 고하려면 확실히 남의 떡이 더 커 보여야 할 강력한 이유가 필요했습니다. Jenkins를 떠나려면 이미 갖고 있는 것보다 훨씬 더 많은 무언가를 Tekton이 줄 수 있어야 했죠. 

결국 제 결론은 이랬습니다. 'OpenShift/k8s 영역에서는 Tekton이 더 잘 통합되고, Jenkins를 사용할 때는 반드시 필요하다고 생각하지 않았던 새로운 기회에 대한 잠재력을 열어준다.'

이 내용은 이 문서의 나머지 부분에서 설명하겠습니다. 저와 같은 질문을 하고 있는 분이 계신다면 원하는 답변을 찾을 수 있기를 바랍니다.

개인적인 Jenkins 사용 경험

Jenkins가 아무리 좋아도 오래된 것은 사실입니다. 2005년경에 처음 등장했는데 그 이후로 크게 바뀐 것이 없습니다. 가장 큰 장점은 플러그인이 다양하기 때문에 사용자가 거의 모든 것과 인터페이스로 쉽게 연결할 수 있다는 것입니다. 그러나 이는 약점이 되기도 합니다. 플러그인의 소프트웨어 라이프사이클이 불확실하기 때문입니다. 플러그인에 문제가 발생하면 주로 근본적인 해결책 없이 일시적으로 해결해야 할 때가 많습니다. 

Jenkins는 Java 기반입니다. 지속적으로 실행되며 메모리와 프로세서를 많이 사용하는 것으로 잘 알려져 있죠. 게다가 컴퓨팅 리소스 비용까지 집계되면 문제가 될 수 있습니다.

컨테이너 이전 시대에는 일반적으로 전체 개발 부서가 '커다란' Jenkins 서버 한 대를 사용했습니다. 그리고 이것은 결과적으로 개발 부서에 장애물이 되곤 했습니다. Jenkins에 높은 부하가 가해지면 이를 처리하는 데 어려움을 겪을 수 있기 때문에 Jenkins가 엄청나게 꼬였으니까 다시 시작해야 한다고들 했죠. 그러면 별수 없이 원점으로 돌아가는 거고요. 

컨테이너가 등장하면서 이제 팀마다 Jenkins 서버를 소유하고 원하는 방식으로 구성할 수 있게 되었습니다. 그러나 이로 인해 'Jenkins의 무분별한 확산'이라는 또 다른 문제가 발생했습니다. 그렇게 확산된 Jenkins 서버들은 대부분 별로 하는 일도 없이 계속 실행되어 리소스를 낭비하기만 했습니다. 팀마다 여러 유형의 수많은 파이프라인 코드를 배포한 것은 말할 것도 없습니다.

따라서 풋프린트를 최소화해 각 팀에 분산될 수 있는 동시에 모든 파이프라인이 비슷하게 보이도록 강력하게 유도할 수 있는 툴이 필요한 상황이었습니다. 이 부분은 잠시 보류해 두고 나중에 다시 이야기하겠습니다.

프로세스 시퀀싱 모델 정보

소프트웨어 시스템에서는 결과에 영향을 미치기 위해 서비스 호출/프로세스 단계의 순서를 구성할 수 있는 방법이 필요합니다. 이를 수행하는 방법에는 두 가지가 잘 알려져 있습니다.

첫 번째 패턴은 오케스트레이션 유형으로, 프로세스 관리자 패턴을 특징으로 합니다.

출처. (이 파일은 Creative Commons Attribution-Share Alike 4.0 International 라이센스에 따라 사용이 허가되었습니다.)

프로세스 관리자는 실제 오케스트라의 지휘자처럼 작동합니다. 그래서 오케스트레이션이라는 이름이 붙었습니다.

Jenkins는 이 패턴의 예입니다. 프로세스 관리자, 즉 지휘자 역할을 하죠. 사용자는 JenkinsFile을 사용하여 프로세스를 코딩하고, 이 과정에서 프로세스를 정의합니다. Jenkins에서 여러 플러그인 기반 인터페이스를 통해 전달한 모든 작업은 완료된 상태로 프로세스 관리자에게 다시 돌아갑니다. 그러면 프로세스의 다음 단계가 시작될 수 있습니다. 이는 대부분의 경우 동기식 동작으로 나타납니다. 

프로세스 관리자 패턴에 대해 Refactoring to Patterns(Kerievsky 2004)에서는 '본질적으로 불안정한' 것으로 설명하고 있습니다. 이는 누군가 프로세스 관리자를 다시 시작하면 해당 시점에 실행 중이던 프로세스가 중단될 수 있기 때문입니다. 따라서 프로세스 관리자의 설계는 장기적으로 실행되는 프로세스에서 특히 효과가 없는 것으로 알려져 있습니다. 

이제 두 번째 시퀀싱 패턴을 살펴보겠습니다. 다음 사진은 스포츠 경기장에서 파도타기 응원을 하고 있는 관중들의 모습입니다.

출처. (이 파일은 Creative Commons Attribution-Share Alike 2.0 Generic 라이센스에 따라 사용이 허가되었습니다.)

관중 속 각 사람은 누가 말해 주지 않아도 자기가 일어서서 손을 들어야 할 때를 알고 있습니다. 그렇지만 대규모 축구장에서는 너무 많은 상황이 발생하다 보니 이렇게 일사불란한 오케스트레이션을 기대할 수 없습니다. 이것이 코레오그래피(Choreography)라는 다음 시퀀싱 패턴 유형의 예입니다.

오케스트레이션은 대부분의 개발자가 가장 먼저 당연하게 선택하는 설계 옵션입니다. 코레오그래피는 그렇지는 않지만 이벤트와 함께 작동할 때 효과적이며 일반적으로 대폭 개선된 재작성/설계 옵션입니다.

이는 수백 개의 서비스를 시퀀싱해야 할 수 있는 마이크로서비스 환경과 매우 관련이 있습니다. 그러나 마찬가지로, 장기적인 구축, 테스트 및 해체 유형의 파이프라인 활동이 발생할 수 있는 환경에서는 코레오그래피 스타일이 훨씬 더 강력하고 실용적인 모델입니다.

Tekton 파이프라인은 K8 API 서버에서 내부 쿠버네티스 이벤트를 통해 순서대로 배열된 별도의 컨테이너에서 구축됩니다. Tekton 파이프라인은 이벤트 기반 코레오그래피 시퀀싱 유형의 예입니다. 잠그거나, 다시 시작하거나, 리소스를 독점하거나, 장애를 일으킬 단일 프로세스 관리자가 없습니다.  Tekton을 사용하면 담당하는 파이프라인 프로세스의 모든 단계를 수행하기 위해 필요할 때 각 포드가 인스턴스화할 수 있습니다. 그리고 완료되면 종료되므로 사용하던 리소스를 더 이상 사용하지 않아 다른 작업을 위한 리소스가 확보됩니다.

재사용을 통한 이상적인 탄력적 결합 및 주기

Tekton의 또 다른 특징은 소프트웨어 아키텍처 내에서 탄력적 결합이 가능하다는 것입니다. 아래 장난감 기차 세트의 사진을 보면서 생각해 보겠습니다.

Ultra-lab의 '나무 선로 위의 장난감 기차(Toy train for wood tracks)'는 CC BY-SA 2.0 라이센스에 따라 사용이 허가되었습니다. 

열차와 객차 사이의 연결은 끌어당기는 힘이 있습니다. 그래서 아이는 열차를 단독으로 갖고 놀 수도 있지만 모든 객차를 연결하거나 그 외 여러 형태로 연결하여 가지고 놀 수 있습니다.

아이는 객차의 순서를 바꿀 수도 있습니다. 예를 들어 연두색과 노란색 객차의 순서를 바꿀 수 있죠. 만약 아이에게 비슷한 기차 세트가 또 있다면 한 세트의 모든 객차를 다른 세트에 연결해 '슈퍼 열차'를 만들 수도 있습니다.

이러한 예에서 '탄력적 결합'이 왜 최적의 소프트웨어 설계 아키텍처인지 알 수 있습니다. 본질적으로 재사용을 촉진하며, 이것은 바로 Tekton의 기본 정신 중 하나입니다. 한번 만들어진 구성 요소는 프로젝트 간에 매우 쉽게 공유할 수 있습니다.

결합이라는 주제를 살펴보는 동안 탄력적 결합의 반대인 긴밀한 결합에 대해서도 알아보겠습니다. 또 다른 어린이 장난감을 보도록 하죠.

PINTOY^®의 '09506_Pull-Along Caterpillar'는 CC BY-SA 2.0 라이센스에 따라 사용이 허가되었습니다. 

애벌레 장난감도 여러 부분으로 나뉘어져 있지만 고정되어 있기 때문에 순서를 변경할 수 없습니다. 나뉜 부분의 개수를 줄일 수도 없고 추가해서 슈퍼 애벌레를 만들 수도 없습니다. 만약 아이가 3개의 부분으로만 이뤄진 애벌레를 원한다면 부모에게 다른 애벌레 장난감을 사달라고 부탁해야 합니다.

이 예에서 우리는 긴밀한 결합이 재사용을 촉진하지 않고 오히려 중복을 강요한다는 것을 알 수 있습니다.

네, 저는 Jenkins 파이프라인도 탄력적으로 결합이 가능하고 프로젝트 간 코드 공유가 가능하다는 데 동의합니다. 하지만 이것은 기정사실이 아닙니다. 파이프라인 설계 방식에 따라 크게 달라지는 부분입니다.

대안은 모든 프로젝트에 하나의 Jenkins 파이프라인을 사용하는 것입니다. 그러나 이는 제한적이며, 곧 시작하게 되는 또 다른 프로젝트에서는 모든 방식에 적합한 접근 방식에서와는 다른 요구 사항을 접하게 됩니다. 결국 단일 파이프라인 설계의 무결성이 훼손되고 맙니다.

Tekton은 본질적으로 선언적이며 Tekton의 파이프라인은 나무로 된 장난감 기차의 예와 매우 닮았습니다. 피상적이지만 Tekton의 하이 레벨 오브젝트인 'Pipeline(파이프라인)'을 기관차로 상상해볼 수 있습니다. 파이프라인에는 객차처럼 생각하면 되는 태스크들이 포함되어 있습니다. 그리고 서로 다른 파이프라인에 다시 매개 변수화되고 재사용된 동일한 태스크가 포함될 수 있습니다. 따라서 탄력적으로 결합되고 매개 변수화할 수 있는 태스크들이 서로 연결되어 파이프라인을 형성합니다. Tekton은 탄력적인 결합을 강력하게 촉진하므로 재사용 기회가 직접적으로 발생합니다. 즉, 한 프로젝트의 작업을 선택하여 다른 곳에서 사용할 수 있습니다.

또한 Tekton은 쿠버네티스 오브젝트에 대한 추가적인 정의입니다. 즉, 모든 요소의 코드화 방식과 GitOps에도 쉽게 적용될 수 있습니다. 파이프라인 코드는 다른 클러스터/네임스페이스 구성과 함께 클러스터에 쉽게 적용할 수 있습니다.

그렇다면 왜 이런 것들이 중요할까요?

공식적인 개발, 테스트 및 UAT 유형 환경의 개념은 대체로 오래된 개념이기 때문입니다. 이러한 고정된 환경은 물리적 서버를 구입한 다음 사용 용도를 지정해야 했던 시절에 시작된 것입니다.

이것이 과거의 방식이었습니다. OpenShift와 모든 요소의 코드화, 반려동물과 가축의 비교로 비유되는 변경 불가능한 인프라와 변경 가능한 인프라 등의 환경에서는 파이프라인과 테스트, 그리고 실행을 통해 이러한 환경을 동적으로 인스턴스화하지 못할 이유가 없습니다. 일단 완료되면 이 환경들은 다른 테스트 등을 위해 다시 완전히 제거될 수 있습니다.

하지만 아직 대부분의 기업에서는 도입하지 않은 방식입니다. 아마도 그 이유 중 하나는 지금까지 사용하던 툴링이 특별히 적합하지는 않았기 때문일 것입니다.

결론

세계는 과거에는 그저 불가능하기만 했던 OpenShift와 같은 기술이 제공하는 기회를 모두 따라잡으려고 여전히 애쓰고 있습니다.

컴퓨팅 리소스가 최소한 저녁 시간에는 유휴 상태인 것을 고려하면 테스트를 자동화하여 더 나은 소프트웨어를 제공할 수 있는 기회는 무궁무진합니다. 저는 오랫동안 이러한 종류의 아이디어들에 대해 이야기했지만 Jenkins가 이 같은 유형의 작업에 적합한 툴이라고 생각한 적은 없습니다. 그리고 열린 마음으로 처음 Tekton을 접하자마자 Tekton이 최적의 툴이라는 것을 금세 깨달을 수 있었습니다.

Tekton은 근본적으로 쿠버네티스 API 및 보안 모델과 통합되며 탄력적 결합/재사용을 강력하게 촉진합니다. Tekton은 코레오그래피 모델에 따라 이벤트를 기반으로 하므로 장기간 실행되는 테스트 유형 프로세스를 제어하는 데 적합합니다. 파이프라인 아티팩트는 포드 정의, 서비스 계정, 암호 등 추가적인 쿠버네티스 리소스에 불과하며, k8 유형 에코시스템의 나머지 부분과 연계되어 모든 요소의 코드화 환경에 쉽게 활용될 수 있습니다.

각 애플리케이션 팀은 자체 파이프라인 코드를 보유할 수 있습니다. 자체 파이프라인 코드는 실행되지 않을 때는 리소스를 전혀 사용하지 않기 때문에 유휴 부하가 없는 '분산형 Jenkins'의 장점을 제공합니다. Apache Maven은 판도를 바꾼 혁신적인 툴이기 때문에 빠른 속도로 성공을 거두었습니다. Apached Maven을 통해 Java 프로젝트 설계에 체계적인 방식이 도입되었고, 개발자는 프로젝트 간 빌드 구성을 쉽게 파악할 수 있었습니다. Tekton은 파이프라인으로 동일한 작업을 수행하므로 태스크를 쉽고 확실하게 재사용할 수 있습니다.

Cruise Control은 2000년대 초반에 등장한 최초의 CI 툴이었습니다. 개인적인 경험으로는 사용하기가 어려운 툴이었습니다. 당시에는 Jenkins가 과거에 비해 획기적으로 개선된 툴로 느껴졌습니다. 그리고 지금 OpenShift/k8s 환경에서는 Tekton이 파이프라인 기술 분야의 발전을 위해 반드시 필요한 단계라는 느낌을 강하게 받고 있습니다.

자세히 알아보기

• Red Hat OpenShift 기반의 클라우드 네이티브 CI/CD