태그 : pagerank
2007/08/13 Google Search Engine 해부 - 구글 페이지랭크(PageRank) 알고리즘.
2007/08/13 Google Search Engine 해부 - 1 [6]
2007/08/13 Google Search Engine 해부 - 1 [6]
2007년 08월 13일
Google Search Engine 해부 - 구글 페이지랭크(PageRank) 알고리즘.
Abstract
웹 페이지의 '중요성'은 본질적으로 주관적인 문제여서 읽는 사람의 관심사나 지식 그리고 태도 등에 의존한다. 하지만 웹페이지의 상대적 중요성에 관해서는 객관적으로 얘기할 수 있는 부분이 많다. 이 논문은 객관적이고 기계적으로 웹 페이지를 랭킹해서읽는 사람의 관심이나 기울이는 주의를 효과적으로 측정할 수 있는 수단인 "PageRank"를 소개한다. 우리는페이지랭크(PageRank)를 이상적인 랜덤 웹 써퍼(random web surfer)에 비교해 볼 것이며, 어떻게 많은 웹페이지를 대상으로 PageRank를 능률적으로 계산할 수 있는지를 설명할 것이다. 그리고 어떤 방식으로 PageRank를검색이나 사용자 네비게이션에 응용할 수 있는지도 보여 주고자 한다.
1. 도입과 동기(Introduction and Motivation)
월드와이드웹(World Wide Web)은 정보검색(Information Retrieval)에 새로운 과제를 안겨 주었다.웹은 매우 거대하며 이질적(heterogenous)이다. 현재 추산으로도 약 1억5천만 페이지 이상이 웹에 존재하며, 이 숫자는매년 적어도 두 배씩 커지고 있다. 더욱 중요한 점은, 웹 페이지들이 극단적으로 다양하다는 것이다. 예를 들면 "Joe가 오늘점심 때 뭘 먹었지?"와 같은 질문이 있는가하면 정보검색에 관한 전문적 논문집이 있기도 하다. 이런 주된 도전 과제들 외에도웹에는 익숙하지 못한 초보 사용자들과 검색 엔진의 랭킹 기능(ranking function)을 교묘히 이용하려는 많은 웹페이지들로부터 비롯되는 문제점이 있다.
그러나 웹은 다른 "평면적"인 문서 컬렉션(flat document collections)과 달리 하이퍼텍스트가 있다.하이퍼텍스트(hypertext)는 웹 페이지 자체의 텍스트 외에 링크 구조(link structure)나 링크 텍스트(linktext)같은 상당한 수준의 부가적인 정보를 제공한다.
이 논문에서 우리는, 모든웹 페이지를 보편적 "중요도" 순으로 순위를 매기기 위해 웹의 링크 구조를 사용하였다. 이 랭킹은 페이지랭크(PageRank)라하며, 검색엔진 사용자나 웹 사용자가 거대한 이질적 세계인 월드와이드웹을 빠르게 이해할 수 있게 도와준다.
1.1 웹 페이지의 다양성(Diversity of Web Pages)
학술적 인용(academic citation)을 분석한 문헌은 이미 많이 존재하지만 웹 페이지와 학술 출판물 사이에는 많은 중요한차이가 있다. 학술 논문은 철두철미하게 리뷰되지만 웹 페이지는 '품질 관리'나 '출판 비용' 없이 늘어난다. 단순한 프로그램하나만으로도 아주 많은 페이지를 손쉽게 만들어 낼 수 있으며 인위적으로 인용 횟수를 쉽게 부풀릴 수 있다. 웹 환경 속에는 그안에서 이익을 찾는 많은 벤쳐들이 있기 때문에 이들이 사용자의 주의를 끌어오는 전략 역시 검색엔진 알고리듬의 발달에 맞춰서 함께진화되어 왔다. 이러한 이유로 복제가능한 특징을 세는 방식으로 웹 페이지를 평가하려는 전략은 손쉽게 악용될 수 있다. 게다가,학술 논문의 경우는 그 갯수를 정확히 셀 수 있을 뿐만 아니라 사실상 질적인 면 및 인용 횟수 등에서 유사하고 그 목적 역시비슷하다.(대개 '지식의 몸체'를 키우기 위한 목적으로 만들어진다.) 하지만 웹 페이지는 질적인 면에서나 사용적인 측면, 인용,길이 등에 있어서 학술 논문보다 훨씬 더 다양하다. IBM 컴퓨터에 관한 애매한 질문들을 모아놓은 것은 IBM 홈페이지와 매우다르다. 운전자에게 휴대폰이 미치는 영향에 관해서 연구한 논문은 특정 휴대폰 회사의 광고와 매우 다르다. 사용자가 읽은 웹페이지의 평균적인 질은 평균적인 웹 페이지의 질보다 높다. 그것은 웹 페이지를 만들고 퍼블리슁하는 것이 매우 쉽기 때문에 웹에는사용자들이 읽지 않으려 하는 많은 저품질의 웹 페이지가 있기 때문이다.
웹 페이지에는 여러 가지 분화될 수 있는 요소가 많이 있다. 이 논문에서 우리는 그 중의 하나 - 웹 페이지의 상대적 중요성을 어떻게 추산할 것인가 - 라는 문제를 주로 다룬다.
1.2 페이지랭크(PageRank)
웹페이지의 상대적 중요성을 측정하기 위해 우리는 웹 그래프를 기반으로 웹 페이지를 랭킹(ranking)하는 방식인 페이지랭크를제안한다. 페이지랭크는 검색이나 브라우징, 트래픽 추산에 적용될 수 있다. 섹션 2에서는 페이지랭크의 수학적 기술을 다룰 것이며직관적인 정당화(intuitive justification)를 얘기할 것이다. 섹션 3에서는 5억1800만 개에 이르는하이퍼링크에 대해 어떻게 효율적으로 페이지랭크를 계산할 수 있는지 보여주고자 한다. 페이지랭크의 유용성을 테스트하기 위해 우리는구글(Google)이라는 웹 검색 엔진을 구축했다. 이것은 섹션 5에서 다룬다. 섹션 7.3에서는 페이지랭크가 어떻게 브라우징을 도울 수 있는지 보여주고자 한다.
2. 웹 상의 모든 페이지의 순위 매기기(A ranking for every page on the Web)
2.1 관련 자료
학술 인용 분석에 관해서는 매우 많은 연구가 이미 존재한다. Goofman은 과학 커뮤니티에서 일종의 유행병처럼 정보 흐름이 퍼져 나간다는 것을 주장한 흥미로운 이론을 발표하기도 했다.
웹같은 대형 하이퍼텍스트 시스템에서 어떤 방식으로 링크 구조(link structure)를 이용할 수 있는지에 관해서도 최근들어상당한 연구가 이뤄지고 있다. Pitkow는 얼마 전에 다양한 방식의 링크 기반 분석을 설명한 "월드와이드웹 생태계의특징"이라는 제목의 박사 학위 논문을 완성했다. Weiss는 링크 구조를 감안한 클러스터링 방식에 대해서 논했다.Spertus는 여러 가지 적용사례에 있어서 링크 구조로 부터 얻어낼 수 있는 정보에 관해 발표했다. 좋은 시각화를 위해서는하이퍼텍스트에 부가적인 구조가 필요하다는 연구도 있었다. Kleinberg는 웹을 서로 인용하는 행렬로 보고 그고유벡터(eigenvector)를 계산하는 방식을 기반으로 "헙 & 오쏘리티(Hubs and Authorities) 모델"이라는 흥미로운 모델을 개발했다. 마지막으로, 도서관 커뮤니티 쪽에서는 웹의 "질"이라는 것에 대해 관심을 갖고 있기도 하다.
일반적인 인용 분석 테크닉을 웹의 하이퍼텍스트적 인용 구조에 적용하고자 시도하는 것은 너무도 자연스러운 것이다. 단순하게 웹페이지에 있는 각각의 링크를 학술적 인용처럼 생각해 볼 수 있는 것이다. 야후! 같은 메이져 페이지는 야후!를 가리키는 수 만,수십 만 개의 백 링크(backlinks) 또는 인용을 갖고 있는 것이다.
야후!홈페이지가 아주 많은 백 링크를 갖고 있다는 사실은 야후! 홈페이지가 매우 중요하다는 사실을 함축한다. 사실 많은 웹검색엔진들은 어떤 페이지가 얼마나 중요한가 내지는 높은 질을 갖고 있는가를 판단할 때 백 링크 숫자를 바탕으로 가중치를 주고있다. 하지만 단순히 백 링크의 갯수를 세는 것은 많은 문제점을 갖는다. 이 문제점들은 학술 인용 데이타베이스에는 존재하지 않는웹만의 특징과 관련이 있는 것들이다.
2.2 웹의 링크 구조(Link Structure of the Web)
약간의 편차는 있지만 현재 크롤링 가능한 웹 그래프는 약 1억5천만개의 노드(node;페이지)와 17억 개의엣지(edge;링크)가 있다고 알려져 있다. 각각의 웹 페이지는 그 페이지로부터 밖으로 나가는 포워드 링크(forwardlink; outedges)와 그 페이지를 가리키는 백 링크(backlink; inedges)를 갖는다. 어떤 페이지의 모든 백링크를 다 찾아낸다는 것은 불가능하지만 페이지를 다운로드하고 나면, 포워드 링크가 무엇인지는 알 수 있다.
웹페이지가 백 링크를 몇 개나 갖느냐는 매우 다양하다. 우리가 갖고 있는 데이타베이스에 따르면 넷스케잎 홈페이지는 62804개의백 링크를 갖는데 반해 대개의 페이지들은 단지 몇 개의 백 링크만을 갖는다. 일반적으로 링크가 많이 된 페이지일수록 그렇지 못한페이지보다 더 "중요하다". 학술 인용에서도 인용의 횟수를 세는 단순한 방법이 미래의 노벨상 수상자를 예측하는 데 사용될 수있다. 페이지랭크는 인용 횟수를 세는 방식 이상의 훨씬 더 정교화된 방법을 제시한다.
페이지랭크가 흥미로운 이유는 인용 횟수가 일반적인 의미의 중요성과 일치하지 않는 경우가 매우 많기 때문이다. 어떤 웹 페이지가야후!에 링크가 되어 있다면 그 페이지는 오직 하나의 백 링크밖에 없지만 그 링크는 매우 중요한 링크다. 야후!에 링크된 그페이지는 다른 별 볼 일 없는 여러 곳에서 링크된 페이지보다 더 높은 순위를 가져야 한다. 페이지랭크는 링크 구조만을 사용해서어떻게 "중요성"을 정확히 추정해낼 수 있을까를 시도한 것이다.
2.3 링크를 통한 랭킹의 전파(Propagation of Ranking through Links)
위의 논의를 기초로, 우리는 페이지랭크에 대한 직관적 기술을 다음과 같이 할 수 있다: 어떤 페이지가 높은 랭크의 백 링크를 많이가질수록 그 페이지의 랭크도 올라간다. 이것은 어떤 페이지가 많은 백 링크를 갖는 경우와 몇 개의 높은 랭크값 백 링크를 갖는경우 모두를 포괄하는 것이다.
2.4 페이지랭크(PageRank)의 정의
어떤 웹 페이지를 u라고 하고 u 페이지가 가리키는 페이지들의 집합을 Fu, u 페이지를 가리키는 페이지의 집합을 Bu라하자. Nu = |Fu|라 하고, 이것은 u 페이지로부터 나가는 링크의 갯수, 즉 Fu의 갯수다. 그리고 노멀라이제이션에사용되는 팩터를 c라고 하자.(노멀라이제이션은 전체 웹 페이지의 랭크 총합을 일정하게 하기 위해서다.)
일단, 단순 랭킹 R을 정의하는 것에서 출발해 보자. 단순 랭킹 R은 페이지랭크(PageRank)를 약간 단순화시킨 버전이다.
위 식은 전 섹션에서 얘기한 직관을 공식화한 것이다. 어떤 페이지가 가리키는 페이지들의 랭크에 균일하게 기여하기 위해,링크가 나가는 페이지의 랭크를 그 페이지의 포워드 링크 갯수로 나누고 있다는 점에 주의하자. 그리고 c는 1보다 작아야 하는데,c < 1인 이유는 포워드 링크가 없는 페이지도 많이 있기 때문에 그런 페이지들의 가중치는 시스템 속에서 사라질 수 있기때문이다.(섹션 2.7을 참조하라.) 위 등식은 재귀적(recursive)인 식이지만 초기 랭크 집합을 주고 수렴할 때까지연산을 함으로써 계산할 수 있다.
그림 2 단순화된 페이지랭크의 계산
그림 3 정상상태를 이루고 있는 페이지들
그림 2는 한 쌍의 페이지로부터 다른 한 쌍의 페이지로 랭크가 전파되어 나가는 것을 보여주고 있다. 그림 3에서는 일군의 페이지들 사이에서 일정한 정상상태(steady state)의 솔루션을 이루고 있는 것을 볼 수 있다.
이것을 다른 방식으로 표현해 보자. 각 행과 열이 웹 페이지에 대응하는 정방행렬을 A라 하자. 그리고, 페이지 u에서 v로 가는 연결(edge)이 있다면 Au,v = 1/Nu이라 하고, 엣지가 없다면 Au,v는 0이라 하자. R을 웹 페이지들의 벡터로 생각해 보면, R = cAR이된다. 그러므로 R은 A의 아이겐벡터(eigenvector; 고유벡터)가 되고 아이겐밸류는 c이다. 사실, 우리가 원하는 것은A의 지배적 고유벡터(dominant eigenvector)다. 이것은 A를 여러 비퇴화적 시작 벡터(nondegeneratestart vector)에 반복적으로 적용함으로써 계산될 수 있을 것이다.
그림 4 랭크 싱크
위에서 살펴 본 단순화된 랭킹 함수는 약간의 문제가 있다. 두 페이지가 서로서로 가리키고 있으며 다른 페이지로는 연결되어있지 않은 경우를 생각해 보자. 다른 웹 페이지가 그 두 페이지 중 하나를 가리키고 있는 경우, 반복연산(iteration)이진행되면서 그 루프에서는 랭크가 계속 축적될 뿐 외부로 전혀 분산하지 못 한다.(왜냐하면 외부로 나가는 엣지가 전혀 없으므로.)루프는 일종의 함정을 형성하게 된다. 우린 이것을 랭크 싱크(rank sink)라 부른다. 랭크 싱크로부터 초래되는 문제를해결하기 위해, 우리는 랭크 소스를 도입한다.
정의 1:
랭크의 소스에 해당하는 웹 페이지의 벡터 중 하나를 E(u)라 하자. 그러면 일군의 웹 페이지들의 페이지랭크는 다음 식을 만족하며 ||R||1 = 1(||R||1은 R'의 L1 norm)이고 c가 최대값을 가질 때의 R'이다.역자주
E가 모두 다 양수이면 등식의 균형을 위해서 c 값이 줄어들어야만 한다는 것에 주의하자. 그러므로 이 테크닉은 소멸계수(decay factor)에 해당한다. 위 식을 행렬 용어로 표현하면 R' = c(AR' + E)이고, ||R||1 = 1이므로 이 식은 R' = c(A + E x 1)R'로 다시 쓸 수 있다. 여기서 1은 1로만 구성된 벡터다. 그러므로, R'은 (A + Ex1)의 아이겐벡터라고 할 수 있다.
역자주 L1 norm은(a,b,c,d,e,..)라는 벡터가 있을 때 (a+b+c+d+e+..)의 값을 의미합니다. '소스'(source)와'싱크'(sink)는 그래프 이론에서 나온 용어로, 아웃엣지가 없는, 즉 밖으로 나가는 링크가 없는 것을 싱크라 하고 반대로인엣지가 없는, 즉 안으로 들어 오는 링크는 없고 밖으로 나가는 것만 있는 것을 소스라 합니다.
2.5 랜덤 써퍼 모델(Random Surfer Model)
위와 같은 페이지랭크의 정의는 그래프 상의 랜덤 워크(random walks)라는 또 하나의 직관적 기반을 갖고 있는것으로 볼 수 있다. 단순화된 버전의 페이지랭크는 웹 그래프 상에서 랜덤 워크의 확률분포에 해당한다. 직관적으로 생각해 보면이것은 "랜덤 써퍼"의 행동을 모델링한 것으로 볼 수 있다. "랜덤 써퍼"는 무작위로 일련의 링크들을 클릭해 나간다. 하지만실제 웹 써퍼가 작은 루프에 빠져 들었을 때도 계속해서 그 루프 내를 맴돌 가능성은 거의 없다. 대신, 그 써퍼는 다른 페이지로점프하려 할 것이다. 부가적 팩터인 E는 바로 그 행동을 모델링한 것으로 볼 수 있다. 즉, 써퍼는 주기적으로 "지루해지고"E의 분포에 기반해서 선택된 무작위 페이지로 점프하는 것이다.
지금까지 우리는 E를 사용자 정의 퍼래미터로 생각했다. 대부분의 테스트에서 우리는 E를 모든 웹 페이지에 걸쳐 동일하게α값을 갖는 것으로 했다. 하지만, 섹션 6에서는, E 값이 달라짐에 따라 페이지의 랭크가 어떻게 "사용자화"될 수 있는지를보여줄 것이다.
2.6 페이지랭크 계산(Computing PageRank)
페이지랭크를 계산하는 것은 규모의 문제를 무시한다면 아주 간단명료하다. S를 웹 페이지의 벡터(E 같은)라 하자. 그러면 페이지랭크는 다음과 같이 계산될 수 있을 것이다.
R0 <--- S
loop:
Ri+1 <--- ARi
d <--- ||Ri||1 - ||Ri+1||1
Ri+1 <--- Ri+1 +dE
δ<--- ||Ri+1 - Ri||1
while δ> ε
d 팩터가 수렴속도를 빠르게 하고 ||R||1을 유지하는 것에 주목하자. 또 다른 노멀라이제이션 방법은 적절한 팩터를 R에 곱하는 것이다. d의 사용은 E의 영향에 작은 효과만 미칠 것이다.
2.7 댕글링 링크(Dangling Links)
이 모델과 관계되는 이슈 중 하나는 댕글링 링크 문제다. 댕글링 링크란 외부로 나가는 링크가 없는 페이지를 가리키는 링크를뜻한다. 댕글링 링크가 모델에 영향을 주는 이유는, 이것의 가중치가 어디로 분산되고 있는지가 불분명하고 또 아주 많은 댕글링링크가 존재하기 때문이다. 종종 댕글링 링크가 가리키고 있는 페이지는 다운로드되지 않은 페이지일 수도 있다. 웹을 통째로샘플링하는 것은 어렵기 때문이다.(현재 우리가 다운로드한 2400만 페이지에는 아직 URL이 가리키는 문서가 다운로드되지 않은5100만 개의 URL이 있는 상태다. 즉, 5100만 개의 댕글링 링크가 있는 것이다.) 댕글링 링크는 다른 페이지의 순위에직접적으로 영향을 주지는 않기 때문에, 우리는 모든 페이지랭크가 계산될 때까지 댕글링 링크를 그냥 제거했다. 페이지랭크 계산이다 끝난 뒤에, 즉 큰 문제를 일으키지 않게 되었을 때, 댕글링 링크를 다시 첨가할 수 있다. 링크가 제거됨으로써 그 페이지에있는 다른 링크의 노멀라이제이션이 영향받을 수는 있지만 크게 변화되는 건 아니다.
3 임플리멘테이션(Implementation)
스탠포드 웹 베이스 프로젝트(Stanford WebBase project)의 일환으로, 우리는 현재 총 2400만 페이지의리파지터리(repository)를 갖고 있는 완전한 크롤링 & 인덱싱 시스템을 구축했다. 웹에 있는 모든 URL을 찾을수 있게 하기 위해서는 모든 웹 크롤러가 URL 데이타베이스를 유지하고 있어야 한다. 웹 크롤러는 페이지랭크의 임플리멘테이션을위해, 크롤링하면서 만나는 링크의 인덱스만 구축하면 된다. 작업 자체는 단순한 것이지만 볼륨이 거대하기 때문에 쉽지 않다. 예를들어, 현재 우리가 구축한 2400만 페이지의 데이타베이스를 5일 안에 인덱싱하기 위해서는, 초당 50 페이지를 프로세싱해야한다. 보통의 페이지 하나에 통상 11개의 링크가 있으므로(무엇을 링크로 셀 것인가에 따라 달라질 수는 있다.) 초당 550개의링크를 프로세싱해야 하는 것이다. 또한, 우리가 구축한 2400만 페이지의 데이타베이스는 7500만 개의 각기 다른 URL을참조하고 있으며, 각각의 링크는 반드시 서로 비교되어야만 하는 것이다.
웹에 깊숙히 그리고 미묘하게 존재하는 결함들에 유연하게 대응할 수 있는 시스템을 구축하기 위해서 많은 시간이 걸렸다.웹에는 한없이 커다란 싸이트, 페이지, 심지어 끝없이 계속되는 긴 URL들이 있다. 상당수의 웹 페이지가 잘못된 HTML을 담고있기 때문에 파서(parser)를 디자인하는 것이 까다로왔다. 예를 들어, 우리는 URL에 /cgi-bin/이들어 있는 경우 크롤링하지 않았다. 물론, 웹은 계속해서 변하고 있기 때문에 "전체 웹"을 정확하게 샘플링한다는 것은불가능하다. 싸이트가 다운되는 경우도 있고, 어떤 경우는 자신의 싸이트를 인덱싱되지 않도록 해 놓기도 한다. 이런 모든 점에도불구하고, 우리는 공개적으로 접근가능한 웹의 실제 링크 구조를 상당한 수준으로 표현했다고 생각하고 있다.
3.1 페이지랭크 임플리멘테이션
우리는 각각의 URL을 각기 유니크한 정수로 변환하고, 하이퍼링크의 페이지를 구분할 수 있도록 모든 하이퍼링크를 페이지의 정수 ID를 이용해서 데이타베이스에 저장했다. 임플리멘테이션에 관한 자세한 사항은 구글 검색엔진의 해부학 논문에서 밝혔다. 보통, 페이지랭크는 다음과 같은 식으로 임플리멘테이션했다.
먼저, 부모 ID(Parent ID)를 이용해서 링크 구조를 정렬한다. 그 다음, 앞에서 말한 것과 같은 이유로 링크데이타베이스에서 댕글링 링크를 제거한다. (몇 번의 반복 작업만으로도 대부분의 댕글링 링크를 제거할 수 있다.) 그 다음, 랭크값을 초기화한다. 초기화 값을 어떻게 할 것인가는 어떤 전략을 갖고 있느냐에 따라 달라진다. 수렴할 때까지 반복작업을 계속할생각이라면, 일반적으로 초기값은 최종값에 영향을 미치지 않는다. 단지 수렴 속도만 빠르게 할 뿐이다. 하지만 초기값을 잘선택하면 수렴과정의 속도를 높일 수 있다. 우리는 초기 할당값을 신중하게 선택하면 제한적 횟수의 많지 않은 반복 작업만으로도아주 좋은 결과를 얻거나 더 나은 퍼포먼스를 만들어 낼 수 있다고 믿고 있다.
각 페이지의 가중치에 메모리를 할당한다. 우리는 단정도 부동소수점(single precision floatingpoint) 값을 사용했고, 각각은 4바이트씩 할당했으므로 7500만 개의 URL은 곧 300메가바이트의 크기가 된다. 만약모든 가중치를 담고 있을 만큼 램이 충분치 않으면 여러 번의 패쓰(pass)를 사용해도 된다.(우리가 임플리멘테이션한 것은메모리의 절반과 2개의 패쓰를 사용했다.) 현재 진행 중인 단계의 가중치는 메모리에 저장되고, 전단계의 가중치는 디스크를 통해리니어(linear)하게 억세스한다. 또한, 링크 데이타베이스 - 즉 알고리듬 정의에서의 A - 로의 모든 억세스도 정렬되어있기 때문에 리니어하다. 그러므로 A 역시 디스크에 저장될 수 있다. 이러한 데이타 구조들이 매우 큰 크기임에도 불구하고,리니어 디스크 억세스를 통한 각 반복작업에 걸리는 시간은 보통의 웍스테이션상에서 약 6분 정도면 된다. 가중치들이 수렴하고나면, 다시 댕글링 링크를 추가하고, 랭킹을 재연산한다. 댕글링 링크를 되돌려 넣은 뒤에 필요한 반복 작업 횟수는 댕글링 링크를제거하는 데 요구되었던 횟수와 똑같다는 점에 주의하라. 그렇지 않으면, 댕글링 링크의 일부는 가중치가 0이 될 것이다.
이상의 모든 과정은 현재의 임플리멘테이션의 경우 총 5시간이 소요된다. 수렴 조건을 덜 엄격하게 하고, 더 최적화를 한다면계산속도는 더 빨라질 수 있을 것이다. 또는, 아이겐벡터를 추산하는 보다 더 효율적인 테크닉이 사용되어도 퍼포먼스가 더 좋아질것이다. 어쨌든, 페이지랭크를 계산하는 데 필요한 코스트는 풀 텍스트 인덱스를 구축하는 데 필요한 것에 비하자면 아주 사소한것이라 할 수 있다.
4 수렴 특성(Convergence Properties)
그림 5에서 볼 수 있는 것처럼, 3억 2200만개라는 큰 링크 데이타베이스를 합리적으로 감내할 만한 수준으로 수렴시키는데 필요한 반복작업은 약 52회다. 데이타의 크기가 반이라면 대략 45회면 된다. 이 그래프를 통해서, 극단적으로 큰 크기의컬렉션에서도 페이지랭크가 아주 쉽게 확장될 수 있다는 것을 알 수 있다. 스케일링 팩터가 대략 logn과 거의 선형관계를 이룬다.
그림 5 페이지랭크 연산의 수렴
페이지랭크 연산이 아주 빠르게 수렴한다는 사실로부터 파생되는 한 가지 흥미로운 점은 웹이 익스팬더양그래프(expander-like graph)라는 점이다. 이 부분의 이해를 돕기 위해서 그래프 상의 랜덤 워크 이론의 간단한개론을 살펴 보자. 자세한 것은 Motwani-Raghavan이 쓴 페이퍼를 참조하라.
그래프 상의 랜덤 워크는 스토캐스틱(stochastic)한 과정이다. 즉, 임의의 한 타임스텝에 우리는 그래프 상의 특정노드에 서 있고, 다음 타임스텝에 어떤 노드로 이동할 것인지는 균일하게 무작위적으로 분포하는 아웃엣지 중 하나를 선택해서결정하는 것이다. 만약 모든 (너무 크지는 않은) 서브셋 노드 S가 이웃(neighborhood; S에 속한 노드들로부터아웃엣지를 통해 접근가능한 꼭지점들의 집합)을 가지고 있고, 그 이웃 노드의 크기가 |S|보다 α배 이상 크다면 그 그래프는하나의 익스팬더(expander)라고 할 수 있다. 그리고 만약, 특히 가장 큰 아이겐벨류가 두 번째로 큰 아이겐벨류보다 충분히더 큰 경우, 그 그래프는 좋은 익스팬젼 팩터를 갖고 있다고 볼 수 있다. 랜덤 워크가 빠른 속도로 그래프 상의 노드들의 제한된분포로 수렴해 가면 그 그래프는 래피들리-믹싱(rapidly-mixing)하다. 또한 그래프가 익스팬더이고 아이겐벨류분리(eigenvalue separation)를 갖고 있다면 그 랜덤 워크는 래피들리-믹싱인 경우라 할 수 있다.
이상의 내용을 페이지랭크 연산과 관련 지어 보자. 페이지랭크란 본질적으로, 웹 그래프 상의 랜덤 워크의 제한된 분포로결정짓는 것이다. 어떤 노드의 중요도 랭킹이란, 본질적으로 충분히 시간이 흐른 뒤에 랜덤 워크가 그 노드에 있을 확률인 것이다.페이지랭크 연산이 로그 시간 내에 종결될 수 있다는 사실은 랜덤 워크가 래피들리 믹싱이거나 그래프가 좋은 익스팬젼 팩터를 갖고있다는 말이 된다. 익스팬더 그래프는 여러 가지 바람직한 특성을 많이 갖고 있기 때문에 웹 그래프와 관계된 연산을 함에 있어서앞으로 다양하게 활용할 수 있을 것이다.
5 페이지랭크를 이용한 검색
페이지랭크의 주된 적용처는 검색이다. 우리는 페이지랭크를 활용한 두 가지 검색엔진을 임플리멘테이션했다. 하나는 단순한타이틀 기반의 검색엔진이고 다른 하나는 풀 텍스트 검색엔진이다. 후자의 이름은 구글이다. 구글은 표준적인 IR 측정치,근접성(proximity), 앵커 텍스트(웹 페이지를 가리키는 링크의 텍스트), 그리고 페이지랭크 등의 많은 요소를 바탕으로검색 결과를 랭킹한다. 페이지랭크가 어떤 이점을 갖는지에 관한 포괄적인 유져 스터디는 이 논문의 범위를 벗어나지만, 몇 가지비교 실험과 검색 결과 샘플을 이 논문을 통해 얘기해 보려 한다.
페이지랭크의 이점이 가장 크게 활용될 수 있는 부분은 덜 특화된 질의어(underspecified queries)를처리하는 것이다. 예를 들어, "스탠포드 대학"이라는 질의어를 넣으면, 일반적인 검색엔진은 스탠포드가 들어 간 많은 페이지들을결과로 보여 줄 뿐이다. 하지만 페이지랭크를 활용하면 스탠포드 대학 홈 페이지가 순위의 가장 위로 올라 오는 것이다.
5.1 타이틀 검색
페이지랭크가 검색에 활용되면 얼마나 유용한지를 시험해 보기 위해 우리는 1600만 페이지의 제목만을 사용하는 검색엔진을만들어 보았다. 그 검색엔진은 질의어를 넣으면 문서 제목에 질의어가 들어 있는 모든 웹 페이지를 찾은 다음, 그 결과를페이지랭크를 이용해서 정렬한다. 이 검색엔진은 아주 단순한 것이고 간단하게 구축할 수 있는데, 비공식적인 시험을 해 본 결과놀랄 만큼 훌륭한 성능을 보여 주었다. 그림 6에서 볼 수 있는 것처럼 "University"라는 검색어에 대해 페이지랭크를이용한 제목 검색엔진은 대표적인 대학들의 목록을 보여 준 것이다. 이 그림은 우리가 만든 MultiQuery 시스템으로, 두개의 검색엔진에 동시에 질의를 할 수 있는 시스템이다. 그림의 왼 편에 있는 것이 페이지랭크를 기반으로 한 타이틀 검색엔진이다.검색 결과에 있는 바 그래프와 퍼센티지는 탑 페이지를 100%로 잡고 페이지의 실제 페이지랭크 값에 로그를 취한 다음노멀라이징한 값이다. 이 논문의 다른 곳에서는 계속 퍼센타일(percentile)을 사용했지만 여기서는 아닌 것이다. 그림의오른 쪽에 있는 것은 알타비스타 검색엔진이다. 알타비스타의 검색 결과를 보면 "University"라는 질의어에 맷칭되는무작위적으로 보이는 웹 페이지들 그리고 여러 써버의 루트 페이지가 보인다. (알타비스타는 퀄리티 휴리스틱으로 URL의 길이를사용하는 것 같다.)
그림 6 "University" 검색어에 대한 결과 비교
5.2 랭크 머징(Rank Merging)
타이틀에 기반한 페이지랭크 시스템이 아주 훌륭한 결과를 보여 주는 이유는, 제목을 맷칭하는 것이 페이지의 높은 프리시젼을보장하고, 페이지랭크가 페이지의 높은 품질을 보장하기 때문이다. 웹 검색에서 "University" 같은 질의를 하는 경우,사용자가 살펴 볼 페이지보다 훨씬 많은 페이지들이 존재하기 때문에 리콜은 그다지 중요하지 않다. 리콜이 중요하게 요구되는 특화된검색의 경우는 풀 텍스트에 대한 전통적인 정보검색 점수와 페이지랭크를 함께 적용할 수 있을 것이다. 구글 시스템은 그런 형태의랭크 머징을 사용한다. 랭크 머징은 아주 까다로운 문제로 알려져 있어서 우리는 그런 형태의 질의어를 합리적으로 평가할 수 있게구축하기 위해 상당한 노력을 부가적으로 기울여야만 했다. 하지만, 그런 형태의 질의어에 있어서도 페이지랭크가 상당히 도움이된다고 생각된다.
5.3 몇 가지 샘플 결과
우리는 페이지랭크를 이용한 풀 텍스트 검색엔진인 구글을 이용해서 상당히 많은 테스트를 해 보았다. 완전한 형태의 유져스터디는 이 논문의 범위를 벗어나지만, 몇 개의 샘플을 이 논문의 부록 A에 수록했다. 더 많은 질의어에 대한 결과를 원하는분은 직접 구글을 테스트 해보면 된다.
표 1은 페이지랭크에 기반한 탑 15위 페이지 목록이다. 이 리스트는 1996년 7월 시점의 결과다. 최근 다시 페이지랭크를 계산해 보았을 때는 마이크로소프트가 넷스케잎보다 조금 더 큰 페이지랭크를 보여 주었다.
표 1
5.4 커먼 케이스(Common Case)
페이지랭크의 디자인 목표 중 하나가 질의어의 커먼 케이스를 잘 처리하게 한다는 것이었다. 예를 들어, 미시건 대학의 학생관리자 기능 시스템의 이름에 "wolverine"이라는 게 들어 있었던 것으로 기억하고 있는 사람이 "wolverine"이라는검색을 한다고 하자. 우리의 페이지랭크 기반 타이틀 검색엔진은 "Wolverine Access"를 검색 결과의 첫 번째로 보여준다. 이것은 대단히 합리적이다. 왜냐하면 모든 학생들은 Wolverine Access 시스템을 사용하고 있고,"wolverine"이라는 질의를 한 사람이라면 Wolverine Access 페이지를 살펴 보려 할 가능성이 매우 크기때문이다. 그런데 Wolverine Access 싸이트가 좋은 커먼 케이스라는 사실은 그 페이지의 HTML에는 전혀 담겨 있지않다. 심지어 이런 형태의 메타 정보를 페이지 내에 담을 수 있는 방법이 있다고 하더라도, 이런 류의 평가에 있어서는 페이지를만든 사람을 신뢰하기 힘들다는 게 문제가 된다. 웹 페이지를 만드는 많은 사람들이 자신이 만든 페이지가 웹에서 가장 훌륭하고가장 자주 읽힌다고 주장할 것이기 때문이다.
wolverine이라는 것에 관해서 가장 많은 정보를 담고 있는 페이지를 찾는 것과 wolverine 싸이트의 커먼케이스를 찾는 것은 전혀 다른 일이라는 사실이 중요하다. 웹의 링크구조를 통해 텍스트의 매칭 점수를 전파해 나감으로써 어떤주제를 자세하게 다룬 싸이트를 찾아내는 흥미로운 시스템이 있다.(Massimo Marchiori. The quest forcorrect information on the web: Hyper search engines.) 그 시스템은 그런 과정을 통해가장 중심적인 경로에 포함되는 페이지들을 결과로 보여주는 것이다. 이런 방식은 "flower" 같은 질의어의 경우 좋은 결과를보여 준다. 즉, 그 시스템은 '꽃'이라는 주제를 자세히 다루고 있는 싸이트에 도달할 수 있는 경로 중 가장 좋은 것을 보여주는것이다. 이것과 커먼 케이스를 찾는 접근법을 비교해 보자. 커먼 케이스 접근법은 꽃에 관한 정보대신 꽃을 구입하는 방법만이담긴, 사람들이 가장 많이 찾는 꽃 판매 싸이트를 보여줄 지도 모른다. 두 가지 방식 모두 중요하다는 게 우리의 생각이고,일반적 목적의 웹 검색엔진이라면 마땅히 위의 두 가지 태스크 모두에 있어서 만족스러운 결과를 보여줘야 한다고 생각한다. 이논문에서는, 우리는 커먼 케이스적 접근법에만 집중하고 있다.
5.5 커먼 케이스의 하부 구성요소(Subcomponents of Common Case)
페이지랭크가 도움이 될 수 있는 커먼 케이스 시나리오가 어떤 성격을 갖는가를 생각해 보는 것은 무척 유익하다. Wolverine Access 싸이트처럼 가장 자주 사용되는 페이지 외에도, 페이지랭크는 협동적 오쏘리티또는 신뢰할 수 있는 싸이트 역시 표현해 준다. 예를 들어, 사용자는 어떤 뉴스가 단지 뉴욕 타임즈 홈 페이지로부터 직접링크되어 있다는 이유만으로 더 선호할 수 있다. 물론, 그 뉴스 페이지는 뉴욕 타임즈처럼 중요도가 높은 페이지로부터 링크되어있다는 사실만으로 매우 높은 페이지랭크 값을 갖게 된다. 이것은 일종의 협동적 신뢰(collaborative trust)의특성을 잡아내고 있는 것처럼 보인다. 왜냐하면, 신뢰도가 높고 권위 있는 소스로부터 언급된 페이지일수록 그 페이지의 신뢰도와권위가 올라가기 때문이다. 유사하게, 페이지의 품질이나 중요도 역시 이런 류의 순환적 정의에 잘 부합되는 것 같다.
6 개인화된 페이지랭크(Personalized PageRank)
페이지랭크 연산의 중요한 요소 중 하나가 E이다. E는, 랭크 싱크처럼 아웃엣지가 없는 싸이클을 보충하기 위한 랭크 소스웹 페이지의 벡터다. 한편, E는 랭크 싱크 문제에 대한 해결책으로써뿐만 아니라, 페이지랭크 값을 조정할 수 있는 강력한퍼래미터이기도 하다. 직관적으로 보자면, E 벡터는 랜덤 써퍼가 주기적으로 점프해 가는 웹 페이지의 분포에 해당한다. 밑에서살펴 보겠지만, 이것은 웹을 거시적으로 관찰하거나 특정 부분에 대해 집중적이고 개인화된 관찰을 하는 데 사용될 수 있다.
우리가 수행한 실험은 대부분 E 벡터를 모든 웹 페이지에 걸쳐 균일하게 ||E||1 = 0.15로가정했다. 즉, 랜덤 써퍼가 주기적으로 또 다른 랜덤 웹 페이지로 점프하는 것을 가정한 것이다. 이것은 모든 웹 페이지가 단지존재하고 있다는 이유만으로 똑같이 가치를 부여받는 것이므로 E를 무척 민주적으로 선택한 것이다. 이런 테크닉이 상당히성공적이었기는 했지만 중요한 문제점도 갖고 있다. 관련 링크가 많은 어떤 웹 페이지들이 지나치게 높은 랭킹을 받을 수 있는문제다. 예컨데, 저작권 관련 페이지나 상호간에 링크가 많이 된 메일링 리스트 모음 등이 여기에 해당한다.
또 하나의 극단적 형태로, E를 오직 하나의 웹 페이지로만 구성할 수 있다. 우리는 두 가지로 실험해 보았다. 하나는넷스케잎 홈 페이지로 해 보았고 다른 하나는 유명한 컴퓨터 과학자인 존 맥카씨(John McCarthy)의 홈 페이지로 했다.넷스케잎의 홈 페이지로 한 실험은, 넷스케잎을 기본 홈 페이지로 하고 있는 초보 사용자의 시각에서 페이지의 랭크를 만들어 내려는시도를 한 것이다. 존 맥카씨의 홈 페이지를 이용한 실험은, 그의 홈 페이지에 있는 링크를 바탕으로 우리에게 상당한 문맥적정보를 제공한 개인의 시각에서 페이지랭크를 계산한 것이다.
두 경우 모두, 위에서 말한 메일링 리스트 문제가 나타나지 않았다. 그리고 두 경우 모두에서, 각각의 홈 페이지가 가장높은 페이지랭크 값을 나타냈으며 그 페이지로부터 직접 연결된 페이지들이 그 뒤를 이엇다. 그 다음 시점부터는 불균형은 줄어들었다. 표 2는 각각의 경우에서 여러 페이지들의 페이지랭크 퍼센타일을 나타낸 것이다. 컴퓨터 사이언스에 관계된 페이지일수록넷스케잎 쪽 랭크보다 매카씨 랭 크쪽이 더 높은 값을 갖고, 특히 스탠포드 대학의 컴퓨터 사이언스 학과와 관계되는 페이지는 더욱높은 매카씨 랭크 값을 갖는 것을 볼 수 있다. 예를 들어 스탠포드 컴퓨터 사이언스 학과의 또 다른 교수의 웹 페이지는 매카씨쪽 랭크가 넷스케잎의 경우보다 6 퍼센타일 더 높다. 그리고 페이지랭크 값을 퍼센타일로 표시한 것에 주의하자. 이렇게 한 것은상위 순위에서 나타나는 페이지랭크 값의 큰 차이를 줄여서 표현하기 위해서다.
표 2
위와 같은 개인화된 페이지랭크는 개인화된 검색엔진처럼 다양하게 응용할 수 있을 것이다. 개인화된 검색엔진은, 단순히북마크나 홈 페이지를 입력하는 것만으로 사용자의 취향을 상당 부분 효과적으로 추측해내서 사용자의 수고를 대폭 덜어줄 수 있을것이다. "Mitchell"이라는 질의어로 시행한 예를 부록 A에 수록했다. 그 예를 보면, 웹 상에 "Mitchell"이라는이름을 가진 사람이 아주 많음에도, 존 매카씨 교수의 동료인 존 밋첼 교수의 홈 페이지가 결과의 1위로 나타난 것을 볼 수 있다.
6.1 상업적 이익을 위한 조작
이런 형태의 개인화된 페이지랭크는 상업적 이익을 위해 조작하는 것을 사실상 완전히 차단할 수 있다. 높은 페이지랭크 값을갖기 위해서는 중요한 페이지로부터 언급되거나 중요하지 않은 많은 페이지로부터 링크되어야만 한다. 최악의 경우, 중요한 싸이트에서광고(링크)를 구입하는 형태의 조작이 있을 수 있겠지만 그건 비용이 소요되므로 충분히 조절 가능하다. 조작에 대한 이런 저항성은정말로 중요한 특성 중 하나다. 왜냐하면 상업적 조작 때문에 많은 검색엔진이 골머리를 앓고 있으며 훌륭한 기능을임플리멘테이션하는 것이 조작 때문에 매우 어려워지기 때문이다. 예컨데, 문서가 자주 업데잇되는 것은 매우 바람직한 특징임에도검색 결과를 조작하고자 하는 사람에 의해 이런 특징이 남용되고 있는 것이다.
균일한 E로 할 것인지 아니면 단일 페이지 E로 할 것인지의 절충안으로 E를 모든 웹 써버의 루트 수준 페이지로 구성할수도 있다. `이 경우, 어느 정도의 페이지랭크 조작이 가능하다는 것에 주의해야 한다. 많은 루트 레벨 써버를 확보해서 특정싸이트로 링크하면 간단히 조작되기 때문이다.
7 적용(Applicaitons)
7.1 웹 트래픽의 추산
페이지랭크는 대략 랜덤 웹 써퍼에 해당하기 때문에(섹션 2.5 참조), 페이지랭크가 실제 사용도와 어떻게 대응되는지 알아 보는 것은 아주 흥미로운 일이다. 우리는 NLANR(NLANR)의 프록시 캐쉬로부터 얻은 웹 페이지의 접근 횟수를 페이지랭크와 비교해 보았다. NLANR 데이타는 미 전역에 있는 프록시캐쉬에 있는 여러 달에 걸쳐진 기록으로, 11,817,665개의 각기 다른 URL에 관한 자료이다. 그 데이타에 따르면 가장히트가 높은 것은 알타비스타로 638,657 히트다. 그 데이타베이스는 우리가 갖고 있는 7500만 개 URL 데이타베이스와260만 페이지가 중복된다. 이들 데이타셋을 분석, 비교하는 것은 몇 가지 이유에서 대단히 까다로운데, 우선 캐쉬 억세스데이타에 있는 많은 URL들이 무료 이메일 서비스에 있는 개인 메일을 읽기 위해 접근한 것들이라는 점이 있다. 그리고 중복된써버 이름과 페이지 이름도 심각한 문제점이다. 불완전성과 편향됨은 페이지랭크 데이타와 사용도 데이타 모두에서 문제가 된다.하지만, 몇 가지 흥미로운 트렌드를 볼 수 있었다. 캐쉬 데이타에서는 포르노그래프 싸이트들이 높은 사용도를 보였음에도 이들의페이지랭크 값은 대부분 낮았다. 이것은, 사람들이 자신의 웹 페이지에 포르토그래피 싸이트로 링크하는 것을 원하지 않기 때문인것으로 생각된다. 그러므로 페이지랭크와 사용도 데이타 사이의 차이점을 살펴 보는 것을 통해, 사람들이 보고는 싶어하는데 자신의웹 페이지에서는 언급하고 싶어 하지 않는 게 어떤 것이 있는지를 알아낼 수 있을 것이다. 어떤 싸이트는 매우 높은 사용도를갖는데 페이지랭크가 낮은 경우가 있다. netscape.yahoo.com 같은 게 그렇다. 이것은 아마도 우리 데이타베이스에중요한 백 링크가 누락되어 있기 때문인 것 같다. 우리 데이타베이스는 웹 링크 구조이 일부분만을 담고 있기 때문이다. 사용도데이타를 페이지랭크 계산의 시작 벡터로 사용하고 페이지랭크 연산을 몇 차례 반복하는 것도 가능할 것이다. 이렇게 하면 사용도데이타가 채워주지 못 한 부분을 메꿀 수 있을 것이다. 어떤 식이 되었든, 이런 형태의 비교는 향후 연구를 위한 흥미로운주제이다.
7.2 백 링크 예측자로써의 페이지랭크
페이지랭크는 백 링크의 예측자로써의 의미가 있다. "Efficient crawling through urlordering"(Junghoo Cho, Hector Garcia Molina, and Lawrence Page) 논문에서,우리는 어떻게 웹을 효율적으로 크롤링할 수 있는지, 더 좋은 문서들을 먼저 크롤링할 수 있는지의 문제를 탐색했다. 우리는스탠포드 웹에서 시행한 테스트를 통해서 페이지랭크가 단순히 인용 횟수를 세는 것보다 훨씬 더 좋은 미래 인용 횟수의 예측자라는것을 알게 되었다.
실험은, 다른 정보 없이 단일 URL에서 출발해서 가급적 최적의 순서에 가깝게 페이지를 크롤링하는 것을 목표로 하고 있다.최적의 순서란 평가함수에 따른 랭크 순서와 정확히 일치하는 순서로 페이지를 크롤링하는 것이다. 이 실험에서의 평가함수는 완전한정보가 주어졌을 때의 인용 횟수 순서로 했다. 문제는, 평가함수를 계산할 정보를 완전히 알게 되는 것은 모든 문서를 크롤링한다음이라는 점이다. 이렇게 불완전한 데이타를 사용해서 크롤링 순서를 정할 때, 단순히 이미 알고 있는 인용 횟수를 활용하는것보다 페이지랭크를 이용하는 쪽이 더 효과적인 것으로 드러났다. 바꿔 얘기하자면, 심지어 측정 기준이 인용횟수를 세는것일지라도, 페이지랭크가 인용회수를 직접 세는 것보다 더 좋은 예측자라는 얘기다! 이것의 이유는 페이지랭크의 경우 인용 횟수를세는 것이 국소적으로만 최대화되는 것을 피할 수 있기 때문인 것 같다. 예를 들어, 인용 횟수를 직접 세는 경우에는 스탠포드CS 웹 페이지들의 컬렉션 속에만 빠져 드는 경향이 있어서 그곳을 벗어나 다른 곳에 있는 인용 회수가 높은 페이지를 찾아 나서는데 오랜 시간이 걸린다. 하지만 페이지랭크는 스탠포드 홈 페이지가 중요하다는 것을 금방 알게 되고, 그 하부 페이지들에게우호적인 점수를 주기 때문에 더 효율적이고 광범위한 검색이 가능한 것이다.
이러한 인용 횟수의 예측자로써의 페이지랭크의 능력은 페이지랭크를 사용해야 하는 아주 설득력 있는 이유가 된다. 웹의인용구조를 완전히 매핑하는 것은 아주 까다롭기 때문에, 인용 횟수를 직접 세는 것보다 페이지랭크가 훨씬 더 좋은 인용 횟수근사치가 될 수 있는 것이다.
7.3 사용자 네비게이션: 페이지랭크 프락시(User Navigation: The PageRank Proxy)
우리는 사용자가 각 링크의 페이지랭크와 함께 부가적인 설명을 볼 수 있는 웹 프락시 애플리케이션을 개발했다. 그애플리케이션은 아주 유용했는데, 사용자가 링크를 클릭하기 전에 관련 정보를 미리 알 수 있기 때문이다. 그림 7은 프록시프로그램의 스크린샷이다.빨간 바의 길이는 URL의 페이지랭크 값에 로그를 취한 값이다. 그림을 보면 스탠포드 대학 같은 메이져조직은 매우 높은 랭킹을 받게 되고, 뒤이어 리서치 그룹이, 그 다음으로 개인이 -개인의 경우 스케일의 최상단에는 교수가위치한다 - 나타남을 알 수 있다. 또한 ACM이 스탠포드 대학보다는 높지 않지만 매우 높은 페이지랭크를 갖는 것도 볼 수있다. 재미있는 것은, 아주 지명도가 높은 교수의 페이지가 심할 정도로 낮은 페이지랭크 값을 갖고 있는 것을 찾으면 URL이잘못 되어 있는 것을 찾아낼 수 있다는 점이다. 결과적으로, 프락시 툴은 네비게이션 뿐만 아니라 페이지 제작에도 도움이 될 수있는 것 같다. 이 프락시 애플리케이션은 다른 검색엔진의 결과를 살펴 보는 데에도 아주 유용하다. 그리고 야후의 리스팅 같이링크가 매우 많은 페이지를 파악하는 데도 큰 도움이 된다. 프락시를 통해서 많은 링크 중 어떤 것이 더 흥미로운 것인지를 짐작할수 있기 때문이다. 또는 자신이 찾고 있는 링크가 "중요도" 측면에서 어느 정도인지를 알 수도 있고, 훨씬 더 빠르게 페이지를전체적으로 살펴볼 수 있다.
그림 7 페이지랭크 프락시
7.4 페이지랭크의 다른 용도
페이지랭크의 최초 목표는 백 링크를 정렬해서, 만약 어떤 문서가 많은 백 링크를 갖는다면 그 중 어떤 것이 "최상"의것인지를 찾아서 그걸 가장 먼저 보여주려는 것이었다. 그리고 우리는 그런 시스템을 임플리멘테이션했다. 페이지랭크를 기준으로정렬된 백 링크를 살펴 보는 것은 경쟁을 파악하는 측면에서도 아주 흥미롭다. 예를 들어, 뉴스 싸이트를 운영하는 사람이라면경쟁자가 확보한 중요한 백 링크가 어떤 것인지 지속적으로 관찰하고자 할 것이다. 또한, 페이지랭크는 사용자가 어떤 싸이트가신뢰할 수 있는 것인지 아닌지 판단하는 데 도움을 준다. 예를 들어, 스탠포드 홈 페이지에서 직접 인용된 정보라면 아무래도사용자가 더 신뢰하려 할 것이다.
8 결론
이 논문에서, 우리는 웰드 와이드 웹 상의 모든 페이지를 페이지랭크라는 단일한 숫자로 압축하고자 하는 담대한 작업을 다루어보았다. 페이지랭크는 페이지의 컨텐트와 상관없이, 오직 웹의 그래프 구조 상의 위치에만 의존하는 모든 웹 페이지의 글로벌랭킹이다.
페이지랭크를 사용함으로써 우리는 더 중요하고 중심적인 웹 페이지들을 더욱 선호하는 식으로 검색 결과를 정렬할 수 있다.여러 실험을 통해서, 페이지랭크는 고품질의 검색 결과를 보여줌을 알 수 있었다. 페이지랭크의 기반이 되는 직관은 웹 페이지외부에 있는 정보, 즉 일종의 피어 리뷰인, 백 링크를 사용한다는 것이다. 게다가, "중요한" 페이지들로부터의 백 링크는평균적인 페이지들로부터의 백 링크보다 더 중요하며, 이것은 페이지랭크의 재귀적인 정의(섹션 2.4 참조)를 통해 확실히 구현되어있다.
페이지랭크는 대부분의 질의어에 대한 답변이 될 수 있는 소수의 자주 사용되는 문서들을 분리해 내는 데에도 사용될 수 있다.풀 데이타베이스는 작은 데이타베이스가 질의어에 적절히 응답할 수 없을 때만 참조되면 된다. 마지막으로, 페이지랭크는 클러스터의센터로 사용할 수 있는 대표 페이지를 찾아내는 좋은 방법이 될 수도 있을 것이다.
페이지랭크는 검색 외에도 트래픽 추산이나 사용자 네비게이션 같은 다른 많은 곳에 적용될 수 있다. 또한, 웹을 특정 시점에서 바라볼 수 있는 사용자화된 페이지랭크 역시 만들어 낼 수 있다.
종합하자면, 페이지랭크를 이용한 실험은 웹 그래프의 구조가 다양한 정보검색 작업에서 매우 유용하게 사용될 수 있음을 보여 준다고 할 수 있다.
문서출처: 이명헌 경영스쿨 http://www.emh.co.kr/xhtml/google_pagerank_citation_ranking.html
이 문서를 게시하거나 프린트하려면 위 문서출처를 반드시 포함해야 합니다.(참고: 저작권정책)
이 문서를 게시하거나 프린트하려면 위 문서출처를 반드시 포함해야 합니다.(참고: 저작권정책)
# by | 2007/08/13 20:33 | Search Engine | 트랙백 | 덧글(0)
2007년 08월 13일
Google Search Engine 해부 - 1
구글은 처음부터 다른 서비스와는 차별되는 검색엔진과아키텍처, 새로운 개념의 랭킹 모델들을 사용함으로써 그간의 웹 검색에 대한 개념을 크게 바꾸어 놓았다. 구글의 기술은 검색업계에서 일하는 개발자들은 물론 일반 개발자들까지도 관심을 갖게 만드는데, 그 핵심은 탄탄한 기반 기술들과 그것들을 하나로 묶는거대한 프레임워크에 있다. 이번 특집 2부를 통해 구글의 기술이 어떤 그림을 갖고 있는지에 대해 이해할 수 있는 시간이 될것으로 기대한다.
구글 검색엔진
검색엔진은 대상이 되는 문서들을 수집하고, 수집된 문서들로부터 키워드를 추출하여 키워드-문서간의 역 색인(inverted index)을 생성한 후, 사용자의 질의어(query)를 입력받아 해당 쿼리를 역 색인 구조를찾아, 매칭된 문서를 결과로 반환해 준다. 구글의 검색엔진 역시 이러한 전통적인 검색엔진의 구조와 크게 다르지 않다. 구글의검색엔진은 웹 문서들을 수집하고, 웹 문서들로부터 키워드를 추출하여 역 색인 구조를 생성하고, 생성된 역 색인 구조로부터질의어를 매칭하여 결과를 반환해준다. 그러나 구글의 검색엔진은 기존의 검색 시스템과는 스케일이나 기능 면에서 많은 차이를보여준다.
전통적인 키워드 매칭(keyword matching)을 기반으로 한 자동화된검색엔진(automated search engine)은 몇 가지 약점을 갖고 있었다. 기본적으로 낮은 질의 매칭 결과가 너무빈번하게 나타났다. 게다가 광고주들이 웹 문서에 포함된 키워드들을 조작해 엉뚱한 결과가 노출되도록 하는 것이 가능했다. 구글은이런 문제점을 해결하기 위해 웹 문서의 하이퍼텍스트에 존재하는 부가적인 구조적 정보들을 사용하기 시작했다. 또한 방대한 웹 문서데이터들을 처리하기 위해 매우 거대한 스케일의 검색 아키텍처를 구축했다.
구글 검색엔진의 지향점
웹을 효율적으로 검색하기 위해서는 몇 가지의 필수적인 기술들이 요구된다. 웹 문서들을 신속하고효율적으로 수집하고, 수집된 데이터들을 최신의 상태로 유지하기 위한 크롤링(crawling) 기술, 대용량 데이터 처리를 위해효율적으로 공간을 사용할 수 있는 색인 구조, 대용량 데이터를 신속하게 처리할 수 있는 색인기(indexer) 기술, 다량의질의어들을 처리할 수 있는 질의어 분석/처리 시스템 등이 그것이다.
웹이 성장하면서 이러한 기술들이 감당해야 하는 목표들은 급격하게 상향 조정된다. 게다가 단순히하드웨어의 발전만으로는 웹의 발전 속도를 감당할 수 없다. 하드웨어의 발전이 검색 시스템의 성능을 증가시키지만, 기본적으로디스크 탐색 시간(disk seek time)이나 운영체제의 강력함(robustness)은 그렇게 주목할 만한 요소가 아니다.구글 검색엔진은 극단적으로 큰 데이터 셋(data set)을 커버하기 위한 확장형 구조이며, 효율적인 색인 구조를 사용함으로써데이터에 대한 신속하고 효율적인 액세스가 가능하도록 최적화된 구조이다.
웹 검색의 초창기에 많은 사람들이 검색엔진의 색인이 완전하고 무결성을 갖는다면 어떤 키워드에대해서도 원하는 웹 문서를 검색할 수 있다고 믿었다. 그러나 웹 검색이 발전하면서 색인의 완전성과 무결성이 검색 품질을 좌우하는유일한 요소가 아님이 밝혀졌다. 웹 검색은 일반적으로 입력되는 질의어에 대해 매칭되는 문서의 개수가 대단히 많다. 즉, 검색대상이 되는 색인 내에서 검색 결과로 재현될 수 있는 비율이 대단히 크다. 그러나 일반적인 사용자들은 많은 검색 결과 중에서상위의 일부 결과만을 보고 검색 결과의 모든 품질을 평가하려는 성향이 있다. 관련 있는 검색 결과가 상위에 랭크되어 있지 않고몇 십 페이지 뒤에 랭크되어 있다면, 그것을 찾기 위해 페이지를 클릭할 사용자는 그렇게 많지 않다. 따라서 사용자의 만족감을충족시키기 위해서는 극도로 높은 정확도에 기반한 검색 결과를 제공해야 한다. 정확도는 대용량 데이터의 검색 결과 품질을 좌우하는요소이기 때문에, 재현율을 희생해서라도 정확도를 확보하는 것이 사용자들의 만족감을 위해 가장 중요하다⑴.
구글 검색엔진은 이러한 이유로 정확도 중심의 엔진으로 설계됐다. 구글의 정확도는 극도의 관계성판단(relevance judgement)에 의해 산출되는데, 그 기반에는 링크 구조와 앵커 텍스트(anchor text)를분석한 정보에 의한 질적인 필터링(filtering)이 존재한다. 구글은 이러한 정보들의 정확도를 높이는 두 가지 방법을사용한다. 하나는 개별 웹 페이지의 품질 순위 할당을 위한 페이지 랭크 알고리즘이고, 다른 하나는 검색 결과 개선을 위한 앵커텍스트 사용이다.
참고로, 구글이 검색엔진을 발표했던 초창기에는 또 한 가지 목표를 가지고 있었다. 그것은대용량 웹 문서들과 대용량 트래픽을 감당할 수 있는 거대한 웹 시스템을 만들고, 실제로 많은 사용자들이 그것을 사용하면서 얻는데이터(usage data)를 학술적인 연구에 제공하겠다는 것이었다.
구글 검색엔진의 특징
페이지 랭크의 사용웹 문서에 존재하는 레퍼런스(링크) 그래프는 구글 검색엔진이 거의 최초로 주목한 요소이다.페이지 랭크는 이러한 요소들로부터 사용자들이 생각하는 특정 페이지의 중요성(importance)에 부합하는정확도(precision)의 객관적인 척도를 산출해낸다. 사용자들의 생각과 관련을 갖기 때문에 페이지 랭크는 웹 문서에 순위를할당하는데 매우 합리적인 수단이다. 질의어를 문서 제목과 매칭되는지 여부만을 평가하는 단순한 텍스트 검색엔진에는 물론, 풀텍스트(full text, 제목과 내용을 모두 포함) 검색엔진이나 페이지 랭크로 순위를 매기는 경우에도 상당한 성능을 보여주기때문이다.
페이지 랭크는 한 페이지의 인용 횟수(백 링크, back link)를 카운팅하는 방식으로계산된다. 한 페이지가 얼마나 많은 레퍼런스를 받고 있느냐의 수준이 그 페이지의 중요성이나 품질(quality)을 추정할 수있는 요소로 간주된다. 페이지 랭크는 이 기본적인 아이디어를 확장하여 그 링크가 어떤 페이지에서 왔는지를 차별화하고, 링크하는페이지에서 외부로 나가는 총 링크 개수로 노멀라이징(normalizing)을 수행했다.
페이지 랭크를 간략하게 정리하자면 다음과 같다. 페이지 A를 링크하는 다른 페이지들의 set을(T1, T2, T3, ...., Tn)이라고 한다면, 파라미터 d는 0~1 사이의 값을 갖는다. C(A)는 페이지 A에서외부로 나가는 아웃 링크(out link)의 개수이다. 이 때 페이지 A의 페이지 랭크 값 PR(A)은 다음과 같은 수식으로표현된다.
페이지 랭크 PR(A)은 반복 알고리즘(iterative algorithm)으로 계산할 수있으며, 그 값은 웹 링크를 노멀라이징해서 행렬로 바꾸었을 때 주 고유 벡터(principal eigen-vector)에해당한다. 참고로 이것은 약 2600만 페이지의 페이지 랭크를 계산하는데 중급의 워크스테이션으로 수 시간 내에 연산이 가능한수준이다.
페이지 랭크는 또한 사용자의 행동 패턴을 모델링하고 있다. 무작위로 선택한 하나의 웹페이지에서 출발해서 백 버튼을 누르지 않은 상태로 계속 링크를 따라 네비게이션하는 랜덤 서퍼(random surfer)는네비게이션 도중 지루해지면 다시 무작위로 페이지를 선택해서 네비게이션을 시작한다. 한 페이지의 페이지 랭크는 랜덤 서퍼가 그페이지를 방문할 확률을 나타낸다. 페이지 랭크에서 주요 파라미터 중 하나가 댐핑 팩터(damping factor) d이다.페이지 랭크에서는 파라미터 d를 특정 페이지 하나 또는 일련의 페이지에만 선택적으로 적용함으로써개인화(personalization)를 가능하게 하며, 페이지에 대한 랭킹을 올리기 위한 속임수(abusing)를 사실상불가능하게 만들 수 있다.
페이지 랭크의 직관적인 요소 중 또 하나는 페이지 랭크 값이 커지기 위해서는 많은 페이지가어떤 한 페이지를 집중적으로 레퍼런스하고 있거나, 특정 페이지를 레퍼런스하는 페이지 자체의 페이지 랭크 값이 커야 한다는것이다. 예를 들어 많은 페이지로부터 인용되고 있는 페이지는 살펴볼 만한 가치가 있는 것이고, 야후 같은 메이저페이지(major page)에서 링크되고 있는 페이지는 그렇지 않은 페이지보다 중요하다고 간주되는 것이다. 페이지 랭크에 대한더 자세한 내용은 뒤에서 따로 다루겠다.
앵커 텍스트의 사용
구글 검색엔진은 링크의 텍스트 자체를 특별하게 취급한다. 대부분의 검색엔진들은 링크의텍스트(앵커 텍스트)를 링크를 담고 있는 페이지 자체의 정보 중 일부로만 취급하고 있지만, 구글의 검색엔진은 링크가 가리키고있는 페이지를 링크의 텍스트와 연관시켜 처리한다. 이런 방법은 몇 가지 장점을 가진다. 첫째, 앵커 텍스트는 링크를 담고 있는페이지에 대한 설명보다 링크가 가리키고 있는 페이지에 대해 더 정확한 설명을 담고 있는 경우가 대부분이다. 둘째, 일반적인텍스트 검색엔진이 색인할 수 없는 이미지나 프로그램, 데이터베이스로의 앵커(링크)도 존재할 수 있다. 따라서 앵커를 사용한다면크롤링되지 않는 웹 페이지들까지도 찾아낼 수 있다. 물론 이러한 링크에 걸려있는 대상들은 검색에 유효하지 않은 대상일 수있으므로 사용자에게 보여주기 전에 먼저 유효성 검사를 통과해야 한다. 존재하지 않는 페이지를 가리키는 앵커의 경우에도 유효성검사를 거치면 큰 문제는 없다.
앵커 텍스트를 그 앵커가 가리키는 페이지로 전파시켜 나간다는 아이디어는 World WideWeb Worm(WWWW) 검색엔진에서 먼저 구현됐다. 앵커 텍스트가 텍스트 이외의 데이터에 대한 검색을 용이하게 해 주었고,검색엔진이 크롤링한 웹 문서보다 훨씬 더 많은 영역을 포괄하게 해주는 것에 이 아이디어의 유용성이 있다. 다만, 이를 위해서는대용량 데이터 처리를 위한 구조가 필수적이다.
그 밖의 특징
페이지 랭크와 앵커 텍스트에 대한 접근 방식 외에도 구글 검색엔진은 몇 가지 특징을 갖는다.첫째, 구글 검색엔진은 문서로부터 추출된 모든 키워드들에 대한 위치 정보(positional information)를 저장한다.위치 정보의 저장은 검색 수행 시 근접도의 광범위한 사용을 가능케 한다. 둘째, 구글은 문서 내에서 추출된 키워드의 폰트 크기,대소문자 여부 등에 대한 부수적이고 시각적인 세부 요소들을 추적한다. 폰트 크기가 큰 단어나 볼드체로 된 단어, 대문자로 작성된단어의 경우에는 그렇지 못한 단어에 비해 더 높은 가중치(weight)가 부여된다. 셋째, 구글 검색엔진은 수집된 웹 문서를완전한 HTML 형식으로 압축 저장하기 때문에 이를 활용할 수 있는 여지가 있다.
<그림 1> 구글 검색엔진의 아키텍처
구글 검색엔진의 전반적인 구조
지금까지 구글 검색엔진의 특징을 살펴보았고, 이제는 구글 검색엔진의 구조에 대해 알아보자.<그림 1>은 구글 검색엔진의 아키텍처를 표현하고 있다. 구글 검색엔진의 구조는 일반 검색엔진과 큰 차이가 없다.구글 검색엔진은 크게 웹 문서를 수집하는 크롤러(crawler) 영역과, 역 색인(inverted index)을 생성하는색인기(indexer) 영역, 그리고 검색을 수행하는 검색기(searcher) 영역으로 구분된다. 구글 검색엔진이 데이터를수집하고 색인을 생성하여 검색을 수행하는 전반적인 시퀀스는 다음과 같다.
• 크롤링
- 분산 배치된 크롤러에 의해 웹 페이지들이 다운로드된다.
- 크롤러가 수집한 문서들은 URL server로 보내져서 URL list로 변환된다.
- 크롤러로부터 패치(fetch)된 웹 문서들은 Store server에 저장된다.
- Store server에 저장된 웹 문서들은 압축되어 리파지토리에 저장된다.
- 저장된 웹 문서들은 특정한 docID를 부여받는다.
• 색인
- Indexer가 리파지토리를 읽어 압축된 웹 문서들의 압축을 해제한다.
-Indexer가 압축 해제된 웹 문서를 파싱하여 문서에 포함된 부수적인 정보(위치 정보, 폰트 크기, 대소문자 여부)와 함께추출한 키워드 정보(Hits라고 불린다)의 set을 생성하고, 링크들을 분석하여 링크의 방향성과 앵커 텍스트들을 추출해서anchor file을 생성한다.
- Indexer가 문서 당 추출된 키워드들의 set을 Barrel에 일부분 정렬이 이루어진 forward index 형태로 분산 저장한다.
-URL resolver가 anchor file을 분석하여 상대 URL(relative URL)을 절대 URL(absoluteURL)로 변환하고, 변환된 URL 정보를 Barrel에 저장되어 있는 forward index의 docID와 조합한다.
- Sorter가 Barrel에 docID 순으로 정렬되어 있는 정보를 키워드 별로 정렬하여 wordID를 할당한다.
- Indexer가 wordID 순으로 정렬된 정보를 이용하여 최종적으로 역 색인(inverted index)을 생성하여 Lexicon에 저장한다.
<그림 2> 라파지토리의 자료구조
• 검색
- 입력 받은 질의어를 분석한다.
- Lexicon을 뒤져서 분석을 통해 추출된 키워드에 해당하는 wordID를 찾는다.
- 발견된 wordID에 해당하는 doclist의 시작 위치를 Barrel을 뒤져서 찾는다.
- doclist를 스캔하여 입력된 search term과 매칭되는 도큐먼트들을 찾는다.
- 탐색된 도큐먼트들에 대해서 페이지 랭크를 계산한다.
구글 검색엔진의 자료구조
구글 검색엔진은 기본적으로 대용량 데이터를 다룬다. 기본적인 정보 외에도 부수적인 정보들을충분히 다루고 있는 만큼 모든 색인 구조를 비롯한 자료구조는 매우 효율적이고 최적화돼 있어야 한다. 머신의 성능은 급격하게발전하고 있지만 디스크 I/O 속도는 크게 변함이 없는 현실에서 자료구조는 훨씬 더 중요한 위치를 차지한다. 다음은 구글검색엔진에서 사용하고 있는 자료구조들이다. 구글 검색엔진의 자료구조를 살펴보면, 구글 검색엔진의 내부 프로세스와 구조를 더자세히 볼 수 있다.
• 리파지토리
리파지토리는크롤러에 의해 수집된 웹 문서의 full HTML을 zlib를 이용해 압축, 저장한다(zlib은 다른 압축 솔루션에 비해 압축과압축 해제 속도가 뛰어나다). 리파지토리에 저장되는 각 웹 문서들은 docID를 prefix로 사용하여, 기타 정보들을 함께묶은 형태의 자료구조로 표현된다. 웹 문서의 consistency 유지나 크롤러의 에러는 리파지토리의 모든 자료구조를재생성(rebuilding)함으로써 해결한다. <그림 2>는 리파지토리의 자료구조를 나타낸 그림이다.
• 도큐먼트 인덱스(Document Index)
도큐먼트 인덱스는 각 도큐먼트의 정보들을 저장하며, 기본적으로 docID에 의해 정렬된 fixed width ISAM(Indexsequential access mode)이다. 이것은 도큐먼트에 대한 추가적인 정보로 도큐먼트의 상태 정보, 리파지토리내에서의 해당 도큐먼트에 대한 위치, 도큐먼트 체크섬(checksum), 기타 수치적 정보들을 포인터로 담고 있다. 포인터정보만 사용함으로써 콤팩트한 자료구조의 구성이 가능하며, 검색을 수행하는 동안 디스크 탐색 시간을 줄일 수 있다. 추가로,도큐먼트의 정보 중 URL과 docID의 관계를 저장해 두기 위해 URL을 docID로 변환한 관계를 저장하는 파일이 존재한다.이것은 URL 체크섬을 키(key)로 갖고, docID를 데이터로 갖는 자료구조로 일반적인 btree(binary tree)검색과 유사한 방식에 의해, URL 체크섬을 키로 던져 해당 URL의 docID를 찾아내는데 사용된다. 이 방식은URLresolver가 URL을 docID로 변환하는데 사용된다.
• Lexicon
Lexicon은 실제 검색을 수행할 때 반드시 필요한 역 색인 구조를 만들기 위한 자료구조이다. 검색엔진의 성능과 처리 가능한 용량이 대부분Lexicon과 역 색인 구조에 기반해 결정되기 때문에 Lexicon의 자료구조는 검색엔진의 전체 구조 중 매우 중요한 요소를차지한다. 검색엔진의 속도 향상을 위한 기초적인 접근 방식은 Lexicon을 메모리에 구동 가능한 크기로 쪼개는 것이다. 초기구글 검색엔진의 경우에는 256MB 메인 메모리에 올라갈 수 있는 크기로 설계됐고, 256MB 안에 1,400만 개의 단어를올릴 수 있었다. 구글의 Lexicon은 추출된 단어들의 리스트와 포인터의 해시(hash) 테이블, 두 가지 요소로 구성된다.
• Hit Lists
Hit는 하나의 도큐먼트에서 추출된 하나의 단어에 대한 부가적인 위치 정보, 폰트 정보, 대문자 여부 등의 집합이다. HitList는 forward index와 inverted index에서 모두 사용되며 검색엔진 내의 정보 중 상당 부분을 차지하기때문에 가능한 효율적인 구조를 가져야 한다. 구글 검색엔진은 하나의 hit를 2바이트로 인코딩하는 방식을 취한다.
Hit는 다시 각 도큐먼트에서 URL, title, anchor text, meta tag로부터 추출된 정보를 저장하는 fancyhit, anchor text로부터 정보를 추출된 정보를 저장하는 anchor hit, 그리고 그 밖의 요소들로부터 추출되는plane hit 등 3개의 hit로 구분된다. <표 1>은 인코딩된 fancy hit과 plane hit,anchor hit의 구조를 나타낸다.
Anchor hit에 포함된 4비트짜리 해시는 해당 anchor가 출현한 웹문서의 docID에 대한 해시 값을 저장한다. 이것은 anchor file에 저장되어, 랭크 산출에 가중치 요소로 사용된다.최종적으로 hit list들은 Barrel에 forward index를 구성하면서 wordID를 기준으로 저장되고,inverted index에 docID를 기준으로 저장된다.
• Forward Index
ForwardIndex는 도큐먼트에 대한 docID를 기준으로 추출된 hit list를 wordID와 함께 붙여서 barrel에 분산해놓은구조이다. Barrel 자체가 wordID의 특정 range에 대해 분산되도록 설계되어 있기 때문에 docID가 중복 저장될가능성이 있다. 하지만 inverted index를 구성할 때 Sorter에 의해 wordID를 중심으로 재구성되어야 하기때문에, 실제로는 이와 같은 방식이 조금 더 효율적일 수 있다. Barrel 내에 forward index가 저장될 때는wordID 24비트와 hit list length에 대한 정보가 8비트 추가된다.
• Inverted Index
InvertedIndex는 forward index가 Sorter에 의해 wordID 순으로 정렬된 구조이다. 유효한(valid)wordID는 Lexicon에 저장되고, 각 wordID가 속한 도큐먼트에 대한 docID는 Barrel 내에 역 색인으로서저장된다. Lexicon의 각 wordID는 inverted barrel 내의 docID를 가리키는 포인터를 갖는다.
<그림 3>은 Forward Index, Inverted Index,Lexicon의 구조에 대한 그림이다. Forward Barrel에 저장된 docID의 리스트는 최종적으로 Lexicon과Inverted Barrel에 저장되면서 최종적인 역 색인 구조를 구성하게 된다.
<그림 3> Forward/Bcakward Index와 Lexicon의 자료구조
<표 1> 인코딩된 fancy hit과 plane hit, anchor hit의 구조
| 구분 | 내용 | ||||
| Plane Hit | capitalization: 1 | font info: 2 | position: 12 | ||
| Fancy Hit | capitalization: 1 | font info: 7 | type; 4 | position: 8 | |
| Anchor Hit | capitalization: 1 | font info: 7 | type; 4 | hash: 4 | position: 4 |
<표 2> 구글 검색엔진의 퍼포먼스 수치 정보
| Storage Statistics | ||||||||||||||||||||||||||||||||||||
| Total Size of Fetched Pages | 147.8GB | |||||||||||||||||||||||||||||||||||
| Compressed Repository | 53.5GB | |||||||||||||||||||||||||||||||||||
| Short Inverted Index | 41GB | |||||||||||||||||||||||||||||||||||
| Full Inverted Index | 37.2GB | |||||||||||||||||||||||||||||||||||
| Lexicon | 293MB | |||||||||||||||||||||||||||||||||||
| Temporary Anchor Data | 6.6GB | |||||||||||||||||||||||||||||||||||
| Document Index Incl. Variable Width Data | 9.7GB | |||||||||||||||||||||||||||||||||||
| Links Database | 3.9GB | |||||||||||||||||||||||||||||||||||
| Total without Repository | 55.2GB | |||||||||||||||||||||||||||||||||||
| Total with Repository | 108.7GB | |||||||||||||||||||||||||||||||||||
| Web Page Statistics | ||||||||||||||||||||||||||||||||||||
| Number of Web pages fetched | 24 million | |||||||||||||||||||||||||||||||||||
| Number of URLs seen | 76.5 million | |||||||||||||||||||||||||||||||||||
| Number of Email Address | 1.7 million | |||||||||||||||||||||||||||||||||||
| Number of 404's | 1.6 million | |||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||
지금까지 구글 검색엔진에 대한 특징과 아키텍처, 자료구조에 대해 살펴보았다. 구글이 등장한지많은 시간이 흘렀지만, 구글의 검색엔진은 여전히 최적화된 혁신적인 구조로 개발자들에게 받아들여지고 있다. 많은 검색엔진들은여전히 구글 검색엔진을 벤치마크 대상으로 이용하고 있고, 구글 검색엔진이 갖고 있는 합리적인 랭킹 모델이나 데이터 처리 모델과자료구조는 많은 검색엔진이 닮고 싶어하는 요소들이다.
현대적 랭킹 모델, 페이지 랭크 알고리즘
구글은 처음 등장할 때 대량의 웹 페이지 데이터들에 대한 새로운 개념의 랭킹 모델 적용으로가장 주목받았다. 페이지 랭크라 불리는 이 랭킹 모델(ranking model)은 각 웹 페이지들의 중요성(importance)을 기반으로 계산(scoring)된, 사용자 입장에서 상당히 정확해 보이는 랭킹을 제공한다.
세르게이 브린(Sergey Brin)이 제안한 페이지 랭크 알고리즘은 웹 페이지의 중요성에기반을 둔 일종의 보팅 알고리즘(voting algorithm)으로, 사용자 중심의 주관적 영역에 놓여있던 ‘중요성’을상대적이고 기계적인 관점에서 정량화가 가능한 객관적 영역으로 변환시킨다. 이것은 기존의 야후나 기타 검색엔진들이 제공했던 사람이직접 웹 페이지의 중요도를 등록하여 결과로 제공하는 것이 웹 페이지의 랭크라고 믿어오던 사람들의 생각을 완전히 바꿨다. 구글은모든 페이지들의 중요도를 인터넷에서 웹 페이지를 생산해내는 사람들과 사용자들이 웹 페이지에 접근하는 행태를 분석하여 자동으로랭킹이 계산되는 구조를 만들어 냈다. 인력으로 랭킹을 처리하는 데에는 한계가 있었기 때문에, 비교할 수 없을 정도로 훨씬 더많은 데이터들에 대해 유효해 보이고 자동화된 랭킹을 제공한 구글은 단숨에 검색 사용자들의 이목을 끌 수밖에 없었다.
<그림 4> 역 링크: 링크 A와 링크 B는 페이지 C에 대한 역 링크이다.
랭크를 갖는 링크: 링크를 통한 랭킹의 전파
웹 링크의 중요성에 대한 접근은 구글 이전에도 있었는데 대부분 웹 공간 상에서 링크는 논문에기재되는 학술적 레퍼런스와 유사한 개념으로 보아, 레퍼런스 구조를 분석하고 중요성을 계산하는 테크닉들이 대부분이었다. 예를들어, 학술적으로 자주 인용되는 논문은 그렇지 않은 논문에 비해 중요한 논문일 가능성이 크다고 보는 것이다. 페이지 랭크의기본적인 아이디어는 웹 상의 이러한 레퍼런스 구조를 웹 공간의 링크 구조로 더욱 포괄적으로 확장하는 데 있다.
웹 페이지는 그 페이지에서 밖으로 나가는 순 링크(forward link, outedge)와외부에서 그 페이지를 가르키는 역 링크(back link, inedge)를 포함한다. 기본적으로 페이지 랭크에서 측정되는 웹도큐먼트의 중요성은 웹 도큐먼트의 컨텐트와 상관없이 그 웹 도큐먼트가 갖고 있는 링크 구조를 분석함으로써 측정된다.
페이지 랭크에서 중요성에 대해 가장 주요한 요소로 간주된 것은 링크가 많이 된 페이지가 그렇지못한 페이지보다 대부분 더 중요하다는 가정이었다. 역 링크라 불리는, 외부 페이지로부터의 레퍼런스 횟수는 중요성을 계산하는데기본적인 요소로 사용되었다. <그림 4>는 역 링크의 일반적인 형태를 나타낸다.
하지만 역 링크의 개수를 세는 것만으로 중요성을 매기는 것은 유효하지 않을 수도 있다. 어떤웹 페이지가 달랑 야후 하나에 링크되어 있다면 그 도큐먼트는 단 1개의 역 링크를 갖고 있지만, 그 링크는 중요하지 않은페이지로부터의 역 링크 몇 개보다 훨씬 더 중요한 링크라고 간주될 수 있다. 페이지 랭크는 링크를 통해 랭킹을 전파하는구조이다. 모든 역 링크에는 랭크 값이 있고, 랭크 값이 높은 역 링크의 레퍼런스를 많이 갖는 웹 도큐먼트일수록 웹 도큐먼트의랭크가 올라간다.
페이지 랭크의 개념
페이지 랭크를 단순하게 모델링한다면 다음과 같은 간단한 수식으로 표현할 수 있다.
어떤 웹 페이지를 u라고 하고, 웹 페이지 u가 레퍼런스하고 있는 페이지의 집합을 Fu, 웹페이지 u를 역 링크하고 있는 페이지의 집합을 Bu로 표현한다. Nu는 웹 페이지 u로부터 나가는 순 링크의 개수(| Fu|)이다. c는 웹 페이지의 랭크 총합을 일정 레벨로 맞추기 위한 노멀라이징 팩터(normalizing factor)이다.<그림 5>는 페이지 랭크가 계산되는 방식을 간단하게 보여준다.
그러나 웹 공간 상의 복잡한 링크 구조는 이와 같은 수식으로 해결하기 어려운 그래프를구성하기도 하는데, 랭크 싱크(rank sink)와 댕글링 링크(dangling link)가 그것이다 ⑵. 페이지 랭크에서는이런 문제를 해결하기 위해 사용자 정의 파라미터를 하나 더 둔다. 다음은 사용자 정의 파라미터 E가 추가된 페이지 랭크 모델을표현한다.
추가 파라미터 E(u)는 웹 페이지 u로부터 또 다른 특정 페이지로 이탈할 확률 분포에 대한모델이다. 앞서 검색엔진을 설명하면서 잠시 거론되었던 페이지 랭크의 사용자 행동 패턴에 대한 모델링(랜덤 서퍼 모델)이 바로파라미터 E이다. 즉, 파라미터 E는 랜덤 서퍼가 특정 확률 주기에 의해 다른 페이지로 이탈하는 것을 의미하며 이것은 댕글링링크를 이탈하는 행동의 모델링으로 볼 수 있다. 구글 검색엔진은 일반적으로 모든 페이지에 동일한 확률 주기의 E 값을 셋팅하여,모든 서퍼들이 주기적으로 링크의 그래프를 이탈한다고 보지만 E 값을 특정 페이지로 지정함으로써, 개인화된 페이지 랭크 모델을만들 수도 있다.
만약 2개의 페이지 랭크 모델을 만들어서 하나는 E를 일반 포탈 사이트의 홈페이지로, 나머지하나는 E를 컴퓨터 사이언스 관련 커뮤니티의 홈페이지로 셋팅한다면, 일반 포탈 쪽 랭크보다 컴퓨터 사이언스 관련 커뮤니티 쪽의랭크들이 더 큰 값을 가지게 될 것이다.
페이지 랭크의 구현
페이지 랭크는 일반적인 재귀 연산(recursive operation)의 형태이지만, 효율성을위해 컴퓨터 상에서는 벡터의 형태로 변환되어 계산된다. 이에 관련된 정보를 얻고 싶다면 Taher H. Haveliwala가 쓴『Efficient Computation of PageRank(Stanford Technical Report, 1999)』를참조하기 바란다. 페이지 랭크가 컴퓨터 상에서 처리되는 방식은 다음과 같다.
R0 ← S loop : Ri + 1 ← ARi d ← ||Ri||1 - ||Ri + 1 ||1 Ri + 1 ← Ri + 1 + dE δ ← ||Ri + 1 - Ri||1 while δ ＞ ∈• S는 한 웹 페이지의 초기 벡터 값이다.
• Ri는 i번째 페이지 랭크 벡터 값을 나타낸다.
• ||R||1은 벡터 R의 노름(norm) 값이다.
• d는 댐핑 팩터(damping factor)이다.
• A는 한 웹 페이지 u에서 다른 웹 페이지 v로 연결되는 포워드 링크의 개수의 역수이다. 만약 서로 연관된 링크가 없다면 0이 된다.
<그림 5> 페이지 랭크의 계산
이와 같은 연산은 수렴(convergence)이 이루어질 때까지 반복적으로 이루어진다. 구글 검색엔진 내부에서는 방대한 웹 페이지들의 페이지 랭크 계산을 위해 다음과 같은 방식으로 프로세스를 진행한다.
① docID를 이용하여 링크 구조를 정렬한다.
② 링크 데이터베이스에서 댕글링 링크를 제거한다.
③ 랭크 값을 초기화한다.
④ 각 페이지의 가중치를 저장하기 위한 메모리를 할당한다.
⑤ 한 단계의 계산이 완료되면 디스크에 가중치를 저장하고, 다음 단계의 계산을 메모리 상에서 진행한다.
⑥ Stet 5를 수렴할 때까지 반복된다.
페이지 랭크의 의미
페이지 랭크는 본질적으로, 웹 링크의 그래프 상에서의 랜덤 서퍼가 갖는 행동 패턴을 제한된분포로 결정짓는 작업이다. 그래프 상의 한 노드의 중요도는 충분한 시간이 흐른 후에 랜덤 서퍼가 그 노드 위에 있을 확률이다.확률이 높다면 웹 상의 서퍼들이 접근할 가능성은 높아진다. 이것은 웹 페이지의 컨텐츠와 상관없이 웹 상에 존재하는 가중치가부여된 링크 구조에 의한 중요성을 산출한다는 의미이다. 이런 특징은 대부분 사용자들의 웹 페이지 접근 의도에 대한 일반적인케이스(common case) 처리가 가능토록 한다.
예를 들어 꽃이라는 키워드를 쳤을 때, 일반적인 케이스는 꽃에 대한 설명이 담긴 페이지들이아니라 꽃 구입이나 배달과 관련된 페이지들이다. 일반적으로 사람들이 특정 질의어를 입력했을 때 특정 페이지가 일반적인 케이스라는정보는 HTML 자체에는 담겨져 있지 않기 때문에, 링크 구조를 분석하는 페이지 랭크는 일반적인 케이스 처리에 매우 효과적이다.또한 페이지 랭크는 사용자에게 자신이 찾고 있는 링크가 중요도 측면에서 어느 정도의 위치를 차지하고 있는지에 대한인디케이터(indicator)가 될 수도 있다.
참고로, 페이지 랭크의 요소들은 지금도 계속해서 튜닝되고 있다. 예를 들면 웹 페이지의 컨텐츠가 얼마나 자주 갱신되는가에 대한 빈도수(frequency) 등이 새롭게 추가되는 요소들 중 하나이다.
대용량 파일의 분산 처리를 위한 구글 파일 시스템
검색엔진의 성능이 검색엔진의 자료구조와 아키텍처에 밀접한 관계가 있는 것은 사실이지만, 어느수준의 성능 이상을 요구하는 경우에는 반드시 최적화된 하부 구조가 필요하다. 앞서 살펴보았던 구글 검색엔진은 대용량의 웹데이터를 다루고, 그에 따른 대용량 데이터와 색인 구조들을 다루고 있다. 대용량 처리를 위해서는 비용 문제를 간과하기 힘들기때문에, 구글은 저 사양의 머신들을 대량 배치하여 분산 처리하는 것으로 대용량 데이터와 대용량 트래픽에 대응하고 있다. 이를가능하게 한 데에는 효율적으로 대용량 파일의 분산 처리와 성능을 위해 자체적으로 개발된 구글 파일 시스템의 역할이 크다.
<그림 6> 구글 파일시스템 아키텍처
구글 파일 시스템의 특징
대용량 분산 파일 시스템이 가져야 하는 요소에는 확장성(scal ability),성능(performance), 신뢰성(reliability), 가용성(avail ability) 등이 있다. 구글 파일 시스템역시 이런 특징적 요소들을 모두 포함하고 있다. 구글 파일 시스템은 리눅스 파일 시스템을 기반으로 개발되었으며, 추가적으로다음과 같은 접근 특성들에 대한 처리 목표를 취하고 있다.
• 분산 처리 서버들의 오류(failure)에 대한 대응
-애플리케이션 버그, 디스크 오류, 메모리 오류, 커넥션 오류, 네트워킹 오류, 파워 서플라이 오류 등에 대해서 모니터링, 오류허용(fault-tolerance), 자동 복구(automatic recovery) 등이 시스템에 포함
• 기존의 파일에 비해 훨씬 더 큰 대용량 파일의 처리
- Multi-GB 파일들이 사용되기 때문에 I/O 오퍼레이션과 블럭 크기(block size)에 대한 파라미터 조정을 통해 효율적으로 관리
• 특징적인 읽기/쓰기 패턴에 대한 최적화
- Large streaming reads
- Small random reads
- Large, sequential writes
- Small writes
• Well-defined semantics를 갖는 구조
- 동일 파일에 읽기/쓰기를 하려는 다수의 클라이언트의 오퍼레이션을 처리하기 위해 동기화(synchronization) 처리
• 고속의 대역폭(bandwidth) 유지
- 읽기/쓰기에 대해 엄격한 응답 시간(response time) 유지
구글 파일 시스템 아키텍처
구글 파일 시스템은 하나의 마스터 서버(master server)와 다수의 청크서버(chunk server), 그리고 다수의 클라이언트(client)로 구성되어 있다(이러한 서버들은 모두 표준화된 형태인데,구글에서는 표준화된 서버를 pizza server box라고 부른다). <그림 6>은 이러한 구글 파일 시스템의아키텍처에 대한 그림이다.
마스터 서버는 청크 서버에 대한 메타 데이터들을 관리한다. 청크 서버는 정해진 크기의 청크들을 저장하고, 클라이언트는 마스터 서버의 메타 데이터들을 확인하고, 청크 서버에 접근하여 필요한 데이터를 읽고 쓴다.
각 파일들은 정해진 크기의 청크(chunk)로 나뉜다. 각 청크는 생성 시점에 마스터 서버에의해 글로벌하게 유니크한(globally uni que) 청크 핸들(chunk handle)을 할당받는다. 청크 핸들과 바이트레인지(byte range)에 의해 결정된 청크 데이터들은 청크 서버의 로컬 디스크에 저장되는데, 저장되는 청크 데이터는기본적으로 3개의 복제본을 가지게 된다. 하나의 청크 서버에서 청크들을 로컬 파일로 존재하므로 별도의 캐시(cache) 없이리눅스의 버퍼 캐시 효과를 그대로 사용한다. 구글 파일 시스템의 청크 크기는 64MB로 일반적인 리눅스 파일 시스템의 블럭크기보다 크다. 이처럼 큰 청크 크기를 사용함으로써, 클라이언트가 동일한 청크에 접근할 때 불필요하게 마스터 서버와의 통신을줄일 수 있고, 클라이언트의 네트워크 오버헤드와 마스터 서버에 저장되는 메타 데이터의 크기도 줄일 수 있다.
마스터 서버는 모든 파일 시스템의 네임 스페이스(name space), 액세스 컨트롤정보(access control information), 파일-청크 간의 맵핑 정보 등의 메타 데이터를 관리한다. 마스터 서버는이 정보를 이용하여 청크 서버들과 Heart Beat 메시지에 의한 커뮤니케이션을 통해 청크에 대한 가비지 컬렉션(garbagecollection), 청크 서버 간의 마이그레이션(migration)을 수행한다. 마스터 서버의 메타 데이터들은 모두 메모리상에 저장되기 때문에, 마스터 서버의 오퍼레이션이 매우 빠르다. 이는 주기적으로 상태를 스캐닝하여 청크 서버의 오류 상황이발생했을 때 복제본을 재배치한다거나 청크 서버들의 디스크 사용 상태에 따라 청크 마이그레이션을 수행하는데 매우 효율적인 방식이다.
클라이언트는 구글 파일 시스템 API에 의해 구현된 애플리케이션을 담고 있으며, 마스터 서버및 청크 서버와 커뮤니케이션하면서 애플리케이션에 필요한 데이터를 읽고 쓴다. 클라이언트는 마스터 서버와의 메타 데이터와오퍼레이션 내용과 커뮤니케이션하고, 모든 실제 데이터와의 커뮤니케이션을 청크 서버와 직접 하게 된다.
구글 파일 시스템의 일관성 모델(Consistency Model)
클라이언트에 의해 파일이 청크 서버에 저장될 때는 오류 발생에 대비해서 3개의 복제본으로저장된다. 만약, 데이터가 변경/추가된다면 청크 서버 내의 모든 복제본에 대해 동기화가 이루어져야 한다. 파일 쓰기가 이루어졌을때 다음과 같은 순서로 복제본의 동기화가 이루어진다.
① 클라이언트가 마스터 서버에게 현재 사용하고 있는 청크와 또 다른 복제본들의 위치에 대한 정보를 요청한다.
② 마스터 서버가 클라이언트에게 1차 복제본(primary replica)의 ID와 2차 복제본(secondary replica)의 위치 정보를 보내준다.
③ 클라이언트가 모든 복제본에 대해 데이터를 푸시한다. 각 청크 서버는 넘어온 데이터들을 저장한다.
④ 모든 복제본들이 데이터를 받은 것에 대한 완료 여부(acknowledge)가 확인되면 클라이언트는 1차 복제본에 쓰기 요청을 한다.
⑤ 1차 복제본은 모든 2차 복제본에 쓰기 요청을 전달한다.
⑥ 2차 복제본의 오퍼레이션이 완료되면 1차 복제본에 완료 시그널을 보낸다.
⑦ 모든 2차 복제본에서 완료 시그널이 오면 1차 복제본은 쓰기 요청이 완료되었음을 클라이언트에게 회신한다.
<그림 7>은 이와 같은 동작의 흐름을 나타낸 그림이다. 이러한 동작은 기본적으로컨트롤 플로우(control flow)와 데이터 플로우(data flow)가 구분되어 네트워크를 효율적으로 사용하는 방식으로구성되어 있다.
구글 파일 시스템의 마스터 서버 오퍼레이션
마스터 서버는 구글 파일 시스템 내의 모든 네임 스페이스와 청크들의 복제본에 대한 관리를 처리한다. 마스터 서버에서 진행되는 오퍼레이션들을 간단하게 살펴보면 다음과 같다.
• 네임 공간에 대한 관리 및 락킹(locking)
- 네임 공간은 풀 패스 명(full path name)의 맵핑 테이블에 의해 관리된다.
- 읽기/쓰기가 발생할 때 lock 처리를 해 conflict가 발생하는 상황을 방지한다.
• 복제본 배치
- 청크의 복제본을 데이터의 신뢰성과 가용성을 최대화하는 방향으로 배치한다.
- 청크의 복제본을 네트워크 사용성(utilization)을 최대화하는 방향으로 배치한다.
<그림 7> Write Control and Data Flow
• 청크와 복제본에 대한 관리
- 새로운 청크를 생성할 때 청크 서버의 디스크 사용 수준이나 최근 영역의 분포 등을 확인하여 생성한다.
- 오류가 발생하여 복제본 간의 내용이 맞지 않다면(corrupted 되었다면) 정상적인 복제본을 재배포한다.
- 청크 서버의 디스크 상태와 부하(load) 상태를 확인하여 좀 더 나은 상태의 청크 서버로 복제본을 재분산(rebalancing)한다.
<그림 8> 구글플렉스의 논리적 구조
<그림 9> 구글의 주요 기술 요소들을 나타내는 다이어그램
• 가비지 컬렉션
- 파일 삭제가 일어나면 마스터 서버에 삭제 시간을 비롯한 정보가 로그로 남는다. 실제 청크 서버에서는 파일 삭제가 바로 이루어지지 않고, 히든 타입으로 리네임(rename) 처리가 된다.
- 마스터 서버에서는 청크 네임 공간 스캔을 통해 3일 이상된 히든 타입의 파일들을 삭제한다.
- 파일이 네임 공간에서 삭제되면 마스터 서버의 메타 데이터가 삭제된다.
구글 파일 시스템의 오류 복구
마스터 서버와 청크 서버는 각각 메모리에 올라갈 수 있는 수준의 메타 데이터를 가지고 있다. 서버에 문제가 생겨서 재시작되는 경우 빠른 시간 안에 재동작을 할 수 있는 상황으로 복구될 수 있다.
각 청크는 여러 대의 서로 다른 랙(rack)에 위치한 청크 서버에 복제본을 기본적으로 3개배치한다. 각 청크들은 체크섬 버전 정보를 가지고 관리되며 이에 의해 각 복제본 간의 동기화 작업이 이루어진다. 데이터를 읽기위해 접근한 청크 서버가 문제가 있다면 또 다른 청크 서버에 담겨있는 복제본에 의해 데이터 읽기 작업은 무사히 수행될 수 있다.
마스터 서버 역시 마스터 서버에서 일어나는 모든 오퍼레이션의 로그와 상태(state), 체크포인트들은 여러 대의 머신으로 복제한다(Shadow master라고 불린다). 마스터 서버의 디스크에 오류가 있거나, 외부모니터링 툴에 의해 이상이 발견되는 경우 복제된 마스터 서버에 의해 파일 시스템 오퍼레이션은 정상 수행되도록 조정된다.
구글 파일 시스템은 구글 검색엔진과 서비스에 적합하도록 심플하고 효과적인 파일 시스템으로설계되어 있다. 구글에서 일어나는 대부분의 데이터 액세스는 추가(append) 중심의 쓰기 작업과 빈번한 읽기 중심의작업들이고, 저가의 머신에 의한 클러스터(cluster) 구성이기 때문에 오류 처리 역시 중요한 이슈가 된다.
구글의 파일 시스템은 시스템 내의 중심적인 읽기/쓰기 패턴을 명확하게 정의하고 오류 처리를중심으로 견고하고 효과적으로 설계되어 있다. 검색엔진에서 하부 저장 구조라는 것은 검색엔진 자체의 성능을 뛰어넘도록 하고검색엔진 자체의 안정성을 확장하는 요소로, 구글이 갖고 있는 효율적인 하부 저장 구조는 구글의 기반을 다진 핵심 기술 요소 중매우 중요한 요소로 볼 수 있다.
모든 기술을 아우르는 거대한 프레임워크
지금까지 구글이 갖고 있는 기술들 중에 핵심 기술(core technology)이라고 불릴 수있는 요소들에 대해 간략하게 살펴보았다. 이 기술들은 현재의 구글을 있게 만든 구글만의 독자적인 기술임에 틀림없다. 하지만구글의 기술은 이것이 전부가 아니다. 구글은 모든 애플리케이션과 기능들을 웹 중심(web-centric)으로 흡수하기 위한작업을 하고 있다. 그 기반에는 구글의 기술들을 모두 아우르는 거대한 프레임워크가 존재한다.
구글플렉스
구글플렉스(Googleplex, 구글 본사 건물의 별칭이기도 하다)는 구글의 프레임워크에서매우 중요한 위치를 차지하는 요소이다. 구글플렉스는 동일한 개체들이 모여 거대한 시스템을 구성하는 논리적 구조이다. 하나의서버는 다른 서버들과 기능과 속성들을 공유한다. 이런 서버들이 모여서 클러스터를 구성한다. 클러스터들을 모여서 데이터센터(data center)를 구성한다. 또 다시 데이터 센터들은 다른 애플리케이션 서버들과 모여서 구글의 온라인 시스템을구성한다.
<그림 8>은 구글플렉스의 타이트하고 규칙적으로 조직화된 모습을 보여준다. 그림을살펴보면 구글플렉스 내의 모든 레벨에 걸쳐 동일한 패턴이 반복되고 있음을 알 수 있다. 다시 말해 구글플렉스의 모든 구성요소들은 동형(homogeneous)의 컴퓨팅 시스템이다. 구글 버전의 리눅스 위에서 돌아가는 구글 애플리케이션들의 집합은슈퍼컴퓨터를 이용해 애플리케이션을 돌리는 것과 유사하다.
동형의 컴퓨팅 시스템은 몇 개의 장점을 갖고 있다. 모든 데이터 센터를 구성하고 있는 서버들의구성 역시 동일한 구성이기 때문에, 시스템 규모의 확장시 단순히 서버 랙을 꽂고(plugged-in) 케이블을 연결하는작업만으로도 셋팅과 설정(configuration)을 가능하게 한다. 앞서 살펴보았던 구글 파일 시스템 내에서 마스터가 청크서버에 청크들을 복제하는 작업 역시 동형의 컴퓨팅 시스템에 대한 접근이므로 매우 친숙하고 쉬운 오퍼레이션으로 구현될 수 있다.즉, 구글플렉스는 구글 파일 시스템의 기능과 목적들을 효율적이고 효과적으로 지원할 수 있는 논리적 구조이다.
구글 컴퓨팅 프레임워크
개발자들이 흔히 말하는 ‘구글스럽다’라는 말의 의미는 무엇인가. 검색 영역의 개발자와 일반영역의 개발자가 바라보는 관점이 약간의 차이는 있을 수 있겠지만, 대부분의 경우 구글을 구글스럽게 만드는 것은 검색 기술처럼특화된 기술 자체가 아니라 일반적이고 연구 개발적인 관점에서 접근하는 소프트웨어 공학적이면서 하드웨어 공학적인 솔루션들이일으키는 시너지이다.
<그림 9>는 구글 프레임워크의 전체적인 모습을 나타낸 다이어그램이다. 이 그림을 보면 구글의 프레임워크에 포함되어 있는 중요한 기술들에 대해 알 수 있다.
• 대용량 파일 및 function 가속을 위해 수정된 리눅스
- 기능에 적합하게 튜닝된 리눅스를 사용한다.
• 기능 추가 및 규모 확대에 플러그인 방식에 의해 별도로 손이 가지 않을 정도로 표준화된 분산 구조
- 구글플렉스는 자기 유사 구조를 가지며, 서버의 추가와 오류에 대한 대응이 쉽다.
• 스케일 레벨(scale level)에 관계없이 유사한 기술 구조
- 동형(homogeneous) 구조에 의해 모든 요소들이 구성된다.
• 프로그래밍 언어에 관계없이 기능 구현이 가능한 웹 기반 아키텍처
- 프레임워크의 인터페이스로 WSDL, XML, HTML, POP3, SMTP 등과 같은 플랫폼 독립(platform-independent)적인 프로토콜을 제공한다.
<그림 10> Google's fuction: Hardware and Software Innovations
<그림 11> 구글 검색과 LostGoocle을 이용한 검색의 비교
구글의 프레임워크는 구글 파일 시스템에 의해 구성된 데이터 센터와 분석적 방법으로 광고를집행하는 구글 광고 시스템(Ad System), 각종 서비스 시스템(gmail, News 등), 검색엔진 등을 모두 포함한다.구글플렉스의 외부와 내부에는 새로운 서비스 시스템과 애플리케이션들이 추가될 수 있고, 기본적인 인터페이스들을 통해 구글프레임워크로의 접근과 구글 프레임워크의 기능을 사용할 수 있는 확장적이고 오픈된 구조이다(구글의 피카사(Picasa)나 구글어스(Earth)는 로컬 머신에서 수행되는 애플리케이션을 구글 프레임워크로 포괄시키는 좋은 예이다).
조금 다른 관점에서 본다면, 구글 프레임워크는 소프트웨어 공학과 하드웨어 공학의 접점에 놓여있다. 소프트웨어적인 관점에서 성능을 확보하면서 동시에 하드웨어 공학적인 관점에서 비용 절감을 위한 기술들을 모두 포함한다.이는 비용 절감, 저가형 하드웨어, 스마트한 소프트웨어에 대해 집중하는 구글 문화의 주요 부분이다.
구글 프레임워크는 구글을 여타 다른 경쟁업체와 차이를 갖도록 하는 명확한 요소이다.구글플렉스는 구글 파일 시스템과 구글이 지향하는 성능과 비용절감의 측면에서 매우 효율적인 구조이다. 서버 랙이나 데이터 센터가오류를 일으키더라도 데이터의 손실이나 구글플렉스 전체의 다운은 방지된다. 또한, 동형 시스템의 사용으로 인해 머신의 설치과정이나 설정(configuration)의 표준화와 자동화를 가능케 했다. 이는 타 업체가 소프트웨어 중심의 튜닝이나 하드웨어의업그레이드에 의존해 성능과 안정성을 유지하는 모습과는 상당한 차이를 보인다.
구글의 프레임워크는 또한 구글 내의 개발자는 물론, 일반적인 개발자들에게 아주 좋은 장난감꾸러미(toy box)이다. 구글 프레임워크의 인터페이스를 통해 언제 어디서나 웹과 연결된 환경이라면 구글의 강력한 기능을그대로 활용할 수 있는 것이다. 이러한 확장적이고 오픈되어 있는 프레임워크 구조는 많은 개발자들의 호응을 얻고 있다.
구글 APIs
구글은 개발자들이 쉽게 구글 프레임워크에 접근할 수 있는 API set을 제공한다. 구글이갖고 있는 기술에 쉽게 접근하여 방대한 데이터와 강력한 기능들을 사용할 수 있는 구글 API는 개발자들에게 매력적인 요소일수밖에 없다. 앞서 1부에서 소개한 것처럼 구글에서는 다양한 API들을 제공하는데, 여기서는 가장 대표적으로 사용되고 있는 구글웹 검색 API에 대해 살펴보겠다.
구글 웹 검색 APIs
구글 웹 검색 API는 SOAP과 WSDL 표준을 기반으로 구글과 통신할 수 있는 방식을제공한다. 개발자는 어떤 프로그래밍 언어를 사용하든 상관없이 구글과의 프로토콜만 맞춰줌으로써 구글의 기능을 그대로 사용할 수있다. 구글 웹 검색 APIs 페이지(http://www.google. com/apis/)에는 다음과 같은 프로그래밍아이디어들이 기재되어 있다.
- 주제에 맞는 새로운 정보에 대한 자동 모니터링
- 시간의 흐름에 따른 마켓 분석과 트렌드 분석
- 온라인 게임의 개발 - 새로운 검색 UI의 개발
- 구글의 스펠 체크 기능을 애플리케이션에 추가
<표 3> 구글 웹 검색 APls를 통한 검색 요청에 사용되는 기본적인 파라미터
| 파라미터 명 | 설명 |
| key | 구글 인증키. APls를 다운받은 후 구글로부터 메일로 인증 키를 받아야 한다. |
| q | 질의어 |
| start | 검색 결과 중 불러올 index 번호. 0부터 시작 |
| maxResults | 한 페이지에 최대로 불러올 검색 결과의 건 수 |
| filter | 검색 결과 중 특정 결과들을 필터하기 위한 조건 |
| restricts | 구글 웹 색인 중 서브 셋을 검색하기 위한 조건 |
| safeSearch | 성인 필터링을 위한 Boolean 파라미터 |
| lr | 언어 제한. 특정 나랏말로 된 문서만을 검색하기 위한 조건 |
구글 웹 검색 APIs는 SOAP을 사용하는 웹 서비스 모델과 만나면 굉장한 효과를 발휘할 수있다. LostGoogle(http://lostgoggles.com) 은 구글 API를 이용하여 웹 검색 결과에 해당 페이지의스크린샷을 썸네일로 제공한다. 만약 LostGoogle을 이용하여 아마존닷컴(http:// www.amazon.com)의 내용을검색하고자 하면 아마존닷컴에서 웹 서비스로 제공하고 있는 요소들과 합쳐져 도서에 관련된 훨씬 더 풍부한 정보 도서의 형태,가격, 인기도 등을 볼 수 있다.
구글 웹 검색 APIs를 통한 검색 요청
구글 웹 검색 APIs를 통해 구글로 검색 요청을 보내기 위해 사용하는 기본적인 파라미터는 <표 3>과 같다. 질의어 파라미터에 해당되는 는<표 4>와 같은 형식으로 기술할 수 있다. 부수적인 qualifier들을 사용함으로써 검색 결과를 특정 조건에 맞게필터링할 수 있다. 파라미터들을 이용하여 SOAP을 구성한다면 <화면 2>와 같은 형식으로 구글에 리퀘스트를 날리게될 것이다.
<화면 2> SOAP으로 구성된 구글 검색 요청
<화면 3> SOAP으로 구성된 구글 검색 결과 포맷
<표 4> 질의어 파라미터의 기술 형식
| 쿼리의 성격 | 예제 | 설명 |
| 특정 질의어를 포함 | Star Wars Episode +1 | 일번적인 질의어에 "+ 특정 질의어"를 붙여 일반적인 질의어와 특정 질의어가 모두 출현한 검색 결과만을 출력한다. |
| 특정 질의어를 제외 | bass-music | 일반적인 질의어에 "- 특정 질의어"를 붙여 일반적인 질의어는 출현하지만 특정 질의어가 출현하지 않는 검색 결과만을 출력한다. |
| 특정 어구 검색 | "yellow pages" | 특정 어구가 출현한 검색 결과만을 출력한다. |
| Boolean or 검색 | vacation london OR paris | "word A OR word b" 는 word A 와 word B에 대해 Boolean or 검색 결과만을 노출한다. |
| 사이트 제한 검색 | admission site: www.stanford.edu | 특정 domain에 포함되어 있는 도큐먼트에 대한 결과만을 노출한다. |
| 날짜 제한 검색 | Star Wars datarange:2452122-2452234 | Jullian Date 포맷으로 입력된 날짜 기간동안 생성된 웹 페이지드에 대한 검색 결과만을 노출한다. |
| 제목 검색(팀) | intitle:Google search | "intitle:" 바로 뒤에 명시된 질의어가 제목에 출현한 검색 결과만을 노출한다. |
| 제목 검색(전체) | allintitle:Google search | "alltitle:" 뒤에 명시된 모든 쿼리 팀들이 제목에 출현한 검색 결과만을 노출한다. |
| URL 검색(팀) | inurl: Google search | "inurl:" 바로 뒤에 명시된 질의어가 URL에 포함되어 있는 웹 문서만을 노출한다. |
| URL 검색(전체) | allinurl: Google search | "allinurl:" 로 시작되는 질의어의 경우 명시된 모든 질의어가 URL에 포함되어 있는 웹 문서만을 노출한다. |
| 텍스트만 검색 | allintext: Google search | "alltext:"로 시작되는 질의어의 경우, 명시된 질의어가 웹 문서의 body text 부분에서 출현한 문서만을 노출한다. |
| 링크만 검색 | allinlinks: Google search | "allinlinks:"로 시작되는 질의어의 경우, 명시된 모든 질의어가 앵커 텍스트에서 출현한 문서만을 노출한다. |
| 파일 타입 포함 필터링 | Google filetype: doc OR filetype:pdf | "filetype:" 뒤에 명시된 파일 타입을 포함하고 있는 문서만을 노출한다. |
| 파일 타입 제외 필터링 | Google filetype: doc-filetype:pdf | "-filetype:" 뒤에 명시된 파일 타입을 포함하지 않는 문서만을 노출한다. |
| 웹 문서 정보 | info:www.google.com | 특정 URL에 해당되는 페이지 하나만을 검색 결과로 노출한다. |
| 역 링크 | link:www.google.com | 특정 URL에 역 링크하고 있는 페이지들을 노출한다. |
| 관련 링크 | related:www.google.com | 특정 URL의 페이지와 유사한 페이지들을 노출한다. |
| 캐시된 결과 페이지 | cache:www.google.com web | 구글이 수집하여 캐시해 놓은 페이지를 보여준다. 특정 질의어와 함께 입력되면 해당 질의어에 하이라이팅 처리를 해준다. |
구글 웹 검색 API를 이용한 검색 결과의 수신
SOAP을 이용하여 리퀘스트를 날리면, 구글은 SOAP으로 검색 결과를 회신한다. 회신되는 결과에 포함되는 주요 정보들은 다음과 같다.
<URL> - 검색 결과의 URL path
<snippet> - 검색 결과 웹 페이지 중 입력된 질의어가 출현한 부분을 볼드 처리하여 추출한 웹 페이지 컨텐츠의 일부 스트링
<title> - 검색 결과의 타이틀 - 캐시된 페이지의 KB 크기
<relatedInformationPresent> - related: 요청에 대한 true/false 값
<hostName> - 필터링이 수행되어 한 호스트에서 두 개의 결과가 노출되는 경우, 두 번째 결과에 추가적으로 호스트 네임이 기술된다.
SOAP에 의해 넘어온 검색 결과는 <화면 3>과 같은 형태가 될 것이다.구글 웹 검색 APIs를 다운로드하면 자바로 작성된 간단한 패키지가 포함되어 있다. 이것은 자바를 통해 SOAP 메시지를 구성해구글과 간단하게 통신할 수 있는 환경을 제공한다. 굳이 자바뿐 아니라 SOAP 처리를 위한 기타 프로그래밍 언어의 라이브러리도다수 공개되어 있으니 개발자가 편의에 맞는 언어를 선택해 SOAP 프로토콜을 처리하는 데에는 그리 큰 어려움이 없다.
구글만이 가진 튼튼한 인프라 구조
지금까지 구글의 핵심 기술이라고 불릴 수 있는 요소들에 대해서 간략하게나마 살펴보았다.검색에 대한 기술들이 상당 부분 오픈되어 있는 현재 상황으로 볼 때, 검색 기술에 대한 진입 장벽은 많이 높은 편이 아니다.그럼에도 불구하고 구글이 검색 업계에서 독보적인 위치를 차지할 수 있는 것은 구글만이 갖고 있는 핵심 기술들이 선구적이고 핵심에집중하며 멈추지 않고 성장하고 있기 때문이다. 게다가 그 기술들은 숨겨져 있는 것이 아니라 많은 개발자들을 위해 개방되어 있다.구글의 기술이 개발자들에게 전파되고 전파된 기술들이 역으로 다시 구글을 발전시킨다.
사용자들이 흔히 말하는 바와 같이, 구글의 서비스가 구글스러울 수밖에 없는 것은 구글만이갖고 있는 인프라 구조들이 버티고 있기 때문이다. 최하단의 인프라 구조들과 그것을 아우르는 프레임워크, 그리고 구글이 기술을바라보는 철학이 최상단의 서비스에 영향을 미치고 있는 것이다.
출처: 동우리's rants
# by | 2007/08/13 16:30 | Search Engine | 트랙백(3) | 덧글(6)
◀ 이전 페이지 다음 페이지 ▶
