| Status | Authors | Coach | DRIs | Owning Stage | Created |
|---|---|---|---|---|---|
| proposed |
@skarbek
|
@rymai
| - |
기능 플래그
요약
이 문서는 특히 셀 인프라에서 사용될 때 개발에서 Feature Flags의 GitLab 현재 사용 및 미래 사용을 다루고자 합니다. Feature Flags의 개발 문서에 대한 참조는 여기를 확인하세요.
:warning: GitLab 애플리케이션의 Feature Flags 기능 세트와 혼동하지 마세요.
현재 사용 방법
Feature Flags는 GitLab 개발에 매우 중요한 역할을 합니다. 코드 청크들은 안전하게 테스트할 수 있는 능력을 가지고 있어서 새로운 기능이 원하는 대로 원하는 규모에서 작동할 것으로 확신을 높일 수 있습니다. Cells는 Feature Flags의 광범위한 사용과 관련된 이미 존재하는 기술적 부채의 새로운 도전 과제를 제시합니다. 추가 정보를 원하시면 기존 Feature Flags에 대한 우리의 청사진을 참조하세요: Feature Flag Use Cases
Cells에서의 도전
- 셀에 존재하는 액터를 이해하기 위한 발견 능력
- 셀별로 롤아웃 능력이 존재하지 않음
- 기능 플래그 상태의 중앙 집중화된 관리가 이루어지지 않음
- Cells의 확장은 개발 및 운영 팀에 부담을 주게 됩니다.
제안
우리는 Feature Flags의 사용을 Cells로 확장하는 것에 대해 반드시 느리게 진행할 것입니다. 현재 .com 인프라가 주요 지점이며 대부분의 Feature Flags가 테스트를 위해 활용될 수 있기 때문에 고객을 Cells로 이주시키는 것이 미래의 목표이므로 우리는 Feature Flags와 상호작용하는 방법을 확장하길 원할 것입니다. 그러나 .com의 안전성과 안정성을 보장할 수 있는 능력과 절차를 개발해야 할 필요가 있습니다.
1.0 Cells 반복
Cells가 더 안정적인 GitLab 버전을 호스팅하려는 궁극적인 목표로, 피처 플래그에 대한 첫 반복 작업은 주로 수행해야 할 작업의 발견과 적절한 팀과의 우선순위를 매기는 것입니다. 이렇게 함으로써 우리는 또한 미래의 반복 작업에 대해 생각하는 시간을 가질 수 있으며 필요에 따라 정제할 수 있습니다.
여기서의 기대는 Primary Cell, 우리의 현재 인프라를 계속해서 사용하여 기본 Cell이 지속적으로 이뤄지는 작업을 계속해서 수행하는 것과 관련된 개발팀으로부터의 예상되는 변화 없이 여전히 운영을 할 것임을 의미합니다. 이미 진행 중인 개선 사항에 대한 모든 작업은 간섭을 방지하거나 불필요한 복잡성을 도입하지 않도록 고려되어야 합니다.
미래의 반복 작업
기능 추가
Cells에서의 참여
과거에 Feature Flags는 사건을 완화시키는 잠재력을 지니고 있습니다. 예를 들어, 특정 기능이 feature flag 뒤에 숨겨져 있고 활성화되어 있지만 코드가 원하는 대로 행동하지 않을 수 있습니다. 우리는 이를 이용하여 사건을 완화할 수 있습니다. 다른 예로는 기능이 격려하게 개발 중이거나, 해당 기능을 클러스터 전역으로 활성화하기 전에 추가 정보를 수집해야 할 수도 있습니다. 우리는 개발팀이 직접 셀과 상호작용할 수 있는 메커니즘을 제공할 수 있을 것입니다. 이를 위해 Chatops의 기능을 확장하여 셀의 개념을 이해할 수 있도록 하는 것과 공항해 지원하기 위한 UX를 제공해야 할 것입니다.
예를 들어, Cell 7에서 lorem_ipsum_dolar 피처 플래그를 변경하고자 한다면, 다음 명령어를 사용합니다.
/chatops run feature set lorem_ipsum_dolar false --cell 7
이 명령은 Cell 7로 접근하여 해당 기능 플래그를 비활성화합니다.
액터에 대한 참여
개발 보조를 위해 활용되는 Feature Flags는 특정 프로젝트, 사용자 또는 백분율 기반 액터를 대상으로 하는 경우가 있습니다. 이를 모든 셀에 대해 설정하는 것을 어렵게 만드는 문제점이 있습니다. 그렇기에 액터 기반의 Feature Flags 변경은 Primary Cell에서만 가능할 것입니다.
예를 들어, lorem_ipsum_dolar 피처 플래그를 @ayufan 액터를 대상으로 변경하고자 한다면, 다음 명령어를 사용합니다.
/chatops run feature set lorem_ipsum_dolar ayufan
이 명령은 해당 사용자를 Primary Cell에서만 변경합니다. 다른 모든 셀은 무시될 것입니다. 우리는 Chatops를 확장하여 특정 Cell에서 직접 설정을 할 수 있도록하는 것이 가능할 수도 있습니다. 이를 위해서는 엔지니어가 액터가 어느 셀에 속해 있는지를 알고 있어야 합니다. 이러한 제한 사항의 이유는 사용자와 프로젝트가 다양한 셀에 퍼져 있을 수 있기 때문입니다. 또한 Cells는 한 셀에서 데이터를 다른 셀로 이주할 수 있도록 설계되고 있습니다. Feature Flag 데이터는 셀의 설정으로 저장되며, 특정 액터에 대한 설정과 연계된 메타데이터는 액터의 지식과는 별개입니다. 따라서 우리가 어떤 액터를 대상으로 설정하고, 나중에 해당 액터가 옮겨지면 설정이 제대로 되지 않을 위험이 존재합니다. 이로 인해 특정 액터에 대한 다양한 행동이 나타날 수 있지만, 일반적으로 이러한 종류의 변경 사항은 GitLab의 내부 고객에게 발생하므로 사용자가 셀 간을 이동할 때 행동 변경에 유의할 가능성이 줄어듭니다. 또한 이 구현은 비교적 간단하여, 셀과 해당 액터가 존재하는 “어떠 서비스”를 쿼리하거나 한 결과 대상이 단일 셀 이상일 때 전문 롤아웃 절차를 개발할 필요가 없어집니다. 다음 섹션에서 논의될 것입니다.
환경에서의 참여
오늘날은 전체 환경에 대한 기능 플래그를 설정할 수 있는 능력을 갖추고 있습니다. 프로덕션 환경이 하나입니다. 이것으로 인해, 모든 셀에 기능 플래그를 전파하는 방법에 대해 고민할 필요가 있습니다. 이상적으로는 플래그가 충분히 테스트되어야 하지만, 모든 셀에 플래그를 전파하기 전에 동작을 검증하는 일종의 테스트가 여전히 필요할 수 있습니다.
예를 들어보겠습니다. lorem_ipsum_dolar 플래그를 프로덕션 전체에 활성화하려고 합니다. 다음 명령을 사용하여:
/chatops run feature set lorem_ipsum_dolar true --production
이 명령은 많은 작업을 수행해야 합니다. 먼저, 이 기능 플래그가 있는 모든 셀을 수집해야 합니다. 플래그가 어떤 셀에도 존재하지 않는 경우, 엔지니어의 기대치와 프로덕션 환경의 기대치 간에 불일치 문제가 발생하므로 이를 변경해서는 안 됩니다. 그러나 전체 배포가 완전히 완료되지 않은 배포 사고를 완화하기 위해 이를 활용하려는 경우, 이를 무시할 수 있는 오버라이드를 고려할 수 있습니다. 특정 환경의 모든 셀에 플래그가 존재한다면, 그 변경 사항을 모든 셀에 전파하기 시작합니다. 모든 셀을 동시에 변경하는 것은 비추천됩니다. Chatops는 이제 주어진 셀 목록에 변경을 수행하고, 신호를 기다린 후 다음 셀 목록으로 진행할 수 있는 메커니즘을 가져야 합니다. 완료될 때까지 반복합니다. 모든 셀에 걸쳐 사건을 완화할 가능성이 있는 플래그를 대상으로 하는 경우에는 이러한 고의적으로 구축된 천천히 전파하는 메커니즘을 우회할 필요가 있을 수 있습니다. 전달 팀은 셀에 대한 링 형식의 배포를 사용할 계획입니다. 우리는 이 사용 사례의 전파를 지원하는 데에 유사한 메타데이터를 활용할 수 있을 것입니다.
요구 사항
- Chatops는 필요한 정보를 수집하기 위해 어떤 서비스 와 대화할 수 있는 기능이 필요합니다. 이 정보에는 다음이 포함될 수 있습니다.
- 셀 목록
- 셀 목록에 할당된 작업자
- 새로운 셀이 온라인 상태가 되면, Chatops의 구성을 관리할 필요가 없습니다. 대신, Chatops는 새로운 셀에 자동으로 액세스할 수 있어야 합니다. 이렇게 함으로써, 새로운 셀이 생성될 때마다 관리 부담을 최소화합니다.
- 절차의 개선. 오늘날 우리는 이미 기존 노력을 통해 특징 플래그의 다양한 측면을 개선하기 위한 노력을 하고 있습니다. 우리는 계속 이러한 진행 중인 작업을 유념해야 합니다.