본 문서는 총 2부로 구성되어 있으며 이 글은 2부입니다.
1부 링크 : 클라우드상의 변경 관리 모범 사례 1/2
클라우드의 변경 관리
모든 변화는 비즈니스 가치를 제공하는 것이어야 하며, 변경 관리는 낭비되는 노력이나 비용을 최소화하면서 생산성을 극대화하는 방식으로 비즈니스 리스크를 최적화하는 데 집중해야 합니다. AWS 클라우드는 다음과 같은 방법으로 이러한 비즈니스 위험을 최적화하는 자동화를 지원합니다.
· 작업자의 실수 가능성을 최소화합니다.
· 예측 가능하고 테스트 가능한 변경 결과를 위해 동일한 환경을 만들 수 있습니다.
· 비즈니스 수요를 충족하기 위해 인프라 확장 시 변경 사항을 제출해야 하는 요구사항을 제거합니다.
· 장애로부터 자동으로 복구하고 실패한 변경 사항을 롤백합니다.
자동화의 이점은 변화와 관련된 비즈니스 위험을 크게 줄이고 비즈니스 민첩성을 높여 궁극적으로 더 많은 비즈니스 가치를 제공할 수 있습니다.
변경 관리의 핵심 개념은 AWS Cloud에서 그대로 유지됩니다. 변화는 비즈니스 가치를 제공하며 효율적이어야 합니다. 신속한 변화를 위한 방법론과 AWS 클라우드의 자동화 기능은 비즈니스 가치를 신속하고 효율적으로 제공하도록 설계되었기 때문에 변경 관리의 핵심 원칙과 함께 제공됩니다. 기존 변경 프로세스를 새로운 변경 방식에 맞게 수정해야 할 수 있는 몇 가지 핵심 영역이 있습니다.
클라우드의 구성 항목
예를 들어 애플리케이션 업데이트 및 운영 체제 패치가 서버에 설치되거나 배포되는 기존 IT 환경에서 애플리케이션에 장애가 발생하는 경우 엔지니어가 조사하여 수정 작업을 적용하거나 새 서버를 배포해야 할 수 있습니다. 이러한 작업 중 어느 하나라도 최소한 긴급한 변경이 필요하며 상당한 시간 동안 비즈니스를 위험에 빠뜨릴 수 있습니다. AWS Cloud에서는 자동 확장 그룹을 사용하여 이 프로세스를 자동화할 수 있습니다. 미리 정의된 상태 점검을 사용하여 오류를 자동으로 감지하고 서버를 정확히 동일한 구성으로 자동 교체할 수 있습니다. 이 간단한 시나리오는 자동화의 분명한 이점을 보여줍니다. 인적 오류가 제거되고, 구성 지연이 제거되며, 복구 시간이 크게 단축됨에 따라 비즈니스 위험이 최소화됩니다.
또한 자동 확장 그룹을 사용하여 비즈니스 요구를 충족하기 위해 추가 리소스를 자동으로 프로비저닝할 수도 있습니다. 다시 말해, 기존 환경에서는 서버를 추가하기 전에 여러 비즈니스 프로세스가 필요했을 수 있으며, 변경 관리에 접근하기 전에 요구 사항을 구현하기 위한 표준 또는 일반적인 변경이 필요했을 수 있습니다. 최상의 시나리오에서는 용량을 늘리기 위해 많은 작업이 수행되었습니다. 최악의 경우 추가 용량을 도입하는 데 필요한 모든 비즈니스 프로세스에 의해 비즈니스에 영향을 미치고 위험에 처하게 됩니다. 또한, 필요한 시기에 비즈니스 수요를 충족시키지 못했을 수도 있습니다.
이 예에서는 장애로부터 복구하거나 비즈니스 요구를 충족하기 위해 용량을 확장하는 데 필요한 수동 승인 단계가 본질적으로 비즈니스에 위험을 초래합니다. 변경 사항은 구성 항목의 추가, 수정, 교체 또는 제거로 간주됩니다. 구성 항목을 변경하기 위해 승인이 필요한 경우 기존 변경 관리 프로세스에서 이러한 자동화된 시나리오를 허용하지 않을 수 있습니다. 이 시나리오에서는 구성 항목으로 간주되는 항목을 재정의하는 데 도움이 될 수 있습니다. 위의 예제에서는 구성 항목이 일시적이고 구성 불가능한 항목이 될 수 있으므로 자동 확장 그룹에 있을 때 구성 항목이 되는 것은 서버 자체가 아닙니다. 서버를 생성하는 데 사용되는 자동 확장 그룹과 이미지는 잘못 구성된 경우 비즈니스를 위험에 빠뜨릴 수 있는 항목이므로 구성 항목으로 간주해야 합니다.
오토메이션
또 다른 주요 고려 사항은 AWS Cloud에 구축할 때 발생하는 비즈니스 리스크를 이해하는 것입니다. 배포가 애플리케이션인지, 패치인지, 구성 변경인지에 관계없이 최적화된 클라우드 구성은 변경되지 않은 파이프라인을 통해 배포 프로세스를 자동화할 수 있습니다. 이를 통해 소프트웨어 테스트, 컴플라이언스 테스트, 보안 테스트 및 기능 테스트의 자동화를 지원할 뿐만 아니라 여러 환경 전반에서 반복성과 일관성을 유지할 수 있습니다.
이는 부정적인 영향을 미치는 변화에 대한 보장이 되지는 않지만 위험을 줄일 수 있으며, 모든 변경에 대해 이러한 자동화된 프로세스를 재고해서는 안 됩니다. 초점을 맞추어야 하는 것은 실제 구성 변경 자체이다. 예를 들어 자동화된 보안 테스트가 배포용으로 승인된 경우 변경 승인 프로세스 중에 보안 검토가 해당 상황에서 대폭 축소되거나 완전히 제거될 수 있습니다. 워크로드 및 워크로드의 라이프사이클 전체에 걸쳐 반복성과 일관성을 구현하면 변경 승인 보드의 변경 사항 검사에 대한 부담을 줄일 수 있습니다. 변화는 어떻게 전달되고(파이프라인) 시험의 자동화가 주안점을 두어야 하며, 이사회의 수동 시험과 정밀 감시를 줄일 수 있는 테스트의 자동화가 주안점을 두어야 합니다. 이 두 가지 테스트는 모두 사람의 실수를 유발하기 쉽습니다.
Remediation
실패의 결과를 고려하지 않고 변경 사항을 승인해서는 안 됩니다. “이상적으로, 조직을 초기 상황으로 되돌릴 수 있는 백아웃 계획이 있을 것입니다. AWS Cloud를 사용하면 반복 가능한 프로세스를 사용하여 백업 계획을 완전히 자동화할 수 있습니다. 모든 변경 사항을 되돌릴 수 있는 것은 아니며, “고장 발생 시 수정 내용을 다시 검토해야 할 수 있습니다.” AWS Cloud 모자의 배포는 자동화된 파이프라인을 사용하여 변경 사항을 신속하고 안전하게 재구축하여 위험을 최소화하고 비즈니스에 미치는 영향을 줄일 수 있습니다. 특정 시나리오에서는 변경 사항을 백업하거나 재배치가 불가능할 수 있습니다. 이 경우 “조직의 비즈니스 연속성 계획을 실행해야 합니다.” 가장 심각한 경우에도 클라우드에서 지속적인 데이터 보호를 사용하면 RPO(복구 시점 목표)를 초 미만으로 달성할 수 있으며, RTO(복구 시간 목표)를 분 단위로 측정할 수 있습니다. 자세한 내용은 AWS의 재해 복구를 참조합니다. 특히 AWS Cloud는 변경 사항을 백업할 수 없는 경우 재해 복구 계획을 더 빠르고 쉽게 재구축하거나 호출하여 실패한 변경으로 인한 비즈니스 위험과 영향을 크게 줄일 수 있는 방법을 제공합니다.
클라우드의 최신 구축 방법을 통해 빠른 롤백을 실현하거나 즉각적인 롤백을 실현할 수 있습니다. 예를 들어 파란색-녹색 배포를 사용하면 구성 변경과 함께 활성 환경(녹색)의 동일한 복사본(녹색)을 배포하여 워크로드를 변경할 수 있습니다.
그런 다음 이전 라이브 환경(파란색)은 사용 가능하지만 유휴 상태인 동안 사용자를 새 환경(녹색)으로 전환할 수 있습니다. 이 시나리오에서는 오류가 발견되면 사용자를 즉시 Blue 환경으로 리디렉션하여 비즈니스에 미치는 영향을 크게 줄일 수 있습니다. 또한 이 접근 방식을 클라우드에서 쉽게 사용할 수 있는 카나리아 릴리스와 결합할 수도 있습니다. 이 접근 방식을 사용하면 사용자 중 일부를 새 배포로 리디렉션하고, 그 효과를 평가하고, 모든 사용자가 새 배포를 사용할 때까지 새 배포의 사용자 수를 점진적으로 늘릴 수 있습니다. 배치 방법을 선택할 때는 다른 고려 항도 있지만, 변경 관리의 핵심은 이와 같은 방식으로 구축된 변경사항의 비즈니스에 대한 리스크가 크게 감소된다는 것입니다.
클라우드에 변경 관리 적용
변경 프로세스를 조정해야 할 수 있는 영역은 두 가지가 있습니다. 실패한 변경으로 인한 비즈니스에 미치는 위험과 영향이 크게 줄어들기 때문에 롤백 계획에 대한 신뢰도를 높이고 보다 빈번하게 변경될 수 있습니다. 그 결과, 고려해야 할 두 번째 영역은 롤백 변경의 수용입니다. 롤백 속도와 일관성으로 인해 실패한 변경이 훨씬 낮은 영향을 미치는 경우 롤백 활성화는 일반적인 프로세스의 일부로 간주해야 합니다. 이는 특히 문제를 신속하게 해결하고 동일한 자동화된 파이프라인을 통해 변경의 원래 의도된 비즈니스 가치를 신속하게 제공할 수 있는 경우에 해당합니다.
이러한 고려사항을 염두에 두고 자동화, 파이프라인 및 구축 방법이 마련되어 있는 경우 표준 변경에 대한 접근 방식을 재고할 수 있습니다. 표준 변경은 변경 요청을 시작하기 위해 정의된 트리거가 있는 경우입니다. ddition에서 표준 변경에서는 작업이 잘 알려져 있고 문서화 및 입증되며, 사전에 권한이 부여되며, 위험은 보통 낮습니다. 적절한 자동화, 테스트 및 구축 전략을 수립할 경우 대규모, 간헐적 및 위험한 변경 사항이 작고 빈번한 위험 변화로 전환되는 시나리오가 발생해야 합니다. AWS Cloud를 통해 실현되는 리스크 감소 전략을 이해함으로써, 기존의 IT 환경에서와 관련된 리스크로 인해 이전에는 정상적인 변경으로 간주되었던 구축까지 포함하도록 표준 변경 범위를 넓힐 필요가 있을 수 있습니다.
신속한 변화를 위한 방법론과 자동화 증가로 인해 변경이 빈번해짐에 따라 변경 관리가 일반적인 변경으로 인해 과도하게 부담되어 대역폭 제약으로 인해 변경이 지연되거나 리소스 제약으로 인해 변경이 제대로 조사되지 않아 중요한 세부 사항이 누락될 위험이 있습니다. 이러한 두 가지 시나리오 모두 변경 관리가 최적화를 목표로 하는 비즈니스 리스크를 도입합니다. 작고 빈번한 변화의 환경에서 표준 변경은 정상적인 변화에 대한 적절한 조사를 통해 비즈니스 리스크를 최적화하고 비즈니스 가치를 제공할 수 있도록 새로운 정상으로 자리매김해야 합니다.
서비스 전환
변경 관리 프로세스를 통해 릴리즈가 승인되고 적절한 프로젝트 관리, 릴리스 및 배포 관리 단계가 모두 수행된 후에는 릴리스가 배포되어 서비스 검증 및 테스트 프로세스에 들어갑니다.
여기서 잠시 기다려 AWS Cloud 내에서 서비스 검증 및 테스트 범위를 결정할 수 있습니다. 이는 보안에 대한 AWS 공유 책임 모델을 이해하는 것이 가장 좋습니다. 서비스의 검증 및 테스트는 이 다이어그램에서 고객의 범위에 해당하는 영역으로 제한되어야 합니다. 그러나 운영을 통해 관리되는 서비스를 서비스로 수락하기 전에 운영 방식을 이해하는 것이 중요합니다.
앞서 언급한 바와 같이 AWS Cloud의 자동화, 통합 및 구축 툴을 통해 기업은 비즈니스 위험을 줄이고 비즈니스 가치를 향상시키는 작고 빈번한 변경을 수행할 수 있습니다. 클라우드의 도입으로 서비스 검증 및 테스트 프로세스가 변경되어서는 안 되지만, 변경률이 높아지면 프로세스 구현과 이해 관계자의 집중도를 변경해야 할 수 있는 검증 및 테스트 요구 사항이 증가할 수 있습니다.
변화는 비즈니스 가치를 도입합니다. 릴리즈는 고객의 기대를 충족하고 IT 운영 팀은 이러한 새로운 비즈니스 가치를 지원할 수 있어야 합니다. 클라우드에서 이 가치를 평가하는 기준은 이미 존재하는 것과 달라서는 안 되며, 조직은 릴리스 증가에 대비하고 프로세스에 자동화를 도입하여 이러한 프로세스의 구현을 조정해야 합니다.
새로운 서비스는 새로운 서비스가 합의 된 서비스 수준 요구 사항을 충족한다는 고객의 동의가 필요합니다. 현재 서비스 수준 목표를 추적하고 SLA (서비스 수준 계약) 위반을 추적하는 현재 모범 사례가 여전히 적용됩니다. 외부 대면 서비스에 대한 타사 모니터링 서비스를 통해 를 수행 할 수 있습니다. 내부 서비스의 경우 서비스의 주요 비즈니스 기능에 대한 모니터링 및 메트릭을 통해 를 추적해야 니다. 서비스의 여러 측면에 대해 별도의 서비스 수준 요구 사항이 존재할 수 있으며, 해당 측면이 측정되고 있음을 나타내는 메트릭으로 추가 차원이 필요할 수 있습니다. 실제로 SLA를 위반하는 경향이 있음을 나타내는 경우 자동 롤백을 수행하는 것이 종종이 모니터링입니다.
새로운 릴리즈 또는 서비스를 고객에게 제공하기 전에 작업을 지원할 수 있어야 합니다. 이 프로세스는 올바른 툴링을 통해 문서 생성 자동화, 자동화된 런북 및 플레이북 프로비저닝, 사전 정의되고 자동화된 패치 적용 계획을 수립하여 크게 자동화할 수 있습니다. 이 프로세스는 사전 승인된 서비스만 사용할 수 있도록 정확한 툴링을 사용하여 더욱 견고하게 만들 수 있습니다.
테스트 관리자는 가능한 한 서비스 승인 테스트를 자동화하는 데 중점을 두어야 합니다. 이는 검증과 테스트에 모두 사용할 수 있는 다양한 툴을 통해 클라우드에서 더 쉽게 사용할 수 있습니다.
신뢰성
변경 구현은 워크로드 가용성 및 논리적 재해 복구 기능에 직접적인 영향을 미칩니다. 잘 설계된 안정성 필러 백서, 특히 가용성에 대한 운영 고려 사항 섹션에 자세한 정보가 나와 있습니다. 가용성 극대화에 있어 변화의 자동화가 가장 중요합니다. 수동 프로세스가 있는 경우 이러한 수동 작업을 기다리는 데 중요한 시간이 손실됩니다.
파란색-녹색 또는 카나리아색 배포와 같은 위험을 줄이는 배포 패턴을 사용합니다. 파이프라인에 부하 상태, 부하 상태 성능 및 복원력 테스트를 포함한 종합적인 테스트가 있는지 확인합니다. 핵심 성과 지표(KPI)에 대한 효과적인 모니터링이 필수 사항이며, 이러한 KPI가 임계값을 초과할 가능성이 있는 경우 자동 롤백을 트리거해야 합니다.
재해 복구를 철저히 테스트하여 복구 목표가 충족되는지 확인합니다. 모든 데이터 백업은 자동화를 통해 수행되어야 합니다. 복구 프로세스와 절차가 올바른지 확인하기 위해 정기적으로 복원 및 복구합니다.
이러한 고려 사항은 워크로드의 안정성을 향상시키고 위험을 줄입니다. 변경 관리 프로세스는 이러한 위험 감소를 반영해야 하며 조직은 “위험이 보통 낮고 항상 잘 이해되기 때문에” 자동화, 빈도, 소규모 및 가역 가능한 변경이 표준 변경으로 처리될 수 있다는 점을 고려해야 합니다.
결론
클라우드의 자동화, 통합 및 구축 툴을 통해 기업은 비즈니스 위험을 줄이고 비즈니스 가치를 향상시키는 작고 빈번한 변경을 수행할 수 있습니다. 변경 프로세스는 실제로 변경되는 것을 반영하도록 조정되어야 합니다. 즉, 변경의 양 증가와 이러한 변경과 관련된 위험 감소입니다. 자동화, 일관성 또는 롤백을 활용하지 않는 변경의 경우 변경 프로세스는 그대로 유지되어야 합니다.
마지막으로, 변화를 구현하지 않거나 지연을 도입하지 않을 경우 발생하는 비즈니스 영향과 리스크를 항상 고려할 가치가 있으며, 변화를 관리하는 목적은 비즈니스 리스크를 최적화하는 것입니다.
빌드업웍스에서 AWS 무료 컨설팅을 진행합니다.
AWS에 대하여 궁금하신 내용이 있으시거나, 도입을 검토 중이시라면 편하게 신청해주세요.
[ 고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는 Change Management in the Cloud(2019년, 영문) 내용에 기반하여 작성 되었습니다.
이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.
© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
