목차
1. 데브옵스(DevOps)란?
2. 애자일 방법론과 데브옵스의 유래
3. Why? DevOps
4. DevOps를 위한 필수 구성 요소
5. 클라우드와 DevOps
6. DevOps 성공사례
1. 데브옵스(DevOps)란?
개발자와 운영자의 소통, 협업 및 통합을 강조하는 문화, 방법론, 프로세스, 도구 모두를 의미한다. 데브옵스는 개발팀과 운영팀 간 충돌을 해결하는 것에서 시작했다.
2. 애자일 방법론과 데브옵스의 유래
1) 시대별 개발방법론
1990년대: 경량화된 개발방법론 1991년: 빠른 개발방법론(RAD) 1995년: 스크럼 개발방법론 1996년: XP(eXtreme Programming) 2001년: 애자일 소프트웨어 개발 선언문 발표
2) 애자일 방법론이란
아무 계획이 없는 개발 방법과 계획이 지나치게 많은 방법론 사이에서 타협점을 찾고자 탄생한 개발방법론이다. 프로그램 개발 과정 중 발생하는 추가적인 요구사항이나 변화에 빠르게 대응하여 개발 속도가 늦춰지지 않게 하는 동시에, 계획과 목표를 수립해 효율적으로 일할 수 있도록 한다. 애자일 방법론에서는 문서를 통한 개발보다 실질적인 코딩을 지행한다. (less document-oriented, code-oriented)
애자일 방법론에서는 일정한 주기를 가지고 프로토타입을 반복해서 만들어낸다. 요구사항을 그때그때 반영하고 결함을 수정하며 소프트웨어를 개발한다. 이는 개발 단계를 순차적으로 진행하는 폭포수 모델론에 대한 해결책으로 여겨졌다.
(폭포수 모델은 상세한 기능 요구사항을 사전에 작성할 것을 요구하며, 이 요구 조건은 거의 일방적으로 개발자에게 넘겨진다. 개발자는 요구사항을 정의, 분석하여 개발을 진행한다. 따라서 적지 않은 빈도로 이해 당사자가 원하던 것과는 다른 결과물이 만들어진다.)
3) 애자일 소프트웨어 개발 원칙 12가지
- 우리의 최우선 순위는 가치 있는 소프트웨어를 일찍, 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
- 비록 개발 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스는 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
- 작동하는 소프트웨어를 자주 전달하라. 2주에서 2개월 간격으로 하되, 더 짧은 기간을 선호하라.
- 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
- 동기가 부여된 개인을 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
- 개발팀, 개발팀 내부에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
- 작동하는 소프트웨어가 진척의 주된 척도이다.
- 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.
- 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 민첩성을 높인다.
- 단순성 즉, 안 하는 일의 양을 최대화하는 기술이 필수적이다.
- 최고의 아키텍처, 요구사항, 설계는 스스로 조직된 팀에서 나온다.
- 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.
3. Why? DevOps
1) 데브옵스의 필요성
애자일 개발 방법론 도입으로 소프트웨어 배포는 더 빨라졌고, 빌드는 더 소소하고 빈번하게 진행되었다. 이는 운영팀에 부하가 걸리는 등 여러 문제점을 촉발했다. 배포, 테스트, 빌드 등 개발과 운영의 전반적인 주기 자동화 필요성이 대두되었고, 데브옵스(DevOps)가 등장하게 되었다.
데브옵스 도입으로 개발자 생산성은 극대화하고 지속적인 학습을 통한 비즈니스 경쟁력을 확보할 수 있게 됨으로써 IT 기업은 다음과 같은 효과를 기대할 수 있게 되었다.
- 비즈니스 경쟁력 확보 구성원의 유기적인 협력을 통해 조직 공동 목표 달성을 위해 노력하여 안정성, 신뢰성, 보안성, 가용성 확보로 기업 경쟁력 강화
- 고객 요구사항에 효과적으로 대응 교차 기능팀을 통해 적시적소에 고객 요구사항 파악이 가능하며, 다른 팀에 의존하지 않고 빠르게 업무 관련 기술 활용 가능
- 소규모 팀의 독립적인 프로세스 소큐모 팀이 코드를 신속하고 독립적으로 개발, 테스트, 배포할 수 있는 프로세스를 구축하고 신뢰할 수 있는 가치 제공
지난 40년 동안, 전략적 비즈니스 역량과 기능을 개발하고 배포하는 데 필요한 시간과 비용은 기술 발전을 통해 지속적으로 감소했다.
| 구분 | 1970~1980년대 | 1990년대 | 2000년대~현재 |
|---|---|---|---|
| 시대 | 메인프레임 | 클라이언트 및 서버 | 클라우드 |
| 대표 기술 | 코볼, DB2 | C++, 오라클, 솔라리스 | 자바, MySQL, 레드핫, Python |
| 사이클 타임 | 1~5년 | 3~12개월 | 2~12주 |
| 위험 범위 | 전체 회사 | 제품 라인 또는 부서 | 제품 기능 |
| 실패 비용 | 부도, 매각, 대규모 해고 | 수익 손실, CIO 업무 | 미미함 |
데브옵스를 도입한 조직은 수백, 수천 개 변경 사항을 매일 배포한다. 이는 빠르게 변화하는 시장에 대처할 수 있게 하며, 매일 수십 번 배포할 수 없는 조직은 경쟁자에 패할 운명에 처해 있다.
2) 데브옵스의 목표와 효과
대부분 IT 조직애서는 개발팀과 운영팀 사이에 갈등이 있다. 개발팀은 빠르게 변화하는 경쟁 환경에 대응하는 것, 운영팀은 고객에게 안정적이고 신뢰할 수 있는 서비스를 제공하는 것이 목표기 때문이다. 이러한 갈등은 신제품 혹은 신기능 출시 지연, 품질 저하, 서비스 중단을 초래해 비즈니스 경쟁력을 떨어뜨린다.
데브옵스의 목표는 소규모 팀에서 기능을 독립적으로 구현하고, 운영 환경과 동일한 환경에서 테스트를 수행하며, 코드를 빠르게 배포하는 환경을 구성하는 것이다. 데브옵스를 통해 다음과 같은 효과를 얻을 수 있다.
- 빠르고 정확하게 운영 환경에 코드를 배포할 수 있다. 서비스를 중단하지 않고도 배포할 수 있다.
- 배포 프로세스 단계별로 피드백을 빠르게 받을 수 있다.
- 자동화를 통해 빠르고 효과적으로 업무를 진행할 수 있다.
- 원하는 기능과 고객 요구사항을 독립적으로 전달하고 배포할 수 있다.
- 신규 제품이나 기능 출시에 대한 피드백을 효과적으로 진행할 수 있다. 신규 기능을 배포할 때 개발된 내용을 운영 환경 하위 집합으로 적용하지만, 사용자에게는 노출하지 않거나 일부만 노출하면서 테스트할 수 있다.
4. DevOps를 위한 필수 구성 요소
1) 문화적 구성 요소
데브옵스의 핵심 사항은 ‘협업’과 ‘목표 공유 문화’다. 문화는 성공적인 데브옵스를 수행하기 위한 밑바탕이며, 도구와 기술이 이를 가능하게 한다. 데브옵스를 위한 문화적 구성 요소는 네 가지 요인으로 정리할 수 있다.
- 배려하고 존중하는 환경 구성하기
개발자와 운영자가 각자 일을 떠넘기지 않고 서로 존중하면서, 이슈가 발생했을 때 문제 해결을 위해 서로 도움받는 것이 중요하다. - 자유로운 토론 환경 조성하기
문제를 회피하지 않고 오픈마인드로 커뮤니케이션하고, 개발자와 운영자 간 적극적으로 토론하고 대화하면서 현재 업무 진행상황이나 향후 계획을 공유한다. - 남 탓하지 않기
운영 중 문제 발생 시 개발팀과 운영팀 간 책임을 공유하고 협력하여 문제를 빠르게 해결한다. - 완료했다고 해서 책임을 회피하지 않기
프로그램을 배포했다고 해도 개발팀은 책임이 끝나지 않아야 한다. 성공과 실패는 개발팀과 운영팀 양쪽 모두가 책임을 진다는 인식을 공유해야 한다.
2) 기술적 구성 요소
- 코드 기반 인프라(Infrastruction as Code) 관리
‘프로그래밍형 인프라’라고도 한다. 인프라 구성을 프로그래밍하는 것처럼 처리하는 방식을 가리킨다. 애플리케이션을 작성하는 작업과 애플리케이션이 실행되는 환경을 구현하는 작업을 모두 코드 기반으로 관리할 수 있다. 아마존, MS, 구글 등 클라우드 업체는 대부분 IaC 기반 인프라 서비스를 제공한다. - 버전 관리(Version Control)
개발 시간이 경과함에 따라 발생하는 소스코드 변경 사항을 개발팀이 관리하는 데 도움을 주는 소프트웨어 도구로, 소스코드의 모든 수정 사항을 저장하고 추적한다. 버전 관리 시스템은 휴먼 에러 및 의도하지 않은 결과로부터 소스코드를 보호한다. - One-Step 빌드와 배포(Build & Deploy)
빌드 작업이란, 팀 내 여러 개발자가 개발한 소스를 버전 관리 시스템을 이용해 통합하고, 통합한 소스를 텀파일, 테스트, 정적 분석 등을 거쳐 실제로 동작 가능한 소프트웨어로 변환하는 작업이다.
배포 작업이란, 빌드한 파일을 개발 서버 또는 운영 서버에 등록하여, 신규 프로그램이나 변경된 프로그램을 사용할 수 있게 전달하는 과정이다. 배포 과정에서 발생하는 작은 장애나 실수는 서비스 장애로 이어지므로, 배포 작업의 위험을 최소화해야 한다. 배포 툴은 대량으로 변경된 내용을 한 번에 배포하기 보다, 조금씩 자주 배포함으로써 위험을 분산시킨다. 배포 주기가 잦으면 위험이나 결함을 사전에 파악할 수 있다. 이러한 자동화 서비스를 CI/CD(Continuous Integration/Continuous Delivery)라고 한다. - 장애 발생 시 인프라를 빠르게 배포
데브옵스 기반 인프라 환경에서는 인프라에 문제가 발생했을 때, 인프라를 재구성하기 위해 OS 설치, 솔루션 설치, 환경 구성까지 할 필요가 없다. 기존 인프라를 수정하지 않고 재배포할 수 있으며, 환경 관리 도구(Configuration Management Tool)를 이용해 쉽고 빠르게 신규 환경을 구성할 수 있다. 특히 최근 클라우드 기반 환경에서는 클릭 몇 번으로 Paas, IaaS 기반 인프라에서 손쉽게 재구성 및 재배포할 수 있다.
5. 클라우드와 DevOps
대부분 프로젝트에서 하드웨어를 클라우드 서비스로 대체하면서, 프로젝트 시작 후 몇 분 ~ 며칠만에 기본적인 인프라 구성을 마무리할 수 있게 되었다. 운영팀은 기본적인 OS 설치까지 마친 서버를 개발자에게 빠르게 전달할 수 있고, 개발자는 구성 파일과 스크립트를 통해 인프라를 구성할 수 있다.
데브옵스가 제공하는 것은 요청하는 즉시 애플리케이션을 구축할 수 있는 역량이고, 클라우는 애플리케이션을 바로 배치할 수 있기 때문에 데브옵스와 클라우드는 상호 잠재력을 극대화해준다.
6. DevOps 성공 사례
1) Netflix
2008년, 넷플릭스 데이터 센터에서 운영 중이던 RDBMS인 Oracle 서버에 문제가 발생해 전체 서비스가 다운되고, 3일 동안 DVD 배송이 중단되는 문제가 발생했다. 다시는 이런 문제를 만들지 않기 위해 두 가지 선택지 사이에서 고민했다.
- 월드 클래스 데이터 센터를 구축하여 글로벌 오퍼레이션 기업이 되는 것
- 퍼블릭 클라우드로 모든 서비스를 이전하는 것
당시 넷플릭스는 매우 빠르게 성장하는 기업이었으므로, 자체적인 데이터 센터로는 가파르게 증가하는 볼륨을 감당할 수 없다는 판단을 내ㅔ렸다. 클라우드로 이전할 경우 수천 개 이상의 가상 서버를 손쉽게 추가하고 수분 이내로 페타바이트 단위로 스토리지를 사용할 수 있다는 것을 알고있었다.
기존 시스템을 클라우드로 이전하기 위해서는 기존 인프라 구조를 완전히 새롭게 설계해야 했다. 넷플릭스는 기존에 구현했던 시스템을 AWS에서 재구현하기로 헸고, 이를 통해 오퍼레이션 방식을 근본적으로 바꾸기로 결정헀다. 모놀리틱스 방식(Monolithic Architecture)을 MSA(Microservice Architecture) 방식으로 전환하여 AWS에 재구현했고, 이를 통해 보다 효과적으로 서비스를 운영할 수 있는 기반을 마련했다. 기존 넷플릭스 서비스를 다수의 소규모 서비스로 쪼개는 마이크로서비스는 인프라를 더욱 민첩하게 만들 수 있게 했고, 각 마이크로서비스는 개별 서비스와 프로세스를 가장 잘 이해하는 소규모 팀이 직접 운영하도록 변경했다. 이는 결국 데브옵스를 도입한 것으로, 당시에는 획기적인 결정이었다.
넷플릭스가 기존 데이터 센터 전체를 클라우드로 완전히 이전하기까지 7년이 걸렸다. 이제는 클라우드 인프라가 고객 정보에서부터 추천 알고리즘까지 모든 컴퓨팅 및 스토리지 니즈를 담당하고 있다. 클라우드로의 이전은 서비스 확장성과 가용성, 새로운 콘텐츠와 기능, UX/UI 출시 속도를 단축시켰으며, 엔지니어를 해방시켜 다른 업무에 자유롭게 시간을 쓸 수 있게 만들었다.
또한, 클라우드를 사용한만큼 비용을 지불하면 되므로, 많은 비용을 들여 투자하지 않아도 신기술 개발, 적용, 검증을 할 수 있게 되었다.
| 연도 | Netflix 클라우드 여정 | 서비스 현황 |
|---|---|---|
| 2008 | 데이터센터 장애 발생 |
100s 마이크로서비스 1,000s 일간 서비스 배포 10,000s 서버 인스턴스 수 100,000s 분당 트랜잭션 수 1,000,000s 총 고객 수 1,000,000,000s 측정 데이터 10,000,000,000s 총 스트리밍 시간 10s 시스템 엔지니어 수 No Datacenter |
| 2009 | 클라우드 이전 시작 | |
| 2010 | AWS 클라우드에서 서비스 시작 (US-EAST-1) | |
| 2011 | EU-WEST-1 | |
| 2013 | US-EAST-2 (Active/Active) | |
| 2015 | 전체 이전 완료 |
넷플릭스는 모든 인프라에서 실패할 것을 가정하고 인프라를 운영한다. 넷플릭스가 사용하는 AWS 영역 중 하나에서 실패가 발생해도 이를 문제없이 넘길 수 있도록 카오스 엔지니어링을 채택했다. 한 영역을 비활성화하고 6분 안에 비활성화된 영역의 모든 고객을 다른 영역 중 하나로 이동시킬 수 있는지 테스트한다.
넷플릭스 정책의 핵심은 ‘자유와 책임의 균형’이다. 각 마이크로서비스를 맡은 팀을 독립적으로 관리하면서도 각 팀이 같은 목표를 공유하고 이를 달성하기 위해 노력한다.
2) Facebook
페이스북은 사용자 증가와 새로운 서비스 오픈에 따라 엄청난 트래픽이 발생했으며, 이로 인해 시스템이 중단되었다. 시스템에 영향이 가지 않으면서도 새롭게 출시하는 기능을 테스트할 수 있는 방법으로 다크 론칭(Dark Launching) 기법을 고안했다. 다크 론칭 기법은 특정 사용자에 한정해 새로운 기능을 배포하고 테스트한 뒤 피드백을 반영하여 새 기능이 안정화되면 전체 배포하는 방식이다. 또한 CD(Continuous Delivery) 도입을 통해 새로운 서비스 배포가 기존 애플리케이션 성능에 영향을 미치지 않고, 더욱 빠르고 편리하게 서비스를 릴리즈한다.
다크 론칭 기법에서는 전용 배포 파이프라인을 통해 새로운 기능을 일부 사용자에게 배포한다. 아래 그림처럼 선택한 사용자 그룹에 해당하는 파이프라인만 동작하고 그 외 파이프라인은 모두 꺼진다.
새 기능을 배포한 타겟 그룹을 지속적으로 모니터링하고 피드백을 반영하여 안정성이 확보되면 꺼져있는 다른 배포 파이프라인을 켜서 나머지 사용자를 대상으로도 점진적으로 배포한다. 만약 테스트에서 문제를 발견하면 롤백한다. 이는 페이스북이 데브옵스를 기반으로 CI/CD 도입함으로써 가능하게 되었다.
페이스북에는 별도 QA팀이 없다. 개발자는 새롭게 개발한 모든 코드를 직접 테스트하며, 코드는 커밋과 푸시 작업의 일부로 자동화된 회귀 테스트를 모두 통과해야 한다. 이러한 책임 문화는 심각한 버그 발생을 막는 데 도움이 된다.
3) Amazon
2002년 아마존은 자사 데이터베이스와 서비스를 오픈 API 형태로 외부에 개방했다. 이를 이용해 다른 웹사이트가 제품 가격과 상세 설명을 아마존 DB에서 골라 올리고 아마존 결제 시스템과 장바구니를 이용할 수 있게 했다. 이것이 아마존 웹 서비스(AWS)의 시작이다.
2006년 아마존 웹 서비스를 시간 단위로 외부 기업에 임대하는 Elastic Compute Cloud(EC2), 사진, 문서 등 파일을 아마존 서버에 저장하게 해주는 Simple Storage Service(S3)를 공개했다. 이런 서비스를 이용해 신규 업체는 자체 전자상거래 시스템을 구축하거나 운영하는 대신 아마존에 사용한만큼 돈을 지불하며 사용할 수 있게 되었다.
아마존 CEO 제프 베조스는 아마존 시스템을 서비스 지향 아키텍처로 변경하는 과정에서 투 피자 팀(Two Pizza Team)이라는 팀 빌딩 방식을 도입한다. 피자 2판이 16조각이고 1인당 2~3조각을 먹으니, 팀원이 아무리 많아도 8명 이상이 되어서는 안 된다는 법칙이다. 이는 조직을 작은 팀 단위로 나눠 의사결정 속도를 높이는 반면, 만장일치를 이루려고 하는 경향인 집단 사고(Group Think)를 피하기 위함이다. 팀 크기뿐만 아니라 자율성과 책임성도 핵심 요소다. 이는 데브옵스에서 말하는 핵심 조직 운영 전략과 밀접한 관련이 있다.
수 년 전, 아마존은 내부 시스템 코드 커밋부터 정식 서비스 릴리즈까지 걸리는 시간을 측정했는데, 실제 개발하는 시간보다 승인, 피드백, 알림 등 커뮤니케이션에서 시간이 더 오래 걸렸다. 이러한 시간을 단축하고자 소스, 빌드, 테스트, 배포 단계별로 사람의 영향을 최소화하는 파이프라인(Pipeline)이라는 도구를 개발했다. 이는 전통적인 의미의 CI/CD를 구현하는 제품이다. 파이프라인을 통해 아마존은 서비스를 빠르게 출시하고 지속적으로 혁신을 이룰 수 있었다.
현재 AWS의 서비스 중 많은 것이 아마존닷컴 내부 경험을 바탕으로 외부 고객 요구사항을 받고 피드백을 거쳐 서비스로 공개한 것이다. Amazon DynamoDB는 아마존닷컴 장바구니 시스템에 사용하던 키-밸류 데이터베이스인 DynamoDB를 제공하는 서비스다. 앞서 설명한 아마존닷컴 내부 시스템 관리, 배포용 서비스는 AWS CodeDeploy, AWS CodePipeline이라는 이름으로 제공하고 있다.