분산저장시스템 개발에 대한 12가지 이야기
•Als PPTX, PDF herunterladen•
16 gefällt mir•8,462 views
우리가 이름만 들어도 아는 유명 IT 서비스들의 화려한 웹페이지도, 예쁜 모바일 앱도 그 뒤에는 탄탄하고 강력한 분산 시스템을 기반으로 합니다. 이러한 백엔드 시스템이 부실할 경우 서비스나 앱은 그야말로 사상누각입니다. 본 세미나에서는 이러한 시스템들을 만들때 풀어야 할, 가장 기본이 되는 문제와 이슈들 12가지에 도전해봅니다.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie 분산저장시스템 개발에 대한 12가지 이야기
Ähnlich wie 분산저장시스템 개발에 대한 12가지 이야기 (20)
Mehr von NAVER D2
Mehr von NAVER D2 (20)
분산저장시스템 개발에 대한 12가지 이야기
- 1. 분산저장시스템 개발에 대한 12가지 이야기 네이버 분산시스템 문상철
- 2. 소개 • 문상철 • 네이버 (from 2007) • 분산시스템 연구 & 개발 • 분산 파일 시스템 • 분산 데이터 베이스 • Linux system & network programming
- 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
- 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
- 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
- 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. 감사합니다