이 글은 절판도서 "웹 개발자를 위한 대규모 서비스를 지탱하는 기술" 을 개인적인 용도로 정리한 글입니다. 모든 내용을 정리한 것이 아니라 필요한 부분만 정리했다는 점 양해 부탁드립니다
문제/오류가 있을 시 댓글로 알려주면 감사하겠습니다
대규모 데이터 처리 실전 입문
애플리케이션 개발의 급소
- 전문탐색, 유사문서계열 탐색, 데이터 마이닝 등 통계나 검색을 하는 에플리케이션은 광범위한 데이터에 액세스한다
- 대량의 데이터 내의 여기저기에 엑세스하거나 혹은 대부분에 엑세스해서 계산해가므로 애초에 '데이터 내에서 이 부분만'이라고 절단할 수 없다
- 이렇게 RDBMS(MySQL)에서 처리할 수 없는 규모의 데이터를 대상으로 계산하고자 할 때의 방법을 알려준다
용도 특화형 인덱싱
대규모 데이터를 능수능란하게 다루기
| 인덱스와 시스템 구성- RDBMS의 한계가 보일 때
- 위와 같은 경우 RDBMS만으로는 한계가 있다
- 배치 처리로 RDBMS에서 데이터를 추출해서 별도의 인덱스 서버와 같은 것으로 만들고, 이 인덱스 서버에 웹 에플리케이션에서 RPC(Remote Procedure Call 등)으로 엑세스 하는 방법을 사용한다
| RPC(Remote Procedure Call), 웹 API
- RPC는 이전에 API를 부르는 말인 듯 하다(이 책 옛날 책이다)
하테나에서 사용하는 검색 시스템은 다음과 같이 동작한다
1) DB에서 cron등으로 데이터를 추출해서 인덱스 서버로 넘긴다
2) 인덱스 서버에서는 검색용 역 인덱스를 만들어준다(검색 결과 JSON 반환)
3) AP 서버에서는 인덱스를 갖고 있는 인덱스 서버에 API(RPC)로 엑세스 한다
- API 서버에 인덱스를 직접 저장하지 않는 이유는 AP서버에 충분한 메모리가 탑재 되어있지 않은 경우가 많기 때문이다
- AP 서버 아키텍쳐 면에서 볼 때 커다란 검색 인덱스를 여러 프로세스에서 같이 사용하도록 구성하는 것은 적합하지 않다
- AP 서버가 여러개 있을 경우 그 여러대에 전부 인덱스를 갖고 있도록 하는 것도 곤란하다
| 용도 특화형 인덱싱- 튜닝한 데이터 구조 사용하기
- 위와 같은 방식을 용도 특화형 인덱싱이라고 하며 RDBMS에서 어려운 일들을 할 수 있게 한다
- RDBMS는 범용적인 용도(데이터 정렬, 통계, JOIN)로 만들어져있고, 특정한 목적으로만 사용하고자 할 때에는 특정한 목적만으로 사용할 수 있도록 튜닝한 데이터 구조를 사용하면 압도적으로 빠르다
- 검색에서 역 인덱스가 전형적인 예로 자연언어처리와 같은 처리를 미리 한 다음 인덱스를 만들어두면 RDBMS로 데이터를 전부 순회하지 않아도 순식간에 검색할 수 있다
| 예시_하테나 키워드에 의한 링크
- 특정 문서가 20만 이상의(꼭 20만 아니여도 대량의) 키워드 중 무엇을 포함하는지 찾아야할 때 일일히 DB 내에 있는 키워드 목록과 사용자가 작성한 내용을 맞춰보게 되면 DB에 과부하가 걸리게 된다
- 그래서 배치 처리로 20만건의 키워드를 추출해둔다
- 예전에는 굉장히 거대한 정규표현을 만들었다
- 약 10만건의 정규표현이 들어간 거대한 파일을 메모리에 읽은 후 매칭시켰다
- 하지만 오토마톤 중 NFA 특성으로 인해 OR로 연결하면 계산량이 방대해져 속도가 느린 문제가 있었다
- 그래서 정규표현만 사용하는 것이 아니라 Trie 정규표현을 이용해 Common prefix Search를 진행하도록 개선했다
- Common Prefix Search를 할 때 Aho-Corasick법이나 Double Array Trie 등 다양한 알고리즘/데이터 구조를 이용함
- 이러한 데이터 구조를 DB에서 사전에 추출해서 만들어두고 매칭하는 것이 키워드 링크의 방법이다
| 예시_하테나 북마크의 텍스트 분류기
- Complement Naive Bayes라는 알고리즘을 사용해 카테고리 자동 분류를 진행하며, 이 알고리즘을 사용할 때에는 문서에 포함된 단어의 출현확률이 필요하다
- DB에 단어 하나하나를 질의하면 느리므로, 출현확률(출현 빈도)만을 저장해둔 서버를 가동하고 이에 질의를 한다
| 전문 검색엔진
-
전문 검색에서는 다음사항을 유의하며 어떻게 쿼리할 것인가가 중요하다
1) 대량의 데이터에서 검색하고자 한다
2) 빠르게 검색하고자 한다
3) 좋은 느낌(Feeling Lucky)와 같은 문서를 상위로 -
좋은 느낌을 가진 문장을 상위로 가져오는 것이 가장 어려우며 이를 위해 '스코어링'을 한다
-
이 스코어링은 복합적인 것을 고려하며 이루어지며 특정 칼럼으로만 정렬할 수 있는 RDBMS에서는 무리다
-
검색 인덱스를 직접 만들면, 전문 검색 엔진을 직접 구현한다면 스코어링 알고리즘도 자유롭게 선택할 수 있으므로 검색결과를 나열하는 방법은 RDBMS를 사용하는 것보다 더 유연하게 구성이 가능하다
이론과 실전 양쪽과의 싸움
| 요구되는 기술적 요건 규명하기
- 노하우도 좋지만 서비스가 커지면서 문제가 커져감에 따라 배드 노하우가 통용되지 않을 수 있다(ex 분리될 것이니 JOIN을 하지 않는 등)
- 큰 문제를 해결하기 위해서는 이론이 중요하다
- 알고리즘/데이터 구조로 무언가를 실행할 때 어떤 것이 가능한지 머리속에 넣어두지 않으면 '키워드로 링크하고 싶다' 등 실현을 할 때 떠오르지 않는다
나는야 누워있는 개발머신