다중 변형 기능 플래그 규칙 이해 - AWS AppConfig
split 연산자 이해

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

다중 변형 기능 플래그 규칙 이해

기능 플래그 변형을 생성할 때 해당 변형에 대한 규칙을 지정해야 합니다. 규칙은 컨텍스트 값을 입력으로 받아 부울 결과를 출력으로 생성하는 표현식입니다. 예를 들어 베타 사용자(계정 ID로 식별됨)에 대한 플래그 변형을 선택하는 규칙을 정의하여 사용자 인터페이스 새로 고침을 테스트할 수 있습니다. 이 시나리오의 경우 다음을 수행합니다.

  1. UI 새로 고침이라는 새로운 기능 플래그 구성 프로필을 생성합니다.

  2. ui_refresh라는 새로운 기능 플래그를 생성합니다.

  3. 기능 플래그를 생성한 후 편집하여 변형을 추가합니다.

  4. BetaUsers라는 새 변형을 생성하고 활성화합니다.

  5. 요청 컨텍스트의 계정 ID가 새 베타 환경을 보도록 승인된 계정 ID 목록에 있는 경우 변형을 선택하는 BetaUsers에 대한 규칙을 정의합니다.

  6. 기본 변형의 상태가 비활성화로 설정되어 있는지 확인합니다.

참고

변형은 콘솔에 정의된 순서에 따라 정렬된 목록으로 평가됩니다. 목록 맨 위에 있는 변형이 먼저 평가됩니다. 제공된 컨텍스트와 일치하는 규칙이 없는 경우는 기본 변형을 AWS AppConfig 반환합니다.

가 기능 플래그 요청을 AWS AppConfig 처리할 때 AccountID(이 예제의 경우)를 포함하는 제공된 컨텍스트를 BetaUsers 변형과 먼저 비교합니다. 컨텍스트가 BetaUsers에 대한 규칙과 일치하는 경우는 베타 경험에 대한 구성 데이터를 AWS AppConfig 반환합니다. 컨텍스트에 계정 ID가 포함되지 않거나 계정 ID가 123 이외의 값으로 끝나는 경우는 기본 규칙에 대한 구성 데이터를 AWS AppConfig 반환합니다. 즉, 사용자가 프로덕션 환경에서 현재 경험을 봅니다.

참고

다중 변형 기능 플래그 검색에 대한 자세한 내용은 기본 및 다중 변형 기능 플래그 검색 페이지를 참조하세요.

split 연산자 이해

다음 섹션에서는 다양한 시나리오에서 사용 시 split 연산자의 동작 방식을 설명합니다. 참고로, split은 제공된 콘텍스트 값의 일관된 해시를 기준으로 지정된 비율만큼의 트래픽을 true로 평가합니다. 이를 더 잘 이해하기 위해 두 개의 변형으로 split 연산자를 사용하는 다음 기준 시나리오를 살펴봅니다.

A: (split by::$uniqueId pct::20)
C: <no rule>

예상대로, 임의의 uniqueId 값 집합을 넣으면 대략 다음과 같은 분포가 생성됩니다.

A: 20%
C: 80%

세 번째 변형을 추가하되 동일한 분할 비율을 사용하면 다음과 같습니다.



A: (split by::$uniqueId pct::20)
B: (split by::$uniqueId pct::20)
C: <default>

결과적으로 분포는 다음과 같습니다.

A: 20%
B: 0%
C: 80%

이렇게 잠재적으로 예상치 못한 분포가 나타나는 이유는, 각 변형 규칙이 순서대로 평가되고 첫 번째 매치가 어떤 변형을 반환할지 결정하기 때문입니다. 먼저 규칙 A를 평가하면 uniqueId 값의 20%가 일치하므로 첫 번째 변형이 반환됩니다. 다음으로 규칙 B가 평가됩니다. 그러나 두 번째 분할 명령문과 일치를 이루는 모든 uniqueId 값은 변형 규칙 A와 이미 일치했으므로 B에는 아무 값도 일치하지 않습니다. 대신 남은 기본 변형이 반환됩니다.

이제 세 번째 예를 살펴보겠습니다.

A: (split by::$uniqueId pct::20)
B: (split by::$uniqueId pct::25)
C: <default>

앞의 예시와 마찬가지로 uniqueId 값의 처음 20%는 규칙 A와 일치합니다. 변형 규칙 B의 경우 모든 uniqueId 값의 25%가 일치하지만 이 중 대부분은 이미 규칙 A와 일치된 값입니다. 결과적으로 전체 값 중 5%만이 변형 B와 일치하게 되고, 나머지는 변형 C가 받게 됩니다. 결과 분포는 다음과 같습니다.

A: 20%
B: 5%
C: 75%
seed 속성 사용

seed 속성을 사용하면 split 연산자가 사용되는 위치에 관계없이 지정된 콘텍스트 값에 대해 트래픽이 일관되게 분할되도록 할 수 있습니다. seed를 지정하지 않으면 해시는 로컬에서 일관되게 동작하므로 해당 플래그에 대해서는 트래픽이 일관되게 분할됩니다. 그러나 동일한 컨텍스트 값을 수신하는 다른 플래그의 경우 트래픽이 다르게 분할될 수 있습니다. seed를 제공하면 각 고유 값은 기능 플래그, 구성 프로파일 및 AWS 계정계정 전반에 걸쳐 트래픽을 일관되게 분할할 수 있습니다.

일반적으로 고객은 동일한 콘텍스트 속성에서 트래픽을 분할할 때 하나의 플래그 안에서 모든 변형 간에 동일한 seed 값을 사용합니다. 그러나 상황에 따라 다른 seed 값을 사용하는 것이 더 합리적일 수 있습니다. 다음은 규칙 A와 B에서 서로 다른 seed를 사용하는 예제입니다.

A: (split by::$uniqueId pct::20 seed::"seed_one")
B: (split by::$uniqueId pct::25 seed::"seed_two")
C: <default>

앞에서와 마찬가지로, 일치하는 uniqueId 값의 20%가 규칙 A와 일치합니다. 따라서 값의 나머지 80%는 변형 규칙 B로 넘어와 테스트됩니다. 여기서 seed가 다르기 때문에 A와 일치하는 값과 B와 일치하는 값 간에는 상관관계가 없습니다. 그러나 일치 규칙 B의 25%로 분할할 수 있는 uniqueId 값은 원래의 80%에 불과하므로 결과는 75%가 아닙니다. 이는 다음 분포 결과로 나타납니다.

A: 20%
B: 20% (25% of what falls through from A, or 25% of 80%) 
C: 60%