- 작동 방식
- 기능 플래그 생성
- 기능 플래그 최대 수
- 기능 플래그 전략
- 코드 참조 검색
- 특정 환경에서 기능 플래그 비활성화
- 모든 환경에서 기능 플래그 비활성화
- 애플리케이션과 기능 플래그 통합
- 기능 플래그 관련 이슈
- 성능 요소
기능 플래그
기능 플래그를 사용하면 새로운 기능을 프로덕션 환경에 작은 배치로 배포할 수 있습니다. 사용자 하위 집합에 기능을 토글하여, 지속적인 전달을 달성하는 데 도움이 됩니다. 기능 플래그를 사용하면, 제어된 테스트를 수행하고 기능 전달을 고객 출시와 분리하여 리스크를 줄일 수 있습니다.
기능 플래그의 실제 동작을 확인하려면 기능 플래그로 위험 제거을 참조하십시오.
클릭하여 데모를 보려면 기능 플래그를 확인하십시오.
작동 방식
GitLab은 기능 플래그에 대한 Unleash-호환 API를 제공합니다.
GitLab에서 플래그를 활성화하거나 비활성화함으로써, 애플리케이션은 활성화하거나 비활성화할 기능을 결정할 수 있습니다.
GitLab에서 기능 플래그를 만들고 애플리케이션에서 이 API를 사용하여 기능 플래그 목록과 상태를 가져올 수 있습니다. 애플리케이션은 GitLab과의 통신을 구성해야 하므로, 호환되는 클라이언트 라이브러리를 사용하고 앱에 기능 플래그 통합을 개발자가 수행해야 합니다.
기능 플래그 생성
기능 플래그를 만들고 활성화하려면:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 배포 > 기능 플래그를 선택하십시오.
- 새 기능 플래그를 선택하십시오.
- 영문자로 시작하고 소문자, 숫자, 밑줄(
_
), 또는 대시(-
)만 포함하고 대시(-
) 또는 밑줄(_
)로 끝나지 않는 이름을 입력하십시오. - 선택 사항. 설명을 입력하십시오 (최대 255자).
- 각 전략에 유형 (기본값은 모든 사용자) 및 환경 (기본값은 모든 환경)를 포함하여 기능 플래그에 전략을 추가하십시오.
- 기능 플래그 만들기를 선택하십시오.
이러한 설정을 변경하려면 목록에서 모든 기능 플래그 옆에 있는 편집()을 선택하십시오.
기능 플래그 최대 수
Self-managed GitLab 인스턴스의 프로젝트 당 기능 플래그의 최대 수는 200입니다. GitLab SaaS의 경우, 최대 수는 티어에 따라 결정됩니다:
티어 | 프로젝트 당 기능 플래그 (SaaS) | 프로젝트 당 기능 플래그 (Self-managed) |
---|---|---|
무료 | 50 | 200 |
프리미엄 | 150 | 200 |
얼티메이트 | 200 | 200 |
기능 플래그 전략
기능 플래그 전략을 여러 환경에 걸쳐 적용할 수 있습니다.
GitLab 기능 플래그는 Unleash를 기반으로 합니다. Unleash에는 세분화된 기능 플래그 제어를 위한 전략가 있습니다. GitLab 기능 플래그는 여러 전략을 가질 수 있으며, 지원되는 전략은 다음과 같습니다:
기능 플래그를 만들 때 이러한 전략을 추가하거나, 만든 후에 배포 > 기능 플래그로 이동하여 기존 기능 플래그를 편집하여 추가할 수 있습니다.
모든 사용자
모든 사용자에게 기능을 활성화합니다. Standard (default
) Unleash 활성화 전략을 사용합니다.
비율 적용
페이지 뷰의 특정 비율에 대해 기능을 활성화합니다. 구성 가능한 일관성
(또한 stickiness 라고 함)으로 행동합니다. 이 일관성은 stickiness로도 알려져 있습니다. Gradual Rollout (flexibleRollout
) Unleash 활성화 전략를 사용합니다.
일관성은 다음을 기반으로 구성할 수 있습니다:
- 사용자 ID: 각 사용자 ID에는 세션 ID를 무시하고 일관한 동작이 있습니다.
- 세션 ID: 각 세션 ID에는 사용자 ID를 무시하고 일관한 동작이 있습니다.
- 랜덤: 일관한 동작이 보장되지 않습니다. 기능은 페이지 뷰의 선택한 비율에 대해 무작위로 활성화됩니다. 사용자 ID와 세션 ID가 무시됩니다.
-
가능한 ID: 사용자 상태를 기반으로 일관한 동작을 시도합니다.
- 사용자가 로그인한 경우, 사용자 ID에 기반하여 동작이 일관됩니다.
- 사용자가 익명인 경우, 세션 ID에 기반하여 동작이 일관됩니다.
- 사용자 ID나 세션 ID가 없는 경우, 기능은 페이지 뷰의 선택한 비율에 대해 무작위로 활성화됩니다.
예를 들어, 가능한 ID를 기반으로 15%의 값으로 설정하여 페이지 뷰의 15%에 대해 기능을 활성화할 수 있습니다. 인증된 사용자의 경우 사용자 ID를 기반으로, 익명 사용자의 경우 세션 ID를 기반으로, 제공되지 않은 경우에는 임의로 처리됩니다.
롤아웃 비율은 0%에서 100%까지 설정할 수 있습니다.
사용자 ID를 기반으로 한 일관성을 선택하면 사용자 비율 롤아웃과 같은 기능을 합니다.
경고: 랜덤을 선택하면 개별 사용자에 대해 일관되지 않은 애플리케이션 동작을 제공합니다.
사용자 비율
인증된 사용자의 비율에 따라 기능을 활성화합니다. Unleash 활성화 전략
gradualRolloutUserId
를 사용합니다.
예를 들어, 인증된 사용자의 15%에 대해 기능을 활성화하도록 값을 설정할 수 있습니다.
롤아웃 비율은 0%에서 100%까지 설정할 수 있습니다.
동일한 사용자에 대한 일관된 애플리케이션 동작이 보장되지만 익명 사용자에 대해서는 보장되지 않습니다.
사용자 ID에 기반한 비율 적용 롤아웃은 동일한 동작을 합니다. 사용자 비율 대신 사용자 비율 전략을 선택하면 Unleash 클라이언트에 기능이 활성화되도록 반드시 사용자 ID를 제공해야 합니다. Ruby 예시를 참조하십시오.
사용자 ID
대상 사용자 목록에 대한 기능을 활성화합니다. Unleash UserIDs(userWithId
) 활성화 전략를 사용하여 구현됩니다.
사용자 ID를 쉼표로 구분된 값의 목록으로 입력(예: user@example.com, user2@example.com
, 또는 username1,username2,username3
및 그 이상).
사용자 ID는 애플리케이션 사용자의 식별자입니다. GitLab 사용자일 필요는 없습니다.
경고: 대상 사용자에게 기능을 활성화하려면 Unleash 클라이언트에게 사용자 ID를 반드시 제공해야 합니다. 아래의 Ruby 예제를 참조하세요.
사용자 목록
기능 플래그 UI에서 만든 사용자 목록을 통해 기능을 활성화합니다. 또는 기능 플래그 사용자 목록 API를 사용할 수 있습니다.
사용자 ID 와 유사하게 Unleash UsersIDs(userWithId
) 활성화 전략를 사용합니다.
특정 사용자의 특정 기능을 비활성화할 수는 없지만 사용자 목록을 활성화함으로써 유사한 결과를 얻을 수 있습니다.
예:
- 전체 사용자 목록
= 사용자1A, 사용자1B, 사용자2A, 사용자2B, 사용자3A, 사용자3B, ...
- B 사용자 제외 전체 사용자 목록
= 사용자1A, 사용자2A, 사용자3A, ...
사용자 목록 만들기
사용자 목록을 만들려면:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 배포 > 기능 플래그를 선택합니다.
- 사용자 목록 보기를 선택합니다.
- 새 사용자 목록을 선택합니다.
- 목록에 이름을 입력합니다.
- 만들기를 선택합니다.
목록의 사용자 ID는 해당 목록 옆의 편집()을 선택하여 볼 수 있습니다. 목록을 보는 동안 편집()을 선택하여 이름을 바꿀 수 있습니다.
사용자를 사용자 목록에 추가
사용자를 사용자 목록에 추가하려면:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 배포 > 기능 플래그를 선택합니다.
- 사용자를 추가하려는 목록 옆의 편집()을 선택합니다.
- 사용자 추가를 선택합니다.
- 사용자 ID를 쉼표로 구분된 값의 목록으로 입력합니다. 예를 들어
user@example.com, user2@example.com
, 또는username1,username2,username3
등입니다. - 추가를 선택합니다.
사용자를 사용자 목록에서 제거
사용자를 사용자 목록에서 제거하려면:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 배포 > 기능 플래그를 선택합니다.
- 변경하려는 목록 옆에 있는 편집()을 선택합니다.
- 제거하려는 ID 옆의 제거()를 선택합니다.
코드 참조 검색
코드 정리 중에 코드에서 기능 플래그를 제거하려면 해당 프로젝트에서 참조를 찾으세요.
기능 플래그의 코드 참조를 검색하려면:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 배포 > 기능 플래그를 선택합니다.
- 제거하려는 기능 플래그를 편집합니다.
- 더 많은 작업()을 선택합니다.
- 코드 참조 검색을 선택합니다.
특정 환경에서 기능 플래그 비활성화
특정 환경에서 기능 플래그를 비활성화하려면:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 배포 > 기능 플래그를 선택합니다.
- 비활성화하려는 기능 플래그의 편집()을 선택합니다.
- 플래그를 비활성화하려면:
- 각 전략에 적용되는 환경 아래에서 환경을 삭제합니다.
- 변경 사항 저장을 선택합니다.
모든 환경에서 기능 플래그 비활성화
모든 환경에서 기능 플래그를 비활성화하려면:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 배포 > 기능 플래그를 선택합니다.
- 비활성화하려는 기능 플래그의 상태 토글을 비활성화됨으로 슬라이드합니다.
기능 플래그는 비활성화됨 탭에 표시됩니다.
애플리케이션과 기능 플래그 통합
기능 플래그를 애플리케이션과 통합하려면 GitLab에서 액세스 자격 증명을 가져옵니다. 그런 다음 클라이언트 라이브러리로 애플리케이션을 준비합니다.
액세스 자격 증명 가져오기
GitLab과 통신하는 데 애플리케이션이 필요로 하는 액세스 자격 증명을 가져오려면:
- 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
- 배포 > 기능 플래그를 선택합니다.
-
구성을 선택하여 다음을 볼 수 있습니다:
- API URL: 클라이언트(애플리케이션)가 기능 플래그 목록을 가져오기 위해 연결하는 URL
- 인스턴스 ID: 기능 플래그의 검색을 인증하는 고유 토큰
-
애플리케이션 이름: 애플리케이션이 실행되는 환경의 이름 (애플리케이션 자체의 이름이 아닙니다).
예를 들어, 애플리케이션이 프로덕션 서버에서 실행되는 경우 애플리케이션 이름은
production
또는 유사한 이름이 될 수 있습니다. 이 값은 환경 스펙(specific) 평가에 사용됩니다.
이러한 필드의 의미는 시간이 지남에 따라 바뀔 수 있습니다. 예를 들어, 인스턴스 ID가 단일 토큰인지 아니면 환경에 할당된 여러 토큰인지 확실하지 않습니다. 또한 애플리케이션 이름은 실행 환경이 아닌 애플리케이션 버전을 설명할 수 있습니다.
클라이언트 라이브러리 선택
GitLab은 Unleash 클라이언트와 호환되는 단일 백엔드를 구현합니다.
Unleash 클라이언트로, 개발자는 응용 프로그램 코드에서 플래그의 기본값을 정의할 수 있습니다. 각 기능 플래그 평가는 제공된 구성 파일에서 플래그가 없는 경우 원하는 결과를 표현할 수 있습니다.
Unleash는 현재 다양한 언어 및 프레임워크에 대한 다양한 SDK를 제공합니다.
기능 플래그 API 정보
API 콘텐츠는 다음을 참조하세요: - 기능 플래그 API - 기능 플래그 사용자 목록 API
Go 어플리케이션 예시
아래는 Go 어플리케이션에 기능 플래그를 통합하는 방법의 예시입니다:
package main
import (
"io"
"log"
"net/http"
"github.com/Unleash/unleash-client-go/v3"
)
type metricsInterface struct {
}
func init() {
unleash.Initialize(
unleash.WithUrl("https://gitlab.com/api/v4/feature_flags/unleash/42"),
unleash.WithInstanceId("29QmjsW6KngPR5JNPMWx"),
unleash.WithAppName("production"), // 어플리케이션의 실행 환경에 설정
unleash.WithListener(&metricsInterface{}),
)
}
func helloServer(w http.ResponseWriter, req *http.Request) {
if unleash.IsEnabled("my_feature_name") {
io.WriteString(w, "Feature enabled\n")
} else {
io.WriteString(w, "hello, world!\n")
}
}
func main() {
http.HandleFunc("/", helloServer)
log.Fatal(http.ListenAndServe(":8080", nil))
}
루비 어플리케이션 예시
루비 어플리케이션에 기능 플래그를 통합하는 방법의 예시입니다.
Unleash 클라이언트는 퍼센트 롤아웃(로그인한 사용자) 롤아웃 전략이나 타겟 사용자 목록에 사용할 사용자 ID가 제공됩니다.
#!/usr/bin/env ruby
require 'unleash'
require 'unleash/context'
unleash = Unleash::Client.new({
url: 'http://gitlab.com/api/v4/feature_flags/unleash/42',
app_name: 'production', // 어플리케이션의 실행 환경에 설정
instance_id: '29QmjsW6KngPR5JNPMWx'
})
unleash_context = Unleash::Context.new
// 인증된 사용자의 ID로 "123"을 대체합니다.
// 컨텍스트의 사용자 ID는 문자열이어야 합니다:
// https://unleash.github.io/docs/unleash_context
unleash_context.user_id = "123"
if unleash.is_enabled?("my_feature_name", unleash_context)
puts "Feature enabled"
else
puts "hello, world!"
end
Unleash Proxy 예시
Unleash Proxy 버전 0.2부터 프록시는 기능 플래그와 호환됩니다.
GitLab.com에서 프로덕션에 Unleash Proxy를 사용해야 합니다. 자세한 내용은 성능 참고사항을 확인하세요.
프로젝트의 기능 플래그에 연결하려면 Docker 컨테이너를 실행하여 다음 명령어를 실행하세요.
docker run \
-e UNLEASH_PROXY_SECRETS=<secret> \
-e UNLEASH_URL=<project feature flags URL> \
-e UNLEASH_INSTANCE_ID=<project feature flags instance ID> \
-e UNLEASH_APP_NAME=<project environment> \
-e UNLEASH_API_TOKEN=<tokenNotUsed> \
-p 3000:3000 \
unleashorg/unleash-proxy
변수 | 값 |
---|---|
UNLEASH_PROXY_SECRETS
| Unleash Proxy 클라이언트를 구성하는 데 사용되는 공유 비밀. |
UNLEASH_URL
| 프로젝트의 API URL. 자세한 내용은 액세스 자격 증명 가져오기를 읽으세요. |
UNLEASH_INSTANCE_ID
| 프로젝트의 인스턴스 ID. 자세한 내용은 액세스 자격 증명 가져오기를 읽으세요. |
UNLEASH_APP_NAME
| 어플리케이션이 실행되는 환경의 이름. 자세한 내용은 액세스 자격 증명 가져오기를 읽으세요. |
UNLEASH_API_TOKEN
| Unleash Proxy를 시작하는 데 필요하지만 GitLab에 연결하는 데 사용되지 않습니다. 아무 값을 설정할 수 있습니다. |
또한, Unleash Proxy를 사용할 때 제한이 있으며, 각 프록시 인스턴스는 UNLEASH_APP_NAME
에 명명된 환경에 대해서만 플래그를 요청할 수 있습니다. 프록시는 클라이언트를 대신하여 GitLab에 이를 전달하기 때문에 클라이언트는 이를 재정의할 수 없습니다.
기능 플래그 관련 이슈
관련된 이슈를 기능 플래그에 연결할 수 있습니다. 기능 플래그의 연결된 이슈 섹션에서
+
버튼을 선택하고 이슈 참조 번호 또는 전체 이슈 URL을 입력하세요.
이러한 이슈들은 관련 기능 플래그와 역방향으로 표시됩니다.
이 기능은 연결된 이슈 기능과 유사합니다.
성능 요소
GitLab 기능 플래그는 모든 어플리케이션에서 사용할 수 있습니다. 대규모 어플리케이션의 경우 고급 구성이 필요할 수 있습니다. 본 섹션은 조직이 기능을 사용하기 전에 필요한 조치를 식별하는 데 도움이 되는 성능 요소에 대해 설명합니다. 자세한 내용은 세부 정보에 진입하기 전에 작동 방식 섹션을 읽으세요.
어플리케이션 노드에서 지원되는 클라이언트의 최대 수
GitLab은 비인증된 트래픽(특정 IP 주소에서의)으로 여러 클라이언트 요청을 받아들입니다. GitLab.com의 경우 GitLab.com 구체적인 제한 사항을 확인하세요.
폴링 속도는 SDK에서 구성 가능합니다. 모든 클라이언트가 동일한 IP에서 요청하는 경우:
- 분당 한 번 요청 … 500개 클라이언트를 지원할 수 있습니다.
- 15초마다 한 번 요청 … 125개 클라이언트를 지원할 수 있습니다.
더 확장 가능한 솔루션을 원하는 어플리케이션의 경우 Unleash Proxy를 사용해야 합니다.
GitLab.com에 경우, Unleash Proxy를 사용하여 엔드포인트 전체에 대한 속도 제한을 줄일 수 있습니다.
본 프록시 서버는 서버와 클라이언트 그룹 간에 요청을 생성하므로 외부 요청의 수를 크게 줄일 수 있습니다. 여전히 429
응답을 받는다면 Unleash Proxy에서 UNLEASH_FETCH_INTERVAL
값을 늘리세요.
현재 속도 제한에 더 많은 용량을 제공하기 위한 이슈도 존재합니다.
네트워크 오류 복구
일반적으로, Unleash 클라이언트는 서버가 오류 코드를 반환할 때 대체 메커니즘을 가지고 있습니다.
예를 들어, unleash-ruby-client
는 플래그 데이터를 로컬 백업에서 읽어 애플리케이션이 현재 상태에서 계속 실행될 수 있도록 합니다.
더 많은 정보를 보려면 SDK 프로젝트의 설명서를 참조하세요.
Self-Managed GitLab
기능 측면에서는 차이가 없습니다. SaaS와 Self-Managed는 동일하게 작동합니다.
확장성 측면에서는 GitLab 인스턴스의 사양에 달려 있습니다. 예를 들어, GitLab.com은 HA 아키텍처를 사용하여 많은 동시 요청을 처리할 수 있습니다. 그러나 성능을 비교할 수 없을 정도로 성능을 제공하지 못하는 저사양 머신에 설치된 Self-Managed 인스턴스도 있습니다. 더 많은 정보는 참조 아키텍처를 참조하세요.