Cloud Composer 1은 사후 유지보수 모드 상태입니다. Google은 Airflow의 새 버전, 버그 수정, 보안 업데이트를 비롯한 Cloud Composer 1 추가 업데이트를 출시하지 않습니다. Cloud Composer 2로 마이그레이션하는 것이 좋습니다.

이 페이지는 Cloud Translation API를 통해 번역되었습니다.

환경 스냅샷으로 재해 복구

Cloud Composer 1 | Cloud Composer 2 | Cloud Composer 3

이 페이지에서는 재해 복구를 위해 환경 스냅샷을 사용하는 방법을 설명합니다.

정의

이 가이드에서는 다음 정의를 사용합니다.

재해는 Cloud Composer 또는 환경 작업에 필요한 기타 구성요소를 사용할 수 없는 경우를 의미합니다. 이 경우에는 다른 리전 및 Cloud Composer 환경에 대한 장애 조치가 필요합니다. 장애 조치의 원인은 자연적이거나 인위적일 수 있고 Google Cloud 리전의 다운타임 및 자체 인프라 중단을 모두 포함합니다.
Cloud Composer의 맥락에서 재해 복구(DR)는 재해 발생 후 환경 운영을 복원하는 프로세스입니다. 이 프로세스에는 아마도 다른 리전에 환경을 다시 만드는 과정이 포함됩니다. 재해 복구에 대한 자세한 내용은 재해 복구 계획 가이드를 참조하세요.
기본 환경은 DR 기능을 사용 설정하려는 Cloud Composer 환경입니다.
장애 조치 환경은 기본 환경의 활동을 이어 받도록 설계된 Cloud Composer 환경입니다.
웜 DR 시나리오는 재해 발생 전에 생성되는 대기 장애 조치 환경을 사용하는 재해 복구의 한 변형입니다.
콜드 DR 시나리오는 재해 발생 후 장애 조치 환경을 만드는 재해 복구의 한 가지 유형입니다.
리전 간 DR은 기본 및 장애 조치 환경이 서로 다른 리전에 있는 웜 또는 콜드 재해 복구의 변형입니다.

재해 복구 절차 정보

재해 복구 절차는 재해로 인해 기본 환경이 작동 중지(손상되었거나 액세스 불가)된 경우 문제를 해결합니다.

이 절차에서는 기본 환경이 현재 상태에서 재해 해결을 위해 수정되지 않는다고 가정합니다. 대신 두 번째(장애 조치) 환경을 나란히 만듭니다. 이 환경이 기본 환경 대신 작동합니다. 이후 단계에서는 기본 환경으로 돌아가거나 장애 조치 환경을 계속 사용하도록 결정할 수 있습니다.

이 절차에서는 장애 조치 환경이 사용되기 때문에 기본 환경으로 다시 전환할 때 변경사항이 도입됩니다. 기본 환경과 장애 조치 환경 사이의 변경사항에는 다음 항목이 포함됩니다(목록이 전체가 아님).

웹 서버 URL이 달라집니다. 따라서 Airflow UI 및 Airflow REST API 엔드포인트 주소가 달라집니다.
환경의 버킷 URL이 달라집니다.
네트워크 및 액세스 권한 구성을 조정해야 할 수 있습니다.

웜 DR 시나리오를 사용하는 경우 웹 서버, 환경의 버킷 주소, 네트워크 구성을 미리 알고 있어야 합니다.

시작하기 전에

Cloud Composer는 2.0.32 이상 버전에서 예약된 스냅샷을 지원합니다. 환경 스냅샷은 2.0.9 이상 버전에서 지원됩니다.

스냅샷을 만들려면 Airflow 데이터베이스에 20GB 미만의 데이터가 포함되어야 합니다.
스냅샷을 만들려면 환경 버킷의 /dags, /plugins, /data 폴더에 있는 총 객체 수가 100,000개 미만이어야 합니다.
XCom 메커니즘을 사용하여 파일을 전송하는 경우 Airflow 가이드라인에 따라 사용해야 합니다. XCom을 사용하여 큰 파일이나 다수의 파일을 전송하면 Airflow 데이터베이스 성능이 영향을 받고 스냅샷을 로드하거나 환경을 업그레이드할 때 오류가 발생할 수 있습니다. 대용량 데이터를 전송하려면 Cloud Storage와 같은 대안을 사용하는 것이 좋습니다.

준비 개요

두 가지 DR 시나리오 모두 다음 준비 단계가 포함됩니다.

장애 조치 환경을 만듭니다.
- 웜 DR 시나리오에서는 이 환경을 계속 사용할 수 있습니다.
- 콜드 DR 시나리오에서는 재해 복구 절차를 테스트하는 용도로만 이 환경을 만듭니다. 준비가 완료되면 이 환경을 삭제하고 재해 발생 후에 다시 만듭니다.
스냅샷 버킷을 만듭니다.
- DR 리전에서 버킷을 사용할 수 있어야 합니다. 리전 간 DR의 경우 스냅샷 버킷이 여러 리전에 있거나 기본 환경과 다른 리전에 있어야 합니다.
- DAG가 리전 리소스에 액세스할 수 있는지 확인합니다.
DB 유지보수를 설정합니다.
예약된 스냅샷을 설정합니다.
재해 복구 절차를 테스트합니다.

재해 복구 개요

재해 발생 후:

(콜드 DR만 해당) 장애 조치 환경을 만듭니다.
가능하면 기본 환경에서 DAG 실행을 중지합니다.
스냅샷 버킷에서 장애 조치 환경으로 스냅샷을 로드합니다.
필요한 경우 장애 조치 환경의 구성을 조정합니다.
기본 환경에서 수행할 작업을 결정합니다.

준비 단계

아래 설명된 단계를 수행하여 해당 환경에 맞게 재해 복구를 설정합니다.

장애 조치 환경 만들기

장애 조치 환경으로 작동하는 환경을 만듭니다.

다음 가이드라인을 참조하세요.

기본 환경 및 장애 환경은 동일한 버전의 Cloud Composer 및 Airflow를 사용해야 합니다.

주의: 가능하지만 호환성과 관련된 추가 변경사항이 요구될 수 있으므로 이후 버전의 Cloud Composer 또는 Airflow로 장애 조치를 수행하지 마세요.
웜 DR 시나리오의 경우 두 환경을 모두 동기화된 상태로 업데이트 및 업그레이드해야 합니다. 예를 들어 기본 환경을 이후 Cloud Composer 버전으로 업그레이드하거나 PyPI 패키지를 설치하는 경우 장애 조치 환경에도 이러한 변경 사항이 포함되어야 합니다.
기본 환경과 다른 리전에 장애 조치 환경을 만드는 것이 좋습니다. 그러면 전체 리전의 가용성에 영향을 주는 재해와 같이 다양한 범위의 재해 시나리오를 지원할 수 있습니다.
Terraform을 사용하여 기본 환경 및 장애 조치 환경을 만들어서 두 환경 모두 구성을 일관성 있게 만드는 것이 좋습니다. 기본 환경 및 장애 조치 환경 모두에 대한 Terraform 정의가 동기화되었는지 확인하세요.
장애 조치 환경의 구성(예: 환경 크기, 스케줄러 수, IAM 권한)이 기본 환경의 구성과 일치하는 것이 좋습니다. 두 환경 모두 IAM 권한이 사용자 및 스냅샷에 대해 적절한 액세스 권한을 부여해야 합니다.

리소스 가용성 확인

DAG는 외부 리소스에서 작동할 수 있고, 이러한 리소스에 대한 액세스는 환경의 서비스 계정에 부여된 권한, 네트워크 구성 또는 프로젝트와 같은 해당 환경의 구성에 따라 달라질 수 있습니다. 이러한 리소스를 장애 조치 환경에서 사용할 수 있는지 확인합니다.

환경은 Airflow에 저장된 연결을 통해 일부 외부 리소스와 상호 작용할 수 있습니다. 장애 조치 환경에서 기본 환경에 대해 이러한 리소스를 조정해야 하는지 확인합니다.

스냅샷용 스토리지 버킷 만들기

환경 스냅샷을 위해 새 스토리지 버킷을 만듭니다. 보관 정책 및 수명 주기에 대한 구성이 버킷 수준에서 적용되기 때문에 재해 복구에 환경 버킷을 사용하지 마세요.

이 스토리지 버킷에서 IAM 권한, 보존 정책, 수명 주기 구성이 실수로 삭제되거나 무단으로 액세스하지 못하도록 설정되었는지 확인하세요. 스냅샷용 버킷 구성에 대한 자세한 내용은 예약된 스냅샷 구성을 참조하세요.

다음과 같은 작업을 할 수 있습니다.

다른 리전에 버킷을 만듭니다.
멀티 리전 버킷을 만듭니다.

DB 유지보수 설정

데이터베이스 정리를 설정하여 Airflow 데이터베이스를 크기 제한 내로 작게 유지합니다. 이렇게 하면 스냅샷 저장 및 로드 프로세스가 더 빨라집니다. 스냅샷을 만들려면 Airflow 데이터베이스에 20GB 미만의 데이터가 포함되어야 합니다.

예약된 스냅샷 설정

기본 환경에 대해 예약된 스냅샷을 설정합니다.

스냅샷은 정상 환경에서만 만들 수 있으므로, 재해가 발생하기 전 스냅샷을 저장해야 합니다.

스냅샷 작동 방법에 대한 자세한 내용은 환경 스냅샷 저장 및 로드를 참조하세요. 저장된 스냅샷을 찾을 위치에 대한 자세한 내용은 이 문서의 환경 스냅샷 저장 섹션을 참조하세요.

(선택사항) 예약된 스냅샷 작업에 대한 모니터링 설정

간격이 최소 12시간에 한 번 이상으로 예약된 스냅샷의 경우 Cloud Monitoring을 사용해서 스냅샷이 자동으로 생성되지 않았을 때 알림을 받을 수 있습니다.

빈도가 낮은 예약의 경우 Google Cloud CLI를 사용해서 스냅샷 작업 결과를 확인합니다. 스냅샷 저장 작업 확인을 참조하세요.

Google Cloud 콘솔에서 Monitoring 페이지로 이동합니다.
Monitoring으로 이동
Monitoring 탐색창에서 알림을 선택합니다.
알림 채널을 만들지 않고 알림을 받으려면 알림 채널 수정을 클릭하고 알림 채널을 추가합니다. 채널을 추가한 후 알림 페이지로 돌아갑니다.
알림 페이지에서 정책 만들기를 클릭합니다.
측정항목을 선택하려면 측정항목 선택 메뉴를 확장한 후 다음을 수행합니다.
1. 메뉴를 관련 항목으로 제한하려면 필터 표시줄에 Composer Snapshot을 입력합니다. 메뉴를 필터링한 후 결과가 없으면 활성 리소스 및 측정항목만 표시 전환을 중지합니다.
2. 리소스 유형에 대해 Cloud Composer 환경을 선택합니다.
3. 측정항목 카테고리에 대해 환경을 선택합니다.
4. 측정항목에 대해 스냅샷 생성 횟수를 선택합니다.
5. 적용을 선택합니다.

필터 추가를 클릭하고 드롭다운 메뉴를 사용하여 다음 필터를 추가합니다.

필터	비교 연산자	값
리소스 라벨 > environment_name	=	예약된 스냅샷을 모니터링하려는 환경 이름입니다.
모니터 라벨 > 결과	=	`SUCCEEDED`

Transform 데이터 섹션에서 다음 속성을 설정합니다.
- 순환 기간에 대해 이 경고의 모니터링 기간을 선택합니다. 이 값은 다음 단계에서 임곗값 구성에 영향을 줍니다.
  예약된 스냅샷 모니터링에 권장되는 값은 1일입니다.
- 순환 기간 함수에 대해 델타를 선택합니다.
다음을 클릭합니다.

알림 트리거 구성 페이지의 설정에 따라 알림이 트리거되는 시점이 결정됩니다. 다음 표의 설정으로 이 페이지를 작성합니다.

필드	값
`Condition type`	`Threshold`
`Alert trigger`	`Any time series violates`
`Threshold position`	`Below threshold`
`Threshold value`	알림에 대한 순환 기간으로 구성된 기간 내에 저장될 것으로 예상되는 예약된 스냅샷 수입니다. 다음 수식을 사용하여 이 값을 계산합니다. `(rolling window in hours / schedule frequency in hours) - 1` 참고: 수식에서 `1`시간을 뺀 것은 스냅샷 완료 시간이 달라질 것을 고려한 것입니다. 이렇게 하면 모니터링 검사 중 최신 스냅샷이 계속 실행될 때 거짓양성이 발생하는 것을 방지하는 데 도움이 됩니다. 예시: 권장되는 순차 기간 1일을 사용하고 예약 빈도가 2시간에 한 번이면 이 값을 `11`로 설정합니다(계산식: `24 / 2 - 1 = 11`). 일정이 올바르게 실행되면 24시간 이내에 최소 11개의 스냅샷이 저장됩니다. 그렇지 않으면 스냅샷 작업이 성공적으로 완료되지 않았고 Cloud Monitoring에서 이 알림이 트리거됩니다.
`Condition name`	조건에 대한 커스텀 이름입니다.

다음을 클릭합니다.
선택사항: 알림 정책에 알림을 추가하려면 알림 채널을 클릭합니다. 대화상자의 메뉴에서 하나 이상의 알림 채널을 선택한 다음 확인을 클릭합니다.
선택사항: 이슈 자동 종료 기간을 업데이트합니다. 이 필드는 측정항목 데이터가 없어 Monitoring에서 이슈를 닫을 시간을 결정합니다.
선택사항: 문서를 클릭한 후 알림 메시지에 포함할 정보를 추가합니다.
알림 이름을 클릭하고 알림 정책 이름을 입력합니다.
정책 만들기를 클릭합니다.

자세한 내용은 알림 정책을 참조하세요.

재해 복구 절차 테스트

설정 후 재해 복구 절차를 테스트하고 이후 주기적으로 테스트해야 합니다. 이렇게 하면 실제 재해 복구 프로세스에 영향을 줄 수 있는 잠재적인 문제를 해결할 수 있습니다.

콜드 DR 시나리오에서는 재해 복구 절차 테스트가 끝난 후 장애 조치 환경을 삭제할 수 있습니다.

스냅샷 저장 작업 확인

Google Cloud CLI를 사용하여 스냅샷 저장 작업 목록을 검색하고 스냅샷이 재해 복구 시나리오에 맞게 준비되었는지 확인할 수 있습니다.

이 방법은 스냅샷을 12시간에 한 번 이하로 저장하는 경우에 유용합니다. 스냅샷 저장을 더 자주 확인하려면 Cloud Monitoring 알림을 구성하는 것이 좋습니다. 예약된 스냅샷 작업에 대한 모니터링 설정을 참조하세요.

gcloud

특정 환경의 모든 스냅샷 작업을 나열합니다. 전체 명령어 참조는 gcloud composer operations list를 참고하세요.

gcloud composer operations list \
    --locations LOCATION \
    --filter="metadata.operationType=SAVE_SNAPSHOT AND 
    metadata.resource=projects/PROJECT_ID/locations/LOCATION/environments/ENVIRONMENT_ID"
    --format yaml

다음과 같이 바꿉니다.

LOCATIONS를 환경이 있는 리전 식별자 목록으로 바꿉니다.
PROJECT_ID를 환경이 있는 프로젝트의 식별자로 바꿉니다.
ENVIRONMENT_ID를 스냅샷 작업을 확인하려는 환경의 식별자로 바꿉니다.

예를 들면 다음과 같습니다.

gcloud composer operations list \
    --locations us-central1 \
    --filter="metadata.operationType=SAVE_SNAPSHOT AND 
    metadata.resource=projects/my-project/locations/us-central1/environments/my-environment"
    --format yaml

재해 발생 후

재해 발생 후 기본 환경을 복구하려면 아래 설명된 단계를 수행합니다.

(콜드 DR만 해당) 장애 조치 환경 만들기

장애 조치 환경 만들기 섹션의 안내를 따릅니다.

기본 환경에서 DAG 실행을 중지합니다.

가능하면 기본 환경에서 DAG 실행을 중지합니다.

기본 환경에 계속 액세스할 수 있으면 모든 DAG를 일시중지합니다.
기본 환경의 버킷에 액세스할 수 있으면 환경 버킷의 모든 DAG를 기본 환경 버킷의 /dags 외부 폴더로 이동합니다.

장애 조치 환경에 스냅샷 로드

기본 환경의 스냅샷을 장애 조치 환경에 로드합니다.

스냅샷이 장애 조치 환경에 로드되면 스냅샷을 만든 후 기본 환경에서 아무 것도 수행되지 않은 것처럼 태스크가 예약되고 실행됩니다. 그러나 이러한 태스크 중 일부는 이미 기본 환경에서 수행되었을 수 있습니다. 장애 조치 환경은 스냅샷을 생성한 이후부터 재해 발생 전까지 어떤 태스크가 수행되었는지 인식할 수 있는 방법이 없습니다. 따라서 일부 태스크는 기본 환경과 장애 조치 환경을 포함하여 두 번 실행될 수 있습니다. 모든 태스크가 멱등성을 갖도록 하고 예약된 스냅샷을 2시간 마다 생성하는 것이 좋습니다.

(필요한 경우) 장애 조치 환경의 구성 조정

경우에 따라 기본 환경의 스냅샷을 로드한 후 장애 조치 환경의 구성을 변경해야 할 수 있습니다.

예를 들어 콜드 DR 시나리오에서는 장애 조치 환경에서 서로 다른 Airflow 환경 변수 집합을 사용해야 할 수 있습니다. 또 다른 예시로, 웜 DR 시나리오에서는 사용자가 장애 조치 환경에 액세스할 수 있도록 Airflow UI에서 사용자에게 권한을 부여해야 할 수 있습니다.

이러한 변경사항을 수동으로 수행하거나 gcloud composer environment update 명령어를 실행하여 장애 조치 환경의 구성을 변경하는 명령어로 셸 스크립트를 준비할 수 있습니다.

기본 환경에서 수행할 작업 결정

일부 재해는 기본 환경에 연결할 수 없지만 계속 작동하거나 올바르게 작동하지 않기 때문에 발생할 수 있습니다. 예를 들어 인프라 오류로 인해 네트워크를 통해 기본 환경에 액세스하지 못할 수 있습니다. 또 다른 예시로, 일부 오류가 발생하거나 용량이 감소한 상태로 환경이 작동하지만 일부 DAG가 계속 실행될 수 있습니다.

원래 환경이 계속 작동할 때는 새 환경이 대체 환경으로 생성되더라도 Cloud Composer 또는 DAG를 통해 액세스되는 기타 서비스와 직접적으로 관련된 비용이 발생할 수 있습니다. 이 환경에서는 일부 DAG를 계속 실행할 수 있습니다. 따라서 계속 실행 중인 기본 환경과 스냅샷 로드 후 장애 조치 환경에서 각각 한 번씩 일부 작업이 두 번 실행될 수 있습니다.

기본 환경이 존재하지만 올바르게 작동하지 않는 경우

모든 관련 데이터가 복구되었으면 기본 환경을 삭제할 수 있습니다. 예를 들어 네트워킹 구성 또는 /dags 및 /plugins 폴더 외부의 환경 버킷 콘텐츠와 같이 환경 스냅샷에 포함되지 않은 데이터를 복구해야 할 수 있습니다.

기본 환경이 다시 액세스 가능해지고 정상화되는 경우

기본 환경에 일시적으로만 액세스할 수 없고 다시 액세스 가능해지고 정상화되면 다음 중 한 가지 방법을 선택할 수 있습니다.

장애 조치 환경을 계속 사용합니다.
기본 환경으로 돌아갑니다.

장애 조치 환경을 계속 사용하려면 다음 안내를 따르세요.

기본 환경에서 DAG가 계속 실행되면 가능한 한 빨리 이를 일시중지합니다.
모든 관련 데이터가 복구되었는지 확인한 후 기본 환경을 삭제합니다.
예약된 스냅샷 설정과 같은 장애 조치 환경에 대한 DR 준비 단계를 반복합니다.

기본 환경으로 돌아가려면 다음 안내를 따르세요.

장애 조치 환경에서 모든 DAG를 일시중지합니다.
장애 조치 환경에서 모든 DAG 실행이 완료될 때까지 기다리거나 중지합니다.
장애 조치 환경의 스냅샷을 저장합니다.
이 스냅샷을 기본 환경에 로드합니다.
기본 환경에서 DAG 일시중지를 해제합니다.
필요한 경우 장애조치 환경을 삭제합니다.