#데브옵스는 무엇일까?
보통 소프트웨어를 만드는 조직에는 크게 프로그램을 구현하는 개발부서(dev)와 출시 후에 유지보수를 담당하는 운영부서(ops)가 존재하는데 전자같은 경우는 오류를 수정하고, 사용자 니즈를 반영 후 새기능을 제공하여 잦은 업데이트에 집중하는 반면, 후자는 서비스 안전성,빠른 성능 요구 등 변화를 최대한 적게하여 서비스 안전성을 확보하는데 집중한다.
-출처:네이버 블로그(코드스테이츠)이런 조직 구조는 서로간의 협업이 이루어지지않을 가능성이 있고,그로인해 개발과서비스 배포의 속도가 줄어들 수 있고 결과물의 완성도도 높지않을 것이다. 사실 개발 뿐만 아니라 이런 문제는 공직에도 일어난다. 서로 원하는것만 요구하고 책임을 떠넘기기만하고 민원인은 답답하기만한 경우가 존재한다.협업은 조직의 가장 중요한 덕목이다.이런 조직 환경을 보완하기위한 방식이 데브옵스(DevOps)다.
데브옵스는 지식백과에 따르면 소프트웨어 개발(Software Development)과 it운영(Information Technology Operation)을 병행하고 협업하는 방식으로 여러팀간 의사소통과 협업을 활성화시킬 수 있다.개발부문,운영부문,품질관리 부서 사이의 통합,커뮤니케이션,협업을 위한 일련의 방법 및 적기에 제품이나 서비스 출시를 목표로 하는 조직에 효율을 가져다줄 수 있는 요소다.
"각 분야의 각개전투는 비효율적이니 한번에 처리하자!"개발과 운영은 상호의존의 관계여야될 이유는 뭐냐면 이2가지의 영역이 분리되면 개발이 지연되거나 납기 후 문제 발생 빈도가 높은 반면,데브옵스에서는 개발자와 운영자 간에 책임을 공유함으로서 개발 주기가 단축되고 비용을 절감시킬 수 있다.그리고 문제 발생 빈도가 낮아지고 문제가 발생하여도 즉시 처리가 가능하다.
"쉽게 말해 데브옵스는 개발과 배포 속도를 향상시킨다"
- 출처:네이버 지식백과(it용어사전)
이런 이유로 데브옵스 엔지니어가 존재하게되었고 수요가 생겼다.
데브옵스의 장단점을 정리하자면 아래와 같다.
장점
1)생산성 증대
2)구성원에게 개발 책임감과 코드의 소유권을 높여줘 개발 프로세스를 간소화 시킬 수 있음
단점
1)충분한 시간이 필요하다.
왜냐? 다양한 팀이 모여 업무 역할이 변경되기때문에 활성화하는데 시간이 필요하기때문
2)코드를 자주 배포할 필요가 없다면 비용만 늘어남
3)포괄적인 자동화도구가 필요함
또한 데브옵스의 구성은 코드 리포지토리, 아티펙트 리포지토리, CI/CD, 컨테이너, 컨피그레이션 매니지먼트로 되어있다.자세히 알아보면
-
코드 리포지토리(Code repositories)
-코드 수정내용 보관 및 타 개발자들이 변경된 코드를 적용함
(git,svn)
-
아티펙트 리포지토리(Artifact repositories)
-프로젝트 수행시 만든 산출물(설계문서,jar파일 등)을 버전별로 보관함
(jfrog, nexus repositery)
->자료를 보관하는것도 그냥 막 보관할시에는 다음에 찾는데 상당히 애먹는다;;; -
CI/CD
CI(continuous integration 지속적인 통합)
CD(continuous deploy 지속적인 배포)
-품질관리를 위해 지속적인 빌드와 테스트 과정 지원과 지속적으로 배포하는 기능을 포함함
(jenkins)
4.컨테이너(Containers)
가상환경에 접속한 후 해당 환경에 맞추어 세팅해주면 개발 시스템 별로 세팅해줄 필요없이 컨테이너에 맞춤대로 개발 시스템에 동일하게 세팅이 가능해진다.(docker,microsoft hyper v)
-> 봤을때 화물 컨테이너들이 쌓여있는 모습이 상상된다.유사하게 생긴 컨테이너들 사이 그 안에 있는 내용은 달라도 겉으론 비슷한 모습이라는점에서 연상이 되는것같다.하나의 개발환경 셋팅 기능 부품이라고도 생각된다.
5.컨피그레이션 매니지먼트(configuration management)
-서버 컨테이너 릴리즈별 설정 관리(puppet,chef)
- 출처: tistory (Wakestand Island)
그렇다면 데브옵스 엔지니어는 무슨 역할을 하는 개발자일까?
데브옵스 엔지니어는 개발부터 운영까지 하나의 통합된 프로세스를 묶어내는 역할,다시 말해 각 부서의 업무를 효율적으로 엮고 자동화하여 두 부서 모두의 목표를 달성시켜주는 사명감을 지닌 개발자다.
사람들은 서비스에 대한 기대감과 요구가 높아지고 있으며,오류는 금방 해결되길 원한다.
엔지니어가 하는 작업 3단계
1.자동화
(why:사람의실수를 줄이기위해 컴퓨터가 할 수 있는 일은 최대한 스스로 하게끔 구조화하여 휴먼에러를 줄이기위해!)
2.롤백(=이전 버전으로 돌려놓는 행위)
(why:에러가 발생하여 소프트웨어에 문제가 생겼을때,이것을 즉시 파악하여 이전의 문제가 없던 버전으로 되돌려놓는 과정이 필요하기 때문!)
3.모니터링
서비스개발단계부터 출시 후 사용자가 이용중인 서비스를 모니터링하고 변경사항들을 모두 기록하여 다른 조직 구성원과 공유한다.
(why:이런 기록들은 서비스가 중단되었을때 누구든지 이 문제를 진단하고 시스템을 복구하여 운영할 수 있도록 절차를 마련하는데 사용되기때문!)
-> 건축 설계를 할때도 이런 모니터링 과정이 있는데 건축이든 개발이든 이렇게 재사용할 프로세스를 발전시키고자하는것은 인류의 큰자산이 아닐까싶다.
- 출처: 네이버블로그(코드스테이츠)
