분산저장시스템 개발에 대한 12 가지 이야기네이버 분산시스템문상철

소개• 문상철• 네이버 (from 2007)• 분산시스템 연구 & 개발

• 분산 파일 시스템• 분산 데이터 베이스

• Linux system & network programming

iceberg

출처 :http://kingofwallpapers.com/iceberg/

수면위로 얼마나 보이는 거지 ?• 전체 부피 중 유체 위에 노출되는 부피 비율

• = 1 - ( 물체의 밀도 / 유체의 밀도 )• = 1 - (0.92 / 1.03) = 0.1 = 10%

• 10% 의 예쁜 빙산이 바다 위에서 보이려면 90% 의 거대한 빙산이 수면 아래에 존재해야 함

빙산의 일각• 이름만 들어도 아는 유명 IT 기업들

• Google, Amazon, Apple…• Naver…

• 이들의 서비스가 만일 “일각”이라면 , 수면 아래에는 뭐가 있지 ?

분산시스템• 정의

• A distributed system is a collection of independent computers that appears to its users as a single coherent system.

분산시스템• 정의

• A distributed system is a collection of independent computers that appears to its users as a single coherent system.

플랫폼• 서비스마다 공통으로 필요로 하는 기반 기술

• 파일 , 구조화된 데이터 , 대용량 분석 , 이미지 처리 , 지도 , 머신러닝 , …• Software Framework + Hardware

Infrastructure• 훌륭한 서비스를 만들기 위해 잘 설계되고 견고한 부품

분산 저장 시스템• 분산 시스템• 데이터 저장

• 파일이나 구조화된 데이터• 플랫폼

12 가지 이야기를 시작하며• 간단한 서비스를 만들어봅시다 .

• 성능• 비용• 가용성

1. 네이버 회원 3,700 만명에게 30GB 의 드라이브를 제공하고 싶은데 어떻게 하면 될까 ?

간단한 계산• 3,700 만명 x 30GB = 1100 PB (1PB =

1000TB)• 1,000 만명 x 5GB = 50PB

• 1 TB disk 가 50,000 개• 1 대 서버에 10 개 disk 를 장착할 수 있다면 ?

• 총 5000 대의 서버가 필요1/12

메타 데이터

1 2 3 … 4999 5000

1/12

메타 데이터

1 2 3 … 4999 5000

sangchul 의 데이터는 어느 서버에 어느 디스크에 저장하지 ?

1/12

메타 데이터id server disk

sangchul 3 2yj 50 9

wendy 920 1kh 743 8… … …

1/12

시나리오

1 2 3 … 4999 5000

APIsangchul

server 3, disk 1

file write

1/12

Service

2. Peak 시간대에 사용자가 갑자기 몰리면 어떻하지 ?

메타 데이터 조회• 가입자의 10% 가 peak 시간대에 파일을 읽으려고 한다면 ?• 100 만명이 자신의 meta 정보를 조회• DB 1 대의 처리량 : 10,000 qps

• 100 만번째 유저는 100 초를 기다려야 함 ?

2/12

메타 데이터 Cache

• 사용자 id 와 server, disk 정보는 거의 변경되지 않음• 모두 메모리에 cache 해두면 훨씬 낫지 않을까 ?

2/12

메타 데이터 Cache

• user id, server id, disk id• 256 + 4 + 2 = 262 byte• 262 * 3700 만명 = 대략 10GB

2/12

메타 데이터 Cache

• cache 의 성능은 10 만 qps 라고 가정하면 10대의 cache 서버에 meta data 를 모두 저장하자• 100 만명이 동시 요청을 보내도 빠른 시간 내에 처리할 수 있음

2/12

시나리오

1 2 3 … 4999 5000

APIsangchul

server 3, disk 1

file write

C

C

…C

2/12

3. 데이터는 절대 잊어버리면 안 돼

사용 시간에 따른 디스크의 고장 확률고장 확률

디스크 사용 시간 3/12

디스크 고장• 디스크가 고장나서 데이터를 잃어버리면 큰일 !• 여러 개의 디스크에 데이터를 똑같이 저장해두자

3/12

복제• 사용자가 1 개 파일을 저장하면 N 개 디스크에 동시에 저장하자 .

• N-1 개의 디스크 고장에도 서비스 할 수 있음• Failure Transparency

• 데이터 안전성 vs 비용• 복제 되어 있는 것도 잘 감추자

• Replication Transparency3/12

다시 계산• 1 copy 일 때 50,000 개 디스크 , 3 copy 면 총

150,000 개 디스크가 필요• 서버 대수도 15,000 대

3/12

메타 데이터 변경

• 메타 데이터는 3 개의 서버 위치를 저장해야 함

3/12

메타 데이터id server1 disk1 server2 disk2 server3 disk3

sangchul 15 2 23 5 255 3

john 50 9 534 3 4564 5

cathy 920 1 4363 8 457 8

lucy 743 8 6436 2 13453 1

3/12

장 , 단점• 부수 효과

• 복제본이 많다면 읽기 처리량을 늘릴 수 있음• 어려운 점

• 동시 연산이 수행될 때 데이터들간의 정합성을 맞추기 쉽지 않음3/12

복제 정합성

3/12

복제 정합성

3/12

복제 정합성불일치

3/12

복제 정합성a.jpg 쓰기 a.jpg 지우기

3/12

복제 정합성a.jpg 쓰기 a.jpg 지우기

3/12

복제 정합성 ?

데이터 유실 !3/12

복제 정합성 ?a.jpg 쓰기 a.jpg 지우기

Lock…

3/12

복제 정합성 ?

a.jpg

a.jpg 쓰기 a.jpg 지우기

a.jpg

Lock

a.jpg

…

3/12

문제점들• Single Point of Failure (SPoF)• Concurrency problem

3/12

4. 일부 헤비 유저때문에 성능이 안 나와요

location transparency

• 처음 메타 데이터를 구성할 때부터 각 서버별 성능 /용량에 대한 고려를 할 수 없음• 서버별 성능 / 용량 편차가 발생할 경우 재배치가 필요함

4/12

Migrationsangchu

l 15 1

15sangchul

Migrationsangchu

l 15 1

15sangchul

60

Migrationsangchu

l 15 1

15sangchul

60sangchul

copy

Migrationsangchu

l 15 1

15sangchul

60sangchul

logplay

Migrationsangchu

l 60 1

15sangchul

60sangchul

고려할 점• 데이터를 옮기고 있을 때 사용자가 새로운 파일을 쓰거나 기존 파일을 지우면 어떻하지 ?

• 복제 정합성이 안 맞는 문제• Cache 에 옛 meta 정보가 있음

• cache invalidation 문제4/12

5. 1TB 로 upgrade 하는 상품을 출시하려는데요 .

Scalability

• 성능과 용량 확장• 확장이 용이한가 ?• 들인 비용 만큼의 효과가 나오는가 ?

5/12

Scalability• Scale up

• 장비 업그레이드• 성능에 비해 비용은 기하급수적으로 증가

• Scale out• 새 장비를 추가• 성능과 비용이 산술급수적으로 증가

5/12

Scale out• 15,000 대 서버를 2 배로 증설합시다• 새로운 사용자들은 15,001~30,000 번 서버를 사용하게 합시다• 기존 사용자들도 일부 새 서버들로 옮깁시다 .

• Migration

5/12

6. 고장난 장비를 처리하는 운영자가 고생 많네요 .

운영자• 장비 및 네트워크 담당자• 고장난 디스크 교체• 디스크가 빨리 교체되지 않으면 시스템 가용성이 낮아짐

6/12

자동 복구

• 또 다시 Migration!

6/12

Migration

id server1 disk1 server2 disk2 server3 disk3

sangchul 60 1 23 5 255 3

23 번 장비 5 번 디스크에 있던 sangchul 을 다른 디스크로 옮기시오

6/12

Migration

id server1 disk1 server2 disk2 server3 disk3

sangchul 60 1 23 5 255 3

23 번 장비의 5 번 디스크의 sangchul 데이터를6800 번 장비의 1 번 디스크로 옮깁니다 .

6/12

Migration

id server1 disk1 server2 disk2 server3 disk3

sangchul 60 1 6800 1 255 3

복사중 발생한 연산을 6800 번 장비에 replay 합니다 .

6/12

Migration

id server1 disk1 server2 disk2 server3 disk3

sangchul 60 1 6800 1 255 3

6/12

고장의 규모• 서버• 네트워크• IDC• 다 migration 으로 자동 복구 가능

6/12

7. 비용 좀 줄일 방법 없을까요 .

파레토 법칙• 80/20 법칙• 전체 트래픽의 80% 는 20% 의 유저에게서 발생• 전체 읽기 트래픽의 80% 는 최신 20% 데이터에만 발생한다

7/12

Cold Data

• 별로 읽히지 않는 데이터까지 3 copy 를 보관할 필요 있을까요 ?• 잘 안 읽히는 데이터는 2 copy 만 보관합시다 .

• 2 copy 도 아까운데 더 줄일수는 없을까요 ?

7/12

더 좋은 방법 ?• 비용을 줄일 수 있는 요소

• 더 값싼 서버• 가격은 싸고 저장 용량이 더 큰 디스크

• 싼게 비지떡• 고장이 더 잘 나면 곤란함

• 복제방식과 같은 가용성을 제공하면서 더 적게 용량을 차지하도록 저장하는 방법은 없을까 ?7/12

Erasure Code

data 1MB

7/12

Erasure Code

data1 data2 data3 data4

7/12

Erasure Code

data1 data2 data3 data4f( )

7/12

Erasure Code

data1 data2 data3 data4

code1 code2

f( )=

7/12

Erasure Code

data1 data2

data3 data4

code1 code2f( )=

7/12

Erasure Code

data1 data2 data3 data4

code1 code2 1.5MB

7/12

Replication vs Erasure Code

• Replication (3 copy) : 2 개 디스크가 고장나도 1개 디스크로 서비스 할 수 있음• 3 개 디스크 필요• 디스크 고장시 추가 연산 필요 없음

7/12

Replication vs Erasure Code

• Erasure Code (4+2) : 2 개 블럭이 없어도 임의의 4 개 블럭만 있으면 데이터를 복구할 수 있음• 1.5 배 용량만 필요• 디스크 고장시 나머지 4 개 데이터를 모두 읽어 계산을 해야 함

7/12

다시 계산• 90/10 법칙 적용

• 전체 트래픽의 90% 는 최근 10% 에 기록된 파일들• 5,000 대 * 0.1 * 3 = 1,500 대• 5,000 대 * 0.9 * 1.5 = 6,750 대• 총 8,250 대 필요

• 기존 15,000 대 대비 55% 수준 비용• 동일하게 2 개 디스크 장애에 대한 가용성 보장• hot data 들에게는 여전히 빠른 연산 보장

7/12

8. 해외 진출 합니다 .

Globalisation

• 대륙별 , 대륙내에서도 지역별로 IDC 가 있음• 이 IDC 들간의 network latency 편차가 매우 큼• 심지어 IDC 간 network 이 끊어질 수도 있고 , IDC 자체가 파괴될 수도 있음

8/12

Globalisation• 파일시스템이 여러 IDC 에 나눠져 있다는 사실 조차

transparency 를 제공• 여러 IDC 에 나눠 저장되는 파일들의 단일한 이름 체계는 ?

• 한국 사용자가 스페인에 여행을 가서 찍은 사진을 업로드합니다 .• 이 사용자의 데이터가 한국에 있다면 ?

• …8/12

9. 문제가 생겼을 때 빠르게 대처하기 위해선 ?

진단 및 대응• 로그 메시지• 에러 분류 및 대응 매뉴얼• 통계 및 지표 분석• 알림 체계

9/12

10. 쌓여있는 데이터를 또 다르게 활용할 수도 있겠죠

분석• Locality

• 데이터가 저장된 장비에서 직접 데이터를 읽어 분석해야 network 비용을 최소화 할 수 있음• 분석 스크립트나 명령어를 분석해서 데이터 위치 및 장비 상태 , 알고리즘 특성을 고려해 최적의 장비에서 수행

10/12

사용자 통계

• sangchul 사용자가 저장하고 있는 파일 유형과 개수를 얻는 스크립트를 수행한다면 ?

10/12

분석

1 … 4999 5000

sangchul

server 680, disk 1

runscript

680 …

10/12

분석680

sangchul

script결과1. 전체 파일 목록을 순회

2. 각 파일 별 type 정보 요청3. type 별 count 누적

4. 최종 결과 전송

10/12

11. 플랫폼화

저장 플랫폼• 모든 서비스들이 비슷한 고민을 하고 있음

• 네이버 클라우드 , 메일 , 블로그 , 카페 , 사진 , 지도…• 여러 종류의 저장소들도 비슷한 기능이 요구됨

• 파일 시스템 , 데이터베이스 , 메모리 저장소 , 캐시…11/12

저장 플랫폼• 서비스들이 공통으로 사용하는 시스템• 잘 만들어진 플랫폼은 새롭고 품질 높은 서비스를 빠르게 개발할 수 있는 토대가 됨

11/12

12. 이 좋은 걸 우리만 쓰기는 아깝네요

Open Source

• 나눔과 도움• 개발자 본인에게도 명성을 쌓을 수 있는 기회• 사용자로써 분산저장플랫폼을 평가할 수 있는 안목

12/12

Open Source

• 네이버에서 만들고 성공적으로 적용해서 외부에 open 된 대표적인 플랫폼들• Arcus, Pinpoint, nBase-ARC …

12/12

마치며

• 대규모 , 대용량 , 성능 , 고가용성 , 비용의 문제를 푸는게 재밌다면 ?• 다른 개발자가 사용하는 , 퀄리티 있는 소프트웨어 부품을 개발하는 재미를 맛보고 싶다면 ?

감사합니다