DevOps Devops & Culture

DevOps 도입을 위한 도구 소개

시작하며…

현재 제가 몸 담고 있는 IT조직은 고객의 요구사항을 수용하여 개발을 수행하는 소프트웨어 개발자(Dev)와 이런 개발이 적용 된 시스템을 운영하는 운영자(Ops)로 조직 내 Role이 명확하게 나누어져 있습니다.
늘 그렇듯 개발자는 고객의 요구사항에 맞는 새로운 기능을 만들어 배포하고자 하지만, 운영자는 최대한 현재의 레거시 시스템을 변화없이 안정적으로 운영하기를 원합니다.

시대의 흐름은 Agile 방법론의 물살을 타 개발 사이클이 빨라지고 빈번하게 릴리즈 하는 것이 대세가 되었지만 정작 IT조직은 전통적인 구조에 의해 개발자와 운영자간의 대립이 발생할 수 밖에 없습니다.

그래서 등장한 것이 바로 DevOps의 개념입니다.
DevOps는 문자 그대로 개발(Development)과 운영(Operation)의 합성어로, 시스템 개발과 운영을 병행하거나 혹은 개발자와 운영자가 상호 협력해가면서 비지니스의 가치를 실현하는 개념으로 별도의 방법론이 있는 것은 아닙니다.
DevOps는 개발과 운영 간의 협업이 굉장히 중요한데, 개발자와 운영자 간의 Role과 그에 따른 성과가 명확하게 분리된 IT조직이라면 크고 작은 장애 하나하나에 민감하게 반응하며 서로를 질책하려 들 수 도 있습니다.
그렇다면 우리는 어떻게 DevOps의 개념을 기존의 IT 조직에 적용해 나아갈 수 있을까요?

DevOps의 도구

DevOps의 적용은 크게 조직적인 측면도구 도입 측면으로 나누어 볼 수 있는데 조직적인 측면은 한마디로 요약하자면 Agile 방법론을 적용한 것입니다.
(Agile 방법론에 대해서는 Mark님이 훌륭하게 연재해 주실 예정입니다.ㅎ )

오늘 제 글의 목적은 DevOps 도입을 위해 필요한 도구들과 도구도입 절차에 대한 소개입니다. 사실, 오늘 소개되는 도구들은 DevOps 떠나 기본적으로 대규모 시스템을 개발 운영하는 조직이라면 이미 사용 중인 도구 일 것이라고 생각합니다.
다만, 이 글을 읽는 분들이 현재 몸담고 있는 조직에서는 어떠한 도구를 사용 중인지, 그리고 도입된 도구를 제대로 활용하고 있는지 진단해보고, 앞으로 어떠한 도구를 추가로 도입하여 활용하면 좋을지 생각해보면 좋을 것 같습니다.

도구 도입은 좋은 툴이라고 마구잡이로 적용할 순 없습니다. 도구를 도입함에 있어 도구들 간의 전후관계 및 의존관계가 존재하기 때문입니다.

1.버전관리 도구

앞에서도 이야기 했듯이 DevOps도입을 떠나 버전관리를 하지 않는 IT조직은 없을 것이라 생각합니다. 고객의 새로운 요구사항을 수용하고 반영하기 위해 우리는 빈번하게 소스코드를 수정합니다.
따라서 언제, 누가, 어떤 이유로, 어떤 수정을 했는지 추적 관리 할 수 있어야만 합니다.

  • 버전관리 도구의 종류 : Git, Subversion

특히 테스트 자동화나 지속적 통합(CI)는 버전 관리 시스템에 강하게 의존하기 때문에 버전 관리 시스템이 제대로 정착하지 못한다면 이후 도구를 도입하는 것은 의미가 없습니다.

2.프로젝트 관리도구

이 역시도 대부분의 IT조직에서 도입해서 사용 중일 것이라 생각합니다. 고객의 요구사항과 발생 이슈에 대한 관리를 위해 누구나 해당 내용 및 진척도를 확인 할 수 있어야 합니다. 만약 우리가 이를 엑셀파일로 관리하여 메일 등으로 주고받는다면 실시간으로 갱신이 어려울 뿐만 아니라 중간에 누락 건이 발생할 수도 있습니다.

이러한 문제를 해결하기 위해서 우리는 프로젝트 관리도구를 도입하여 사용합니다.

  • 프로젝트 관리도구의 종류 : GitHub의 Issue, Redmine, JIRA

현재 제가 몸담고 있는 조직을 예로 들까요?
현재 저희 부서는 JIRA를 사용하여 개발 과제 별로 티켓을 발행합니다. 발행된 티켓으로 해당 과제에 대한 개발 기한, 이슈 내역, 진척사항들을 실시간으로 공유합니다. JIRA Dashboard를 활용하여 관련된 모든 사람들이(개발자,운영자,고객) 프로젝트의 전체적인 상황을 빠르고 쉽게 한눈에 파악할 수 있습니다.
또한 버전 관리 시스템과의 연계 설정을 통하여 버전관리시스템(svn)으로 소스코드를 커밋 할 때 JIRA 티켓 번호를 포함함으로써 어떤 과제번호로 인하여 누가,어떤 변경을 했는지 추적관리를 가능하게 합니다.

3.테스트 자동화 도구

DevOps를 적용하면 빈번하게 기능이 추가되고 릴리즈가 발생하게 됩니다. 따라서 릴리즈 때마다 시스템 내 기능들이 정상적으로 동작되고 있는지 테스트를 통해 검증해야하는데, 시간이 많이 소요될 수 밖에 없습니다. 테스트에 할당되는 시간이 많아지면 당연히 개발 속도도 느려질 수 밖에 없습니다. 혹은 한정된 시간 내에서 기한을 맞추느라 개발코드에 잦은 휴먼오류들이 발생할 수 있는 원이 되기도 합니다. 따라서 효과적 개발을 위해 테스트 자동화 도구를 도입하는 것을 고려해 볼 수 있습니다.

  • 테스트 자동화 도구 : JUnit, PHPUnit, Selenium, AntBot

JUnit이나 PHPUnit 유닛 테스트 도구를 활용하여 소스 수정 발생 시 관련 소스들에 대한 단위 테스트를 자동화 할 수 있습니다. 다만, 시스템 화면에서부터 발생되는 통합 테스트를 수행하기는 어렵습니다.
그래서 Selenium과 같은 웹앱 테스트 프레임워크를 사용하여 테스트를 자동화 하기도 합니다. 그러나 Seleninum 역시 라이브러리의 동작 테스트와 같이 GUI에 의존하는 테스트는 수행하기 어려울 수 있습니다.
따라서 최근에는 RPA 솔루션을 이용하여 테스트를 자동화하기도 합니다. 제가 몸담고 있는 조직에서는 AntBot이라는 RPA 솔루션을 이용하여 테스트 자동화에 활용하고 있습니다. 특히, 매일 아침 시스템의 주요 기능들을 자동화하여 점검하고 테스트 결과를 관련 직원 모두에게 발송해 줍니다.

4.지속적 통합 도구

앞의 도구들을 도입했다면 그 다음으로 도입해야 하는 도구는 지속적 통합 도구입니다.
지속적 통합(CI : Continuos Intergration이란 자동화된 빌드 및 테스트가 수행 된 후, 코드 변경 내역을 레파지토리에 정기적으로 병합하는 DevOps 소프트웨어 개발 방식입니다.

  • 지속적 통합 도구 : Jenkins, Hudson, CircleCI

지속적 통합 도구는 버전 관리 시스템과의 연결을 통해 레파지토리에 커밋되어 있는 소스코드를 추출하여 빌드 도구로 빌드를 실행하고 자동화된 테스트를 수행합니다.
즉, 개발자가 소스를 커밋 시 주기적으로 소스코드를 폴링하여 자동으로 빌드부터 테스트까지 수행하여 결함여부를 확인 할 수 있어 조기에 이를 발견하고 해결할 수 있게 합니다.

5.가상 환경 구축 도구

앞서 언급된 도구들은 어떻게 보면 소프트웨어 개발 프로세스의 개선이라는 관점에서 도입되는 도구들이라고 볼 수 있습니다. 그런 관점에서 가상 환경 구축 도구는 개발 프로세스적인 측면보다는 환경 구축 프로세스 개선이라는 관점으로 접근하여 도입되는 도구입니다.

  • 가상 환경 구축 도구 : Vagrant, Virtualenv, Docker
출처 : https://hamait.tistory.com/871

위에 언급된 가상 환경들은 도구의 측면에서 보자면, 모든 개발자들에게 동일한 개발 환경을 제공할 수 있습니다. 특히 각자의 환경을 수작업이 아닌 자동화를 통해 빠른 시간 내에 오차 없이 구축 및 제공 될 수 있게 하죠.
예를 들면, 개발 환경에서는 동작하던 코드가 테스트 환경에서는 동작하지 않는 상황이 발생할 수 있습니다. 이러한 문제를 방지하기 위해 우리는 환경 구축 초창기에 환경을 가상화 해둠으로써(머신 이미지를 생성해둠) 이를 모두에게 배포하여 동일한 환경에서 개발, 테스트를 수행할 수 있게 합니다.

6.프로비저닝 도구

시스템 개발 환경에서는 개발 환경, 테스트 환경, 운영 환경 같은 다양한 환경이 존재합니다. 이러한 환경을 설치 문서에 기반을 두고 수작업으로 작업하려면 상당히 많은 시간이 소요되기 마련입니다. 따라서 앞서 언급된 가상 환경 구축 도구를 통해 생성한 동일한 환경 이미지를 프로비저닝 도구를 통하여 자동화하여 인프라 구축할 수 있습니다.

  • 프로비저닝 도구 : Ansible, Chef

7.모니터링 도구 도입

개발 사이클을 줄이고 빈번하게 기능을 배포할 수 있게 되면 마지막으로 중요한 것은 모니터링입니다. 어떠한 시스템을 운영중인 조직이라면 당연히 모니터링은 필수로 수행 중일 것입니다.

  • 모니터링 도구 : Sensu, Zabbix, Nagios, Bmon

모니터링을 통해 장애 발생여부를 확인할 뿐만 아니라, 더 나아가 다양한 데이터를 얻어 개발프로세스의 문제, 인프라 구성의 개선 포인트를 찾아 개발 사이클에 대한 피드백 뿐만 아니라 추가 개선이 필요한 기능을 찾기도 합니다.

마무리

이렇게 DevOps 적용을 위해 도구들을 용도에 따라 분류하고 정리하는 글을 쓰고 나니, 저 역시도 무의식적으로 사용하던 다양한 도구들에 대하여 다시 한번 생각해보게 되었습니다.

현재 저희 조직에 도입된 도구들 역시 올바르게 정착되어 사용되고 있는지, 효과를 보고 있는지 차근차근 집어볼 필요가 있는 것 같습니다.

유행한다고 무조건 새로운 도구를 도입할 이유는 없습니다.
모든 변화에는 기회비용이라는 것이 발생하기 마련입니다.
따라서, 현재 조직에 도입된 도구들이 올바르게 정착되어 사용되고 있는지, 그리고 효과를 보고 있는지 차근차근 집어봐야합니다. 이후에 현재 수행되고 있는 개발 프로세스에서의 문제점이 있는지 고민해보고, 필요한 추가적인 도구가 무엇인지, 해당 도구를 도입했을 때의 장단점과 소용되는 비용과 시간들을 꼼꼼하게 따져볼 필요가 있습니다.

Reference

도서 : 서버/인프라 엔지니어를 위한 DevOps

https://happystory.tistory.com/89

https://hamait.tistory.com/871

댓글 남기기

이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.

%d 블로거가 이것을 좋아합니다: