DevopBen

이진분류 (Binary Classification)

True Positive = 코드에 문제가 없으며, 테스트가 문제를 발견하지 않음

True Negative = 코드에 문제가 있으며, 테스트가 문제를 발견함

False Positive = 코드에 사실 문제가 없지만, 테스트가 문제를 발견함

False Negative = 코드에 문제가 있지만, 테스트가 문제를 발견하지 못함

하둡을 공부하고 운영해보신 분이라면 데이터를 기본 3개의 64MB 복제본으로 나누어 분산 저장한다는 것을 잘 알고계실 겁니다. 이로인해 호스트나 디스크 장애가 발생할때도 하둡은 나머지 2개의 복제본으로 데이터 가용성을 제공하고 부족한 복제본은 다른 호스트에 복사합니다. 그렇기에 호스트나 디스크 장애 쯤이야 자동으로 극복하고 하둡을 사용할 경우 100% 서비스 가동률을 장담할 것이라 안심합니다.

여기까진 이론적인 얘기고 실제 50대 이상의 클러스터를 구성하고 TB 단위의 데이터를 보관하다보면 아주 사소한 하둡 설정 실수에도 클러스터는 예민하게 반응합니다. 운영을 하다보면 상당히 자주 볼수 있는 장애 유형은 디스크 장애입니다. 아무래도 TB단위의 데이터를 매 시간 처리하다보니 일반적인 애플리케이션 보다는 디스크 및 호스트 장애율이 높습니다. 50대 규모의 하둡 클러스터를 운영하다보니 근래엔 1주일에 한번꼴로 디스크 장애가 발생합니다. 호스트들도 점점 늙어가나 봅니다 -.- 200~300대 이상의 클러스터에선 매일같이 디스크 장애가 난다해도 무난하겠죠? 이때 hdfs-site.xml의 dfs.datanode.failed.volumes.tolerated 설정이 제대로 안되어있으면 디스크 하나가 고장나도 데이터노드가 셧다운됩니다.

본론으로 가서 하둡 운영을 하다보면 디스크 원인 말고도 한두개의 데이터노드가 죽는 경우가 많은데, 과연 이 클러스터는 몇 대의 데이터노드 장애까지 허용할 수 있는지 몇 대의 데이터노드가 디커미션 없이 죽었을때 블록이 손실되는 현상이 발생할까? 라는 호기심이 듭니다. 그래서 간단하게 각 호스트 장애 발생시 3개의 복제본을 손실할 확률을 계산하는 방법을 설명하겠습니다.

37대의 데이터노드가 있고 각 블록은 3대의 복제본을 관리한다고 가정합시다. 이중 5대의 데이터노드 장애 발생시 특정 블록이 모든 복제본을 손실할 확률은 무엇일까요?

바꿔 말하면, 50개의 구슬이 있고 그 안엔 3개의 파란구슬과 47개의 빨간구슬이 있습니다. 이중 5개의 구슬을 무작위로 뽑았을때 3개의 파란구슬이 뽑힐 확률은 무엇일까요? 확률 수업이 새록새록할 겁니다.

즉 0.13 % 의 확률을 가집니다.

10대의 노드가 장애가 발생한다하면 1.5%가 되고, 37대 장애가 생기면 100%겠죠?

데이터노드 장애가 늘어날 수록 확률이 높아지는걸 볼 수 있습니다. 눈으로 보기엔 블록 손실 확률이 매우 적어보입니다. 하지만 우리는 블록 한개를 운영하려고 하둡을 도입하지 않습니다. 다음 문제를 풀어봅시다.

위의 질문에서 클러스터에 100TB의 데이터가 64MB의 블록으로 쪼개어 저장되어 있었다면 모든 복제본을 손실한 블록(missing block)의 수는 몇개일까요?

100TB를 64MB블록으로 나누면 1562500개의 블록이 존재합니다. 위에서 계산한 확률을 곱하면 0.0013 * 1562500 = 2031

2031개의 블록이 손실됩니다. 손실된 블록과 연관된 파일은 접근이 불가능해진단 말이며 금융 시스템 같은 경우 매우 치명적인 현상입니다.

이러한 계산을 통해 본인의 클러스터가 몇대의 데이터노드 장애를 허용할 수 있는지 알 수 있고 미리 데이터 장애에 대비할 수 있습니다.

 일단 가장 큰 변화로는 얀 자체로 맵리듀스를 구동할 수 있고, 추가로 다른 분산처리 프레임워크 (Giraph, Storm, HBase 등)을 사용자의 인터페이스 개발만으로 구동 가능하게됐습니다. 참고로 얀에서 작동하는 맵리듀스를 MRv2라고 부릅니다.

기술적으로는 기존 맵리듀스의 마스터인 잡트래커가 리소스관리, 잡 스캐줄링, 잡 모니터링을 하는데 비해 얀의 마스터인 ResourceManager(RM)은 두개의 서비스로 분리되고 (클러스터 리소스를 관리하는 Scheduler와 ApplicationMaster(AM)를 관리하는 ApplicationsManager(AsM)), AM은 하나의 노드에 RM에 의해 가동되어 잡의 라이프사이클과 모니터링을 담당합니다. 이 모델은 기존 5000개 정도의 노드 제한이 있는 잡트래커 방식에 비해 발전된 확장성을 가지고 각 애플리케이션 별 독립성도 부여합니다.

참고자료:

http://blog.cloudera.com/blog/2012/10/mr2-and-yarn-briefly-explained/
http://blog.cloudera.com/blog/2012/02/mapreduce-2-0-in-hadoop-0-23/

얀이 상승세를 탈 시기가 되었습니다. 일단 하둡0.23 2011년말 출시된지도 꽤 됐고, 이제 곧 하둡 2.1 베타버전이 출시됩니다. 또한 최근 야후에서 yarn-storm 오픈소스를 공개해 얀의 배치성 작업과 스톰의 실시간성 작업을 같은 클러스터에 구성할 수 있게 되어 화두가 되고 있습니다.

http://developer.yahoo.com/blogs/ydn/storm-yarn-released-open-source-143745133.html

전망되는 얀의 최고 상승세는 물론 얀의 정식버전이 출시될때입니다. 아직 하둡2.0이 알파 버전이라 운영클러스터 적용을 꺼려하고 있는데 베타버전을 거쳐 정식버전이 출시되면 큰 인기를 얻을 전망입니다. 

 하둡과 맵리듀스도 배우기 바쁜 이 시점에서 아직 사용자층에서 얀에 큰 관심은 없지만 금년 말부터 빅데이타 트랜드가 될것으로 보이고 하둡2.0에서 채택한만큼 피해갈 수 없는 기술로 보입니다.