<30312DC6EDC1FDC0A7BFF82E687770>

Size: px

Start display at page:

Download "<30312DC6EDC1FDC0A7BFF82E687770>"

강하 인
5 years ago
Views:

1 8 OwFS: 대규모인터넷서비스를위한분산파일시스템 성균관대학교 김진수 * NHN( 주 ) 김태웅 * 1. 서론 1) 현대인들에게있어서다양한인터넷서비스는소수의전문가혹은신세대들만의전유물에서벗어나일상적인문화의일부분으로자리잡아가고있다. 무료이메일계정을통해메일을주고받고, 카페나소셜네트워킹사이트등을통해친목을도모하며, 자신이촬영한사진이나손수제작한동영상을공유사이트에업로드하는등의활동이보편화되고있다. 이밖에도게임, 블로그, 위성사진, 지도, 뉴스, 도서, 쇼핑몰등의다양한서비스들이인터넷을통해이루어지고있으며, 서비스규모또한날로대형화되고있는추세이다. 이에따라인터넷상의정보량또한폭발적으로증가하고있다. 특히, 사용자가적극적으로사용자제작컨텐츠 (UGC: User Generated Contents) 의생성, 유통, 공유, 재사용에참여하는웹 2.0 시대로접어들면서그현상은더욱가속화되고있다. 미국의시장조사업체 IDC는개인에의해만들어지는 UGC 의증가, 아날로그정보의디지털전환, 이메일의증가등으로인해앞으로수년간전세계의디지털정보가연평균 57% 씩증가할것으로예상하였다 [1]. 인터넷서비스업체들은보다많은사용자를확보하기위하여경쟁적으로대규모의저장공간을제공하고있다. 당시로서는파격적이었던, 1GB 이상의메일저장공간을최초로제공해서화제가되었던구글메일 (Gmail) 은현재사용자당 7.3GB를제공하고있으며, 야후메일 (Yahoo!Mail) 은무한대의저장공간제공을선언하고나섰다. 사진공유사이트인 Picasa 는사용자계정당 1GB 의저장공간을지원하고, 유사한서비스를제공하는 Flickr는총사용량의제한없이매달 100MB 미만의사진을무제한업로드할수있도록허용하고있다. 동영상공유사이트인 YouTube 에 * 종신회원 는재생시간 10분이내, 크기 1GB 미만의동영상을무한대로업로드할수있다. 대부분이러한서비스들은사용자들에게무료로제공되기때문에인터넷서비스업체의입장에서는최소의비용으로필요한저장공간을확보하는것이해당서비스의경쟁력, 더나아가서는회사의생존과직결되는매우중요한요소가되고있다. 일례로, 인터넷메일서비스의후발주자였던 Gmail 이서비스개시몇년만에수천만명이상의사용자를확보할수있었던이면에는적은비용으로성능이우수하고, 신뢰성있는저장장치를대용량으로구축할수있었던구글의기술력이있었기때문이다. 구글은수십만대이상의저가하드웨어를클러스터링하여대규모저장용량을제공하는구글파일시스템 (GFS)[2] 을자체적으로개발한후, 자사의웹검색서비스를비롯한다양한서비스에적용하고있으며, 이를통해단위저장공간당요구되는비용을경쟁업체대비획기적으로절감하고있는것으로알려지고있다. 아마존 (Amazon) 도 Dynamo[3] 라불리는자체적인저장시스템을개발하여쇼핑카트서비스를포함한아마존전자상거래플랫폼의핵심서비스에적용하고있다. GFS나 Dynamo 와같이특정서비스에특화된저장장치의개발및활용은대용량저장공간확보에필요한비용을줄이고효율성을높일수있는새로운방법으로주목받고있다. 이것은폭발적으로증가하는데이터를고가의범용저장장치에저장할경우서비스비용이심각하게증가하기때문이다. 구글이나아마존은목표서비스들이공통적으로요구하는최소한의기능만을구현하였으며, 저가의하드웨어를사용하는데따르는데이터가용성의저하는복제본을이용한소프트웨어기술로보완하는접근방법을취하였다. 이와같은해외선두업체의움직임에영향을받아국내의대규모인터넷서비스업체들도고가의외산 OwFS: 대규모인터넷서비스를위한분산파일시스템 77

2 저장장치에의존하던기존의방법에서탈피, 저장장치의경쟁력을높이려는노력을본격화하기시작하였다. 본고에서는이러한노력의하나로탄생한분산파일시스템 OwFS(Owner-based File System) 를소개하고자한다. 지난 2006년부터김진수교수연구팀과 NHN이개발해온 OwFS 는고성능, 신뢰성, 확장성, 대용량처리, 관리의용이성을갖춘분산파일시스템이다 [4]. 순수독자적인기술로개발된 OwFS 는 2년여에걸친개발과집중적인테스팅과정을거친후 2007 년하반기부터 NHN의실제서비스에적용되었으며, 이후점진적으로적용범위를확대해나가고있다. 2. OwFS 요구사항 2.1 설계목표및특징 OwFS 의주요설계목표및특징을요약하면다음과같다. 네이버커뮤니티서비스를위한분산파일시스템초기 OwFS 는메일, 카페, 블로그등네이버커뮤니티서비스에의적용을목표로설계되었다. 이들서비스들의특징은다루는정보가크게데이터부분 ( 메일원문, 카페및블로그의이미지, 첨부파일등 ) 과데이터에대한메타정보부분 ( 메일헤더정보, 카페및블로그의게시관련정보등 ) 으로구성되어있다는점이다. OwFS 는기존의저장장치를완전히대체하는용도로개발되기보다는커뮤니티서비스가다루는정보중데이터부분에해당하는정보만을저장하는보완적인저장장치로개발되었다. 그이유는데이터부분이저장공간용량의대부분을차지하는데반해그접근특성이단순하여특화된저장장치개발이용이하였기때문이다. OwFS 가대상으로하는파일시스템의접근특성에대해서는다음절에서자세히살펴보기로한다. 고성능, 저비용, 확장성지원 OwFS 는수백 TB에서수십 PB에이르는대용량저장공간지원을목표로설계되었으며, 저장장치구축에소요되는비용을낮추기위하여 GFS 와같이다수의저가서버를활용하는접근방법을택하였다. 모든서버가파일접근요청을처리할수있기때문에용량의증가는곧성능의증가로이어지며, 몇몇파일서버만이요청을처리하는기존방식에비해파일접근성능을보다향상시킬수있다. 데이터가용성유지기존의고가저장장치와는달리 OwFS 는저가하드웨어를활용하기때문에개개구성요소의장애발 생확률이상대적으로높으며, 서버와디스크의수가증가할수록이는더욱문제가된다. 특히, 일반사용자를대상으로하는커뮤니티서비스의특성상데이터의유실은사용자감소및대외이미지저하로직결되므로서버나네트워크장애발생시에도데이터가유실되지않도록높은데이터가용성을지원해야한다. OwFS 는 GFS 나 Dynamo 와같이복제본을활용하여데이터가용성을확보하는방안을채택하였다. 관리편의성제공 OwFS 가실제서비스에적용될경우별도의인력이 OwFS 운용을담당하게되므로, 저장장치의관리편이성은 OwFS 개발초기부터매우강조되었다. OwFS 는서비스를중단하지않고저장장치의추가, 제거, 업그레이드가가능하도록설계되었으며, 관리자의개입없이자동적으로저장장치간부하를분산하는기능도제공된다. 또한 OwFS 를구성하는각서버의상태를모니터링하고, 장애발생을통지하는등의전용관리도구들도개발되었다. 고유한파일시스템 API 제공대부분의코드가내부에서직접개발되는웹응용의특성상표준 POSIX 파일시스템인터페이스의제공은불필요한것으로판단되었다. 대신 OwFS 는 POSIX 와유사한 OwFS 고유의파일시스템 API 와 OwFS 클라이언트라이브러리를제공한다. OwFS 를사용하기위해서기존의응용들이수정되어야하는부담은있지만, POSIX 파일시스템인터페이스를제공할필요가없게됨으로써커널수정이불필요하게되었으며, OwFS 개발시간도단축할수있게되었다. 2.2 파일시스템접근특성전술한바와같이 OwFS 는메일원문, 카페나블로그의첨부파일, 이미지, 음악및동영상파일등과같은불변 (immutable) 파일들의저장을목표로한다. 불변파일이란한번파일이생성되면더이상파일의내용이변경되지않는파일을의미한다. 이들불변파일들은인터넷서비스업체들이저장해야하는데이터의대부분을차지하며, 일반적인파일과는다른접근특성을가지고있기때문에이와같은특성을고려하여 OwFS 를최적화하는것이필요하다. OwFS 가대상으로하는불변파일들의접근특성을요약하면다음과같다. 첫째, 동영상을제외한대부분의불변파일들은크기가상대적으로매우작다. 이메일서비스의경우 95% 의메시지들이 55KB 미만이었으며, 98.5% 의메시지들도 100KB 미만에불과하였다. 따라서 OwFS 는매우 정보과학회지제 27 권제 5 호

3 많은수의작은크기파일들을효율적으로다룰수있어야한다. 둘째, 불변파일들은생성, 읽기, 삭제와같은세종류의주된연산에의해접근된다. 파일이생성될때에는순차적으로쓰여지며, 한번쓰여지고나면그내용이변경되지않는다. 또한파일이생성될때마다시스템에서고유한파일이름을부여하므로, 동일파일에대한동시쓰기요구도발생하지않는다. 읽기요청은해당파일이완전히생성된이후에만허용되며, 쓰기요청과는달리동일파일에대해동시읽기요구가있을수있다. 이러한특징들은 OwFS 에서데이터일관성유지를단순화하는데이용된다. 3. 관련연구 3.1 NAS(Network Attached Storage) NAS 방식은저장공간을제공하는 NAS 서버가 LAN 을통해 NFS 혹은 SMB/CIFS 와같은업계표준의네트워크파일시스템프로토콜을이용하여클라이언트와연결되는구조를가지고있다 [5]. NAS 방식은설치가쉽고, 이기종시스템지원이용이하다는장점이있으나확장성에제약이있고관리비용이크다는단점이있다. 특히, 저장용량을확장할경우부하분배를위해서는수동으로데이터를이동시키는작업이필요하며, 파일시스템을접근하는경로가정적으로결정되어있기때문에파일이동이클라이언트에투명하게이루어지기어렵다. 3.2 Coda Coda 는미국 CMU 대학에서개발된분산파일시스템이다 [6]. 서버나네트워크에장애가발생하여도서비스의중단없이클라이언트가원하는파일을접근할수있도록파일을볼륨 (volume) 단위로구성하고, 볼륨을두개이상의서버에중복하여저장하는방식을사용한다. 한볼륨이어떤서버에중복되어저장 되어있는지의정보는모든서버에분산되어관리된다. 볼륨이여러서버에중복해서저장되고, 일부서버나네트워크연결에장애가발생한사이다른서버의파일이갱신될수있기때문에 Coda 에서는여러서버에있는복제본간의일관성유지가가장큰부담중의하나이다. Coda 에서는각파일이나볼륨별로버전정보를관리함으로써일관성을유지하는데, 이와같은복잡한일관성유지방법은불변파일들을위해서는불필요하다. 또한 Coda 는볼륨의복사본을분산시키는자동화된정책을가지고있지않으며, 기존의서버중하나가새로운서버로대체되더라도자동으로이전의서버가가지고있던내용을복구하는등의기능이지원되지않는다. 3.3 Lustre Lustre 는오브젝트기반의분산파일시스템으로확장성이뛰어나기때문에고성능컴퓨팅환경에서많이사용되고있다 [7]. 대규모의 I/O를효과적으로처리하기위해 Lustre 에서는파일의메타데이터와데이터를독립시켜관리한다. 파일에대한 I/O를수행할경우, 클라이언트는중앙의메타데이타서버 (MDS) 로부터파일에대한정보만을얻은다음분산되어있는데이터서버들에게직접 I/O를요청한다그러나 Lustre 는 MDS 내의로컬파일시스템을이용하여메타데이타를관리하기때문에, 파일의개수가많을경우 MDS 에많은부하가걸리게된다. 또한장애발생에대응하기위해서는시스템구축비용이증가하고, 자동으로부하를분산하는기능도제공되지않는다. 3.4 GFS(Google File System) GFS 는구글이검색엔진을비롯한자사의다양한서비스를위해개발한분산파일시스템이다 [4]. GFS 는하나의마스터서버와다수의청크서버 (chunk server) 표 1 주요저장시스템의특징비교 NAS Coda Lustre GFS OwFS 파일서비스구현 Kernel-level User-level Kernel-level User-level User-level POSIX API 지원 O O O X X 마스터서버의유무 X X O O O 마스터서버장애대응 HA failover HA failover HA failover 데이터서버장애대응 Replication HA failover Replication Replication 복제단위 Volume Chunk Owner 자동장애검출및복구 O O 자동데이터이동 X X X O O 주요용도범용유닉스환경 고성능컴퓨팅환경 큰파일저장 다수의불변파일저장 OwFS: 대규모인터넷서비스를위한분산파일시스템 79

로구성되어있다. 하나의파일은고정된크기의청크단위로나뉘어서청크서버에저장되고, 장애에대응하기위하여각각의청크는기본적으로 3개의서로다른청크서버에복제된다. 마스터서버는파일시스템의이름공간 (namespace) 과청크의위치정보등을관리하는데, Lustre 와는달리이들정보는메모리에저장된다.

4 로구성되어있다. 하나의파일은고정된크기의청크단위로나뉘어서청크서버에저장되고, 장애에대응하기위하여각각의청크는기본적으로 3개의서로다른청크서버에복제된다. 마스터서버는파일시스템의이름공간 (namespace) 과청크의위치정보등을관리하는데, Lustre 와는달리이들정보는메모리에저장된다. 그러나파일의개수가많아질경우모든파일에대한메타데이터를마스터서버의메모리에유지시키기에는무리가있다. 표 1은이들시스템의주요특징을 OwFS 와비교한것이다. 4. OwFS 구조 4.1 전체적인구조및동작 OwFS 의전체적인구조는그림 1에보이는바와같다. GFS 와유사하게 OwFS 는하나의메타데이터서버 (MDS: MetaData Server) 와다수의데이터서버 (DS: Data Server) 들로구성된다. MDS 는파일의저장공간과관련된메타데이터를관리하고, DS 서버의상태를감시하여장애상황에대응한다. DS는파일의저장을담당하고있어, 파일에대한연산은실제로 DS에서수행된다. 메타데이터서버와데이터서버는모두리눅스상에서사용자수준의프로세스로구현되었으며, 클라이언트프로그램은 OwFS 클라이언트라이브러리와링크되어사용된다. 현재 OwFS 클라이언트라이브러리는 C와 Java 버전으로제공되며, 리눅스와윈도우환경을모두지원한다. OwFS 로부터파일다운로드를지원하기위한 Apache 모듈도지원된다. OwFS 가 GFS 와구별되는가장큰차이점중의하나는파일저장공간을 owner 라는단위로묶어서관리 한다는점이다. 서로관련있는파일들은동일한 owner 에속하게되며, 어떤파일을어떤 owner에저장할것인지의여부는전적으로 OwFS 를사용하는응용에의해결정된다. 예를들어, 이메일서비스의경우 owner는각각의사용자계정에대응될수있으며, 해당사용자가가지고있는메일메시지는각 owner 에속한파일들로사상될수있다. 카페나블로그서비스의경우에는 owner가각각카페나블로그의고유식별자에대응되도록하는것도가능하다. OwFS 에서각각의 owner는복제본을유지하는단위가된다. OwFS 는각 owner에대해기본적으로 3개의복제본을유지하며, 이때동일한 owner에속하는파일들은모두동일한 3대의 DS에저장된다. OwFS 에서 owner라는개념을사용하는주된이유는 OwFS 가다른파일시스템들과는달리매우많은수의파일들을다룰수있도록설계되었기때문이다. 만일개개의파일마다해당파일의메타데이터를 MDS 에저장한다면 MDS 의부담이너무커지게되고, MDS 가성능향상의장애요인이될수있다. 반면 OwFS 는응용의필요에따라적절한수의 owner를생성하고, 해당 owner에대한복제본위치정보만을 MDS 에유지함으로써파일수의증가에따른 MDS 의부담을경감시킨다. OwFS 에서파일을읽는과정을간단히설명하면다음과같다. 먼저, 응용프로그램이읽고자하는파일의 owner 명을 MDS 에게전달하면, MDS 는해당 owner 의아이디와 3개의복제본위치를알려준다. 그러면, 클라이언트라이브러리는복제본을저장하고있는 3개의 DS 중임의의 DS를접근하여파일을읽게된다. 파일을쓰는경우도유사하게진행되지만, 읽기의경우 그림 1 OwFS 의구조 정보과학회지제 27 권제 5 호

5 와는달리쓰기의경우에는세개의 DS 모두에게쓰기요청을전달한다. 4.2 MDS MDS 는모든 owner들의최신복제본위치와 DS들의상태정보를관리한다. OwFS 에서는 owner 에대해열기 (open), 닫기 (close), 생성 (create), 삭제 (delete), 삭제취소 (undelete), 이름변경 (rename), 리스트조회 (read_owner_list) 등의연산을제공하는데, 이들연산들은모두 MDS 에의해처리된다. 또한, 장애복구나부하분산을위해복제본을이동하는작업에도 MDS 가관여하게된다. 각각의 DS는주기적인 heartbeat 메시지를이용하여자신의정상동작여부를 MDS 에게보고하며, MDS 는이를통해 DS의장애유무와 CPU, 네트워크, 로컬디스크의사용량등을모니터링한다. MDS 가관리하는각종정보들은 MySQL 에의해데이터베이스테이블로관리된다. 이것은 DBMS 를사용하는것이 Lustre 와같이로컬파일시스템에정보를저장하는것보다측정결과우수한성능을보였기때문이다. 또한 DBMS를사용하게되면백업및복제가용이하고, 메타데이타에대한각종조회및변경작업을 SQL 질의문을통해손쉽게행할수있다는이점이있다. MDS 는 2개의백업서버에의해 3중으로보호되며, 공유스토리지와 MySQL 에서제공하는비동기복제를이용하여장애에대비하고있다. 4.3 DS DS는파일을저장하고, 파일에대한각종연산을처리하는서버이다. OwFS 는파일에대해읽기 (read), 쓰기 (write), 위치변경 (lseek), 삭제 (delete), 삭제취소 (undelete), 이름변경 (rename), 존재여부검사 (exists), 파일정보검사 (stat), 파일리스트조회 (readdir) 등의연산을제공한다. 파일들은 XFS와같은리눅스파일시스템을이용하여저장된다. Owner 별로별도의디렉토리가생성되며, owner 에속하는파일들은해당 owner 디렉토리하부에저장된다. 또한 DS는자신이관리하는 owner 의상태정보를메모리에캐싱하여연산처리속도를높인다. DS는그수가많기때문에장애발생확률이상대적으로높다. DS에장애가발생할경우복제본수의감소로가용성이저하되고, 복제본간일관성이유지되지않을수있으므로신속하고정확한대처가필요하다. DS의장애발생시대처방안에대해서는 5절에서자세히살펴보기로한다. 4.4 FlexRPC 클라이언트와 MDS, DS는모두 FlexRPC[8] 라불리는전용의 RPC(Remote Procedure Call) 계층을이용하여통신한다. OwFS 개발초기에는 Coda에서사용하는 RPC2 계층이나리눅스에서기본적으로제공되는 RPC 계층을멀티스레드환경으로확장하여사용하려는시도를하였으나, 모두 OwFS 에서요구되는기능들을제공하기에는한계가있어새로운 RPC 계층을개발하였다. FlexRPC 계층의특징은다양한호출형태를지원한다는점이다. 가장기본적인호출형태는기존의 RPC 에서와같이하나의클라이언트가하나의서버와통신하는단일호출 (single call) 이다. OwFS 에서는동일한파일을서로다른 DS에복제하기위하여하나의클라이언트가다수의서버에게같은내용의매개변수를이용하여호출할필요가있는데이를멀티캐스팅 (multicasting) 호출이라부른다. 멀티캐스팅호출은클라이언트가모든서버에게병렬적으로매개변수를전송하는병렬멀티캐스팅 (parallel multicasting) 호출과매개변수를여러서버를거쳐파이프라인형태로전송하는직렬멀티캐스팅 (serial multicasting) 호출 [9] 로다시세분화될수있는데 FlexRPC 에서는이러한두가지종류의멀티캐스팅호출형태를모두지원한다. 병렬멀티캐스팅의경우빠른응답시간을가질수있는반면네트워크대역폭을많이사용하게되고, 직렬멀티캐스팅은네트워크사용량을분산시킬수있지만상대적으로긴응답시간을가진다. FlexRPC 계층은 TCP와 UDP 프로토콜을모두지원하며필요에따라일부는 TCP 프로토콜을, 다른일부는 UDP 프로토콜을사용하는것이가능하다. 특히, UDP 프로토콜을사용할경우에는서버측에응답캐시 (response cache) 를두어 at-most-once 시맨틱을보장하며, TCP 프로토콜을사용할경우에는핸들캐시 (handle cache) 를두어매번연결을새로설정하는오버헤드를감소시킨다. 이밖에도 FlexRPC 계층은클라이언트와서버에서모두멀티스레드환경을지원하며, 기존의 SunRPC 와비교하여 IDL(Interface Description Language) 수준에서호환되고제공되는인터페이스도거의유사하다. 5. OwFS 데이터서버장애대응방법 5.1 장애유형 OwFS 에서는장애유형을일시적장애와영구적장애의두가지로분류하고, 각각의장애유형에대해 OwFS: 대규모인터넷서비스를위한분산파일시스템 81

그림 2 DS의복제본상태변화서로다른대응방법을사용한다. 일시적장애란네트워크장비의일시적인오동작, 관리자에의한시스템재시작과같이일시적으로 DS가파일연산요청에응답하지못하는경우를의미한다. 일시적장애가해소된후에는장애발생직전의데이터를이용할수있으므로, OwFS 는복제본복구 (replica recovery) 를통하여일시적장애가있던동안업데이트된파일의일관성을유지시킨다.

6 그림 2 DS의복제본상태변화서로다른대응방법을사용한다. 일시적장애란네트워크장비의일시적인오동작, 관리자에의한시스템재시작과같이일시적으로 DS가파일연산요청에응답하지못하는경우를의미한다. 일시적장애가해소된후에는장애발생직전의데이터를이용할수있으므로, OwFS 는복제본복구 (replica recovery) 를통하여일시적장애가있던동안업데이트된파일의일관성을유지시킨다. 반면영구적장애는하드디스크의고장, 파일시스템오류, 커널패닉, 전원공급장치고장등과같이해당 DS가정상적으로서비스를지속할수없는심각한상황을의미하며, 이경우에는장애발생직전의데이터를이용할수없는경우가대부분이므로 OwFS 는복제본이동 (replica migration) 을통해다른 DS에새로운복제본을생성한다. 일시적인장애와영구적인장애는장애지속시간이나관리자의판단에의해구분된다. 5.2 복제본상태변화그림 2는일시적 / 영구적장애검출과해소에따른복제본의상태변화를요약한그림이다. 각각의복제본은어느순간 N (Normal), M(Migrating), R(Recovering), F(Fail) 중하나의상태에있게된다. N 상태는정상적인복제본을의미하고, F 상태는복제본을저장하고있는서버가장애에빠져해당복제본을접근할수없음을뜻한다. 만일발생한장애가일시적인장애였다면, 장애가해소된후해당복제본은 R 상태로전이하고, 복제본복구과정을시작한다. 복제본복구과정이완료되면다시정상상태인 N 상태로전이한다. 반면발생한장애가영구적인장애인경우, 해당복제본의상태는 M 상태로바뀌고 MDS 는복제본이동과정을시작한다. 복제본이동이정상적으로완료되면해당복제본의상태는다시 N 상태로돌아간다. 복제본복구나이동중관련된 DS가다시장애 에빠질수있으며, 이경우해당복제본은다시 F 상태로빠지게된다. 각 owner의상태는해당 owner의복제본상태를이용하여표시한다. 예를들어어떤 owner의상태가 O 1 = [N, N, N] 와같이표시되었다면, 이것은 owner O 1 의모든복제본상태가정상임을표시한다. 반면, 어떤 owner 의상태가 O 2 = [N, N, F] 라면이는 owner O 2 의한복제본이장애로인해가용하지않음을의미한다. OwFS 의초기버전에서는모든 owner의복제본상태정보또한 MDS 가 DB 형태로저장하도록하였다. 그러나이와같은방법은어떤 DS가장애에빠질때마다해당 DS가저장하고있는모든복제본의상태정보를 N F 로변경하고, 복제본복구를시작하게되면다시복제본의상태를 F R 로변경하는등의빈번한복제본상태업데이트를필요로한다. 보통하나의 DS가저장하고있는 owner의수는수십만개이상이되기때문에수많은 owner들에대한복제본상태업데이트는상당한오버헤드를수반하며, 결과적으로장애가발생할때마다 MDS 의성능을급격히저하시키는요인이되었다. 이와같은문제점은 MDS 에서개개복제본의상태정보를제거하고, DS의상태정보만을관리함으로써해결되었다. 개선된방법에서는서버의상태를통해각복제본의상태를유추해내는방법을사용한다. 예를들어, DS의상태가 N이나 F 라면, 이것은해당 DS에저장되어있는모든복제본이 N이나 F 상태와같다는것을의미한다. DS 의상태가 R이나 M인경우에는약간의주의가필요한데, 그것은 DS에저장되어있는복제본중일부의복제본은이미복구가완료되거나 (R 상태인경우 ) 복제본이동에참여하지않아 (M 상태인경우 ) N 상태로남아있을수있기때문이다. 그러나이경우에도해당 DS에문의하면특정복제본의정확한상태를알아낼수있기때문에동작에는문제가없게된다. 5.3 복제본복구일시적인장애에빠졌다가돌아온경우 DS는복제본복구과정을수행한다. 복제본복구의목표는해당 DS가일시적인장애에있는동안발생한변경을반영하여다른복제본과의데이터일관성을유지하는것이다. 일시적인장애로부터의복구를위해 OwFS 는로깅방법을사용한다. 어떤복제본이 F 상태에빠진경우, 다른정상상태의복제본들은 MO-LOG(Missed Operations Log) 라불리는로그를작성하여그동안일어 정보과학회지제 27 권제 5 호

7 난업데이트를기록한다. 남아있는정상상태의복제본중하나가또다른장애에빠질수있기때문에, MO-LOG 는모든 N 상태의복제본에의해기록되어야한다. 일시적인장애가해소되면 DS는 MDS 에게자신이복제본복구과정을개시했음을알리고, F R 로의상태변경을요청한다. 그리고는자신이저장하고있는모든 owner에대해정상상태의복제본을소유하고있는서버를접근하여 MO-LOG 를수신하고, 이를재연하는과정을반복한다. 한편 MO-LOG 를수신하여재연하는동안해당 owner 에대해새로운업데이트요청이수신될수있다. MO- LOG 가완전히재연되기전까지새로도착하는업데이트요청은바로처리될수없기때문에 OwFS 는이들을 DO-LOG(Delayed Operations Log) 라불리는별도의로그에임시로저장한다. DO-LOG 는 MO-LOG 의재연이완료된후이어서처리되며, 모든 owner에대해이과정이완료되면해당 DS는자신의상태를 N 상태로변경한후복제본복구과정을종료한다. 5.4 복제본이동어떤 DS가영구적인장애에빠진것으로판단되면, 해당 DS에속한복제본은더이상가용하지않으므로일정한복제본수를유지하기위하여 MDS 는복제본이동과정을개시한다. 복제본이동은각대상 owner에대해새로운복제본을저장할 DS의위치를결정하고, N 상태의복제본으로부터파일을복사함으로써이루어진다. 남아있는복제본의수가적은 owner 일수록우선적으로복제본이동이행해지며, 시스템의성능을유지하기위해하나의 DS는동시에두개이상의서로다른복제본이동에참여하지않도록제한한다. 필요에따라관리자는특정복제본을임의의위치로이동시킬수있으며, 특정 DS에저장공간이부족해질경우자동으로부하를분산하는기능도유사한방법을사용하여구현된다. OwFS 에서는복제본의상태에따라클라이언트의동작이결정된다. 예를들어, 읽기의경우 N 상태의정상적인복제본에게만읽기요청을보내며, 쓰기의경우에는 F 상태가아닌모든복제본에게쓰기요청을보낸다. 따라서클라이언트는복제본의상태를정확히아는것이중요하게된다. 그러나클라이언트와무관하게 DS는언제나장애에빠질수있기때문에현재클라이언트가알고있는복제본의상태가정확한상태라고볼수는없다. 마찬가지로, MDS 가 heartbeat 통신을통하여 DS의장애여부를파악한다고해도그정보가최신상태라고볼수는없다. OwFS 에서는상태매칭 (state matching) 이라불리는기법을사용하여복제본상태동기화를행한다. 상태매칭은클라이언트가특정 owner 에대한연산을 DS에요청할경우, 자신이알고있는 owner의현재상태를 RPC를통해함께실어보내는방법이다. 만일연산을요청받은 DS에서도해당 owner 에대해동일한상태를알고있다면연산은성공한다. 그러나상태매칭에실패했을경우 DS는 MDS 로부터해당 owner 에대한최신정보를갱신하고, 그래도상태매칭이이루어지지않으면클라이언트에게상태매칭실패를알린다. 이를받은클라이언트는자신도해당 owner 의최신정보를 MDS 로부터갱신한다음동일한연산을재시도한다. 그림 3은 DS의복구를전후하여상태매칭을통해복제본상태를동기화하는예를보인것이다. 어떤 owner O 의복제본이 DS1, DS2, DS3 세대의서버에저장되어있을때, 이중 DS3가현재 F 상태에있고, MDS 와클라이언트, DS1, DS2 모두이사실을알고있다고하자 (Phase 1). DS3 에일시적인장애가해소되면 DS3 는 MDS 에게복제본복구과정을시작했음을알리고, 이과정에서 DS3와 MDS 의상태는 [ N, N, R ] 로변경된다. 그러나클라이언트와 DS1 및 DS2 는아직이사실을모르고있기때문에클라이언트는업데이트 5.5 복제본상태동기화 그림 3 상태매칭의예 OwFS: 대규모인터넷서비스를위한분산파일시스템 83

8 요청을 DS1과 DS2에게만전송하게되고, DS1 과 DS2 는아직 DS3가 F 상태에있다고판단, MO-LOG 를계속기록하게된다 (Phase 2). 한편 DS3는복제본복구를위하여 DS2에게 MO-LOG 를요청한다. 이과정에서 DS2는 DS3가 R 상태로전이하였음을알고자신도 O의상태를 R로변경한다. 이사실을모르는클라이언트는여전히 O의상태를 [ N, N, F ] 로알고업데이트요청을전송하게되나, DS2 에의해상태매칭을실패하게된다 (Phase 3). 상태매칭을실패한클라이언트는 MDS 로부터 O의상태를새로갱신하여요청을재시도하게되지만, 이번에는아직까지 DS3 의상태가변경된줄모르는 DS1에의해상태매칭이실패하게된다 (Phase 4). 상태매칭을실패한 DS1가 MDS 로부터 DS3의상태를갱신하고나면관련된모든서버가 O 에대해모두동일한 [ N, N, R ] 상태를갖게되고, 이후의연산은상태매칭의실패없이정상적으로수행된다. 상태매칭기법은장애가발생하지않는대부분의정상적인경우상태정보를 RPC에함께실어보내는것외의다른오버헤드를수반하지않는다. 5.6 복제본배치정책의개선 OwFS 초기버전은하나의 owner 가생성될때, 해당 owner의복제본을디스크사용률과워크로드가낮은 3개의 DS 서버에할당하였다. OwFS 에서는 DS가 3대이상고장나면일부 owner에대해서는데이터가용성을보장할수없다. 따라서수백대규모로 OwFS 를구성하는환경에서네트워크스위치또는전원에장애가발생하면, 3개의복제본을모두접근할수없는 owner 수가많아질수있다. 이러한문제점을보완하기위해네트워크스위치나전원장애발생시접근할수없는 DS 서버들을그룹별로나누어 DS 그룹당 1개의 owner 복제본을가지도록복제본배치정책을변경하였다. DS 서버장애가동시에 DS 그룹 3개이상에걸치지않는다면, DS 서버장애수와관계없이적어도 1개의정상복제본이존재하므로데이터가용성이향상된다. DS 그룹별복제본배치정책은장애에대한데이터가용성을높이지만, DS 서버의영구적장애로인한복제본이동의성능은저하시킨다. 그이유는특정 DS 그룹내의한 DS가고장나면해당 DS가가지고있던복제본들을다시생성해야하는데, 새로운복제본을저장해야할 DS 서버후보군의수가 DS 그룹제약조건에의해줄어들기때문이다. 따라서동시에수행할수있는복제본이동작업개수가줄어들어복제본이동에걸리는시간이늘어난다. 복제본이동의성능을 저하시키는또하나의요소는네트워크스위치간전송지연시간이다. 복제본을재생성하기위해서는다른 DS 그룹내의서버에서복제본을읽어와야하는데, 데이터전송시간은동일네트워크스위치내의 DS 서버간통신에비해약간증가하게된다. 6. NHN 서비스적용현황 OwFS 는 2006년개발이시작되었으며, 2007년하반기부터네이버와한게임서비스에적용되어현재까지안정적으로운용되고있다. 네이버서비스에서는사용자들에의해업로드 / 다운로드되는파일서비스에주로사용되고있으며, 한게임서비스에서도게임이용자들에의해발생되는게임데이터를저장하는용도로사용되고있다. OwFS 를기존서비스들에적용하는경우새로운 API 를익혀야하는점에대한개발자들의부담과코드수정으로인한새로운버그발생의우려가가장큰문제점으로대두되었다. 그러나이와같은점에도불구하고파일시스템의변경으로인한코드수정은대부분 2주이내로완료가능하였다. 설계초기부터 OwFS 를가정하고개발하는신규개발서비스의경우에는개발자로부터의피드백이좋았으며, OwFS 적용으로인한추가적인개발기간의증가는없었다. OwFS 는기존저장시스템으로사용되던 NAS 방식보다총소유비용 (TCO) 면에서우수하기때문에저장장치구축비용을절감하는효과가있을것으로기대된다. 이에따라 NHN 서비스에 OwFS 를적용하려는움직임은확대되고있고, 신규로개발되는네이버 / 한게임서비스중대규모의저장공간을필요로하는경우는대부분 OwFS 기반으로구축될것으로예상된다. 7. 결론지금까지대규모인터넷서비스를위해개발된분산파일시스템 OwFS의설계목표및전체적인구조, 장애대응방법, NHN 서비스적용현황등에대해간략하게살펴보았다. OwFS 의공동개발은산학협동의모범적인성공사례로써, OwFS 분산파일시스템은현재 NHN 내부표준파일시스템의하나로자리매김하고있다. OwFS 는지속적으로새로운기능이추가되고있으며, 그적용범위또한확대되어갈전망이다. 인터넷보급의증가로다양한종류의신규인터넷서비스들이하루가다르게쏟아져나오고있다. 날로심화되는글로벌경쟁에서살아남기위해서는새로운 정보과학회지제 27 권제 5 호

인터넷서비스와비즈니스모델의발굴도중요하지만, 이에못지않게수천만명이상의사용자들에게안정적인서비스를지속할수있는대규모서버및스토리지시스템기술또한매우중요하다. 현재우리나라의컴퓨터시스템기술은매우취약한상황이며, 관련인력도부족한실정이다. 국내인터넷서비스업체들이구글이나야후등과같은글로벌업체들과경쟁하기위해서는이제부터라도시스템관련기술과인력을확보하기위해노력을경주해야할것으로보인다.

참고문헌 [1] International Data Corporation (IDC), The Diverse and Exploding Digital Universe, 2007 & 2008. [2] S. Ghemawat, H. Gobioff, and S.-T.

9 인터넷서비스와비즈니스모델의발굴도중요하지만, 이에못지않게수천만명이상의사용자들에게안정적인서비스를지속할수있는대규모서버및스토리지시스템기술또한매우중요하다. 현재우리나라의컴퓨터시스템기술은매우취약한상황이며, 관련인력도부족한실정이다. 국내인터넷서비스업체들이구글이나야후등과같은글로벌업체들과경쟁하기위해서는이제부터라도시스템관련기술과인력을확보하기위해노력을경주해야할것으로보인다. 감사의글 OwFS 개발에참여한 KAIST 컴퓨터구조연구실의정욱, 이대우, 박은지, 이영재, 김상훈연구원과 NHN ( 주 ) 가상화플랫폼개발팀의전성원수석, 주윤철수석, 양명아대리에게감사드립니다. 참고문헌 [1] International Data Corporation (IDC), The Diverse and Exploding Digital Universe, 2007 & [2] S. Ghemawat, H. Gobioff, and S.-T. Leung, The Google File System, Proceedings of the 19th ACM Symposium on Operating Systems Principles (SOSP), pp , [ 3 ] G. DeCandia et al., Dynamo: Amazon s Highly Available Key-value Store, Proceedings of the 21st ACM Symposium on Operating Systems Principles (SOSP), pp , [4] 김태웅, 사용자를위한보이지않는노력, 대용량분산파일시스템, NHN Story, com/story.nhn?story_id=86 [ 5 ] W. Singer, NAS and iscsi Technology Overview, SNIA Technical Tutorials, Fall [6] J. H. Howard et al., Scale and Performance in a Distributed File System, ACM Transactions on Computer Systems (TOCS), 6(1):51-81, [ 7 ] Cluster File Systems Inc. Lustre: A Scalable, High Performance File System, [ 8 ] Sang-Hoon Kim, Youngjae Lee, and Jin-Soo Kim, FlexRPC: A Flexible Remote Procedure Call Facility for Modern Cluster File Systems, Proceedings of the 9th IEEE International Conference on Cluster Computing, September [ 9 ] Sang-Hoon Kim, Jin-Soo Kim, and Seungryoul Maeng, Modeling and Evaluation of Serial Multicast Remote Procedure Calls (RPCs) IEEE Communications Letters, 13(4): , 김진수 1991 서울대학교컴퓨터공학과공학사 1993 서울대학교컴퓨터공학과공학석사 1999 서울대학교컴퓨터공학과공학박사 1998~1999 IBM T. J. Watson Research Center, Academic Visitor 1999~2002 한국전자통신연구원선임연구원 2002~2008 KAIST 전산학과부교수 2007~2008 삼성전자고문 2008~ 현재성균관대학교정보통신공학부부교수관심분야 : 운영체제, 스토리지시스템, 내장형시스템, 분산시스템 jinsookim@skku.edu 김태웅 1993 서울대학교컴퓨터공학과공학사 1995 서울대학교컴퓨터공학과공학석사 2000 서울대학교전기, 컴퓨터공학부공학박사 2000~2000 서울대학교컴퓨터신기술공동연구소특별연구원 2000~2006 데이터코러스 ( 주 ) 기술이사 2006~ 현재 NHN( 주 ) 가상화플랫폼개발팀장관심분야 : 분산파일시스템, 운영체제, 가상머신, 스토리지가상화 taewoong.kim@nhn.com OwFS: 대규모인터넷서비스를위한분산파일시스템 85

클라우드스토리지서비스 N 드라이브 NHN Business Platform 저장시스템개발팀 / 전성원 2011 NHN Corporation

클라우드스토리지서비스 N 드라이브 NHN Business Platform 저장시스템개발팀 / 전성원 2011 NHN Corporation 목차 I. N 드라이브서비스를위해풀어야할숙제들 II. NHN 파일스토리지 OwFS III. OwFS 적용으로얻은이점 N 드라이브서비스를위해풀어야할숙제들 N 드라이브서비스 N 드라이브 : 규모 l 30GB C: 드라이브 N: