데브옵스 알아가기(7) : 5plays

이 글을 읽기 전에 다음의 글을 먼저 참고하여 보시기 바랍니다.

• 데브옵스 알아가기 1편 - 애자일 vs 데브옵스
• 데브옵스 알아가기 2편 - 그럼 데브옵스란 ?
• 데브옵스 알아가기 3편 - 데브옵스 구현 전략
• 데브옵스 알아가기 4편 - 3Ways개요 및 제1원칙
• 데브옵스 알아가기 5편 - 3Ways 제2원칙
• 데브옵스 알아가기 6편 - 3Ways 제3원칙

앞서 데브옵스 알아가기 시리즈3-구현전략 편에서 데브옵스 플레이북에 대해서 간단히 소개하였다. 본 편에서는 챕터별로 각 Play에 해당하는 본문의 내용을 설명하는 방식으로 기술하고자 한다.
5plays는 3Ways에 비해 실용적인 측면 위주로 쓰여진 책이라, 현실 세계에서도 이미 많이 실행되고 있는 전략들이 나타난다. 한편으로는 5plays를 통하여 이미 실행하고 있는 전략들이 어떠한 맥락에서 비롯되고 전체적인 데브옵스 이행 전략을 어떻게 전개해야 할지에 대해 논리적 개연성을 확인할 수 있을 것이다.

이 책의 전체 목차는 다음과 같이 구성되어 있다.

Play 1: Develop the Team—Culture, Principles, and Roles

Principles & Culture

보통 데브옵스 전환을 추진할 때 흔히 하는 실수가 곧바로 데브옵스 파이프라인부터 구축하려거나 또는 외부 컨설턴트의 힘을 빌려 타사의 성공한 모델을 자사에 이식하는 것이다. 새로 신생하는 조직이나 스타트업처럼 변화와 적응이 빠른 조직에서는 이러한 방법이 효과적으로 작용할 수 있을 것이다.
반면 엔터프라이즈 조직, 기존의 복잡한 레거시를 갖고 있는 조직에서는 변화를 추진할 때 내부의 저항과 반발심을 겪기 마련이다. 오랫동안 조직 전반에 깊숙이 뿌리내리고 있는 관행을 바꾸는 것이 쉽지 않다. 외부의 힘을 빌리는 것보다는 내부 사정을 잘 아는 조직 구성원들이 변화의 의지를 가지고 같은 방향성을 공유하고 실천하게 된다면 훨씬 효과적으로 변화할 수 있을 것이다. 그렇다면 변화의 의지와 방향성을 심기 위해 조직의 문화는 어떻게 되어야 하는가? 저자에 의하면 성공적인 데브옵스 문화를 가진 회사는 공통적으로 다음과 같은 원칙과 특징을 갖는다.

 1. 운영 및 관련 요청을 최우선으로 여긴다. (Treat operations as first-class citizens)
 2. 개발자가 우선적으로 문제 대응한다 
    (Developers act as first responders to issued /w production System)
 3. 문제의 확인으로부터 해결되는 시간을 단축한다 
    (Shorten the time b/w identification of a production issue and its repair)
 4. 코딩이 완료되고 배포되는 시간을 단축한다 (Shorten the time b/w code commit and deploy 
    : architecture must be designed to automate deployment)
 5. 아예 배포/출시를 위해 관련부서간 협력해야 할 일 자체를 줄인다 
    (Minimize coordination to deploy releases)
 6. Stop and fix potential defects identified by continuous flow and monitoring
 7. Enforce standardized processes to ensure predictable outcomes
    : 예외사항, 비공식적이거나 변칙적인 작업이 정기적으로 발생하지 않아야 함
 8. Become a learning organization through continual feedback and action  
    : Learn about what works and what doesn’t and what we learn becomes our organizational memory  

위의 몇 개 항목은 필자의 눈에 문화적 특징이 아니라 프로세스와 자동화 도구 등을 통해서 해결되어야 하는 항목으로 보이기도 한다. 그러나 다시 생각해보면 이를 실행하려는 원칙과 의지가 없다면 도구가 있다고 해서 해결되는 것 또한 아니다.
예전에 제니퍼 같은 툴을 도입하여 시스템을 모니터링한 적이 있다. 몇몇은 그래프의 특이사항이 나타나는지 주시하면서 오류를 제거하지만, 대다수는 제3자가 문제점을 찾아 꼭집어주어야만 오류를 인지하는 경향이 있었다.
저자는 자발적으로 문제를 찾아내고 해결하고, 개선하려는 원칙과 문화가 먼저 데브옵스 성공에 필요한 것임을 제 1의 플레이 원칙으로 삼았다.

Roles

데브옵스를 위해서는 새로운 역할과 책임이 필요하다. 그렇다고 해서 별도의 독립적인 DevOps팀을 조성하는 것은 오히려 또다른 사일로를 만들 수 있어 바람직하지 않으며, 기존의 조직 내 구성원의 역할이 확장되는 것이 효과적이다.

① DevOps 아키텍트

• DevOps아키텍트는 애자일 프랙티스 및 자동화, 기술적 깊이를 가지고 있으며, 열정을 가지고 끊임없는 자동화와 개선을 추구는 역할이다.
• 기술적으로는 IaaS, PaaS, 컨테이너 등 클라우드 기술을 이해하고 배포 파이프라인 설계를 주도할 수 있어야 한다.

② DevOps 엔지니어

• DevOps 엔지니어는 개발과 운영을 결합하는 하이브리드 기술을 담당하며, 아키텍트가 설계한 대로 구현을 하는 역할이다.
• 코딩, 스크립트 작성, 프로세스 reengineering 및 여러 작업그룹과 collaborating에 능숙하고, 여러가지 OS와 플랫폼에 능숙하다.

③ 테스트 자동화 엔지니어

• 테스트 자동화 엔지니어는 테스트 커버리지 및 신뢰성을 위해 많은 단계를 자동화한다.
• 다양한 테스트 기법, 테스트 프로세스와 도구를 잘 다루며 테스트 자동화와 각 스텝별 데브옵스 파이프라인 구축에 필요한 스크립트 작성한다.
• 단, 테스트 자동화 엔지니어가 테스트 자동화를 모두 떠맡아서는 안된다.(개발자와 테스터가 함께 일함)
• 테스트 자동화 엔지니어가 정의한 데브옵스 파이프라인에 따라 개발자가 자동화 테스트를 위한 작업을 추가할 수 있다.

④ 사이트 안정화 엔지니어 (Site reliability engineer)

• APM, SIEM 및 측정도구 등을 사용하여 어플리케이션 및 서비스의 상태를 모니터링할 수 있지만, 단순 모니터링 OP는 아니다.
• 문제해결 능력이 뛰어나며, 메트릭 분석을 통해 각각 다양한 상태의 어플리케이션 및 서비스별에 대하여 “경고 (Alert) 자동화”를 위한 임계값을 설정에 능숙해야 한다.

⑤ S/W 엔지니어

• 개발/운영 조직의 대다수를 차지하는 S/W엔지니어(혹은 개발자)는 새로운 역할은 아니지만, 이들이야말로 데브옵스 월드의 핵심 역할이다.
• 데브옵스 문화와 원칙을 이해하고 준수하며, 완벽한 팀 정신을 갖고 협력해야 한다. (특히 위의 새로운 역할자들과 함께)
  
  

Play 2: Study the DevOps Practices

두번째 Play에서는 다음의 7가지 프랙티스에 대한 내용인데, 각각의 프랙티스는 이미 잘 알려져 있는 것들이므로 몇 가지 특징에 대해서만 강조하고자 한다.

Configuration Management

여기서의 Configuration Management(CM) 영역은 기존의 구성관리와는 다른 개념이다.
기존 CM이 S/W, H/W를 포함한 시스템 구성요소의 변경 및 버전관리와 변경영향도를 고려한 통제 정책 등 포괄적인 개념이라면, 여기서의 CM은 안전하고 명확한 저장소를 관리하라는 개념이다. Gitflow workflow 정책과 비슷한데 중앙 저장소(마스터)와, Hotfix, Release, Development, Feature 등의 브랜치 Naming, Tagging, Version 에 대한 사용 정책과 오너 등을 정의하여 안전한 사용을 위한 지침을 마련함으로써 개발팀, 유지보수팀, 운영팀이 효과적으로 자원을 접근하며 충돌을 방지할 수 있다.
필요할 경우 각 팀이 어떤 목적별로 소스를 수정하고자 할 때 브랜치와 버전 지정을 자동화함으로써 workload와 팀간의 불필요한 Communication, 혼란도 방지할 수 있다.

Continuous Delivery & Continuous Deployment

플레이북에서 정리한 프랙티스 중 또하나 특이한 사항은 Continuous Delivery와 Continuous Deployment를 분리했다라는 점인데, 이는 우리가 보통 동일 시점으로 취하는 출시와 배포의 행위를 각각 다른 시점에서 처리할 수 있다는 취지로 프랙티스를 분리한 것이다.
즉, 고객이 원하는 시점에 서비스가 동작되도록 하는 것을 출시라고 한다면, 출시에 맞추어 배포가 이루어지는 것이 아니라 지속적이고 자동화된 방법에 의해 미리 배포 되고 출시를 위해 모든 것이 Stand-by되어야 한다는 것이다.
이러한 배포-출시 분리를 위한 방법으로 카나리아 배포 또는 블루-그린 배포 전략 등이 있다. 또한 가능한 테스트가 완료되자마자 자동적으로 배포되도록 한다면, 개발자는 어쩔 수 없이 사람이 개입해야 하는 수동 테스트만 수행하고 그 외의 테스트와 배포를 위한 대기, 확인 작업 등에서 해방될 수 있다. 출시를 위해 IT담당자들이 밤새 야근을 한다던가, 새벽 일찍 출근하는 일은 엄청 줄어들 것이다. 그야말로 데브옵스는 워라밸(WLB : Work and Life Balance)을 위해 꼭 필요한 것이다.

Continuous Monitoring

Continuous Monitoring은 운영과 개발을 이어주는 가교 역할을 한다. 보통은 시스템이 출시되고 나서야 모니터링을 하게 되는데, 이러한 작업의 결과는 대부분 운영팀 내부에서만 공유가 되며 개발팀은 자신들의 결과물이 어떠한 상태인지 잘 모르게 된다. 그러나 데브옵스 월드에서는 운영자가 개발에 깊이 관여하듯이 시스템 모니터링 또한 개발 단계에서부터 이루어져야 한다고 본다. 말그대로 “지속적인” 모니터링이 되기 위해 단 몇 개의 프로그램이라도 개발이 완료되면 모니터링을 시작해야 하는 것이다. 모니터링을 통해 개발자들도 운영에서 요구하는 성능, 보안 규칙을 포함해 시스템이 남기는 로그의 문제 등을 파악할 수 있다. 일부의 경우에 한하겠지만 운영자들은 신규 시스템을 인수하고 나서 개발자가 싸놓은 응가를 치운다고 말한다. 만약 고가의 APM이 개발 단계에서도 주어졌다면 조금은 달랐으리라 본다. 데브옵스 월드에서는 이러한 부분이 필수가 되어야 한다.

Play 3: Assess Your DevOps Maturity Level and Define a Roadmap

평가를 하는 것은 데브옵스 실행을 강화하고 성숙시키는 데 꼭 필요한 일이다. 성숙도 모델은 CMM, CMMI이 일종의 메타 모델이 되어 이미 많은 회사에서 자체적인 모델을 수립하고 내부 조직을 평가하는 데 사용한다. 필자의 조직에서도 작년도에 실험적으로 데브옵스 평가 모델을 만들어 조직별 수준을 진단하였다. 5Plays에서 제시하는 성숙도 모델은 각 프랙티스별로 평가 항목(checklist)이 있고 각 항목의 실행 수준을 진단하여 획득한 포인트의 합계에 따라 Base / Beginner / Intermediate / Advanced / Extrem에 해당하는 성숙도 레벨이 정해진다.

각 프랙티스별 체크리스트가 어떻게 구성되었는지 알아보고 싶다면 데브옵스 플레이북의 pp.44~55을 참고하면 된다.

Play 4: Create a DevOps Pipeline

데브옵스 문화를 위한 원칙의 수립과 학습, 그리고 성숙도 평가 모델을 통해 조직의 로드맵을 수립했다면 이제 데브옵스를 실행할 차례로 드디어 데브옵스 파이프라인을 구축할 수 있다. 데브옵스 파이프라인이란 변경 작업의 결과물을 운영기(Production)으로 이행하는 과정의 워크플로우 자동화를 위해 함께 작동하는 툴과 프로세스 모음이다.

성공적인 파이프라인은 다음과 같은 특징을 가진다. • 빌드, 테스트 및 배포를 자동화한다 • S/W 상태에 영향을 주지 않으면서도 자동화된 프로세스를 통해 인프라 환경을 생성하고 폐기할 수 있다 • DevOps 철학 및 전략을 반영하는 릴리즈 절차를 가진다 • 불변의 인프라를 통해 반복 가능하고 결과를 예상할 수 있는 프로세스로 구성된다 • 전체 파이프라인 워크플로우 단계에 대한 가시성을 제공한다

다음은 데브옵스 파이프라인 구축 예시이다. 구체적인 구축 절차는 조직의 Needs와 역량, 목표 수준에 따라 달라질 수 있으므로 아래의 예시는 참고만 하기 바란다.

데브옵스 파이프라인을 일단 구축하게 되면 이제 그것을 잘 활용하며, 문제가 있는 부분을 개선하여 더욱 효과적인 파이프라인으로 업그레이드될 수 있도록 해야 한다. 이를 위해 다음 Play 5 단계가 필요하다.

Play 5: Learn and Improve through Metrics and Visibility

지속적인 개선을 이루기 위해서는 지금까지 구축된 문화, 조직의 역할, 파이프라인 등에서 구체적으로 어떤 부분이 개선이 필요한지가 파악이 되어야 한다. 문제점을 찾아내고 발견하는 능력은 조직의 역량에 달려 있는데, 이는 곧 앞에서 강조했던 핵심 원칙인 끊임없는 피드백과 학습을 통해서 가능하다.

따라서 지속적 개선 이전에 지속적 학습과 피드백이 촉진되는 환경과 문화를 만들어야 하며, 메트릭을 통해 학습효과와 개선에 대한 가시성과 통찰을 확보할 수 있다.

문화적 메트릭

•  크로스 스킬링 : 팀 간에 얼마나 많은 지식 공유 및 페어링이 존재하는가?
•  집중 : 팀들이 공통의 목표나 목표를 달성하기 위해 유동적이고 집중적인 방식으로 일하고 있는가?
•  프로젝트 기반 팀 : 팀은 기술 집합이 아닌 프로젝트 중심으로 구성되는가?
•  태도 :  팀 구성원이 지속적인 개선에 대해 수용적이고 긍정적인가?
•  측정 기준 수 : 측정기준에 대한 강박관념이 너무 높은 것으로 인식되고 있는가?
•  기술 실험 : 프로젝트 내에서 실험과 혁신의 정도는?
•  팀 자율성 : 팀이 자신의 업무와 업무 관행을 얼마나 성공적으로 관리하고 있는가?
•  보상 : 팀원들이 그들의 일에 대해 감사하고 보람을 느끼는가?

그리고 당연히 데브옵스 프로세스 측면에서도 메트릭을 설정하고 관리해야, 엔터프라이즈 데브옵스 성숙도를 향상시켜 나갈 수 있다.

프로세스 메트릭

• 요구사항 수집 및 관리 프로세스가 있는가 ?
• 신속한 변화를 위한 개발 원칙이 준수되는가 ?
• 소프트웨어 빌드에 일반적으로 발생하는 결함 수준
• 사용 적합성을 판단하기 위해 코드 단위를 테스트하는 정도
• 사용자 인수 테스트 정도
• 제3자에 의한 품질 보증 프로그램
• 프로그램의 안정성과 확장성을 보장하기 위한 성능 모니터링
• 애플리케이션과 로드가 확실히 가능한지 확인하기 위한 클라우드 테스트 여부

마지막으로 다음과 같이 데브옵스 파이프라인용 필수 메트릭을 설정하여 파이프라인의 효과성을 모니터링하고 지속적으로 개선시켜나갈 수 있다.

• 배포 빈도 : 새로운 코드가 고객에게 얼마나 자주 도달하는가?
• 개발에서 프로덕션까지의 리드 타임
- 개발 프로세스의 효율성, 코드 및 개발 시스템의 복잡성, 팀 및 개발 역량을 측정하는 척도가 된다.
- 리드 타임이 너무 길면 개발 및 배치 프로세스가 특정 단계에서 비효율적이거나 성능 병목 현상의 영향을 받는다는 신호이다.
• 고장률 : 시간이 지나도 고장률이 감소하지 않는다면 전체 DevOps 프로세스에 문제점이 있다고 보아야 한다.
• 평균 복구 시간(MTTR) : 실패한 배포에서 복구하는 데 걸리는 평균 시간은?  

에필로그

이상 엔터프라이즈 데브옵스를 위한 5 plays 실천법에 대한 간단한 설명을 끝으로 데브옵스 대탐험의 긴 여정을 마친다.

애자일 퀵가이드의 정리도 그러했지만 데브옵스 역시 이에 대한 많은 토론과 실천법, 전략, 도구 사용법에 대한 산더미같은 자료들에서 데브옵스를 쉽고 올바르게 이해할 만한 자료들을 건져올려 한 줄로 꿰어 일련의 시나리오처럼 엮어 내기에는 필자의 역량이 중과부적임을 여실히 느낀다. 그럼에도 불구하고, 자료를 찾아 정리하는 육체적, 정신적 고통을 감내할 수 있었던 것은 강한 호기심과 애자일 코치로서 사명감? 때문이리라…

덕분에 나태해지려는 갈망을 어르고 달래 자신과 싸움하며 몇 달의 시간을 보내고 나니 이제 데브옵스는 무엇이다라고 말할 수 있 것 같다.

그 사이 “CI/CD를 위한 데브옵스 구현”이라는 오프라인 강의를 하나 들었는데, AWS/Azure 각각의 소스 빌드와 배포를 자동화시키는 툴 사용법에 대한 내용이었다. 이틀간 무언가를 누르고 실행하고 만들고 하는 과정을 정신없이 따라갔는데, 데브옵스 material은 있지만 instruction은 없었다. 아마도 대부분의 데브옵스 관련 교육이 그와 같이 material 위주이고, 어떻게 데브옵스를 잘 할 수 있는지에 대해서는 알려주는 과정은 없는 것으로 안다.
데브옵스 1장에서도 언급했지만, devops라는 용어가 세상에 나온 이후 devopsdays 컨퍼런스가 수백차례 열리는 동안 우리나라에서는 단 한번도 이를 개최하지 않았다는 것은 데브옵스 철학과 문화 및 변화 운동에 대한 이해와 공감이 아직 형성되지 않았음을 반증한다고 보인다. 이제 데브옵스 파이프라인을 만들어 CI/CD를 하고 있다는 사례들이 나오고 있지만 아직은 material 위주의 접근이며, instruction 차원의 접근은 아직 가야 할 길이 멀기에 조금은 안타까운 마음이다.

그런 맥락에서 본다면, 빈약하고 부족한 내용일지라도 이렇게나마 정리를 통하여 올바른 데브옵스 구현 전략을 위한 고민에 한걸음 다가 간 것에 큰 의의를 두면서 수고한 나 자신을 칭찬해본다.

본 블로그의 주된 내용은 다음을 참고하여 작성하였음을 밝힙니다.

• Enterprise DevOps Playbook, O’Reilly

< EOF >