DevOps에 관심이 있다면 ‘스윔 레인(Swim lanes)’이란 용어가 귀에 들어올 것입니다. 스윔 레인은 말 그대로 수영장에서 레인을 구분하듯이 개발 프로세스의 각 단계를 시각적으로 구분하여 나타내는 것을 뜻합니다. 칸반(Kanban) 보드를 접해본 이들에게는 익숙한 개념일 것입니다. 각 개발 프로젝트의 작업을 시각화하고 진행 상황을 직관적으로 추적할 수 있도록 돕는 역할을 하는 것이 스윔 레인이라 이해하면 됩니다. 스윔 레인은 일반적으로 개발 프로세스의 각 단계를 나타내는 별도의 칸으로 나뉩니다. 예를 들어, 계획, 개발, 테스트, 배포 및 모니터링 단계와 같은 단계가 있을 수 있습니다. 각 단계는 해당 단계와 관련된 작업을 나타내는 카드로 채워집니다. 이를 적용하면 다음과 같은 효과를 거둘 수 있습니다.
l 가시성 향상: 스윔 레인은 팀이 작업 진행 상황을 시각화하고 병목 현상을 식별하는 데 도움이 될 수 있습니다.
l 커뮤니케이션 개선: 스윔 레인은 팀원 간의 커뮤니케이션과 협업을 개선하는 데 도움이 될 수 있습니다.
l 효율성 향상: 스윔 레인은 작업이 적절한 사람에게 할당되고 올바른 순서로 완료되도록 하여 팀이 더욱 효율적으로 작업할 수 있도록 도와줍니다.
l 품질 향상: 스윔 레인은 작업이 배포되기 전에 적절하게 테스트 되도록 하여 작업의 품질을 개선하는 데 도움이 될 수 있습니다.
개발과 인프라 팀의 소통 강화를 위한 스윔 레인
이 중 이번 포스팅에서는 커뮤니케이션 개선에 대해 알아볼까 합니다. 스윔 레인은 DevOps 파이프라인에 관여하는 여러 이해관계자 간이 소통과 협력에도 도움이 됩니다. 이런 이유로 개발과 운영 간의 보이지 않는 커뮤니케이션의 불편함과 비효율을 제거하는 수단으로 스윔 레인 개념을 수용하는 곳이 많습니다. 예를 들어 볼까요. 스윔 레인을 지원할 수 있는 적절한 도구를 제공하면 개발자는 티겟을 열거나, 이메일을 보내거나, 필요한 것을 얻기 위해 슬랙으로 메시지를 운영 팀에 보내지 않고도 애플리케이션 배포와 운영 인프라의 상태를 직접 파악할 수 있습니다. 인프라 운영자는 DevOps 파이프라인에 대한 가시성을 토대로 개발 팀의 작업에 영향을 끼치지 않도록 패치 및 업데이트 작업 관련 다운타임을 최소화할 수 있습니다. 개발자와 운영자는 불필요한 커뮤니케이션 없이 각자의 작업을 할 수 있어 의사소통과 작업 효율이 모두 높아집니다.
개발과 운영 간 소통과 작업 효율을 높일 수 있는 부분은 배포와 모니터링입니다. 스윔 레인 관점에서 배포와 모니터링 관련 소통과 효율을 높이는 데 있어 Red Hat OpenShift는 꽤 훌륭한 도구라 할 수 있습니다.
개발자 스윔 레인
Red Hat OpenShift는 애플리케이션 콘솔, API 및 CLI를 통해 제품 팀을 위한 스윔 레인을 제공합니다. 두 옵션 중 하나를 사용하여 개발 팀은 운영 팀에 매번 지원 요청을 하지 않고도 애플리케이션 및 인프라 상태는 물론 로그 및 메트릭에 액세스할 수 있습니다.
개발자는 위 스크린샷에서 볼 수 있듯이 필요에 따라 로그와 메트릭을 확인할 수 있습니다.
운영자 스윔 레인
Red Hat OpenShift는 클러스터 운영자에게 클러스터에서 워크로드를 실행하는 개발자를 위해 최소한의 또는 눈에 띄지 않는 가동 중지 시간으로 클러스터를 업데이트할 수 있는 수단을 제공합니다. 운영자는 개발 작업에 끼치는 영향을 최소화하면서 실행 중인 환경에 필요한 변경을 수행할 수 있습니다. 또한, 필요에 따라 특정 워크로드를 퍼블릭 클라우드로 이동하기로 한 경우도 동일한 콘솔, API 또는 CLI 환경을 유지할 수 있어 프라이빗 데이터 센터에서와 동일한 방식으로 퍼블릭 클라우드에서 클러스터를 생성하고 유지할 수 있습니다. 이게 뜻하는 바는? 스윔 레인을 유지할 수 있다는 것입니다.
개발자와 운영자를 위한 스윔 레인 지원의 원칙
DevOps 파이프라인에서 개발과 운영이 서로 독립적으로 작업을 할 수 있는 스윔 레인을 유지하려면? 이를 지원하는 도구가 필요합니다. Red Hat OpenShift은 배포와 모니터링 측면에서 개발과 운영 팀이 독립적으로 스윔 레인을 유지할 방법을 제시합니다. 더 자세한 내용이 궁금하다면 락플레이스로 문의 바랍니다.
참고로 운영 팀 입장에서 개발자 모두에게 독립적인 작업을 보장하는 것은 위험이 따를 수 있습니다. 이런 경우를 위해 레드햇은 CRC(Code Ready Container)라는 것을 제공합니다. 인프라 프로비저닝 및 모니터링에 서툰 개발자가 있다면? CRC를 통해 충분히 사전 훈련을 시킬 수 있습니다. CRC는 개발자의 로컬 머신에서 Red Hat OpenShift 기반 개발 환경을 에뮬레이션 하는 것이라 보면 됩니다. 개발자의 시스템에 가상 머신 띄우듯 CRC를 통해 사전 구성된 OpenShift 클러스터를 로컬 PC에서 사용해 볼 수 있습니다.
