안전한 배포 사례
릴리스가 기대에 부합하지 않는 경우가 있습니다. 모범 사례를 사용하고 모든 품질 게이트를 전달했음에도 불구하고 프로덕션 배포로 인해 사용자에게 예기치 않은 문제가 발생하는 문제가 가끔 있습니다. 이러한 문제의 영향을 최소화하고 완화하기 위해 DevOps 팀은 지정된 릴리스의 노출과 검증된 성능의 균형을 맞추는 점진적 노출 전략을 채택하는 것이 좋습니다. 릴리스는 프로덕션에서 증명되므로 모든 사용자가 사용할 때까지 광범위한 대상 계층에서 사용할 수 있게 됩니다. 팀은 프로덕션에서 릴리스의 품질과 속도를 최대화하기 위해 안전한 배포 방법을 사용할 수 있습니다.
고객에 대한 노출 제어
DevOps 팀은 다양한 사례를 사용하여 고객에게 업데이트 노출을 제어할 수 있습니다. 지금까지 A/B 테스트는 다양한 버전의 서비스 또는 사용자 인터페이스가 대상 목표에 대해 수행하는 방식을 확인하려는 팀에게 널리 사용되는 선택이었습니다. A/B 테스트는 일반적으로 사소한 변경 내용이며 종종 서비스의 고객 연결 에지에서 다른 릴리스만 비교하기 때문에 비교적 사용하기 쉽습니다.
링을 통한 금고 배포
플랫폼이 성장함에 따라 인프라 규모와 대상 그룹 요구도 증가하는 경향이 있습니다. 이렇게 하면 새 배포와 관련된 위험과 약속하는 업데이트의 이점의 균형을 맞추는 배포 모델에 대한 수요가 생성됩니다. 일반적인 아이디어는 지정된 릴리스가 위험 허용 오차가 가장 높은 소수의 사용자 그룹에만 먼저 노출되어야 한다는 것입니다. 그런 다음 릴리스가 예상대로 작동하는 경우 더 광범위한 사용자 그룹에 노출될 수 있습니다. 문제가 없는 경우 모든 사용자가 새 릴리스를 사용할 때까지 더 광범위한 사용자 그룹 또는 링을 통해 프로세스를 계속할 수 있습니다. GitHub Actions 및 Azure Pipelines와 같은 최신 지속적인 업데이트 플랫폼을 사용하여 링으로 배포 프로세스를 빌드하면 모든 규모의 DevOps 팀에서 액세스할 수 있습니다.
기능 플래그
특정 기능은 릴리스의 일부로 배포해야 하지만 처음에는 사용자에게 노출되지 않는 경우가 있습니다. 이러한 경우 기능 플래그는 환경, 링 또는 기타 특정 배포에 따라 구성 변경을 통해 기능을 사용하도록 설정할 수 있는 솔루션을 제공합니다.
사용자 옵트인
기능 플래그와 마찬가지로 사용자 옵트인은 노출을 제한하는 방법을 제공합니다. 이 모델에서 지정된 기능은 릴리스에서 사용하도록 설정되지만, 특별히 원하지 않는 한 사용자에 대해서는 활성화되지 않습니다. 위험 허용 오차 결정은 특정 업데이트를 얼마나 빨리 채택할지 결정할 수 있도록 사용자에게 오프로드됩니다.
여러 사례가 일반적으로 동시에 사용됩니다. 예를 들어 팀에는 매우 구체적인 사용 사례를 위한 실험적 기능이 있을 수 있습니다. 위험하기 때문에 내부 사용자가 사용해 볼 수 있도록 첫 번째 링에 배포합니다. 그러나 기능이 코드에 있더라도 사용자 인터페이스를 통해 기능이 노출되도록 링 내의 특정 배포에 대한 기능 플래그를 설정해야 합니다. 그럼에도 불구하고 기능 플래그는 사용자가 새 기능을 사용하도록 옵트인하는 옵션만 노출할 수 있습니다. 링에 없거나, 해당 배포에서, 또는 옵트인하지 않은 사람은 이 기능에 노출되지 않습니다. 이는 상당히 모순된 예이지만 점진적 노출의 유연성과 실용성을 보여 줍니다.
팀이 초기에 직면하는 일반적인 문제
팀이 더 Agile DevOps 연습을 진행함에 따라 기존의 모놀리식 배달에서 멀어진 다른 팀과 일치하는 문제가 발생할 수 있습니다. 몇 달에 한 번씩 배포하는 데 사용되는 팀은 안정화를 위해 버퍼링하는 사고 방식을 가지고 있습니다. 각 배포는 서비스에 상당한 변화를 가져올 것이며 예기치 않은 문제가 있을 것으로 예상합니다.
페이로드가 너무 큽니다.
몇 개월마다 배포되는 서비스는 일반적으로 많은 변경 내용으로 채워집니다. 이렇게 하면 즉각적인 문제가 발생할 가능성이 높아지고 새 항목이 너무 많기 때문에 이러한 문제를 해결하기가 어려워집니다. 더 빈번한 배달로 이동하면 배포되는 항목의 차이가 작아지게 되므로 더 집중적인 테스트와 더 쉽게 디버깅할 수 있습니다.
서비스 격리 없음
모놀리식 시스템은 일반적으로 배포되는 하드웨어를 평준화하여 확장됩니다. 그러나 인스턴스에 문제가 발생하면 모든 사람에게 문제가 발생합니다. 한 가지 간단한 해결 방법은 여러 인스턴스를 추가하여 사용자의 부하를 분산하는 것입니다. 그러나 다중 인스턴스로 빌드되지 않은 많은 레거시 시스템을 사용하려면 아키텍처를 고려해야 할 수 있습니다. 또한 다른 곳에서 더 잘 통합될 수 있는 기능을 위해 상당한 중복 리소스를 할당해야 할 수 있습니다.
새로운 기능이 추가됨에 따라 마이크로 서비스 아키텍처가 더 나은 서비스 격리 덕분에 운영 및 크기를 조정하는 데 도움이 되는지 살펴보세요.
수동 단계를 수행하면 실수가 발생합니다.
팀이 연간 몇 번만 배포하는 경우 배달 자동화는 투자 가치가 없는 것처럼 보일 수 있습니다. 따라서 많은 배포 프로세스가 수동으로 관리됩니다. 이렇게 하려면 상당한 시간과 노력이 필요하며 사람의 오류가 발생하기 쉽습니다. 가장 일반적인 빌드 및 배포 작업을 자동화하기만 하면 손실된 시간과 강제되지 않은 오류를 줄일 수 있습니다.
또한 Teams는 인프라를 코드 로 사용하여 배포 환경을 더 잘 제어할 수 있습니다. 이렇게 하면 다양한 배포 환경에 새로운 기능 또는 종속성이 도입됨에 따라 운영 팀에 대한 요청이 수동으로 변경될 필요가 없습니다.
Ops만 배포를 수행할 수 있습니다.
일부 조직에는 운영 직원이 모든 배포를 시작하고 관리해야 하는 정책이 있습니다. 과거에는 그럴 만한 이유가 있었을 수 있지만, 개발 팀이 배포를 시작하고 제어할 수 있을 때 Agile DevOps 프로세스는 큰 이점을 제공합니다. 최신 지속적인 업데이트 플랫폼은 배포를 시작할 수 있는 사용자와 상태 로그 및 기타 진단 정보에 액세스할 수 있는 사용자를 세부적으로 제어하여 적절한 사용자가 가능한 한 빨리 올바른 정보를 갖도록 합니다.
잘못된 배포가 진행 중이며 롤백할 수 없습니다.
배포가 잘못되어 팀에서 해결해야 하는 경우가 있습니다. 그러나 프로세스가 수동이며 정보에 대한 액세스가 느리고 제한된 경우 이전 작업 배포로 롤백하기 어려울 수 있습니다. 다행히 배포 실패의 위험을 완화하기 위한 다양한 도구와 사례가 있습니다.
핵심 원칙
안전한 배포 사례를 채택하려는 팀은 노력을 뒷받침하기 위해 몇 가지 핵심 원칙을 설정해야 합니다.
일관성 유지
프로덕션 환경에서 배포하는 데 사용되는 것과 동일한 도구를 개발 및 테스트 환경에서 사용해야 합니다. 새 버전의 종속성 또는 도구에서 자주 발생하는 것과 같은 문제가 있는 경우 코드가 프로덕션에 릴리스되기 전에 잘 catch되어야 합니다.
품질 신호에 대한 관심
너무 많은 팀이 품질 신호에 대해 별로 신경 쓰지 않는 일반적인 함정에 빠지게 됩니다. 시간이 지남에 따라 노란색 경고를 녹색 승인으로 변경하기 위해 테스트를 작성하거나 품질 작업을 수행한다는 것을 알 수 있습니다. 품질 신호는 프로젝트의 펄스를 나타내기 때문에 매우 중요합니다. 배포를 승인하는 데 사용되는 품질 신호는 매일 지속적으로 추적되어야 합니다.
배포에는 가동 중지 시간이 필요하지 않습니다.
모든 서비스를 항상 사용할 수 있는 것은 아니지만 팀은 언제든지 중단하지 않고도 새 버전을 배포할 수 있고 배포해야 한다는 마음가짐으로 DevOps 배달 및 운영 단계에 접근해야 합니다. 최신 인프라 및 파이프라인 도구는 거의 모든 팀이 100% 가동 시간을 목표로 할 수 있는 정도로 고급입니다.
작업 시간 동안 배포가 수행되어야 합니다.
팀이 배포에 가동 중지 시간이 필요하지 않다는 사고 방식을 사용하는 경우 배포가 푸시될 때는 중요하지 않습니다. 또한 작업 시간, 특히 이른 시간 및 주 초에 배포를 푸시하는 것이 유리합니다. 문제가 발생하면 폭발 반경을 제어할 수 있을 만큼 일찍 추적해야 합니다. 또한 모든 사용자가 이미 작업하고 문제를 해결하는 데 집중할 것입니다.
링 기반 배포
완성도가 높은 DevOps 릴리스 사례가 있는 팀은 링 기반 배포를 수행할 수 있는 위치에 있습니다. 이 모델에서는 가장 큰 위험을 감수하고자 하는 고객에게 새로운 기능이 먼저 배포됩니다. 배포가 입증되면 모든 사용자가 배포를 사용할 때까지 대상 그룹은 더 많은 사용자를 포함하도록 확장됩니다.
링 모델 예제
일반적인 링 배포 모델은 사용자 및 인프라의 세분화를 통해 가능한 한 빨리 문제를 찾을 수 있도록 설계되었습니다. 다음 예제에서는 Microsoft의 주요 팀에서 링을 사용하는 방법을 보여줍니다.
| 링 | 목적 | 사용자 | 데이터 센터 |
|---|---|---|---|
| 0 | 배포에서 도입된 대부분의 사용자에게 영향을 미치는 버그를 찾습니다. | 내부 전용, 위험 및 버그에 대한 높은 허용 오차 | 미국 중서부 |
| 1 | 팀이 광범위하게 테스트하지 않는 영역 | 제품의 폭을 사용하는 고객 | 작은 데이터 센터 |
| 2 | 크기 조정 관련 문제 | 공용 계정, 다양한 기능 집합을 사용하는 이상적으로 무료 계정 | 중간 또는 큰 데이터 센터 |
| 3 | 내부 계정의 문제 및 국제 관련 문제 크기 조정 | 대규모 내부 계정 및 유럽 고객 | 내부 데이터 센터 및 유럽 데이터 센터 |
| 4 | 배율 단위 다시 기본 | 다른 모든 사용자 | 모든 배포 대상 |
베이킹 시간 허용
베이킹 시간이라는 용어는 다음 링으로 확장하기 전에 배포를 실행할 수 있는 시간을 나타냅니다. 일부 문제는 증상 표시를 시작하는 데 몇 시간 이상이 걸릴 수 있으므로 릴리스가 준비된 것으로 간주되기 전에 적절한 시간 동안 사용해야 합니다.
일반적으로 24시간은 대부분의 시나리오에서 잠재적 버그를 노출하는 데 충분한 시간이어야 합니다. 그러나 이 기간에는 사용량이 가장 많은 기간이 포함되어야 하며, 업무 시간 중에 최고조에 달하는 서비스에는 전체 영업일이 있어야 합니다.
핫픽스 신속한 처리
LSI(라이브 사이트 인시던트)는 버그가 프로덕션에 심각한 영향을 미칠 때 발생합니다. LSI는 우선 순위가 높은 문제를 해결하도록 설계된 대역 외 업데이트인 핫픽스를 생성해야 합니다.
버그가 가장 심각한 버그 유형인 Sev 0인 경우 핫픽스는 책임감 있게 가능한 한 빨리 영향을 받은 배율 단위에 직접 배포될 수 있습니다. 수정이 상황을 악화시키지 않는 것이 중요하지만, 이 심각도의 버그가 너무 파괴적인 것으로 간주되어 즉시 해결해야 합니다.
Sev 1 등급의 버그는 링 0을 통해 배포해야 하지만 승인되는 즉시 영향을 받는 배율 단위로 배포할 수 있습니다.
심각도가 낮은 버그의 핫픽스는 계획대로 모든 링을 통해 배포해야 합니다.
핵심 내용
모든 팀은 가능한 한 빠르고 높은 품질로 업데이트를 제공하고자 합니다. 올바른 사례를 사용하면 DevOps 주기에서 생산적이고 고통이 없는 부분이 될 수 있습니다.
- 자주 배포합니다.
- 스프린트 전체에서 녹색으로 유지합니다.
- 개발, 테스트 및 프로덕션에서 일관된 배포 도구를 사용합니다.
- 자동화 및 권한 부여를 허용하는 지속적인 업데이트 플랫폼을 사용합니다.
- 안전한 배포 사례를 따릅니다.
다음 단계
기능 플래그가 사용자에게 새 기능의 노출을 제어하는 데 어떻게 도움이 되는지 알아봅니다.