GitLab 개발 및 운영에서의 기능 플래그 사용

이 청사진은 Development Feature Flags Architecture blueprint을 기반으로 합니다.

요약

기능 플래그는 GitLab의 개발 및 운영 과정에서 중요하지만, 현재 상태에서는 프로덕션 문제를 유발하고 많은 수동 및 유지 관리 작업을 도입할 수 있습니다.

이 청사진의 목표는 이러한 프로세스를 보다 안전하고 유지 가능하며 가벼우며 자동화되며 투명하게 만드는 것입니다.

동기

기능 플래그 사용 사례

기능 플래그는 다양한 목적으로 사용될 수 있습니다:

• GitLab.com 배포의 위험 완화 (대부분의 기능 플래그): 프로덕션 사고 발생 시 빠르게 기능 플래그를 활성화/비활성화할 수 있습니다.
• 진행 중인 기능: 일부 기능은 복잡하고 여러 MR을 통해 구현되어야 합니다. 완전히 구현되기 전까지 누구에게도 표시되지 않아야 합니다. 그 경우 기능 플래그를 사용하여 모든 변경 사항을 본 브랜치에 병합할 수 있습니다.
• 베타 기능: 현재 형태로 모든 설계된 사용 사례에 대해 기능 확장, 지원 및 유지할 수 있는 자신감이 없을 수 있습니다 (예시). 또한 MVC로 고려하기에 충분히 완성되지 않은 상황도 있습니다. 이 경우 플래그를 제공하여 엔지니어 및 고객이 새로운 기능을 사용할 때까지 비활성화할 수 있습니다.
• 운영: 사이트 안정성 엔지니어 또는 지원 엔지니어는 이러한 플래그를 사용하여 자원 집약적인 기능을 비활성화하여 인스턴스를 안정적이고 이용 가능한 상태로 되돌릴 수 있습니다. 다른 예는 SaaS 전용 기능입니다.
• 실험: GitLab.com에서 A/B 테스팅.
• Worker (특별한 ops 기능 플래그): Sidekiq 워커 동작을 제어하는 데 사용되며, Sidekiq 작업을 지연시키는 등의 작업을 수행합니다.

우리는 기능 플래그를 더 잘 분류해야 합니다.

기능 플래그와 관련된 프로덕션 사고

기능 플래그는 GitLab.com에서 프로덕션 사고를 유발했습니다 (1, 2, 3).

GitLab.com의 안정성을 위해 이를 방지해야 합니다.

기능 플래그로 인한 기술 부채

기능 플래그는 점점 더 많은 기술 부채의 원인이 되고 있습니다: 현재 GitLab 코드베이스에는 591개의 기능 플래그가 있습니다.

GitLab 코드베이스의 장기적인 유지 가능성과 품질을 위해 기능 플래그 수를 줄여야 합니다.

목표

이 청사진의 목표는 다음과 같은 기능 플래그 프로세스를 개선하는 것입니다:

• 더 안전하게
• 더 유지 가능하게
• 더 가벼우며 자동화하여
• 더 투명하게

도전 과제

복잡한 기능 플래그 롤아웃 프로세스

기능 플래그 롤아웃 프로세스는 현재:

• 복잡합니다: 롤아웃 문제가 매우 수동적이고 많은 체크박스를 포함합니다 (관련 없는 체크박스 포함). 엔지니어들은 이러한 문제를 자주 사용하지 않으며 시간이 지남에 따라 방치되고 잊혀지는 경향이 있습니다.
• 매우 투명하지 않습니다: 기능 플래그 변경 사항이 롤아웃 문제와는 거리가 먼 여러 곳에 기록되어 최신 기능 플래그 상태를 이해하기 어렵게 만듭니다.
• 프로덕션 프로세스에서 거리가 있습니다: 롤아웃 문제는 gitlab-org/gitlab 프로젝트에 만들어집니다 (프로덕션 이슈 트래커에서 멀리 떨어짐).
• 기능 플래그 롤아웃을 위한 일관된 경로가 없습니다: 엔지니어가 속도와 안전 사이의 절충을 하는 것에 대한 표준화된 롤아웃 단계가 있어야 합니다.

기술적 부채와 코드베이스 복잡성

Development Feature Flags Architecture blueprint에서 제기된 도전 과제와 더불어 새로운 도전 과제가 있습니다:

• 기능 플래그가 기본적으로 활성화되고 온프레미스 설치에서 비활성화되면, 기능 플래그가 제거되면 기능이 갑자기 온프레미스 인스턴스에서 활성화되어 이전 동작으로 롤백할 수 없을 수 있습니다.

기능 플래그 기본 상태 및 가시성에 대한 다중 진실 출처

우리는 현재 여러 곳에서 기능 플래그의 기본 상태를 여러 목적의 대상을 위해 보여줍니다:

GitLab 고객

• 사용자 문서: GitLab 고객이 인스턴스에서 기능 플래그를 조정할 수 있도록 모든 기능 플래그 및 메타데이터를 나열합니다. GitLab.com 사용자가 기능 플래그의 기본 상태를 확인하려는 경우에도 유용합니다.

사이트 안정성 및 배달 엔지니어

• 내부 GitLab.com 기능 플래그 상태 변경 이슈: GitLab.com의 기능 플래그 상태를 변경할 때마다 이 프로젝트에 이슈가 생성됩니다.
• 내부 GitLab.com 기능 플래그 상태 변경 로그: source: feature 및 env: gprd로 로그 필터링하여 기능 플래그 상태 변경 로그를 확인합니다.

GitLab 엔지니어 및 인프라/품질 이사 / 부사장, CTO

• 내부 Sisense 대시보드: 시간 경과에 따른 기능 플래그 메트릭, DevOps 그룹별로 그룹화됩니다.

GitLab 엔지니어 및 제품 관리자

• “주의가 필요한 기능 플래그” 월간 보고서: 특정 DevOps 그룹을 위한 위의 내부 Sisense 대시보드와 동일한 데이터이지만 이슈로 제공되며 해당 그룹의 엔지니어 관리자에 할당됩니다.

기능 플래그 기본 상태를 확인하려는 누구든지

• 비공식 기능 플래그 대시보드: 유용한 필터링을 제공하는 사용자 친화적인 대시보드입니다.

이로 인해 거의 모든 기능 플래그 이해 관계자 (개발 엔지니어, 엔지니어 관리자, 사이트 안정성, 배달 엔지니어)에게 혼란을 야기시킵니다.

제안

기능 플래그 구현 및 사용 개선

• 구현 단계에서의 설정 오류 및 인적 실수 가능성 감소
  • “시간 대비 백분율” 전략 대신 “사용자 수 대비 백분율” 채택
• 기능 플래그 개발 문서 개선

새 기능 플래그 유형 도입

개발 기능 플래그 유형이 실제로 여러 사용 사례를 포함한다는 것은 명백하다:

• GitLab.com 배포 위험 감소. YAML 값: gitlab_com_derisk.
• 진행 중인 기능. YAML 값: wip. 기능이 완료되면 확장 가능성에 대한 의문이 있을 경우 플래그 유형을 beta로 변경할 수 있음.
• 베타 기능. YAML 값: beta.

참고:

• 이러한 새로운 유형은 더 이상 사용해서는 안 되는 폭넓은 개발 유형을 대체한다.
• 개발 기능 플래그가 더 이상 코드베이스에 없을 때까지 하위 호환성을 유지할 것이다.

각 기능 플래그 유형별 제약 조건 도입

각 기능 플래그 유형은 다음과 같은 특정 제약 조건이 할당될 것이다:

• default_enabled 속성에 허용된 값
• 최대 수명 (MLS): 기능 플래그가 도입된 시점(즉, master에 병합될 때)부터 시작하는 기간. 우리는 전역 GitLab.com 활성화(또는 적용 가능한 경우 default_enabled: true)에서 시작되는 수명을 도입하지 않으므로, 기능 플래그를 가능한 빨리 전파 및 삭제하도록 독려할 것이다.

MLS는 섹션 수준에서 자동화, 보고 및 정기적인 검토 회의를 통해 시행될 것이다.

다음은 각 기능 플래그 유형의 제약 조건이다:

• gitlab_com_derisk
  • default_enabled을 true로 설정하면 안 된다. 이러한 유형의 기능 플래그는 GitLab.com의 위험을 낮추기 위한 것이므로 GitLab.com에서 활성화된 후에는 더 이상 코드베이스에 플래그를 유지할 필요가 없다. 이러한 유형의 기능 플래그에서 default_enabled: true은 아무런 효과가 없을 것이다.
  • 최대 수명: 2개월.
  • 추가 참고: 이러한 유형의 기능 플래그는 짧은 수명 및 배포 관련이므로 GitLab의 모든 기능 플래그 페이지에 문서화되지 않을 것이다.
• wip
  • default_enabled을 true로 설정하면 안 된다. 필요한 경우 이 유형은 기능이 완료되면 beta로 변경될 수 있다.
  • 최대 수명: 4개월.
• beta
  • default_enabled를 true로 설정하여 특정 온프레미스 설치에서 문제가 발생하는 경우에만 비활성화할 수 있는 베타 롤아웃 기능을 “릴리스”할 수 있다.
  • 최대 수명: 6개월.
• ops
  • default_enabled를 true로 설정할 수 있다.
  • 최대 수명: 무제한.
  • 추가 참고: 이 유형을 사용할 때 인스턴스 설정을 도입하지 않기로 신중한 결정해야 한다.
• experiment
  • default_enabled를 true로 설정하면 안 된다.
  • 최대 수명: 6개월.

새로운 feature_issue_url 필드 도입

원래 기능 이슈에 대한 URL을 유지함으로써 롤아웃 및 로깅 이슈에서 자동으로 교차 링크 작업을 수행할 수 있게 될 것이다. 이 정보에 대한 새로운 필드는 feature_issue_url이다.

예를 들면:

---
name: auto_devops_banner_disabled
feature_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/12345
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/678910
rollout_issue_url: https://gitlab.com/gitlab-com/gl-infra/production/-/issues/9876
milestone: '16.5'
type: gitlab_com_derisk
group: group::pipeline execution

---
name: ai_mr_creation
feature_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/12345
introduced_by_url: https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14218
rollout_issue_url: https://gitlab.com/gitlab-com/gl-infra/production/-/issues/83652
milestone: '16.3'
type: beta
group: group::code review
default_enabled: true

기능 플래그 롤아웃 프로세스 스트림라인화

1. (프로세스) Production issue tracker에서 롤아웃 이슈 생성으로 전환하고 Change management issue template과 유사하게 템플릿을 조정한다. 그러면 롤아웃 이슈는 실제 프로덕션 변경 사항(즉, 프로덕션에서 플래그의 활성화/비활성화)에만 관련되며, 프로덕션 변경이 예상대로 작동하는 것으로 확인되면 가능한 빨리 닫힐 것이다.
2. (자동화) 대부분의 롤아웃 단계를 자동화한다:
   • (완료) 작성자에게 그들의 기능이 스테이징/카나리아/프로덕션 환경에 배포되었음을 알린다
   • (완료) 실제 기능 플래그 상태 변경(챗옵스 프로젝트에서)을 롤아웃 이슈에 교차 링크한다
   • (완료) 작성자에게 그들의 default_enabled: true MR이 프로덕션에 배포되었고, 기능 플래그가 프로덕션에서 제거될 수 있음을 알린다
   • 기능 플래그가 병합 요청에서 처음 도입될 때 롤아웃 이슈 생성을 자동화하고, rollout_issue_url 필드를 채우기 위한 차이 제안을 제공한다 (Danger)
   • 병합 요청에서 기능 플래그 정의 제한 조건을 확인하고 시행한다 (Danger)
   • MR 마일스톤과 동일하지 않은 경우 milestone 필드를 수정하기 위한 차이 제안을 제공한다 (Danger)
   • 기능 플래그 상태 변경 시, 해당 그룹에 대해 Slack으로 알린다 (챗옵스)
   • 기능 플래그의 최대 수명 7일 전에 자동으로 “정리 MR”을 생성하고 그룹 레이블을 설정하며, 기능 플래그 작성자에게 할당한다 (만약 그들이 GitLab에서 여전히 활동 중이라면). 개발자 작업의 반복적인 자동화를 활용할 수 있다.
   • 섹션 수준에서 자동 보고 및 정기적인 검토를 통해 기능 플래그의 최대 수명을 시행한다
3. (문서/프로세스) 기능 플래그 활성화 후 롤아웃 DRI가 약간의 시간 동안 온라인 상태를 유지하도록 보장한다 (이상적으로 그들은 그들의 날의 시작부터 플래그를 활성화할 것이다) 기능 플래그에 문제가 있을 경우를 대비하여.
4. (프로세스) 표준화된 일련의 롤아웃 단계를 제공한다. 고려해야 할 트레이드오프 사항:
   • 오류 발생 가능성
   • 영향을 받는 총 사용자(사용자/요청/프로젝트/그룹) 수, 예를 들어 1%로 롤아웃할 때 10만 명의 사용자가 로그인할 수 없는 경우에는 안 좋을 것이다.
   • 각 단계 사이에 대기해야 하는 시간. 일부 기능 플래그는 각 단계 당 10분을 대기해야 하고, 일부 기능 플래그는 24시간을 대기해야 한다. 이상적인 경우, 각 단계에서 부정적인 영향이 없는지를 활발히 확인하기 위한 자동화가 있어야 한다.

GitLab.com에서 기능 플래그 기본 상태 및 현재 상태 및 상태 변경에 대한 더 나은 SSOT 제공

GitLab 고객

• 사용자 문서: 현재 페이지를 유지하되, 비공식 기능 플래그 대시보드와 유사하게 필터링 및 정렬 기능을 추가합니다.

사이트 신뢰성 및 배송 엔지니어

우리는 기능 플래그 상태 변경 로깅 전략의 유용성을 평가했으며, 내부 GitLab.com 기능 플래그 상태 변경 문제 및 내부 GitLab.com 기능 플래그 상태 변경 로그이 다른 사용자들에게 유용한 것으로 나타났습니다.

GitLab 엔지니어 및 인프라/품질 책임자/부사장 및 CTO

• 내부 Sisense 대시보드: 현재 대시보드를 해당 이해 관계자에게 더 유용하게 만들기 위한 향상을 진행합니다.

GitLab 엔지니어 및 제품 매니저

• “주목이 필요한 기능 플래그” 월간 보고서: 현재 보고서를 행동 가능하게 만들어 기능 플래그 삭제를 위한 자동 생성된 MR과 함께 링크하고, 기능 플래그에 대한 문서 및 모베스트 프랙티스를 향상시킵니다.

반복

이 작업은 향상된 기능 플래그 내부 사용을 위한 전담 에픽의 일부로 진행됩니다: 기능 플래그 내부 사용 향상. 본 에픽은 이러한 변경을 위한 메타 이유를 설명합니다.

자원

• 기능 플래그란?
• 기능 플래그 모베스트 프랙티스
• 단기 또는 장기 사용 플래그? 기능 플래그 수명 주기 설명