프로젝트이야기 2: 빅데이터를 이용한 경로탐색정보 분석

산행준비

고객사의 글로벌 경로탐색 프로젝트를 마무리 하던 시점에 업무 담당 매니저에게서 새로운 프로젝트를 제안 받았다. 현재 서비스 중인 LBS시스템의 경로탐색 결과정보를 분석하여 통계를 내는 새로운 업무시스템 구축이었다. 경로탐색 품질을 확인하기 위하여 실사 검증팀이 전국을 순회하며 경로탐색을 수행하며 품질 검증을 하던 수작업 업무에서 하루 평균 600백만건이 발생하는 경로탐색정보를 시스템적으로 분석하여 사용자가 원하는 정보를 추출하는 것이 프로젝트의 목표였다. 또한 자동화 된 품질 검증 프로세스 구축으로 인해 기존 수작업 검증에 소요되는 비용의 절감과 전체 사용자의 실시간 정보를 활용하여 높은 품질의 분석결과를 도출하고 다음 업그레이드에 반영할 수 있는 기반정보를 얻게되는 것이 수반되는 기대 효과였다.

첫번째 고개

새로운 프로젝트를 준비하면 만난 첫번째 이슈는 새로운 시스템을 구축하기 위한 아키텍쳐를 결정하는 것이었다. 로그분석 시스템을 구축하기 위한 2가지 방법을 고려하였었는데 첫번째는 전통적인 방식으로 로그를 수집하고 Spring Batch Framework 와 CI Tool을 이용하여 로그를 분석하고 결과를 저장하는 것이고 두번째가 대용량 로그 분석을 수행할때 많이 이용되는 하둡을 적용하는 방식이었다. 프로젝트 팀원들 모두가 하둡에 대한 경험과 이해도가 전무한 상태에서 두가지 선택사항중 하나의 방향을 선정해야하는 것이 PM으로서 첫번째 결정사항이 되었다.

고객의 프로젝트 수행 목적 중 하나가 대용량 분석시스템 기반을 준비하는 것 이라는 사항과 개인적이면서 팀원들의 공통적인 새로운 영역에 대한 열망이 하둡을 기반으로 하는 로그분석시스템으로 아키텍쳐의 방향을 결정하는 중요한 고려사항이 되었다. 프로젝트를 성공적으로 마무리 지어야 하는 PM으로서 경험이 전무한 기술요소를 선택하게한 팀원들의 열망이 오랜만에 나의 가슴을 뛰게 만들었으며 안정적인 기술요소를 버리고 새로운 영역에 뛰어들게 만들었다.

두번째 고개

하둡을 로그분석 기반으로 결정하면서 마주친 두번째 이슈는 하둡과 연관된 수많은 기술요소들과 이러한 기술요소들에 대한 경험이 전무한 상태에서 우리 시스템을 구축하기 위한 Framework와 기술을 선정해야 하는 것이었다. 하둡생태계에서 연관되는 수많은 기술요소들 중 우리가 원하는 기능에 근접하는 기술요소들을 결정하는 것도 매우 중요한 일이었다.

[그림1] Hadoop Eco System (출처 : http://1004jonghee.tistory.com)

하둡의 버전을 선택하는 문제와 어떤 패키지를 선택하는냐에 대한 문제도 기술요소를 선택하는 분기점이 되었다. 네임노드 가용성 문제가 있지만 안정적인 1.X 버전과 아직 베타버전인 2.X 버전 그리고 두가지 버전의 기능을 포함하는 클라우데라 배포판에서 우리는 아파치 하둡 1.X를 선택하였다. 차후 시스템 업그레이드와 패키지 간의 독립성을 보장하기 위하여 기능적인 면에서 아쉬운 점이 있지만 아파치 하둡을 선택하는 것이 옳은 결정이라고 판단하였으며 2.x는 아직 안정화 버전이 출시되지 않아 고려대상에서 제외시켰다.(현재는 2.X 안정화 버전이 출시되었다.) 클라우데라 배포판은 기능적인 면과 안정성면에서 장점이 존재하지만 일정 노드 수 이상의 노드 구성시 구매를 해야하는 라이센스 정책으로 고려대상에서 제외하였다.

로그수집기의 경우 척와와 플럼을 대상으로 검토를 진행 하였으며 단순한 구조와 멀티구성을 통한 수집 기능확장 및 java상속을 통한 커스터마이징의 장점을 고려하여 Flume을 최종 선택하였다. 실제 flume을 사용하는 사례들을 구글링을 통해 많이 확인한 것도 고려대상이 되었었다. 잘 모르는 기술요소인 경우는 많이 사용하는 기술요소를 1차 검토 대상으로 올려놓고 검토를 하였다.

세번째 고개

시스템 구성을 위한 신규 도입 서버 환경에 대하여 업무팀과 논의하던중 예상하지 못한 문제에 직면했다. 프로젝트가 시작되기 전에 로그분석시스템을 위한 사양이 발주되었으며 이 시스템은 하둡 분석시스템을 고려하지 않은 서버환경으로 준비가 되었던 것이었다. 운영서버,통합테스트서버,개발서버 총 3개의 서버가 발주되었으며 로그수집 정보 보관을 위한 오라클서버 저장공간을 위한 확장 예산이 승인된 상태였다. 협의 결과 3개의 서버를 모두 하둡 클러스터링으로 구성하여 운영서버로 사용하기로 결정하였으며 세부사양은 데이터노드와 네임노드에 맞게 허용가능 범위안에서 일부변경하였다. 하지만 노드 서버를 추가 확보하지 못하여 우리의 하둡 분석시스템은 네임노드 1대와 데이터노드 2대로 구성할 수 밖에 없었다. 네임노드의 메모리가 부족한 부분은 1차개발범위내에서는 해결하기 어려운 상황이라서 2차 고도화 사업때 시스템 확장을 포함하기로 논의하였다.

NAME노드 : HP DL380pG8 3.30GHz 2P8C, Mem 16GB, DISK 600GB
DATA노드1 : HP DL380pG8 2.30GHz 2P12C, Mem 16GB, DISK 4.5TB
DATA노드2 : HP DL380pG8 2.30GHz 2P12C, Mem 16GB, DISK 4.5TB
replication=1 인 경우 일평균 로그 수집량 : 96G
replication=1 인 경우 월평균 로그 수집량 : 2.8TG
replication=1 인 경우 년평균 로그 수집량 : 33.6TG

고사양의 장비로 구성되었으나 물리적으로 부족한 노드 구성은 11월부터 로그수집을 본격적으로 시작하고 한달만에 늘어나는 로그정보와 24개의 분석 M/R을 감당하지 못하고 임계치가 초과하여 일정시간안에 분석이 완료되지 못하는 문제를 발생시켰다. 프로젝트 발주 이전 서버 도입이 고려되던 시기에 우리가 하둡에 대한 지식이 조금이라도 있더라면 충분히 고려된 사양이 준비가 되도록 조언을 할 수 있었을 텐데 그렇지 못한 점이 마무리 한 시점에 와서도 아쉬운 점이다. 한참 그 당시 진행중이던 프로젝트를 마무리 하기 위하여 일정에 쫓기고 있던 시기였지만 노련한 프로젝트 관리자라면 다음 프로젝트를 위한 사전 준비를 그 시점에 했었어야 한다는 것을 뒤늦게 깨닫게 되었다. 프로젝트를 관리하는 입장에서 한순간의 판단이 어떻게 고객사에게 영향을 끼치는지 알게된 중요한 경험이었다.

[그림2] 서버별 어플리케이션 구성

네번째 고개

1차오픈이 한달 남은 시점에 개발환경문제로 고민에 빠져 있었다. 분산환경을 테스트 하기 위한 개발서버가 준비되지 못했으며 오픈 한달전까지 준비하기로 예정되었던 운영서버도 도입되지 않았다. 운영서버 도입일정은 여전히 TBD 상태였으며 4주남은 시점에 개발환경이 겨우 준비되어 분산환경 테스트를 진행할 수 있었다. 3주가 남은 시점에 운영서버가 개발팀에 인계되었고 1주일을 새로운 운영서버의 운영환경을 설정하는데 소비가 되었다. 오픈을 위한 다급한 마음이 서버사양을 제대로 확인하지 않고 네임노드와 데이터노드를 설치하여 프로젝트 마무리 시점에 재 설정하는 불필요한 시간낭비도 초래하였다. 물론 이로 인하여 운영메뉴얼에 네임노드 이전시 고려사항에 대하여 기술하여 인수팀에 전달할 수 있는 좋은 사례가 되었지만 개발팀의 실수임은 부인할 수 없는 사실이다. 운영서버 환경이 늦어지니 테스트 미비로 로그수집기의 서비스 운영서버 설치에 대한 운영팀 담당자의 허락이 떨어지지 않았다. 운영담당자의 요구사항에 맞추어 서비스시스템의 통합테스트 서버에서 로그수집기를 설치하고 스트레스 테스트를 진행하였다.

[그림3] 로그수집기 스트레스 테스트 결과

테스트 수행결과 임계치 상태의 서비스 중 flume 로그수집기의 CPU 사용율이 약5%정도이며 1-2분 이내로 10분단위의 로그수집이 완료되는 것으로 확인되어 허용범위안에 들어오는 것으로 확인되었다. 요청량이 작은 Group A 서비스에 선적용하고 요청량이 많은 Group B는 좀 더 시간을 두고 적용하는 것으로 시스템 운영담당자와 업무담당자간 3자미팅에서 결정되었다. 서버 도입이 늦어지게 되어 전체 일정에 있어서 준비시간이 부족하게 되어 11월오픈은 group A에 대해서 오픈이 적용 되었으며 group B까지 최종 오픈은 11월 중순에 가서야 가능해 졌다. 서버 준비는 PM인 내가 관여할 수 있는 영역밖의 일이지만 전체 일정에 영향을 주는 중요한 요소라서 매주 미팅때마다 일정 지연에 대한 이슈를 제기하였었다. 하지만 결과적으로는 전체 일정에 영향을 주게 되었으며 짧은 오픈 준비기간으로 팀원들에게 부담감과 주말근무를 할 수밖에 없는 상황을 초래케 한 것은 PM이 책임져야하는 귀책사유라 할것이다.

정상에 올라서서

경험해보지 못한 미지의 세계를 여행하는 것은 언제나 설레임과 미래의 경험에 대한 기대치로 흥분된다. 업무적으로 쉽게 접해볼 수 없는 BigData 분석 시스템을 경험해 본 것만으로도 개발자로서 충분히 만족스러운 프로젝트였다. 비록 PM의 역활로 인해 세부적인 개발에 집중할 수 없었지만 한번의 경험은 이후 업무의 자산이 되리라 생각한다. 모두들 처음 접해보는 업무영역에서 서로간의 생각의 차이로 인한 이견들도 많았던 프로젝트였다. Spring framework를 기반으로 하둡 분석 아키텍쳐를 구성하자는 의견과 하둡생태계에서 많이 사용하는 기술요소들을 도입하자는 다양한 의견들로 인해 여러가지 아키텍쳐를 검증해볼 수 있었으며 서로 다른 아키텍쳐 각각의 가능성을 확인 해 볼 수 있는 좋은 기회였다.

이러한 경험들은 프로젝트의 1차목표인 로그분석을 위한 기반시스템 구성을 충족하면서 2차 고도화 프로젝트의 아키텍쳐를 구성하는데 기반이 되리라고 생각한다. 프로젝트의 위험관리에 있어서 중요성을 또 다시 깨닫게 된 프로젝트 였으며 PM의 부족함에도 불평없이 마지막까지 따라와 주며 열심히 노력한 팀원들 덕분에 마무리를 잘 할 수 있었다고 생각한다. PM의 위험관리능력 부족으로 인해 일정이 지연되면서 마무리 되지 못한 보안점검 프로세스와 당일 발생 로그 전체를 오라클 DB에 등록하여 차후 비정형DATA 분석시 사용하려던 기능은 현재 시스템 여건상 24시간내에 오라클 DB 등록 불가하다는 부적합성 확인으로 마무리되어 마지막 아쉬움으로 남는다.

2차 고도화 사업에서는 다른 방식으로 문제로 풀어내기로 고객과 협의가 되었음에도 불구하고 프로젝트 일정초과는 PM인 나의 어깨를 누른다. 회사사정으로 직접 마무리하지 못하고 2차 고도화 사업 담당 PM에게 업무를 인수하게되어 아쉬움이 남지만 훨씬 뛰어난 PM이 프로젝트를 맡게 되어 내가 진행하는 것보다 고객에게 더 유용한 시스템을 전달할 수 있으리라 믿어 의심치 않는다.