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