devops

DevOps의 소개와 필요성을 정리 한다. --

Contents

DevOps는 개발(development)와 운영(operations)의 합성어로 소프트웨어 개발자와 IT 전문가, 운영자간의 원할한 통합과 협업, 커뮤니케이션을 위한 소프트웨어 개발 방법론이다. DevOps는 기존에 분리되어 있던 소프트웨어 개발과 IT 운영조직을 압축해서 협업하게 만들어서 신속한 소프트웨어 개발과 좋은 서비스를 제공하는 걸 목적으로 한다.

http://upload.wikimedia.org/wikipedia/commons/thumb/b/b5/Devops.svg/400px-Devops.svg.png

DevOps는 최적화된 소프트웨어 개발과 배포 그리고 품질 관리를 위한 사람과 공정(process), 정책, 툴 들의 총합이다. DevOps는 단일 솔류션, 툴이 아닌 그 자체가 목적인 통합적인 활동을 의미한다. 이 활동의 가장 중요한 요소는 품질과 자동화다. 이들 주요 요소들을 달성하기 위해서 신중하게 툴을 선택하고 적절한 문화를 선택한다. DevOps에서 지향하는 문화는 소프트웨어 개발팀과 운영에 참여하는 모든 구성원들 사이에 장벽을 제거 함으로써 열린 의사소통이 가능하게 하는 환경을 만드는 것이다. DevOps는 ITIL, ITSM과 같은 자동화 계획과 비교할 수 있겠는데, 자동화와 관련된 영역만 비슷할 뿐이다. DevOps는 문화다.

개발 -> 테스트 -> 배포 까지의 과정을 압축해서, 빠르게 배포한다. 주의 할 것은 과정을 압축하는 거지, 건너뛰는게 아니라는 점이다. 테스트 100개 할 걸 10개로 줄여서 배포까지의 과정을 줄이는게 아니다. 품질을 희생해서 빠르게 배포하는게 아니다.

품질에 대한 요구사항은 그대로인 상태에서 배포까지의 과정을 줄이기 위해서는 아래의 활동이 필요하다.

1. 코드 통합, 빌드, 테스트를 짧은 주기로 하고, 그 과정을 자동화 한다.
2. 필요한 때, 필요한 기능을 가진 서비스를 빠르게 배포한다.

1은 개발관점의 활동이다. 폭포수방식의 경우 각 컴포넌트(혹은 기능)개발자들이 크게 개발을 한 후(다른 말로 오랜시간) 다른 컴포넌트들과의 통합을 하는 방식으로 개발을 진행한다. 통합 작업기간에는 테스트와 개발이 지속적으로 이루어지는데, 작업 했던 기능과 코드의 양이 많다 보니 무리없이 통합하는게 매우 힘들었다. "어.. 원했던 기능이 이게 아니었는데 ? 리턴 값이 왜 이래요. 프로토콜이 틀리잖아요 !?. 이 기능은 왜 빠졌나요."... 테스트 -> 회의 -> 개발 -> 회의 -> 테스트 -> 개발 이런 상황 한번쯤 경험해 봤을 거다.

DevOps는 개발한 내용을 지속적으로 통합하고 테스트 해서, 문제를 조기에 발견해서 처리 하는 방식을 사용한다. 리스크를 분산하는 정책인 셈이다. 개발 -> 빌드 -> 테스트의 과정을 거의 일단의로 수행하며, 전 과정이 자동된다. 개발자는 자신이 개발한 코드를 중앙 저장소에 지속적으로 저장을 하고, 빌드 시스템은 코드를 통합하고 빌드해서 테스트 결과를 자동으로 레포팅한다. 이렇게 하면 적은 노력과 적은 비용으로 초기에 결함을 찾아서 해결할 수 있다. 결과적으로 품질 향상에 도움을 준다.

2는 운영관점의 활동이다. 이 활동은 두개로 이루어진다. 첫 번째 활동은 빠르게 배포하는 것이며이게 목적이다. 두번째 활동은 목적을 달 성하기 위한 활동으로 필요한 때, 필요한 기능을 포함한 서비스를 설계다.

통합을 하고 테스트를 통과했다고 해서 서비스 수준의 품질이 보장되는 것은 아니다. 테스트 시나리오를 정밀하게 관리하는 것으로 기본적인 품질을 유지해야 겠지만 결국 품질은 운영단계에서 확인할 수 있다. 운영단계가 되어야만 품질을 확인할 수 있다는 것은 굉장히 위험한 발상이라고 생각할 수 있겠다. 하지만 이건 피할 수 없는 현실이다. 아무리 완벽하게 프로그램을 만들고 테스트를 하더라도 운영단계에서 품질 문제가 발생하는 건 막을 수 없다.

그렇다면 애초에 문제 발생 여지를 없애면(줄이면)된다. 추가되는 기능을 줄여서 소프트웨어의 복잡도를 낮추는 거다. 거함거포주의를 버리고, "회사의 아이디어를 빠르게 서비스의 기능으로 구현하면" 된다. 이렇게 하려면 의사결정 과정이 단순하고 빨라야 하며, 무엇보다 개발자와 운영자가 서비스에 대한 실질적인 권한을 가지고 있어야 한다. 수평적인 조직이 되어야 한다는 이야기다. 요즘엔 수시로 배포되는 것은 요즘엔 그리 낯설은 광경도 아니다.

통합과 배포를 위해서는 소스코드 형상관리 와 빌드 & 테스트, 배포를 위한 세 가지 범주의 툴이 필요하다.

Git을 이용해서 소스코드들을 통합 하고 jenkins로 통합된 소스코드를 빌드 하고 테스트 한다.

개발, 통합, 테스트, 인프라 운영, 서비스 운영에서 발생하는 이슈들을 모두 추적한다. 이슈추적 시스템은 첫번째 목적은 이슈의 빠른 해결, 이슈 처리에 대한 지식 축적에 있을 것이다. 이 외에 DevOps 관점에서 "이슈를 중심으로 개발, 운영, 테스트 등 모든 조직을 통합"하는 중요한 역할을 한다. 서비스 운용을 예로 어떻게 이슈시스템으로 각 팀이 통합될 수 있는지 살펴보자.

서비스 운영팀은 고객접점에 있다. 이들은 고객으로 부터 메일, 고객 게시판, 앱에 내장된 버그 리포팅 기능등을 이용해서 고객으로 부터 정보를 수집한다. 수집한 정보는 적절히 처리하고 그 결과를 고객에게 알려줘야 한다. 이를 위해서는 서비스 운영팀, 개발자, 테스터, 시스템 운영팀의 협업이 필요하다. 이슈 시스템을 이용해서 이들을 묶어보자.

1. 고객이 APP에 내장된 서비스 문의 기능을 이용해서, 요구사항을 전송한다.
2. APP은 Jira API를 이용해서 티켓을 Open 한다. APP은 session id를 함께 전송하는데, 이 session id를 이용해서 API 호출권한과 고객의 Email 정보 등을 확인할 수 있다.
3. 서비스 운영자는 티켓의 내용을 읽어서, 직접처리할 수 있는 이슈인지를 판단한다. 직접 처리할 수 있다면 티켓은 Resolve 한 후 Close 한다. 물론 고객에게는 처리 메시지를 보내야 한다.
4. 운영자가 처리할 수 없는 이슈는 각 팀에 할당한다.
5. 할당 받은 팀은 팀내에서 업무를 다시 할당 한다.
6. 문제를 해결하고 Resolv한다.
7. 서비스 운영자는 문제가 해결 됐는지를 확인한다. 필요할 경우 품질 관리 팀에 이슈를 재 할당해서 테스트를 요청할 수 있다.
8. 유저에게 메일을 보내고 Close 한다.

이슈를 해결하기 위해서 티켓이 흐르는 과정에서 각 팀원들이 자연스럽게 의사소통을 하게 된다. 초반에는 티켓을 기반으로 하는 의사소통이 어색할 수도 있겠지만, 몇 번 사이클을 돌다보면 자연스럽게 정착 된다. 이 과정에서 각 팀은 다른 팀의 성향들 그러니까, 서비스에서 어떤 역할을 하고 있는지, 어떤 일을 할 수 있는지(혹은 할 수 없는지), 역량은 어떤지, 어떤 식으로 일을 돌려야 효율적인지에 대한 노하우를 쌓을 수 있다. 결과적으로 서비스 품질을 높이는데 큰 도움이 된다.

이슈추적 시스템은 모니터링과도 통합되야 한다. 모니터링 결과 발생한 모든 이슈는 Jira 티켓으로 발행한다. 시스템 운영자는 아래 정책에 따라서 티켓을 처리해야 한다.(정책은 환경에 따라 달라질 수 있다.)

• Deliberate : 심사숙고하다.
• approach : 접근하다.

• DevOps -- wikipedia

제목	저자	변경일