IT/모바일
쿠버네티스는 소프트웨어를 안정적으로 운영하기 위해 만들어졌습니다.
애플리케이션 지향 application-oriented API, 자가 치유self-healing 속성, 무중단 소프트웨어 롤아웃을 위한 디플로이먼트 등 유용한 툴을 제공하여 애플리케이션을 배포/관리하는 작업을 간편하게 할 수 있죠. 그러나 쿠버네티스로 서비스할 애플리케이션을 더 쉽게 개발할 수 있게 해주는 것은 아닙니다. 그렇기 때문에 개발자 워크플로가 중요합니다.
클러스터는 대부분 프로덕션 애플리케이션을 운영할 목적으로 설계되었으므로 개발자 워크플로에서 직접 액세스할 일은 드물지만, 쿠버네티스를 타깃으로 한 개발자 워크플로를 구축하는 일은 매우 중요합니다. 보통 하나의 클러스터 또는 적어도 전체 클러스터의 일부를 개발 용도로 구축하는데, 개발 클러스터를 잘 구축해서 쿠버네티스용 애플리케이션 개발을 간소화하는 것은 쿠버네티스 시스템의 성공을 보장하는 핵심 요소라고 할 수 있습니다.
목표
이야기를 계속 하기 전에 개발 클러스터를 구축하는 목표를 분명히 하고자 합니다. 개발자가 쿠버네티스에서 애플리케이션을 쉽고 빠르게 개발하도록 지원하는 것이 궁극적인 목표인데, 현장에서는 이 말이 정확히 어떤 의미일까요? 그리고 실용적인 관점에서 개발 클러스터는 어떤 가치가 있을까요? 이 질문에 답하려면 먼저 개발자가 클러스터와 인터랙션 (상호 작용)하는 과정을 살펴 볼 필요가 있습니다.
첫 번째 단계는 온보딩입니다. 신규 개발자가 팀에 합류하면 클러스터에 로그인 가능 한 유저 계정을 발급하고 처음 배포를 할 수 있을 때까지 숙달시키는 과정입니다. 목표는 개발자가 최단 시간 내에 업무 적응을 마치도록 돕는 것입니다. 이 프로세스는 미리 KPIKey Performance Index (성과 지표)를 수립해야 합니다. ‘아무것도 모르는 팀원도 30분 이내에 최신 버전의 애플리케이션을 실행시킨다’ 하는 식으로 말이죠. 새로 팀원이 들어올 때마다 목표가 제대로 달성되고 있는지 점검해 봅시다.
두 번째 단계는 개발입니다. 네, 개발자가 매일 하는 일이죠. 이 단계의 목표는 신속한 이터레이션과 디버깅입니다. 개발자는 자기가 짠 코드를 빠르게, 반복적으로 클러스터에 푸시하는 동시에 코드를 쉽게 테스트하고 (제대로 작동하지 않으면) 디버깅할 수 있어야 합니다. 이 단계의 KPI를 정확하게 측정하기는 쉽지 않지만, PRPull Request(풀 리퀘스트)를 보내거나 수정한 코드를 클러스터에서 실행하기까지 걸린 시간, 그리고 유저가 느끼는 생산성에 관한 설문 조사(또는 둘 다) 결과를 평가에 반영할 수 있겠습니다. 팀의 전반적인 생산성을 가늠해보는 것도 좋은 방법이 되겠네요.
세 번째 단계는 테스팅입니다. 코드를 커밋 또는 머지(병합)하기 전에 코드가 올바른 지 검사하는 단계로, 개발과 맞물려 있습니다. 이 단계의 목표는 두 가지입니다. 첫째, 개발자가 PR을 보내기 전에 자신의 PC 환경에서 모든 테스트를 실행해 볼 것. 둘째, 모든 테스트는 코드가 리포지터리에 머지되기 전에 자동으로 실행될 것. 프로젝트가 복잡해질수록 테스팅 시간도 점점 늘어나므로 테스트 실행 시간도 KPI에 포함시켜야 합니다. 이때 개발자가 PR을 보내기 직전, 초기 검사 용도로 사용할 만한 작은 규모의 스모크 테스트smoke test 가 있으면 도움이 될 것입니다. 코드를 변경하지 않았는데 간헐적으로 (혹은 종종) 테스트가 실패하는 테스트 불안정성에 관한 엄격한 KPI도 필요합니다. 상당히 액티브한 프로젝트에서 이런 일이 1/1,000 비율로만 생겨도 개발자 마찰로 이어질 수 있습니다.
어떤 경우에도 클러스터 환경 때문에 테스트가 실패하지 않도록 해야 합니다. 코드 자체의 문제 또는 개발 환경의 간섭(예: 부족한 리소스와 주변 노이즈)으로 테스트가 불안정해지는 경우도 많습니다. 개발 환경에 이런 문제가 없도록, 또 만약 생기면 재빨리 조치할 수 있도록 항상 준비해야 합니다.
개발 클러스터 구축
쿠버네티스 환경에서 개발을 고려할 때, 제일 먼저 대규모 단일 개발 클러스터를 구축할지, 아니면 개발자마다 클러스터를 따로 부여할지 결정해야 합니다. 물론, 이 선택은 퍼블릭 클라우드처럼 클러스터를 그때그때 쉽게 생성할 수 있는 환경에서만 의미가 있습니다. 물리적 환경에서는 당연히 하나의 대규모 클러스터를 구축하는 방법 하나 뿐이죠.
저마다의 장단점을 잘 따져봐야 합니다. 개발자마다 클러스터를 구축하면 개발자마다 각자 관리할 클러스터를 발급하는 체제라 다른 개발자의 클러스터에 침범해서 영향을 끼칠 일이 거의 없다는 장점이 있습니다. 하지만 비용이 많이 들고 비효율적이며 관리할 클러스터가 상당히 늘어나는 중대한 단점이 있습니다. 클러스터별 활용도가 그리 높지 않으므로 추가 비용이 많이 들고, 개발자마다 클러스터를 발급하면 사용하지 않는 리소스를 추적해서 정리하기가 쉽지 않습니다.
이와 달리, 단일 개발 클러스터는 매우 효율적입니다. 개발자 인원수가 같다면 비용을 1/3 이하로 낮출 수 있고, 모니터링이나 로깅같은 공용 클러스터 서비스를 훨씬 더 쉽게 설치할 수 있으므로 개발자 친화적인 클러스터를 만들 수 있습니다. 단, 유저 관리 프로세스와 개발자 간의 간섭은 단점으로 작용합니다.
쿠버네티스 클러스터에 새로운 유저와 네임스페이스를 추가하는 과정은 아직도 그리 간단한 편은 아니라서, 신규 개발자를 온보딩하는 프로세스를 잘 준비해두어야 합니다. 쿠버네티스의 리소스 관리 및 RBACRole-Based Access Control(역할 기반 액세스 제어)를 잘 활용하면 개발자끼리 충돌이 일어날 확률은 줄일 수 있지만, 어느 한 유저가 리소스를 과도하게 써버려 개발 클러스터 전체가 먹통이 되어 버릴 가능성은 항상 존재합니다. 그리고 개발자 본인이 자기가 어떤 리소스를 생성했는지 잊거나, 실수로 리소스 릭resource leak (자원 누수)을 일으키지 않도록 신경 써야 하죠.
물론, 개발자가 직접 자신의 클러스터를 만들어 사용하는 첫 번째 방식보다는 쉽습니다. 둘 중 어느 쪽이라도 가능하지만, 모든 개발자가 단일 대규모 클러스터를 사용하는 방안을 권장하고 있습니다. 개발자 간의 간섭은 발생할 수 있지만 관리를 잘 하면 되며, 무엇보다 비용 효율성이 높고 전사 공용 기능을 클러스터에 쉽게 추가할 수 있는 장점이 크기 때문입니다. 하지만 개발자 온보딩, 리소스 관리, 가비지 컬렉션 프로세스에 어느 정도 투자는 필요합니다.
일단 단일 클러스터를 만들어 사용해보다가 나중에 사세가 확장되거나 조직 규모가 커졌을 때 수백 명의 유저를 수용 가능한 아주 큰 클러스터보다는 팀이나 그룹 단위(10~20명)로 작은 클러스터를 두는 방안을 고려하는 것이 좋습니다. 그렇게 해야 비용, 관리 측면에서 모두 유리하죠. 클러스터를 여럿 두면 일관성을 맞추기가 조금 복잡해지지만, 플릿 매니지먼트fleet management 같은 툴을 활용하면 보다 쉽게 여러 클러스터를 관리할 수 있습니다.
개발 환경 설정 모범 사례
쿠버네티스의 개발 워크플로 구축은 개발자 생산성을 높여, 팀원들이 기쁜 마음으로 일할 수 있는 환경을 만드는 핵심 포인트입니다. 개발자가 쿠버네티스에 빠르게 적응하고 개발 성과를 내는 데 도움이 될 만한 모범 사례를 소개합니다.
✓ 개발자 경험을 온보딩, 개발, 테스팅의 3단계로 생각하고, 자신이 구축한 개발 환경이 이 세 단계를 모두 잘 지원하는지 점검합시다.
✓ 개발 클러스터는 대규모 단일 공용 클러스터로 구축할 수도 있고, 개발자마다 따로 발급되는 클러스터로 구축할 수도 있습니다. 각각 장단점이 있지만 일반적으로 공용 클러스터 가 더 낫습니다.
✓ 클러스터에 유저를 추가할 때 유저 아이덴티티를 추가하고 각자 자기 네임스페이스만 액세스할 수 있도록 설정합시다. 이때 유저가 쓸 수 있는 클러스터의 양은 리소스 리밋으로 제한합니다.
✓ 네임스페이스를 관리할 때 오래된 미사용 리소스를 어떻게 회수할지 고민합시다. 미사용 리소스를 방치하는 개발자는 항상 있기 마련이므로 리소스 정리 작업을 자동화하는 것이 좋습니다.
✓ 모든 유저가 사용 가능한 클러스터 수준의 서비스(예: 로그, 모니터링)를 검토합시다. 모든 유저를 대신하여 데이터베이스 등의 클러스터 수준의 디펜던시를 헬름 차트 같은 템플릿으로 구축하는 것이 유용할 때도 있을 것 입니다.
결론
쿠버네티스 클러스터를 구축하는 작업은 (특히 클라우드 환경에서) 비교적 간단한 편입니다. 하지만 개발자가 쿠버네티스 클러스터에서 생산적으로 애플리케이션을 빌드하며 활용할 수 있으려면 온보딩, 이터레이션, 테스팅, 디버깅 등에 관한 핵심 목표를 잘 정의하는 것이 중요합니다. 아울러 유저 온보딩, 네임스페이스 프로비저닝, 기본 로그 집계 등 클러스터 서비스에 특화된 기본 툴에도 투자를 고려하면 좋습니다. 사내 모범 사례를 표준화하고 실천하는 기회로 삼아 개발 클러스터와 코드 리포지터리를 구축한다면, 향후 개발자가 만족스럽게 생산적으로 코드를 빌드하며 프로덕션 쿠버네티스 클러스터에 성공적으로 배포할 수 있을 것입니다.
위 콘텐츠는 『쿠버네티스 창시자에게 배우는 모범 사례(2판)』에서 내용을 발췌하여 작성하였습니다.
최신 콘텐츠