Create 김현준.md

Author: HyeonJun0530

week5(9~10장)/김현준.md

@@ -0,0 +1,153 @@
+# 9. 웹 크롤러 설계
+
+## 웹 크롤러
+
+검색 엔진 인덱싱
+
+- 웹 페이지를 모아 검색 엔진을 위한 로컬 인덱스 만듦
+
+웹 아카이빙
+
+- 나중에 사용할 목적으로 장기보관하기 위해 웹에서 정보를 모으는 절차
+
+웹 마이닝
+
+- 데이터 마이닝으로 유용한 지식을 도출해 낼 수 있는 것
+
+웹 모니터링
+
+- 저작권이나 상표권이 침해되는 사례를 모니터링
+
+### 문제 이해
+
+웹 크롤러가 만족시켜야 할 속성
+
+규모 확정성
+
+- 병행성을 활용해 효과적으로 많은 양의 웹을 크롤링 해야 한다.
+
+안정성
+
+- 비정상적인 입력이나 환경에 대응해야 한다.
+
+예절
+
+- 수집 대상 웹사이트에 짧은 시간 동안 너무 많은 요청을 보내서는 안된다.
+
+확장성
+
+- 새로운 형태의 콘텐츠를 지원하기 쉬워야 한다.
+
+### 상세 설계
+
+웹은 깊이를 모르기 때문에 BFS를 보통 사용한다.
+
+- 한 페이지에서 나오는 링크의 상당수는 갚은 서버로 되돌아가 같은 호스트에 속한 많은 링크를 다운받아 서버에 수많은 요청이 가게 된다.
+- URL의 우선순위가 없다.
+
+위와 같은 문제점 때문에 동일한 웹 사이트에 대해 한 번에 한 페이지만 요청해야한다.
+
+- 큐 라우터로 같은 호스트에 속한 URL은 언제나 같은 큐로 가도록 보장한다.(매핑 테이블로 정보 유지)
+- 큐 선택기가 큐들을 순회하면서 큐에서 URL을 꺼내 지정된 작업 스레드에 전달한다.
+- 작업 스레드가 전달된 URL을 다운로드한다.
+
+또한 데이터의 신선함을 유지하기 위해 주기적으로 다운로드한 페이지도 재수집해야 한다.
+
+- 웹 페이지 변경 이력 활용 및 우선순위를 활용해 최적화한다.
+- 데이터 크롤링에 대한 정보는 `각 웹사이트 메인 URL/Robots.txt` 에 있음
+
+### 성능 최적화
+
+- 분산 크롤링
+    - 여러 서버에 크롤링을 분산
+- 도메인 이름 변환 결과 캐시
+    - DNS 요청을 보내고 결과를 받는 작업의 동기적 특성 때문에 성능 병목(100ms~200ms)
+    - 크롤러 스레드 가운데 어느 하나라도 이 작업을 하고 있으면 다른 스레드의 DNS 요청은 전부 블록
+    - 따라서 DNS 조회 결과로 얻어진 도메인 이름과 IP 주소 사이의 관계를 캐시 해놓고 크론 잡 등을 돌려 주기적으로 갱신
+- 지역성
+    - 크롤링 서버를 지역적으로 분산해 가까운 지역 서버의 다운로드를 빠르게 한다.
+- 짧은 타임아웃
+- 안정성
+
+### 문제 콘텐츠 감지 및 회피
+
+1. 중복 콘텐츠
+    
+    해시나 체크섬을 사용해 탐지
+    
+2. 거미 덫
+    
+    크롤러를 무한 루프 돌도록 하는 악의적인 웹사이트로 깊은 디렉터리 구조는 최대 URL의 길이로 예방할 수 있다. 그러나 다른 덫을 모두 피하기는 쉽지 않다
+    
+
+# 10. 알림 시스템 설계
+
+모바일 푸시 알림, SMS 메시지, 이메일로 분류 가능
+
+알림 시스템 설계 시 3가지 절차에 대한 설계 필요.
+
+알림 유형별 지원 방안, 연락처 정보 수집 절차, 알림 전송 및 수신 절차
+
+### 알림 유형별 지원 방안
+
+- IOS 푸시 알림
+    - 알림 제공자(provider): 알림 요청을 만들어 애플 푸시 알림 서비스로 보내는 주체다.
+        - 단말 토큰: 알림 요청을 보내는 데 필요한 고유 식별자
+        - 페이로드: 알림 내용을 담은 JSON 딕셔너리다.
+    - APNS(Apple Push Notification Service): 애플이 제공하는 원격 서비스다. 푸시 알림을 IOS 장치로 보내는 역할을 담당한다.
+    - IOS 단말: 푸시 알림을 수신하는 사용자 단말
+- 안드로이드 푸시 알림
+    - IOS와 비슷하되 APNS 대신 FCM(Firebase Cloud Messaging)을 사용한다는 점만 다르다.
+- SMS 메시지
+    - 트윌리오, 넥스모 같은 제 3사업자의 서비스를 많이 이용한다.
+- 이메일
+    - 이메일 서버 구축 및 상용 서비스 이용
+
+### 연락처 정보 수집 절차
+
+알림을 보내려면 모바일 단말 토큰, 전화번호, 이메일 주소 등의 정보가 필요하다.
+
+앱 설치 및 계정 등록 시 API 서버가 정보를 수집해 DB에 저장한다.
+
+### 알림 전송 및 수신 절차
+
+- 1부터 N까지의 서비스: 알림 시스템 서버의 API를 통해 알림을 보낼 서비스들
+- 알림 서버
+    - 알림 전송 API: 스팸 방지를 위해 보통 사내 서비스 또는 인증된 클라이언트만 이용 가능하다.
+    - 알림 검증: 이메일 주소, 전화번호 등에 대한 기본적 검증을 수행한다.
+    - 데이터베이스 또는 캐시 질의: 알림에 포함시킬 데이터를 가져오는 기능
+    - 알림 전송: 알림 데이터를 메시지 큐에 넣는다.
+- 캐시: 사용자 정보, 단말 정보, 알림 템플릿 등을 캐시한다.
+- 메시지큐: 시스템 컴포넌트 간 의존성을 제거하기 위해 사용한다. 다량의 알림이 전송되어야 하는 경우를 대비한 버퍼 역할도 한다.
+- 작업 서버: 메시지 큐에서 전송할 알림을 꺼내서 제3자 서비스로 전달하는 역할
+- 제 3자 서비스 및 단말
+
+수신 절차
+
+1. API 호출하여 알림 서버로 알림을 보낸다.
+2. 알림 서버는 사용자 정보, 단말 토큰, 알림 설정 같은 메타데이터를 캐시나 데이터베이스에서 가져온다.
+3. 알림 서버는 전송할 알림에 맞는 이벤트를 만들어서 해당 이벤트를 위한 큐에 넣는다.
+4. 작업 서버는 메시지 큐에서 알림 이벤트를 꺼낸다.
+5. 작업 서버는 알림을 제3자 서비스로 보낸다.
+6. 제 3자 서비스는 사용자 단말로 알림을 전송한다.
+
+### 상세 설계
+
+- 안정성
+    - 데이터 손실 방지를 위해 알림 데이터를 데이터베이스(로그 DB)에 보관하고 재시도 매커니즘을 구현해야 한다.
+- 알림 중복 전송 방지
+    - 보내야 할 알림이 도착하면 그 이벤트 ID를 검사하여 이전에 본 적이 있는 이벤트인지 살핀다.
+- 알림 템플릿
+    - 알림 메시지의 유사성을 고려하여 인자나 스타일, 링크를 조정해 알람을 만들어내는 틀을 만든다.
+- 알림 설정
+    - 알림 설정을 상세히 조정할 수 있도록 알림 설정 테이블에 보관된 알림 설정을 보고 특정 알림을 보내기 전 테이블을 확인해서 보내야 한다.
+- 전송률 제한
+    - 한 사용자가 받을 수 있는 알림의 빈도를 제한한다.
+- 재시도 방법
+    - 알림을 재시도 전용 큐에 넣고, 같은 문제가 계속해서 발생하면 개발자에게 통지한다.
+- 푸시 알림과 보안
+    - 인증된, 승인된 클라이언트만 해당 API를 통해 알림을 보낼 수 있도록 고려(appKey, appSecret)
+- 큐 모니터링
+    - 큐의 쌓인 알림 수를 보는 모니터링 구축 → 알림 수가 많을 수록 작업 서버 증설
+- 이벤트 추적
+    - 알림 확인율, 클릭율 등을 추적하는 데이터 분석 서비스 기능 통합