트리거 규칙 설정
"트리거 규칙 설정"은 특정 URL 조건에 따라 대기실/차단실을 노출할 규칙을 설정할 수 있는 구성으로, 트래픽 제어가 활성화되어야 하는 시점에 대한 세밀한 제어를 제공합니다. 이 기능은 URL 트리거 통합(UTI)에서만 의미가 있습니다.
개요
URL 트리거 통합(UTI)에서는 웹사이트의 어디에 트래픽 제어를 적용할지 정의해야 합니다. 코드 기반 통합(CBI)이 nfStart() 및 nfStop() 함수를 사용하여 특정 코드 세그먼트를 래핑하는 반면, UTI는 URL 기반 규칙을 사용하여 어떤 페이지가 트래픽 제어를 트리거해야 하는지 결정합니다.
트리거 규칙은 근본적인 질문에 답하는 핵심 구성입니다: "어떤 요청이 트래픽 제어를 거쳐야 하는가?"
UTI는 페이지 요청에만 적용되며 API 호출에는 적용되지 않습니다. 사용자가 페이지로 이동할 때(링크 클릭 또는 URL 입력 등) UTI는 액세스를 제어할 수 있습니다. 그러나 AJAX 호출, API 요청 또는 기타 백그라운드 요청은 트리거 규칙의 영향을 받지 않습니다.
API 엔드포인트를 보호해야 하는 경우, 대신 nfStart() 및 nfStop() 함수를 사용하는 코드 기반 통합(CBI)을 사용하세요.
작동 방식
누군가 웹사이트를 방문하면 NetFUNNEL은 액세스하려는 URL을 검사하고 트리거 규칙과 비교합니다:
- URL이 규칙과 일치하는 경우: 방문자가 해당 페이지에 액세스하기 전에 대기실로 이동
- URL이 어떤 규칙과도 일치하지 않는 경우: 방문자가 페이지로 직접 이동
이를 통해 트래픽 제어로 보호해야 하는 페이지, 경로 또는 도메인을 정확히 정의하는 여러 규칙을 설정할 수 있습니다.
트리거 규칙 처리 흐름
트리거 규칙은 URL 트리거 통합(UTI)에서만 의미가 있습니다. 코드 기반 통합(CBI)을 사용하는 경우, nfStart() 및 nfStop() 함수를 사용하여 코드에서 직접 트래픽을 제어하므로 트리거 규칙이 필요하지 않습니다.
이렇게 생각해보세요: UTI를 사용하면 문(URL 수준)에서 트래픽을 제어하므로, 어떤 페이지에 대기가 필요한지 결정하는 규칙이 필요합니다. CBI를 사용하면 건물 내부(코드 수준)에서 트래픽을 제어하므로 보호해야 할 것을 이미 정확히 알고 있습니다.
규칙 구성 요소
트리거 규칙은 논리 연산자(AND/OR)를 사용하여 결합된 여러 조건으로 구성됩니다. 각 조건은 URL에서 찾을 내용을 지정하고, 논리 연산자는 이러한 조건이 함께 작동하는 방식을 결정합니다.
트리거 규칙 구조
트리거 규칙
└── 조건 1
├── Validator: URL
├── Component: Path | Domain | URL
├── Match Type: Equals | Contains | StartsWith | EndsWith | Exists
├── Value: 일치할 특정 텍스트
├── Negate: Does | Does not
└── 대소문자 구분: 체크됨 | 체크 안 됨
↓
[AND | OR] ← 논리 연산자
↓
조건 2 (동일한 구조)
↓
[AND | OR] ← 논리 연산자 (조건이 더 있는 경우)
↓
조건 N... (동일한 구조)
예시: AND 연산자를 사용하는 2개의 조건이 있는 트리거 규칙
- 조건 1: Path가
/checkout과 같음 - AND ← 논리 연산자
- 조건 2: Domain이
shop.example.com과 같음 - 결과:
shop.example.com의/checkout페이지만 트래픽 제어를 트리거
논리 연산자
여러 조건이 있을 때, 이것은 조건이 함께 작동하는 방식을 정의합니다:
- AND: "모든 조건이 참이어야 함" - 트래픽 제어가 적용되려면 모든 조건이 일치해야 함
- OR: "최소한 하나의 조건이 참이어야 함" - 어떤 조건이든 트래픽 제어를 트리거할 수 있음
Validator
검사할 요청 속성의 유형:
- URL: 현재 유일한 옵션 - 누군가 액세스하려는 웹 주소 검사
- 향후 옵션에는 Header, Cookie 및 기타 요청 속성이 포함될 수 있음
Component
검사할 URL의 부분:
| Component | 검사 내용 | 예시 |
|---|---|---|
| URL | 전체 웹 주소 | https://example.com/page?id=123 |
| Domain | 웹사이트 이름만 | example.com, www.example.com |
| Path | 특정 페이지 경로 | /page, /api/users |
Negate
규칙을 정상적으로 적용할지 역으로 적용할지:
- Does: "이것이 참일 때 트래픽 제어 적용" (정상)
- Does not: "이것이 거짓일 때 트래픽 제어 적용" (역) - "관리자 페이지를 제외한 모든 페이지에 트래픽 제어 적용"과 같음
Match Type
URL 구성 요소를 비교하는 방법:
| Match Type | 작동 방식 | 예시 |
|---|---|---|
| Exists | "이 부분이 존재하는가?" | 페이지에 경로가 있는가? |
| Equals | "이것이 정확히 동일한가?" | 경로가 정확히 /event여야 함 |
| Contains | "이것이 이 텍스트를 포함하는가?" | 도메인이 api를 포함 |
| StartsWith | "이것이 이것으로 시작하는가?" | 경로가 /mobile로 시작 |
| EndsWith | "이것이 이것으로 끝나는가?" | 경로가 .html로 끝남 |
Value
일치시킬 특정 텍스트. 이것은 URL에서 찾고 있는 것입니다.
대소문자 구분 (Aa)
대문자에 대해 신경 쓸지 여부:
- 체크 안 됨: "VIP"와 "vip"가 동일하게 처리됨
- 체크됨: "VIP"와 "vip"가 다르게 처리됨
구성 프로세스
트리거 규칙 설정은 레스토랑을 위한 특별한 메뉴 시스템을 만드는 것과 같습니다. 단계별로 살펴보겠습니다:
1단계: 트리거 규칙 설정 액세스
- NetFUNNEL에서 기본 제어 세그먼트로 이동
- "트리거 규칙 설정" 클릭
- 중요: UTI를 사용하고 있는지 확인 - 트리거 규칙은 URL 트리거 통합에서만 의미가 있음
2단계: 첫 번째 조건 생성
이것을 메뉴에 특별한 섹션을 추가하는 것으로 생각하세요:
- 검사할 항목 선택: Validator에서 "URL" 선택 (누군가 원하는 메뉴 섹션을 확인하는 것과 같음)
- 검사할 부분 선택: Component에서 Domain, Path 또는 URL 선택 (레스토랑 이름만 확인하는 것과 전체 메뉴 항목 확인의 차이)
- 엄격함 정도 결정: Match Type 선택 (Equals, Contains, StartsWith 등)
- 찾을 항목 기록: Value에 특정 값 입력 (특별 메뉴의 "VIP 라운지"와 같음)
- 정상 또는 역 선택: Negate에서 "Does" 또는 "Does not" 선택 (정상 조건 또는 예외 조건)
- 대문자에 대해 결정: 대소문자 구분에서 조건에 대해 대소문자 구분이 중요한지 확인
3단계: 규칙 테스트
라이브 전에 규칙을 테스트하여 예상대로 작동하는지 확인하세요:
- 콘솔에 테스트 URL 입력 (다른 메뉴 항목 테스트와 같음)
- 규칙이 올바르게 적용되는지 확인
- 필요시 설정 조정
4단계: 여러 조건 추가 (선택 사항)
더 복잡한 로직이 필요한 경우:
- 추가 조건 추가
- 결합하기 위해 AND/OR 선택 ("VIP 라운지 AND 특별 이벤트"와 같음)
- 결합된 동작 테스트
쿼리 문자열 필터링은 현재 트리거 규칙에서 지원되지 않습니다. URL 경로, 도메인 또는 전체 URL에 대해서만 일치시킬 수 있습니다.
쿼리 문자열에 대한 해결 방법: 특정 쿼리 매개변수가 있는 페이지를 보호해야 하는 경우, 브라우저에서 쿼리 문자열을 포함한 전체 URL을 복사하고 URL 정확 일치를 사용하세요.
이 제한 사항은 향후 업데이트에서 해결될 수 있습니다.
일반적인 사용 사례
가장 일반적인 시나리오와 일반적인 구성은 다음과 같습니다:
| 시나리오 | Component | Match Type | Value | 논리 연산자 | 예시 |
|---|---|---|---|---|---|
| 특정 페이지 보호 | Path | Equals | /checkout | - | 체크아웃 페이지만 보호 |
| 페이지 그룹 보호 | Path | StartsWith | /event | - | 모든 이벤트 페이지 보호 |
| 여러 페이지 | Path | Equals | /checkout, /flash-sale, /limited-edition | OR | 여러 특정 페이지 보호 |
| 도메인별 보호 | Domain | Equals | shop.example.com | - | shop 하위 도메인만 보호 |
| 결합된 조건 | Path + Domain | Equals | /checkout + shop.example.com | AND | shop 도메인의 체크아웃만 보호 |
| 전체 URL 보호 | URL | Equals | https://example.com/checkout?step=payment | - | 쿼리 문자열이 있는 특정 URL 보호 |
모범 사례
트리거 규칙을 설정할 때는 간단하게 시작하고 점진적으로 복잡성을 구축하는 것이 중요합니다. 많은 사용자가 한 번에 모든 것을 구성하려고 시도하는 실수를 하며, 이는 종종 혼란과 예상치 못한 동작으로 이어집니다.
간단하게 시작한 다음 확장
가장 좋은 접근 방식은 가장 중요한 페이지로 시작하고 점진적으로 더 많은 조건을 추가하는 것입니다. 예를 들어, 전자상거래 사이트는 /checkout 페이지만 보호하는 것으로 시작한 다음, 몇 주 동안 트래픽 패턴을 모니터링한 후 /flash-sale 및 /limited-edition 조건을 추가할 수 있습니다.
이 점진적 접근 방식은 복잡성을 추가하기 전에 트리거 규칙이 특정 트래픽 패턴과 어떻게 작동하는지 이해하는 데 도움이 됩니다.
테스트 전략
라이브 전에 항상 조건을 철저히 테스트하세요. 진입 허용 수를 0으로 설정하여 대기실이 올바르게 나타나는지 확인한 다음, 다른 대소문자, 매개변수 및 형식을 포함한 다양한 URL 변형으로 테스트하세요.
좋은 테스트 접근 방식에는 다음이 포함됩니다:
- 정확 일치 테스트:
https://example.com/event(트리거되어야 함) - 대소문자 변형 테스트:
https://example.com/EVENT(대소문자 구분이 없으면 트리거되어야 함) - 매개변수로 테스트:
https://example.com/event?id=123(트리거되어야 함) - 엣지 케이스 테스트:
https://example.com/events(같음으로는 트리거되지 않아야 함)
피해야 할 일반적인 실수
과도하게 광범위한 조건은 빈번한 문제입니다. "Path가 /로 시작"을 사용하면 사이트의 모든 것을 보호하게 되며, 이는 거의 원하는 것이 아닙니다. 대신 "Path가 /checkout으로 시작"과 같이 구체적으로 지정하여 필요한 영역만 보호하세요.
대소문자 구분 혼란은 또 다른 일반적인 문제입니다. 특정 요구 사항이 없는 한, 사용자가 사이트로 이동하는 방식에 따라 /Event와 /event에 액세스할 수 있으므로 대소문자 구분을 체크 안 됨 상태로 유지하세요.
매개변수 변형을 테스트하지 않음은 /product?id=123은 작동하지만 /product?category=electronics는 작동하지 않는 문제를 일으킬 수 있습니다. 항상 다른 매개변수 조합으로 URL을 테스트하여 조건이 예상대로 작동하는지 확인하세요.
전문가 팁
"규칙 1"과 같은 일반적인 이름 대신 조건에 대해 설명적인 이름을 사용하세요. "체크아웃 보호" 또는 "플래시 세일 보호"와 같은 이름은 관리가 훨씬 쉬워지며, 특히 여러 조건이 있을 때 유용합니다.
설정을 보수적으로 시작하고 점진적으로 증가시키세요. 제한을 증가시키는 것이 시스템 과부하를 처리하는 것보다 훨씬 쉽고, 이 접근 방식은 특정 트래픽 패턴에 대한 최적의 지점을 찾는 데 도움이 됩니다.
마지막으로, 조건이 활성화되어 있을 때 항상 서버 메트릭(CPU, 메모리, 응답 시간)을 모니터링하여 추가 문제를 일으키는 대신 실제로 시스템에 도움이 되는지 확인하세요.
고급 구성 옵션 및 통합 세부 사항은 기본 제어 세그먼트 개요 및 기본 설정 문서를 참조하세요.