분산저장시스템 개발에 대한 12가지 이야기
-
Upload
naver-d2 -
Category
Technology
-
view
4.226 -
download
6
Transcript of 분산저장시스템 개발에 대한 12가지 이야기
분산저장시스템 개발에 대한 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
마치며
• 대규모 , 대용량 , 성능 , 고가용성 , 비용의 문제를 푸는게 재밌다면 ?• 다른 개발자가 사용하는 , 퀄리티 있는 소프트웨어 부품을 개발하는 재미를 맛보고 싶다면 ?
감사합니다