소프트웨어 제공의 배포 단계는 오늘날의 소프트웨어 개발에서 중요한 역할을 하며 클라우드 환경에서는 더욱 그렇습니다.
그럼에도 불구하고 가장 과소평가된 전달 단계 중 하나이기도 합니다. 회사는 일반적으로 배포를 빠르고 안정적이고 자동화하는 등의 작업에 충분한 시간과 에너지를 투자하지 않습니다.
대부분의 경우 여전히 다양한 형태의 수동 배포 절차를 봅니다. 더 좋은 경우에는 적어도 적절하게 문서화된 단계 체크리스트가 있습니다. 최악의 경우 마지막 몇 분 동안 즉흥적으로 만든 임의의 계획입니다.
자동화된 배포 절차는 항상 먼 목표이며 단기 및 중기 로드맵 자리 표시자이지만 실제 경로는 울퉁불퉁하고 예측할 수 없습니다. 그러나 완전히 자동화되고 안정적인 배포 절차를 갖추는 것이 시간이 지남에 따라 상당한 비용 절감의 핵심입니다. 그런 다음 대부분의 개발 팀이 모든 프로덕션 릴리스를 배포하기 위해 일반적으로 소비하는 노력을 제거할 수 있습니다.
Canary 및 Blue-Green 배포 전략은 이러한 모든 이점을 활용하고 더 많은 고가용성, 빠른 설치 및 롤백 프로세스를 추가합니다. 팀이 잠 못 이루는 밤 없이 더 자주 릴리스할 수 있습니다. 그들이 무엇을 가져오고 어떻게 다른지 살펴봅시다.
목차
블루-그린 배포: 개요
원천: cncf.io
Blue-Green 배포는 활성(파란색) 및 비활성(녹색)의 두 가지 동일한 환경을 만들어 다운타임과 새 소프트웨어 버전의 위험을 줄입니다.
활성 환경은 소프트웨어의 현재 버전이 실행되고 사용자가 생산 트래픽을 생성하는 곳입니다. 비활성 환경은 새 버전의 소프트웨어가 배포되고 테스트되는 곳입니다.
새 버전이 테스트되고 준비되면 활성 환경에서 비활성 환경으로 트래픽이 전환되어 새로운 활성 환경이 됩니다. 필요에 따라 이 과정을 반복할 수 있습니다.
또한 읽기: Blue-Green 배포 및 DevOps에서의 역할 설명
주요 기능 및 이점
Blue-Green 배포 프로세스의 특정 기능은 다음과 같습니다.
- 두 개의 동일한 환경은 데이터 및 프로세스 관점에서 동일합니다. 블루(활성) 환경은 프로덕션 사용자가 일상적인 프로세스를 실행하는 곳입니다. 녹색(비활성) 환경은 새 배포가 설치되고 항상 파란색과 동기화되는 위치입니다.
- 활성 환경에서 비활성 환경으로 트래픽을 전환하여 새로운 활성 환경으로 만듭니다. 스위치는 즉각적입니다. 모든 배포는 이제 과거의 일입니다. 가동 중지 시간이 없습니다. 사용자는 새로운 환경에 도달하기 위해 아무 것도 할 필요가 없습니다.
- 문제 발생 시 신속한 롤백이 결과입니다. 이렇게 하면 소프트웨어의 새 버전에 문제가 발생할 경우 가동 중지 시간이 최소화되고 응용 프로그램의 가용성이 높게 유지됩니다.
- 자동화된 테스트는 Blue-Green 배포의 핵심 측면입니다. 새 버전의 소프트웨어가 활성 환경에 배포되기 전에 철저하게 테스트되도록 합니다.
- 이 배포는 지속적 배포 파이프라인의 일부이며, 이는 궁극적으로 소프트웨어를 프로덕션으로 더 빠르고 더 자주 릴리스함을 의미합니다. 배포가 이미 완료되었고 트래픽 스위치 자체만 수행하면 되므로 매일 수행할 수 있을 정도로 빠릅니다. 테스트 활동이 빠르다고 가정합니다.
카나리아 배포: 개요
원천: cncf.io
카나리아 배포는 전체 사용자 기반에 롤아웃하기 전에 소규모 사용자 하위 집합에 대한 새로운 기능 또는 업데이트의 점진적 릴리스를 실행합니다.
이 접근 방식에는 소프트웨어의 새 버전을 만들고 소규모 그룹에 배포하는 동시에 나머지 사용자를 위해 이전 버전을 계속 실행하는 것이 포함됩니다. 개발팀은 새 버전이 안정적이고 예상대로 작동하는지 면밀히 모니터링합니다.
모든 것이 순조롭게 진행되면 새 버전이 전체 사용자 기반에 도달할 때까지 더 많은 사용자에게 배포됩니다. 이러한 방식으로 프로젝트 팀은 모든 사용자에게 한 번에 영향을 미칠 수 있는 버그 또는 기타 문제가 발생할 위험을 최소화합니다.
그 목적은 대규모 사용자 기반에 새로운 기능을 도입할 위험을 줄이는 것입니다. 따라서 새 버전으로의 전환이 훨씬 더 원활하게 이루어집니다.
또한 읽기: DevOps에서의 카나리아 배포 및 역할 설명
주요 기능 및 이점
카나리아 배포 프로세스의 특정 기능은 다음과 같습니다.
- 먼저 새 버전을 소규모 사용자 하위 집합에 배포한 다음 시간이 지남에 따라 점차 더 많은 사용자에게 배포합니다. 모든 사용자에게 한 번에 영향을 미칠 수 있는 버그 또는 기타 문제가 발생할 위험을 최소화합니다.
- 새 버전이 안정적이고 예상대로 작동하는지 면밀히 모니터링합니다. 개발자는 새 버전에 대한 피드백을 더 빨리 받을 수 있으므로 전체 사용자 기반에 배포하기 전에 필요한 조정을 할 수 있습니다.
- 문제가 발생하면 빠르고 쉽게 배포를 이전 버전으로 롤백하십시오. 이렇게 하면 사용자 환경에 영향을 줄 수 있는 문제가 발생할 위험이 줄어들기 때문에 배포 프로세스에서 개발자와 이해 관계자의 신뢰를 높이는 데 도움이 됩니다.
- 인적 오류의 위험을 줄이기 위해 배포 프로세스를 최대한 자동화합니다.
요약: 블루-그린 배포와 카나리아 배포 비교
기능청록색 배포카나리아 배포데이터 동기화청색 환경과 녹색 환경 간의 지속적인 데이터 동기화.사용자 또는 서버의 하위 집합이 새 버전을 받습니다. 나머지는 현재 버전을 계속 사용합니다.활성화 프로세스새 버전이 준비되면 활성 환경에서 비활성 환경으로 전환합니다.새 버전을 적극적으로 테스트하는 정의된 사용자 하위 집합에 대한 점진적 롤아웃입니다.생산 사용자 경험생산 중단 시간이 없습니다. 활성 환경 간의 원활한 전환. 프로덕션 사용자의 하위 집합이 새 버전을 적극적으로 테스트합니다. 이 그룹의 잠재적 문제.고가용성 대 피드백 속도고가용성에 우선 순위.빠른 피드백 및 제어된 롤아웃에 우선 순위.위험 완화사용자 하위 집합에 대한 점진적 릴리스를 통해 문제 가능성 감소.주로 비활성 환경에서 테스트. 테스터는 모든 실제 문제를 파악하지 못할 수 있습니다. 테스트 접근 방식주로 비활성 환경에서 테스트합니다. 테스터가 모든 실제 문제를 파악하지 못할 수도 있습니다. 프로덕션 사용자는 테스터 역할을 하여 실제 문제를 조기에 발견합니다. 주목할만한 사용 사례Netflix, Amazon, Etsy, LinkedIn 및 IBM은 Blue-Green을 사용합니다.Netflix 및 Google은 자동 테스트와 함께 Canary를 사용합니다. 그리고 점진적인 롤아웃.
Blue-Green 배포와 Canary 배포 비교: 기능
전개
블루-그린 배포는 두 가지 환경(블루 및 그린)을 의미합니다. 그러나 동시에 두 환경은 데이터 측면에서 지속적으로 동기화됩니다. 이로 인해 두 환경 간의 영구 데이터 동기화 프로세스에 대한 요구가 증가합니다.
새 버전이 테스트되고 준비된 것으로 간주되면 트래픽이 활성 환경에서 비활성 환경으로 전환되어 새로운 활성 환경이 됩니다.
새 코드를 배포하는 데 시간을 소비하지 않으며 생산 중단 시간도 없습니다. 모든 프로덕션 사용자는 현재 활성 환경에서 항상 작업하며 전환을 인식하지도 못합니다.
원천: aws.amazon.com
카나리아 배포에는 대부분의 사용자 또는 서버가 현재 버전을 계속 사용하는 동안 소규모 사용자 하위 집합에 새 버전의 소프트웨어를 배포하는 작업이 포함됩니다. 이는 전체 스위치가 아닌 점진적 배포입니다. 이 경우 테스터는 정의된 하위 집합일지라도 직접적인 프로덕션 사용자입니다. 이 그룹은 프로덕션 프로세스를 통해 새 버전을 적극적으로 테스트하고 있으며 최종적으로 안정되면 새 버전이 나머지 사용자에게 확산됩니다.
고가용성이 우선인 경우 Blue-Green 배포를 선택해야 합니다. 더 빠른 피드백과 더 통제된(느리지만) 롤아웃을 선호하는 경우 Canary 배포를 선호할 수 있습니다.
위험 차이 완화
Blue-Green 배포는 안정적인 이전 버전으로 빠르게 전환하여 릴리스 실패 위험을 완화합니다. 모든 사용자에게 즉시 제공됩니다. 분명히 롤백의 경우 사용자에게 새로운 기능이 지연될 위험이 여전히 있지만 새 릴리스의 몇 가지 중요한 문제로 인해 적어도 사용자 중 누구도 차단되지 않습니다.
Canary 배포 위험 완화 전략은 문제 가능성을 점진적으로 줄이는 데 있습니다. 새 기능은 프로덕션 사용자의 하위 그룹에 릴리스되기 때문에 릴리스가 모든 사용자에게 배포되기 전에 이미 해당 소프트웨어 버전을 사용하고 있습니다. 초기 사용자가 이러한 문제를 곧 발견할 가능성이 매우 높습니다.
테스트 접근 차이
Blue-Green 배포는 비활성 환경에 대한 테스트 프로세스만 남겨둡니다. 여기서 개발자, 테스터 및 다양한 이해 관계자는 원하는 모든 것을 테스트할 수 있습니다. 테스트가 활성 프로덕션 환경에서 직접 실행되는 것처럼 항상 유사한 동작을 기대할 수 있습니다(데이터 및 구성이 두 환경 간에 항상 동기화되기 때문).
따라서 귀하의 테스터는 테스트 쇼를 실행하고 있으며 실제 프로덕션 사용자가 수행할 모든 문제를 포착하지 못할 가능성이 여전히 있습니다. 그러나 비활성 환경과 활성 환경 간의 전환이 항상 빠르기 때문에 이는 실제로 문제가 되지 않습니다. 그런 다음 개발자가 문제를 수정하고 전환을 다시 수행하도록 할 수 있습니다.
원천: ibm.com
카나리아 배포를 통해 프로덕션 사용자를 테스터로 사용할 수 있습니다. 이러한 사용자는 일반적으로 더 짧은 시간에 더 많은 문제를 찾는 경향이 있습니다. 그들은 단순히 일상적인 비즈니스 프로세스를 완전한 종단 간 방식으로 실행합니다.
그러한 테스트 시나리오와 사례를 구성했기 때문이 아니라 어쨌든 그렇게 해야 하기 때문입니다. 그룹의 사람들이 한동안 심각한 문제를 겪게 될 위험이 있습니다. 그러나 대부분의 사용자에게 영향을 미치지 않으며 개발 팀은 가장 심각한 실제 문제에 즉시 집중할 수 있습니다.
경험 및 사용 사례
다음은 이러한 배포가 이미 성공적으로 실행되고 있는 알려진 사용 사례 중 일부입니다.
- Netflix는 Blue-Green 배포를 사용하여 스트리밍 서비스의 새 버전을 배포합니다.
- Amazon과 Etsy는 Blue-Green 배포를 사용하여 전자 상거래 플랫폼의 새 버전을 배포합니다.
- LinkedIn은 Blue-Green 배포를 사용하여 소셜 네트워킹 플랫폼의 새 버전을 배포합니다.
- IBM은 Blue-Green 배치를 사용하여 클라우드 플랫폼의 새 버전을 배치합니다.
- Netflix는 또한 Canary Deployment를 사용하여 스트리밍 서비스에 대한 변경 사항을 롤아웃합니다. 회사는 자동 테스트, 기능 플래그 및 A/B 테스트를 조합하여 변경 사항을 천천히 적용합니다.
- Google은 카나리아 배포를 사용하여 클라우드 서비스에 변경 사항을 적용합니다. 마찬가지로 이 회사는 자동화된 테스트, 트래픽 분할 및 모니터링 포함의 이점을 사용하여 모든 사용자에게 배포하기 전에 소규모 사용자 하위 집합에 대한 변경 사항을 점진적으로 롤아웃합니다.
모범 사례 및 향후 동향
자동화가 핵심이며 DevOps 파이프라인은 확실히 배포 프로세스의 미래입니다. 이들은 다음과 같은 단계를 포함하는 완전 자동 프로세스입니다.
- 서비스, 데이터, 사용자 또는 권한 측면에서 대상 환경 생성 또는 업데이트.
- 코드 리포지토리에서 직접 소스 코드의 전체/델타 버전을 자동으로 배포합니다.
- 데이터베이스 스키마 업그레이드 및 데이터 새로 고침.
- 배포 활동 중에 직접 자동화된 테스트 실행.
- 중요한 테스트 사례가 성공적으로 완료되지 않은 경우 자동화된 롤백 프로세스.
- 수동 개입 단계를 0으로 제거합니다.
이러한 배포 파이프라인이 있으면 Canary 또는 Blue-Green 프로세스 또는 원하는 다른 것을 연결할 수 있습니다. 그것들은 이미 잘 작동하는 것으로 입증된 두 가지 예에 불과합니다. 그러나 이러한 것들은 배포 활동과 관련된 대부분의 문제를 해결하기 위한 철학적 프레임워크일 뿐입니다. 시간이 지남에 따라 이들 사이를 전환하거나 두 가지를 조합하여 사용하는 것도 어렵지 않습니다.
마지막 말
수동 배포 절차를 고수하는 것은 미숙한 개발 프로세스 또는 팀의 모습입니다. 또는 특정 회사가 소프트웨어 제공 측면에서 얼마나 유연하지 않고 획일적인지 노출할 수 있습니다. 두 경우 모두 현상 유지를 수정하는 데 많은 노력이 필요함을 의미합니다. 따라서 프로젝트에 대해 위에서 언급한 배포 전략을 구현해 보십시오.
다음으로 Kubernetes에서 애플리케이션을 배포하는 방법을 확인합니다.