빅데이터를 위한 은탄환으로서의 분산 컴퓨팅 신화
Source: Dev.to
Introduction
분산 기술이 빅데이터 처리의 만병통치약일까요?
오늘날 빅데이터를 처리하기 위해 분산 클러스터를 사용하는 것이 주류입니다. 큰 작업을 여러 하위 작업으로 나누어 여러 노드에 분산시키면 종종 큰 성능 향상을 얻을 수 있습니다. 따라서 처리 용량이 부족해지면 많은 사람들은 직관적으로 노드를 추가하는 방안을 떠올립니다. 이런 “분산 사고”는 우리 사고방식에 깊이 자리 잡게 되었습니다.
When Distributed Technology Works
Suitable Scenarios
작업을 쉽게 파티셔닝할 수 있을 때 분산 기술은 빛을 발합니다. 전형적인 예는 다음과 같습니다:
- Transactional (OLTP) workloads – 각 작업이 적은 양의 데이터를 처리하지만 동시성이 높습니다. 작업들은 자연스럽게 독립적이며, 성숙한 솔루션이 가끔 발생하는 분산 트랜잭션을 이미 처리합니다.
- Simple analytical queries – 예를 들어 단일 계좌의 상세 정보를 조회하는 경우(중국의 건강 QR‑코드 조회 등). 이러한 쿼리는 전체 데이터 양이 방대하지만, 각 요청은 아주 작은 독립적인 데이터 조각만을 건드립니다. 노드를 추가하면 쿼리 효율이 향상되어 이러한 경우에 분산 처리가 “마법”처럼 보입니다.
When Distributed Technology Falls Short
Complex Computations and Data Shuffles
노드 간에 광범위한 통신이 필요한 연산에서는 분산의 이점이 감소합니다. 전형적인 조인이나 연관 연산을 생각해 보세요:
- 데이터가 노드 간에 셔플되어야 합니다.
- 노드 수가 늘어날수록 셔플에 따른 네트워크 지연이 병렬 처리에서 얻는 이득을 능가할 수 있습니다.
- 많은 분산 데이터베이스가 노드 수에 상한을 두고 있습니다(보통 수십 개, 많아야 백 개 정도).
Non‑Linear Scaling
클러스터의 컴퓨팅 파워는 선형적으로 확장되지 않습니다:
- 노드들은 네트워크를 통해 통신합니다. 네트워크는 대량 전송에는 효율적이지만, 작은 조각의 무작위 메모리 접근에는 비효율적입니다.
- 노드 간 메모리 읽기는 로컬 메모리 접근보다 1~2 자릿수 정도 느릴 수 있습니다.
- 이를 보완하려면 하드웨어 자원을 여러 배 추가해야 하지만, 전체적인 속도 향상은 미미합니다.
Complex Batch Jobs
야간에 비즈니스 데이터를 변환하는 배치 작업은 종종 매우 복잡합니다:
- 여러 단계의 계산을 순차적으로 수행해야 합니다.
- 방대한 양의 히스토리 데이터를 반복적으로 읽고 연관시킵니다.
- 중간 결과가 생성되어 이후 단계에서 사용될 수 있도록 저장됩니다.
이러한 중간 결과는 사전에 분산시킬 수 없기 때문에, 다른 노드가 네트워크를 통해 이를 가져와야 하며, 이는 심각한 성능 저하를 초래합니다. 따라서 많은 조직이 여전히 이러한 워크로드를 단일 고성능 데이터베이스에서 실행하고 있습니다—비용이 많이 들고 작업량이 증가함에 따라 용량 한계에 빠르게 도달합니다.
Analyzing Bottlenecks
성능이 정체되고 분산 확장이 더 이상 도움이 되지 않을 때는 깊이 있는 분석이 필요합니다.
Data Size vs. Computation Complexity
대부분 “느린” 연산은 테라바이트 규모의 데이터를 다루는 것이 아닙니다. 전형적인 배치 작업은 다음과 같은 규모를 처리합니다:
- 실행당 수십에서 수백 기가바이트(예: 2천만 계좌, 3억 행, 약 300 GB 원시 데이터, 압축 시 < 100 GB).
이 정도 규모는 단일 머신에서도 충분히 처리할 수 있습니다.
실제 병목 현상의 주된 원인은 보통 다음 두 가지입니다:
- 높은 연산 복잡도 – 반복적인 연관 연산, 무거운 알고리즘 등.
- 빈번한 데이터 셔플 – 데이터 양이 작아도 알고리즘이 많은 노드 간 교환을 요구하면 병목이 됩니다.
Example: Astronomical Clustering
과학적 워크로드가 약 10 GB 정도의 데이터(11장의 사진, 각각 5 백만 개의 천체)만을 다루더라도, 공간 근접성을 기준으로 클러스터링을 해야 한다면 알고리즘 복잡도로 인해 분산 환경에서 성능이 크게 떨어집니다.
What to Do Instead?
- 워크로드 프로파일링 – 병목이 I/O, 네트워크 셔플, CPU 연산 중 어느 부분인지 파악합니다.
- 단일 노드 솔루션 고려 – 데이터 규모는 중간 정도이지만 알고리즘 복잡도가 높은 경우, 강력한 단일 머신(또는 소규모 병렬 환경)이 대규모 클러스터보다 뛰어난 성능을 보일 수 있습니다.
- 알고리즘 최적화 – 노드 간 데이터 교환을 최소화하고, 중간 결과를 배치 처리하거나, 보다 embarrassingly parallel하게 재설계합니다.
- 하이브리드 접근 – 원시 데이터는 분산 스토리지에 두고, 연산 집약적인 단계는 로컬에서 처리하는 방식을 결합합니다.
Conclusion
분산 기술은 강력한 도구이지만 모든 빅데이터 문제에 대한 만병통치약은 아닙니다. 그 효과는 작업을 깔끔하게 파티셔닝하고 노드 간 통신을 최소화할 수 있느냐에 달려 있습니다. 많은 복잡하고 연산 집약적인 배치 작업에서는 단일, 잘 튜닝된 머신—또는 하이브리드 아키텍처—가 무작정 클러스터를 확장하는 것보다 더 나은 성능과 비용 효율성을 제공합니다. 워크로드의 특성을 정확히 이해하는 것이 올바른 솔루션을 선택하는 핵심입니다.