슬라이드 1

Size: px

Start display at page:

Download "슬라이드 1"

간희 진
5 years ago
Views:

1 Lessons learned from deploying SSD in NAVER services NVRAMOS Naver Labs 김태웅

2 목차 Naver Labs 네이버의데이터저장플랫폼 네이버서비스에서 SSD 활용 결론 2

3 3

4 4 4

5 역할 네이버의핵심기술의연구 / 개발을통해기술을내재화 학생및개발자들을대상으로기술과꿈을나누는조직 5

6 개발자컨퍼런스 DEVIEW 6

7 목차 Naver Labs 네이버의데이터저장플랫폼 네이버서비스에서 SSD 활용 결론 7

8 The era of data explosion 매 1 분마다 유튜브는 72시간분량의신규동영상업로드이메일사용자는 2억개이상의메일발송구글은 4M개검색질의처리페이스북사용자는약 2.5M개의컨텐츠공유트위터는약 280K개의트윗인스타그램은약 220K개의사진업로드 하루최대 130 억건의 communication 분당약 9M 건이상메시지, 동영상, 사진송수신 출처 : 8

9 이용자에의해생성되는데이터도있지만 출처 : 9

10 네이버의데이터저장플랫폼 파일저장소 분산파일시스템 : OwFS, Papyrus 데이터베이스 DBMS: CUBRID 분산 DB 클러스터링 : nbase-t 분산 Key/value 저장소 nbase-arc 메모리캐시 ARCUS 10

11 OwFS What is OwFS? Owner-based File System 네이버의포털서비스환경에적합하도록개발한대규모분산파일시스템으로, 여러서버들의디스크공간들을묶어하나의대규모파일저장공간을생성 Owner 서로관련있는파일들을묶어서저장하는단위 (container 개념 ) 수많은 owner의합이전체파일시스템을구성 Owner 별로 3개의복제본을서로다른서버에저장 OwFS 의특징 가용성 확장성 성능 운영편의성 점검시서비스 downtime 이없음 Owner map 캐시 응용서버 Owner 조회 파일 I/O Owner 의복제본정보 메타데이터서버 (MDS) DS1 DS2 DS3 홍길동변학도 홍길동성춘향 홍길동이몽룡 Owner map Owner 이름 복제본 홍길동 1,2,3 이몽룡 3,4,5 성춘향 2,5,6 변학도 1,4,6 DS4 DS5 DS6 이몽룡변학도 성춘향이몽룡 성춘향변학도 데이터서버 (DS) 11

12 OwFS 적용서비스 네이버 /LINE/NHN Entertainment 의 200 개이상서비스 일반적으로데이터저장서버는대용량의 SATA 디스크기반으로구축 고성능을위해서최신데이터는 SSD 에우선저장하고일정기간후 HDD 로이동시키는 tiering 을적용하기도함 범용파일저장목적외에 ViSTO (Virtual iscsi Storage over OwFS): Amazon EBS 와유사하게네이버내부개발자클라우드의 VM 환경에서동적으로블록스토리지를제공 12

13 Papyrus 분산파일시스템의 Storage tiering 에서 secondary storage 저장비용이효율이좋은파일 archive 용스토리지 특징 OwFS 와같은복제본기반의데이터가용성을사용하지않고 Erasure coding 을사용한데이터저장방식사용 file D0 D1 file D2 D3 C0 C1 encoding D0 D1 D2 D3 C0 C1 Papyrus 13

14 Papyrus architecture Cover, TOC, Index, Page 서버군으로구성 Application Cover Get section of chapter /foo TOC Chapter to Section Mapping write( /foo/bar ) Index Get pages map of /foo Section to Pages Mapping D0 D1 D2 D3 D4 D5 C0 C1 C2 Page Section 14

15 CUBRID DBMS 네이버의오픈소스 DBMS 15

16 CUBRID 적용서비스 메일, 사전, Naver me, 네이버캐스트, N 드라이브등 NAVER 주요서비스에적용 사내시스템모니터링사이트인 Nsight 등사내주요서비스에적용 16

17 nbase-t nbase-t 분산과확장성을제공하는 DB middleware 분산키별로 container 라는개별공간을제공. container 별로 RDBMS 기능을지원 Online data migration 을통한노드증설 / 감설 / 물리이전 / 밸런싱기능을제공 주요기능 Online data migration 병렬작업에대한스케쥴링및로드관리 Membership 상태및메타데이터관리 Distributed query processing 등 Node1 Node2 Application NodeN Management + Server + nbase + nbase + nbase + nbase... + nbase + nbase CUBRID HA or MySQL MMM 적용서비스 네이버 : 메일, 블로그, 라인 : 분산코인시스템, 세션 / 인증, 게임 DB, 기타라인플레이게임 DB, NHN ENT 게임메일 / 게임 DB CUBRID HA or MySQL MMM CUBRID HA or MySQL MMM 17

일관성을보장하는복제 layer 기반의복제그룹의집합이며, nbase-arc 는복수의

18 nbase-arc Redis 기반의분산메모리저장소로다양한구조체에대한 in-memory 고속연산을분산환경에서동일하게제공 고가용 Multi-Cluster service pool 일관성을보장하는복제 layer 기반의복제그룹의집합이며, nbase-arc 는복수의 cluster 를운용 페타바이트급대용량이기종클러스터드 DBMS SW 개발 ( 과제번호 ) 18

19 ARCUS ( 메모리캐시클라우드 ) 19

20 서비스와플랫폼개발및구축시고려사항 Better Solution? Faster Cheaper 데이터스토리지관점에서 Better 데이터의 durability를높이려면더많은복제본을동기적으로기록 Faster 데이터 IO의 latency를줄이려면메모리와같은고속매체의존성이높아짐 Cheaper 비용만생각한다면성능과품질의희생이필요 20

21 목차 Naver Labs 네이버의데이터저장플랫폼 네이버서비스에서 SSD 활용 결론 21

22 A brief retrospect 네이버는 2010 년부터 SSD 도입시작 고성능 DB 서버에 SSD 장착, 높은 IOPS 를요구하는서비스에시범적용 SSD 에대한막연한불안감 수명과안정성을고려하여 SLC 모델위주도입 GC 로인한성능저하를우려하여용량기준을 85% 만사용하는것을기준 2011 년 DBMS는대부분 SAS 디스크를사용 읽기부하가높은 DB 서비스는메모리캐시 + DBMS 조합으로구성 쓰기부하가높은 DB에만 SSD 장착 2012 년 ~ DB 쓰기부하가높은응용의요구사항증가 SSD 의구축비중이높아짐 22

23 SSD 도입시고려했던사항 SSD 의장점 성능관점 : HDD 에비해우수한성능 (random I/O) IDC 운영관점 : 소음과발열이적고소비전력과상면공간절약 SSD 의단점 높은비용과소용량 ( vs. HDD) 쓰기회수제한 ( 데이터의성격에따라다름 ) Write Once Read Many 성격의사진, 뮤직, 동영상서비스에는우수 데이터베이스와같이데이터의삽입, 삭제, 변경이많은경우는내구성문제 스토리지구축시 HDD/SSD 선택기준 요청처리량, 목표응답시간, 워크로드특성 ( 읽기 : 쓰기비율 ) 성능요구사항에부합되는비용효율성고려 DB 서버의 scale up, scale out시비용 메모리캐시클라우드의활용시비용 23

24 SSD 사용현황 SSD 는어떤용도로주로사용되는가? 고성능데이터베이스서버 고성능파일서비스를위해 SSD-HDD로 Tiering 24

25 SSD 의고장률통계 Type 별장애비율 Type 장애비율 SATA 1.57% SAS 1.21% SSD 0.41% SSD 고장이발생시 RAID 로구성된다른 SSD 도고장날가능성이높다는것을경험하였고 SSD 의수명을예측하고대비하는것이매우중요 25

26 PCIe Flash card Fusion-io 의 iodrive, ioscale 초고성능 DB 서버구축시주로사용 PCIe Flash Card 의경우문제점 운영관점 : 저장장치고장시교체의문제 비용관점 : SSD 에가격이매우비쌈 DB 와 I/O intensive 서버들은상대적으로 CPU utilization 이낮으므로이런서버들을 consolidation 하는용도로도 PCIe Flash Card 를활용가능 26

27 DBMS Page buffer 와디스크간 I/O 는 random I/O 27

28 SSD 도입으로인한 SELECT 성능향상 YCSB 를이용한성능측정 DB 데이터버퍼크기와저장매체간의성능변화상관관계 CUBRID의버퍼크기를변경하면서 SELECT TPS 측정 28

29 분산파일시스템에서 Tiering OwFS Instance SSD Group 1 *1 SATA Group 1 SSD Group 2 *2 SATA Group 2 MDS *2 SATA Group 3 *1 파일 write 직후 async 하게복제 *2 일정기간경과후 SSD Group 의복제본을제거하고 SATA 그룹내에서 3 copy 복제 29

30 Many small files 저장문제 1GB 블록디바이스를각각 Ext4, XFS 로파일시스템을만든후디렉토리당 1KB 크기의파일을 10,000 개씩생성 1GB 는약 1,000,000 KB 이므로, 백만개에근접한개수의파일을저장하는것을기대 파일시스템 File system full File system usage Ext4 65,518 개파일생성 31% XFS 234,482 개파일생성 100% mkfs 의 default 옵션 : 파일시스템의블록크기 4KB, ext4 의경우 1GB 파티션의경우 inode 개수가 65,536 개로파일시스템이만들어짐 파일시스템 Tuning 파일시스템 File system full mkfs 명령옵션 Ext4 796,702개파일생성 -b 1024 N XFS 810,172개파일생성 -bsize=1024 -imaxpct=0 30

31 Many small files 저장문제 ( 계속 ) 파일저장서버 12 디스크 bay, 4TB SATA 디스크 RAID5 구성으로 6개씩구성하면 20TB 볼륨 2개 RAID5 구성으로 12개를구성하면 44TB 볼륨 1개 4KB 미만의가변크기의작은파일을저장한다면, 20TB 볼륨에는최소 50 억개이상의파일이저장됨 (5,3 Billion) 44TB 볼륨에는최소 110 억개이상의파일이저장됨 (11.8 Billion) 디렉토리블록과 inode 블록을메모리에충분히캐싱하기어려움 파일을접근하려면로컬파일시스템에서지속적인 random I/O 유발 따라서, Many small files 저장서버구성시 HDD 보다는 SSD 가유리그러나, 문제는비용 31

32 Many small files 에유리한저장구조 Small 파일을파일시스템상의개별파일로저장하지않고 Container 파일에 append하여저장 Container Index Pathname /foo /bar/file1 /bar/file2 /baz/file Offset Header Header Header Header Pathname File size Creation time Deleted flag Deleted time Checksum Index 를메모리에전부올려처리하는것이최선 Index 를 SSD 에저장하는것이차선책 32

33 목차 Naver Labs 네이버의데이터저장플랫폼 네이버서비스에서 SSD 활용 결론 33

34 SSD 에대한요구사항 Random I/O 성능극대화 복제를이용한가용성제공및고장복구 SSD 에 RAM 버퍼를두고쓰기요청을 RAM 버퍼에기록하고반환해도허용될수있는여지가있음 Maximum read latency 최소화 Average read latency 도중요하지만 maximum read latency 가더중요 SSD 내부에서읽기요청을쓰기요청보다높은우선순위로처리하거나 GC 의수행주기등을조절하여읽기요청의응답시간편차를감소 DBMS 에서단일페이지의 atomic write DBMS 가사용하는페이지크기와 SSD 내부의페이지크기가일치하지않으면, 단일페이지쓰기가 SSD 내부에서복수의페이지쓰기가될수있음 이러한 mismatch 에대비하여 DBMS 들은보완책을사용하게되는데 SSD 의내부페이지크기를응용이요구하는크기로맞출수있다면좋겠음 박준현, 신기빈, 송창현, IDC 에서의애플리케이션이슈와 SSD 요구특성, 전자공학회지 (The Magazine of the IEEK) 제 41 권 5 호, pp.57-67, 2014 년 5 월 34

35 SSD 에대한요구사항 SSD 내부동작상태의조회기능 SSD 내부의페이지 / 블록크기, GC 수행시점과주기, wear leveling, 에러수정 (error correction), read-ahead 등의내부상태를조회하는기능 SSD 내부동작의제어기능 SSD 내부동작을제어할수있다면, 응용상황에맞게 SSD 를사용할수있음 Ex) GC 수행기준이나주기를제어하여, latency 또는 throughput 성능을조절하거나 GC 의일시적중지 / 재개를통해쓰기요청과 GC 작업의간섭최소화 Transparent compression 파일저장목적으로사용하려면 SSD 가자동압축 / 해제기능을지원 Over-provisioning SSD 용량을 full 로사용하더라도성능저하나고장이발생하지않도록 SSD 내부의예비공간을충분히제공 박준현, 신기빈, 송창현, IDC 에서의애플리케이션이슈와 SSD 요구특성, 전자공학회지 (The Magazine of the IEEK) 제 41 권 5 호, pp.57-67, 2014 년 5 월 35

슬라이드 1

슬라이드 1 네이버의플랫폼기술소개 2014-11-27 Naver Labs / 서비스플랫폼 G 김태웅 2 https://www.facebook.com/naverlabs 3 3 역할 네이버의핵심기술의연구 / 개발을통해기술내재화 학생및개발자들을대상으로기술과꿈을나누는조직 4 서비스플랫폼 G 의연구개발분야 범용스토리지플랫폼 분산파일시스템 : OwFS, Papyrus DBMS: CUBRID