비 개발자를 위한 개발 이야기— Apache Hadoop(FDC/Zeppelin)
저는 네이버 파이낸셜 페이플랫폼에서 개발 업무를 담당하고 있는 김태우 입니다.
해당 포스팅은 비 개발자를 위해 쉽고 재미있게 작성한 (적어도 그런 시도는 한) 개발 문서입니다, 특히, 가이드 문서에서 데이터 분석에 제플린(Zeppelin)을 쓰라고 하니 Zeppelin 를 써서 열심히 데이터 추출을 하고 있지만, Zeppelin이 정확히 뭔지, 가끔 거기 나오는 Hive나 Hadoop은 또 무슨 말인지 잘 모르겠는 주니어 기획자 분들을 위해 작성했습니다. 😏
최대한 비 전공자들도 재미있게 읽을 수 있는 설명을 하기 위해 정확하지 않은 부분이나 생략된 부분이 있을 수 있으니 이 점 염두에 두고 읽어 주시기를 바랍니다.
처음부터 시작해 보겠습니다.
Zeppelin이 뭘까요? Zeppelin은 web UI를 통해 SQL, Scala, Python, R, Hadoop 등의 데이터 분석 Tool을 이용 할 수 있는 웹 어플리케이션 입니다.
다만 여러분이 주로 사용하고 계실 Zeppline은 네이버 파이낸셜에서 FDC를 사용하기 위해 구축한 FDC용 Zeppelin 입니다. 고로 해당 글에서는 Zeppline = FDC Web Application 이라고 간소화 하겠습니다.
그럼 FDC는 또 뭘까요? FDC는 네이버 파이낸셜 에서 자체적으로 구축한 Apache Hadoop 기반의 Data Warehouse 입니다. (즉, Naver Financial Hadoop= FDC)
그렇다면 Zeppline은 Apache Hadoop을 쉽게 사용하는 툴 이라고 볼 수 있을 것 같습니다.
그럼 Apache Hadoop은 뭐고, Data Warehouse는 또 뭘까요..?
아주 짧게 설명하자면, Apache hadoop은 데이터 저장은 오래 걸리고, 데이터 조회는 아주 빠른, 빅데이터에 특화된 분산 시스템인 HDFS기반의 데이터 저장소입니다, 또한 Hadoop과 같이 나오는 단어인 Hive 까지 설명하려면 너무 길어 질 테니 일단은 Hadoop = Hive 이라고 이해해 주셔도 무방합니다.
HDFS나 분산형 같은 기분 나쁜 단어가 아닌, 현실적인 예를 들어 Apache hadoop을 설명해 보자면, hadoop은 대한민국 오천만 국민의 모든 정보를 저장/조회 하는 공무원 조직이라고 가정할 수 있을 것 같습니다. 공무원은 500명이고, 각각의 (불쌍한) 공무원들은 30 만 명분의 정보를 관리합니다. 그럼 500 * 30만 명 = 일억 오천만명의 데이터고, 한국 국민은 겨우 오천만명인데, 왜 한 명의 정보를 여러 명의 공무원이 중복해서 관리할까요? 요즘 공무원 분들이 얼마나 퇴직을 자주 하는지 고려해야 하고, 공무원이 몇 명 퇴직해도 남은 공무원들은 여전히 한국 사람들의 신상을 관리할 수 있어야 하니까요!
hadoop에서 쓰는 서버는 (적어도 기계 반란 전까지는) 퇴사하지 않겠지만, 서버는 다운될 수 있기 때문에 hadoop도 여러 서버가 하나의 정보를 함께 관리할 수 있습니다.
그리고 위의 공무원들을 데리고 모든 강릉 사람의 정보를 조회 했을 시 모든 강릉 사람의 정보를 조회하는 명령은 모든 500명의 공무원들에게 전파되고, 각 공무원들은 자기가 가진 30 만 명의 정보 중 강릉 사람의 데이터를 전부 조사해 가져오게 될 것이고, 가져온 500개의 결과를 취합하면, 우리가 찾는 ‘모든 강릉 사람’의 정보를 얻게 됩니다. 다만, 조회는 500명의 공무원을 괴롭혀 동시에 빠르게 진행했기 때문에 일반적인 경우 1명이 500개의 명부를 보면서 조사하는 결과보다 500명이 각각 명부를 들고 조사 하는 게 500배 빠를 겁니다, 물론 명령 전파나, 공무원들의 속도, 보고서 취합 시간도 고려하면 속도가 500배는 되지 않겠죠.
여기서 공무원은 어디까지나 예시이고 실제로는 위와 유사하게 500대의 DB 서버가 동시에 내 요청을 처리하기 때문에 우리가 Zeppline에서 데이터 검색/분석을 했을 때 결과가 그렇게 빠르게 나올 수 있었던 겁니다.
여기서 생각이 빠르신 분들은 이렇게 생각하셨을 겁니다.
‘어 뭐야, 그럼 취합 시간 좀 늘어나는 거랑 서버 좀 여러 대 써야 하는 거 빼면 DB가 500배 빨라 지는 거 아니야? 명령 전파나, 취합 시간 빼고 보수적으로 계산해도 100배 빨라진다는 소리잖아! 그럼 모든 DB를 apache hadoop 기반으로 바꾸면 DB 서버도 100배 빨라지겠네?’
좋은 질문입니다! 다만 세상 일은 보통 저렇게 잘 풀리지는 않습니다.
위의 공무원 조직에서 새로 주민등록을 하려면, 일이 꽤 번거로워 질 겁니다. 우리가 직접 주민 명부를 들고(여기서 주민 명부는 일반적인 DB에 대한 비유입니다) 그냥 새로 태어난 주민의 정보를 명부에 적으면 되던 기존과는 다르게 , 서로 일을 떠 넘기는 500명의 공무원들 중에 해당 주민을 관리하는 여러 명의 담당자를 찾아야 할 거고, 담당 공무원들이 주민등록을 처리 했는지 하나하나 다 확인해야 할 테니까요.
그래서 일반적으로 공무원들은 새벽에 사람이 별로 없을 때 하루에 있었던 출생 신고를 전부 모아서 일괄 처리를 합니다. 한국에서는 하루에 몇 천 명이 태어나고, 아이들이 태어날 때마다 담당자들을 모아 주민등록 처리를 시키면 더 이상 목록에서 강릉 시민들을 찾아낼 시간이 없어질 겁니다.(개발자들이 ‘FDC는 새벽에 배치가 돌면서 데이터를 업데이트한다’ 라고 설명한다면 보통 이 부분을 말합니다) 그래서 간단히 우리 손에 명부를 들고 직접 주민 목록을 관리하던 때와는 다르게 Hadoop에서는 당일 날 변경된 사항을 찾을 수 없고, 해당 데이터를 찾으려면 1~2일 정도 일괄 처리가 완료되기를 기다려야 합니다.
또한, 이 공무원 조직은 사람을 ‘한 명’ 찾는 속도는 느립니다. 단 한 명의 정보를 알고 싶어도, 여전히 A씨의 정보를 찾으라는 공문을 발송해야 할 거고, 500명이 각자 자기 명부에서 A씨의 정보를 찾아보는 걸 기다려야 할 것이며, 또 500명이 각자 보낸 A씨의 정보를 (혹은 자기는 A씨의 정보가 없다는 정보를) 취합해야만 A씨의 정보를 알아 낼 수 있을 테니까요, 물론 500명 중에 한 명만 A씨의 정보를 준다면 A씨의 정보를 알아낼 수 있겠지만, 이론 상으로는 500명 중 단 3명만이 A씨의 정보를 가지고 있습니다, 즉 A씨의 정보가 없다는 이야기를 200번 정도 들으면서 ‘기다려야’ 합니다. (무엇보다, 실제로는 상황이 더 복잡하기 때문에 500명의 보고를 다 기다려야 합니다)
위에서 볼 수 있는 것처럼, Hadoop은 여러 명의 공무원(서버)를 동시에 괴롭혀, 빠르게 대량의 정보를 뽑아올 수 있지만, 새로운 정보를 저장 하는 건 좀 번거로워지는 대용량 정보 관리 시스템입니다. 물론 현실의 Hadoop이 어떻게 정보를 취합할지, 어떻게 리소스를 관리할지, 어떻게 Map-Reduce 작업을 효율화하고 가속화 할지 등의 여러 복잡한 이슈가 많이 산재해 있습니다. Map-reduce는 또 뭐냐구요? Map-reduce가 뭔지 설명하려면 이 글의 제목부터 개발자를 위한 Apache Hadoop로 바꿔야 할 겁니다!
비 개발적인 측면에서 본 Hadoop의 원리는 위와 같습니다, 그럼 Hadoop의 실제 사용법은 어떻게 풀어 볼 수 있을까요?
저희가 스마트스토어에서 물건을 사면 2초 안에 우리가 네이버에서 물건을 샀다는 정보를 볼 수 있고, 또한 네이버페이로 물건을 구매해도 2초 안에 우리가 사용한 네이버 포인트 금액이 차감 되는 걸 확인할 수 있습니다, 즉, 스마트스토어나 네이버페이는 실시간 서비스에 Hadoop을 사용하지 않습니다, 적어도 네이버 유저들이 내가 산 물건을 확인하는데 하루가 걸리는 걸 참아줄 때까지는 Hadoop을 사용하지 않을 겁니다. (TMI 일 수 있지만 제 인내심의 한계는 5초입니다)
그렇다면 Hadoop은 어디서 어떤 용도로 사용될까요?
먼저 Hadoop은 빅데이터 분석에 사용될 수 있습니다. Hadoop은 아주 빠른 속도로 데이터를 찾을 수 있고, 위의 예제에서는 그냥 단순히 ‘강릉 시민 명부’ 를 찾는다고 예시를 들었지만, 조금 더 자세히 설명하자면 우리는 각 공무원들에게 ‘강릉 시민들 정보를 다 줄 필요는 없고 그냥 강릉 시민들의 평균 연봉만 계산해서 알려줘요’, 혹은 나아가서 ‘나이 별 강릉 시민들의 평균 연봉을 알려줘요, 아 참고로 강릉 시민은 거주 지역이 강릉이고 적어도 강릉에서 5년 이상 산 사람들로 정의 할께요’ 와 같은 구체적인 통계 명령도 줄 수 있습니다. 물론 속도는 여전히 500배이기 때문에, 서비스에서 사용하는 일반적인 DB를 통해 계산했다면 10 시간이 걸렸을 통계도 72초면 결과가 나올 겁니다. 즉, Hadoop을 통해 우리는 빠르고 편하게 데이터 분석이 가능합니다.
zeppeline 사용자들은 네이버 쇼핑에서 가장 많은 돈을 쓴 상위 5% 유저는 한 달에 얼마를 썼을까? 네이버 플러스에 가입한 유저는 가입하지 않은 유저 보다 얼마나 더 많은 물건을 살까? 리뷰를 자주 작성하는 유저는 평균적인 유저 보다 많은 소비를 하는가? 한달에 교환/환불을 10번 이상 하는 유저는 총 유저의 몇 퍼센트를 차지하는가? 와 같은 다양한 질문들에 대한 답을 아주 빠르게 (위에서 말한 500배의 속도로) 구할 수 있습니다.
또한, 이번에 타임라인 (네이버 쇼핑 구매 이력) 서버를 새로 개발하며, 데이터베이스 서버도 교체하는 작업이 있었는데, 새로운 데이터베이스에 기존 쇼핑 이력 데이터를 새로 저장하기 위해 FDC (Naver Hadoop)이 사용 되었습니다. 기존 데이터베이스 서버는 기존 타임라인에서 사용하는 데이터만을 추출해서 저장했기에 새로운 타임라인이 요구하는 다양한 데이터가 담겨있지 않았고, 그렇기에 데이터를 기존 DB에서 옮기는 것이 아닌, FDC에서 가져와야 했습니다. FDC는 서비스 별로 분산 된 원천 데이터베이스로부터 분석을 위해 데이터를 통합한 데이터베이스이기 때문입니다.
계속 강릉 공무원 이야기만 하기는 걱정되어 실제 지금 검토 중인 업무를 예를 들어 설명하자면, 네이버 쇼핑에서 물건을 산 후 리뷰를 작성하지 않은 회원들에게 리뷰를 작성해 보라는 알림을 보내기 위해서 FDC를 사용할 예정에 있습니다. 위의 예시에서 공무원들은 한국 국민 리스트에서 강릉 시민 리스트를 찾았지만, FDC는 네이버 파이낸셜 회원들 리스트에서 리뷰 미 작성 유저 리스트를 찾을 겁니다. 😉
비 개발자를 위한 개발 이야기는 계속해서 연재 예정에 있습니다. 다음 편은 kafka로(많이 들어보시지 않으셨나요!) 예정을 하고 있고 기획자 분들이 실제로 궁금해 하시는 부분 위주로 글을 쓰기 위해 여러분의 제안을 적극 반영할 예정입니다, 여러분의 제안이나 질문은 언제나 환영입니다, 여러분의 다양한 의견을 기다리며 이번 글을 마치겠습니다.
