Offcanvas

How To / 경력관리 / 데브옵스 / 데이터센터 / 리더십|조직관리 / 애플리케이션 / 오픈소스 / 인문학|교양

기고 | '개념에서 의의까지' 데브옵스 따라잡기

2015.06.22 Matthew Heusser  |  CIO


빌드 자동화
지속 통합(CI, Continuous Integration) 툴이야 말로 여기 언급된 것들 중 가장 널리, 많이 쓰이는 툴일 것이다. 일부 기업들은 빌드를 계속하기도 하지만 자동화 빌드의 잠재력은 컴파일 단계에서 그치지 않는다. 브랜치에 따른 로깅 및 태깅 빌드를 포함할 수도 있고, 커밋 넘버와 브랜치에 연결된 아카이브에 빌드를 저장할 수도 있으며, 빌드에 기능을 연결할 수도 있을 지도 모른다.

빌드가 완성되면 항상 모든 유닛 테스트를 진행할 수 있을 뿐 아니라 소프트웨어를 개발, 테스트, 및 스테이징 서버에 언제든지 배치할 수 있다. CI툴에서 웹 서비스나 GUI 엔드 투 엔드 체크를 통해 새로운 코드에 큰 결함은 없는지 살펴볼 수 있다.

그렇지만 이것이 지속적 전달(continuous delivery )은 아니다. 코드가 자동으로 프로덕션 코드가 되는 것은 아니다. (일부 기관들에서는 배치할 때마다 개발 환경을 업그레이드 하는 게 아니라 완전히 새로운 가상 서버를 구매하기도 하고, 프로그래머 당 하나 이상의 가상 환경을 만들기도 한다.)

결함으로 인해 발생하는 데미지가 해당 결함의 심각성과 그것이 얼마나 많은 사람들에게 노출되었느냐에 의해 결정된다고 한다면, 최대한 빨리 그 결함을 발견하고 수리하는 것이야 말로 피해를 최소화하는 방법일 것이다. 많은 사용자들이 발견하기 전에 문제를 먼저 발견하는 것이 쉽지만은 않지만, 시각적 모니터링과 대체로 어느 정도 도움을 받을 수 있다.

서버 로그에는 엄청난 분량의 정보가 들어 있다. 리퀘스트 처리에 얼마만큼의 시간이 걸리는지에서부터 시스템에 404, 500 에러가 얼마나 발생했는지까지 말이다. 이 에러들을 그래파이트(Graphite)와 같은 오픈소스 툴을 사용해 그래프로 시각적으로 표현하면 문제가 발생하는 즉시 이를 파악하고 조치를 취할 수 있다.

이러한 작업이 완성되고 나면, 프로덕션 롤아웃 단계는 웹 페이지, 혹은 최소한 명령행 인터페이스상에 자동화할 수 있다. 지속적인 배치 시스템은 여기서 프로덕션으로 한 단계만 더 나아가면 된다.

푸시 버튼 배치는 푸시 버튼 해결책으로 이어지게 되고 이는 프로덕션 모니터링과 만나 결함의 TTL(time to live)을 극적으로 줄이게 된다.

설정 플래그
설정 플래그(Configuration Flag)는 TTL을 줄이는 또 다른 메커니즘이다. 프로덕션 코드를 바꾸는 대신 새 코드에 “if(feature){}”을 적용해 코드를 바꾼다. 프로그래머는 플래그를 온 또는 오프로 저장한 디스크상의 파일을 바꾼다. 이는 코드를 변경하는 것이 아니므로 새로운 빌드/배치가 필요 없다.

노아 서스먼(Noah Sussman)의 “컨피그 플래그: 러브 스토리(Config Flags: A Love Story)”는 이 주제를 훨씬 깊이 있게 다루고 있다. 설정 플래그는 점진적인, 그리고 궁극적으로 폭넓은 고객 유형을 만족시키는 방안이 될 수 있다. 맨 처음에는 직원, 다음으로 직원들의 가족, 베타 테스터, 리스크 감내 고객, 다음으로는 정기 고객, 그리고 마지막으로 ‘기업’고객 및 리스크 회피적 고객 순으로 배포 범위를 넓혀나감으로써, 새로운 기능을 알려나가는 과정에서 시스템 관리와 피드백 수집의 이점을 누릴 수 있다.

그 구체적인 방법론은 다양하게 전개될 수 있지만, 대표적인 전략을 한 가지 소개하자면 2008년 출간된 “마이크로소프트의 소프트웨어 테스트 비법(How We Test Software in Microsoft)”에 소개되며 알려진 ‘생산 중 테스트(Testing in Production)’을 이야기해볼 수 있다.

이 아이디어들은 대부분 컨셉트에 그치지만, 그것을 실행할 방법은 상용, 오픈소스 시장에 다양하게 존재한다. 가장 흔히 이용되는 전략 중 하나는 퍼블릭/프라이빗 클라우드 내에 가상 서버 팜을 생성하는 것이다. 새로운 빌드를 생성하되 배치하지 않는 방식이다.

이 경우 시스템은 새로운 기기로 로드 밸런스를 조절해 보낼 수 있다. 이러한 서비스 ‘전환’은 사용자가 그 과정을 인식할 수 없도록 이뤄진다. 또한 혹 발생할 수 있는 심각한 문제에 대비해 전환 후 수 분 간은 기존 시스템 역시 대기하게 된다.

(실물 혹은 가상) 기기 셋을 설정하는 것은 다량의 스크립팅과 자동화를 요구한다. 이 과정을 지원하는 툴로는 셰프(Chef)와 퍼펫(Puppet)이 대표적으로, 모두 데브옵스 업무에 자주 사용되고 있다.

데브옵스에 관해 듣게 되는 가장 실망스러운 말은 데브옵스가 ‘새로운 역할’라거나, 이를 위해 제 3의 ‘팀’을 꾸려야 한다는 것이다. 일부 개발자들은 자동화 혹은 인프라스트럭처 작업의 구축/배치를 선택할 수도 있지만, 데브옵스라는 아이디어는 본래 공동 작업을 원칙으로 한다. 다른 이들이 이해하지 못하고, 신경도 쓰지 않는 모호한 디테일들을 다루는 특수직이 되어버린다면, 결국 데브옵스은 머지않아 자취를 감추게 될 것이다.

데브옵스 테스트는 당신의 팀이 어느 정도나 데브옵스을 받아들였는지, 그리고 앞으로 받아들일 수 있을지를 간단히 평가할 수 있는 도구다. 완벽하진 않지만 빠르고 간편하게 진행할 수 있으니 시험 삼아 참여해보자. 결국 미래는 당신이 써 내려가는 것이다.

* Matthew Heusser는 엑실리온 디벨롭먼트의 수석 컨설턴트다. ciokr@idg.co.kr 

CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.