DevOps 텍스트 교육

프로덕션에 DevOps 코드를 낮은 위험으로 어떻게 배포하나요?

많은 IT 조직에서 프로덕션 배포는 번거롭고 스트레스가 많습니다. 문제를 피하기 위해 가능한 한 배포 횟수를 줄이려는 경향이 생깁니다. 그 결과 조직은 더 큰 배치로 배포할 수밖에 없고, 더 큰 문제가 생깁니다. 이 파괴적인 악순환은 계속 심해지며, 안타깝게도 소프트웨어와 기술이 핵심 사업인 곳을 포함해 많은 대규모 조직의 현주소를 보여 줍니다.

DevOps 팀에는 통제와 위험 완화 장치가 내장되어 있습니다

일반적인 IT 조직에서는 개발팀이 소프트웨어를 구축하고 운영팀이 배포를 맡습니다. DevOps는 통제와 위험 완화의 책임을 외부 독립 팀에서 역량과 자율성을 갖춘 자체 팀으로 옮깁니다. 팀 내부의 자동 배포와 동료 검토 절차에 의존합니다.

프로덕션과 비프로덕션 환경은 모두 DevOps 팀이 만드는 소프트웨어만큼 중요한 자산입니다. 따라서 팀은 세 가지 중요한 원칙을 따릅니다.

1. 운영체제, 구성 요소, 인터페이스, 패치 수준, 기타 모든 종속성과 자체 소프트웨어 및 구성에 대해 모든 환경의 일관성을 확보합니다.
2. 환경의 일관성을 깨뜨리는 장애물을 수정하는 것이 최우선입니다.
3. 모든 환경에 같은 기법으로 배포해 프로덕션 배포 리허설을 일상적인 업무와 습관으로 만듭니다.

내장된 셀프서비스 배포 방식

자동화된 셀프서비스 배포는 다음 패턴을 따릅니다.

1. 코드를 작성해 트렁크에 체크인합니다.
2. 배포 가능한 패키지를 빌드합니다.
3. 배포 가능한 패키지, 종속성 및 구성의 준비 상태를 검증합니다.
4. 환경의 준비 상태를 검증합니다.
5. 자동화된 테스트를 실행합니다.
6. 감사 및 규정 준수를 위해 모든 검증 결과와 자동화된 테스트 결과를 기록합니다.
7. 대상 환경에 패키지를 배포합니다.
8. 대상 환경에서 자동화된 테스트를 실행해 배포를 검증합니다.
9. 대상 환경의 시스템, 성능, 활동 지표를 모니터링합니다.
10. 빠르게 피드백하고 문제가 발생하면 배포를 수정하거나 롤백합니다.

배포와 릴리스는 서로 다른 작업입니다

비프로덕션 및 프로덕션에 코드를 배포하는 자동화된 셀프서비스 방식으로 DevOps 팀은 매일 배포할 수 있게 됩니다. 모든 배포를 고객을 위한 기능 또는 혜택의 릴리스로 분류할 수는 없습니다. 따라서 릴리스에 코드 변경이나 그에 따른 추가 배포가 필요하지 않도록 애플리케이션 및/또는 환경의 아키텍처를 설계해야 합니다.

블루-그린 배포 패턴

배포 자동화의 과제 중 하나는 테스트의 마지막 단계에서 가동 중인 프로덕션으로 소프트웨어를 옮기는 전환 자체입니다. 가동 중단을 최소화하려면 대개 신속히 전환해야 합니다. 블루-그린 배포는 최대한 동일한 프로덕션 환경을 두 개 두는 방식입니다. 어느 시점에든 둘 중 하나가 가동 중입니다. 여기서는 블루가 가동 중이라고 가정합니다. 새 소프트웨어 릴리스를 준비할 때 그린 환경에서 마지막 테스트를 합니다. 그린 환경에서 소프트웨어가 작동하면 라우터를 전환해 모든 수신 요청을 그린으로 보냅니다. 블루 환경은 이제 유휴 상태입니다.

카나리 배포 패턴
(다크 론치라고도 합니다)

카나리아는 한때 탄광에서 조기 경보 수단으로 널리 사용되었습니다. 광산의 메탄이나 이산화탄소 같은 유독 가스는 광부에게 영향을 미치기 전에 새를 죽였습니다. 새가 고통스러워하는 징후가 나타나면 광부들은 환경이 위험하다는 것을 알았습니다.

광업의 카나리아에서 영감을 받은 카나리 배포는 일부 사용자 또는 서버에 릴리스를 내놓는 패턴입니다. 먼저 소수의 서버에 변경을 배포해 테스트한 다음 나머지 서버에 배포합니다. 카나리 배포는 가동 중단의 영향이 적은 조기 경보가 됩니다. 카나리 배포에 실패해도 나머지 서버는 영향을 받지 않습니다.

Facebook, Google을 비롯한 여러 대형 기술 기업은 ‘다크 론치’라는 카나리 배포 패턴을 사용합니다. 전체에 릴리스하기 전에 소수의 사용자에게 새 기능을 점진적으로 릴리스하고 테스트합니다. 사용자가 좋아하는지 싫어하는지 확인하고, 시스템 성능에 어떤 영향이 있는지 평가할 수 있습니다. Facebook은 소비자의 새 기능 접근을 제어하므로 다크 론치 도구를 ‘Gatekeeper’라고 부릅니다.

보통 이러한 기능 릴리스를 공개하지 않고 사용자의 1%, 5%, 30% 순서로 조용히 제공하기 때문에 다크 론치라고 합니다. 새 기능이 며칠간 다크 론치되었다가 다시는 보이지 않을 때도 있습니다. 성과가 좋지 않았거나 기업이 개발 방향을 정할 초기 피드백만 필요했을 가능성이 큽니다.

클러스터 면역 체계 릴리스 패턴

이 릴리스 패턴은 카나리 배포 패턴을 확장합니다. 성능 및 소프트웨어 활동 모니터링 시스템을 릴리스 절차와 긴밀히 통합해야 합니다.

위 그림의 카나리 배포에서 주황색 서버에 초기 배포가 끝나면 모니터링 시스템이 모든 시스템, 성능 및 소프트웨어 활동 지표를 기록합니다. 문제가 특정 임계값을 넘어 늘어나면 조기 경보를 내고, 주황색 서버에 설치된 코드를 자동으로 롤백합니다.

주황색 서버의 자동화된 테스트와 모니터링에서 좋은 결과가 나오면 DevOps 팀은 나머지 모든 파란색 서버 클러스터에도 훨씬 안심하고 코드를 배포할 수 있습니다. 요약하면 클러스터 면역 체계 릴리스 패턴은 DevOps 팀에 다음을 제공합니다.

• 자동화된 테스트에서 놓칠 수 있는 문제에 대한 추가 보호 장치.
• 프로덕션 문제에 대한 빠른 피드백과 자동 롤백.

기능 토글

기능 토글로 애플리케이션 기능을 켜고 끌 수 있습니다. 특정 기능에 필요한 코드가 모두 프로덕션 시스템에 배포되면, 토글을 켜는 것만으로 기능을 릴리스할 수 있습니다. 기능 토글은 대개 런타임 시스템 구성 파일이나 시스템 구성 데이터베이스의 설정입니다.

카나리 배포로 오류가 발생하거나 사용자 경험이 좋지 않으면, 기능 토글로 해당 기능을 끌 수 있습니다. 시스템 확장에 어려움이 있을 때는 자원을 많이 쓰지만 상대적으로 덜 중요한 기능을 비활성화할 수도 있습니다. 모든 기능을 실행한 상태로 확장하기 어렵더라도 고객이 핵심 기능에서 최대 처리량을 얻도록 할 수 있습니다. 예를 들어 전자상거래 포털에서 청구서 보기 기능을 잠시 꺼 결제 흐름에 더 많은 CPU와 메모리 자원을 할당할 수 있습니다.

또한 서비스 지향 아키텍처에서는 여러 버전의 서비스를 켜지 않고도 배포할 수 있습니다. 새 기능 또는 서비스 흐름에 필요한 새 서비스 버전을 모두 배포한 뒤 해당 토글을 켜 새 서비스 흐름을 활성화합니다.

더 안전한 릴리스를 위한 아키텍처 설계

모든 규모와 모든 소프트웨어 제품 및 서비스에 완벽하게 맞는 아키텍처는 없습니다.

스타트업이 처음 IT 플랫폼을 구축할 때는 대개 모놀리식 아키텍처를 선택합니다. 시장에 가장 빠르고 저렴하게 진입하고 사업 타당성을 검증하기 위해서입니다. 모놀리식 아키텍처의 문제는 핵심 기능, 보조 기능, 사용자 및 시스템 인터페이스와 통합 등 기능적으로 구분할 수 있는 부분이 별도 구성 요소로 나뉘지 않고 얽혀 있다는 것입니다. Amazon, Google, Facebook, Ebay 등 여러 대형 조직은 성장 과정에서 빠르게 확장하고 고객에게 제공하는 기능을 낮은 위험으로 릴리스하고 확장하기 위해 모놀리식 아키텍처를 포기해야 했습니다. 다음으로 향한 방향은 스트랭글러 애플리케이션 패턴을 적용한 서비스 또는 마이크로서비스 지향 아키텍처였습니다.

스트랭글러 애플리케이션 패턴으로 마이크로서비스 마이그레이션 위험 줄이기

복잡한 시스템을 완전히 교체하는 일은 규모가 클 수 있습니다. 아직 이전하지 않은 기능을 위해 기존 시스템을 유지하며 새 시스템으로 점진적으로 이전해야 할 때가 많습니다. 그러나 두 가지 애플리케이션 버전을 별도로 실행하면 클라이언트가 각 기능의 위치를 알아야 합니다. 기능이나 서비스를 이전할 때마다 클라이언트가 새 위치를 가리키도록 업데이트해야 합니다.

스트랭글러 애플리케이션 패턴은 특정 기능을 새 애플리케이션과 서비스로 점진적으로 교체합니다. 백엔드 레거시 시스템으로 가는 요청을 가로채는 파사드를 만듭니다. 파사드는 요청을 레거시 애플리케이션이나 새 서비스로 전달합니다. 기존 기능을 새 시스템으로 점진적으로 이전할 수 있으며, 이용자는 이전 사실을 알지 못한 채 같은 인터페이스를 계속 사용할 수 있습니다.

Ebay는 스트랭글러 애플리케이션 패턴으로 레거시 모놀리식 아키텍처를 마이크로서비스로 이전한 초기 조직 중 하나입니다. Ebay 생태계에서 잘 정의된 공통 API 뒤에 애플리케이션을 두는 것부터 시작했으므로 한 번에 기존 코드를 모두 다시 작성할 필요가 없었습니다. 엔지니어링 조직을 엔지니어 6~10명으로 구성된 소규모 팀으로 재편했습니다. 이제 최대 10명인 팀 하나가 경매 플랫폼 공통 API를 처리할 수 있습니다. 이 API는 전 세계에서 가장 많이 사용하는 경매 API입니다.

결론

대다수 IT 부서에서 팀은 미래에 대응할 수 있고 확장 가능하며 더 안전한 배포 패턴과 관련 아키텍처를 구축하는 데 책임을 지지 않습니다. 하지만 빠르고 안전한 배포를 지원하는 아키텍처와 기능을 구축하는 일은 DevOps에서 성공하는 중요한 전제 조건입니다.

매일 더 빠르게 낮은 위험으로 배포할 수 있어야 팀이 지속적 배포와 원활한 릴리스의 이점을 누릴 수 있습니다.