참으로 오랬만에 포스팅을 합니다. 거의 1년 넘게 포스팅을 안 했던것 같습니다. 오랬만에 쓰는 글이니 요즘 근황을 좀 늘어놓는다면, 처음에 시작한 스타트업인 음악 로그 분석 사업은 제대로 못해서 여러가지 이유로 잠시 중지 된 상태입니다. 지금은 새로운 분들과 함께 마음고리라고 하는 마인드케어 서비스를 준비하고 있습니다. 새 기술도 공부도 할 겸 해서 기존에 하던 Java는 버려두고 일부러 NodeJS, AngularJS, Ionic 등을 써서 개발을 해 보는 중입니다. 상당히 재미있게 하고 있습니다.
위키북스에서 기회를 주셔서 엘라스틱서치 서적도 한권 집필 했습니다. 제목은 “시작하세요! 엘라스틱서치” 입니다.
저도 엘라스틱서치를 실무에서 제대로 사용 해 볼 기회가 제대로 없어서 깊은 내용은 다루지 못했고, 저도 공부 할 겸 검색엔진에 대해 처음 시작하시는 분들이 가볍게 개념 잡을 수있도록 돕는 목적으로 썼습니다. 사실 엘라스틱서치 홈페이지에 도큐먼트가 워낙 잘 되어 있어서 처음 개념만 잡고 나면 필요한 내용은 도큐먼트 페이지에서 다 찾을 수 있습니다. 덕분에 30대 버킷 리스트 중 하나였던 서적 집필하기도 할 수 있었네요. :)
엘라스틱서치 커뮤니티도 어느덧 가입자 수가 1000명이 넘었습니다. 조용히 은둔중이신 고수분들이 계셔서 올라오는 질문들도 답변도 잘 해주시고 여러가지로 감사하게 운영 되고 있습니다. 오프라인 모임을 기획 해 보았는데 다들 바쁘시고 해서 참여율이 높지 않아 평소에는 잘 하지 않고, 작년 6월, 그리고 올해 4월에 엘라스틱서치 교육 차 본사 개발자들이 한국에 왔을 때 잠깐 세미나좀 부탁해서 모임을 만들었습니다. 작년에는 50분, 올해는 70분 정도 참여하셨습니다. 우리 커뮤니티 내에서도 스터디 모임도 생기고 자체 세미나도 열고 싶고 한데, 아직 그러기에는 이용자가 부족한건지, 제 기획력이 부족한건지.. 여튼, 올해는 한번 했으면 좋겠다는 마음만 가지고 있습니다.
제가 처음 예상했던 것보다 엘라스틱서치에 대한 관심들은 많으신데, 실제 활발하게 질문 올리시고 하는 분들은 어느정도 사용 경험이 있으셔서 문제 해결을 위한 질문들을 많이 올리시는것 같습니다. 그러다보니 커뮤니티에 올라오는 질문들이 너무 어렵다고 궁금하긴 한데 너무 쉬운 내용이라 차마 질문은 못 하겠다고 저한테 개인적으로 쪽지 보내시는 분들도 계시고 그런데요, 좀 가벼운 질문들도 커뮤니티 내에서 많이 나누었으면 좋겠습니다. (그래야 저도 답변을 드리고 할 수 있으니까요 ^^;)
보통 이런 질문들을 자주 하셨던 것 같습니다.
엘라스틱서치에 데이터가 많아지다 보니 점점 느려진다. 적정한 서버 구성은 어떻게 해야 하는가?
사실, 이런 질문에 대해서는 엘라스틱서치를 개발한 개발자들도 답을 할 수 없다고 생각됩니다. 각자 사용 하는 데이터의 종류와 검색하는 질의 종류가 다르기 때문이죠. 몇가지 참고 할 만한 내용은 있습니다. 예를 들면
- 1개의 노드에 할당하는 메모리는 30GB를 넘지 않도록 한다.
- ES의 힙메모리 사이즈는 서버 전체 메모리의 50%가 넘지 않도록 한다.
- HD 보다는 SSD에서 성능이 월등히 향상된다.
대충 이런 것들인데, 서버가 느리고, 메모리가 부족하고, 이런 것들에 대해서 가장 명쾌한 해답은 하나인 것 같습니다.
메모리랑 CPU 늘리세요.
이거 말고 다른 답이 또 있을까요? 사실 제가 생각하는 엘라스틱서치의 가장 큰 장점이 바로 스케일-아웃이 정말 편하다는 것입니다. 서버 사용하다가 부족하면 다시 다른 서버 열고 두 서버 간에 9300번 포트만 열어놓고 클러스터 이름 같게 하고 노드 실행 시키면 끝! 특히 클라우드 환경 같은 경우는 AWS 플러그인 같은것 설치 하면 바로 바로 연동도 되고요.
또 이런 질문들도 자주 하셨는데요,
현재 DB(Oracle, MySQL 등)에 있는 데이터를 엘라스틱서치로 옮기고 싶은데 어떻게 하면 되겠는가?
특히 대기업 연구소 같은 조직에서 높으신 분들이 그런 이야기들을 많이 하는 것 같습니다.
“요즘 들어보니 몽고DB, 엘라스틱서치 같은게 유행이라던데 우리도 그걸로 바꿔보는게 어때?”
사실 오라클, MySQL 같은 관계DB는이미 나온지 30년이 되었는데도 아직까지도 널리 쓰이는 만큼 거의 완벽한 데이터 모델입니다. 잘 사용 중인 데이터를 새로운 패러다임이 나왔다고 궂이 바꿀 필요는 전혀 없다고 생각합니다. 최근에 다양한 형태의 데이터를 분석하기 위해 빅데이터라는 패러다임이 나왔는데, 관계DB와 NoSQL은 서로 사용하는 영역이 분명히 다르다는 생각이 듭니다.
빅데이터는 신문기사, SNS, 상위검색어 등과 같이 서로 형태(스키마)가 다른 여러가지 데이터를 모아서 그것들을 분해해서 그 가운데 연관성을 찾아 그것들로 통계를 내고, 랭킹을 만드는 데에 쓰입니다. 서비스의 접속 로그를 수집해서 소비자 패턴을 분석하거나, 선거철에 후보들 간에 트랜드 분석 등을 하는데 적합합니다. 이 경우 대용량 데이터를 저장하기 위한 Hadoop 같은 저장소, 그리고 분석을 위한 각종 분석 툴 (또는 검색엔진) 등을 사용합니다.
하지만 사용자들의 회원 가입 정보라던지, 거래 명세서 정보 같은 정확성이 중요한 데이터는 관계DB가 훨씬 적합하죠.
“엘라스틱서치에 데이터를 넣었더니 데이터가 유실되었다.”
“River Plugin이 버그가 좀 많은것 같다”
이런 이야기들을 심심치 않게 들었는데요, 정답은 아니지만 제 짧은 경험에 비추어 몇가지 팁을 좀 드리자면
- 엘라스틱서치는 검색 데이터에 활용하시고 원본 데이터는 따로 보관하세요.
- River 보다는 Logstash 사용을 권해드립니다.
- 원본 데이터를 Logstash에 바로 입력 가능한 JSON 형식으로 저장해서 AWS 의 S3같은 곳에 압축해서 보관하면 편합니다.
RDB에 있는 데이터를 엘라스틱서치로 옮기고자 할 때는 왠만하면 River 사용하지 마시고 직접 프로그램 짜셔서 DB에 있는 데이터를 –> JSON 텍스트 파일로 저장을 하신 다음 Logstash 로 집어 넣으세요. 그리고 저장 한 JSON 텍스트 파일은 따로 다른곳에 보관을 하세요.
저 같은 경우 어떻게 했냐 하면 매일 10GB정도 씩 되는 데이터를 엘라스틱서치에 넣기 위해 JSON 형식으로 변환 하고 Logstash로 입력 한 다음 변환 한 파일은 tar.gz 로 압축해서 AWS(아마존 웹 서비스)의 S3 버킷에 매일 날짜별로 백업하는 형식으로 운영했습니다. 텍스트 파일이라 압축하면 1/100 정도로 줄어들기 때문에 10GB도 100MB 정도로 되고 AWS의 S3는 사용료도 저렴해서 백업 해 두기도 좋습니다. 정책을 정해서 3개월 이상 된 파일은 다시 S3에서 Glacier로 옮겨서 더 저렴하게 보관하고요.
그리고 운영하시는 서비스에 따라 가능하지 않을 수도 있겠지만 ES에 저장되어 있는 데이터는 변형이나 가공을 되도록 하지 말고 무결성에 대한 기대도 하지 않고 순수하게 검색, 통계를 위해 사용 하는것이 편합니다. 뭔가 이상하면 인덱스 싹 날리고 백업 해 둔 JSON 파일 가지고 다시 새로 퍼붓고 사용하고. 다 사용하면 날리던지 서버 꺼 두고. 이러면서 운영하는 노하우를 키우는 것이 좋을 것 같습니다. 그래서 ES는 클라우드에서 사용 하는게 편합니다. 데이터 많으면 큰 서버 잠시 켜서 쓰고 다 쓰면 끄고 할 수 있으니까요.
짧은 소견으로 몇가지 내용 적어 보았습니다. 사실 지금은 NodeJS, AngularJS 를 주로 하느라 엘라스틱서치는 많이 사용하지 않고 있는데, 앞으로 또 다른 경험을 하게 되면 정리해서 자주 공유 할 수 있도록 노력 해 보겠습니다.
