우리가 이름만 들어도 아는 유명 IT 서비스들의 화려한 웹페이지도, 예쁜 모바일 앱도 그 뒤에는 탄탄하고 강력한 분산 시스템을 기반으로 합니다. 이러한 백엔드 시스템이 부실할 경우 서비스나 앱은 그야말로 사상누각입니다. 본 세미나에서는 이러한 시스템들을 만들때 풀어야 할, 가장 기본이 되는 문제와 이슈들 12가지에 도전해봅니다.

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

2. 소개
• 문상철
• 네이버 (from 2007)
• 분산시스템 연구 & 개발
• 분산 파일 시스템
• 분산 데이터 베이스
• Linux system & network programming

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

4. 수면위로 얼마나 보이는
거지?
• 전체 부피 중 유체 위에 노출되는 부피 비율
• = 1 - (물체의 밀도 / 유체의 밀도)
• = 1 - (0.92 / 1.03) = 0.1 = 10%
• 10%의 예쁜 빙산이 바다 위에서 보이려면 90%의
거대한 빙산이 수면 아래에 존재해야 함

5. 빙산의 일각
• 이름만 들어도 아는 유명 IT 기업들
• Google, Amazon, Apple…
• Naver…
• 이들의 서비스가 만일 “일각”이라면, 수면 아래에
는 뭐가 있지?

6. 분산시스템
• 정의
• A distributed system is a collection of
independent computers that appears to its
users as a single coherent system.

7. 분산시스템
• 정의
• A distributed system is a collection of
independent computers that appears to its
users as a single coherent system.

8. 플랫폼
• 서비스마다 공통으로 필요로 하는 기반 기술
• 파일, 구조화된 데이터, 대용량 분석, 이미지 처
리, 지도, 머신러닝, …
• Software Framework + Hardware Infrastructure
• 훌륭한 서비스를 만들기 위해 잘 설계되고 견고한
부품

9. 분산 저장 시스템
• 분산 시스템
• 데이터 저장
• 파일이나 구조화된 데이터
• 플랫폼

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

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

12. 간단한 계산
• 3,700만명 x 30GB = 1100 PB (1PB = 1000TB)
• 1,000만명 x 5GB = 50PB
• 1 TB disk가 50,000개
• 1대 서버에 10개 disk를 장착할 수 있다면?
• 총 5000대의 서버가 필요
1/12

13. 메타 데이터
1 2 3 … 4999 5000
1/12

14. 메타 데이터
1 2 3 … 4999 5000
sangchul의 데이터는 어느 서버에 어느 디스크에 저장하지?
1/12

15. 메타 데이터
id server disk
sangchul 3 2
yj 50 9
wendy 920 1
kh 743 8
… … …
1/12

16. 시나리오
1 2 3 … 4999 5000
API
sangchul
server 3, disk 1
file write
1/12
Servic
e

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

18. 메타 데이터 조회
• 가입자의 10%가 peak 시간대에 파일을 읽으려고
한다면?
• 100만명이 자신의 meta 정보를 조회
• DB 1대의 처리량: 10,000 qps
• 100만번째 유저는 100초를 기다려야 함?
2/12

19. 메타 데이터 Cache
• 사용자 id와 server, disk 정보는 거의 변경되지 않
음
• 모두 메모리에 cache해두면 훨씬 낫지 않을까?
2/12

20. 메타 데이터 Cache
• user id, server id, disk id
• 256 + 4 + 2 = 262 byte
• 262 * 3700만명 = 대략 10GB
2/12

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

22. 시나리오
1 2 3 … 4999 5000
API
sangchul
server 3, disk 1
file write
C
C
…
C
2/12

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

24. 사용 시간에 따른
디스크의 고장 확률
고장 확률
디스크 사용 시간 3/12

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

26. 복제
• 사용자가 1개 파일을 저장하면 N개 디스크에 동시에 저
장하자.
• N-1개의 디스크 고장에도 서비스 할 수 있음
• Failure Transparency
• 데이터 안전성 vs 비용
• 복제 되어 있는 것도 잘 감추자
• Replication Transparency
3/12

27. 다시 계산
• 1 copy일 때 50,000개 디스크, 3 copy면 총
150,000개 디스크가 필요
• 서버 대수도 15,000대
3/12

28. 메타 데이터 변경
• 메타 데이터는 3개의 서버 위치를 저장해야 함
3/12

29. 메타 데이터
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

30. 장,단점
• 부수 효과
• 복제본이 많다면 읽기 처리량을 늘릴 수 있음
• 어려운 점
• 동시 연산이 수행될 때 데이터들간의 정합성을
맞추기 쉽지 않음
3/12

31. 복제 정합성
3/12

32. 복제 정합성
3/12

33. 복제 정합성
불일치
3/12

34. 복제 정합성
a.jpg 쓰기 a.jpg 지우기
3/12

35. 복제 정합성
a.jpg 쓰기 a.jpg 지우기
3/12

36. 복제 정합성?
데이터 유실!
3/12

37. 복제 정합성?
a.jpg 쓰기 a.jpg 지우기
Lock
…
3/12

38. 복제 정합성?
a.jpg
a.jpg 쓰기 a.jpg 지우기
a.jpg
Lock
a.jpg
…
3/12

39. 문제점들
• Single Point of Failure (SPoF)
• Concurrency problem
3/12

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

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

42. Migration
sangchul 15 1
15
sangchul

43. Migration
sangchul 15 1
15
sangchul
60

44. Migration
sangchul 15 1
15
sangchul
60
sangchul
copy

45. Migration
sangchul 15 1
15
sangchul
60
sangchul
log
play

46. Migration
sangchul 60 1
15
sangchul
60
sangchul

47. 고려할 점
• 데이터를 옮기고 있을 때 사용자가 새로운 파일을
쓰거나 기존 파일을 지우면 어떻하지?
• 복제 정합성이 안 맞는 문제
• Cache에 옛 meta 정보가 있음
• cache invalidation 문제
4/12

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

49. Scalability
• 성능과 용량 확장
• 확장이 용이한가?
• 들인 비용 만큼의 효과가 나오는가?
5/12

50. Scalability
• Scale up
• 장비 업그레이드
• 성능에 비해 비용은 기하급수적으로 증가
• Scale out
• 새 장비를 추가
• 성능과 비용이 산술급수적으로 증가
5/12

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

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

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

54. 자동 복구
• 또 다시 Migration!
6/12

55. Migration
id server1 disk1 server2 disk2 server3 disk3
sangchul 60 1 23 5 255 3
23번 장비 5번 디스크에 있던 sangchul을 다른 디스크로 옮기시오
6/12

56. Migration
id server1 disk1 server2 disk2 server3 disk3
sangchul 60 1 23 5 255 3
23번 장비의 5번 디스크의 sangchul 데이터를
6800번 장비의 1번 디스크로 옮깁니다.
6/12

57. Migration
id server1 disk1 server2 disk2 server3 disk3
sangchul 60 1 6800 1 255 3
복사중 발생한 연산을 6800번 장비에 replay 합니다.
6/12

58. Migration
id server1 disk1 server2 disk2 server3 disk3
sangchul 60 1 6800 1 255 3
6/12

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

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

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

62. Cold Data
• 별로 읽히지 않는 데이터까지 3 copy를 보관할 필
요 있을까요?
• 잘 안 읽히는 데이터는 2 copy만 보관합시다.
• 2 copy도 아까운데 더 줄일수는 없을까요?
7/12

63. 더 좋은 방법?
• 비용을 줄일 수 있는 요소
• 더 값싼 서버
• 가격은 싸고 저장 용량이 더 큰 디스크
• 싼게 비지떡
• 고장이 더 잘 나면 곤란함
• 복제방식과 같은 가용성을 제공하면서 더 적게 용량을 차
지하도록 저장하는 방법은 없을까?
7/12

64. Erasure Code
data 1MB
7/12

65. Erasure Code
data1 data2 data3 data4
7/12

66. Erasure Code
data1 data2 data3 data4
f( )
7/12

67. Erasure Code
data1 data2 data3 data4
code1 code2
f( )
=
7/12

68. Erasure Code
data1 data2
data3 data4
code1 code2
f( )
=
7/12

69. Erasure Code
data1 data2 data3 data4
code1 code2 1.5MB
7/12

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

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

72. 다시 계산
• 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

73. 8. 해외 진출 합니다.

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

75. Globalisation
• 파일시스템이 여러 IDC에 나눠져 있다는 사실 조차
transparency를 제공
• 여러 IDC에 나눠 저장되는 파일들의 단일한 이름
체계는?
• 한국 사용자가 스페인에 여행을 가서 찍은 사진을 업
로드합니다.
• 이 사용자의 데이터가 한국에 있다면?
• …
8/12

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

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

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

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

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

81. 분석
1 … 4999 5000
sangchul
server 680, disk 1
run
script
680 …
10/12

82. 분석
680
sangchul
script
결과1. 전체 파일 목록을 순회
2. 각 파일 별 type 정보 요청
3. type별 count 누적
4. 최종 결과 전송
10/12

83. 11. 플랫폼화

84. 저장 플랫폼
• 모든 서비스들이 비슷한 고민을 하고 있음
• 네이버 클라우드, 메일, 블로그, 카페, 사진, 지
도…
• 여러 종류의 저장소들도 비슷한 기능이 요구됨
• 파일 시스템, 데이터베이스, 메모리 저장소, 캐
시…
11/12

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

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

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

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

89. 마치며

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

91. 감사합니다