제가 9장의 첫 부분을 읽을 때, "크롤러의 대표적인 활용 사례 중 하나가 검색 엔진 인덱싱"이라고 하는 것이 잘 납득이 안 갔습니다.
이는 '검색 엔진'과 '크롤링'의 원리에 대한 이해가 부족했기 때문입니다.
하지만, 9장의 내용을 읽고, 인터넷 리서치를 하고, 여러 가지 실험을 해보면서
개략적인 동작 원리를 파악할 수 있었습니다.
# 특정 키워드로 웹 사이트들을 1초만에 조회하는 방법
2021년 기준으로 WWW (World Wide Web) 상에 존재하는 웹사이트의 개수는 약 20억 개이고
그 중 활성화된 웹사이트의 개수는 4억개라고 합니다.
(이 글의 나머지에서는 대략 10억 개의 페이지들이라고 표현하겠습니다.)
만약 캐싱이나 인덱싱이 되어 있지 않은 빈 메모리, 빈 디스크 상태에서
특정 키워드가 포함된 페이지들을 그때 그때 검색하려면
매번 10억 개의 페이지들을 WAN 통신을 통해 요청하여 일일이 다 받아와야 할 것입니다.
그리고 추가적으로, 각 페이지에서 특정 키워드와 일치하는 String이 있는지 또 한 번 순회를 해야할 것입니다.
이는 1초는 커녕, 수개월이 걸릴 수 있습니다.
이런 문제를 해결하기 위해서는, 사전에 WAN 통신을 통해 얻어온 페이지들을 미리 저장해놓을 필요가 있습니다.
따라서, 검색 엔진을 만들기 위해서는
웹 상에 존재하는 모든 웹 사이트들을 순회하여, 검색에 유리한 자료 구조로 저장해놓는 과정이 필요한데
이를 웹 크롤링이라고 표현할 수 있을 것 같습니다.
# 10억 개의 페이지를 크롤링하여, 복사본을 저장해놓으면 최신 내용이 아닐 텐데?
저는 이런 의문이 들었습니다.
엄청나게 큰 저장소가 있어서, 10억 개의 페이지의 복사본을 모조리 저장할 수 있다고 해보자.
그래도 복사본 페이지들이 저장된 지 10초가 경과하면
3초 전에 수정된 원본 페이지의 내용과 일치한다는 보장이 없을 텐데?
하지만 분명 구글에서 특정 키워드로 검색을 하고, 특정 사이트를 클릭하여 그 페이지로 이동하면
당장 1초 전에 갱신된 내용이 반영된 최신 페이지가 잘 나옵니다.
여기서 저는 방금 제공 받은 페이지가 웹 크롤러의 저장소로부터 얻어온 페이지가 아니라
원본 페이지가 있는 서버로부터 직접 얻어온 페이지라는 것을 알 수 있었습니다.
그럼 검색 결과에서 미리 보기 내용은 '크롤러 저장소'에서 얻어온 내용일까, '원본 서버'에서 얻어온 내용일까?
정답은 '크롤러 저장소'인 것 같습니다.
이런 추론을 하게 된 근거로써, 제가 시도한 실험을 소개해드리겠습니다.
# 내가 올린 게시글의 내용을 수정해보고, 즉시 검색 엔진에서 확인해보기
제가 예전에 올린 게시글들 중 구글 검색 엔진에서 검색이 되는 글이 있는데
링크를 클릭하면, 아래와 같은 제목을 보여주고 있습니다.
이 글의 제목을 수정해보겠습니다.
글의 제목을 수정하고 나서, 구글 검색 엔진에서 재검색을 해도, 검색 결과가 바뀌지 않습니다.
하지만 다시 이 링크를 클릭하면, 바뀐 제목의 페이지가 잘 나옵니다.
이 실험을 통해 저는 다음과 같은 사실들을 깨달았습니다.
검색 엔진에서 나오는 결과는 웹 크롤러를 통해 얻은 시점의 '제목'과 '미리 보기'를 보여준다.
하지만 검색 엔진에서 제공하는 링크를 클릭하면, 원본 서버에 직접 요청하여 원본 페이지를 제공 받는다.
그럼 1초만에 검색이 되는 것도 납득이 가고
최신 페이지를 얻을 수 있는 것도 납득이 가게 됩니다.
검색 엔진의 원리를 다시 정리하자면
웹 크롤러가 매일 24시간 끊임 없이 '새로운 페이지' 또는 '기존의 페이지'들을 크롤링하고
얻어 온 페이지들을 적절히 가공하여, 자신의 저장소에 '생성' 또는 '갱신'하면
유저가 특정 키워드를 질의하여, '검색 결과(=제목, 미리 보기 등)'와 '원본 페이지에 대한 링크'를 제공받게 되고,
이는 검색 성능에 특화된 자료 구조 덕분에 빠르게 제공 받을 수 있습니다.
예전에 저는 다음과 같은 의문이 들었습니다.
내가 올린 게시글이 구글 검색에 반영 되는 데에 왜 일주일이 걸렸을까?
내가 올린 게시글의 제목이 수정된 것이 구글 검색에 반영 되는 데에 왜 3일이 걸렸을까?
이젠 검색 엔진의 원리를 이해하니, 위의 의문들이 해결 되었습니다.
그리고 사이트맵을 제출하면 인덱스 생성이 좀 더 빨리 이루어지는데
(이를 '수동 크롤링'이라고 합니다)
이는 책 9장 154쪽에 나온 '순위결정장치'를 이용하면 될 것 같았습니다.
또 다른 현상이 있는데,
'구글'과 '네이버', '다음'은 똑같은 키워드를 입력해도 각자 다른 검색 결과가 나옵니다.
검색 결과가 배열된 순서가 다르기도 하고,
특정 포털에서는 나오는 검색 결과가 다른 포털에서는 나오지 않는 경우도 있습니다.
이것은 포털마다
인덱싱된 '자료 구조의 형태'나 '검색 알고리즘'이 다르기도 하고
(아래 그림에서는) '시작 URL 집합'과 '미수집 URL 저장소'의 내용이 다르고
'컨텐츠 파서'와 'URL 필터' 등의 구현 방법이 다르며
전체 아키텍처를 다르게 구성했기 때문일 것입니다.
그리고, 검색 엔진의 품질을 높이고 경쟁력을 갖추려면
여러 가지 효율적인 '크롤링 알고리즘'과 '검색 알고리즘'을 고안하고
막강한 컴퓨팅 파워도 갖추어야 할 것 입니다.
구글 검색 엔진의 세부적인 동작 방식은 다음 링크를 참고하시기 바랍니다.
이 링크에는 책 156쪽에 나왔던 Robots.txt 파일에 대한 내용도 나옵니다.
# Open Graph
웹 크롤러에 대해서 공부를 하면서, 문득 떠오른 현상이 또 있습니다.
유튜브 영상의 URL을 인스타그램 DM으로 공유하면
썸네일과 함께 텍스트 설명이 미리 보기로 함께 보이는데
그렇게 공유가 된 뒤에 유튜브 영상의 텍스트 설명을 없애고 나서, 다시 URL을 공유하면
텍스트 설명이 미리 보기에서 사라지지 않고 그대로 남아 있는 현상입니다.
이는 원본 페이지의 변경 사항이 곧바로 반영되지 않는다는 점에서
검색 엔진과 공통점이 있어 보였습니다.
이러한 현상은 인스타그램 뿐만 아니라 카카오톡에서도 마찬가지였습니다.
그래서 내부 동작이 어떻게 벌어지는지 알아보기 위해
티스토리에 직접 게시글을 '생성'하고 '수정'하고 '삭제'하면서
그 사이사이마다 카카오톡 채팅방에 게시글의 URL을 공유해보았습니다.
위와 같은 제목과 내용의 게시글을 작성하고
카카오톡에 URL을 공유했더니
위와 같이 'test3'라는 제목과 'test3'라는 내용이 '미리 보기'로 보여졌습니다.
이제 제목과 내용을 'test4'로 수정하고
다시 카카오톡에 공유했더니, 'test4'로 변경되지 않고 'test3' 그대로 유지되었습니다.
또한, 게시글을 아예 삭제해도 'test3'가 그대로 보였습니다.
다른 기기(모바일, 태블릿, PC)에서 같은 URL을 입력해도, 같은 현상이 발생한 것으로 보아
기기에 로컬 캐싱하는 것은 아닌 것 같았습니다.
왜 이런 건지 인터넷에 찾아보았는데
카톡이나 인스타는 채팅방에 URL 공유 시 '미리 보기'를 위해 OG(Open Graph) 캐시를 쓴다는 것을 알게 되었습니다.
URL이 최초로 입력되었을 때는, 직접 원본 서버에 요청하여 내용을 읽어 캐싱하고
2번째 이후부터는, 원본 서버에 원본 내용을 요청하지 않고, 이미 캐싱된 내용을 그대로 쓰는 것입니다.
신기하게도 카카오톡은 이 링크에서
누구나 특정 URL에 대한 캐시를 제거할 수 있도록 열어놓았습니다.
이번에는 캐시를 제거한 뒤, 다시 URL을 공유했더니
'test4'로 변경된 것이 잘 반영된 미리 보기가 뜨는 것을 볼 수 있었습니다.
캐시를 제거하였으니, 다시 원본 서버로부터 최신 내용을 받아왔기 때문입니다.
그리고 이번에는
게시글을 비공개로 전환하거나, 게시글을 삭제한 상태에서
캐시 초기화와 함께 URL을 공유해보았는데
아무런 미리 보기 없이, 대화 내용만 떴습니다.
연관 챕터
25
조사 내용
# '크롤러'랑 '검색 엔진'이랑 무슨 상관??
제가 9장의 첫 부분을 읽을 때, "크롤러의 대표적인 활용 사례 중 하나가 검색 엔진 인덱싱"이라고 하는 것이 잘 납득이 안 갔습니다. 이는 '검색 엔진'과 '크롤링'의 원리에 대한 이해가 부족했기 때문입니다.
하지만, 9장의 내용을 읽고, 인터넷 리서치를 하고, 여러 가지 실험을 해보면서 개략적인 동작 원리를 파악할 수 있었습니다.
# 특정 키워드로 웹 사이트들을 1초만에 조회하는 방법
2021년 기준으로 WWW (World Wide Web) 상에 존재하는 웹사이트의 개수는 약 20억 개이고 그 중 활성화된 웹사이트의 개수는 4억개라고 합니다. (이 글의 나머지에서는 대략 10억 개의 페이지들이라고 표현하겠습니다.)
만약 캐싱이나 인덱싱이 되어 있지 않은 빈 메모리, 빈 디스크 상태에서 특정 키워드가 포함된 페이지들을 그때 그때 검색하려면 매번 10억 개의 페이지들을 WAN 통신을 통해 요청하여 일일이 다 받아와야 할 것입니다. 그리고 추가적으로, 각 페이지에서 특정 키워드와 일치하는 String이 있는지 또 한 번 순회를 해야할 것입니다. 이는 1초는 커녕, 수개월이 걸릴 수 있습니다. 이런 문제를 해결하기 위해서는, 사전에 WAN 통신을 통해 얻어온 페이지들을 미리 저장해놓을 필요가 있습니다.
따라서, 검색 엔진을 만들기 위해서는 웹 상에 존재하는 모든 웹 사이트들을 순회하여, 검색에 유리한 자료 구조로 저장해놓는 과정이 필요한데 이를 웹 크롤링이라고 표현할 수 있을 것 같습니다.
# 10억 개의 페이지를 크롤링하여, 복사본을 저장해놓으면 최신 내용이 아닐 텐데?
저는 이런 의문이 들었습니다.
하지만 분명 구글에서 특정 키워드로 검색을 하고, 특정 사이트를 클릭하여 그 페이지로 이동하면 당장 1초 전에 갱신된 내용이 반영된 최신 페이지가 잘 나옵니다.
여기서 저는 방금 제공 받은 페이지가 웹 크롤러의 저장소로부터 얻어온 페이지가 아니라 원본 페이지가 있는 서버로부터 직접 얻어온 페이지라는 것을 알 수 있었습니다.
정답은 '크롤러 저장소'인 것 같습니다. 이런 추론을 하게 된 근거로써, 제가 시도한 실험을 소개해드리겠습니다.
# 내가 올린 게시글의 내용을 수정해보고, 즉시 검색 엔진에서 확인해보기
제가 예전에 올린 게시글들 중 구글 검색 엔진에서 검색이 되는 글이 있는데 링크를 클릭하면, 아래와 같은 제목을 보여주고 있습니다.
이 글의 제목을 수정해보겠습니다.
글의 제목을 수정하고 나서, 구글 검색 엔진에서 재검색을 해도, 검색 결과가 바뀌지 않습니다.
하지만 다시 이 링크를 클릭하면, 바뀐 제목의 페이지가 잘 나옵니다.
이 실험을 통해 저는 다음과 같은 사실들을 깨달았습니다.
그럼 1초만에 검색이 되는 것도 납득이 가고 최신 페이지를 얻을 수 있는 것도 납득이 가게 됩니다.
※ 참고1 : 검색 엔진은 얼마나 많은 디스크 공간이 필요한가? ※ 참고2 : 구글 검색 엔진의 스냅샷
# 검색 엔진과 관련된 그밖에 다양한 현상들
검색 엔진의 원리를 다시 정리하자면 웹 크롤러가 매일 24시간 끊임 없이 '새로운 페이지' 또는 '기존의 페이지'들을 크롤링하고 얻어 온 페이지들을 적절히 가공하여, 자신의 저장소에 '생성' 또는 '갱신'하면 유저가 특정 키워드를 질의하여, '검색 결과(=제목, 미리 보기 등)'와 '원본 페이지에 대한 링크'를 제공받게 되고, 이는 검색 성능에 특화된 자료 구조 덕분에 빠르게 제공 받을 수 있습니다.
예전에 저는 다음과 같은 의문이 들었습니다.
이젠 검색 엔진의 원리를 이해하니, 위의 의문들이 해결 되었습니다.
그리고 사이트맵을 제출하면 인덱스 생성이 좀 더 빨리 이루어지는데 (이를 '수동 크롤링'이라고 합니다) 이는 책 9장 154쪽에 나온 '순위결정장치'를 이용하면 될 것 같았습니다.
또 다른 현상이 있는데, '구글'과 '네이버', '다음'은 똑같은 키워드를 입력해도 각자 다른 검색 결과가 나옵니다. 검색 결과가 배열된 순서가 다르기도 하고, 특정 포털에서는 나오는 검색 결과가 다른 포털에서는 나오지 않는 경우도 있습니다.
이것은 포털마다 인덱싱된 '자료 구조의 형태'나 '검색 알고리즘'이 다르기도 하고 (아래 그림에서는) '시작 URL 집합'과 '미수집 URL 저장소'의 내용이 다르고 '컨텐츠 파서'와 'URL 필터' 등의 구현 방법이 다르며 전체 아키텍처를 다르게 구성했기 때문일 것입니다.
그리고, 검색 엔진의 품질을 높이고 경쟁력을 갖추려면 여러 가지 효율적인 '크롤링 알고리즘'과 '검색 알고리즘'을 고안하고 막강한 컴퓨팅 파워도 갖추어야 할 것 입니다.
구글 검색 엔진의 세부적인 동작 방식은 다음 링크를 참고하시기 바랍니다. 이 링크에는 책 156쪽에 나왔던 Robots.txt 파일에 대한 내용도 나옵니다.
# Open Graph
웹 크롤러에 대해서 공부를 하면서, 문득 떠오른 현상이 또 있습니다. 유튜브 영상의 URL을 인스타그램 DM으로 공유하면 썸네일과 함께 텍스트 설명이 미리 보기로 함께 보이는데 그렇게 공유가 된 뒤에 유튜브 영상의 텍스트 설명을 없애고 나서, 다시 URL을 공유하면 텍스트 설명이 미리 보기에서 사라지지 않고 그대로 남아 있는 현상입니다.
이는 원본 페이지의 변경 사항이 곧바로 반영되지 않는다는 점에서 검색 엔진과 공통점이 있어 보였습니다.
이러한 현상은 인스타그램 뿐만 아니라 카카오톡에서도 마찬가지였습니다.
그래서 내부 동작이 어떻게 벌어지는지 알아보기 위해 티스토리에 직접 게시글을 '생성'하고 '수정'하고 '삭제'하면서 그 사이사이마다 카카오톡 채팅방에 게시글의 URL을 공유해보았습니다.
위와 같은 제목과 내용의 게시글을 작성하고 카카오톡에 URL을 공유했더니
위와 같이 'test3'라는 제목과 'test3'라는 내용이 '미리 보기'로 보여졌습니다.
이제 제목과 내용을 'test4'로 수정하고
다시 카카오톡에 공유했더니, 'test4'로 변경되지 않고 'test3' 그대로 유지되었습니다. 또한, 게시글을 아예 삭제해도 'test3'가 그대로 보였습니다.
다른 기기(모바일, 태블릿, PC)에서 같은 URL을 입력해도, 같은 현상이 발생한 것으로 보아 기기에 로컬 캐싱하는 것은 아닌 것 같았습니다.
왜 이런 건지 인터넷에 찾아보았는데 카톡이나 인스타는 채팅방에 URL 공유 시 '미리 보기'를 위해 OG(Open Graph) 캐시를 쓴다는 것을 알게 되었습니다.
URL이 최초로 입력되었을 때는, 직접 원본 서버에 요청하여 내용을 읽어 캐싱하고 2번째 이후부터는, 원본 서버에 원본 내용을 요청하지 않고, 이미 캐싱된 내용을 그대로 쓰는 것입니다.
신기하게도 카카오톡은 이 링크에서 누구나 특정 URL에 대한 캐시를 제거할 수 있도록 열어놓았습니다.
이번에는 캐시를 제거한 뒤, 다시 URL을 공유했더니 'test4'로 변경된 것이 잘 반영된 미리 보기가 뜨는 것을 볼 수 있었습니다.
캐시를 제거하였으니, 다시 원본 서버로부터 최신 내용을 받아왔기 때문입니다.
그리고 이번에는 게시글을 비공개로 전환하거나, 게시글을 삭제한 상태에서 캐시 초기화와 함께 URL을 공유해보았는데 아무런 미리 보기 없이, 대화 내용만 떴습니다.
인스타그램(페이스북)도 캐시를 제어할 수 있는 페이지를 제공했는데
카카오톡과 달리 좀 더 상세한 캐시 정보를 제공했고 캐시를 삭제하는 기능이 아닌 캐시를 갱신하는 기능을 제공했습니다. (다시 스크랩)
@caffeine-library/readers-system-design-interview