분산 컴퓨팅, RAID의 한계를 넘어 분산 플랫폼의 시대로(대본)

- 분산 컴퓨팅 필요성(vs RAID)

 

- Hadoop MapReduce

 

- Apache Spark

 

- 도입 시 고려사항

 

- 대규모 데이터 처리가 필요한 분산 환경 속

  기존 RDBMS를 대체하는 NoSQL 기반 DB,

  인프라 직접 구축이 필요없는 Databricks, Anyscale 등 플랫폼 서비스(PaaS) 등장

 

 

0. 인사 및 목차 소개

 

안녕하세요. 오늘 세미나에서 현대 백엔드 아키텍처의 핵심 중 하나인 분산 컴퓨팅 시스템의 흐름에 대해 발표할 지디지 백엔드 파트멤버 김태우입니다.//

 

오늘 발표에서는 분산 컴퓨팅의 필요성과 개념부터 시작해,

디스크 기반 분산 컴퓨팅 프레임워크인 Apache Hadoop과 핵심 엔진인 MapReduce

가장 많이 쓰이는 인메모리 기반 분산 컴퓨팅 엔진인 Apache Spark,

그리고 이들을 도입할 때 고려할 사항과, 대규모 데이터 처리와 분산 환경 관리를 요구하는 시대의 흐름 속에서 등장한 서비스들까지 살펴보도록 하겠습니다.//

 

1. Intro: 분산 컴퓨팅의 필요성과 개념

 

분산 컴퓨팅이란, 여러 대의 컴퓨터를 네트워크로 연결하여, 마치 하나의 거대한 컴퓨터처럼 사용하는 기술을 말합니다.

컴퓨터 한 대의 성능을 높이는 것(Scale-up)은 한계가 있기에 컴퓨터를 옆으로 계속 이어 붙여(Scale-out) 병렬 처리를 통해 성능을 높이고,

컴퓨터 한 대가 고장 나면 전체가 멈추지 않고 다른 컴퓨터가 그 일을 대신 처리해 서비스가 중단되지 않고 계속 돌아갈 수 있도록 합니다.//

운영체제 시간에 저희는 RAID에 대해 배웠습니다. RAID는 단일 서버 내부에서 여러 개의 디스크를 묶어 시스템의 일부에 장애가 발생하더라도 전체 시스템이 멈추지 않고 기능을 계속 수행할 수 있는 내결함성을 확보하는 훌륭한 기술입니다. 하지만 백엔드 엔지니어로서 저희는 디스크 한 장이 고장나는 수준을 넘어서는 문제들을 마주합니다. 현대의 웹 서비스와 AI 워크로드는 매일 수십 테라바이트의 로그를 쏟아냅니다. 단일 서버의 CPU와 메모리로는 이 거대한 데이터를 처리하는 데 수년이 걸릴 수도 있습니다. 데이터가 페타바이트(PB) 단위로 폭증하면, 아무리 좋은 서버도 결국 물리적인 슬롯이나 연산 성능의 한계에 부딪힐 수 밖에 없습니다.//

결정적으로, RAID는 디스크 단위의 내결함성만 제공할 뿐, 서버 본체나 전원 장치 같은 '서버 단위 장애(Server Failure)'는 커버하지 못합니다. 물론 이중화 서버 구성을 할 수도 있지만, 데이터 규모 자체가 커지면 결국 '디스크 묶기'라는 로컬의 개념을 넘어, 네트워크로 수많은 컴퓨터를 연결해 하나의 시스템처럼 움직이게 하는 분산 컴퓨팅 수준의 설계가 요구됩니다.//

 

즉, 이제는 단순히 '안전하게 저장'하는 것을 넘어, 수천 대의 컴퓨터에 데이터를 흩뿌리고 '동시에 연산'하는 분산 환경이 필요하게 된 것입니다.//



2. Main #1: Disk-based Distributed System (Hadoop)

이러한 문제 해결을 위해 등장한 것이 Apache Hadoop입니다. Hadoop은 단일 서버에서 수천 대의 머신으로 확장 가능한 분산 처리를 지원하는 프레임워크로 HDFS라는 분산 파일 시스템과 MapReduce라는 분산 처리 엔진을 사용합니다.//

먼저 분산 저장을 통해 데이터 안정성을 확보하는 HDFS부터 살펴보겠습니다. 하둡은 데이터를 저장할 때 일정한 크기의 블록으로 쪼개고, 기본적으로 3개의 복제본을 만듭니다. RAID의 '중복 저장' 개념을 네트워크 수준으로 확장한 정교하게 설계된 복제 정책을 보여준다고 할 수 있겠습니다.

첫 번째 복제본은 네트워크 부하를 줄이기 위해 가급적 데이터를 생성하는 로컬 노드에 우선 배치합니다. 이어서 두 번째는 네트워크 지연이 적은 동일 랙 내의 다른 노드에, 마지막 세 번째는 랙 전체 장애에 대비해 물리적으로 분리된 다른 랙의 노드에 배치합니다.
이렇게 함으로써 서버 한 대는 물론, 랙 전체가 전원 장애로 다운되어도 데이터를 안전하게 지켜낼 수 있습니다.//



다음은 분산 데이터를 처리하는 엔진인 MapReduce에 대해 살펴보겠습니다. MapReduce 엔진의 핵심은 Data Locality(데이터 지역성)입니다. 과거에는 계산을 위해 데이터를 서버로 읽어왔지만, 하둡은 그렇지 않습니다. 거대한 데이터를 옮기는 대신 데이터가 저장된 그 컴퓨터에 아주 작은 실행 코드만 보내서 그 자리에서 계산하는 전략을 취합니다. 10TB의 데이터를 옮기는 것이 아니라 10KB의 코드를 보내 효율적으로 분산 데이터 처리를 수행해줍니다.


하지만 이 방식에도 치명적인 병목이 존재합니다. 바로 셔플링(Shuffling) 과정입니다. 각 서버에서 계산이 끝나면, 결국 최종 결과를 내기 위해 데이터를 서로 교환하고 합쳐야 합니다. 이때 중간 결과물을 매번 디스크에 썼다가 다시 네트워크로 전달하고 동기화하는 과정에서 막대한 I/O 비용이 발생합니다. 이 지점에서 하둡은 실시간 워크로드에서 한계를 보이게 되었습니다.//



3. Main #2: In-Memory Distributed Computing (Apache Spark)

MapReduce 엔진이 가진 시간 지연 문제를 극복하기 위해 등장한 것이 Apache Spark입니다. 스파크는 다중 노드 데이터 처리를 위한 통합 분석 엔진으로 메모리 중심의 혁신을 가져왔습니다.//

 

하둡이 중간 결과물을 매번 느린 하드디스크에 써야 했다면, 스파크는 모든 과정을 빠른 RAM, 즉 인메모리(In-Memory) 상에서 처리해 디스크 I/O를 획기적으로 줄일 수 있었습니다.//

스파크의 구조에 대해 살펴보겠습니다. 첫번째로 RDD(Resilient(탄력성 있는) Distributed Dataset)입니다. 데이터를 하드디스크가 아닌 메모리에 저장하되, 장애 발생 시에는 Lineage(계보)라 불리는 '데이터 생성 과정'을 이용해 재계산합니다. 다만, 계산 과정이 길어져 장기 작업이 된다면 이 Lineage 관리 비용을 줄이기 위해 중간 결과를 저장하는 Checkpoint 설정이 필요할 수 있습니다.

두 번째는 알고리즘 시간에 배운 DAG(Directed Acyclic Graph) 기반의 Lazy Evaluation입니다. 명령을 즉시 실행하지 않고 전체 실행 계획을 그래프 형태로 먼저 그린 뒤 최적의 경로를 찾습니다. 이러한 최적화 덕분에 스파크는 특정 반복 연산이나 메모리 중심 워크로드에서 하둡 대비 수십 배 이상의 압도적인 성능을 보여주며 현대 분산 처리의 표준으로 선택받게 되었습니다.//


4. Consideration: 도입 시 고려사항 및 최신 트렌드

그렇다면 우리는 어떤 기준으로 기술을 선택해야 할까요?

간단한 서비스라면 이러한 분산 환경을 고려할 필요가 없겠지만 대규모 데이터 처리와 장애 처리가 필요한 서비스라면 앞에서 소개한 Hadoop이나 Spark를 도입하는 것을 고려해볼 수 있겠습니다.
먼저 성능, 비용, 안정성의 Trade-off입니다. 스파크는 빠르지만 비싼 RAM 자원을 대량으로 소비합니다. 반면 하둡의 HDFS는 저렴한 하드디스크 기반으로 대규모 데이터를 장기 보관하는 데 여전히 유리합니다. 따라서 현재 다루고 있는 서비스의 특성, 가용 예산 등을 고려해 선택할 필요가 있습니다.//


분산 환경에서 자주 쓰이는 NoSQL과의 상호보완성도 고려해볼 수 있습니다. 전통적인 RDBMS는 분산 환경에서 CAP 정리(일관성, 가용성, 분할 내성을 모두 만족할 수는 없음)의 벽에 부딪힙니다. 수많은 노드 사이에서 강한 일관성을 유지하려다 가용성과 확장성을 잃게 됩니다. CassandraDB나 MongoDB에서 쓰이는 NoSQL은 엄격한 조인과 강한 일관성을 일부 포기하거나 조정하는 대신, 수평 확장성(Scale-out)과 가용성을 선택했습니다. 하지만 NoSQL이 특정 키를 통한 고속 조회에는 유리해도, 데이터 간의 복잡한 조인(Join)이나 전체 데이터를 훑어야 하는 전수 분석에는 구조적인 한계가 있습니다. 데이터를 여러 서버에 흩뿌려 놓았기 때문에 이들을 다시 모아 계산하는 작업은 NoSQL 입장에서 매우 비용이 드는 일이 됩니다.

따라서 현대적인 아키텍처에서는 '저장'과 '분석'을 철저히 분리합니다. 실시간으로 발생하는 방대한 데이터의 쓰기 작업은 확장성이 뛰어난 NoSQL이 받아내고, 그렇게 쌓인 로우(Raw) 데이터를 가져와 복잡하고 정교한 연산을 수행하는 분석의 영역은 Spark가 담당하게 됩니다. 이러한 효율적인 역할 분담을 통해 대규모 데이터를 분산 환경에서 효율적으로 저장하고 관리한다고 보시면 되겠습니다.//

 

또한 최근에 등장한 Saas, PaaS 형태의 소프트웨어, 플랫폼 서비스에 대해 알아볼 필요가 있습니다.

대표적인 분산 처리 플랫폼 서비스인 Databricks와 Anyscale은 모두 분산 엔진을 직접 운영하고 튜닝하는, 즉 분산 처리 인프라를 구축하는 부담을 줄이기 위해 등장했습니다.

 

앞에서 설명한 Apache Hadoop이나 Spark는 오픈소스 소프트웨어라서 누구나 코드를 내려받을 수 있지만, 결국 이 시스템을 운영하기 위해 온프레미스(On-premise) 즉, 직접 서버를 빌리고, 자바를 깔고, 네트워크를 설정하고, 클러스터를 구성해야 합니다.

 

 

Databricks는 Spark 엔진 기반 플랫폼으로 레이크하우스 아키텍처를 통해 분산 환경에서도 ACID 트랜잭션을 보장하며, 대규모 데이터 처리 및 분석에 강점을 보입니다.

반면 Anyscale은 Ray 엔진을 기반으로 하여, ML·AI 모델의 분산 학습과 실시간 서빙(Serving)에 초점을 맞춘 컴퓨팅 플랫폼입니다.

요약하면 Databricks는 대규모  데이터 엔지니어링에, Anyscale은 AI 워크로드에 특화된 분산 처리 플랫폼으로,

운영할 서비스의 특성에 따라 플랫폼을 선택해

직접 서버를 구축하고 관리할 필요 없이

비즈니스 로직에 집중할 수 있게 해준다고 보시면 되겠습니다.//

5. Recap: 결론 및 요약

지금까지 RAID의 로컬 내결함성에서 시작해 분산 컴퓨팅의 필요성, 디스크 기반 서비스인 Hadoop, 인메모리 기반의 Spark, NoSQL과의 연결고리, 마지막으로 현대 플랫폼 인프라 서비스로 이어지는 흐름을 살펴보았습니다.

분산 시스템은 결국 네트워크의 불확실성을 설계로 극복하는 과정입니다. 인프라를 직접 구축하던 시대를 지나 이제는 플랫폼을 통해 데이터를 어떻게 활용할지 고민하는 시대로 변화하고 있습니다. 우리가 만들 서비스의 요구사항에 맞는 최적의 기술적 선택지를 찾는 안목이 앞으로 더욱 중요해질 것 같다는 사견을 덧붙이며 발표 마무리 하도록 하겠습니다. 감사합니다.//