[개발자 필독 추천] 올바른 데브옵스 구축을 위한 7가지 고려사항 (Feat.툴 선택을 잘하자)

SHARE
DevOps의 비즈니스 가치에 대한 이해에 모아졌었던 개발자들의 관심사가 옮겨가고 있다. 바로 어떤 방식을 활용하여 데브옵스을 가장 잘 구현할 것인가에 대한 문제로 말이다. 전자는 정의하기가 크게 어렵지 않았던 반면 후자는 훨씬 어려웠다. 왜? 문제 영역의 수와 종류는 문제 영역마다 크게 다르기 때문이다. 개발팀과 운영팀이 DevOps에 적용할 수 있는 툴의 유형도 크게 다르다.

예를 들어 중앙에서 통제하는 릴리즈는 심각할 정도로 DevOps 및 업무의 효율을 방해할 수 있다. 그러나 차츰 모범 사례가 나오기 시작하고 있으며 대부분의 기업형 DevOps 팀들이 이를 따르는 추세이다. 이러한 모범 사례들은 상식을 뛰어넘어 DevOps가 조직에 무엇을 의미하는지, 그리고 DevOps를 처음 올바르게 만드는 방법의 본질에 도달한다. 대부분의 조직에게 이러한 과정이 새로운 것일거라고 생각한다.

 

데브옵스 모범 모델

만약 DevOps 구축에 관심이 있는 사람이라면 혹은 고려하고 있다면 생각해보아야 할 많은 요소들이있다. 이 구조의 핵심은 자동화 프로비저닝, 자동화 테스트, 자동화 구축 및 구현 등으로 이루어져 있다. 또한 지속적인 피드백을 주고 받을 수 있는 프로세스를 확립하고 정보는 격차를 최소화 하여야 하며 최대한 모든 것이 기록될 수 있도록 노력해야한다.

그림1: 데브옵스는 유기적인 조직이다. 각 단계별로 모범 사례를 참고하고 최고의 기술력을 구현할 수 있도록 노력해야한다. DevOps 구현을 용이하게 만들기 위하여 사용할 수 있는 도구들은 아래에 설명할 것이며 DevOps 도구를 선택하는 고려 사항에 대해서는 7단계로 요약하여 정리하였다.

 

1단계: 개발, QA 및 인프라 자동화 팀의 협업 및 공유 툴 전략을 이해하기

DevOps 팀은 개발, 테스트 및 배포 전반에서 협업할 수 있는 공통 툴을 선택하고 비용을 최소화하는 등의 전략을 마련해야 한다. 툴을 사용하는 것에 대해서 비효율적으로 며칠씩이나 논쟁을 벌이라는 말이 아니다. 개발팀과 운영팀 모두를 위한 DevOps 공통 전략을 수립하라는 말이다. 존재하는 전략은 다음곽 ㅏㅌ다.

  1. 프로세스 전략
  2. 커뮤니케이션 및 협업 계획
  3. 지속적인 개발 도구
  4. 지속적인 통합 툴
  5. 지속적인 테스트 툴
  6. 지속적인 구축 툴
  7. 지속적인 운영 및 CloudOps 툴

툴 전략에 대한 아이디어를 수집했다고 하여 툴 선택이 뚝딱 이루어지는 것은 절대 아니다. 적어도 현 시점(1단계)에서는 그럴 수 없다. 모두가 동의할 수 있고 DevOps를 활용하여 달성하고 싶은 목표를 반영하는 공통 전략을 선택해야 한다는 것을 잊으면 안 되기 때문이다. 툴 선택을 잘못하면 오히려 팀 내부의 의사소통을 방해할 수 있기 때문에 신중을 가해야 한다. DevOps 툴 전략은 팀원간의 원활한 협업과 프로세스 통합을 제공하고, 동시에 공통의 목표 달성에 기여해야한다. 목표는 모든 것을 자동화하는 것이다: 개발자는 모든 팀원의 프로세스를 방해하지 않고도 새로운 소프트웨어를 배포하고 운영할 수 있어야 한다.

 

 

2단계: 툴을 사용하는 이유를 알자: 모든 요청은 기록되어야 한다

DevOps 프로세스 외부에서 임시 작업이나 변경이 발생해서는 안 된다. DevOps 프로세스 내부에서 툴을 사용할 때 새로운 소프트웨어와 변경된 소프트웨어에 대한 모든 요청은 기록되어야 한다. (공유되어야한다) 소프트웨어 진행 상황을 프로세스를 거치는 중에 발생하는 모든 의사결정은 기록되어야 한다는 말이다.

DevOps는 비즈니스 또는 DevOps 팀의 다른 부분에서 발생하는 변경 요청을 수용하고 적용하기까지 일련의 과정을 자동화할 수 있는 기능을 제공한다. 새로운 비즈니스 모델을 수용하고 적용하기 위해 소프트웨어를 변경(수정)하거나, 데이터베이스 접속 모듈의 성능 향상을 위한 요청을 반영하기 위해 소프트웨어를 변경하는 모든 행동이 일련의 예이다.

 

3단계: 툴을 사용함에 따라 처리할 수 있는 자동화 및 DevOps 요청 – 칸반 프로젝트 사용하기

칸반은 진행 중인 업무량 및 팀 역량을 고려하여 개발을 구현하기 위해 사용되는 프레임워크다. 개발 주기 동안 팀들에게 더 유연하게 업무를 계획할 수 있게하고, 더 빠른 산출, 명확한 목표와 투명성을 제공한다. 칸반 도구는 각 팀원이 무엇을 하는지를 파악할 수 있게하고 모든 항목을 서로 공유하여 파악하기 수월한 프로세스를 제공한다. 또한 진행 중인 작업의 양을 적당한 선에서 제한하여 워크 플로우 균형을 유지하고 한꺼번에 너무 많은 업무가 몰리지 않게 한다. 마지막으로 칸반 도구는 업무 흐름을 효율적으로 변화시킬 수 있다. 칸반에서는 하나의 작업 항목이 완성되면, 연속적으로 업무가 처리될 수 있게 도와준다.

 

 

4단계: 업무 툴을 사용하여 수동 및 자동 프로세스 모두에서 로그를 기록하기

자동화 및 수동 DevOps 프로세스의 생산성을 이해하고 DevOps 프로세스가 자신에게 유리한지 여부를 먼저 판단하고 각 전략에 따라 도움이 되는 도구를 선택해야한다. 본 단계를 위하여 두 가지를 생각하자. 첫째, 구축 속도 혹은 발견된 테스트 오류와 같은 DevOps 프로세스와 관련된 매트릭스를 정리한다. 둘째, 자동화된 프로세스를 정의하여 사람의 개입 없이 문제를 해결할 수 있도록 한다. 예를 들어 클라우드 기반 플랫폼에서 소프트웨어 확장 문제를 자동으로 처리할 수 있는 방식 같은 것 말이다.

 

 

5단계: 테스트 자동화 및 데이터 프로비저닝 도구 선택

테스트 자동화는는 단순히 ‘자동화’ 만을 의미하는 것은 아니다. 코드와 데이터를 취하여 보편적인 테스트를 꾸준히 실행하여 코드의 품질, 데이터 및 전체 솔루션를 보장할 수 있어야하는 기능이다. DevOps의 경우 테스트는 연속적으로 끊임없어야 한다. 코드와 데이터를 프로세스에 투입할 수 있다는 말은 코드를 샌드박스에 넣고, 테스트 데이터를 애플리케이션에 할당하고, 완료되었을 때 자동으로 코드를 DevOps 프로세스로 투입하거나, 재작업을 위해 개발자에게 반환하는 수백, 수천 개의 테스트를 무한 루프로 반복할 수 있어야 한다는 말이며 이를 위한 적절한 협업 툴을 팀 내에서는 결정하고 사용해야한다.

 

 

6단계: 각 배포에 대한 테스트

테스트 과정에서는 인프라, 애플리케이션, 데이터 및 사용할 테스트 제품군에 대한 허용 수준에 대한 기준을 명확히하고 각 배포별로 승인 여부에 대한 기준이 팀 내에서 있어야한다. 선택한 툴의 경우 DevOps 테스트 프로세스를 담당하는 사람들은 허용 테스트에 대한 기준을 정의하고 테스트 결과물이 허용 기준을 충족하는지 확인하는 데 노력을 기해야한다.

물론 이러한 테스트는 개발이나 운영 상황에 의해 언제든지 변경될 수 있다. 애플리케이션이 시간이 지남에 따라 혁신적으로 변화함에 따라서 소프트웨어에 새로운 변경 사항을 적용해야 하며, 이러한 변경 사항에 대해 세분화하여 테스트해야 한다. 상황을 예로 들자면 특정 유형의 데이터에 관한 보호, 관련된 규정 준수 문제 또는 성능 문제에 대한 변경 사항을 테스트하여 기업이 서비스 수준을 충족하는지 확인해야 할 수 있다.

 

 

7단계: 팀 간의 지속적인 피드백을 통해 정보 격차 최소화하기.

마지막으로, 문제가 있는 테스트와 선택한 툴에서 프로세스를 지원해야 하는 테스트 간의 통신을 자동화하려면 [피드백 루프]가 필요할 것이다. 협업 툴을 올바르게 사용하고 있는가에 대한 질문에 답하려면 아래의 질문에 대해 고민해 보아야 한다.

  1. 수동 또는 자동화된 매커니즘을 사용하여 문제를 식별하고 있는가?
  2. 개발자나 운영자가 무엇이 발생했는지, 왜 발생했는지, 그리고 어디에서 발생했는지 이해할 수 있도록 태그를 적절하게 사용하고 있는가?
  3. 툴 사용이 협업 및 피드백 루프 내의 모든 커뮤니케이션을 정보격차가 없도록 도움을 주고 있는가?

여기에는 팀원 전원이 공동으로 문제를 해결하기 위한 접근법, 적용해야 할 해결방식에 대한 합의, 필요한 추가 코드 또는 기술의 목록이 포함되어야 한다. 그런 다음 자동화된 테스트, 자동화된 배포 및 자동화된 운영을 통해 해결되었는지 여부를 보고하기 위해 툴은 제대로 된 역할을 하고 있는가 파악하는 것도 빠질 수 없다.

 

 

 

그림 2: 데브옵스를 위한 툴 별 정리 ,단계/카테고리 별 툴 분포

툴은 너무나도 많고 어떤 것을 선택해야 하는가 혼란스럽다. 다 거기서 거기처럼 보이니… 그러므로 카테고리와 필요한 기능에 초점을 맞추어 취사선택할 수 있도록 한다. 그렇다면 좋은 툴은 어떤 사고를 거쳐 선택할 수 있는가?

 

 

주요 협업 툴별 카테고리

주요 협업 툴을 나눌 수 있는 업무 범주를 아래 나열해보았다.

  • 버전 컨트롤: 수동으로든 자동으로든 소프트웨어 버전을 릴리즈 별로 추적하는 도구. 이는 버전 넘버링을 하는 것 뿐 아니라 데이터베이스의 유형, 브랜드 및 버전, 운영 체제 세부 정보, 심지어 필요한 물리적 서버 또는 가상 서버 유형과 같은 구성 및 인프라를 명시하는 것을 의미한다. 본 카테고리는 변경 관리 툴과 관련이 있다.
  • 코드 빌딩/구축: 지속적인 개발 및 통합, DevOps 프로세스 전반에 걸쳐 소프트웨어 구축 및 구축을 자동화하는 툴
  • 기능 테스트: 자동화 테스트가 용이한 툴. 테스트 툴은 통합 단위 및 성능과 보안 테스트를 제공할 수 있어야 한다. End-to-end 자동화가 목표!
  • 프로비져닝/변경사항 관리: 소프트웨어 배포에 필요한 플랫폼을 프로비저닝하고, 구성, 데이터 또는 소프트웨어에 발생하는 변경 사항을 모니터링. 이러한 도구들은 최악의 상황에 시스템을 전의 상태로 되돌릴 수 있도록 도와준다.

 

덜 복잡해야 더 잘 개발할 수 있다

DevOps를 위한 올바른 도구를 선택하는 것은 많은 변수를 고려해야 하는 일이다. 이러한 도구들은 늘 변화하고 새로워서 대부분의 기업 개발팀에게는 생소하게 느껴질 수 있다. 그러나 이 글의 설명을 단계별로 꼼꼼히 읽어보고, 개념으로서 DevOps의 목표를 명확히 할 수 있다면 DevOps 프로세스를 구축하는데 도움이 될 것이다.

향후 몇 년 동안 기업이 지속적으로 겪게 될 변화를 고려하고, 어떤 것이 효과가 있고 어떤 것은 개선되어야 하는지에 대한 툴 사용을 지속적으로 평가할 준비가 필요하다면 다양한 도구의 이점을 살펴볼 수 있는 팀내 TF를 만들어 보는 것도 도움이 될 수 있다. 이를 통해 DevOps를 더 잘 수행하는 방법을 지속적으로 실험해보고 DevOps 운영을 모니터링해야한다.

 

DevOps 공부는 어디서? 

인프라 구축을 위해서 공부하는 많은 개발자들을 위하여 적합한 많은 온라인 강의 중 패스트캠퍼스 온라인의 강의는 어떤가? AWS & Docker 클라우드 서버 구축 올인원패키지를 통해 인프라 개발자로 거듭나보자.

 

 

본문은 7 steps to choosing the right DevOps tools (https://techbeacon.com) 의 내용을 번역 및 발췌하여 작성하였습니다.

Facebook Comments