이 문서에서는 지속적 통합 및 지속적 배포 (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의 비즈니스 연속성 계획 프로세스, 특히 중요한 비즈니스 기능과 도구 종속 항목을 식별하는 단계에서 중요한 단계입니다. 또한 CI/CD 도구 모음(종속 항목 및 DevOps 수명 주기 내에서의 작동 방식 포함)을 이해하는 것은 CI/CD 프로세스의 BCP를 개발하기 위한 기본적인 구성요소입니다.
비즈니스 영향 분석 단계의 주요 단계는 다음과 같습니다.
- 중요한 기능: 복구 시 우선순위를 두어야 하는 주요 비즈니스 기능과 프로세스를 결정합니다. 예를 들어 애플리케이션 배포가 단위 테스트 실행보다 중요하다고 판단되면 애플리케이션 배포 프로세스 및 도구의 복구를 우선시합니다.
- 종속 항목: 중요한 기능의 복구에 영향을 줄 수 있는 내부 및 외부 종속 항목을 식별합니다. 종속 항목은 도구 모음을 통해 CI/CD 프로세스의 지속적인 작동을 보장하는 데 특히 관련이 있습니다.
- RTO 및 RPO: 각 핵심 기능에 허용되는 다운타임 제한 및 데이터 손실 제한을 정의합니다. 이러한 RTO 및 RPO 타겟은 비즈니스 기능의 연속 운영에 관한 중요성과 연결되며 비즈니스 기능이 원활하게 작동하는 데 필요한 특정 도구를 포함합니다.
전략 개발
이 단계에서 기술팀은 작업 및 데이터 복원, 공급업체 및 이해관계자와의 커뮤니케이션과 같은 중요한 비즈니스 기능을 위한 복구 전략을 수립합니다. 전략 개발은 CI/CD 프로세스의 비즈니스 연속성 계획, 특히 중요한 기능의 대략적인 복구 전략을 선택하는 단계의 핵심적인 부분이기도 합니다.
전략 개발 단계의 주요 단계는 다음과 같습니다.
- 복구 전략: 중요한 기능을 복원하는 전략을 수립합니다. 이러한 전략에는 대체 위치, 원격 근무, 백업 시스템이 포함될 수 있습니다. 이러한 전략은 각 중요한 기능의 RTO 및 RPO 타겟과 연결됩니다.
- 공급업체 및 공급자 관계: 중단 시 공급망을 계속 운영할 수 있도록 주요 공급업체 및 공급자와의 커뮤니케이션 및 조정 계획을 수립합니다.
- 데이터 및 IT 복구: 데이터 백업, IT 시스템 복구, 사이버 보안 조치에 관한 계획을 수립합니다.
- 커뮤니케이션 계획: 서비스 중단 중 및 중단 후에 내부 및 외부 이해관계자를 위한 명확한 커뮤니케이션 계획을 수립합니다.
계획 개발
이 단계의 주요 단계는 BCP를 문서화하는 것입니다. 기술팀은 각 중요 기능의 도구, 프로세스, 복구 전략, 근거, 절차를 문서화합니다. 계획 개발에는 직원이 서비스 중단 중에 따라야 할 단계별 안내 작성도 포함됩니다. 구현 및 지속적인 유지보수 중에 계획에 변경사항을 도입해야 할 수 있으며 계획은 실시간 문서로 취급되어야 합니다.
구현
이 단계에서는 기술팀에서 만든 BCP를 사용하여 조직의 계획을 구현합니다. 구현에는 직원 교육과 BCP의 초기 테스트가 포함됩니다. 또한 중단이 발생할 경우 정상적인 운영을 복구하기 위해 계획을 사용하는 것도 구현에 포함됩니다. 주요 구현 단계는 다음과 같습니다.
- 초기 테스트 및 교육: BPC가 문서화된 후 시뮬레이션 및 연습을 통해 BPC를 테스트하여 공백을 파악하고 효과를 개선합니다. 서비스 중단 시 직원의 역할과 책임에 관한 교육을 진행합니다.
- 활성화: 서비스 중단이 발생하면 사전 정의된 트리거 및 절차에 따라 BCP를 시작합니다.
- 커뮤니케이션: 이해관계자에게 상황과 복구 작업에 관한 정보를 계속 제공합니다.
유지보수 및 검토
이 단계는 한 번만 발생하는 정의된 프로세스가 아닙니다. 대신 CI/CD 작업의 일반적인 부분이 되어야 하는 지속적인 노력을 나타냅니다. 서비스 중단이 발생할 경우 관련성 있고 실행 가능한 BCP를 유지할 수 있도록 조직 내에서 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 애플리케이션 예시의 이전 1단계 도구 모음 다이어그램을 확장하여 도구 모음의 내부 종속 항목인 애플리케이션 사용자 인증 정보, 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
개발자 영향과 운영 영향이 큰 소스 제어 관리 및 아티팩트 레지스트리와 같은 구성요소는 비즈니스에 가장 큰 영향을 미칩니다. 이러한 구성요소는 RTO 및 RPO 목표가 가장 낮아야 합니다. 다른 사분면의 구성요소는 우선순위가 낮으므로 RTO 및 RPO 목표가 더 높습니다. 일반적으로 도구 모음 구성요소의 RTO 및 RPO 목표는 해당 구성요소의 서비스를 복원하는 데 걸리는 시간과 비교하여 허용 가능한 데이터 또는 구성 손실의 양에 따라 설정해야 합니다.
예를 들어 그래프에서 Artifact Registry와 IaC 파이프라인의 서로 다른 위치를 생각해 보세요. 이 두 도구를 비교해 보면 Artifact Registry 중단이 IaC 파이프라인 중단보다 비즈니스 운영에 더 큰 영향을 미친다는 것을 알 수 있습니다. 아티팩트 저장소 중단은 애플리케이션을 배포하거나 자동 확장하는 기능에 상당한 영향을 미치므로 다른 도구에 비해 RTO 및 RPO 타겟이 더 낮습니다. 반면 그래프는 IaC 파이프라인 중단이 다른 도구보다 비즈니스 운영에 미치는 영향이 더 적음을 보여줍니다. 그러면 IaC 파이프라인의 RTO 및 RPO 목표가 더 높아집니다. 중단 중에 다른 방법을 사용하여 인프라를 배포하거나 업데이트할 수 있기 때문입니다.
비즈니스 연속성을 위한 대략적인 전략 선택
프로덕션 애플리케이션의 비즈니스 연속성 프로세스는 종종 일반적인 DR 전략 3가지 중 하나를 사용합니다. 그러나 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 파이프라인으로 전환하면 됩니다. 그러면 이 파이프라인이 활성 파이프라인이 됩니다. 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일 수 있습니다.
백업/복원 전략의 이점은 다음과 같습니다.
- 비용: 이 전략은 DR 시나리오 중에만 백업 파이프라인을 배포하므로 비용이 가장 적게 듭니다.
이 전략의 단점은 다음과 같습니다.
- 다운타임: 이 전략은 필요한 시점에 장애 조치 파이프라인을 만들기 때문에 구현하는 데 더 많은 시간이 걸립니다. 사전 빌드된 파이프라인을 사용하는 대신 서비스는 문제 복구 중에 생성되고 구성되어야 합니다. 아티팩트 빌드 시간과 외부 종속 항목을 가져오는 시간도 상당히 길어질 수 있습니다.
BCP 문서화 및 권장사항 구현
CI/CD 도구 모음을 매핑하고 종속 항목을 식별한 후 중요한 기능의 RTO 및 RPO 타겟을 결정했다면 다음 단계는 서면 BCP에 모든 관련 정보를 문서화하는 것입니다. BCP를 만들 때 각 핵심 기능을 복원하는 전략, 프로세스, 절차를 문서화합니다. 이 문서화 프로세스에는 서비스 중단 시 특정 역할의 직원이 따라야 할 단계별 절차를 작성하는 것이 포함됩니다.
BCP를 정의한 후 권장사항에 따라 CI/CD 도구 모음을 배포하거나 업데이트하여 RTO 및 RPO 타겟을 달성합니다. CI/CD 도구 모음은 매우 다를 수 있지만, 도구 모음에 관계없이 권장사항의 두 가지 주요 패턴, 즉 종속 항목에 대한 포괄적인 이해와 자동화 구현은 공통적입니다.
종속 항목과 관련하여 대부분의 BCP는 관리 범위 내의 시스템을 직접 다룹니다. 하지만 두 번째 또는 세 번째 외부 종속 항목도 마찬가지로 영향을 줄 수 있으므로 이러한 중요한 종속 항목에도 권장사항과 중복 조치를 구현하는 것이 중요합니다. 예시 애플리케이션의 외부 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 Observability는 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 | 솔루션 설계자