2013.03.26

기고 | 하둡 어플라이언스와 유지보수에 대한 단상

김형준, 그루터 아키텍트 | ITWorld
빅 데이터 외부 프로젝트를 수행하면서 새롭게 하둡을 도입하고자 하는 여러 기업을 만나봤다. 이때 항상 물어 보는 것이 유지보수에 대한 내용이다. 그래서 하둡이나 하둡 에코 시스템에 대한 유지보수에 대한 이야기를 좀 해볼까 한다.
 
하둡 관련 프로젝트를 하면서 필자가 항상 주장하는 것은 반드시 내부 기술 역량을 갖춰야 한다는 것이다. 내부적으로 갖춰야 할 역량은 대략 다음과 같은 것이 있다.
 
1. 하둡 및 에코 시스템에 대한 전반적인 이해
2. 시스템 운영 능력 및 문제해결 능력
3. 하둡 및 에코 시스템을 이용한 응용(분석 프로그램) 개발 능력
 
1, 3번 항목에 대해서는 실제 도입하고자 하는 기업에서도 어느 정도 인식하고 있는 부분이다. 2번 항목의 경우 대부분의 기업이 인프라 운영 부서로 업무를 이관하려고 한다. 하지만 하둡의 현재 솔루션 상태를 보면 인프라 운영 부서로 운영 업무를 이관하는 것이 쉬운 상황은 아니다. 그 이유를 생각해보면 다음과 같다.
 
- 하둡과 에코 시스템은 복잡한 분산 아키텍처다. 실제 사용되는 데몬의 종류도 많고 데몬의 상태도 다양하다. 이런 복잡한 아키텍처를 제대로 이해해야만 운영할 수 있는데, 인프라 운영 조직에서 복잡한 아키텍처를 이해하면서까지 운영할 수 있는 조직은 많지 않다.
 
- 인프라 운영 부서의 대부분의 주요 미션은 장애율을 줄이는 것이다. 거기에는 하드웨어 장애까지 포함하고 있다. 하지만 하둡이나 하둡 에코 시스템의 경우 기존 시스템보다 CPU, 디스크, 메모리 등을 시스템의 극한 상황까지 사용하는 경우가 많으며, 다른 업무의 서버에 비해 장애가 자주 발생한다. 하지만 서버에 장애가 발생했다 하더라고 즉시 대응할 필요가 없는 아키텍처를 가지고 있는 것이 하둡인데 인프라 운영 조직의 특성상 이런 장애 상태를 보고만 넘어가지 않을 가능성이 많다. 기존의 프로세스대로 운영하게 되면 운영자 또한 장애 보고서와 재발 방지 대책 등으로 엄청난 스트레스를 받을 것이다.
 
- 하나의 문제가 전체의 문제가 될 수도 있고 많은 문제가 아무런 문제를 발생시키지 않을 수도 있는 복잡한 상황
- 원인 파악의 어려움
- 다양한 버전의 오픈소스
 
따라서 인프라 운영 조직의 경우 당연히 기존의 방식과 동일하게 개발업체에서 제공하는 하둡 어플라이언스를 도입하는 것이 더 좋을 것 같다라는 의견을 많이 제시한다. 하둡 어플라이언스를 도입한다고 해서 앞서 설명한 운영 문제가 해결될지는 의문이다. 
 
아직 필자도 하둡 어플라이언스를 제공하는 개발업체의 유지보수 SLA을 보지는 못했다. 하지만 추측하건데 하드웨어 장애에 대한 즉시 대응이라던가, 장애 원인 파악 보고서 작성 등과 같이 기존의 엔터프라이즈 시스템에서 제공되던 많은 항목들이 없어지거나 수준이 낮아졌을 가능성이 높다. 
 
하둡에서 버그나 문제가 발생할 경우 다음과 같은 해결 방법이 있다.
 
1. 오픈소스 커뮤니티의 버그 패치나 문제 해결 방법에 의존
2. 개발팀 스스로 버그 픽스 또는 문제 해결
3, 어플라이언스의 경우 제공하는 개발업체에서 패치를 제공하거나 문제를 해결
 
개발업체의 제품을 구매하는 경우 3번을 기대하고 구매하는 것인데, 현재의 하둡 어플라이언스를 제공하는 업체들은 자체 하둡 코어를 수정할 수 있는 능력이나 문제를 해결할 수 있는 능력이 높은 것 같지는 않다. 대부분은 클라우데라 배포판을 사용하거나 아파치 버전을 조금 수정해서 사용하는 정도라고 볼 수 있다. 
 
따라서 어플라이언스를 도입하고도 오픈 소스 커뮤니티에 의존하거나 심지어는 자체 해결해야 할 경우가 많아질 가능성이 높다. 또한 하둡의 파편화는 어떻게 해결할 것인지 고민스러운 부분이 아닐 수 없다.
 
물론 어플라이언스를 도입했을 때 장점은 있다. 그런 문제 발생 시 문제의 원인, 문제의 책임을 인프라 조직이 아닌 개발업체에게 전가시킬 수 있다. 이 장점을 제외한다면 하둡 어플라이언스를 구매했을 때의 장점은 거의 없다고 할 수 있다. 물론 많은 업체들이 이런 이유때문에 개발업체 솔루션을 선정하는 경우도 많다.
 
그러면 하둡을 도입하고자 하는 기업은 하둡의 운영을 어떻게 해야 할까? 당장의 대답은 개발팀에서 운영을 같이 해야 한다는 것이다. 필자는 기회가 있을 때마다 어플라이언스 도입 비용으로 내부 기술력을 키우는데 투자하는 것이 더 좋다고 강조하고 있다. 
 
운영의 주체를 지금 당장 인프라 운영 조직으로 넘기기보다는 내부 개발 조직에서 기술력을 내재화시키고, 이를 기반으로 운영체제/하드웨어는 인프라 운영 조직에서, 하둡 이후부터는 내부 개발 조직에서 운영하는 편이 좋을 것이다.
 
현재의 하둡은 단순히 솔루션을 사용하는 관점이 아니라 다양한 에코 시스템을 연계해 하나의 거대한 데이터 처리 플랫폼을 만들어야 하는데 이를 위해서는 내부 개발팀에서 운영도 같이 병행해 빠른 시간에 기술력을 올려야 하기 때문이다.
 
마지막으로 빅 데이터를 추진하는 대부분의 기업은 대기업이다. 국내 소프트웨어의 경쟁력을 확보한다는 큰 뜻을 위해서라도 이런 기회에 오픈소스 중심의 생태계를 만들어 보는 것도 좋지 않을까 제안해본다. editor@itworld.co.kr 


2013.03.26

기고 | 하둡 어플라이언스와 유지보수에 대한 단상

김형준, 그루터 아키텍트 | ITWorld
빅 데이터 외부 프로젝트를 수행하면서 새롭게 하둡을 도입하고자 하는 여러 기업을 만나봤다. 이때 항상 물어 보는 것이 유지보수에 대한 내용이다. 그래서 하둡이나 하둡 에코 시스템에 대한 유지보수에 대한 이야기를 좀 해볼까 한다.
 
하둡 관련 프로젝트를 하면서 필자가 항상 주장하는 것은 반드시 내부 기술 역량을 갖춰야 한다는 것이다. 내부적으로 갖춰야 할 역량은 대략 다음과 같은 것이 있다.
 
1. 하둡 및 에코 시스템에 대한 전반적인 이해
2. 시스템 운영 능력 및 문제해결 능력
3. 하둡 및 에코 시스템을 이용한 응용(분석 프로그램) 개발 능력
 
1, 3번 항목에 대해서는 실제 도입하고자 하는 기업에서도 어느 정도 인식하고 있는 부분이다. 2번 항목의 경우 대부분의 기업이 인프라 운영 부서로 업무를 이관하려고 한다. 하지만 하둡의 현재 솔루션 상태를 보면 인프라 운영 부서로 운영 업무를 이관하는 것이 쉬운 상황은 아니다. 그 이유를 생각해보면 다음과 같다.
 
- 하둡과 에코 시스템은 복잡한 분산 아키텍처다. 실제 사용되는 데몬의 종류도 많고 데몬의 상태도 다양하다. 이런 복잡한 아키텍처를 제대로 이해해야만 운영할 수 있는데, 인프라 운영 조직에서 복잡한 아키텍처를 이해하면서까지 운영할 수 있는 조직은 많지 않다.
 
- 인프라 운영 부서의 대부분의 주요 미션은 장애율을 줄이는 것이다. 거기에는 하드웨어 장애까지 포함하고 있다. 하지만 하둡이나 하둡 에코 시스템의 경우 기존 시스템보다 CPU, 디스크, 메모리 등을 시스템의 극한 상황까지 사용하는 경우가 많으며, 다른 업무의 서버에 비해 장애가 자주 발생한다. 하지만 서버에 장애가 발생했다 하더라고 즉시 대응할 필요가 없는 아키텍처를 가지고 있는 것이 하둡인데 인프라 운영 조직의 특성상 이런 장애 상태를 보고만 넘어가지 않을 가능성이 많다. 기존의 프로세스대로 운영하게 되면 운영자 또한 장애 보고서와 재발 방지 대책 등으로 엄청난 스트레스를 받을 것이다.
 
- 하나의 문제가 전체의 문제가 될 수도 있고 많은 문제가 아무런 문제를 발생시키지 않을 수도 있는 복잡한 상황
- 원인 파악의 어려움
- 다양한 버전의 오픈소스
 
따라서 인프라 운영 조직의 경우 당연히 기존의 방식과 동일하게 개발업체에서 제공하는 하둡 어플라이언스를 도입하는 것이 더 좋을 것 같다라는 의견을 많이 제시한다. 하둡 어플라이언스를 도입한다고 해서 앞서 설명한 운영 문제가 해결될지는 의문이다. 
 
아직 필자도 하둡 어플라이언스를 제공하는 개발업체의 유지보수 SLA을 보지는 못했다. 하지만 추측하건데 하드웨어 장애에 대한 즉시 대응이라던가, 장애 원인 파악 보고서 작성 등과 같이 기존의 엔터프라이즈 시스템에서 제공되던 많은 항목들이 없어지거나 수준이 낮아졌을 가능성이 높다. 
 
하둡에서 버그나 문제가 발생할 경우 다음과 같은 해결 방법이 있다.
 
1. 오픈소스 커뮤니티의 버그 패치나 문제 해결 방법에 의존
2. 개발팀 스스로 버그 픽스 또는 문제 해결
3, 어플라이언스의 경우 제공하는 개발업체에서 패치를 제공하거나 문제를 해결
 
개발업체의 제품을 구매하는 경우 3번을 기대하고 구매하는 것인데, 현재의 하둡 어플라이언스를 제공하는 업체들은 자체 하둡 코어를 수정할 수 있는 능력이나 문제를 해결할 수 있는 능력이 높은 것 같지는 않다. 대부분은 클라우데라 배포판을 사용하거나 아파치 버전을 조금 수정해서 사용하는 정도라고 볼 수 있다. 
 
따라서 어플라이언스를 도입하고도 오픈 소스 커뮤니티에 의존하거나 심지어는 자체 해결해야 할 경우가 많아질 가능성이 높다. 또한 하둡의 파편화는 어떻게 해결할 것인지 고민스러운 부분이 아닐 수 없다.
 
물론 어플라이언스를 도입했을 때 장점은 있다. 그런 문제 발생 시 문제의 원인, 문제의 책임을 인프라 조직이 아닌 개발업체에게 전가시킬 수 있다. 이 장점을 제외한다면 하둡 어플라이언스를 구매했을 때의 장점은 거의 없다고 할 수 있다. 물론 많은 업체들이 이런 이유때문에 개발업체 솔루션을 선정하는 경우도 많다.
 
그러면 하둡을 도입하고자 하는 기업은 하둡의 운영을 어떻게 해야 할까? 당장의 대답은 개발팀에서 운영을 같이 해야 한다는 것이다. 필자는 기회가 있을 때마다 어플라이언스 도입 비용으로 내부 기술력을 키우는데 투자하는 것이 더 좋다고 강조하고 있다. 
 
운영의 주체를 지금 당장 인프라 운영 조직으로 넘기기보다는 내부 개발 조직에서 기술력을 내재화시키고, 이를 기반으로 운영체제/하드웨어는 인프라 운영 조직에서, 하둡 이후부터는 내부 개발 조직에서 운영하는 편이 좋을 것이다.
 
현재의 하둡은 단순히 솔루션을 사용하는 관점이 아니라 다양한 에코 시스템을 연계해 하나의 거대한 데이터 처리 플랫폼을 만들어야 하는데 이를 위해서는 내부 개발팀에서 운영도 같이 병행해 빠른 시간에 기술력을 올려야 하기 때문이다.
 
마지막으로 빅 데이터를 추진하는 대부분의 기업은 대기업이다. 국내 소프트웨어의 경쟁력을 확보한다는 큰 뜻을 위해서라도 이런 기회에 오픈소스 중심의 생태계를 만들어 보는 것도 좋지 않을까 제안해본다. editor@itworld.co.kr 


X