이 문서에서는 지속적 통합 및 지속적 배포 (CI/CD)의 맥락에서 재해 복구 (DR) 및 비즈니스 연속성 계획에 대해 설명합니다. 또한 포괄적인 비즈니스 연속성 계획 (BCP)을 개발할 때 종속성을 식별하고 완화하는 방법에 관한 안내도 제공합니다. 이 문서에는 사용하는 도구 및 프로세스와 관계없이 BCP에 적용할 수 있는 권장사항이 포함되어 있습니다. 이 문서에서는 사용자가 소프트웨어 배포 및 운영 주기, CI/CD, DR의 기본사항에 익숙하다고 가정합니다.
CI/CD 파이프라인은 비즈니스에 중요한 애플리케이션을 빌드하고 배포하는 역할을 합니다. 따라서 애플리케이션 인프라와 마찬가지로 CI/CD 프로세스에도 DR 및 비즈니스 연속성을 위한 계획이 필요합니다. CI/CD의 DR 및 비즈니스 연속성을 고려할 때는 소프트웨어 제공 및 운영 주기의 각 단계를 이해하고 이러한 단계가 전체 프로세스로 어떻게 함께 작동하는지 이해하는 것이 중요합니다.
다음 다이어그램은 소프트웨어 개발 및 운영 주기의 간소화된 뷰로, 다음 세 단계를 포함합니다.
- 개발 내부 루프: 코딩, 시도, 커밋
- 지속적 통합: 빌드, 테스트, 보안
- 지속적 배포: 승격, 출시, 롤백, 측정항목
이 다이어그램은 Google Kubernetes Engine (GKE), Cloud Run, Google Distributed Cloud가 소프트웨어 개발 및 운영 주기의 가능한 배포 타겟임을 보여줍니다.
소프트웨어 개발 및 운영 주기 전반에 걸쳐 재해가 팀의 운영 능력과 비즈니스에 중요한 애플리케이션 유지보수에 미치는 영향을 고려해야 합니다. 이렇게 하면 CI/CD 도구 체인의 도구에 대한 복구 시간 목표 (RTO) 및 복구 지점 목표 (RPO)를 결정하는 데 도움이 됩니다.
또한 대부분의 조직에는 다양한 애플리케이션과 인프라 세트를 위한 여러 CI/CD 파이프라인이 있으며 각 파이프라인에는 DR 및 비즈니스 연속성 계획에 대한 고유한 요구사항이 있습니다. 파이프라인에 선택하는 복구 전략은 도구의 RTO 및 RPO에 따라 달라집니다. 예를 들어 일부 파이프라인은 다른 파이프라인보다 더 중요하므로 RTO 및 RPO 요구사항이 더 낮습니다. BCP에서 비즈니스에 중요한 파이프라인을 식별하는 것이 중요하며, 테스트 및 복구 절차 실행을 위한 권장사항을 구현할 때도 이러한 파이프라인에 더 많은 관심을 기울여야 합니다.
각 CI/CD 프로세스와 도구 체인이 다르므로 이 가이드의 목표는 CI/CD 프로세스의 단일 장애 지점을 식별하고 포괄적인 BCP를 개발하는 데 도움을 주는 것입니다. 다음 섹션은 다음 작업을 수행하는 데 도움이 됩니다.
- CI/CD 프로세스에 영향을 미치는 DR 이벤트에서 복구하는 데 필요한 사항을 파악합니다.
- CI/CD 프로세스의 도구에 대한 RTO 및 RPO를 결정합니다.
- CI/CD 프로세스의 장애 모드와 종속 항목을 파악합니다.
- 툴체인의 도구에 적합한 복구 전략을 선택합니다.
- CI/CD 프로세스의 DR 복구 계획 구현을 위한 일반적인 권장사항을 이해합니다.
비즈니스 연속성 프로세스 이해하기
BCP를 구축하는 것은 중단 및 비상사태 발생 시 조직이 운영을 계속할 수 있도록 하는 데 매우 중요합니다. 이를 통해 조직은 CI/CD 프로세스의 정상적인 운영 상태로 신속하게 돌아갈 수 있습니다.
다음 섹션에서는 효과적인 BCP를 만드는 데 필요한 단계를 포함하는 대략적인 단계를 설명합니다. 이러한 단계 중 상당수는 프로그램 관리 및 DR에 광범위하게 적용되지만, 특정 단계는 CI/CD 프로세스의 비즈니스 연속성을 계획하는 데 더 적합합니다. CI/CD의 비즈니스 연속성 계획과 관련된 단계는 다음 섹션에서 강조 표시되어 있으며, 이 문서의 나머지 부분에 나오는 안내의 기반이 됩니다.
시작 및 계획
이 초기 단계에서는 기술팀과 비즈니스팀이 협력하여 업무 연속성 계획 프로세스와 지속적인 유지관리의 기반을 마련합니다. 이 단계의 주요 단계는 다음과 같습니다.
- 리더십 동의: 고위 경영진이 BCP 개발을 지원하고 옹호하는지 확인합니다. 계획을 감독할 전담팀 또는 개인을 할당합니다.
- 리소스 할당: BCP를 개발하고 구현하는 데 필요한 예산, 인력, 리소스를 할당합니다.
- 범위 및 목표: BCP의 범위와 목표를 정의합니다. 계획에서 다루어야 하는 중요한 비즈니스 프로세스를 결정합니다.
- 위험 평가: 자연재해, 사이버 보안 침해, 공급망 중단과 같이 비즈니스를 중단할 수 있는 잠재적인 위험과 위협을 식별합니다.
- 영향 분석: 이러한 위험 평가 결과가 비즈니스 운영, 재정, 평판, 고객 만족도에 미칠 수 있는 잠재적 결과를 평가합니다.
비즈니스 영향 분석
이 단계에서는 비즈니스팀과 기술팀이 고객과 조직에 미치는 중단의 비즈니스 영향을 분석하고 중요한 비즈니스 기능의 복구를 우선시합니다. 이러한 비즈니스 기능은 빌드 및 배포 프로세스의 여러 단계에서 서로 다른 도구에 의해 실행됩니다.
비즈니스 영향 분석은 CI/CD의 비즈니스 연속성 계획 프로세스에서 중요한 단계입니다. 특히 중요한 비즈니스 기능과 도구 종속성을 식별하는 단계가 중요합니다. 또한 종속 항목과 DevOps 수명 주기 내에서 작동하는 방식을 비롯한 CI/CD 도구 체인을 이해하는 것은 CI/CD 프로세스의 BCP를 개발하기 위한 기본 구성요소입니다.
비즈니스 영향 분석 단계의 주요 단계는 다음과 같습니다.
- 중요한 기능: 복구에 우선순위를 두어야 하는 핵심 비즈니스 기능과 프로세스를 파악합니다. 예를 들어 단위 테스트 실행보다 애플리케이션 배포가 더 중요하다고 판단되면 애플리케이션 배포 프로세스 및 도구의 복구를 우선시합니다.
- 종속 항목: 중요한 기능의 복구에 영향을 미칠 수 있는 내부 및 외부 종속 항목을 식별합니다. 종속 항목은 특히 도구 체인을 통해 CI/CD 프로세스가 계속 작동하도록 하는 데 관련이 있습니다.
- RTO 및 RPO: 각 중요 기능에 대해 허용되는 다운타임 및 데이터 손실 한도를 정의합니다. 이러한 RTO 및 RPO 목표는 지속적인 운영을 위한 비즈니스 기능의 중요성과 연결되며, 비즈니스 기능이 원활하게 작동하는 데 필요한 특정 도구가 포함됩니다.
전략 개발
이 단계에서 기술팀은 운영 및 데이터 복원, 공급업체 및 이해관계자와의 커뮤니케이션과 같은 중요한 비즈니스 기능의 복구 전략을 개발합니다. 전략 개발은 CI/CD 프로세스의 비즈니스 연속성을 계획하는 데도 중요한 부분입니다. 특히 중요한 기능에 대한 상위 수준 복구 전략을 선택하는 단계에서 그렇습니다.
전략 개발 단계의 주요 단계는 다음과 같습니다.
- 복구 전략: 중요한 기능을 복원하기 위한 전략을 개발합니다. 이러한 전략에는 대체 위치, 원격 근무 또는 백업 시스템이 포함될 수 있습니다. 이러한 전략은 각 중요 기능의 RTO 및 RPO 타겟과 관련이 있습니다.
- 공급업체 및 공급자 관계: 주요 공급업체 및 공급자와의 커뮤니케이션 및 조정 계획을 수립하여 중단 기간 동안 공급망을 유지합니다.
- 데이터 및 IT 복구: 데이터 백업, IT 시스템 복구, 사이버 보안 조치 계획을 만듭니다.
- 커뮤니케이션 계획: 중단이 발생한 동안과 후에 내부 및 외부 이해관계자를 위한 명확한 커뮤니케이션 계획을 수립합니다.
계획 개발
이 단계에서는 BCP를 문서화하는 것이 주요 단계입니다. 기술팀은 각 중요 기능의 도구, 프로세스, 복구 전략, 근거, 절차를 문서화합니다. 계획 개발에는 중단 시 직원이 따라야 하는 단계별 안내 작성도 포함됩니다. 구현 및 지속적인 유지보수 중에 계획에 변경사항을 도입해야 할 수 있으며 계획은 최신 문서로 취급해야 합니다.
구현
이 단계에서는 기술팀에서 만든 BCP를 사용하여 조직의 계획을 구현합니다. 구현에는 직원 교육과 BCP의 초기 테스트가 포함됩니다. 또한 중단이 발생한 경우 일반 작업을 복구하기 위해 계획을 사용하는 것도 구현에 포함됩니다. 주요 구현 단계는 다음과 같습니다.
- 초기 테스트 및 교육: BPC가 문서화된 후 시뮬레이션과 연습을 통해 테스트하여 격차를 파악하고 효과를 개선합니다. 중단 시 직원의 역할과 책임에 대해 교육합니다.
- 활성화: 중단이 발생하면 사전 정의된 트리거 및 절차에 따라 BCP를 시작합니다.
- 커뮤니케이션: 이해관계자에게 상황과 복구 노력에 관한 정보를 제공합니다.
유지보수 및 검토
이 단계는 한 번만 발생하는 정의된 프로세스가 아니라 CI/CD 작업의 일반적인 부분이 되어야 하는 지속적인 노력입니다. 중단이 발생할 경우 관련성이 있고 실행 가능하도록 조직 내에서 BCP를 정기적으로 검토, 테스트, 업데이트하는 것이 중요합니다. 유지보수 및 검토의 주요 단계는 다음과 같습니다.
- 정기 업데이트: BCP가 최신 상태로 유지되고 효과적이도록 주기적으로 검토하고 업데이트합니다. 인력, 기술 또는 비즈니스 프로세스가 변경될 때마다 업데이트하세요.
- 교훈: 중단 또는 테스트 후 브리핑을 실시하여 교훈과 개선 영역을 파악합니다.
- 규정 준수: BCP를 업계 규정 및 표준에 맞게 조정합니다.
- 직원 인식: 직원에게 BCP 및 BCP 실행 시 직원의 역할에 대해 지속적으로 교육합니다.
CI/CD를 위한 비즈니스 연속성 프로세스 구축
이 섹션에서는 CI/CD 작업을 복원하는 데 중점을 둔 BCP를 빌드하기 위한 구체적인 가이드라인을 제공합니다. CI/CD의 비즈니스 연속성을 계획하는 프로세스는 CI/CD 도구 모음과 소프트웨어 배포 및 운영 수명 주기와의 연관성을 철저히 이해하는 것부터 시작됩니다. 이러한 이해를 바탕으로 조직이 중단된 CI/CD 작업을 복구하는 방법을 계획할 수 있습니다.
CI/CD 프로세스를 위한 강력한 비즈니스 연속성 프로세스를 구축하려면 다음 주요 단계를 따라야 합니다.
- 도구 모음 이해하기
- 데이터 및 종속 항목 식별
- RTO 및 RPO 타겟 결정
- 비즈니스 연속성을 위한 상위 수준 전략 선택
- BCP 문서화 및 권장사항 구현
- 실패 시나리오 테스트 및 계획 유지
다음 섹션에서는 이러한 각 단계를 자세히 설명합니다.
도구 모음 이해
CI/CD 도구 체인은 다양한 개별 도구로 구성되며 도구의 가능한 조합은 끝이 없는 것처럼 보일 수 있습니다. 하지만 CI/CD 도구 체인과 종속 항목을 이해하는 것이 CI/CD의 비즈니스 연속성 계획의 핵심입니다. CI/CD 프로세스의 핵심 임무는 최종 사용자가 사용할 수 있도록 프로덕션 시스템에 코드를 제공하는 것입니다. 이 프로세스 전반에 걸쳐 다양한 시스템과 데이터 소스가 사용됩니다. 이러한 데이터 소스와 종속성을 파악하는 것은 BCP를 개발하는 데 매우 중요합니다. DR 전략을 수립하려면 먼저 CI/CD 프로세스에 사용되는 다양한 도구를 이해해야 합니다.
자체 도구 모음을 평가하고 BCP를 개발하는 방법을 이해하는 데 도움이 되도록 이 문서에서는 GKE에서 실행되는 엔터프라이즈 Java 애플리케이션의 예를 사용합니다. 다음 다이어그램은 도구 체인의 첫 번째 데이터 및 시스템 레이어를 보여줍니다. 이 첫 번째 레이어는 개발자가 직접 제어할 수 있으며 다음을 포함합니다.
- 애플리케이션의 소스
- CI/CD 플랫폼의 도구(예: Cloud Build 또는 Cloud Deploy)
- 다양한 도구의 기본 상호 연결
다이어그램에 표시된 것처럼 예시 애플리케이션의 기본 흐름은 다음과 같습니다.
- 개발 내부 루프의 코드 개발 이벤트가 Cloud Build를 트리거합니다.
- Cloud Build가 소스 관리 저장소에서 애플리케이션 소스 코드를 가져옵니다.
- Cloud Build는 Artifact Registry의 Java 저장소에 있는 서드 파티 JAR 파일과 같이 빌드 구성 파일에 지정된 필요한 종속 항목을 식별합니다. 그러면 Cloud Build가 소스 위치에서 이러한 종속 항목을 가져옵니다.
- Cloud Build는 빌드를 실행하고 정적 분석, 단위 테스트와 같은 필요한 검증을 실행합니다.
- 빌드가 성공하면 Cloud Build가 컨테이너 이미지를 만들고 Artifact Registry의 컨테이너 저장소에 푸시합니다.
- Cloud Deploy 파이프라인이 트리거되고 파이프라인이 저장소에서 컨테이너 이미지를 가져와 GKE 환경에 배포합니다.
CI/CD 프로세스에 사용되는 도구를 파악하려면 이 문서의 예와 같이 CI/CD 프로세스와 사용되는 도구를 보여주는 다이어그램을 만드는 것이 좋습니다. 그런 다음 다이어그램을 사용하여 프로세스 단계, 도구의 목적, 도구 자체, 도구 실패의 영향을 받는 팀과 같은 CI/CD 도구 모음에 관한 주요 정보를 포착하는 표를 만들 수 있습니다. 이 표는 도구 모음의 도구를 매핑하고 CI/CD 프로세스의 특정 단계가 있는 도구를 식별합니다. 따라서 이 표를 통해 도구 체인과 작동 방식을 전반적으로 파악할 수 있습니다.
다음 표에서는 앞에서 언급한 엔터프라이즈 애플리케이션의 예를 다이어그램의 각 도구에 매핑합니다. 도구 모음 매핑의 예를 더 자세히 보여주기 위해 이 표에는 보안 도구 또는 테스트 도구와 같이 다이어그램에 언급되지 않은 다른 도구도 포함되어 있습니다.
첫 번째 표는 CI/CD 프로세스의 CI 단계에서 사용되는 도구에 매핑됩니다.
| 지속적 통합 | 소스 | 사용된 도구 | 기본 사용자 | 사용 |
|---|---|---|---|---|
| 단계: 소스 제어 |
|
|
|
|
| 단계: 빌드 |
|
개발자 |
|
|
| 단계: 테스트 |
|
개발자 |
일관된 주문형 플랫폼에서 단위 테스트와 통합 테스트를 실행합니다. |
|
| 단계: 보안 |
|
|
코드에 보안 문제가 있는지 검사합니다. |
두 번째 표에서는 CI/CD 프로세스의 CD 단계에서 사용되는 도구를 중점적으로 다룹니다.
| 지속적 배포 | 소스 | 사용된 도구 | 기본 사용자 | 사용 |
|---|---|---|---|---|
| 단계: 배포 | 배포 구성 파일 |
|
안전하고 일관된 플랫폼에서 트래픽을 승격, 승인, 관리하기 위해 배포를 자동화합니다. |
|
| 단계: 테스트 |
|
|
개발자 |
품질과 유용성을 위해 통합 및 성능을 테스트합니다. |
| 단계: 로깅 |
|
|
관측 가능성 및 문제 해결을 위해 로그를 유지합니다. |
|
| 단계: 모니터링 | 다음과 같은 구성 파일 모니터링
|
|
|
BCP를 계속 작업하고 CI/CD 도구 모음에 대한 이해가 깊어짐에 따라 다이어그램과 매핑 테이블을 업데이트할 수 있습니다.
데이터 및 종속 항목 식별
기본 인벤토리와 CI/CD 도구 모음의 매핑을 완료한 후 다음 단계는 메타데이터 또는 구성의 종속 항목을 캡처하는 것입니다. BCP를 구현할 때는 CI/CD 도구 모음 내의 종속 항목을 명확하게 이해하는 것이 중요합니다. 종속 항목은 일반적으로 내부 (1차) 종속 항목과 외부 (2차 또는 3차) 종속 항목의 두 가지 카테고리로 나뉩니다.
내부 종속 항목
내부 종속 항목은 도구 모음에서 사용하고 직접 제어하는 시스템입니다. 내부 종속 항목도 팀에서 선택합니다. 이러한 시스템에는 CI 도구, 키 관리 스토어, 소스 제어 시스템이 포함됩니다. 이러한 시스템은 도구 체인 자체의 다음 레이어에 있다고 생각하면 됩니다.
예를 들어 다음 다이어그램은 내부 종속 항목이 도구 모음에 어떻게 적합한지 보여줍니다. 이 다이어그램은 예시 Java 애플리케이션의 이전 첫 번째 레이어 도구 모음 다이어그램을 확장하여 도구 모음의 내부 종속 항목(애플리케이션 사용자 인증 정보, deploy.yaml 파일, cloudbuild.yaml 파일)도 포함합니다.
다이어그램에 표시된 것처럼 예시 Java 애플리케이션에서 성공적으로 작동하려면 Cloud Build, Cloud Deploy, GKE와 같은 도구가 cloudbuild.yaml, deploy.yaml, 애플리케이션 사용자 인증 정보와 같은 비 도구 체인 종속 항목에 액세스해야 합니다. 자체 CI/CD 도구 체인을 분석할 때는 도구를 자체적으로 실행할 수 있는지 아니면 다른 리소스를 호출해야 하는지 평가합니다.
예시 Java 애플리케이션의 문서화된 내부 종속 항목을 고려하세요.
사용자 인증 정보는 툴체인에 포함되지 않는 Secret Manager에 저장되지만, 사용자 인증 정보는 애플리케이션이 배포 시 시작하는 데 필요합니다. 따라서 애플리케이션 사용자 인증 정보는 GKE의 종속 항목으로 포함됩니다. deploy.yaml 및 cloudbuild.yaml 파일은 애플리케이션 코드와 함께 소스 제어에 저장되지만 해당 애플리케이션의 CI/CD 파이프라인을 정의하므로 종속 항목으로 포함하는 것이 중요합니다.
예시 Java 애플리케이션의 BCP는 복구 프로세스 중에 도구가 설치된 후 CI/CD 파이프라인을 다시 만들기 때문에 deploy.yaml 및 cloudbuild.yaml 파일의 이러한 종속성을 고려해야 합니다.
또한 이러한 종속 항목이 손상되면 도구 자체가 계속 작동하더라도 파이프라인의 전체 기능에 영향을 미칩니다.
외부 종속 항목
외부 종속 항목은 도구 체인이 작동하는 데 사용하는 외부 시스템으로, 직접 제어할 수 없습니다. 외부 종속 항목은 선택한 도구와 프로그래밍 프레임워크에서 발생합니다. 외부 종속 항목은 내부 종속 항목보다 한 단계 아래에 있는 것으로 생각할 수 있습니다. 외부 종속 항목의 예로는 npm 또는 Maven 저장소, 모니터링 서비스가 있습니다.
외부 종속 항목은 제어할 수 없지만 BCP에 통합할 수 있습니다. 다음 다이어그램은 Maven Central의 Java 라이브러리와 Docker Hub의 Docker 이미지와 같은 외부 종속 항목을 내부 종속 항목과 함께 포함하여 Java 애플리케이션 예시를 업데이트합니다. Java 라이브러리는 Artifact Registry에서 사용하고 Docker 이미지는 Cloud Build에서 사용합니다.
다이어그램을 보면 외부 종속 항목이 CI/CD 프로세스에 중요할 수 있습니다. Cloud Build와 GKE 모두 성공적으로 작동하려면 두 개의 외부 서비스 (Maven 및 Docker)가 필요합니다. 자체 도구 모음을 평가할 때는 도구에서 액세스해야 하는 외부 종속 항목과 종속 항목 중단 처리 절차를 모두 문서화합니다.
Java 애플리케이션 예시에서는 Java 라이브러리와 Docker 이미지를 직접 제어할 수 없지만 BCP에 포함하고 복구 절차를 포함할 수는 있습니다. 예를 들어 Maven의 Java 라이브러리를 생각해 보세요. 라이브러리는 외부 소스에 저장되지만 Java 라이브러리를 로컬 Maven 저장소 또는 Artifact Registry에 주기적으로 다운로드하고 새로고침하는 프로세스를 설정할 수 있습니다. 이렇게 하면 복구 프로세스에서 서드 파티 소스의 사용 가능 여부에 의존하지 않아도 됩니다.
또한 외부 종속 항목이 두 개 이상의 레이어를 가질 수 있다는 점을 이해하는 것이 중요합니다. 예를 들어 내부 종속 항목에서 사용하는 시스템을 2차 종속 항목으로 생각할 수 있습니다. 이러한 2차 종속 항목에는 자체 종속 항목이 있을 수 있으며 이를 3차 종속 항목으로 생각할 수 있습니다. 중단 중에 작업을 복구하려면 BCP에서 2차 및 3차 외부 종속 항목을 모두 문서화하고 설명해야 할 수 있습니다.
RTO 및 RPO 타겟 결정
도구 모음과 종속 항목을 파악한 후 도구의 RTO 및 RPO 타겟을 정의합니다. CI/CD 프로세스의 도구는 각각 비즈니스에 다른 영향을 미칠 수 있는 다른 작업을 실행합니다. 따라서 비즈니스 기능의 RTO 및 RPO 목표의 우선순위를 비즈니스에 미치는 영향과 일치시키는 것이 중요합니다. 예를 들어 CI 단계를 통해 애플리케이션의 새 버전을 빌드하는 것은 CD 단계를 통해 애플리케이션을 배포하는 것보다 영향이 적을 수 있습니다. 따라서 배포 도구의 RTO 및 RPO 타겟이 다른 기능보다 길 수 있습니다.
다음 4분면 차트는 CI/CD 도구 체인의 각 구성요소에 대한 RTO 및 RPO 타겟을 결정하는 방법을 보여주는 일반적인 예입니다. 이 차트에 매핑된 도구 체인에는 IaC 파이프라인 및 테스트 데이터 소스와 같은 도구가 포함됩니다. 이 도구는 이전 Java 애플리케이션 다이어그램에서는 언급되지 않았지만, 더 완전한 예를 제공하기 위해 여기에 포함되었습니다.
이 차트는 개발자와 운영에 미치는 영향의 수준을 기준으로 한 사분면을 보여줍니다. 차트에서 구성요소는 다음과 같이 배치됩니다.
- 개발자에게 미치는 영향은 보통, 운영에 미치는 영향은 낮음: 테스트 데이터 소스
- 개발자에게 미치는 영향이 보통이고 운영에 미치는 영향이 보통입니다. Cloud Key Management Service(Cloud KMS)
- 개발자 영향은 보통, 운영 영향은 높음: 배포 파이프라인
- 개발자 영향이 크고 운영 영향이 적음: 개발 내부 루프
- 개발자 영향 높음, 운영 영향 보통: CI 파이프라인, 코드형 인프라 (IaC) 파이프라인
- 개발자 영향이 높고 운영 영향이 높음: 소스 제어 관리(SCM), Artifact Registry
개발자 영향과 운영 영향이 큰 소스 관리 및 Artifact Registry와 같은 구성요소가 비즈니스에 가장 큰 영향을 미칩니다. 이러한 구성요소는 RTO 및 RPO 목표가 가장 낮아야 합니다. 다른 사분면의 구성요소는 우선순위가 낮으므로 RTO 및 RPO 목표가 더 높습니다. 일반적으로 도구 모음 구성요소의 RTO 및 RPO 목표는 해당 구성요소의 서비스를 복원하는 데 걸리는 시간과 비교하여 허용되는 데이터 또는 구성 손실의 양에 따라 설정해야 합니다.
예를 들어 그래프에서 Artifact Registry와 IaC 파이프라인의 위치가 서로 다릅니다. 이 두 도구를 비교하면 Artifact Registry 서비스 중단이 IaC 파이프라인의 서비스 중단보다 비즈니스 운영에 더 큰 영향을 미치는 것으로 나타납니다. Artifact Registry 서비스 중단은 애플리케이션을 배포하거나 자동 확장하는 기능에 큰 영향을 미치므로 다른 도구에 비해 RTO 및 RPO 타겟이 낮아집니다. 반면 그래프를 보면 IaC 파이프라인 서비스 중단이 다른 도구보다 비즈니스 운영에 미치는 영향이 더 적은 것을 알 수 있습니다. 정전 중에 다른 방법을 사용하여 인프라를 배포하거나 업데이트할 수 있으므로 IaC 파이프라인의 RTO 및 RPO 목표가 높아집니다.
비즈니스 연속성을 위한 상위 수준 전략 선택
프로덕션 애플리케이션의 비즈니스 연속성 프로세스는 종종 세 가지 일반적인 DR 전략 중 하나를 따릅니다. 하지만 CI/CD의 경우 비즈니스 연속성을 위해 활성/수동 또는 백업/복원의 두 가지 상위 수준 전략 중에서 선택할 수 있습니다. 선택하는 전략은 요구사항과 예산에 따라 달라집니다. 각 전략에는 복잡성과 비용 간의 절충이 있으며 CI/CD 프로세스에 대한 고려사항이 다릅니다. 다음 섹션에서는 각 전략과 그 장단점에 대해 자세히 설명합니다.
또한 서비스 중단 이벤트가 발생하면 CI/CD 구현에만 영향을 미치지 않을 수 있습니다. 네트워크, 컴퓨팅, 스토리지를 비롯해 필요한 모든 인프라도 고려해야 합니다. 이러한 구성요소에 대한 DR 계획이 있어야 하며 정기적으로 테스트하여 효과적인지 확인해야 합니다.
active/passive
활성/수동 (또는 웜 스탠바이) 전략을 사용하면 애플리케이션과 수동 CI/CD 파이프라인이 미러링됩니다. 하지만 수동 파이프라인은 실제로 고객 워크로드와 빌드 또는 배포를 처리하지 않으므로 축소된 상태입니다. 이 전략은 약간의 다운타임이 허용되는 비즈니스에 중요한 애플리케이션에 가장 적합합니다.
다음 다이어그램은 이 문서에서 사용되는 Java 애플리케이션 예시의 액티브/패시브 구성을 보여줍니다. 수동 파이프라인은 다른 리전에서 애플리케이션 도구 체인을 완전히 복제합니다.
이 예에서 region1은 활성 CI/CD 파이프라인을 호스팅하고 region2에는 수동 대응 항목이 있습니다. 코드가 GitHub 또는 GitLab과 같은 외부 Git 서비스 제공업체에서 호스팅됩니다. 저장소 이벤트 (예: pull 요청에서 병합)는 region1에서 CI/CD 파이프라인을 트리거하여 다중 리전 프로덕션 환경에 빌드, 테스트, 배포할 수 있습니다.
제품의 리전 서비스 중단과 같은 region1 파이프라인의 심각한 문제가 발생하면 배포가 실패하거나 빌드가 실패할 수 있습니다. 문제를 신속하게 복구하려면 Git 저장소의 트리거를 업데이트하고 region2 파이프라인으로 전환하면 됩니다. 그러면 region2 파이프라인이 활성 파이프라인이 됩니다. region1에서 문제가 해결된 후에는 region1의 파이프라인을 수동으로 유지할 수 있습니다.
활성/수동 전략의 장점은 다음과 같습니다.
- 낮은 다운타임: 수동 파이프라인이 배포되었지만 축소되었기 때문에 다운타임은 파이프라인을 확장하는 데 필요한 시간으로 제한됩니다.
- 데이터 손실에 대한 구성 가능한 허용 범위: 이 전략을 사용하면 구성과 아티팩트를 주기적으로 동기화해야 합니다. 하지만 요구사항에 따라 금액을 구성할 수 있으므로 복잡성을 줄일 수 있습니다.
이 전략의 단점은 다음과 같습니다.
- 비용: 인프라가 중복되므로 이 전략은 CI/CD 인프라의 전체 비용을 증가시킵니다.
백업/복원
백업/복원 전략을 사용하면 사고 복구 중에 필요한 경우에만 장애 조치 파이프라인을 만듭니다. 이 전략은 우선순위가 낮은 사용 사례에 가장 적합합니다. 다음 다이어그램은 예시 Java 애플리케이션의 백업/복원 구성을 보여줍니다. 백업 구성은 다른 리전에서 애플리케이션의 CI/CD 파이프라인 일부만 복제합니다.
이전 예와 마찬가지로 region1에서 활성 CI/CD 파이프라인을 호스팅합니다. region2에는 수동 파이프라인이 있는 대신 Maven 패키지 및 컨테이너 이미지와 같은 필수 지역 데이터의 백업만 있습니다. 소스 저장소를 region1에 호스팅하는 경우 DR 위치에도 데이터를 동기화해야 합니다.
마찬가지로 region1 파이프라인에서 심각한 문제가 발생하는 경우(예: 리전 제품 서비스 중단) region2에서 CI/CD 구현을 복원할 수 있습니다. 인프라 코드가 인프라 코드 저장소에 저장되어 있는 경우 저장소에서 자동화 스크립트를 실행하고 region2에서 CI/CD 파이프라인을 다시 빌드할 수 있습니다.
중단이 대규모 이벤트인 경우 클라우드 리소스를 확보하기 위해 다른 고객과 경쟁할 수 있습니다. 이 상황을 완화하는 한 가지 방법은 DR 위치에 여러 옵션을 두는 것입니다. 예를 들어 region1 파이프라인이 us-east1에 있는 경우 장애 복구 리전은 us-east4, us-central1 또는 us-west1일 수 있습니다.
백업/복원 전략의 장점은 다음과 같습니다.
- 비용: 이 전략은 재해 복구 시나리오 중에만 백업 파이프라인을 배포하므로 비용이 가장 적게 발생합니다.
이 전략의 단점은 다음과 같습니다.
- 다운타임: 이 전략은 필요할 때 장애 조치 파이프라인을 만들기 때문에 구현하는 데 시간이 더 오래 걸립니다. 사전 빌드된 파이프라인이 있는 대신 인시던트 복구 중에 서비스를 만들고 구성해야 합니다. 아티팩트 빌드 시간과 외부 종속 항목을 가져오는 시간도 크게 길어질 수 있습니다.
BCP 문서화 및 권장사항 구현
CI/CD 도구 체인을 매핑하고, 종속 항목을 식별하고, 중요 기능의 RTO 및 RPO 타겟을 결정한 후 다음 단계는 관련 정보를 모두 문서화된 BCP에 기록하는 것입니다. BCP를 만들 때 각 중요한 기능을 복원하기 위한 전략, 프로세스, 절차를 문서화합니다. 이 문서화 프로세스에는 특정 역할을 맡은 직원이 중단 중에 따라야 하는 단계별 절차를 작성하는 것이 포함됩니다.
BCP를 정의한 후 권장사항을 사용하여 RTO 및 RPO 목표를 달성하도록 CI/CD 도구 체인을 배포하거나 업데이트합니다. CI/CD 도구 체인은 매우 다를 수 있지만, 도구 체인과 관계없이 권장사항의 두 가지 주요 패턴은 종속 항목에 대한 포괄적인 이해와 자동화 구현입니다.
종속 항목과 관련하여 대부분의 BCP는 관리 범위 내에 있는 시스템을 직접 다룹니다. 하지만 2차 또는 3차 외부 종속 항목도 마찬가지로 영향을 미칠 수 있으므로 이러한 중요한 종속 항목에 대해서도 권장사항과 중복 조치를 구현하는 것이 중요합니다. 예시 애플리케이션의 외부 Java 라이브러리는 3차 종속 항목의 예입니다. 이러한 라이브러리의 로컬 저장소나 백업이 없는 경우 라이브러리를 가져오는 외부 소스가 연결 해제되면 애플리케이션을 빌드하지 못할 수 있습니다.
자동화 측면에서 권장사항의 구현은 전반적인 클라우드 IaC 전략에 통합되어야 합니다. IaC 솔루션은 Terraform과 같은 도구를 사용하여 CI/CD 구현에 필요한 리소스를 자동으로 프로비저닝하고 프로세스를 구성해야 합니다. IaC 관행은 CI/CD 파이프라인의 일상적인 기능에 통합되어 있으므로 매우 효과적인 복구 절차입니다. 또한 IaC는 소스 제어에 구성 파일을 저장하도록 지원하므로 백업 권장사항을 채택하도록 지원합니다.
BCP와 종속 항목 및 자동화에 관한 권장사항에 따라 도구 체인을 구현한 후에는 CI/CD 프로세스와 복구 전략이 변경될 수 있습니다. BCP를 검토하고 권장사항을 구현한 결과로 복구 전략, 프로세스, 절차가 변경된 경우 이를 문서화해야 합니다.
실패 시나리오 테스트 및 계획 유지
지속적으로 BCP를 정기적으로 검토, 테스트, 업데이트하는 것이 중요합니다. BCP 및 복구 절차를 테스트하면 계획이 여전히 유효하고 문서화된 RPO 및 RTO 타겟이 허용되는지 확인할 수 있습니다. 하지만 무엇보다 중요한 것은 정기적인 테스트, 업데이트, 유지보수를 통해 BCP를 정상적인 운영의 일부로 실행할 수 있다는 점입니다. Google Cloud를 사용하면 최소한의 비용으로 복구 시나리오를 테스트할 수 있습니다. 테스트를 돕기 위해서는 다음을 수행하는 것이 좋습니다.
- IaC 도구로 인프라 프로비저닝 자동화: Terraform과 같은 도구를 사용하여 CI/CD 인프라 프로비저닝을 자동화할 수 있습니다.
- Cloud Logging 및 Cloud Monitoring을 사용하여 테스트 모니터링 및 디버그: Google Cloud 관측 가능성은 API 호출을 통해 액세스할 수 있는 로깅 및 모니터링 도구를 제공하므로 측정항목에 대응하여 복구 시나리오 배포를 자동화할 수 있습니다. 테스트를 설계할 때는 적절한 복구 작업을 트리거할 수 있는 적절한 모니터링 및 알림이 있는지 확인합니다.
- BCP에서 테스트 실행: 예를 들어 권한 및 사용자 액세스가 프로덕션 환경에서처럼 DR 환경에서도 작동하는지 테스트할 수 있습니다. DR 환경에서 통합 및 기능 테스트를 실행할 수 있습니다. Google Cloud 에 대한 일반 액세스 경로가 작동하지 않는 테스트를 수행할 수도 있습니다.
Google에서는 DiRT (재해 복구 테스트)라는 프로세스를 통해 BCP를 정기적으로 테스트합니다. 이 테스트를 통해 Google은 영향, 자동화를 확인하고 설명되지 않은 위험을 노출할 수 있습니다. 구현해야 하는 자동화 및 BCP의 변경사항은 DiRT의 중요한 결과입니다.
권장사항
이 섹션에서는 RTO 및 RPO 목표를 달성하기 위해 구현할 수 있는 몇 가지 권장사항을 알아봅니다. 이러한 권장사항은 특정 도구가 아닌 CI/CD의 DR에 광범위하게 적용됩니다. 구현과 관계없이 고가용성, RTO, RPO가 요구사항을 충족하는지 확인하기 위해 BCP를 정기적으로 테스트해야 합니다. 사고나 재해가 발생하면 회고를 진행하고 프로세스를 분석하여 개선해야 합니다.
고가용성
각 도구에 대해 고가용성을 위한 권장사항을 구현해야 합니다. 고가용성 권장사항을 따르면 CI/CD 프로세스가 더 적극적인 자세를 취하게 됩니다. 이러한 권장사항을 통해 CI/CD 프로세스가 장애에 더 탄력적으로 대응할 수 있기 때문입니다. 이러한 사전 예방 전략은 복구 및 백업을 위한 사후 대응 제어 및 절차와 함께 사용해야 합니다.
다음은 고가용성을 달성하기 위한 몇 가지 권장사항입니다. 하지만 CI/CD의 각 도구에 대한 자세한 문서를 참고하여 자세한 권장사항을 확인하세요.
- 관리형 서비스: 관리형 서비스를 사용하면 운영 책임이 Google Cloud로 전환됩니다.
- 자동 확장: 가능한 경우 자동 확장을 사용합니다. 자동 확장 기능의 핵심은 작업자 인스턴스가 동적으로 생성되므로 실패한 노드의 복구가 자동으로 이루어진다는 것입니다.
- 전역 및 멀티 리전 배포: 가능한 경우 리전별 배포 대신 전역 및 멀티 리전 배포를 사용합니다. 예를 들어 멀티 리전 스토리지를 위해 Artifact Registry를 구성할 수 있습니다.
- 종속 항목: 도구의 모든 종속 항목을 파악하고 이러한 종속 항목의 가용성이 높아야 합니다. 예를 들어 아티팩트 레지스트리에 모든 서드 파티 라이브러리를 캐시할 수 있습니다.
백업 절차
CI/CD에 DR을 구현할 때 일부 도구와 프로세스는 백업/복원 전략에 더 적합합니다. 포괄적인 백업 전략은 효과적인 사후 대응 제어의 첫 단계입니다. 백업을 사용하면 악의적인 행위자 또는 재해 시나리오의 경우 중단을 최소화하여 CI/CD 파이프라인을 복구할 수 있습니다.
시작하려면 다음 세 가지 권장사항을 구현해야 합니다. 하지만 백업 권장사항에 관한 자세한 내용은 CI/CD 프로세스의 각 도구에 관한 문서를 참고하세요.
- 소스 제어: 구성 파일과 자동화 스크립트, 정책 등 코드로 작성하는 모든 항목을 소스 제어에 저장합니다. 예로는
cloudbuild.yaml및 Kubernetes YAML 파일이 있습니다. - 중복성: 비밀번호, 인증서, API 키와 같은 보안 비밀에 액세스하는 데 단일 장애점이 없는지 확인합니다. 피해야 할 사례로는 한 사람만 비밀번호를 알거나 특정 지역의 단일 서버에만 API 키를 저장하는 경우가 있습니다.
- 백업: 백업의 완전성과 정확성을 자주 확인합니다. Backup for GKE와 같은 관리형 서비스를 사용하면 인증 프로세스를 간소화할 수 있습니다.
복구 절차
DR에는 백업 프로세스를 보완하는 복구 절차도 필요합니다. 복구 절차와 완전한 백업을 결합하면 재해 시나리오에 얼마나 빠르게 대응할 수 있는지 결정됩니다.
종속 항목 관리
CI/CD 파이프라인에는 여러 종속 항목이 있을 수 있으며, 이는 실패의 원인이 될 수도 있습니다. 종속 항목의 전체 목록은 이 문서의 앞부분에 설명된 대로 데이터 및 종속 항목 식별에서 식별해야 합니다. 하지만 가장 일반적인 두 가지 종속성 소스는 다음과 같습니다.
- 애플리케이션 아티팩트: 패키지, 라이브러리, 이미지 등
- 외부 시스템: 티켓팅 및 알림 시스템 등
종속 항목의 위험을 완화하는 한 가지 방법은 벤더링 관행을 채택하는 것입니다. 애플리케이션 패키지나 이미지를 벤더링하는 것은 비공개 저장소에 사본을 만들어 저장하는 프로세스입니다. 벤더링은 이러한 패키지나 이미지의 외부 소스에 대한 종속 항목을 삭제하며 소프트웨어 공급망에 멀웨어가 삽입되는 것을 방지하는 데도 도움이 될 수 있습니다.
애플리케이션 패키지나 이미지를 벤더링하면 다음과 같은 이점이 있습니다.
- 보안: 벤더링은 애플리케이션 패키지 또는 이미지의 외부 소스 종속성을 삭제하므로 멀웨어 삽입 공격을 방지하는 데 도움이 됩니다.
- 제어: 자체 패키지나 이미지를 벤더링하여 조직은 이러한 패키지와 이미지의 소스를 더 세부적으로 제어할 수 있습니다.
- 규정 준수: 벤더링은 조직이 사이버 보안 성숙도 모델 인증과 같은 업계 규정을 준수하는 데 도움이 될 수 있습니다.
팀에서 애플리케이션 패키지나 이미지를 공급업체에 제공하기로 결정한 경우 다음 주요 단계를 따르세요.
- 벤더링해야 하는 애플리케이션 패키지 또는 이미지를 식별합니다.
- 서드 파티 패키지 또는 이미지를 저장할 비공개 저장소를 만듭니다.
- 원본 소스에서 패키지나 이미지를 다운로드하여 비공개 저장소에 저장합니다.
- 패키지 또는 이미지의 무결성을 확인합니다.
- 필요에 따라 벤더링된 패키지나 이미지를 업데이트합니다.
CI/CD 파이프라인은 외부 당사자 시스템을 호출하여 스캔 실행, 티켓 로깅, 알림 전송과 같은 작업을 실행하는 경우가 많습니다. 대부분의 경우 이러한 외부 당사자 시스템에는 구현해야 하는 자체 DR 전략이 있습니다. 하지만 적절한 DR 계획이 없는 경우도 있으며 이러한 인스턴스는 BCP에 명확하게 문서화해야 합니다. 그런 다음 가용성 문제로 인해 파이프라인의 해당 단계를 건너뛸 수 있는지 또는 CI/CD 파이프라인의 다운타임을 허용할 수 있는지 결정해야 합니다.
모니터링 및 알림
CI/CD는 애플리케이션 프로덕션 시스템과 마찬가지이므로 CI/CD 도구에 대한 모니터링 및 알림 기법도 구현해야 합니다. 권장사항에 따라 대시보드와 알림을 구현하는 것이 좋습니다. Cloud Monitoring의 GitHub 샘플 저장소에는 대시보드 및 알림 정책의 예가 많이 있습니다.
서비스 수준 지표 (SLI) 및 서비스 수준 목표 (SLO)와 같은 추가 모니터링 수준을 구현할 수도 있습니다. 이러한 모니터링 수준은 CI/CD 파이프라인의 전반적인 상태와 성능을 추적하는 데 도움이 됩니다. 예를 들어 빌드 및 배포 단계의 지연 시간을 추적하기 위해 SLO를 구현할 수 있습니다. 이러한 SLO를 통해 팀은 원하는 속도와 빈도로 애플리케이션을 빌드하고 출시할 수 있습니다.
비상 액세스 절차
재해 발생 시 운영팀은 표준 절차 외의 조치를 취하고 시스템 및 도구에 대한 긴급 액세스 권한을 얻어야 할 수 있습니다. 이러한 긴급 조치를 브레이크글래스 절차라고도 합니다. 시작하려면 다음 세 가지 권장사항을 구현해야 합니다.
- 명확한 에스컬레이션 계획과 절차가 있어야 합니다. 명확한 계획이 있으면 운영팀에서 긴급 액세스 절차를 사용해야 하는 시점을 알 수 있습니다.
- 여러 사용자가 구성 및 보안 비밀과 같은 중요한 정보에 액세스할 수 있는지 확인합니다.
- 긴급 액세스 절차가 사용된 시점과 사용자를 추적할 수 있도록 자동 감사 방법을 개발합니다.
다음 단계
- 이 문서에서 사용되는 Google Cloud 제품에 대해 자세히 알아보세요.
- 재해 복구 계획 가이드를 참고하세요.
- 튜토리얼을 완료하여 다른 Google Cloud 기능을 사용해 보세요.
- 그 밖의 참조 아키텍처, 다이어그램, 튜토리얼, 권장사항을 알아보려면 클라우드 아키텍처 센터를 확인하세요.
참여자
저자:
기타 참여자:
- 마르코 페라리 | 클라우드 솔루션 설계자
- 아누라다 바즈파이 | 솔루션 설계자
- Rodd Zurcher | 솔루션 설계자