[소프트웨어공학] DevOps란 / 배포전략

 

데브옵스... 이게 무엇이냐...

Development + Operations = DevOps! 다시 말해 개발과 운용을 합친 방법론이다.

 

기존의 silo 방식(곡물 저장소처럼 큰 벽으로 막힌 것처럼 팀이 서로 벽을 치고 일하는 상황)으로 일하는 환경에서는 빠르게 변하는 운용팀의 상황을 개발팀이 따라가지 못한다. 그 반대의 상황이 일어나기도 한다. software를 개발하는 과정에서 가장 중요한 것은 stake holder의 요구사항에 신속하게 대응하는 것이다.

 

 

PLAN ➡️ CODE ➡️ BUILD ➡️TEST ➡️ RELEASE ➡️ DEPLOY ➡️ OPERATE ➡️ MONITOR가 무한 반복하는 것이 DevOps의 특징인데 이를 하나하나 사람이 하기란 쉽지 않다. 그래서 필수적으로 붙는 것이 CI/CD다.

 

Continuous Integration 지속적 통합

개발자가 공동 작업을 하는 경우 각자 자신의 작업물을 지속적으로 통합해야 한다. (ex. GitHub에 Commit)

코드의 오류를 검사하거나 작업을 테스트, 결과를 통보하는 등 대부분 작업은 자동화된다. (ex. GitHub Action)

 

Continuous Delivery 지속적 배포

통합이 된 코드가 릴리즈 환경으로 이동하고 배포된다.

이때 배포하는 것은 사람의 개입이 필요한 방식이 Continuous Delivery,

배포까지 사람의 개입 없이 진행하는 방식이 Continuous Deployment이다.

 

 

이 지속적 배포를 수행하기 위해서는 어떤 방식으로 프로그램을 배포할 것인가를 생각해야 한다. 

배포전략에는 크게 3가지가 있다.

 

1️⃣ Rolling Update

기존 인프라에 구 서비스를 제공하는 서버를 하나씩, 순차적으로 새로운 버전으로 대체하는 방식이다.

구버전과 신버전의 서비스가 동시에 존재한다는 단점이 있다.

2️⃣ Blue-green

기존 서버의 개수와 동일한 개수의 새로운 환경을 준비하여 동시에 교체하는 방식이다.

여분의 인프라를 준비해야 하지만 구버전과 신버전이 동시에 존재할 일이 없고 문제가 발생했을 때 Rollback이 쉽다.

3️⃣ Canary

서버 중 일부를 신버전으로 배포하고 신버전의 일부 사용자 트래픽을 분산하는 방식이다. 한마디로 야금야금.

별 문제가 발생하지 않으면 남은 서버도 교체하며 사용자 비율을 증가시킨다.

 

예전에 광산의 독가스를 검사하기 위해 사람보다 먼저 광산에 Canary 새를 넣어두었다고 한다. 새가 죽지 않고 건강히 있으면 안전하다는 뜻으로 광부가 들어가 작업을 했다. 여기에서 따온 배포전략이 Canary다. 신버전이 정삭 작동하나 일부 사람에게 검사하고 괜찮다면 모두에게 배포한다.