[PART4] 클라우드/데브옵스 - TERMS 03

[ TERMS 03 ]  데브옵스

DevOps를 설명하는 이미지 (출처 : https://tecoreng.com/blog/what-is-devops/)

 

1. 데브옵스(DevOps)의 정의

DevOps를 설명 및 각 단계별로 사용되는 프로그램을 보여주는 이미지 (출처 : https://shalb.com/blog/what-is-devops-and-where-is-it-applied/)

 DevOps : 개발(Development)과 운영(Operations)의 합성어

 

2. 데브옵스는 어디에서 접하게 될까?

 클라우드로 인해 코드로 인프라 관리가 가능해 졌고, 운영의 많은 부분이 자동화 되었다. 데브옵스 엔지니어가 구축한 자동화 파이프라인을 통해 지속적인 통합, 배포, 테스팅, 모니터링을 접할 수 있다. 마이크로서비스 아키텍처(MicroService Architecture)에서도 데브옵스를 쉽게 접할 수 있다.  작은 서비스 단위로 구성된 마이크로서비스는 개발과 운영을 하나의 팀에 두고 유기적으로 협력한다.

 

3. 데브옵스 알아보기

>  등장배경

 요시바 류타로 외 3인은 변화된 소프트웨어 개발의 특징을 다음과 같이 정리했다.

• 사전에 사양을 상세하게 정할 수 없거나 정하는게 의미가 없다.
• 장시간에 걸쳐 100%완성도를 갖는 소프트웨어를 만드는 것보다 TTM(Time To Market)이 우선시되는 경우가 많다.
• 만든 후에도 이용자의 피드백을 받아 가며 기능을 계속 개선해야 한다.

 기존 개발 방법론들은 위 3가지 항목에 대응하기 어려웠고 이에 따라 애자일(Agile) 개발 방법론이 주목 받게 되었다. 애자인 개발 방법론으로 더 빠른 소프트웨어 배포, 더 소소하고 빈번한 소프트웨어 빌드, 새로운 요구에 따른 빠른 개발과 응대가 가능해졌다. 하지만 운영팀이 많은 부하를 받게 되었다. '개발과 운영  사이의 문제'를 고민하던 패트릭 드보이는 2009년 'Devopsdays' 콘퍼런스를 열었고, 거기서 ' DevOps'라는 단어가 처음 사용되었다.

 

>  개념

 "데브옵스는 비즈니스 측면의 가치를 높이기 위해 개발(Dev)과 운영(Ops)의 유기적인 협업(collabooration)을 강조하는 도구, 프로세스, 방법론, 문화, 철학, 전문적 운동 모두를 포괄하는 것이다.

 데브옵스를 이해할 때 유념할 점은 단순히 협업 도구나 기술 정도로 생각해서는 안된다. 데브옵스는 조직의 문화, 사고방식이며 지속적으로 발전하고 개선하는 운동이며 동시에 구성원에게는 일하는 태도이자 습관이다.

 

>  특징

 잦은 개발과 배포는 운영팀에게 큰 부담이며, 개발팀과 운영팀 사이의 갈등 요인이 된다. 데브옵스는 이 두 이해당사자를 중재하며 조직의 공통 비즈니스 가치를 바라보게 하는 역할을 한다.

 '계획(PLAN) ➩ 개발(CODE) ➩ 빌드(BUILD) ➩ 테스트(TEST) ➩ 구현(RELEASE) ➩ 배포(DEPLOY) ➩운영(OPERATE) ➩ 모니터(MONITOR)'에 이르는 소프트웨어 라이프 사이클에서 갭라과 운영이 유기적인 협업 관계임을 잘 보여 준다.

 개발과 운영의 협업을 가능케 하는 요소들이 있다. 카와무라 세이고는 문화를 형성하는 요소와 도구를 형성하는 요소로 나누었다. 문화를 형성하는 요소로는 '목적의식, 공감대, 자율적사고'가 있다. 앞서 데브옵스의 정의에서 언급한 문화, 철학, 전문적 운동과 관련된 것이라고 볼 수 있다.

 도구를 형성하는 요소로는 '추상화, 자동화, 공통화, 지속적 통합, 모니터링'이 있다. 이 요소들과 관련하여 데브옵스에서 자주 언급되는 개념은 코드형 인프라(Infrastructure as Code, IaC), 지속적인 통합(Continuous Integration, CI), 지속적인 배포(Continuous  Delivery, CD), 지속적인 테스팅(Continuous  Testing), 지속적인 모니터링(Continuous  Monitoring), 마이크로서비스 아키텍처(MSA) 등이다. 이 개념과 실천 도구들을 이용해 자동화 파이프라인을 구축한다. 그 결과 개발과 인프라 관리 프로세스는 자동화 및 간소화되고, 요구사항에 대한 신속하고 빈번한 빌드와 배포가 가능해진다.

 

>  장점

 아마존 AWS 웹 페이지에서는 데브옵스의 장점을 '속도, 신속한 제공, 안정성, 확장, 협업 강화, 보안'으로 정리하고 있다. 데브옵스 실천의 관점에서 크게 2가지로 묶어 정리하자면

 첫 번째는 협업강화, 속도, 신속한 제공이다. 마이크로서비스, 지속적인 통합, 지속적인 배포 등으로 인한 효과이다. 작은 서비스 단위의 팀은 개발과 운영이 책임을 공유한다. 커뮤니케이션과 의사결정도 빠르다. 또한 소프트웨어의 통합과 배포가 자동화되어 비즈니스 요구에 빠르게 대응한다.

 두 번째는 안정성, 확장, 보안이다. 모니터링과 로깅, 코드형 인프라, 코드형 정책의 실천 등으로 인한 효과이다. 이러한 자동화는 휴먼 에러(Human error) 가능성을 낮추고 문제 상황에 즉각적이고 유연하게 대응하게 한다. 예를 들어 온라인 쇼핑몰에서 선착순 이벤트 서비스를 갭라 및 배포하여 이벤트 기간 동안 트래픽이 폭증했을 때 코드형 인프라로 간단히 클라우드를 확장해 대처할 수 있다.

 

>  단점

 데브옵스의 가장 큰 단점은 데브옵스를 올바르게 적용하는 것이 쉽지 않다는 것이다. 데브옵스를 잘못 해석하면 여러 역기능이 발생할 수 있다. 개발과 운영이 협업하는 것이 아니라 개발자가 운영까지 하게 될 수도 있다.

 또한 데브옵스의 적용과 실천에는 많은 시간과 비용이 든다. 각종 도구에 대한 비용뿐만 아니라 인력의 역량 향상과 문화 형성에 상당한 비용을 지속적으로 투자해야 한다. 또한 코드를 자주 배포하지 않거나 자동화 도구가 필요 없는 서비스라면 낭비이다.

 

4. 데브옵스를 사용하는 이유

 비즈니스 민첩성이 기업의 경쟁력인 시대이다. 고객이 만족할 만한 경험을 얼마나 빠르게 시장에 내놓느냐가 기업의 지속 가능성을 보장하게 되었다. 이런 상황에서 개발과 운영이 분리된 IT 개발 조직은 사일로 효과(Organizational Silos Effect, 조직의 부서가 협력하지 않고 자기 부서의 이익만을 추구하는 현상) 같은 역기능에 몸살을 앓기도 한다. 데브옵스는 이런 경우에 적절한 솔루션이 될 수 있다. 대표적 사례로는 아마존이 존재한다. 아마존은 조직을 피자 두 판 팀(Two Pizza Team)으로 잘 알려진 마이크로서비스 팀으로 재편했다. 개발과 운영을 한 팀으로 만들어서 그 결과 지속적인 통합과 배포가 가능해졌고, 경쟁사보다 빠르고 민첩하게 서비스를 제공하게 되었다. 또한 아마존은 자체 서비스 개발의 효율성을 높이기 위해 개발한 툴을 상품화하여 AWS DevOps 서비스를 제공하고 있다.

 

5. 데브옵스 사용하기

 데브옵스에서 자동화를 지원하는 도구들을 통칭해 '데브옵스 생태계'라고 부른다.

데브옵스 주기율표 (출처 : https://www.businesswire.com/newsroom)

위의 이미지는 데브옵스 생태계를 이루는 도구들을 한눈에 볼 수 있게 주기율표로 만든 것이다. digital.ai에서 제공하는 정보로서 데브옵스 실무자들의 투표로 선정된 도구들로 꾸며져 있다. 해당 정보는 주기적으로 갱신된다.

 데브옵스 생태계에는 수많은 도구가 있다. 그중 오픈 소스 도구의 예를 데브옵스 툴체인 관점으로 정리하자면

툴체인	도구	내용
계획	redmine	협업 / 일감 관리
개발	git, subversion, eclipse	코드 버전 관리
빌드	maven, gradle, Jenkins	통합 관리(컴파일 / 패키징)
테스트	JUnit, SonarQube, Katalon	정적 분석 / 통합 테스트
릴리즈	docker	컨테이너 관리
배포	kubernetes	컨테이너 오케스트레이션
운영	ANSBLE, CHEF	코드형 인프라
모니터링	kibana, Prometheus, grafana	대시보드 / 로깅 관리

 

6. 데브옵스 더 알아보기

>  DevOps 엔지니어

 데브옵스는 문화, 철학, 전문적 운동이다. 따라서 데브옵스를 단순히 팀이나 엔지니어에 국한한다면 온전한 실현을 기대하기 어려울 것이다. 따라서 기업의 전사적인 참여와 노력이 바탕이 되어야 한다.

 데브옵스 엔지니어는 개발과 운영을 지원하는 역할을 한다. 개발과 운영의 고객이 사용자라면 데브옵스의 고객은 개발과 운영이다. 따라서 데브옵스 엔지니어는 데브옵스 툴체인 관련 지식뿐만 아니라 개발과 운영 양쪽에 대한 충분한 지식과 경험을 보유해야 한다. 때문에 백엔드 개발자가 데브옵스 엔지니어로 전향하는 경우가 많다. 또한 데브옵스 엔지니어는 개발과 운영사이에서 이들의 유기적 협업을 도와야 하기 때문에 소프트 스킬(Soft skills)도 갖춰야 한다.

 

> 함께 알아 두면 좋은 용어

• CI / CD
• 클라우드
• DevSecOps
• Docker
• GIT
• IaC
• 쿠버네티스(Kubernetes)
• MSA