16.7.3.1 문자열 대조 검사(Regex Matching) 엔진의 스루풋 타격 진단과 한계선
Zenoh 생태계에서 엣지 단말이나 클라이언트가 네트워크에 붙으려 할 때, 가장 무식하고 확실한 보안 1선은 식별자/권한(ACL) 검열이다. “너는 factory/robot_1/* 토픽엔 글(Publish)을 쓸 수 있지만, factory/master/* 엔 쓰면 안 돼!” 와 같은 율법을 라우터가 실시간으로 통제해야 한다.
문제는 중앙 클라우드 라우터 데몬이 초당 100만 건(1M msgs/sec)씩 쏟아지는 분산 패킷들을 쳐내면서, 그 패킷 하나하나의 문패(Key Expression)를 뽑아 들고 허가증(Access Control List)에 맞는지 문자열 정규식(Regex) 대조 타격을 벌일 때 발생한다.
수많은 백엔드 초보자들은 ACL 룰셋을 정의할 때 아무 생각 없이 기괴한 와일드카드나 Regex 떡칠을 해둔다. 본 절에서는 편의성이라는 명목 하에 남용된 이 ‘정규표현식 검열’ 엔진이 라우터의 L7 스루풋 연산 코어를 어떻게 박살 내는지 한계선을 측정하고, 그 파멸의 궤적을 낱낱이 진단(Audit)해 본다.
1. 정규표현식(Regex)의 수학적 오만함과 NFA 의 역습
“어떤 텍스트든 매칭시켜주지!” 라는 거만한 마법의 수식인 정규표현식(Regular Expression)은 백엔드 개발자들의 마약이다.
// [클라우드 Zenoh 라우터에 걸린 치명적인 바보 룰셋]
access_control: {
rules: [
# "factory" 안의 어떤 하부 이름이든, 숫자가 몇 개든 중간에 "temp" 가 들어가면 읽기 허용!
{ id: "rule1", resource: "factory/.*/.*temp[0-9]+.*", action: "read" }
]
}
이 규칙을 들고 있는 Zenoh 라우터에 초당 10만 대의 센서가 factory/robot_234/temperature_sensor_99_a 따위의 토픽으로 패킷을 던진다고 치자.
라우터 스레드는 이 문자열과 저 .*temp[0-9]+.* 식을 대조하기 위해 내부적으로 구동되는 비결정적 유한 오토마타(NFA, Non-deterministic Finite Automaton) 엔진을 발화시킨다.
NFA 엔진은 글자 하나를 읽을 때마다 끝없는 백트래킹(Back-tracking)과 상태 분기를 거듭하며 메모리를 쓸고 다닌다. 만약 악의적인 노드가 뒤에 숫자가 달릴 듯 말 듯 한 기괴한 factory/robot/temp_a_temp_b_... 식의 문자열 타격을 가해오면(ReDoS Attack), 정규식 엔진의 CPU 연산량은 패킷 길이의 지수 단위(O(2^N))로 폭증하며 라우터 코어 자체를 용광로에 처넣고 질식시켜 버린다.
2. 권한 검사(ACL) 통과율에 따른 스루풋 폭락 지표
아키텍트는 단지 ACL 룰에 와일드카드(*, **)와 정규식 몇 개를 섞었을 뿐인데, Zenoh 가 자랑하는 30Gbps 제로카피 스루풋(Throughput)이 얼마나 허망하게 붕괴하는지 숫자로 직시해야 한다.
-
[Case A] 매칭 없는 노 검열 패스 (No ACL)
-
검사 생략. L4 이더넷 카드에서 들어오면 L7 라우터가 앞만 보고 그대로 패스 전송.
-
라우터 통과 속도: 초당 150만 (1.5M) msgs/sec
-
[Case B] 단순 기수 트리(Trie) 혹은 완전 일치 (Exact String Match)
-
factory/robot_1/temp와 정확히 같은지 1:1 비교.strcmp수준의 O(1) 메모리 참조. -
라우터 통과 속도: 초당 130만 (1.3M) msgs/sec (오버헤드 15% 이내)
-
[Case C] 2단 와일드카드 매치 (Prefix Matching)
-
factory/robot_1/**. 앞부분만 맞으면 뒷부분은 무시. -
라우터 통과 속도: 초당 90만 (0.9M) msgs/sec (오버헤드 40% 폭증)
-
[Case D] 정규식 파싱 지옥 (Regex Wildcarding & Backtracking)
-
factory/.*/temp[0-9]+ -
라우터 통과 속도: 초당 4만 (0.04M) msgs/sec (스루풋 1/37 로 대폭파 붕괴!)
3. 한계선(Threshold)의 천명과 검열 엔진의 구조 개혁 예고
스루풋 폭락치(1/37 토막)를 두 눈으로 확인했다면, 분산 메시지 망을 통치하는 자는 라우터 한가운데서 정규식을 파싱 하는 오만함을 철저히 숙청해야 한다.
초당 수백만 개의 패킷이 날아다니는 고속도로 톨게이트에서, 짐칸 안에 든 박스 숫자를 하나하나 정밀 세는 정규식 검사관(Regex)을 세워두는 것은 통신 인프라 자체를 스스로 봉쇄(Denial of Service)하는 짓이다.
동기식(Synchronous) 패킷 전송 루프 한가운데(Critical Path) 에 위치한 접근 제어 목록(ACL) 엔진은, 절대로 문자열 백트래킹 따위의 짓거리로 CPU 사이클을 1마이크로초 이상 잡아먹어서는 안 된다.
오직 O(1) 스텝만으로 패킷을 살릴지 죽일지 판단하고 즉결 처분하는 구조적 트리(Tree) 맵핑이나 완전 해싱(Hashing) 기법만이 이 레이턴시 지옥에서 라우터를 건져낼 수 있다. 정규식 편의성이 불러온 CPU 폭주 파멸을 끊어내고, 무결한 스루풋을 탈환하기 위한 극단적 룩업(Look-up) 전술(16.7.3.2장)로의 이행이 강제되는 분기점이다.