다음은 웹 개발자를 위한 대규모 서비스를 지탱하는 기술을 읽고 정리한 내용입니다 🙌


  • 이전에는 미들웨어를 살펴보면서 운용에 대한 생각을 했다면 이제는 개발에 대한 생각을 하면서 어플리케이션 개발시 고려해야할 급소들에 대해서 살펴보도록 한다.
  • 대량의 데이터에 액세스 (그리고 이러한 데이터들을 특정 부분을 절단하기 어려운 경우가 대부분이다)를 할 대 RDBMS, MySQL등에서 처리할 수 없는 규모의 데이터를 계산하고자 할 경우를 살펴본다.

[강의14] 용도특화형 인덱싱

인덱스와 시스템 구성 - RDBMS가 한계를 보일 때

지나치게 많은 데이터를 다루는 경우 (검색 등) RDBMS로는 한계가 있다. 그렇다면 해결 방법은 ?

  • 배치 처리로 RDBMS에서 대량의 데이터를 추출
  • 별도의 인덱스 서버와 같은 것에 데이터를 보관
  • 웹 어플리케이션에서 RPC(Remote Procedure Call)등으로 액세스 하도록 처리

RPC, 웹 API

  1. DB 가 정기적으로 데이터를 추출해서 인덱스 서버로 넘긴다.
  2. 인덱스 서버에서 검색용 인덱스를 만든다.
  3. WAS 서버에서 인덱스를 가지고 있는 인덱스 서버에 RPC로 액섹스 한다.
    • 여기서 말하는 RPC는 웹 API 이다.
    • 웹 서버에 직접 인덱스를 저장하지 않는 이유는 웹 서버의 용량이 주로 충분하지 않기 때문이다.
    • 대용량 인덱스 데이터를 여러 프로세스에서 공유하는 것은 적합하지 않다.
    • 여러 WAS를 두었을 때 각각 그런 대용량 인덱스를 가지고 있는 것은 매우 비효율적이다.

용도특화형 인덱싱 - 튜닝한 데이터 구조 사용하기

  • RDBMS와 같은 경우는 여러 용도를 가지고 만들어져있다 → 여러 관계형 데이터들을 여러 방식으로 처리할 수 있도록 만들어져 있다.
  • 만일 특정 목적으로 튜닝한 데이터구조를 사용하면 그 목적에 대해서는 압도적으로 빨라질 수 있다.
    • 예) 검색에서의 역 인덱스
    • 자연어 처리를 모두 해두면 데이터를 전부 순회하지 않아도 검색을 처리할 수 있는 등의 속도 개선을 할 수 있음
  • 전문 검색 엔진을 사용
    • 대량의 데이터를 검색하고자 할 때 용이

[강의15] 이론과 실전 양쪽과의 싸움

  • RDBMS에서 Join을 사용하지 말라는 것은 Bad Knowhow 같은 것이다.
    • 이런건 이론에서 추구하기에는 이상한 개념이지만 실전에서 마주한 노하우 같은 것이다.
    • 대규모 어플리케이션을 하면서 이론과 실전의 적절한 균형이 매우 중요하다.
    • 너무 이론을 추구하다보면 실전에서 걸림돌이 되는 경우도 많다.
    • 이론을 모른다면 엄청난 규모의 데이터에서 문제가 생겼을 때 노하우만으로는 해결되지 않는 때가 많아진다.