[IT/개발] DevOps, 개발과 운영의 새로운 문화

[IT/개발] DevOps, 개발과 운영의 새로운 문화

2012년6월20일

출처: http://dev.paran.com/2012/06/20/devops-new-trend-in-developement-and-operations/

DevOps, 개발과 운영의 새로운 문화

kth DevOps팀 김동수

요즘 IT 관련 아티클에 새롭게 그리고 자주 등장하는 단어로는, NoSQL, Cloud, Big Data 그리고 DevOps 등이 있습니다. 이 글에서는 그 중 개발과 운영에 있어 중간적인 입장에서 역할을 수행하는 방법론인 DevOps 에 대해서 이야기 하고자 합니다.

DevOps 에 대해서 이야기 하기에 앞서, DevOps 를 소개하는 자료에서 자주 등장하는 3개의 서비스를 간단히 살펴 보겠습니다.

Netflix 는 미국에서 BlockBuster 라는 거대한 오프라인 영화 렌탈 체인을 함몰시킨 VOD 회사로 이 많은 트래픽을 감당하기 위해 AWS 에 10,000개 이상의 인스턴스를 10명의 DevOps 팀으로 운영하고 개발을 지원하고 있습니다.

Flickr 는 2004년 2월부터 서비스 하고 있는 사진 중심의 SNS 서비스로, 초당 40,000 장의 사진이 업로드 되고 있습니다. 거의 모든 것을 자동화하고, 개발과 운영 각자만의 문화를 바꾸어, 서로 협력하여 하루에도 10번씩 배포할 수 있도록 하였습니다.

fotopedia 는 2006년 파리에서 설립된 20여명의 직원으로 구성된 기업으로, 인간 중심의 사진 이라는 모토로 flickr 와 Wikipedia 를 섞어 놓은 서비스를 제공하고 있습니다. 일일 1억 5000만의 페이지뷰를 보유하고 있습니다. AWS 클라우드에 시스템을 구축하여 1개의 MySQL DB 와 4개의 MongoDB Cluster 로 운영되고 있으며, 매일 평균 3개정도의 hot-patch 를 배포하고 있습니다.

이들 서비스를 제공함에 있어 공통적으로 개발과 운영에 적용한 방법론이 DevOps 입니다. 위의 세 서비스 이외에도 DevOps 방법론을 적용하고 서비스 하는 곳은 점점 더 많아지는 추세입니다. 그럼 DevOps 에 대해서 좀 더 자세히 이야기 해 보겠습니다.

“DevOps” 는 무엇인가?

IT 에 몸을 담고 있는 분이라면 “DevOps” 라는 단어만 보더라도 무엇이 합쳐져서 만들어진 용어인지 쉽게 짐작할 수 있을 것입니다. 짐작되는 대로 Development (개발) 와 Operations (운영) 의 두 단어가 합쳐진 합성어입니다.

영문 Wikipedia 에서는 DevOps 를 다음과 같이 정의하고 있습니다.

DevOps라는 합성어는 소프트웨어 개발자들과 IT 종사자들 사이의 의사소통, 협업, 융합을 강조한 소프트웨어 개발 방법론이며, 소프트웨어 개발과 IT 운영간의 상호 의존관계에 대한 산물이다. DevOps 는 조직에서 소프트웨어 상품과 서비스를 신속히 생산하는 것에 도움이 되는 것을 목적으로 한다.

즉, 소프트웨어를 만들어 내는 개발자, 잘 동작하도록 운영하는 운영자, 그리고 그 소프트웨어의 품질을 관리하는 품질관리 조직 개발조직이, 소프트웨어를 개발, 빌드, 테스트, 배포, 운영에 이르는 사이클을 신속하게 진행할 수 있도록, 업무 프로세스를 정의하고, 각 조직간의 역할을 조율하고, 그 프로세스들을 자동화하여 효율적으로 운영되도록 하는 역할과 방법론을 DevOps 라고 할 수 있습니다.

< devopsdays 2009, from http://devopsdays.org/ >

DevOps 용어는 2009년 벨기에에서 시작되어, 인도, 미국, 브라질, 오스트리아, 독일, 스웨덴 등지에서 개최되고 있는 “Devops Days” 행사로부터 보급되기 시작했습니다.

< devopsdays 2012 사이트>

이 행사는 2009년 이후 해마다 세계 여러 나라에서 개최되고 있으며, 2012년에는 일본의 도쿄, 호주의 시드니, 미국의 마운틴뷰, 인도, 이탈리아에서 개최됩니다. 6월 28~29일 마운틴뷰에서 DevOps Days Mountain View 2012 행사가 열리고, 저희 DevOps 팀에서도 참석할 예정입니다.

“잦은 배포의 효과”

DevOps 를 이야기 하면서, 애자일 방법론이 빠질 수는 없습니다.

그 이유는 다음의 그림에서 애자일과 워터폴 방식에서의 위험도의 변화차이로 설명할 수 있습니다.

<잦은 릴리스로 인한 위험의 하향 균등화, from http://en.wikipedia.org/wiki/DevOps#Devops_Days>

애자일 방법론을 적용하면 작게 그리고 잦은 릴리즈를 하게 되어, 변경되는 범위가 작아지므로, 릴리즈에 따른 위험도가 낮게 균등해 집니다. 반면에, 전통적인 워터폴 방법론을 적용하는 SI 프로젝트와 같은 경우 긴 텀을 두고 한번에 여러 기능을 개발하고 배포하므로 그 추가되는 기능만큼 위험도가 크지게 됩니다.

이렇게 잦은 주기로 반복적으로 배포를 매끄럽게 수행하기 위해서는 만족되어야 하는 것이 있습니다. 첫째, 잦은 개발과 버그 픽스를 할 수 있고, 공유할 수 있는 소스코드 버전 관리 시스템이 있어야 합니다. 이것이 없다면, 동시에 여러 버전을 운영하는 환경에서는 잦은 개발을 할 수 없게 됩니다. 둘째, 빌드, 테스트, 배포 단계를 가능한 한 자동화 해야 합니다. 빌드, 테스트, 배포 단계를 수작업으로 하게 된다면, 실수가 있을 수 있고, 각 단계마다 많은 시간이 반복 소요되므로 효율이 낮아지므로, 자동화를 통해 효율성을 확보해야 합니다. 그리고, 셋째 서비스를 개발하는 개발 조직과 운영해 가는 운영조직간의 매끄러운 협업이 필요합니다.

“개발과 운영 조직”

<Wall of Confusion, from http://dev2ops.org/blog/2010/2/22/what-is-devops.html>

잦은, 반복적인 배포를 하기 위해서는 개발과 운영의 협업이 매우 중요합니다.

개발자는 새로운 기술을 소프트웨어에 적용해서 개발하고, 실험하고, 배포하길 원합니다. 반면, 운영자는 잘해야 본전이므로, 서비스는 절대 멈추어서는 안되기 때문에 서비스의 안정성에 우선하여 보수적인 입장에서 접근하게 되는 서로간의 장벽이 존재합니다. 물론, 각자의 역할을 충실히 임하고 있으니, 어느 누가 잘못된 것은 아닙니다.

규모가 아주 큰 금융이나 통신 SI 프로젝트 인 경우 배포해야 할 시스템도 많고, 개발할 요구사항 목록도 적게는 수백에서 수천 라인을 넘어가는 프로젝트에서는 개발자와 운영자는 각자의 명확한 역할 분담과 함께 책임이 주어져야 합니다. 그러나, 잦은 배포를 하는 인터넷 서비스와 모바일 서비스를 하는 조직에서도 한정된 리소스 내에서 위와 같이 각자의 역할을 분담해서 개발자는 개발만, QA 조직에서는 테스트만, 운영 조직에서는 운영에만 한정되도록 역할을 분담하여 서비스를 운영한다면, 조직간의 시너지를 얻을 수 없고 자원 낭비와 품질에 문제를 가져올 수 밖에 없습니다.

운영자는 서비스하는 어플리케이션에 대한 아키텍처와 데이터저장소, 프레임웍, 프로세스에 대한 이해를 가져야 하고, 개발자 또한 어플리케이션이 돌아가고 있는 서버와 클라우드 환경에 대해서 이해를 하고 있어야 합니다.

그럼, 이 글의 처음에 소개된 3개의 인터넷 서비스 중 Flicker 에서는 어떻게 두 조직을 융합하고 있는지 예를 들어 보도록 하겠습니다.

“운영자 처럼 생각하는 개발자, 개발자 처럼 생각하는 운영자”

개발자와 운영자는 서로 존중하며, 신뢰해야 합니다. 다른 사람들의 전문성과 의견, 책임을 인정해야 합니다.

운영자는 새로운 기능에 있어서, 개발자를 믿어줘야 하고, 개발자는 운영자가 제안하는 인프라의 변화를 믿어줘야 합니다.

서로 숨기지 말고 투명해야 합니다.

개발자는 자신의 코드가 어떠한 영향을 주는지 알려야 하고, 운영자는 개발자에게 시스템에 들어갈 방법을 제공해야 합니다.

그리고, 서로에게 손가락질을 금지해야 합니다. 서로를 비난하고, 시작부터 손가락질 하기 시작하면 다음의 “손가락질 프로세스” 와 같이 숨기기에 급급하여 가장 먼저 해야 할 문제 파악이 뒤쳐지게 됩니다.

반면 아래의 “생산적인 프로세스” 에서는 가장 먼저 문제부터 파악하고, 신속히 장애를 수습하여 정상적인 서비스와 정상적인 삶으로 복귀할 수 있습니다.

“개발, 품질관리, 운영의 교집합”

<개발, 품질관리, 운영의 교집합, from http://en.wikipedia.org/wiki/DevOps#Devops_Days>

DevOps 는 신뢰성, 보안성 그리고 개발과 배포 사이클을 더 빠르게 개선하기 위해 배포, 테스트, 세부기능 개발, 릴리즈 관리를 목표로 합니다.
이러한 면에서 개발, 품질관리, 운영의 교집합이 되는 부분에 위치한다고 볼 수 있습니다.

“결론”

DevOps 는 툴이 아니라 사업적인 목표를 개발과 운영 조직이 서로 협업하여 같은 목표로 나아갈 수 있도록 하는 문화이고 일하는 방식입니다