Devops란
<위키 백과 정의>
데브옵스는 소프트웨어의 개발(development)과 운영(operation)의 합성어로, 소프트웨어 개발과 정보기술 전문가 간의 소통, 협업 및 통합을 강조하는 개발 환경이나 문화를 말한다.
또한 데브옵스는 sw 개발 조직과 운영 조직 간의 상호의존적 대응이며 조직이 sw 제품과 서비스를 빠른 시간에 개발 및 배포하는 것을 목적으로 한다.
<빠른 이해 정의>
개발자(dev)는 고객의 요구사항을 빠르게 수용해서 서비스를 개발하고, 개발된 내용을 빠르게 적용하고 확인하길 원하며, 운영자(ops)는 제공될 서비스가 정확하게 동작하며, 테스트되었고, 성능적인 문제가 없으며, 다른 시스템에 영향을 주지 않고, 안정적으로 동작하기를 원한다.
IT 서비스에 대해 프로세스, 도구의 차이, 그리고 서로 다른 목적 등으로 인해 개발팀과 운영팀 간에 충돌이 빈번하게 발생하게 되고, 이러한 고민에서 데브옵스(Devops)라는 개념이 출현하게 되었다.
즉, 데브옵스는 개발자와 운영자의 소통, 협업 및 통합을 강조하는 문화, 방법론, 프로세스, 도구 모두를 의미한다.
애자일 방법론과 데브옵스의 유래
애자일 방법론은 devops engineer 또는 cloud system architect 등의 공고에서 자주 보게되는 단어 중 하나다.
.
.
.
데브옵스를 이해하기 전에, 데브옵스에 많은 영향을 준 "개발방법론"이라는 것에 대해 먼저 알아보겠다.
1990년 대는 기존에 대규모 개발에 대한 반작용으로 경량화된 개발방법론이 발전되었고,
1991년에는 빠른 앱 개발 방법인 RAD가 나왔다.
그리고 1995년에는 스크럼 개발 방법이나왔고, 1996년에는 극단적인 프로그래밍 방법론을 의미하는 XP가 발표되었다.
2001년 17명의 소프트웨어 개발자들이 유타에 있는 스노우버드 리조트에 모여서, 경량화된 개발방법론에 대해 논의를 했는데, 여기서 애자일 소프트웨어 개발을 위한 선언문을 발표하게 된다.
17명의 소프트웨어 개발자 중에서는 Kent beck, ward unningham(wiki 창업자), jeff sutherland(scrum 공동 창업자), ken schwaber (scrum 공동 창업자), jim highsmith 등의 매우 유명한 개발자를 포함하고 있었다.
애자일 개발방법론(agile software development)은 소프트웨어 개발 방법에 있어 아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론이다.
고전적인 개발방법론은 초기에 수립된 계획에 너무 의존하며, 프로그램 개발 과정 중 발생되는 추가적인 요구사항 및 변화에 적절하게 대응하지 못하고, 전체적인 개발의 흐름 자체를 느리게 하는 단점을 가지고 있었다.
반대로 계획을 수립하지 않고 진행되는 개발의 경우, 앞으로의 일을 예측하기 힘들고 효율적이지 못하다는 취약점을 가지고 있으며, 일정 계획과 목표를 갖고 진행하기 어렵다는 단점을 가지고 있었다.
애자일 개발방법론은 두 가지에 대해 적절한 타협점을 제시하는 방법론이다.
애자일 방법론은 다른 고전적인 방법론, 예를 들면 폭포수 모델 또는 나선형 모델과 구별되는 가장 큰 차이점은 less document-oriented, 즉 문서를 통한 개발 방법이 아니라, code-oriented 실질적인 코딩을 통한 방법론이라는 점이다.
애자일 개발방법론은 계획을 통해 주도해 나갔던 과거의 방법론과는 다르게 앞을 예측하며 개발하지 않고, 일정한 주기를 가지고 끊임없이 프로토타입(시제품)을 만들어내며 그때 그때 필요한 요구를 더하고 수정하여 하나의 커다란 sw를 개발해나가는 adaptive style이라고 할 수 있다.
이런 애자일 방법론은 타당성 조사, 요구 조건 분석, 외부 설계 문서 작성, 프로그램 사양 작성, 코드 작성, 테스트, 그리고 제작같은 일련의 단계를 순차적으로 진행하는 폭포수 방법론에 대한 해결책으로 여겨졌다.
폭포수 모델은 매우 상세한 기능 요구조건을 작성할 것을 요구하며, 이런 요구조건은 거의 일방적으로 개발자들에게 넘겨지고, 개발자들이 정의/분석한 요구사항을 토대로 개발을 진행해나가지만, 이해 당사자들이 원하던 결과물이 아닌 일이 발생하게 된 경우가 빈번하여 어려운 점이 많았다.
애자일 소프트웨어 개발 원칙 12가지는 아래와 같다.
- 고객의 최우선 만족
- 요구사항 변경의 유연성
- 작동하는 소프트웨어를 자주 informing
- 비즈니스 쪽의 사람들과 자주 협업
- 동기가 부여된 개인을 중심으로 프로젝트를 구성
- 개발팀, 개발팀 내부에서 정보를 전달하는 가장 효율적인 방법은 면대면 대화!
- 작동하는 소프트웨어가 진척의 주된 척도이다
- 지속 가능한 개발 장려
- 좋은 설계
- 단순성
- 스스로 조직된 팀에서 최고의 아키텍쳐와 요구사항, 설계가 나온다
- 정기적으로 어떻게 더 효과적일지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.
Devops를 위한 기술적 구성 요소
Devops를 위한 기술적 구성 요소는 아래의 4가지로 정리가 가능하다.
1. 코드 기반 인프라 관리 (Infrastructure as Code)
- Code 기반으로 시스템과 운영/배포 환경 구축
- 인프라 운영/관리 소스의 체크인 및 관리 수행
2. 버전 관리(Version Control)
- 소스 및 빌드 관리를 위한 단일 시스템
- 변경 사항을 커밋할 때마다 빌드
- 빌드 검증 테스트를 자동으로 수행
- 플래그(flag)를 통해 기능(feature) 활성화
3. One Step 빌드/배포(Build&Deployment) = CI/CD (Continuous Integration/Continuous Delivery)
- 한번 클릭으로 빌드/배포(수동)
- 예약 작업을 통한 빌드/배포
- 검증 실패 시 배포 중지 및 알림
4. 장애 시 빠른 인프라 배포
- 문제 발생 시 기존 시스템 수정하지 않고, 재배포
- 환경 설정 스크립트 수정 및 변경
Devops 성공사례
1. Netflix
- microservice & chaos engineering
2. Facebook
- dark launching & devops
3. Amazon
- two pizza team
