DevOps란???

2009년 당시에는 cloud가 별로 도입되지 않았던 시기이다. 즉 각 회사는 server를 각각 구입해 구축하고 배포하고 운영하는 방식으로 이루어 졌는데 이 방식은 프로그렘을 개발하는 개발팀과 프로덕션을 올리는 운영팀이 분리되어 있었다. 
이런 환경은 개발팀이 프로그렘을 개발하더라도 이것을 운영팀이 '이해' 해야하며 이 과정에서는 당연히 둘 사이에서 마찰이 일어날 수 밖에 없다.

이런 마찰을 해결하기 위해 2009년 Flicker에서 등장한 '하루에 10회 이상 배포하기'라는 프로젝트를 통해 최초로 개발자(Dev)와 운영자(Ops)의 협업이 나타나게 되었다. 이 프로젝트에서는 개발팀과 운영팀 간의 괴리감, 불협화음을 어떻게 개선할 수 있는지 이야기를 하며 시작됬다.

 

- 마찰 예시 -

 

운영팀 = 음 이 문제는 보니까 개발팀에서 코드를 잘 못 만든거 같은데요?
개발팀 = 음 이 문제는 보니까 운영팀에서 서버를 잘 못 운영한거 같은데요?
서로가 서로를 이해할 수 없기에 이런 식의 마찰이 일어날 수 밖 에 없는 것 이었다.

 

 

이런 문제를 해결하기 위해 그렇다면 "프로그렘을 만든 개발자가 이 프로그렘을 더 잘 이해하지 않을까?" 하는 의문을 바탕으로 개선점을 마련하기 시작했다. 

 

이 발표에서는 변화에 대응하기 위한 5가지의 도구인 자동화된 인프라, 버전관리 공유, 쉬운 빌드 및 배포, 기능 활성화 스위치, 메신저 봇, 그리고  4가지의 문화인 존중, 신뢰, 실패에 대한 긍정적인 자세, 비난하지 않기, 라는것을 강조했다.

여기에서 영감을 받은 패트릭 드부아 라는 사람은 DevOpsDays라는 컨퍼런스를 주최하고 이 때 처음으로 DevOps라는 단어가 나타나기 시작했다.

 

조금더 명확하게 DevOps를 설명하자면 하나의 페러다임이며 문화이다. 특별한 방법론을 제시하는것이 아닌 하나의 목적인 개발-운영 사이의 벽을 허물어서 더 빠르고 좋은 서비스를 자주 배포하자 라는 목적을 이루고자 한다.

 

즉 DevOps를 정리하면 다음과 같다.

 

제품의 변경사항을 시장에 빠르게 전달하기 위한 실천 방안의 모음
분리된 개발 조직과 운영 조직의 경계를 허물고 하나의 팀으로 통합하고자 하는 문화, 철학

 

그렇다면 이런 DevOps가 필요한 이유가 뭘까??

소프트웨어 개발의 life cycle, 즉 생애주기를 알아봐야 하는데 일반적인 사이클은 다음과 같다.

 

	설계	개발	시험	배포	운영	사용자 지원
명칭	Design	Develop	Test	Deploy	Operate	Support
담당자	Architect	Developer	SDET	Release Eng	Sys Admin	Customer Support

 

의 표의 6가지 단계로 이루어진다.

어떤 소프트웨어를 만들지 고민하고 설계하고 그것을 개발하며 시험단계를 거친다. 어느 상황에서도 특별한 문제가 발생하지 않는다면 1.0ver으로 출시(배포)를 하며 이후에는 출시된 프로그렘을 운영하며 문제가 발생할 시 1.1ver, 1.11ver등의 업데이트를 통해 문제를 해결하며 사용자들을 지원해 준다. 

이런 life cycle에서 다음 구간으로 넘어가기 위해서는 다양한 의사소통이 이루어 지며 이 소통 사이에서 마찰이 생기며 이 마찰은 결국 의사소통의 병목현상을 발생시키게 된다.

DevOps는 이런 병목현상을 해소하기 위한 하나의 방법론이다.


이런 데브옵스를 실천할 수 있는 방법은 크게 6가지로 볼 수 있다.

Continuous intergration(지속적 통합) : 개발자가 만든 변경상황을 빌드- 테스트 한 이후 중앙 코드 저장소에 통합을 함으로써 빠른 버그 파악 및 제품 품질 보장을 할 수 있게 하는 서비스이다. 즉 품질 보장이 가능해진다.

Continuous Delivery(지속적 배포) : 개발 결과물의 산출물을 자동으로 개발환경이나 운영환경으로 배포하도록 하는 '자동화 파이프라인'이다.

이 두가지는 DevOps에서 가장 기본적으로 사용되야 하는 방법이다.

Micro-services(마이크로 서비스) : 어느정도 규모가 있는 서비스가 있는 조직에서 사용할 수 있는데 아무리 자동화 된 파이프라인이 있더라도 서비스 자체가 크다면 병목현상이 일어날 수 밖에 없다. 이 서비스를 도입함으로써 큰 서비스를 작은 서비스들로 쪼게서 업로드, 다운로드 함으로써 시간을 단축시킬 수 있다.

 

Intrastructure as Code(IaC) :  인프라스트럭쳐를 코드로 관리하는 기술을 의미한다. 서비스를 배포하는 방법에 있어서 인프라 변경사항은 필수이다. 이런 인프라 변경사항을 자동화 시켜 빠르게 적용하기 위해서는 인프라 또한 자동화관리가 필요하기 때문이다.

Monitoring & Logging(모니터링과 로깅) : 개발자들에게 제품의 메트릭과 로그 데이터를 중앙에서 확인할 수 있는 환경을 제공하게 되면 개발자들이 직접 운영에 참여하게 됨으로써 문제가 발생하면 즉각 대처할 수 있다.

Communication & Collaboration(소통 및 협업) : 사내 메신저 시스템이나 위치 시스템 등을 잘 활용하는건 어느 단체나 공동체서 당연히 중요한 일이다.