Apollo의 변경 계획과 제약 조건
변경 계획(Plan)은 허브가 관리되는 환경의 에이전트에 전달하는 작업 단위입니다. 설치, 버전 업그레이드나 구성 변경처럼 실제 환경에서 수행할 변경을 담습니다. 에이전트에 계획을 실행하도록 전달하려면 관련 제약 조건(Constraint)을 충족해야 합니다.
계획을 사용하면 진행 중이거나 앞으로 수행할 변경, 과거에 수행한 변경을 구분해서 볼 수 있습니다. 개별 작업의 시작과 종료, 상태와 실패 내용도 조사할 수 있습니다.
변경 계획의 종류
Apollo는 다음 종류의 계획을 지원합니다.
| 계획 | 수행하는 변경 |
|---|---|
| 새 배포 개체 설치 | 환경에 제품의 새 인스턴스를 설치 |
| 구성 변경 | 관리되는 배포 개체의 설정 재정의를 변경 |
| 버전과 구성 변경 | 배포 개체의 버전과 해당 버전에 맞는 설정 재정의를 함께 변경 |
| 배포 개체 제거 | 설치된 대상을 제거 |
| 비밀 정보 관리 | 비밀 정보의 생성, 편집과 삭제 |
제품 버전을 변경할 때는 새 코드에 맞는 설정 재정의를 함께 적용하여 버전과 구성을 일치시켜야 합니다.
환경이나 배포 개체의 Activity에서 계획과 제약을 확인할 수 있습니다. 에이전트가 수행한 과거 계획에는 시작 시각, 종료 시각과 상태가 남습니다.
계획이 실행되는 과정
허브의 오케스트레이션 엔진은 각 스포크에 가능한 계획들을 계속 평가합니다. 각 후보에 적용되는 제약을 확인하고, 조건을 충족한 계획을 스포크의 에이전트에 발행합니다.
에이전트는 허브에 새 계획이 있는지 주기적으로 확인하면서 환경과 배포 개체의 상태를 보고합니다. 발행된 계획을 받으면 필요한 변경을 수행하고, 성공 또는 실패를 다시 보고합니다.
이 과정에서는 다음을 구분해야 합니다.
- 계획 후보가 존재하는가?
- 그 계획의 실행 조건을 충족하는가?
- 에이전트에 계획이 발행되었는가?
- 실제 실행이 성공했는가?
어떤 계획을 우선하는가
오케스트레이션 엔진은 회수된 릴리스에서 다른 버전으로 전환하는 작업과 긴급 우회 명령을 수행하는 계획을 다른 계획보다 우선합니다.
일반적으로는 적용 가능한 최신 상태로 배포 개체를 옮기려고 합니다. 예를 들어 관련 제약을 모두 통과하는 최신 릴리스로 업그레이드하면서, 그 버전과 일치하는 최신 설정 재정의를 함께 적용할 수 있습니다.
수행할 작업이 없어 계획을 발행하지 않는 경우에는 배포 개체의 Activity에 그 이유를 표시합니다. 이미 가능한 상태에 도달했거나 현재 실행할 수 있는 변경이 없을 수 있습니다.
계획 상태와 실패 조사
환경이나 배포 개체의 Plans 탭에서 진행 상황을 확인할 수 있습니다. 계획을 선택하면 상세 정보, 메타데이터, 계획 안의 각 작업 상태와 계획 명세를 볼 수 있습니다.
계획이 실패하면 에이전트가 남긴 계획 출력을 확인합니다. 출력에는 실행 실패를 조사할 수 있는 정보가 포함됩니다.
Apollo는 가능한 경우 추가 실패 메타데이터도 제공합니다. Helm 차트 배포가 실패했다면 준비 상태가 되지 못한 Kubernetes 리소스를 확인할 수 있고, 제품 유효성 검사에서 실패했다면 관련 검사 오류를 볼 수 있습니다.
같은 실패 상태라도 산출물 접근, 구성의 유효성, 실제 워크로드 준비 과정 중 어느 단계에서 문제가 발생했는지에 따라 조치가 달라집니다. 계획의 상태 이름만 보지 않고 해당 작업의 출력과 환경 상태를 함께 확인합니다.
실행 실패 후 자동 억제와 롤백
계획이 실패하면 Apollo는 해당 배포 개체에 자동 변경 억제 시간대를 생성합니다. 이 억제는 그 대상에 대한 추가 작업을 막습니다. 같은 환경의 다른 배포 개체에는 계속 새 계획을 발행할 수 있습니다.
자동 억제 상태인 개체 수가 환경에 설정된 임계값을 초과하면, 시스템 전체의 문제일 수 있으므로 환경 수준의 억제를 만듭니다. 환경 수준의 억제는 환경 안의 모든 개체에 대한 추가 작업을 막습니다. 억제된 개체 수가 임계값 아래로 줄어들면 자동 환경 억제를 제거합니다.
실패 때문에 생성된 자동 억제에는 복구를 위한 예외가 있습니다. 이전 상태로 돌아가는 롤백 계획은 자동 억제가 있어도 허용될 수 있습니다. 그러나 사람이 직접 만든 억제 시간대는 그대로 존중합니다.
계획을 다시 계산하는 계기
다음과 같은 변화가 있으면 Apollo는 기존 계획을 무효화하고 해당 개체의 새 계획을 요청할 수 있습니다.
- 해당 개체의 의존 대상 또는 이 개체에 의존하는 대상의 보고된 상태가 바뀜.
- 개체의 관리 설정이 바뀜. 예를 들어 구독하는 릴리스 채널이 변경됨.
- 설정 재정의나 비밀 정보가 바뀜.
- 개체가 구독하는 채널에 제품 릴리스가 추가됨.
- 구독 채널에 있는 제품 릴리스가 회수됨.
- 기존 계획이 제약 때문에 차단된 상태로 4시간을 넘김.
상태 변화에 따른 재산정은 환경 안의 의존 관계 그래프를 기준으로 합니다. 어떤 대상의 버전이 바뀌면 그 대상뿐 아니라 직접 연결된 의존 대상과 종속 대상이 선택할 수 있는 버전에도 영향을 줄 수 있기 때문입니다.
가상의 관계가 A는 B에 의존하고, B는 C에 의존한다는 두 연결로만 이루어져 있다면 다음과 같이 새 계획을 요청합니다.
| 바뀐 대상 | 새 계획을 요청할 대상 |
|---|---|
| C | C 자체와 C에 직접 의존하는 B |
| B | B 자체, B의 의존 대상인 C, B에 직접 의존하는 A |
| A | A 자체와 A의 의존 대상인 B |
이 예에서 새 계획을 요청하는 대상은 상태가 바뀐 개체와 직접 연결된 이웃 개체입니다.
제약 조건이 하는 일
제약 조건은 에이전트가 계획을 실행하기 전에 충족해야 하는 조건입니다. 제품과 환경의 설정, 의존 관계와 현재 상태를 검토하여 지금 변경해도 되는지 판단합니다.
개체의 Activity에는 어떤 제약 때문에 계획이 차단되는지 표시됩니다. 업그레이드가 진행되지 않는다면 새 버전의 존재뿐 아니라 이 차단 이유를 확인합니다.
긴급 상황에서는 권한을 가진 사용자가 일반 제약을 우회하는 명령을 제출할 수 있습니다. 이런 우회는 정상 운영의 조건을 바꾸는 행동이므로, 영향을 이해하고 조직의 승인 및 운영 절차에 따라 사용해야 합니다.
유지보수 시간대 제약
유지보수 시간대(maintenance window)는 변경을 허용하는 시간입니다. 환경 운영자는 설치, 업그레이드나 구성 변경을 허용할 환경 및 개체의 시간대를 정할 수 있습니다. 제품 편집자는 제품 릴리스의 승격에 적용할 제품 유지보수 시간대를 설정할 수 있습니다.
계획 실행 시에는 해당 개체에 실제 적용되는 유지보수 시간대를 계산합니다. 현재 시각이 그 시간대 밖이면 다음 허용 시간까지 계획 실행을 막습니다.
개체에 적용할 시간대의 선택
실제 적용할 시간대는 다음 우선관계에 따라 결정합니다.
- 제품 유지보수 시간대가 있고 환경이 이를 무시하도록 설정하지 않았다면 제품의 시간대를 사용합니다.
- 그 밖의 경우에는 개체의 시간대를 사용합니다.
- 개체가 별도 시간대를 지정하지 않았다면 환경의 시간대를 사용합니다.
개체나 환경에 임시 유지보수 시간대 예외 설정이 활성화되어 있으면, 계산된 일반 시간대와 관계없이 시간대 제약을 통과할 수 있습니다. 이 예외가 제품 의존 관계 등 모든 다른 제약을 함께 없애는 것은 아닙니다.
운영자는 다음 시간대를 기다리거나, 권한이 있다면 시간 설정을 변경하거나, 임시 예외 설정에 필요한 승인을 요청할 수 있습니다.
회수된 릴리스에서 전환하는 경우
Apollo는 기본적으로 회수된 릴리스에서 다른 버전으로 전환할 때 유지보수 시간대를 무시합니다. 환경 설정의 다음 필드로 이 동작을 조정할 수 있습니다.
require-maintenance-windows-for-no-downtime-recalled-release-roll-offs: true
이 설정은 회수 대응과 일반적인 업그레이드의 시간 정책을 구분하는 데 사용합니다. 실제 변경에 적용되는 다른 제약도 함께 확인해야 합니다.
제품 의존 관계 제약
제품 릴리스를 게시할 때 다른 제품에 대한 의존 관계를 매니페스트의 product-dependencies 확장에 지정할 수 있습니다. 각 의존 제품에는 허용할 버전 범위를 포함해야 합니다.
extensions:
product-dependencies:
- product-group: com.palantir.example
product-name: example
minimum-version: 1.0.0
maximum-version: 1.x.x
- product-group: com.palantir.other
product-name: other
minimum-version: 2.53.1
maximum-version: 2.x.x
이 구성은 제품 이름과 버전 범위를 보여 주는 예입니다. 실제 제품의 의존 관계에 맞게 값을 지정해야 합니다.
Apollo는 계획을 실행할 때 다음을 확인합니다.
- 제안한 변경이 해당 제품의 의존 관계를 위반하지 않는가?
- 이 제품에 의존하는 다른 개체들도 목표 릴리스에 대한 버전 조건을 계속 충족하는가?
일부 의존 기능을 사용하지 않아 해당 제품을 배포하지 않는 경우에는 개체의 고급 설정에서 무시할 의존 관계를 지정할 수 있습니다. 이 설정은 실제로 필요한 의존 관계까지 생략할 수 있으므로, 해당 의존 기능을 사용하지 않는다는 점과 제품에 미치는 영향을 정확히 이해할 때에만 사용합니다.
변경 억제 시간대 제약
변경 억제 시간대(suppression window)는 지정한 시간 동안 계획 발행을 막습니다. 개별 배포 개체 또는 환경 전체에 설정할 수 있으며, 유지보수 시간대보다 우선합니다.
억제는 다음 경로로 생성됩니다.
| 생성 경로 | 적용과 예외 |
|---|---|
| 사용자가 수동으로 생성 | 환경 편집자는 전체 환경이나 개체에 설정할 수 있다. 환경 또는 개체 운영자는 역할이 부여된 개체에 설정할 수 있다. |
| 개체의 계획 실패로 자동 생성 | 실패한 계획을 롤백하려는 경우에는 자동 억제를 무시할 수 있다. |
| 릴리스 승격 과정에서 자동 생성 | 새 버전이 계속 기존 버전을 밀어내 관찰 기간을 채우지 못하는 상황을 막는다. 회수된 릴리스에서 전환할 때에는 이 자동 억제를 무시할 수 있다. |
수동으로 환경을 바꾸기 전에는 해당 대상에 수동 억제를 적용해야 합니다. 그렇지 않으면 Apollo가 동시에 계획을 발행하여 수동 변경과 충돌할 수 있습니다.
억제 시간대를 만들 때 Cancel Active Plans를 선택하면 그 범위의 실행 중인 계획을 취소할 수 있습니다. 별도의 Cancel active Plans 작업으로 환경, 개체 또는 개별 계획을 대상으로 취소할 수도 있습니다.
취소만 하면 Apollo가 같은 계획을 바로 다시 발행할 수 있습니다. 따라서 취소 작업에서는 짧은 억제 시간대를 만들도록 안내합니다.
산출물 누락 제약
설치나 업그레이드를 실행하려면 Apollo 에이전트가 환경에 연결된 아티팩트 레지스트리에서 릴리스의 산출물을 가져올 수 있어야 합니다. 필요한 산출물이 없으면 계획을 차단합니다.
계획을 계산할 때에는 다음 과정을 사용합니다.
- 제품 릴리스 매니페스트에서 필요한 산출물을 확인합니다.
- 환경에 지정된 레지스트리 가운데 각 산출물에 맞는 레지스트리를 선택합니다.
- 레지스트리에 산출물이 존재하는지 점검합니다. 다만 허브 접근을 기대하지 않는 레지스트리는 이 점검을 생략합니다.
제약 화면에서는 산출물을 세 가지로 구분합니다.
| 표시 | 의미 | 계획에 미치는 영향 |
|---|---|---|
Unavailable | 선택한 레지스트리에서 산출물을 찾지 못했거나 레지스트리 요청이 실패함 | 계획을 차단할 수 있다. |
Available | 산출물이 존재하고 가져올 수 있음 | 해당 산출물의 사용 가능 조건을 충족한다. |
Unchecked | URI에 맞는 레지스트리가 없거나 허브가 접근할 수 없어 확인하지 못함 | 이 분류 자체로 계획을 차단하지 않는다. |
산출물이 실제로 없으면 필요한 레지스트리에 게시해야 합니다. 산출물은 존재하는데 Unavailable로 표시된다면 허브에서 레지스트리로 접근할 수 있는지 확인합니다.
허브에서는 접근할 수 없지만 환경의 에이전트가 사용하는 레지스트리라면 Hub access를 Hub access not expected로 설정해 허브의 존재 확인을 생략할 수 있습니다. 이 설정은 실제 산출물을 만들거나 에이전트의 접근 권한을 부여하지 않습니다. 에이전트가 실행할 때 필요한 파일을 실제로 가져올 수 있는지는 별도로 충족해야 합니다.