실시간 Skew를 자동으로 감지해서 'Salting' 로직을 켰다 껐다 하는 지능형 파이프라인

실시간으로 스큐(Skew)를 감지하고 상황에 따라 살팅(Salting) 로직을 동적으로 적용하는 것은 구글이나 넷플릭스 같은 빅테크 기업들이 대규모 트래픽을 처리할 때 사용하는 고도의 기술입니다. 이를 구현하기 위해서는 '모니터링 - 판단 - 적용'이라는 세 가지 핵심 고리가 유기적으로 돌아가야 합니다.

---

🏗️ 지능형 스큐 대응 파이프라인의 전체 구조

이 시스템은 크게 세 부분으로 구성됩니다.

1. 지표 수집기 (Metrics Collector): 카프카 파티션별 랙(Lag)과 처리량을 실시간 수집.
2. 판단 엔진 (Decision Engine): 스큐 발생 여부를 판단하고 살팅 여부를 결정.
3. 동적 프로듀서 (Dynamic Producer): 결정에 따라 키(Key)에 소금을 칠지 말지 결정하여 전송.

---

🛠️ 1단계: 실시간 스큐 감지 (The Sensor)

먼저 "어디가 막혔나?"를 알아야 합니다.

• 수집 지표: 파티션별 Incoming Records Rate와 Consumer Lag을 비교합니다.
• 스큐 판단 로직: * (특정 파티션의 랙) > (전체 파티션 랙 평균 * 3)
• 위 조건이 1분 이상 지속될 경우, 해당 파티션에 할당된 특정 '키(Key)'에 부하가 쏠렸다고 판단합니다.

• 도구: Prometheus로 지표를 모으고, Alertmanager나 별도의 가벼운 파이썬 스크립트가 이 상태를 감시합니다.

---

🧠 2단계: 살팅 로직의 동적 제어 (The Brain)

판단 엔진이 "스큐 발생!"을 감지하면, 이를 프로듀서에게 알려줘야 합니다. 이때 가장 세련된 방법은 '외부 설정 저장소'를 이용하는 것입니다.

• Redis나 ZooKeeper 활용: * 판단 엔진이 Redis에 {"SAMSUNG_ELECTRONICS": "SALT_ON"}이라는 플래그를 꽂습니다.
• 살팅이 필요 없어지면(SALT_OFF) 다시 플래그를 내립니다.

• 제어 루프: 너무 자주 껐다 켰다 하면 오히려 시스템이 흔들리므로(Flapping), 최소 5~10분의 유지 시간을 두는 'Hysteresis' 전략을 적용합니다.

---

⚡ 3단계: 동적 프로듀서 구현 (The Actuator)

이제 프로듀서 코드가 똑똑해져야 합니다. 사용자의 주식 데이터를 보낼 때 다음과 같은 로직을 수행합니다.

def send_stock_data(stock_code, data):
    # 1. Redis에서 해당 종목의 살팅 활성화 여부 확인 (캐싱 권장)
    is_salt_required = redis.get(f"SALT_STATUS:{stock_code}")

    if is_salt_required == "ON":
        # 2. 키 뒤에 무작위 접미사(Salt)를 붙여 파티션 분산 유도
        random_salt = random.randint(0, 9)
        routing_key = f"{stock_code}_{random_salt}"
    else:
        # 3. 정상 상태일 때는 원래 키 사용 (순서 보장 우선)
        routing_key = stock_code

    producer.send(topic, key=routing_key, value=data)

---

🧩 4단계: 컨슈머의 재조립 (The Reassembler)

살팅된 데이터는 여러 파티션으로 흩어져 들어옵니다. 이를 다시 합쳐야 정합성이 맞겠죠?

• Window Aggregation: Spark Streaming이나 Flink에서 데이터를 읽을 때, split("_")[0] 로직을 써서 소금(Salt)을 제거한 원래의 종목코드로 다시 그룹핑(groupBy)하여 합계를 구합니다.
• 결과: 소금 덕분에 병목 없이 빠르게 처리된 데이터들이 다시 하나의 '삼성전자' 통계로 예쁘게 모이게 됩니다.

---

⚖️ 지능형 파이프라인의 '득'과 '실'

장점	단점 및 주의사항
장애 조기 방지: 특정 종목 폭주 시에도 전체 시스템은 평온함.	순서 보장 문제: 살팅된 동안에는 해당 종목의 메시지 순서가 뒤섞일 수 있음.
자원 효율성: 평소엔 적은 리소스로 운영하다 필요할 때만 분산 처리.	복잡도 증가: Redis 관리 및 컨슈머 재조립 로직이 추가됨.
비용 절감: 랙 폭발로 인한 긴급 인프라 증설 불필요.	지연 시간: Redis 조회 시 약간의 네트워크 오버헤드 발생.

---

💡 실전 팁: "언제 켜고 언제 끌까?"

• 살팅 On: 특정 파티션의 지연(Lag)이 임계치를 넘고, 유입되는 키의 집중도가 높을 때.
• 살팅 Off: 지연이 해소되고, 유입 트래픽이 평소 수준으로 돌아왔을 때.

조언: "순서가 절대적으로 중요한 데이터(예: 체결 순서)"라면 살팅보다는 컨슈머의 처리 스레드를 늘리는 방식을 먼저 고민하시고, "통계량(거래대금 합계 등)"이 중요하다면 동적 살팅이 최고의 보약입니다!

---

📊 요약: 지능형 파이프라인 구축 순서

1. 지표 시각화: 파티션별 랙을 Grafana에 띄운다.
2. 알람 설정: 스큐 발생 시 Webhook을 쏘도록 설정한다.
3. 상태 저장소: Redis에 종목별 살팅 플래그 테이블을 만든다.
4. 프로듀서 수정: Redis 플래그에 따라 키를 변환하는 로직을 넣는다.
5. 컨슈머 수정: 들어온 키에서 소금을 제거하고 다시 합치는 로직을 넣는다.

---