Part 3: 분산 시스템의 도전과 해결 (1980s-2000s)
분산 시스템의 도전과 해결 (1980s-2000s)
Google’s Impossible Problem: MapReduce and the NoSQL Revolution
• 전통적 데이터베이스의 스케일 한계: 왜 Oracle, MySQL로는 구글 불가능했나
• CAP 이론: 일관성, 가용성, 분할 내성 중 2개만 선택 가능한 이유
• 구글의 삼위일체: GFS → BigTable → MapReduce 혁신 과정
• NoSQL 혁명: Cassandra, MongoDB가 만든 새로운 데이터베이스 생태계
I. 불가능한 규모: 전통적 데이터베이스의 한계 (1980s-2000s)
1.1 관계형 데이터베이스의 황금기와 한계
1980년대부터 2000년대 초까지, Oracle, IBM DB2, SQL Server는 기업 데이터베이스의 절대강자였습니다. 하지만 인터넷의 등장과 함께 이들이 해결할 수 없는 새로운 도전이 나타났습니다.
데이터베이스 확장성 위기의 진화
• 시스템: IBM DB2, Oracle, SQL Server
• 확장 방법: 수직 확장 (더 큰 서버)
• 최대 규모: ~1TB 데이터베이스, 수천 명 사용자
• 한계: 단일 장애점, 하드웨어 성능에 종속
• 시스템: Oracle RAC, IBM Parallel Sysplex
• 확장 방법: 공유 스토리지 기반 수평 확장
• 최대 규모: ~10TB 데이터베이스, 수만 명 사용자
• 한계: 비싼 공유 스토리지, 복잡한 클러스터링
• 시스템: Google, Yahoo!, Amazon
• 시도: 데이터베이스 샤딩, 캐싱 계층
• 요구사항: 페타바이트 데이터, 수억 명 사용자
• 결론: 전통적 접근법으로는 해결 불가능
1.2 구글의 불가능한 문제
2000년대 초 구글이 직면한 문제는 기존 데이터베이스 기술로는 해결할 수 없는 규모였습니다. 단순히 “큰” 것이 아니라 근본적으로 다른 차원의 도전이었습니다.
🔍 구글의 스케일 진화
문제: 크롤링에 수 주 소요, 인덱스 업데이트 매우 느림
문제: 기존 데이터베이스로는 처리 불가능
해결책: GFS + BigTable + MapReduce 자체 개발
전통적 시스템이 실패한 이유
• 전역 일관성 유지를 위한 분산 락
• 모든 노드 간 동기화 필요
• 하나의 노드 실패가 전체 시스템 중단
• 수십억 레코드 간 조인은 수 시간 소요
• 메모리 부족으로 디스크 스왑 발생
• 성능이 데이터 크기에 지수적 비례
• 고성능 서버 비용이 기하급수적 증가
• 단일 서버의 물리적 한계 존재
• 장애시 전체 시스템 다운
전통적 RDBMS 최대 규모
복잡한 쿼리 응답 시간
고성능 클러스터 비용
🤔 만약에… 구글이 Oracle을 사용했다면?
• 전 세계 웹 인덱싱에 수개월 소요
• 검색 결과 제공에 수 분 대기
• 수십억 달러의 고성능 서버 비용
• 현재와 같은 실시간 웹 검색 불가능
II. CAP 이론: 분산 시스템의 근본적 딜레마 (2000)
2.1 Eric Brewer의 혁명적 통찰
2000년 UC Berkeley의 Eric Brewer 교수가 제시한 CAP 이론은 분산 시스템 설계의 근본적 제약을 수학적으로 증명했습니다. 이는 “모든 것을 다 가질 수는 없다”는 엔지니어링의 기본 원리를 분산 시스템에 적용한 것입니다.
CAP 이론: 3개 중 최대 2개만 선택 가능
모든 노드가 동시에 같은 데이터를 보는 것
예: 은행 계좌 잔액은 모든 ATM에서 동일해야 함
노드가 실패해도 시스템이 계속 동작하는 것
예: 서버 몇 대가 다운되어도 서비스 지속
네트워크가 분리되어도 시스템이 작동하는 것
예: 데이터센터 간 연결이 끊어져도 각자 동작
“You cannot have all three of consistency, availability, and partition tolerance in a distributed system. You must choose at most two.”
Gilbert & Lynch (2002) 수학적 증명:
“In an asynchronous network where messages may be lost, it is impossible to implement a read/write data object that guarantees both availability and atomic consistency.”
2.2 CAP 트레이드오프와 실제 시스템들
CAP 선택에 따른 시스템 분류
• 시스템: Oracle, MySQL, PostgreSQL
• 특징: 강한 일관성, 높은 가용성
• 한계: 네트워크 분할 시 전체 중단
• 적용: 단일 데이터센터 환경에서만 가능
• 시스템: MongoDB, HBase, Redis Cluster
• 특징: 데이터 일관성 보장, 네트워크 분할 허용
• 한계: 분할 발생시 일부 노드 사용 불가
• 적용: 금융 거래, 재고 관리 등 정확성 중요
• 시스템: Cassandra, DynamoDB, CouchDB
• 특징: 항상 사용 가능, 네트워크 분할 허용
• 한계: 일시적으로 데이터가 다를 수 있음
• 적용: 소셜 미디어, 콘텐츠 배포 등 가용성 중요
🌍 실제 기업들의 CAP 선택
Amazon: 쇼핑카트에서 AP 선택 – “장바구니에 물건이 2번 들어가는 것은 괜찮지만, 장바구니가 사라지면 안 된다”
Google: 검색에서 AP 선택 – “검색 결과가 약간 오래되어도 괜찮지만, 검색이 안 되면 안 된다”
은행: 거래에서 CP 선택 – “시스템이 잠시 중단되어도 괜찮지만, 계좌 잔액이 틀리면 안 된다”
III. 구글의 삼위일체: GFS → BigTable → MapReduce (2003-2006)
3.1 혁신의 순서: 저장소부터 컴퓨팅까지
구글은 기존 시스템을 포기하고 완전히 새로운 분산 시스템을 설계했습니다. 중요한 것은 순서였습니다: 먼저 데이터를 저장하고, 그 위에 데이터베이스를 구축하고, 마지막에 처리 엔진을 만든 것입니다.
구글 분산 시스템 삼부작
논문: “The Google File System” – Ghemawat, Gobioff, Leung
해결 과제: 페타바이트 규모 파일 저장
혁신: 상용 하드웨어 장애를 전제한 분산 파일 시스템
논문: “MapReduce: Simplified Data Processing” – Dean & Ghemawat
해결 과제: 대용량 데이터의 병렬 처리
혁신: 함수형 프로그래밍에서 영감받은 분산 컴퓨팅 모델
논문: “Bigtable: A Distributed Storage System” – Chang et al.
해결 과제: 구조화된 데이터의 대규모 저장
혁신: GFS 위에 구축된 분산 데이터베이스
3.2 GFS: 장애를 전제한 파일 시스템
💾 GFS의 핵심 설계 원칙
장애 가정: 상용 하드웨어는 언제든 고장날 수 있다
대용량 파일 최적화: GB 단위 파일에 최적화 (64MB 청크)
단일 마스터: 메타데이터를 한 곳에서 관리
자동 복제: 모든 데이터를 3곳에 복사
일관성 완화: 성능을 위해 강한 일관성 포기
3.3 MapReduce: 프로그래머를 위한 분산 컴퓨팅
MapReduce의 천재성은 복잡한 분산 컴퓨팅을 두 개의 간단한 함수로 추상화한 것입니다. 프로그래머는 Map과 Reduce 함수만 작성하면, 시스템이 자동으로 수천 대의 서버에서 병렬 실행해줍니다.
MapReduce 작동 원리
• 큰 데이터를 작은 조각으로 나누기
• 각 조각을 여러 서버에서 병렬 처리
• 키-값 쌍으로 중간 결과 생성
• 예: 문서에서 단어 추출하고 개수 세기
• 같은 키를 가진 값들을 하나로 모으기
• 집계 함수를 적용하여 최종 결과 생성
• 여러 Reduce 작업을 병렬로 실행
• 예: 같은 단어의 출현 횟수 합계 계산
📊 실제 예시: 웹 페이지 단어 개수 세기
입력: 250억 개 웹페이지
Map: 각 페이지에서 단어 추출 → (“hello”, 1), (“world”, 1), (“hello”, 1)…
Shuffle: 같은 단어끼리 그룹화
Reduce: 같은 단어의 출현 횟수 합계
결과: 전체 웹에서 각 단어의 총 출현 횟수
3.4 BigTable: 스케일하는 데이터베이스
🗃️ BigTable의 혁신적 데이터 모델
데이터 모델: (행, 열패밀리, 타임스탬프) → 값
자동 샤딩: 데이터 크기에 따라 자동으로 분할
컬럼 패밀리: 관련된 컬럼들을 함께 저장
다중 버전: 같은 데이터의 여러 버전 보관
GFS 기반: 분산 파일 시스템 위에 구축
MapReduce 작업 동시 실행
GFS에 저장된 데이터
테라바이트 처리 시간
장애 복구와 확장
IV. NoSQL 혁명: 구글 논문이 만든 새로운 생태계 (2007-2015)
4.1 오픈소스 구현체들의 등장
구글이 논문을 공개하자, 전 세계 개발자들이 이를 오픈소스로 구현하기 시작했습니다. 각각 다른 문제를 해결하기 위해 서로 다른 CAP 선택을 한 NoSQL 데이터베이스들이 등장했습니다.
NoSQL 혁명의 주요 시스템들
• 영감: Amazon DynamoDB + BigTable 개념
• CAP 선택: AP (가용성 + 분할내성)
• 핵심 기능: 선형 확장성, 다중 데이터센터 복제
• 채택 기업: Netflix, Twitter, Instagram, Spotify
• 영감: 문서 저장 요구사항, JSON 유연성
• CAP 선택: CP (일관성 + 분할내성)
• 핵심 기능: 문서 지향, 풍부한 쿼리 언어
• 채택 기업: Foursquare, Disney, Adobe, eBay
• 영감: BigTable 논문의 직접 구현
• CAP 선택: CP (일관성 + 분할내성)
• 핵심 기능: 컬럼 패밀리, 강한 일관성
• 채택 기업: Facebook, Twitter, Yahoo!, Airbnb
4.2 각 시스템의 특화된 선택
NoSQL 시스템별 설계 철학
• 네트워크 분할이 발생해도 읽기/쓰기 계속
• 일시적으로 데이터가 다를 수 있음을 허용
• Netflix가 선택한 이유: 글로벌 서비스 중단 불가
• 네트워크 분할 시 일부 노드 사용 중단
• 모든 노드가 같은 데이터 보장
• 금융 서비스가 선택하는 이유: 데이터 정확성 필수
• 구글 방식의 컬럼 패밀리 데이터 모델
• Hadoop 생태계와의 완벽한 통합
• 대용량 분석이 필요한 기업들이 선택
4.3 Hadoop: MapReduce의 오픈소스 구현
더그 커팅(Doug Cutting)이 개발한 Hadoop은 구글의 MapReduce와 GFS를 오픈소스로 구현한 것입니다. 이로써 구글만의 특권이었던 대용량 데이터 처리가 모든 기업에게 가능해졌습니다.
🐘 Hadoop이 바꾼 것들
민주화: 대용량 데이터 처리가 모든 기업에게 가능
비용 절감: 상용 하드웨어로 페타바이트 처리
생태계: Spark, Kafka, Storm 등 관련 기술 발전
산업 변화: “빅데이터” 산업의 출현
V. 현대 웹 스케일: Netflix, Facebook의 분산 시스템 (2010-현재)
5.1 Netflix: 전 세계 스트리밍의 기술적 도전
Netflix는 전 세계 인터넷 트래픽의 15%를 담당하며, 2억 4천만 구독자에게 서비스를 제공합니다. 이는 구글이 2000년대 초 직면했던 것보다 훨씬 복잡한 분산 시스템 문제입니다.
📺 Netflix의 분산 시스템 아키텍처
Cassandra 선택 이유: 글로벌 다중 지역 서비스, 99.99% 가용성 필요
마이크로서비스: 700개 이상의 독립적 서비스
실시간 추천: 초당 수백만 개의 개인화 추천 생성
장애 허용: “카오스 엔지니어링”으로 장애 상황 시뮬레이션
5.2 Facebook/Meta: 30억 사용자의 소셜 네트워크
Facebook은 30억 명의 월간 활성 사용자를 처리하며, 초당 수백만 개의 메시지와 수십만 장의 사진을 처리합니다. 이를 위해 다양한 데이터베이스를 혼합 사용합니다.
현대 웹 스케일 비교
• 규모: 2억 4천만 구독자, 일일 10억+ API 호출
• 선택: 가용성 > 일관성 (시청 기록이 약간 지연되어도 OK)
• 결과: 99.99% 가용성, 글로벌 무중단 서비스
• 규모: 30억 사용자, 초당 400만 메시지
• 선택: 서비스별 다른 일관성 수준
• 결과: 메시징(CP), 타임라인(AP) 등 차별화
• 규모: 3억 고객, 초당 수천만 요청
• 선택: 장바구니(AP), 결제(CP) 등 적절한 선택
• 결과: 각 서비스에 최적화된 데이터베이스 사용
현대 분산 시스템 노드 수
NoSQL 쿼리 응답 시간
단일 클러스터 저장 용량
초당 처리 가능 연산 수
5.3 분산 시스템의 새로운 도전
🔮 현재와 미래의 도전 과제
엣지 컴퓨팅: 5G와 IoT로 인한 지연 시간 최적화
실시간 AI: 머신러닝 모델의 실시간 추론과 학습
프라이버시: GDPR, 데이터 주권과 분산 시스템의 조화
지속가능성: 에너지 효율적인 대규모 분산 시스템
복잡성 관리: 수천 개 마이크로서비스의 운영과 디버깅
🎯 핵심 통찰 (Key Insights)
⚖️ 완벽한 시스템은 없다
CAP 이론이 증명했듯이, 모든 것을 다 가질 수는 없습니다. 중요한 것은 자신의 요구사항에 맞는 올바른 트레이드오프를 선택하는 것입니다.
🔬 추상화의 힘
MapReduce처럼 복잡한 분산 컴퓨팅을 간단한 프로그래밍 모델로 추상화하면, 더 많은 사람들이 혁신에 참여할 수 있습니다.
🌍 오픈소스의 승리
구글의 논문 공개가 전 세계적인 NoSQL 혁명을 촉발했습니다. 지식 공유가 전체 산업의 발전을 가속화합니다.
📚 Primary Sources & Further Reading
구글 핵심 논문 (필독)
• Ghemawat, S., Gobioff, H., & Leung, S. T. (2003). “The Google file system.” ACM SOSP.
• Dean, J., & Ghemawat, S. (2004). “MapReduce: Simplified data processing on large clusters.” OSDI.
• Chang, F., et al. (2006). “Bigtable: A distributed storage system for structured data.” ACM TOCS.
• Brewer, E. A. (2000). “Towards robust distributed systems.” PODC keynote.
CAP 이론 관련
• Gilbert, S., & Lynch, N. (2002). “Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services.” ACM SIGACT News.
• Brewer, E. (2012). “CAP twelve years later: How the ‘rules’ have changed.” Computer, 45(2), 23-29.
NoSQL 시스템 문서
• Apache Cassandra Documentation and Design Papers
• MongoDB Architecture Guide
• HBase: The Definitive Guide – Lars George
• Designing Data-Intensive Applications – Martin Kleppmann
📖 다음 레슨 예고
Part 4: 오픈소스 운동과 리눅스 (1991-현재)
“리누스 토발즈가 바꾼 세상” – 취미로 시작한 프로젝트가 어떻게 전 세계 서버의 90%를 장악했는지, 오픈소스 협업 모델의 혁신을 탐구합니다.