CS 전공/리뷰2012. 1. 17. 23:06

지난 40년간 마그네틱 디스크는 가장 주요한 저장공간이었다.  대용량 데이터들은 디스크에 기록되고 읽혀졌으며, 상대적으로 용량이 작았던 메인 메모리 때문에 데이터 버퍼링 및 메모리의 효율적 사용이 매우 중요하였다.
때문에 Jim Gray의 5분의 규칙(five-minute rule) 과 같이 데이터 버퍼링 또는 캐싱에 대한  경험적 규칙이 얘기되어 왔다.  실제 디스크에 기반한 DBMS에서도 이 버퍼의 성능이 엄청나게 큰 영향을 미쳐왔다. 
 

5분의 규칙은 1987년, 짐 그레이가 SIGMOD Record에서 언급한 것[각주:1]으로 디스크와 메모리의 접근 시간과 용량을 간단히 수식화하여 약 5분 내 다시 참조될 데이터는 메모리에 올려두는 것이 좋다라고 언급한 것이다.
해당 논문이 쓰여지고 10년뒤 97년에 그레이는 다시 그당시의  저장 계층의 특성에 의해 이 규칙이 어떻게 변화되었는지 다시 소개[각주:2]하였고, 또다시 10년 뒤 2008년에는 고츠 그라페(Goetz Graefe)가 SSD의 출현에 의해 이 규칙이 어떻게 변화되는지를 소개하였다[각주:3].(2007년에 짐 그레이가 실종되서 그는 쓰지 못하였다.)  



디스크는 세월이 지남에 따라 그 저장용량(capacity)은  엄청나게 개선되어 왔다. 하지만, 저장 용량에 비해 접근 지연시간(latency)은 크게 개선되지 못하여 왔다. 아래 표를 보자.
 

 

이 표를 보면 디스크의 용량은 80년대 중반에 30MB인것이 2009년에는 500GB로 약 16,667배정도로 크게 늘어났다. 지금은 데스크탑의 경우 하드디스크의 용량이 1TB는 기본이다.  전송속도 또한 개선되었으나, 저장용량에 비해서는 크게 개선되지 못하였다. 가장 개선이 못된 것은 접근 지연시간이다.  마그네틱 구조의 특성상 회전하는 디스크 위에서 디스크 암이 움직여야 하므로 랜덤 I/O를 위핸 접근 지연시간은 현 HDD 구조에서는 피할 수 없는 특성이다. 그리고, 이것은 크게 개선되지 못하였다. 

따라서 저장용량을 bandwidth로 나누어보면, 용량에 비해 bandwidth 개선이 턱없이 부족함을 보이는 것을 확인할 수 있다.  80년대 중반 15초면 다 읽을 수 있던 것을 지금은 직렬 읽기만 해도 5,000초가 걸리고, 랜덤 읽기인 경우에는 약 58일이라는 엄청난 시간이 요구한다.

이에 따라 연구자들은 기존의 HDD를 대체하기 위해 SSD를 연구해 왔고, SSD는 이제 울트라북을 포함한 여러 PC에 널리 이용되고 있다. 하지만, 데이터센터 스케일에서도 SSD를 적용할 수 있을까? 
 

스탠포드대의 연구자들은 램클라우드라는 프로젝트를 통해 SSD나 디스크보다 이제는 DRAM을 주요 저장공간으로 활용해야 한다고 역설한다.  이들은 인터넷 스케일 서비스의 제공에 있어 HDD를 전혀 이용하지 않고, 수백, 수천대의 노드 컴퓨터들을 연결하여 이들의 메인 메모리들에 모든 데이터를 저장, 관리하는 것을 목표로 한다.

  이러한 목표를 제시한 근거에는 여러가지가 있지만, 우선 위 표를 다시 보면 
 짐 그레이의 5분의 규칙에 따라 5분 이내 재참조될 데이터는 메모리에 올려두었던 것이 이제는 30시간 내에 재참조되는 데이터이라면, 메모리에 올려두는 것이 더 낫다라는 결과를 얻게 되었다는 점이다. 즉, 현재는 가급적이면 모든 데이터를 메모리에 올려두는 것이 효과적이라는 것이다. 사실 이러한 현실은 이전의 Jim Gray의 예측과도 일치한다. 그는 예전에 "Memory becomes disk, disk becomes tape, and tape is dead."라 언급하였다.
 즉, 이제는 메모리를 이전의 디스크가 점유했던 주요 저장소로서 활용하고 디스크는 백업과 아카이빙을 위한 용도로 쓰자는 것이다. 
(사실 테입이 완전히 사라진 것은 아니다. 아직 테입은 여러 데이터 센터에서 데이터 백업의 마지막 보루로 사용되고 있다.) 
 
메모리를 디스크처럼 쓰는 경우 가질 수 있는 많은 장점이 있다. 우선 접근지연시간(latency)가 현격하게 줄어든다. 현재의 데이터 센터를 통한 인터넷 서비스들은 인터넷-스케일이라는 규모가 큰 request들을 처리하는 것을 목적으로 한다. 때문에, 단일 노드로 구성되지 않고 데이터 센터에 많은 노드들을 네트워크로 연결하고 이를 통해 부하를 분산하는 분산 시스템이라는 특징을 가진다. 또한, 웹 서비스와 해당 서비스가 처리/제공하는 데이터가 서로 다른 노드에 위치하는 구조로 인해 접근지연시간이 단일 시스템 구조보다 느리다. 메모리를 디스크처럼 쓰는 경우 이러한 환경에서도 접근지연시간을 마이크로 세컨드 단위로 줄일 수 있다.
SSD를 디스크 대신 쓰는 경우에도 접근지연시간을 크게 줄일 수 있을 것이다. 하지만 저자들은 SSD의 접근지연시간은 디스크에 비해 훨씬 빠르지만, 그렇다하더라도 SSD보다 DRAM의 접근 지연시간 특히 쓰기지연시간이 훨씬 빠르므로 DRAM이 보다 경쟁성이 있다고 저자들은 얘기한다.
아래 그림은 디스크 드라이브, 플래시 메모리오 메모리의 특징을 그림으로 도식화한 것이다.
그림에서 보면 가장 덜 빈번하고, 한번에 요구되는 데이터 량이 큰 경우에는 디스크가 가장 경쟁력이 있고, 작은 크기의 데이터에 대한 매우 빈번한 질의에 대해서는 DRAM이 경쟁력이 있다. 그리고, 이들간의 경계는 시간이 지남에 따라 위쪽으로 이동하는 경향을 보인다. 이러한 경계의 이동은 DRAM의 경쟁력이 갈수록 커짐을 의미한다. 


 낮은 접근지연시간은 또한 온라인 트랜잭션 처리 비용을 줄이는데 큰 도움을 준다. 
예를 들어 일관성을 보장하는데 드는 비용, 즉 특정시간에 동시 수행되는 트랜잭션의 수(overlapping transactions)를 O라고 할 때 이는 새 트랜잭션의 도착비율(arrival rate) R과 각 트랜잭션의 운용기간(duration) D의 곱으로 간략히 표현할 수 있다.   O ~ R*D .
동시 수행되어야  할 트랜잭션의 수가 많을 수록 그만큼 트랜잭션들의 일관성을 보장하기위한 비용은 더 높아질  것이다. 
R 즉 새 트랜잭션의 도착 비율은 시스템의 스케일이 커가면서 계속 커지게 된다.
하지만, D 각 트랜잭션의 운용기간은 접근지연시간이 낮아짐에 따라 크게 개선되며 따라서 동시수행되는 트랜잭션 수를 줄어줄 수 있다. 사실 이러한 아이디어는 이전부터 메모리 상주형 DBMS(memory-resident DBMS 또는 in-memory DBMS)라는 형태로 구현되어 왔다. 하지만, 메모리 상주형 DBMS가 단일 또는 몇개의 노드를 이용하는 것에 국한되었던 것에 비해 램클라우드는 최소 수백대의 노드들의 메모리를 하나의 virtual storage로 보고 여기에 데이터를 저장시킨다는 점이 차이가 있다.

그렇다면 디스크 전체를 메모리로 대체하는 경우 그 비용은 어떨까? 비현실적이지는 않을까?
여기에 저자들이 조사한 간단한 통계정보가 있다.
 


2009년 당시 Amazon과 UA에서의 데이터량과 그당시의 메모리 가격을 가지고 해당 데이터를 모두 메모리에 얹기 위해서 소요되는 비용을 계산해 보았더니, Amazon의 경우 적게는 2.4만불에서 24만불 정도가 소요될 거라 한다. UA의 데이터는 그보다 더 작을 것이라 한다. 
즉, 메모리는 HDD나 SSD에 비해 빠를 뿐더러 I/O집중인 작업에 보다 싸면서 효과적일 수 있다는 것이다.

그렇다면 메모리 캐싱하고 이 램클라우드하고는 어떻게 틀린가? 인터넷 규모의 서비스를 제공하는 ISP들은 Memcached와 같은 분산 메모리 캐싱을 지원을 한다.  2009년 페이스북은 약 4,000개의 MySQL 서버를 이용해서 데이터 요청을 분산하였다 한다. 작업부하의 분산은 페이스북 자체의 코드로 이루어졌다고 한다. 그러다 이또한 바로 한계에 봉착해서 2,000개의 memcached 를 투입하였다고 한다. 
사실 램클라우드는 인터넷 규모의 서비스 제공에 있어 확장성(scalability)을 제공하기 위해 분산 메모리 구조를 지원한다는 점이서는 memcached와 같은 기존 분산 캐싱 기술들과 크게 유사해 보인다. 차이점은 램클라우드는 캐싱이 아닌 아예 데이터를 통채로 메모리에 올리겠다는 것이다. 페이스북 사례와 같은 경우에는 캐쉬된 데이터와 MySQL에 저장된 실 데이터 간의 불일치에 따른 일관성 유지에 따른 관리의 복잡성이 대두될 수 있다. 또한, 데이터가 캐슁되지 않은 경우에는 결국에는 디스크 접근을 필요로 한다. 데이터 접근의 분데이터가 메모리에 캐싱되어 있다면 메모리 접근지연시간을 보장할 수있지만 만약 해당 데이터가 메모리에 캐싱되어 있지 않으면, 디스크에 접근을 하면서 그만큼 접근지연시간이 늦어질 것이라는 점 때문이다.  

단일 사이트에서 동작하도록 설계된 DBMS의 제한된 확장성의 문제는 여러 곳에서 이미 지적된 바 있다. 이러한 문제를 해결하기 위한 현재의대표적인 기술은 NoSQL이라 볼 수 있다. 하지만 NoSQL은 확장성을 위해 기존의 DBMS가 가졌던 주요한 기능, 관계형 모델 대신 단순한 key-value model과 제한된 일관성 지원 정책 등의 한계를 또한 갖는다. 그리고 이들 또한 대부분 디스크에 기반한 저장소를 기준으로 설계되어 있으며, 관계형 DBMS만큼 범용적이지도, 호환적이지도 않다라고 저자들은 언급한다.

RAMCloud는 이러한 문제들을 해결하면서, 보다 큰 확장성과, 더짧은 접근지연시간을 제공하는 범용의 저장 시스템을 제공하기 위해 고안되었다. 

하지만, 이렇게 모든 데이터를 메모리에 올려놓았을때 문제점은 메모리 자체의 휘발성에 따라 장애 시 데이터가 유실될 수 있다는 점이다. 이에 대한 해결책은 크게 다른 데이터 노드에의 메모리에 데이터를 복제해 두거나 디스크에의 로깅을 생각해 볼 수 있다.

데이터들을 복제해서 모두 메모리에 두는 방식은 synchronous I/O를 가지고도 고성능을 보장할 수 있는 장점이 있지만, 상대적으로 비싼 DRAM이라는 저장장치의 공간을 크게 낭비하게 된다.
반대로, 데이터의 복제나 로그를 디스크에 위치시키는 것은 디스크의 접근지연시간에 따른 비효율성을 피할 수 없다. 때문에 이들은 메모리에의 로그 복제와, 메모리에서 디스크로의 비동기적인 data flushing을 통해 이 문제를 해결하려고 하고 있다.

아래 그림은 초기에 저자들이 생각하는 내고장성을 지원하기 위한 방법을 도식화한것이다. 

데이터에 대한 쓰기 연산은 마스터 노드의 메모리 상에서 바로 처리하고, 그에 따른 로그 엔트리들은 다른 노드들의 메모리에 임시적으로 위치시킨다. 그리고, 비동기적으로 각 노드의 메모리에 저장된 로그 데이터를 디스크에 기록한다.  


하지만, 아직 어떠한 방식으로 장애에 대한 내고장성을 지원하는지에 대해서는 구체적으로 연구결과를 내놓았다고 보기 어렵다. 아직까지는 이 연구는 실제 적용된 시스템이라기 보다는 일종의 비전에 가깝다. 하지만, 기술의 트렌드는 저자들이 생각하는데로 변화해 나갈것이라 생각된다.

RamCloud에 대한 간단한 소개와 그들의 프로젝트 홈페이지는 아래와 같다.

written by bart7449

  1. The 5 minute rule for trading memory for disc accesses and the 10 byte rule for trading memory for CPU time, ACM SIGMOD Record, 1987 [본문으로]
  2. The five-minute rule ten years later, and other computer storage rules of thumb, ACM SIGMOD Record, 1997 [본문으로]
  3. The five-minute rule 20 years later (and how flash memory changes the rules), ACM Queue, 2008 [본문으로]
Posted by Bart
CS 전공/리뷰2010. 10. 11. 10:54
지난 주 금요일에 있은 seminar에 Stefan Tai  박사가 오셔서 Cloud Service Engineering이라는 제목으로 약 90분간 발표. Host인 송준화 박사님의 말에 따르면, 가장 성공한 한인 2세대 중 한 명일 것이라고. 태씨라고..독일에서 태어나 미국의 대학을 거쳐 IBM Watson 에서 연구원으로 있다가 지금은 독일의 Karlsruhe Institute of Technology(KIT)에 교수로 초빙받아 가 계신다고.

Seminar는 technical depth가 깊지는 않은, 좀 개념적이고 비즈니스 쪽 얘기도 좀 있었지만 갈무리할만 내용들(특히 정의 관련하여) 이 있어서 정리를 해보자면,
  • Cloud services are infinite IT(compute, storage) resources.
    • available when needed
    • Ubiquitously accessible
    • offered in an open market of competitive service providers
    • cost-efficient ( if not free)

Cloud computing

  • Cloud computing is a business model, and a distributed computing model
    • building compute or storage virtualization, cloud computing provides scalable, network-centric, abstracted IT infrastructure, platform, and applications as on-demand services that are billed by consumption.
  • Three main objectives
    • Enterprise-grade system management
      • Under-utilized: waste computing power & energy
      • Over-utilized: cause interruption or degradation of service levels
    • Internet-scale service computing
      • Services, Internet-scale
      • Sophisticated infrastructure, platform& applications available as modular services
      • The Web as a combined computing, business and collaboration platform
    • Understanding business opportunities
      • Faster time-to-market & cost-effective innovation processes
      • Dynamic, open business, networks
  • Cloud Service Engineering-> business engineering + software engineering
  • "A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks" - ITIL Handbook Service Definition

그리고, 현재 KIT에서 IBM과 같이 수행하고 있는 두 과제를 소개하였는데..

1) Recovery Cloud
 기본 개념은 재해에 대비한 데이터 복제를 cloud 기반으로 하자는 것인데, Tai 박사는 이를 Recovery-as-a-service, Business continuity services 등으로 설명. 결국엔 replica를 cloud platform위에 올리자는 얘기인데 이때의 ownership이나 보안 문제는 어떻게 해결할 것인가 의구심이 좀 든다. recovery가 필요한 기업의 운영 데이터를 클라우드 제공자에게 맡긴다라.

2) Cloud meta-storage
이것은 여러 다양한 클라우드 기반 저장소들(BigTable, HDFS, Dynamo 등)을 대상으로 공통된 abstraction을 제공하는 시스템의 개발을 목적으로 하는데, 쓰여져 있는 바로는

"For purposes of provider independence & scalability (data volume & concurrent users), 
store data with diverse cloud storage service providers on multiple replicas" 
-> High-available, single storage provider architectures to a service value network of multiple storage service providers"

이를 위한 설계 원리는
  • Implement a simple key-value storage model, following the REST architectural style
  • Trade-off "C" for "A" (cf. CAP theorem)
  • Consider failures/outages to be the norm, not the exception)
    • Quorum-based system with hinted handoff
  • Use asynchronous message within the system
  • Use custom levels of security (authentication, additional encryption, file transfer via https)
  • Elevate concept from storage solution like Amazon Dynamo, GFS, Yahoo! PNUTS to a cloud storage SVN(Service Value Network)
와 같이 기술. 사실 기술적 특성은 Amazon의 Dynamo와 유사한듯 싶고, Mediator-Wrapper 형태의 상위 시스템을 만든다라고 봐야할까.. 






Posted by Bart
CS 전공/리뷰2010. 10. 4. 22:37


David A. Patterson이 "데이터센터가 컴퓨터이다"
[각주:1]라고 말하였듯이 최근의 클라우드 컴퓨팅에서는 shared-nothing[각주:2] 구조로 저가의 PC들을 고속의 네트워크로 묶어 데이터를 병렬 처리를 수행함으로써 scalability와 speedup(이에 관해서는 블로그의 다른 글 참조)을 보장한다.

이렇게 많은 PC들을 엮어 병렬 처리함으로써 speedup을 이루는 것을 기존의 방식, 즉 좀더 빠른 연산을 위해 컴퓨팅 파워가 적은 서버에서 대형의, 컴퓨팅 파워가 높은 서버로 대체하는 scaleup과 대비하여 scaleout이라고 설명하기도 한다. 데이터 센터는 무수히 많은 노드들로 이뤄지고 이 노드들은 상대적으로 저가의 PC 서버들이다. 이렇다 보니 데이터 센터에서의 고장은 매우 빈번할 수 있다. 데이터 센터에서의 노드 장애들이 얼마나 빈번한가 하면, Google의 한 데이터센터에서 일할 구인 광고( Job posting)에는 이런 항목이 있다.  

Position requirements:
  • Able to lift/move 20-30 lbs equipment on a daily basis
    (매일 9~13.7Kg의 장비들을 들고, 옮길 수 있어야 함)

 그러면 데이터 센터에서는 어떤 유형의 장애들이 얼마나 많이 발생하는가? 데이터베이스 분야에서 장애는 크게 사용자의 오류나 응용 프로그램의 오류, DBMS 오류, OS 오류와 같은 SW 적인 오류와 하드웨어의 오류, 네트워크 분할(network partition)이나 네트워크 오류, 재해 등과 같은 여러 문제로 기인할 수 있다[각주:3]. 그 중 여기에서는 순수한 HW의 오류에 대해서만 살펴본다. 그중에서도 특히 메모리와 HDD의 오류에 대해서 살펴본다. (CPU 오류는 거의 없다고 본다. 물론 Pentium에서의 FDIV(Floating Division) 오류와 같은 오류가 있었기는하지만.. )흔히들 HW 오류는 SW 오류보다 매우 드물다는 것이 많은 사람들의 의견이지만 많은 노드들을 갖는 데이터 센터에서는 이 오류의 빈도가 만만치가 않다. 마침 HW 오류들에 대한 통계 정보가 있어 이들을 소개한다.  Bianca Schroeder가 Google의  데이터센터에 있는 노드들을 대상으로 2년 반 동안 조사한 바에 따르면 다음과 같은 메모리 오류를 겪는다는 결과[각주:4]가 나왔다.

Picture 27

이 조사에 따르면, 매년 32.2%의 노드들이 CE(Correctable Error)-ECC 등을 통해 잡히고 고쳐질 수 있는 메모리 오류, 하지만 오류 정정에 따른 비용은 물론 있다-를 겪었으며, 매년 22,696번의 오류를 겪는다고 보고되었다. 또한, 고쳐질 수 없어 결국엔 DIMM 모듈 자체의 교체로 대처할 수 밖에 없는 오류 UE(Uncorrectable Error)는 1.29%의 노드가 겪는다고 보고되었다.   DIMM 모듈 단위로 이 통계를 다시 써보면, 1년마다 8.2%의 DIMM 모듈이 CE를 겪고, 0.22%의 DIMM모듈이 UE를 겪는다.  예를 들어, 노드 1만대를 가지고 구성되는 데이터센터에서는 3,220여대의 노드가 CE를 겪고,  129여대가 UE를 겪는다는 얘기이고 129여대는 메모리 모듈을 교체해야 한다는 의미이다. 오류 발생이 균등 분포라 가정해보면 약 3일마다 한 노드에서 UE 메모리 오류가 발생하여 결국엔 DIMM 모듈을 갈아줘야 한다.  물론 그 장애가 메모리 오류에서 발생했다는 사실을 인지할 수 있는 경우에만. 디스크의 경우는 또 어떠한가? 

우리들은  FC(Fibre Channel)나 SCSI 드라이브가 SATA 드라이브보다 더 신뢰성이 높다고 생각한다. 또한 RAID level 5(block-interleaved distributed parity) 등으로 시스템을 구축하면 보다 안전하다고 생각각한다. 그리고  제조업체가 보증하는 MTTF(또는 MTBF)는 충분히 길다고 생각한다.  정말일까? 이와 관련한 재미있는 논문들이 있다.


  • MTTF(Mean Time To Failure)는 MTBF(Mean Time Between Failure)와 많이 혼동된다. 하지만 그 의미는 조금 다르다. MTBF(Mean Time Between Failure)는 한번 고장난 후 다시 고장 날 때까지의 평균 시간으로 고장이 수리될 수 있는 시스템에서 측정된다.  한 시스템에 대한 MTBF를 측정하는 경우 동일 시스템을 여러 개를 두고 이들의 두 고장간에 정상동작된 시간들의 합을 전체 고장횟수로 나눈 시간을 MTBF로 측정한다.  제조업체가 자신의 시스템에 백만시간의 MTBF를 보증한다 하자. 그러면, 두 고장간 드라이브가 정상 동작될 평균 시간은 백만 시간이다.  이것을 어떻게 제조업체들이 측정할까?  디스크들을 백만 시간(약 114년)을 돌리고 평균을 내는가? 물론 아니다. 많은 수의 드라이브들을 돌려서 정상동작 시간들의 합을 드라이브들의 총 고장 횟수+1로 나눈다. 즉 1,000개의 드라이브를 1,000시간 돌려서 드라이브 한개라도 고장이 안나면 (1000*1000)/0+1로 MTBF가 백만 시간이 된다. 때문에 우리는 MTBF가 백만이 넘는 디스크가 나가는 경우를 볼 수가 있다.
  • MTTF는 MTBF와 달리 고장이 수리될 수 없는 시스템에서 첫 고장이 발생하는 평균 시간을 의미한다.
  • AFR(Annualized Failure Rate)은 임의의 많은 수의 디스크들을 돌려 이들  중 1년 안에 얼마나 많은 디스크들이 고장이 나는지를 확률로 표현한다.
  • MTTF는 위의 MTBF와 같은 방식으로 계산될 수있지만,  1년에 고장없이 동작된 시간을 AFR로 나눔으로써 계산될 수도 있다. 가령1년에 5,800시간을 고장없이 동작했고,  AFR은 0.58%이라면 5800/0.0058= 1,000,000시간이 된다.

Google의 엔지니어들에 의해 쓰여진 첫 번째 논문[각주:5]은 100,000개의 디스크를 분석하여 디스크를 디스크의 나이와 사용 빈도,  온도에 따른 오류 발생률을 측정하였다(AFR: Annualized Failure Rates). 또한 SMART 와 같은 디스크의 자기 모니터링 기능의 유용성도 조사하였다.



그림 2에서 보이는 바와 같이 초기 디스크 설치 시에는 고장이 좀 나다가 발생하지 않는 경우에는 1년여간은 안정적으로 동작함을 볼 수 있다. 하지만 2년째부터 AFR는 급격히 올라가고 3년째부터는 AFR이 8%를 넘는다. 이는 간과할만한 수치가 아니다. 10,000개의 노드 PC들로 구성된 데이터 센터에서 노드가  디스크 1개씩만 가진다고 하면, 매년 800개 이상의 노드 PC들의 디스크가 교체되어져야 하기 때문이다. 균등 분포의 오류 발생을 가정할 경우 매일 2-3개의 PC들의 디스크가 교체되어져야 한다.


더불어 디스크는 쓰면 쓸수록 많이 고장이 난다. 그림 3은 활용도를 저, 중, 고로 나누고 이들 간의 AFR 차이가 어떤지를 보인다. 특이한 점은 3개월 짜리 어린 디스크를 많이 이용하는 경우 AFR이 가장 높게 나왔다는 점이다. 또 다른 특징은 어린 디스크들은 고온과 AFR간의 상관관계가 없다는 것이다. 오히려 저온에서 더 높은 AFR을 보인다. 하지만 이것은 디스크가 늙어갈 수록 온도 증가에 따라 AFR이 증가하는 형태로 역전된다.


또한 SMART(Self-Monitoring, Analysis, and Reporting Technology)와 같은 디스크 모니터링 도구는 대규모의 디스크 어래이에서는 거의 사용 의미가 없다고 한다.

Schroeder의 또다른 논문[각주:6]에서는 Los Alamos와 Pittsburgh의 Supercomputer Center의 HPC 클러스터들과 여러 인터넷 서비스 제공자들의 디스크들을 분석하여 다음과 같은 결과를 얻었다.



여기에서 발견한 내용은 다음과 같다.

1. SCSI, FC 디스크같은 고가의 디스크와 저가의 SATA 디스크 간의 연간 디스크 교체 비율(ARR)은 큰 차이가 없다. 즉 고가 디스크라고 ARR이 낮은 것은 아니다.

2. infant mortality(가동 초기의 높은 오류율)을 발견하지 못하였다. 디스크는 그냥 나이에 따라 서서히 닳아(wear-out) 간다. 즉,  나이가 듬에 따라 교체되는 비율이 점차 증가한다.

3. Vendor가 제시하는 MTTF와 실제 ARR과는 많은 차이가 나며, 벤더의 MTTF보다 훨씬 많은 디스크가 고장났다.

4. 디스크 교체 간 평균 시간은 생각보다 짧다. 이것은 RAID 시스템(특히 level 5)에서 고장난 디스크를 교체하는 동안에 다른 디스크가 고장나 데이터를 잃어버릴 확률이 그만큼 높음을 의미한다.  


결론
1. 메모리나 디스크는 무결점의 장치가 아니다.

2. 디스크는 수명이 있고, 생각보다 빨리 단다.  

3. 이런 장치들이 집적된 데이터 센터에서는 많은 수의 장치들이 빠르게 고장날 수 있다.

4. 이러한 환경에서는 빈번한 장애에 대한  내고장성을 지원하는 것이 보다 중요하다.
 

  1. David A. Patterson, The Datacenter is the computer, CACM Vol.51, No. pp.151--151. 2008 [본문으로]
  2. M. Stonebraker, The case for shared-nothing, Database Engineering Bulletin, Vol. 9 No. 1 , pages 4--9, 1986 [본문으로]
  3. M Stonebraker, In Search of Database Consistency, http://cacm.acm.org/magazines/2010/10/99500-in-search-of-database-consistency/fulltext [본문으로]
  4. Schroeder, B. and Pinheiro, E. and Weber, W.D., DRAM Errors in the Wild: A Large-Scale Field Study, In Proc. of ACM SIGMETRICS, 2009 [본문으로]
  5. Pinheiro, E. and Weber, W.D. and Barroso, L.A., Failure trends in a large disk drive population, Proceedings of the 5th USENIX Conference on File and Storage Technologies (FAST’07), 2007 [본문으로]
  6. Bianca Schroeder and Garth A. Gibson, Disk Failures in the Real World: What Does an MTTF of 1,000,000 Hours Mean to You?, 5th USENIX Conference on File and Storage Technologies(FAST'07), 2007 [본문으로]
Posted by Bart
CS 전공/리뷰2010. 1. 8. 12:03

  블로그 주인장은 모 단체에서 DB 및 데이터 처리 기술 관련한 자료의 분석 추천및 검토를 담당하고 있습니다. 
이 분석 자료는 클라우드 컴퓨팅에서의 데이터 관리 이슈와 데이터 처리에 있어 MapReduce와 병렬 DBMS의 비교 분석을 중심으로 클라우드 컴퓨팅에서의 데이터 관리를 설명합니다.
이 자료의 분석은 고려대학교 대학원의 최현식씨께서 수고해 주셨습니다.

아래는 서문과 차례입니다. * 해당 자료의 열람 또는 다운로드는 www.kosen21.org에 가입 후 분석자료 메뉴에서 다운로드 하실 수 있습니다.


1. 분석자 서문 

최근 클라우드 컴퓨팅(cloud computing) 패러다임이 산업계뿐만 아니라 학계에서도 많은 관심을 받고 있다. 이와 더불어 데이터베이스 학계에서는 클라우드 컴퓨팅 환경에서 데이터관리에 대한 집중적인 연구들이 진행되고 있다. 본 분석은 현재 많은 관심을 받고 있는 비공유 구조(shared-nothing architecture) 기반 클라우드 컴퓨팅 환경(아마존 EC2와 같은)에서 유발되는 데이터 관리 이슈들과 이 환경에서 수행되는 데이터 관리의 한계점 및 가능성에 대해 살펴본다. 본 분석은 트랜잭션 데이터 처리보다는 대용량 데이터에 대한 분석 처리가 클라우드 환경에 적합하다는 것을 보인다. 그리고 대용량 데이터 분석을 위해 DBMS에 요구되는 기능들을 제시하고 이 기능들을 바탕으로 기존 오픈 소스 프로그램들과 상용 병렬 DBMS들을 평가한다. 추가적으로, 실험을 통해 두 계열 시스템의 성능을 비교 평가한 논문의 결과를 분석하여 성능 비교에 대한 추가적인 근거를 제시한다. 

2. 목차 

1. 개요 

2. 클라우드 환경에서의 데이터 관리 
2.1 클라우드 환경의 특성 
2.2 클라우드 환경에 적합한 데이터 관리 어플리케이션의 유형 

3. 클라우드 환경에서 데이터 분석용 어플리케이션 
3.1 클라우드 DBMS를 위한 필요기능 
3.2 MapReduce 계열 소프트웨어 
3.3 비공유 구조 기반의 병렬 DBMS 

4. MapReduce와 병렬 DBMS 시스템의 비교 
4.1 질의 시작 비용 
4.2 압축 기능 
4.3 데이터 적재 및 레이아웃 
4.4 실행 전략 
4.5 내고장성 모델 

5. 토론 
5.1 효율성의 비교 
5.2 입력 데이터 형식 
5.3 하이브리드 시스템 

Reference 


Posted by Bart