2011년 북미 아파치콘 참가 후기

2011년 북미 아파치콘(ApacheCon NA 11)에 다녀왔습니다. 한국에 들어와서 밀린 업무를 시작했습니다. 다녀오고서 많은 생각이 들었습니다.

다양한 발음

첫째로 떠오르는 건, 사람들의 말을 알아듣기가 꽤 힘들었습니다. 아파치콘은 세계의 오픈소스 개발자들이 모인 자리로, 발음이 정말 다양합니다. 남미와 아시아, 유럽에서 온 사람들의 발음이 서로 다릅니다. 자신의 발음을 얼마나 미국식에 가깝게 하느냐 보다, 어떻게 그 다양한 발음들을 알아듣느냐가 더 중요합니다. 제가 발음은 좀 엉망으로 해도 사람들은 잘 알아들었습니다. 이런 경험은 기존 교육 방법으로는 쉽게 할 수 없는 지라, 좀 더 전문적인 교육이 필요하지 않은가 의문이 들었습니다.

자신감, 어휘, 문법의 중요성

이야기를 나누면서 자신감과 어휘, 그리고 문법의 중요성을 느꼈습니다.

자신감이 없는 사람의 발표는 소리가 어물어물하여 도무지 알아들을 수가 없었고, 양해를 구하는 말을 하며 발음에 신경을 쓰느라 진도가 나가지 않아 듣기에 참 피곤했습니다. 발음이 어색해도 당당하게 크고 빠르게 말하는 사람의 내용을 귀담아 들을 수가 있었습니다.

또한 굉장히 한정된 분야의 이야기를 나누기 때문에 아주 다양한 어휘를 배울 필요는 없었지만, 여전히 어휘는 중요했습니다. 우리가 자주 쓰는 기술 용어들의 영어 어휘와 일반 회화에서 쓰는 정도의 어휘는 익혀두어야 합니다.

문법은 기본 중의 기본입니다. 어휘를 아무리 잘 늘어놓아도 말의 앞뒤가 맞지 않는다면 이해하기에 굉장히 힘이 듭니다. 이런 부분이 힘든 한 일본인은 아예 대본을 써놓고 와서 읽는 모습도 보았습니다. 문법을 떠올리느라 시간을 허비하는 것보다는 훨씬 나았습니다.

오픈 소스, 오픈 토론

발표 방식은 어차피 다른 기술 발표들과 크게 다르지 않았습니다. 사람들은 자리에 앉아 연단을 바라보고. 강사는 연단에서 서서 화면에 발표자료를 띄워놓고. 화면을 넘겨가며 설명을 하는 바로 그 전통적인 방식입니다.

오히려 크게 차이가 난 것은, 열린 토론 자세였습니다. 일반적으로 상업 기술에 대한 자리는, 핵심 구현 방법에 대한 이야기를 잘 나누지 않고 그저 어떻게 쓰는지와 성능이 어떠한지, 얼마나 기능이 다양한지에 대한 홍보 정도에 그치는 경우가 많습니다. 하지만 오픈소스 기술에 대한 토론은 어차피 모두 공개된 기술에 대하여 논하는지라, 더 깊은 수준의 알고리즘과 구현 단계 등에 대해 논할 수 있었습니다.

일례로, 마이크로소프트가 오픈소스 분산처리 기술인 하둡에 대한 발표를 할 때가 인상적이었습니다. 도대체 무슨 개선점을 반영시켰냐는 질문에 마이크로소프트의 담당자는 꿀먹은 벙어리가 될 수 밖에 없었습니다. 아무리 좋은 기술을 만들어도, 오픈하지 않으면 더 깊은 단계에 대해서 논의할 수 없습니다.

인맥

핵심 개발자들과의 인맥을 쌓은 점도 커다란 수확입니다. 아침 8시부터 저녁 11시까지 참가한 날도 있었을 정도였고, 그 때마다 핵심 개발자들과 만나서 질문도 하고 기분에 대해서 묻기도 하니 제법 친근해졌습니다. 루씬의 핵심 개발자와는 명함도 나누었고, 발표 제의에 수락까지 받아냈습니다. 우리와 비슷한 문제를 겪고 있는 회사의 핵심 개발자와도 의견을 나누고 명함을 주고받을 기회가 있었습니다.

장벽들

가장 큰 어려움을 겪은 부분은 역시 언어, 음식과 일정 부분이었습니다. 영어에 아주 익숙하지는 않아 약간의 어려움이 있었습니다. 컨퍼런스에서 제공된 음식은 주로 우리 입에 잘 맞지 않는 것들 뿐이었습니다. 식초로 절인 쌀 샐러드는 정말 지독했습니다. (…) 일정 관리가 조금 허술해, 해카톤에서는 따로 집중하는 시간이 없어서 첫날부터 굉장히 녹초가 됐습니다. 다른 발표들도 시간이 바뀌거나 라이트닝 토크가 다른 일정의 시간을 침범하는 등의 약간의 진행 문제가 있었습니다.

검색 기술

제가 관심을 가진 루씬의 활용 예는 굉장히 다양했습니다. 실험적인 프로젝트로 연인간 짝을 지어주는 서비스로 활용하거나, 체스 문제를 풀고, 상품을 추천하거나, 표절 논문을 찾아내는 경우에도 활용할 수 있다고 합니다. 물론 그 전용으로 설계된 시스템보다 훨씬 낫다는 이야기는 아니지만, 루씬의 수학적인 바탕을 활용한 생각의 전환점으로 삼기에 충분한 발표였습니다. 회사에서 추구하는 실시간 분석에도 참고할만한 바였습니다.

새롭게 출시될 루씬 4에 대한 발표도 굉장히 인상적이었습니다. 색인 자료구조 개선으로 인해 검색 성능이 향상되고, 멀티스레드를 원활히 사용하여 색인 성능을 높아졌습니다. 이를 구현하면서 겪은 고충에 대해서도 해카톤에서도 핵심 개발자를 만나서 들을 수 있었습니다. 다만 대중이 사용할 수 있기 위해서는 내년까지 기다려야 할 것으로 보입니다.

그 밖에 미트업에서는 세계의 검색엔진 개발자들이 모여서 각자가 겪는 어려움을 털어놓고, 그 해법에 대해서 함께 논의했습니다. 전 세계에 스케일링하는 서비스 제공자부터 모바일 기기의 검색 기능까지 정말 다양한 환경에 대한 이야기를 나누었습니다. 물론 그 중에서도 윈도를 사용하는 개발자는 당장 운영체제를 바꾸라는 핀잔을 들었습니다. :) 이런 실무자들의 모임을 통해서 우리가 흔히 겪을 수 있는 문제에 대해 파악하고 피해갈 방법을 모색할 수 있었습니다. 또한 우리가 택하지 않은 접근법에 대해서도 간접적으로 들을 수 있어 시야를 넓히는 데에도 도움이 됐습니다.

결론

아파치콘에 참석한 건 개발자로써 굉장히 기쁜 일이었습니다. 핵심 기술자들과 만나 기술에 대한 열린 토론을 나눴으며, 앞으로의 교류할 통로도 만들었습니다. 잘만 활용하면 이를 바탕으로 기술적 어려움을 쉽게 해결하거나 새로운 사업 기회를 개척할 가능성을 보았습니다. 비록 언어나 음식, 일정 등에서 어려움이 없지는 않았으나, 다음에 제대로 준비하여 참석한다면 더 나은 결과를 낼 수 있을 터입니다.

아파치콘 셋째 날: 세계의 검색엔진 개발자들을 만나다

안녕하세요. 넥스알(NexR)의 개발자, 최종욱입니다.

캐나다 시각으로 어제는 아파치콘 셋째날이었습니다. 여러 트랙이 열렸는데요, 그 중에서도 루시드 이매지네이션이 후원하는 루씬 트랙에 관심이 갔습니다. 물론 참석자들도 다른 트랙보다 많았구요.

가장 첫 발표는 사이먼의 루씬(Lucene) 4.0에 대한 것이었습니다. DWPT(Documents Writer Per Thread, 스레드 별 도큐먼트 색인)으로 인한 성능향상과 다양한 기록방식을 지원하는 Flex Codec 외에도 다양한 주제가 있었습니다. IndexDocValue는 인덱스 내에 필드값을 넣는 방식으로 디스크 탐색 횟수를 획기적으로 줄일 수 있었으며, 그 밖에도 디스크-메모리 성능 최적화에 관련된 구조적인 개선이 꽤 있었습니다. 출시일은 2012년 중으로 생각하고 있다고 합니다.

루씬 4.0에서 오토마톤(Automaton) 도입으로 인한 퍼지쿼리(Fuzzy Query)의 획기적인 성능 향상에 대해서도 발표했습니다. 이는 정말로 놀라운 발전이었습니다. 퍼지쿼리는 잘못 친 단어나 비슷한 단어들에 대한 검색 기술입니다. 기존에는 일일이 비슷한 단어를 하나하나 사전에서 찾느라 굉장히 느렸습니다. 이제는 텀 사전을 그래프 형식으로 작성하여 그 사이를 바로 탐색하는 방식으로 개선이 이뤄졌습니다. 정말 대단하다고 밖에 할 수 없는 개선입니다.

두번째 발표는 루시드 이매지네이션의 발표였습니다. 루씬으로 할 수 있는 다양한 것들에 대한 소개했습니다. 루씬으로 연애상대를 찾는 서비스를 작성할 수도 있고, 기계학습에 써서 범죄자를 발견할 수도 있으며, 표절 논문을 찾아내거나, 상품을 추천해주고, 번역과 언어 교육에 응용하고, 유전학에서는 루씨진(LuceGene, 검색엔진 Lucene과 유전자 Gene의 합성어)이라는 프로그램으로 생물학적 정보를 검색하고, 심지어 체스 게임까지 할 수 있는 등 다양한 활용 예를 밝혔습니다. 하지만 이 모든 것들을 루씬 바탕으로 할 수 있는 것과 이것으로 해야만 하는 것은 다른 일입니다. 그 분야에 더 적합한 전용 기술을 사용하는 것이 더 좋을 수 있으며, 루시드 이매지네이션의 발표는 루씬의 수학-논리적인 바탕 구조를 어떻게 응용할 수 있는지에 대한 사고 실험에 가까워 보였습니다. 굉장히 재미있고 도전적인 내용이었습니다.

그 밖에도 여러 발표자가 발표를 진행했습니다.

모든 발표가 끝나고, 저녁 8시부터는 미트업(Meet up)을 시작했습니다. 관심 주제에 따라 사람들이 모여서 이야기를 나누는 시간이었는데요. 세계의 검색엔진 개발자들이 한 곳에 모여 자신들이 겪고 있는 문제점과 그 해결책에 대해서 논의했습니다.

간단하게는 윈도 2003 장비를 쓰는 개발자에게 윈도를 쓰지 말고 리눅스나 맥을 쓰고 장비를 업그레이드 하라는 간단한 충고를 했습니다. 많은 개발자들이 너털웃음을 지었죠. 어떤 개발자에게는 메모리를 늘리는 것이 효율적일 것이라는 충고도 했습니다. 루씬은 메모리를 굉장히 많이 쓰거든요.

일본에서 온 한 개발자는 휴대기기에서 검색을 개발하고자 했습니다. 사이먼이 대답을 했는데, 자신도 초창기 안드로이드 기기에서 개발해본 적이 있다는군요. 굉장히 괴롭고 도전적인 작업이라고 합니다. 장비 자체의 성능도 열악한데다, 조금만 돌리면 10분만에 배터리가 모두 떨어지곤 했답니다.

그 밖에도 개발자들이 가져다가 쓸 수 있는 검색엔진 서비스를 제공하는 곳도 있었습니다. MySQL 을 뒤에 붙여서 원문을 저장하고, 솔라(Solr)들을 HA(High Availablilty, 고가용성)로 구성하고 데이터센터 간에도 복제를 하는 경우도 있었습니다. 말 그대로 상상할 수 있는 모든 상황에 루씬을 가져다 쓰더군요. 정말 활용할 곳이 무궁무진하게 많아보였습니다.

저의 경우에는 그 중에서도 좀 독특한 경우였습니다. 그 어떤 개발자도 한번에 이렇게 많은 데이터를 검색하지는 않았습니다. 테라바이트 단위라니요. 게다가 이 많은 데이터들이 실시간으로 들어오며, 실시간으로 갱신되는 두 종류의 자료에 대해 조인(Join) 작업을 해야했습니다. 이걸 비정규화(Denomalize)하는 것이 루씬계의 방식이라고 들었지만, 이 조건에서는 조인조차 할 수가 없었습니다. 그래서 조언을 구한다고 했습니다. 일시에 모든 개발자들이 난색을 표했으며, 답을 찾기가 굉장히 힘들 것이라고 했습니다. 핵심 개발자는 “그 경우에, 너는 완전히 엿됐다”라고 했지요. 그리고 다른 개발자는 복잡한 문제는 어떤 수단으로든 회피할 수 없으며, 더 깊이 생각해봐야 한다고 했습니다. 제 헛된 희망은 와르르 무너졌습니다. 밤 11시가 넘어서야 터덜터덜 방으로 들어왔습니다.

이 날을 요약하자면 이렇습니다. 루씬은 굉장히 많은 사랑을 받고 있으며, IBM, 국내의 N모사 등을 비롯한 굉장히 다양한 회사에서, 상상할 수 없을 정도로 다양한 용도로, 서버에서 모바일에 이르기까지 다양한 곳에서 사용하고 있습니다. 루씬 4.0은 현재의 루씬 3.x보다 더 많은 기능을 제공할 것이며 획기적으로 성능이 향상되었지만, 아직도 개발중이어서 불안정합니다. 그리고 제가 가진 대용량 실시간 데이터간의 조인 작업은 굉장히 복잡한 문제로, 다른 검색엔진 개발자들도 혀를 내두를 만한 문제입니다.

아파치콘 첫 날: 검색엔진 개발자 사이먼 빌노어를 만나다

넥스알(NexR)에서 아파치콘(ApacheCon)에 출장을 나왔습니다. 아파치콘은 유명 오픈소스 재단인 아파치 재단에서 여는 오픈소스 소프트웨어 컨퍼런스입니다.

아파치콘 첫 날에는 자유로운 주제로 프로그래밍을 하는 해카톤(Hackathon, 해킹+마라톤의 합성어)이 열렸습니다. 넥스알 팀은 사이먼 빌노어(Simon Willnaure)를 만나서 루씬에 대한 이야기를 나눌 수 있었습니다. 루씬(Lucene)은 굉장히 인기있는 고성능 오픈소스 검색엔진입니다. 사이먼은 루씬 4의 주요한 개발자로, 최근 루씬의 색인 성능을 몇배로 높이는 데에 지대한 공헌을 했습니다. 이번 아파치콘에서는 루씬 4의 개선점을 발표합니다.

루씬 4는 현재 개발중인 최신 버전으로, 아직 공식 배포되지는 않았습니다. 루씬 3에 비해서는 유연한 코덱(Flexible Codec)이 가장 큰 차이점으로 꼽히며, 이를 바탕으로 사이먼이 DWPT(Documents Writer Per Thread, 스레드별 문서 색인)을 구현해 색인 성능을 극한까지 끌어올렸습니다. 이 밖에도 다양한 개선점들이 있습니다. 다음은 질문과 답변 내용을 간단히 정리한 것입니다. 질문 내용을 제대로 적지 않아 순서가 엉망이 되었거나 내용이 바뀌었을 수 있습니다. 본인의 의도와 다르게 전달될 수 있습니다. 이 점을 참고하시고 읽으시길 바랍니다.

루씬 4의 가장 큰 차이점은 무엇인가?:

다양한 저장 방식을 지원하는 유연한 코덱과 DWPT로 인한 성능 향상이 큰 변화이다. 그 밖에도 다양한 변화가 있었다.

DWPT는 어떻게 색인 성능을 올릴 수 있는가?:

기존 루씬 3은 여러 세그먼트(작은 색인)들의 최적화를 위해 병합할 때, 모든 색인 요청을 멈추는 온-세상을-멈춰(Stop-the-World) 방식이었다. 따라서 병합을 위한 높은 CPU 사용률 뒤에 곧바로 많은 입출력이 뒤따라, 자원을 효율적으로 사용하지 못했다. 반면, DWPT는 각 스레드별로 세그먼트들을 관리한다. 그리고 필요에 따라 락 없이 이 세그먼트들을 꾸준히 병합하는 방식이다. 이는 CPU와 입출력의 사용 수준을 일정하게 유지하여 성능을 최대로 끌어올린다. 구현에서 가장 어려운 부분은 여러 세그먼트들을 관리하는 부분이 아니라, 다중 스레드에서 들어오는 색인의 순서 등을 일관성 있게 유지하는 부분이었다.

성능측정 장비는 굉장히 고급 사양이던데, 어느 정도가 최적의 환경인가?:

효과를 보기 위해서는 다중코어 CPU를 지원하는 고급 장비를 색인 전용으로 작동시켜야 한다. 그렇지 않으면 동시 작업하는 스레드 수가 줄어 기존과 같은 성능 문제에 시달릴 것이다. 성능측정 장비에서 환경설정을 통해 더 적은 자원을 쓰고 더 높은 성능을 낼 수 있었는데, 각 환경에 맞는 최적설정값은 앞으로 더 알아내야 한다.

DWPT를 루씬 3에서 사용할 방법이 있는가? 하위호환성 문제는 어떻게 극복할 것인가?:

트렁크 버전(개발중인 버전, 4)을 사용하라. 아쉽게도 기존의 루씬 3을 사용하던 코드는 바로 사용할 수 없다. 기존 색인을 대상으로 한 검색과 점차적으로 새로운 코덱의 색인으로 바꾸는 기능 등을 지원한다.

분산환경에서 루씬을 서비스하는 elasticsearch가 있다. 온-세상을-멈춰 문제를 DWPT와 비슷한 방식으로 풀어낸 것으로 보인다. 어떻게 생각하는가?:

큰 그림에서 보자면, 둘은 비슷한 면이 있다.

HDFS 코덱도 언급되던데, 그 가능성과 성능은 어떠할까? 혹시 이를 바탕으로 루씬 4도 분산환경을 지원할 것인가?:

HDFS 코덱은 다른 사람이 구현 중이며, 자세한 내용은 아직 잘 모르겠다. 루씬 4는 분산환경을 지원하지 않을 것이다. 분산환경은 다뤄야 할 문제가 너무나도 많다. 앞으로도 라이브러리의 핵심 기능에 집중할 것이다.

이 밖에도 자연스럽게 다른 내용들에 대해서도 이야기를 나누었습니다. 하지만 이에 대한 내용은 후에 이어질 사이먼의 발표로 대신하기로 합니다. :) 앞으로 다가올 그의 발표에 모두 귀를 기울여주시기 바랍니다.

루씬에 대한 사이먼의 놀라운 공헌에 박수를 보냅니다. 그리고 루씬 4의 개선점들을 멋지게 발표할 수 있기를 기대합니다.

iCal의 삭제가 구글에 적용되지 않아, iCloud로 넘어가다

회사에서 구글 캘린더를 사용하여 전사적으로 일정을 관리합니다. 그리고 저는 맥에서 iCal과 연동하여 일정을 관리합니다.

해외 출장을 갈 일이 생겨, 출장 일정을 구글 캘린더로 관리하려니 다중 시간대를 제대로 지원하지 않는 문제가 생겼습니다. 보기에도 불편했고, 이벤트의 시간이 정확히 맞지 않아서 고생했습니다. 반면, iCal은 이러한 문제를 제대로 해결했습니다. 두 시간대를 오가면서 보기에도 편리했고, 각 이벤트에 대한 시간도 맞아들어갔어요. 하지만 iCal에서 삭제한 내용이 구글 캘린더에 적용이 되지 않고 멋대로 다시 생겨나는 문제가 드러났습니다.

그에 대한 설명과 해결책을 찾아보았으나, 한국어 문서에서는 찾기가 힘들었습니다. 그래서 구글의 영문 설명을 제 나름대로 해석해보았습니다.

맥 OS의 iCal에서 지워진 이벤트들이 구글 캘린더에서는 안 지워집니다

일부 구글 사용자들이 iCloud 동기화를 설정하면 iCal과 구글 캘린더의 내용을 동기화하는 과정에서 구글 캘린더 내용이 의도치 않게 사라졌습니다. 이에 따른 대응으로, 우리는 iCal의 삭제 요청이 올 때 정보 삭제를 막았습니다. 나중에 새로 공지할 때 까지, 맥의 iCal에서의 어떤 이벤트 삭제도 구글 캘린더의 이벤트를 삭제하지 않지만, 이벤트 생성이나 기존 이벤트에 대한 수정 등의 다른 모든 요청들은 제대로 동기화될 것입니다. 우리는 애플 사에 연락했으며, 이 문제에 대해서 활발히 작업하고 있습니다. – 이 문제에 대한 본사의 주의를 환기시켜주셔서 감사드리며, 앞으로 보고를 드리겠습니다.

우회 방법으로, 이벤트를 지울 때에는 웹 버전의 구글 캘린더 (calendar.google.com) 를 사용기를 권합니다 – 웹 캘린더에서 변경한 모든 내용은 당신의 iCal에 제대로 동기화될 것입니다.

http://www.google.com/support/calendar/bin/static.py?page=known_issues.cs&&hl=en (영문 원문)

애플의 버그로 인해서 구글 사용자들이 문제를 겪자, 구글 서버에서 이 버그를 막느라 생긴 부가적인 버그란 설명입니다. 빠른 시일 내에 해결을 하겠다고는 하는데, 당장 제 해외 출장에 쓸 수는 없는 노릇이었습니다.

결국 울며 겨자 먹기로 iCloud의 달력 기능을 사용했습니다. 맥북-아이폰-아이패드에서는 완벽하게 동기화가 되며, 구글에서 사용할 때 보다 응답성도 훨씬 뛰어납니다. 반면에 회사의 다른 사람들과 공유하기에는 약간 문제가 있을지 걱정이 됩니다.

NoSQL로 구현하는 대용량 검색

정보량이 기하급수적으로 증가하여 테라, 페타급의 정보가 등장함에 따라 검색 기술은 더욱 중요해지고 있다. 기존의 검색기술로는 이러한 정보를 다루는 데에 분명히 한계가 있다. 반면, NoSQL은 분산 시스템을 활용하여 대용량 자료를 값싸게 다루는 데에 적합하다. 이러한 NoSQL을 활용하여 대용량 정보 검색을 구현하는 이론적 배경을 살펴본다. 그 실제 사례들과 부딪힌 한계 등에 대해서도 살펴본다.

1. 테라, 페타급 정보의 등장

요즘 들어서 한국에서도 트위터나 페이스북을 쓰는 모습을 어렵지 않게 볼 수 있다. 마치 문자 메시지처럼 하루에도 몇번씩 글을 남기고 많은 친구들과 이야기를 나누는 것이 자연스러워졌다. 이렇게 겉으로 보기에 단순해보이는 서비스도, 알고 보면 수억명이 모여서 이야기를 나누는 카페와 같이 북적이는 곳이다. 이런 정보들이 한 곳에 모이면 전에 볼 수 없었던 규모로 커지곤 한다. 테라바이트(1 Terabyte = 1,024GB)급 정보를 다룬다는 이야기는 기업시장에서 나오기 시작한 지 오래고, 트위터나 페이스북 같은 다국적 기업에서는 페타바이트(1 Petabyte = 1,024TB)급 정보들도 화제가 되고 있다.

2. 기존 검색 기술의 실패

기존 검색기술들은 테라바이트가 아닌, 기가바이트급 정보를 다루기에도 벅찬 모습을 보인다. 가장 널리 쓰이는 오픈소스 검색엔진인 아파치 루씬(Apache Lucene)조차도 10GB 이상의 정보에서는 검색 성능이 정보량에 비례하여 떨어지는 것을 확인할 수 있다.


이러한 용량의 한계 문제를 해결하고자 분산환경에서 루씬을 서비스하는 프로젝트들도 많이 생겨났다. 대표적으로 주목받는 것이 엘라스틱서치(elasticsearch) 일 것이다. 하지만 이러한 서비스들도 테라바이트를 제공하는 정도에서 그칠 수 밖에 없다.

이러한 기존 구조의 근본적인 한계는 엘라스틱서치의 개발자, 김치(kimchy)의 2011년 베를린 버즈워즈 발표에서 잘 드러난다. 루씬과 같은 전통적인 검색엔진들은 문서의 양에 따라서 출현 목록을 나누는, 문서 기반 구획법(Document based partitioning)을 사용하고 있다. 이 방법은 구조적으로 단순하며, 분산에 용이하고, 효율적으로 통신망을 사용하는 등의 장점이 있다. 그러나 결정적으로 정보의 양에 비례하여 검색 시간이 길어지는 문제가 있다.

con: O(K*N) disk seeks for K term on N shards

단점: N개의 샤드에 위치한 K개의 용어에 대해 디스크를 O(K*N) 번 탐색한다

용어 기반 구획법(Term based partitioning)은 용어를 기준으로 삼아 출현 목록을 나눈다. 문서 기반 구획법에 비하여 통신망의 과다한 사용, 문서 부가정보 관리 등이 어려운 등의 문제가 있다. 그럼에도 불구하고 다음과 같은 장점이 대용량 검색에선 빛난다.

pro: O(K) disk seeks for K term query

장점: K개의 용어 질의에 대해 디스크를 O(K) 번 탐색한다

김치는 이런 용어 기반 구획법을 이용한 제품의 예로 리악 서치(Riak Search)와 루산드라(Lucandra), 그리고 솔란드라(Solandra) 등을 언급하고 있다. 아직은 많이 쓰이지 않는 제품들이다. 이 제품들은 대체로 NoSQL을 활용하고 있다. 그렇다면 NoSQL은 무엇이며, 어째서 대안으로 주목받는가.

3. NoSQL의 등장

웹에서 대용량 정보들이 등장함에 따라, 몇 대의 대형 기계에서 처리하는 기존의 방식으로는 정보를 모두 수용하기가 점점 힘들어졌다. 흩어져 있고 증발하기 쉬운 웹 정보의 특성상, 금융거래와 같은 강력한 조건을 감시해야 할 필요도 없었다. 이런 정보를 다루기 위해, 다소 느슨하면서도 값싼 여러 기계를 활용하는 새로운 방식이 떠올랐다. 이러한 느슨한 분산 데이터베이스를 NoSQL이라고 부른다. 이론적 배경에 관련한 더 자세한 내용은 위키백과의 NoSQL 설명을 참조하기 바란다.

4. NoSQL은 어떻게 대용량 검색에 대응하는가

검색엔진의 기본 자료구조는 역색인(Inverted Index)이다. 역색인은 책의 뒷편에 있는 색인에 비교할 수 있다. 우선 원하는 용어를 찾고, 그 아래의 목록에 있는 페이지들의 제목을 살펴보며, 원하는 페이지를 찾아가는 방식과 정확히 일치한다. 이를 위해 용어를 모아놓은 용어 사전(Term dictionary)과 출현 목록(Posting list), 그리고 문서(Document)를 구현해야 한다.

NoSQL 중에서도 구글의 빅테이블(BigTable)과 유사한 제품들은 이러한 역색인을 구현하기에 충분한 자료구조를 갖추고 있다. 바로 정렬된 사전(Sorted dicitonary) 방식이기 때문이다. 이 정렬된 사전에서는 출현 목록을 바로 제공하지 않는다. 정렬의 기준이 되는 항목에 문서의 시간을 추가하면 바로 출현 목록을 풀어서 늘어놓은 꼴이 된다. 실제 문서 내용들은 고유번호를 매겨 따로 저장하면 그만이다.

NoSQL의 성능은 O(log n)과 같거나 뛰어나다고 보는 편이 타당할 것이다. 그리고 이러한 성능은 바로 역색인과 같은 수준으로 매우 뛰어나다.

이러한 자료구조의 특성을 가지면서 대용량의 정보를 다루기는 굉장히 어렵고 비싼 일이다. NoSQL은 바로 이런 문제들을 해결하기 위한 제품으로 개발되었으니 여기에 대해서 더는 골치아프게 고민할 필요가 없다. 어떤 기계가 고장이 나도 서비스에 중단이 없으며, 용량이 계속 늘어나거나 성능이 떨어지면 그저 새로운 기계를 추가하면 된다. 물론 제품에 따라서 약간의 관리가 더 필요한 경우도 있다.

5. 적용이 가능한 NoSQL 제품들

위에서 언급한 바와 같은 특성을 가지는 NoSQL 제품은 그리 많지 않다. 대표적으로 빅테이블을 모방한 HBase와 아마존의 심플DB(SimpleDB)를 모방한 카산드라(Cassandra)가 있다. 그 중에서도 HBase는 하둡(Hadoop)과 연동이 자연스럽고 메타정보를 수정하기 쉬운 등의 장점이 있다고 한다.

이들 오픈소스 제품에 비해서 아마존의 심플DB는 사용하기에 더 용이하지만, 그 용량이 한 도메인에 10GB밖에 되지 않아 루씬의 한계를 뛰어넘는 효과를 보기는 힘들어보인다.

6. NoSQL을 검색에 적용한 사례들

페이스북에서 새로운 메시징 플랫폼을 구현하면서 HBase를 사용한 사례가 있다. 역색인을 구현하는 데에도 HBase를 활용하여 실시간으로 정보를 색인하고, 색인이 됨과 동시에 검색이 가능하다. 그리고 그 용량이 굉장히 크다. 위에서 김치가 언급한 제품들도 한번쯤 둘러볼만 하며, HSearch라는 HBase 기반의 검색엔진도 개발중에 있다.

하지만, 위키백과(Wikipedia)와 같이 굉장히 큰 방대한 양의 문서 서비스도 루씬이라는 기존의 제품으로 만족하며, 트위터도 루씬을 활용하여 검색 서비스를 제공한다는 점에도 주목해야한다. 대부분의 경우, 검색은 NoSQL 기반으로 옮겨가야 할만큼의 정보를 다루지 않는다. NoSQL 기술은 루씬 등의 기존 기술에 비하여 다루기가 굉장히 어려우며 그만큼 풍부한 기능을 제공하지도 않는다. 따라서 테라바이트 이상의 정보를 다루는 굉장히 특수한 경우에 한하여, 충분한 기술적 기반을 다진 뒤에 적용을 고려해야한다.

7. NoSQL 대용량 검색의 한계와 극복방안

앞에서 김치가 지적한 바와 같이, 용어 기반 구획법은 통신망의 부하가 크며 복잡한 조건의 검색이나 문서 부가정보를 다루기에는 무리가 있을 수 있다. 이러한 요건들은 검색 결과를 가공하는 능력을 떨어뜨린다.

웹문서 검색이나 일반 문서 검색과 같이 순위가 중요한 경우에는 지금 서술한 내용만으로는 굉장히 부족할 수 있다. 페이스북의 메시지 검색 플랫폼은 그러한 정렬 과정 없이 시간순으로 나타내기에 큰 문제가 없었다. 페이지 점수에 따라서 정렬하는 등의 응용방식으로 이러한 문제를 극복할 수 있을 것으로 보인다.