대규모 서비스를 지탱하는 기술 -3-

검색 시스템의 아키텍처

검색이 가능하기 까지

• 크롤링
• 저장
• 인덱싱
• 검색
• 스코어링
• 결과 표시

처음은 검색할 대상 문서를 가져와야 한다.

대상 문서가 있다면 웹 크롤러를 만들어서 대량 문서를 가져오는 작업이 필요하다.

→ 가져온 문서를 어떻게 저장할 것인가 문제가 있다. 예를 들어 하나의 db에 저장하면 db가 장애날 경우 복원할 수 없다 따라서 분산 데이터 베이스에 저장해야 한다

가져온 문서로부터 인덱스를 구축하는 것이 필요하다

가져온 문서가 얼마나 정확한지 평가하는 랭킹이 필요하다

전문 검색의 종류

• grep 형 : 검색 대상 문서를 처움부터 전부 읽는, 단순한 아키택처
  • 장점 : 즉시성이 좋다. 즉 문서가 갱신되더라도 바로 검색할 수 있으며 검색 누락이 없다. 단순해서 병렬 처리도 간단한다.
  • 단점 : 속도가 느리다
• suffix 형 : 문서를 검색 가능한 형태로 가지고 있다.
  • 장점: 빠르게 검색할 수 있다
  • 단점 : 문서를 검색 가능한 구조로 만들어야 하기 때문에 구현하기 어렵다
• 역 인덱스형 : 단어와 문서를 연관짓는 것
  • 장점: 인덱스를 압축함으로써 대규모화하기 쉽다
  • 단점: 인덱스를 문서로 부터 전처리하는 과정이 있으므로 즉시성 측면에서 좋지 않다

대규모 데이터 처리 서버 인프라

엔터프라이즈 : 기업 환경을 운영하기 위한 시스템 ex) 은행 시스템, 산업 시스템 등

웹 서비스 : 사용자를 위한 시스템

엔터프라이즈 vs 웹 서비스

	엔터프라이즈	웹 서비스
트래픽	그다지 많지 않음	굉장히 많음
성장성	적당한 정도	폭발적
신뢰성	타협 불가 사수해야 한다	성능과 타협을 볼 수 있음
트랜잭션	많이 사용	필요한 부분 사용

 

웹 인프라 특징

• 저비용 고효율을 중시한다. 효율성을 위해서, 성능과 신뢰성을 타협을 본다.
• 확장성과 응답성을 중요시한다. 빠르게 성장하기 때문에 성장속도를 파악하기 어렵고, 사용자의 경험을 위해 빠르게 응답한다
• 서비스 사양이 바뀌는 경우가 있다. 기능이 빈번하게 추가되거나 없어지는 경우가 있으므로 유연하게 대응할 수 있어야 한다
• 변화가 빠른 웹 서비스인 만큼, 개발 속도가 중요시 된다. 따라서 배포를 편하게, 확장 가능하게 만든다

확장

계층별 확장성

AP 서버 : 상태를 가지고 있지 않기 때문에 간단히 확장할 수 있다. 로드밸런스에 새로운 서버를 추가해주기만 하면 된다.

DB나 파일 서버 : 분산과 확장하기 어렵다. 쓰기 작업은 데이터 정합성을 위해 동기화 되어야 하므로 분산하기 어렵다.

부하를 측정하는 항목

load average 본다. load average는 대기 상태의 프로세스 수 이다. 따라서 cpu 부하나 i/o 부하가 없울 수록 0에 수렴한다.

부하는 서비스 용도에 맞게 제어한다. 응답이 느려도 괜찮은 경우는 부하를 허용함으로써 서버당 요청처리 수를 높인다. 응답이 빨라야 하는 경우 부하를 줄임으로써 서버당 요청처리수를 낮춘다.

tip 하테나에서는 대체로 cpu 코어의 수 이하에서 절반 정도로 맞춰지도록 조절한다

다중성 확보

로드밸런서

지속적으로 서버의 상태를 점검한다(헬스 체크). 만약 고장이 난 서버가 있다면 자동적으로 분리하고(페일오버), 서버가 복구되면 원상태로 복귀시키는 작업을 수행한다.(페일백)

데이터베이스

멀티 마스터 방법 사용(서로가 서로의 슬레이브가 되는 상태로 하고 양방향으로 레플리케이션을 한다).

상태 체크는 VRRP라는 프로토콜로 감시한다. 만약 Active가 장애시 StandBy가 Active로 승격한다.

외부에서는 Active와 StandBy를 구분하기 위해 서비스용 IP 가상 주소를 사용한다.

스토리지 서버

트래커, 스토리지 노드, 트래커 DB로 이루어져 있다

• 스토리지 노드 : 실제 파일이 저장되는 곳
• 트래커 : 특정 URL과 실제 파일 처리 담당
• 트래커 DB : 특정 URL에 대한 실제 파일 위치를 저장

시스템 안정화

CPU나 메모리를 한계치 까지 사용하는 경우, 예기치 상황에서 장애가 발생할 수 있다.

따라서 메모리 70% 정도, CPU 70% 정도 사용하는 등 여유를 가질 수 있게 설계하는 것이 중요하다

시스템 불안정 요인

어플리케이션 메모리 문제 → 메모리 누수등 어플리케이션 점검과 메모리 상한을 둔다

사용자 엑세스 패턴 → 조회가 많은 리소스의 경우 캐시 서버에서 전달한다.

데이터량 증가 → 데이터 설계를 바꾸는 등 데이터를 압축하는 것이 중요하다

안정화 대책

적절한 버퍼 유지와 불안정 요인을 제거한다

적절한 버퍼 유지

시스템의 임계점을 정해서 임계점이 넘어가는 경우, 서버를 증설하거나 메모리를 늘리는 방안을 사용한다

불안정 요인 제거

• SQL 부하 : 통계용 쿼리등 무거운 쿼리는 배치용 DB에 날려 운영 서비스와 분리한다.
• 이상 동작시 자율 제어
  • 자동 DOS 판정 : 시간안에 특정 IP로 부터 요청이 반복적으로 오면 엑세스 차단한다
  • 자동 재시작 : 리소스를 지나치게 사용했다고 판단하면 웹 서버 재시작한다
  • 자동 쿼리 제거 : DB 서버에서 쿼리 수행시간을 파악해 시간 경과한 쿼리를 강제 종료한다