View a markdown version of this page

이전 KCL 버전으로 롤백 - Amazon DynamoDB
1단계에서 KCL 1.x로 롤백2단계에서 1단계로 롤백1단계: KCL 마이그레이션 도구 실행2단계: 1단계 구성으로 코드 재배포(선택 사항)

이전 KCL 버전으로 롤백

이 주제에서는 KCL 3.5.x+ 소비자 애플리케이션을 KCL 1.x로 롤백하는 방법을 설명합니다. 롤백 프로세스는 애플리케이션이 현재 어느 마이그레이션 단계에 있는지에 따라 달라집니다.

1단계에서 KCL 1.x로 롤백

애플리케이션이 1단계(CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1)인 경우 이전 코드를 재배포하여 KCL 1.x로 롤백할 수 있습니다. 1단계는 KCL 1.x와 하위 호환되며 리스 테이블에 마이그레이션별 항목을 생성하지 않습니다. 마이그레이션 도구가 필요하지 않습니다. 1단계에서 롤백하려면 KCL 1.x 버전의 코드를 모든 워커에 재배포합니다.

중요

2단계(CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X)는 롤백의 주요 변경 사항입니다. 애플리케이션이 2단계로 전환되면 KCL 1.x와 하위 호환되지 않는 비 리스 항목(WORKER_METRIC_STATS 및 Migration3.0)이 리스 테이블에 기록됩니다. 이 때문에 KCL 1.x로의 직접 롤백이 영구적으로 방지됩니다. 2단계로 진행하기 전에 1단계에서 애플리케이션을 장기간 베이킹하여 안정성을 검증하는 것이 좋습니다.

2단계에서 1단계로 롤백

애플리케이션이 2단계(CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X)인 경우 GitHub 웹 사이트의 KCL 마이그레이션 도구를 사용하여 1단계(CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1)로 롤백해야 합니다. 다음 2단계 프로세스로 진행됩니다.

  1. GitHub 웹 사이트에서 KCL 마이그레이션 도구를 실행합니다.

  2. 1단계 구성으로 코드를 재배포합니다(선택 사항).

중요

두 단계(2단계에서 1단계로, 그런 다음 KCL 1.x로)를 연속해서 롤백할 수 없습니다. KCL 마이그레이션 도구는 2단계에서 1단계로의 롤백만 처리합니다. 이 도구는 리스 테이블에서 비 리스 항목을 삭제하지 않습니다. 이러한 항목은 KCL 1.x와 하위 호환되지 않으므로 2단계에서 KCL 1.x로 두 단계를 한 번에 롤백할 수 없습니다.

1단계: KCL 마이그레이션 도구 실행

2단계(CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X)에서 1단계(CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1)로 롤백해야 하는 경우 KCL 마이그레이션 도구를 실행합니다. 도구는 다음 작업을 수행합니다.

  • DynamoDB의 리스 테이블에서 글로벌 보조 인덱스(LeaseOwnerToLeaseKeyIndex)를 제거합니다. 이 인덱스는 KCL 3.5.x+에 의해 생성되지만 1단계로 롤백할 때는 필요하지 않습니다.

  • 모든 워커가 KCL 1.x와 호환되는 모드로 실행되고 이전 KCL 버전에서 사용된 로드 밸런싱 알고리즘을 사용하도록 합니다. 그러면 KCL 3.5.x+의 새 로드 밸런싱 알고리즘에 문제가 있는 경우 해당 문제가 즉시 완화됩니다.

중요

리스 테이블의 코디네이터 상태 항목(Migration3.0)은 마이그레이션, 롤백, 롤포워드 프로세스 중에 삭제되어서는 안 됩니다.

참고

소비자 애플리케이션의 모든 워커는 지정된 시간에 동일한 로드 밸런싱 알고리즘을 사용해야 합니다. KCL 마이그레이션 도구를 사용하면 KCL 3.5.x+ 소비자 애플리케이션의 모든 워커가 KCL 1.x 호환 모드로 전환되므로 1단계로 배포를 롤백하는 동안 모든 워커가 동일한 로드 밸런싱 알고리즘을 실행하게 됩니다.

KCL GitHub 리포지토리의 스크립트 디렉터리에서 KCL 마이그레이션 도구를 다운로드할 수 있습니다. 리스 테이블에 쓰고 업데이트하는 데 필요한 권한이 있는 워커 또는 호스트에서 스크립트를 실행합니다. KCL 소비자 애플리케이션에 대해 적절한 IAM 권한이 구성되어 있는지 확인합니다. KCL 애플리케이션당 한 번만 스크립트를 실행해야 합니다. 다음 명령을 사용하여 KCL 마이그레이션 도구를 실행합니다.

python3 ./KclMigrationTool.py --region region --mode rollback [--application_name applicationName] [--lease_table_name leaseTableName]

파라미터

--region

리전을 사용자의 AWS 리전으로 바꿉니다.

--application_name

리스 테이블에 기본 이름을 사용하는 경우 이 파라미터가 필요합니다. 리스 테이블에 사용자 지정 이름을 지정한 경우 이 파라미터를 생략할 수 있습니다. applicationName을 실제 KCL 애플리케이션 이름으로 바꿉니다. 이 도구는 사용자 지정 이름이 제공되지 않은 경우 이 이름을 사용하여 기본 테이블 이름을 파생합니다.

--lease_table_name

이 파라미터는 KCL 구성에서 리스 테이블에 사용자 지정 이름을 설정한 경우에 필요합니다. 기본 테이블 이름을 사용하는 경우 이 파라미터를 생략할 수 있습니다. leaseTableName을 리스 테이블에 지정한 사용자 지정 테이블 이름으로 바꿉니다.

2단계: 1단계 구성으로 코드 재배포(선택 사항)

2단계에서 1단계로 롤백하기 위해 KCL 마이그레이션 도구를 실행한 후 다음 메시지 중 하나가 표시됩니다.

메시지 1

"Rollback completed. Your application was running Phase 2 (2x compatible) functionality. Please rollback to Phase 1 by deploying your KCL 3.5.x application with the Phase 1 configuration."

필요한 작업: 워커가 KCL 1.x 호환 모드에서 실행 중이었습니다(2단계가 아직 전체 3.x 로드 밸런싱으로 자동 전환되지 않음). 1단계 구성(CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1)을 사용하여 KCL 3.5.x+ 애플리케이션을 워커에 재배포합니다.

메시지 2

"Rollback completed. Your KCL application was running Phase 2 (3x) functionality and has been rolled back to Phase 2 (2x compatible) mode. If you don't see mitigation after a short period of time, please rollback to Phase 1 by deploying your KCL 3.5.x application with the Phase 1 configuration."

필요한 작업: 워커가 전체 KCL 3.x 로드 밸런싱으로 자동 전환되었고 KCL 마이그레이션 도구가 다시 KCL 1.x 호환 모드로 전환되었습니다. 문제가 해결되면 재배포할 필요가 없습니다. 문제가 지속되면 1단계 구성(CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1)으로 KCL 3.5.x+ 애플리케이션을 워커에 재배포합니다.