졸업논문 — 다차원 부하 불균형 탐지와 핫스팟 식별
분산 스토리지 시스템에서 어느 시점에, 어느 노드·포트가 과도한 부하를 받고 있는가를 정량적으로 판단하는 모듈을 설계하고 있어요. 발표 슬라이드용으로 정리한 노트입니다.
연구 배경
분산 스토리지의 규모와 업무 복잡도가 계속 늘어나면서, 시간대에 따라 또는 노드마다 부하가 심하게 치우치는 현상이 자주 나타나요. 예를 들어:
- 어떤 노드는 IOPS나 대역폭이 항상 높음
- 어떤 포트는 지연 시간이 비정상적으로 튀어오름
그런데 실제 운영에서는 이런 문제를 *“단일 지표 + 경험적 임계값”*으로만 보는 경우가 많아요. “이 노드의 IOPS가 XX 이상이면 문제다” 같은 식이라, 다음을 정량적으로 보기가 어려워요:
- 시스템 전체가 얼마나 건강한지
- 노드/포트 사이의 다차원적인 차이
- 어떤 객체가 진짜로 이동·조정이 필요한 병목인지
또 하나 중요한 점은 시간에 따라 패턴이 계속 바뀐다는 거예요. 어떤 이상은 잠깐 생기는 버스트이고, 어떤 것은 오랫동안 이어지는 구조적 문제라서, 시간 축에서 지속성을 같이 봐야 해요.
제가 맡은 역할
이 프로젝트에서 제가 맡은 역할은 세 가지로 정리돼요.
- 다차원 불균형 탐지 + 핫스팟 식별 모듈 — 시스템 / 노드 / 포트 / 볼륨을 아우르는 4단계 계층 분석을 설계하고 구현
- 정규화된 지수 정의 — 시계열 모니터링 데이터로 불균형 지수와 건강 지수를 정의해서, “지금 전체가 불균형인가, 주요 문제 지점이 어디인가”를 숫자로 답하기
- 마이그레이션 모듈의 입력 생성 — 탐지 결과를 엑셀로 정리해 팀원이 구현하는 마이그레이션/스케줄링 모듈의 입력으로 넘기기
인용 논문 — 핵심 아이디어
Scheduling Cloud Block Storage Proactively and Reactively (Omar 논문)
이 논문에서 가져온 아이디어는 세 가지예요.
1) Resonance-based allocator
같은 사용자에 속한 여러 볼륨의 트래픽 시퀀스를 가지고 피어슨 상관계수를 계산해요.
- 서로 양의 상관이 큰 볼륨들은 한 노드에 몰지 않고 최대한 분산
- 음의 상관이 큰 볼륨들은 한 노드에 같이 두어서 부하가 서로 보완되도록
→ *“시간 패턴까지 고려해서 볼륨을 묶어 본다”*는 발상을 가져왔고, 시간 구간별 hotspot / 지속성 분석에 응용할 계획이에요.
2) Score-based candidate selector
클러스터가 Low / Medium / High 부하 상태인지에 따라 어떤 지표를 우선적으로 볼지 결정하고, 읽기 지배적인 구간과 쓰기 지배적인 구간을 구분해서 서로 다른 스코어 함수를 써요.
→ 나중에 read-heavy / write-heavy hotspot을 따로 구분하고, 그에 맞는 볼륨만 옮기는 정책을 설계할 계획이에요.
3) Scheduling frequency adjuster
Tail latency(P99/P999)와 실제 스케줄링 횟수를 가지고 최적화 문제로 빈도 조절을 해요.
→ 얼마나 자주 재균형을 돌릴 것인가를 데이터 기반으로 학습하는 모듈에 활용할 예정이에요.
다차원 불균형 탐지 설계 (STEP 1~3)
STEP 1: 모니터링 행렬
- 시간은 5분 단위 슬롯으로 쪼개기
- 시스템 / 노드 / 포트 레벨로 계층화
- IOPS, throughput, latency, CPU, queue depth 등 여러 지표를 한꺼번에 수집
이걸 다차원 상태 벡터로 보고, 이후 알고리즘의 입력으로 사용해요.
STEP 2: 시스템 레벨 건강도
각 시스템 s, 시간 t에 대해 여러 지표를 z-score로 정규화한 뒤 지표별 가중합을 통해 **health_score(s,t)**를 만들어요.
health_score < 평균→ normal- 일정 임계값 이상 → busy
- 더 높으면 → hot
연속 구간 길이로 persistent vs transient도 구분해요. 이렇게 해서 시간 축에 따라 시스템이 어떻게 뜨거워지는지 타임라인을 만들었어요.
STEP 3: 노드/포트 레벨 균형 비교
같은 시스템 s, 같은 시간 t 안에서 여러 노드들의 throughput을 비교해서:
- 평균, 분산, 변이계수(CV) 계산
- 각 노드가 평균 대비 얼마나 위/아래인지
imbalance정의
여기에 read, write, latency, CPU까지 z-score로 넣어서 한 노드가 얼마나 과도한 일을 하는지 나타내는 stress_index를 만들고, 이를 기준으로 세 역할로 태깅:
| 역할 | 의미 |
|---|---|
| exporter | 부하를 내보내야 할 노드 |
| importer | 부하를 받을 수 있는 노드 |
| neutral | 둘 다 아님 |
포트 레벨에서도 비슷한 방식으로 read/write throughput 분포의 mean, std, CV, max/mean을 계산해서 분산도가 높은 시점을 port hotspot으로 정의해요.
수식 정리
시스템–시간–지표별 값 *x(s,t,k)*에 대해 평균 μ_k와 표준편차 σ_k를 구하고:
z(s,t,k) = (x(s,t,k) - μ_k) / σ_k
지표별 중요도 w_k를 곱해서:
health(s,t) = Σₖ wₖ · z(s,t,k)
이런 형태로 건강 지수를 정의해요.
노드 레벨에서는 throughput 기준 그룹 평균 μ(s,t,p), 표준편차 *σ(s,t,p)*로 CV와 MaxOverMean을 만들고, 각 노드별 read/write/latency/CPU의 양수 z-score만 모아서:
stress = z_read⁺ + z_write⁺ + z_latency⁺ + z_cpu⁺
이렇게 stress_index를 구성해요. 이 수식들이 Excel 결과의 모든 칼럼을 생성하는 원리예요.
현재 결과 — System / Node / Port / Volume / Ticket
System-level Health Score
8개 시스템에 대해 health_score 타임라인을 만들고, 각 시점마다 normal / busy / hot을 라벨링했어요. 같은 시점에 8개 시스템을 비교해서 cluster_rank, cluster_mean, cluster_cv 등을 구했습니다.
데이터 이슈: 성능 데이터는 8개 시스템 기준이지만, 앱 정보 테이블에는 25개가 있고 그 중 6개만 겹쳐요. 그래서 탐지 자체는 8개 모두에 대해 수행했고, 마이그레이션 후보는 교집합 6개에 대해서만 생성했어요.
Node-level Imbalance & Stress Index
node_roles 시트에는 각 노드의 imbalance, read/write/latency/cpu 정규화 값, stress_index, exporter/importer/neutral 역할, 그리고 hot_type(read-heavy, write-heavy, mixed 등)까지 담겨 있어요.
같은 시스템 안에서 누가 항상 과열되는 노드인지를 시간 축을 따라 바로 확인할 수 있어요.
Port-level Balance & Hotspot
read_throughput, write_throughput에 대해 각 시점의 mean, std, max, min, CV, max_over_mean을 계산하고, CV ≥ θ_cv 또는 max_over_mean ≥ θ_mm을 만족하면 그 시점을 port hotspot으로 태깅해요.
port_balance시트: 모든 시점의 분포 통계port_hotspots: 조건을 만족하는 시점만 필터링
Volume-level Stats
모든 볼륨 데이터를 합쳐서 시스템–볼륨별 평균 read/write throughput과 그 합인 avg_total_throughput을 계산. → volume_stats 시트.
Imbalance Ticket — 종합 뷰
이 모든 정보를 한 줄로 묶은 것이 imbalance_tickets 시트예요. 각 행은:
- 어느 시각에
- 어떤 시스템에서
- health가 얼마나 높았고
- exporter/importer 노드가 몇 개 있었는지
- 포트 hotspot이 있었는지
- 옮길만한 후보 볼륨 리스트가 무엇인지
를 한꺼번에 보여줘요. *“특정 시간이 문제였다”*고 하면 이 시트 한 줄만 보면 언제 / 어떤 시스템 / 어느 노드·포트가 부담을 지고 있었고 / 어떤 볼륨을 옮길 수 있는지가 한 번에 보이도록 설계했어요.
Read / Write 분리 — 핫스팟 성격에 따른 다른 전략
탐지 단계부터 Read/Write를 분리하면, 핫스팟의 성격에 따라 마이그레이션 전략을 다르게 짤 수 있어요.
Read 핫스팟이면
- 많이 읽히는 Volume/Object를 캐시가 여유로운 노드로 옮김
- Read-heavy 워크로드를 분산
Write 핫스팟이면
- Write-heavy Volume을 쓰기 성능 좋은 노드(SSD, 낮은 queue)로 이동
- 백그라운드 Flush/Compaction 정책 조정
→ 문제의 성격이 다르기 때문에 재균형 전략도 달라져야 해요.
현재 단계 요약
시스템–노드–포트–볼륨을 잇는 다차원 불균형 탐지 파이프라인을 완성했고, 그 모든 결과를 imbalance_outputs_v2.xlsx 하나에 정리했어요.
| 시트 | 내용 |
|---|---|
system_health | 시스템 레벨 건강도 타임라인 |
node_roles | 노드별 stress_index, exporter/importer 태깅 |
port_hotspots | 포트 레벨 핫스팟 |
volume_stats | 볼륨 통계 |
imbalance_tickets | 종합 뷰 |
즉, 어느 심각한 이벤트에 대해서든 *“언제, 어떤 시스템에서, 어떤 노드와 포트가 부담을 지고 있었고, 어떤 볼륨을 옮길 수 있는지”*를 하나의 뷰에서 볼 수 있는 수준까지는 구현된 상태예요.
다음 단계
탐지 모듈 위에 논문 아이디어를 얹어서 정책화·최적화 방향으로 확장할 계획이에요.
1. 임계값과 건강 점수의 데이터 기반 튜닝
현재 hot/busy 임계값, 포트 CV / max_over_mean 기준, health 가중치 등은 아직 휴리스틱에 가까워요. 과거 slow I/O 로그와 장애 데이터를 수집해서, 어떤 임계값 조합이 실제 SLO 위반을 잘 예측하는지를 학습하는 방식으로 조정할 계획이에요. Omar 논문에서 tail latency로 스케줄링 빈도를 업데이트하는 아이디어와 연결돼요.
2. 시간·클러스터 단위 분석
지금은 개별 시점 기준이지만, 앞으로는 **시간 창(rolling window)**과 하루/주기 패턴을 같이 보면서 일시적 버스트 vs 구조적 hotspot을 분리할 예정이에요. 또 8개 시스템 간 health 분포를 비교해서 cross-cluster rebalancing이 필요한 상황도 정의하려고 해요.
3. 마이그레이션을 최적화 문제로 정식화
현재 imbalance_tickets는 후보 볼륨 리스트를 만들어 주는 수준이에요. 다음 단계에서는 source–destination 쌍을 결정하는 최적화 모델을 세우고, 시뮬레이션으로 이 볼륨들을 이렇게 옮기면 health와 imbalance가 얼마나 개선되는지를 정량적으로 평가할 계획이에요.
마무리
최종적으로는 **“탐지 → 의사결정(마이그레이션) → 효과 평가”**까지 하나의 폐루프를 만드는 것이 제 연구의 전체 그림이에요.
현재까지는 다차원 불균형 탐지와 핫스팟 식별이 시스템–노드–포트–볼륨 레벨까지 구현된 상태이고, 앞으로는 논문에서 제안된 기법을 참고해서 임계값 튜닝, 시간/클러스터 레벨 분석, 마이그레이션 최적화 쪽으로 확장할 예정이에요.